| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
This is all of the plumbing work, the only real thing
left to do is to fix the Settings class so that it
uses Puppet::Resource instances instead of TransObject
and TransBucket.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
|
|
|
| |
Signed-off-by: Luke Kanies <luke@madstop.com>
|
|
|
|
| |
Signed-off-by: Luke Kanies <luke@madstop.com>
|
|
|
|
| |
Signed-off-by: Luke Kanies <luke@madstop.com>
|
|
|
|
|
|
|
| |
I wasn't adding the catalog to the defined types when creating
the transportable objects.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
|
|
|
|
|
|
| |
interpolation, not both, to avoid issues where a #{} interpolated value
contains a % character.
Signed-off-by: Daniel Pittman <daniel@rimspace.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if there were an error creating a resource,
the error would propagate leaving any previously
created resources still in memory.
Now, resources are removed by default when an error
happens during instantiation, and the error propagates
to the caller so that they can log or whatever.
This also allows the Settings class to correctly and
separately handle the cases where we can't create the
catalog (which should never happen in normal usage but
was happening because of this error -- later catalogs
couldn't be created because earlier catalogs left
resources lying around) from those where we can't
apply the catalog.
|
|
|
|
| |
removing the bangs from 'add_vertex!' and 'add_edge!'.
|
| |
|
|\ |
|
| |
| |
| |
| | |
compatibility
|
|/
|
|
| |
and old client
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
there were enough problems fixing it that I decided something
more drastic needed to be done.
This uses the new Puppet::ResourceReference class to canonize
what a resource reference looks like and how to retrieve resources
via their references. Specifically, it guarantees that resource types
are always capitalized, even when they include '::' in them.
While many files are modified in this commit, the majority of changes are
quite small, and most of the changes are fixing the tests to use
capitalized types.
As we look at consolidating some of our resource types, we could consolidate
the ResourceReference stuff at the same time, but at least the
Puppet::Parser::ResourceReference class subclasses the main Puppet::ResourceReference
class.
|
|
|
|
|
|
|
|
| |
resources. These are commits:
c19835ce9f8a5138b30a1a32ca741c996b0916d2
9290cc89a2206fb5204578f8e91208857a48b147
ffb4c2dbc7314b364d25e4f7be599ef05b767b44
|
|
|
|
|
|
|
|
|
|
| |
references to resources. It deprecates the class-level
[] and []= methods, used for so long to provide closure
behaviour but now unnecessary with the node configuration's
ability to function as a resource container.
All of the spec tests pass, but there is much to do to make
the test/ tests pass, I expect.
|
|
|
|
|
|
|
|
|
| |
from the server. The real problem was getting all of the validation
done before any caching, which required a good bit more refactoring
than I expected.
In actuality, this commit is relatively small even though it covers
many files; most of the changes just make the code clearer or shorter.
|
|
|
|
| |
provider test work on non-Debian platforms.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first real pass towards using caching. The `puppet`
executable actually uses the indirection work, instead of
handlers and such (and man! is it cleaner).
Most of this work was a result of trying to get the client-side
story working, with correct yaml caching of configurations, which
means this commit also covers converting configurations to yaml,
which was a much bigger PITA than it needed to be.
I still need to write integration tests, and I also need to cover
the server-side story of a normal configuration retrieval.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've gone too far down the rabbit hole to turn back now, but the
code is clearly getting more centralized around the Configuration
class, which is the goal.
Things are currently a bit muddy between recursion, dynamic resource
generation, transactions, and the configuration, and I don't expect
to be able to clear it up much until we rewrite all of the tests
for the Transaction class, since that is when we'll actually be
setting its behaviour.
At this point, Files (which are currently the only resources that
generate other resources) are responsible for adding their edges
to the relationship graph. This puts them knowing more than I would
like about how the relationship graph works, but it'll have to do for now.
There are still failing tests, but files seem to work again. Now to
go through the rest of the tests and make them work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ever converting the Transportable objects into a tree of components
and then converting that into a graph. This is a significant
step, and drastically simplifies the model of how to use a configuration.
The old code might have looked something like this:
file = Puppet::Type.create :path => "/whatever", ...
comp = Puppet::Type.create :name => :whatever
comp.push file
transaction = comp.evaluate
transaction.evaluate
The new code looks like this:
file = Puppet::Type.create :path => "/whatever", ...
config = Puppet::Node::Configuration.new
config.add_resource file
config.apply
I did not really intend to do this much refactoring, but I
found I could not use a Configuration object to do work
without refactoring a lot of the system. The primary problem
was that the Client::Master and the Config classes determined
how the transactions behaved; when I moved to using a Configuration,
this distinction was lost, which meant that configurations were
often needing to create other configurations, which resulted in
a whole lot of infinite recursion (e.g., Config objects that create
directories for Puppet use Configuration objects -- yes, I'm
s/Config/Settings/g soon -- and these Configuration objects would
need to create directories).
Not everything is fixed, but it's very close. I am clearly over
the hump, though, so I wanted to get a commit in.
|
|
|
|
| |
than the base PGraph class. I expect I will just do away with PGraph, but for now, I am at least going to keep configuration-related code in that class.
|
|
|
|
| |
generate a graph, rather than having to first convert to RAL types and then have them convert to a graph. This allows us to make it so components do not need a @children array at all. This was all done because I am having the "already a parent of" problem again, and I have gotten far enough that it is relatively easy to just make this problem go away once and for all.
|
|
|
|
| |
that has a resource graph including resources for the container objects like classes and nodes. It is apparently functional, but I have not gone through all of the other tests to fix them yet. That is next.
|
|
|
|
| |
environments, including the parser having an environment setting. I have also created my first spec-based tests, for the interpreter (and deleted the old test/unit tests).
|
|
|
|
|
|
| |
them, the manifest will be incorrect
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@2068 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
significant rewrite of the parser, but it has little affect on the rest of the code tree.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1726 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
tests can more easily tell when an object is invalid.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1597 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1519 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1256 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
there are checks in both directions to stop this.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1246 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
through all of the code and s/collectable/exported/g (thanks to womble for that term).
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1193 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
recognizes it, the AST objects retain the settings, the scopes do the right conversion, the interpreter stores them all in the database, and then it strips the collectable objects out before sending the object list to the client
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1189 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
ActiveRecord into a database (I have only tested sqlite3). Tomorrow will be the grammars used to retrieve those records for object collection.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1187 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1153 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
to puppet nodes work. The biggest change is that there is now a separate NetworkClient class for every Client subclass, because otherwise you get namespace collisions. Most everything other change is a relatively minor patch.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@1145 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@953 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
though: overrides now only work within a class heirarchy, which is to say that
a subclass can override an element in a base class, but a child scope cannot
otherwise override an element in a base scope.
I've also done a good bit of refactoring, though; notably, AST#evaluate now
takes named arguments, and I changed the 'name' parameter to 'type' in all of
the Component classes (this was all internal, but was confusing as it was).
I also removed the need for the autonaming stuff -- it's now acceptable for
components not to have names, and everything behaves correctly. I haven't yet
removed the autoname code, though; I'll do that on the next commit.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@952 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@948 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@929 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
specifying both the name and the namevar, or just a name and having the namevar set.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@896 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
been modified to expect their new behaviour. I have not yet run the test across all test hosts, though.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@873 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
configuration parameters can be converted to a configuration file, a manifest, or a component. All I have to do now is integrate them into the executables.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@872 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
necessary to get basic isomorphism from code to transportables and back. Mostly keyword and autoname stuff.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@871 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
of key bugs
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@841 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
in a YAML format, also. This required a significant rework of both Transportable classes. Lastly, I am also now caching the list of classes in a class file in /etc/puppet.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@816 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@787 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@786 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
| |
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@785 980ebf18-57e1-0310-9a29-db15c13687c0
|
|
|
|
|
|
| |
paths look much better now, and Transportable is much cleaner.
git-svn-id: https://reductivelabs.com/svn/puppet/trunk@740 980ebf18-57e1-0310-9a29-db15c13687c0
|