| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | | |
it belongs. Robustifying the request sanitization a bit more.
|
| | | |
| | |
| | |
| | | |
Finally eliminated dependency on Puppet.start, etc., from WEBrick HTTP server class. {webrick,mongrel}+REST now support request handling uniformly; need encode/decode next.
|
| | | |
| | |
| | |
| | | |
bits for request handling prior to the encode/decode/exception-handling bits. Refactored to make the common logic extractable to a base class.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
indirection, as the REST vs. XMLRPC models are different enough that the object must register itself on initialization and handle the request when it comes in.
|
| | | |
| | |
| | |
| | | |
into Indirection to look up models from indirected names.
|
| | | |
| | |
| | |
| | | |
unknown HTTP Server types; fail fast.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
need to start up a webrick server w/ address + port (this is far too incestuous with Puppet lib & Puppet.start at the moment).
|
| | | |
| | |
| | |
| | | |
classes are named.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
base server / http server classes + specs.
|
| | |\| |
|
| | | | |
|
| | | | |
|
| | |\ \ |
|
| | |\ \ \ |
|
| | |_|_|/
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I've provided backward compatibility with the old
handler.
The only terminus type that currently exists for reports
is the 'code' terminus, which is used to process reports
in the style of the old handler. At some point, we should
likely switch at least some of these report types (e.g., 'store')
to terminus types.
|
| |\ \ \ \
| |/ / /
|/| | /
| | |/
| |/| |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 the configuration system. 'puppet' itself still
works, even with -e, but I expect that puppetd and
puppetmasterd are broken, and there are still quite a few
broken tests because the default fact store can't write but
that's the default behaviour for a networked configuration
master.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
Server. Using Server as the master class for client connections. Server (former RESTServer) will instantiate the appropriate subclass based upon Puppet configurator setting. There are now tests broken in the network section which I can't seem to figure out yet. Not a happy place to be.
|
| | | |
|
| | |
| |
| |
| | |
spec; fleshing out more behavior, implementing.
|
| | | |
|
| | |
| |
| |
| | |
getting the added examples to pass.
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
now be more reasonable.
|
| | |
| |
| |
| | |
name, functionality, and/or location in the tree is subject to change, but it's down now somewhere so we can move forward on it.
|
| |/
|
|
| |
client-side REST terminus behavior.
|
| | |
|
| |
|
|
|
|
|
| |
'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".
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
lib/puppet/defaults.rb
lib/puppet/indirector/facts/yaml.rb
spec/unit/indirector/indirection.rb
spec/unit/indirector/indirector.rb
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
| |
and are used instead of the network handlers, which have been removed. There are some failing tests as a result, but I want to get this code committed before I massage the rest of the system to make it work again.
|
| |
|
|
| |
indirector. I have not yet added the tests for the node handlers themselves, which is next.
|
| |
|
|
| |
autoload, which could class with Kernel.autoload.
|
| | |
|
| |
|
|
| |
but it is unfortunately disabled because we cannot realistically fix it using the current design. It will be easy after the REST refactor, though.
|