| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
what transportable resources get converted to, so
different names don't throw it off.
I also got rid of the Puppet::Type#merge method, which
has been deprecated for ages but was still in there. I
had to fix a few tests that weren't cleaning up after themselves
as a result.
|
| |
|
|
|
|
|
|
| |
resources. These are commits:
c19835ce9f8a5138b30a1a32ca741c996b0916d2
9290cc89a2206fb5204578f8e91208857a48b147
ffb4c2dbc7314b364d25e4f7be599ef05b767b44
|
| |
|
|
|
|
| |
At this point, I'm holding the experiment until after the release,
so I'm committing this for now and will take it back up after 0.24.0
is out.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
to Puppet::SimpleGraph, which should dramatically enhance
performance. It should be largely functionally equivalent,
with the only difference being that edges are no longer deduplicated.
|
| |
|
|
|
|
|
|
|
|
| |
file recursion was previously not working, because
the relationship graph was setting itself as a resource's
primary configuration, which caused it to try creating its
own relationship graph.
I've now found that the current code is about 5x slower than
the released code, so now I hope to resolve that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, for example, the configuration terminus that was a
subclass of 'code' would have been stored at
lib/puppet/indirector/code/configuration and would have had
to have been named 'configuration'. Now, the subclass
can be named however the author prefers, and it must be stored
at lib/puppet/indirector/configuration/<name>.rb, where <name>
is the name you've chosen for the terminus type. The name only
matters insomuch as it is used to load the file from disk and
find the appropriate class when asked.
The additional restriction is that the class constant for the terminus
type must have its name as the last word, and the indirection must
be the second to last word. Thus, in our example, we can choose
any class constant that ends with Configuration::Code; given that
there's only one Configuration class at this point, it makes the
most sense to define the class as Puppet::Node::Configuration::Code.
This is somewhat awkward, because of the class's location on disk,
but the only other real option is to autogenerate a
Puppet::Indirector::Configuration class constant, which is, I think,
uglier.
|
| |
|
|
|
|
| |
This counts as the first commit where configuration compiling
actually uses the caching correctly according to the application
model.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to work. As a result, it involves a lot of integration-level
testing, and a lot of small design changes to make the code
actually work.
In particular, indirections can now have default termini,
so that configurations and facts default to their code terminus
Also, I've removed the ability to manually control whether
ast nodes are used. I might need to add it back in later,
but if so it will be in the form of a global setting,
rather than the previous system of passing it through 10 different
classes. Instead, the parser detects whether there are AST nodes
defined and requires them if so or ignores them if not.
About 75 tests are still failing in the main set of tests,
but it's going to be a long slog to get them working --
there are significant design issues around them, as most of
the failures are a result of tests trying to emulate both the
client and server sides of a connection, which normally would
have different fact termini but in this case must have the same
terminus just because they're in the same process and are global.
The next step, then, is to figure that process out, thus finding a way
to make this all work.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into the indirection system. There are still quite
a few unanswered questions, the two most notable
being embodied in unimplemented tests in the Configuration
Code terminus.
This also requires changing the behaviour in a few places.
In particular, 'puppet' and the 'module_puppet' cfengine
module need to store a Node object in memory with the appropriate
classes, since that's now the only way to communicate with
the compiler. That integration work has not yet been done,
partially because the old configuration handler (which the
soon-to-be-deprecated master handler now uses) still exists.
|
| |
|
|
|
|
|
| |
'Puppet::Util::Settings'. This is to clear up
confusion caused by the fact that we now have a
'Configuration' class to model host configurations,
or any set of resources as a "configuration".
|
| |
|
|
|
|
|
|
| |
it's time to merge it back into the indirection branch.
Considering that this work was what drove me to create the
indirection branch in the first place, i should now be able to
merge both back in the master branch.
|
| |
|
|
|
|
|
|
|
|
| |
in place, which means I'm over the hump in developing
this branch.
I have to fix some design flaws I made in the configurations,
particularly that the 'runner' handler needs to be able to
specify tags and whether to ignore schedules, but otherwise,
I think it's straightforward test- and bug-fixing from here out.
|
| |
|
|
|
|
|
|
| |
branch. The file recursion code actually works for the first
time in a painful while, but there are still some quirks and design
issues to resolve, particularly around creating implicit resources
that then fail (i.e., the behaviour of the create_implicit_resource
method in Configuration).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
are inside a configuration, so the resources can interact with the configuration to get things like relationships.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
instead of pre-extracting the configuration.
|
|
|
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.
|
