Quoting Luke Kanies <[EMAIL PROTECTED]>:
Hmm, so each organization would be responsible for building their own
tool chain, huh? Seems you should at least have a best-practice tool
chain, just to make it easy for people. In the long run, your
approach is clearly superior; in the short term, the current
generation of sysadmins can't handle that, unfortunately. That's why
I've tried to build Puppet as a cohesive tool chain but keep it as
uncoupled as possible.
Sure, but you and I have very different objectives. I am more
interested in demonstrating what _can_ be done, and maybe offering
options to tool developers/independent sysadmins who would only write
their own stuff (mostly) anyway. A big problem I see is that a large
number of people say "oh but my site is totally different I need to
start again on the whole tool thing..." My hope is that maybe some
chunks of this can change the way tools are made.
Ah. This is problematic, IMO, because it makes it very difficult to
share configurations -- you can only share with those who share the
same template policy as you.
Sure, but as above. It would be ideal if we could all share
configurations, but that comes with a canonical language and
infrastructure. This is not aimed at making a single infrastructure,
its aimed at supporting or being a part of any particular
infrastructure that someone might come up with. Someone says "hey I
need to build files from key-value pairs" and my hope is that I'm
offering a small incentive to use the "standard" format with a
pre-existing example of a tool that works this way.
Heh, that's redundant in Puppet -- it's Puppet's job to translate
from attributes to a record:
User { shell => "/bin/bash" } # set a default
user { ed:
home => "/home/ed",
uid => 500,
...
}
...
Sure, but Puppet isn't a 14 line shell script. The point was that it's
not so hard to get some kind of automation in place around it. I'm not
suggesting that having a "files" map is desirable, but, as far as I can
tell, the closer the examples I give are to what I consider a desirable
solution, the less obvious it is how the example works to everyone else.
When yo usay web applications, what do you mean? jsp/php/asp? Sure,
that's a similar problem, but one that isn't dealing with:
Ruby's ERb, perl's HTML::Template, and plenty more.
potentially hostile input (templates)
Puppet's templates are all stored server-side, so they're no more
hostile than the configurations themselves.
Sure, but you're talking about a specific choice you made for what
you're selling as an integrated tool. I was trying not to limit how it
could be used. I can imagine a situation in which grplace was a
back-end for tools for users that allowed them to tweak some config
files. In that case, you have to be more careful.
This is a common conception in the sysadmin world -- that somehow
sysadmins operate in a more dangerous environment than developers. I
don't understand it and I don't agree with it.
I think I'm much closer to being a developer than a sysadmin... But if
you work as a developer on a large codebase, not only do things
inexplicably fail, you can find that you just can't fix them without
huge amounts of work/pulling in colleagues for consulting / so forth. I
think the complexity of a large software project is still probably
higher than that of the average site, but my point is that if I break
my working copy of our software, there's very little penalty associated
with that:
1) rollback is basically free, except I lose my changes
2) our users aren't beating down my door because some fraction of their
network disappeared.
3) I can test exhaustively locally before I check my code back into the
main pool.
4) Even then it has to go through several rounds of Q/A and several
months of testing in-house before it goes out to clients.
Which of these is true for a sysadmin using current generation tools?
Rollback is seldom cheap (although some systems improve this I agree).
Testing the whole thing at scale (integration testing) is pretty hard
for a sysadmin to do, even though as a developer you take it for
granted. And how many sites employ professional testers to find the
holes you missed in your config?
I agree with the markup syntax and escaping problems. I have not
tried to assess ERb's suitability for specific syntaxes, but even
then I'd still prefer a common templating system that could be used
to support different syntaxes than a specialized one that would be
new and different to everyone.
I also must say that your templating system doesn't, um, seem all
that user-friendly. :)
Hard to say. I don't think its so bad, but then I wouldn't. It's a
little ugly, but you're forced into that because of delimiters. Other
than that, its just a very simple language that's enough to generate
config files... It doesn't really seem like there's much space for it
to be friendly or unfriendly.
How does ERb handle multi rooting? That is, one requirement I had was
that I be able to use the file "foo.grp" to make multiple different
files from inside the same template. So you run it with its root as
a.b.c and it pulls its values from inside a.b.c, but you can run it
again with its root as a.b.d and it pulls its values from inside there
inside. I found myself needing to do this with sxprof when I was
automating grid tools for configuration from lcfg, but I had to hack it
there.
Looking at the ERb code, this is just "ruby in delimiters". Which is
fine, but I don't see it as distinguished from PHP. It works in some
situations, sure, but not all of the situations I was trying to
accomodate. Anyway, each to their own I suppose; the objective was to
make something simple that would be an alternative way of making files,
largely inspired by sxprof (you can find the template language in
appendix F of the lcfg manual online).
Heh; good luck with someone adopting it as their own. :) I can't
even get people to help much with Puppet and I'm actively running it.
Oh, and it's not written in C. :)
Psh. Most of the OS is written in C :p
Ed
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
