Hi,
This is formatted as an answer to Evelio, but in fact it's more general
and addressed to all the people in this thread.
On 30/06/13 23:06, Evelio VILA wrote:
>
> Hi Andy;
>
> I'm taking this to mean that you find that iteration constructs and
> new structures move the language away from simplicity and their
> utility does not offset that lo
>
> ss of simplicity. Is that right?
>
>
> indeed. I should had been more clear ;)
>
>
>
> We've found that many end up resorting to using inline templates to
> do many things that are not related to generating text, which is
> what a template is intended to be. Have you not found that to be the
> case for you?
>
>
> i dont remember using inline template as a last resort solution. it is
> true though that its a pretty useful hack. every time i am confronted
> with a need for a loop, i use create_resources. if the problem reveals
> to be more complicated than that, then we turn to other types of
> solutions(functions, providers, etc)
I don't manage a large infrastructure but I'm a Puppet user for a long
time, and have about 150 internal modules (some doing crazy
configurations). I've never used create_resource, and the only time I
had to abuse "inline_template" was to get access to the 'ipaddress' fact
of a given dynamic ethernet interface (ie like emulating
"${ipaddress_${public_if}}", which the new parser wouldn't help solve).
So I think the current state of the DSL is enough for maybe 90% of the
user needs (including me). The other 10% might need a more beefy DSL,
which I thought would be the ruby DSL, but alas this one wasn't fully
feature-full for those usages.
When I first read about the new parser, I had mixed feelings. Like you I
had liked the development time to be spent on speeding Puppet than
adding features for 10% of the users. On the other hand revisiting the
parser would might help speed it, make it more strict or more correct
(or why not change it completely to something based on treetop). Now
that this is implemented, then the discussion is over :)
> i think that that feature is a drift on puppet 'fundamentals'.
>
> on the other hand, what we would really love to see:
>
> a serious increase on performance. simply adding more resources to the
> master or installing more masters when the number of clients grow is
> clearly not a scalable solution. imho there are lots of work to be done
> here. (even if ruby has its limitations on this matter)
By definition this is scalability :)
Since masters are in a share nothing setup (except for the CA part), you
can scale to lots of nodes.
I think that 3.x is way better (I mean about performances) than any
previous version of Puppet. If you hangout on this ML for long, you'll
certainly have seen me, Peter Meier or other people complain about
performances since a long time :)
There are still a lot of performance things to fix (and those were
reported a long time ago, desperately needing a fix):
* recursive file permission change is still a memory/cpu hog
* file content management still produces a lot of md5 checksum
computations (combined with recursivity for more cpu consumption) (do we
really need all those md5 checksum? can't we trust that we
received/wrote the files correctly?)
* re-serialization of the catalog on the agent consumes cpu and memory,
while we could just save the on-the-wire catalog (I know this one is
very complex to solve, and the gain might not be that much).
That's too bad because the two first points are usually hit by newcomers
to Puppet and configuration management. Those people might run to other
products (which certainly have other shortcomings or performance issues).
I'd also really like to see catalog caching on the server side. The
static compiler was a good start, but somehow the effort stopped.
Catalog caching can be done quite easily at the http level (with caching
http proxy like varnish or nginx) with a bit of help from the master and
the node (ie identifying what facts are importants or not), at the
expense of a bit of atomicity regarding file sourcing. That would be
perfect for infrastructure like mine that rarely change (or at least not
every 30 minutes).
> a production ready 'environment' feature: we have found from our own
> experience and also on irc that the risk of 'leak' between environments
> is so high that makes it unusable on production.
>
> more emphasis on security. not long ago we were migrating a master to a
> PCI dss environment and i recall making a question on irc about this
> subject. to my surprise, i learned that the master relies on a fact for
> client auth and not on the dn of the certificate!(or maybe i just got it
> all wrong). anyway, my point here is that puppet stills some work in
> this area.
Are you sure about your assertion regarding agent authentication?
To my knowledge (and how I initially designed the auth.conf stuff), we
were using the client certificate as given by the webserver (either
webrick or rack).
What is true is that the node will request a catalog for his own
hostname. With the default auth.conf only the matching client
certificate DN can request this catalog. If you change your auth.conf,
then you risk opening the system to other nodes.
What you might refer is the hostname fact. This fact is coming straight
from the client (like all facts) and as such might be spoofed if someone
compromised the node. Unlike the client certificate dn which is used in
the auth.conf checks.
> testing testing and more testing. we need tools to test the catalogs
> locally. (a coworker works on a tool to addr this issue
> http://lpuppet.banquise.net) people are forced to use all sorts of hacks
> in the toolchain like apply the catalogs on a test server to check that
> nothing broke , and a bunch of other similar solutions.
May I point you to:
* rspec-puppet:
http://rspec-puppet.com/
and
* puppet-spec:
https://github.com/camptocamp/puppet-spec
Those should cover your need for catalog testing.
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
