Narayan Desai wrote:
"Luke" == Luke Kanies <[EMAIL PROTECTED]> writes:
Luke> The problem is that there appears to be a split whether we
Luke> want it or not. The last few workshops have been very
Luke> frustrating for me, because they haven't really even tried to
Luke> address how a sysadmin would take advantage of what we talked
Luke> about. Tools are cool and great, but how do they make
Luke> people's lives better?
Luke> I'm in the midst of building a large framework (hell, it's >
Luke> 50k lines with test code) and a community around that
Luke> framework. How can the workshop help me make a better tool?
Luke> How can the workshop help my users more effectively use
Luke> Puppet? How can the workshop help potential users choose
Luke> between the different tools?
Perhaps I was wrong, maybe there are three classes of attendees:
researchers, tool developers, and users. I am not sure if I actually
believe this is a good split. I agree strongly with Paul; being
current in the research is critical for anyone who is going to write
tools today that won't be discarded before tomorrow.
I would always expect the tool developers to be responsible for merging
the research and practice; I don't think we'd get much benefit from just
having tool developers talk to each other about their tools.
I'm not trying to be down on research, but I often feel like Config-mgmt
research is in the string theory realm where we can talk for years but
don't carry out any experiments. Good research is founded in good data,
and there's precious little data in the config-mgmt world. And for the
record, I'm not the only one who feels this way -- after every workshop,
I have a few people come up and complain that they sat through the same
workshop the year before.
I've got what I think is a good way to get data, or something like it,
and I'm full-up on research until I make a bit of progress. I have a
theory, I'm testing it, and I'm trying to make a living at the same time
(the fact that I'm trying to survive by developing Puppet surely has an
impact on how I see all of this).
If I come across research that affects my ability to test my theory, I
want to integrate it; if I come across data that either supports or
disproves my theory, then I clearly need to know about it; but there are
many areas of research that are effectively orthogonal to my experiment,
and I just can't be interested in staying up on all of those, just like
my wife (who's a cancer researcher) has only a passing interest in areas
other that cell-cycle research.
Luke> And when I say "better tool", I mean today, this week, next
Luke> month -- not some day, not three years from now. As a
Luke> developer, I'm looking for great features to add, like bcfg2's
Luke> reporting or LCFG's spanning maps, and how those features will
Luke> affect my users.
I guess that I come down in the middle on this one as well; those
features aren't just features; they are research and theory put into
practice.
Clearly some features are just features, and some features are
theory-backed. If they don't become features at some point, though, I
don't have a lot of use for them, so I'm more interested in the features
than the theory, at least as it pertains to my day-to-day job right now.
Luke> I've tried to talk about the theory behind Puppet, and it gets
Luke> a very poor reception, if not sometimes outright hostile. I
Luke> am pretty set in how Puppet works, and I'm in the
Luke> put-up-or-shut-up phase. No one seems particularly interested
Luke> in the fact that I'm trying to create an operating system
Luke> abstraction layer, so the best I can do is create what I think
Luke> is a good tool and see if others are interested in using it.
Luke> I think it's theoretical suicide for any automation tool *not*
Luke> to either create or use an operating system abstraction layer,
Luke> but I'm apparently the only one who thinks that.
I have two points here. I think that you are conflating theory and
design here. For example, (a little closer to home), I could say that
an aspect of the design used by bcfg2 is similar to the formalization
of closures theory work that Alva has done. I think they are two
different things, and this is important distinction.
I could certainly be conflating the two; if that's the case then I
probably have no theory and only a design, which seems somewhat unlikely
but would be tolerable to me. At the least, I expect Puppet to be
fertile ground for research if someone were so inclined, because it
would be a clean line between the interesting stuff above (compiling
configurations, for instance) and the boring crap below (what's the
order of arguments to crontab on linux vs. Solaris?), and I certainly
hope that other people can take advantage of Puppet agents and its
library to avoid reinventing the wheel.
On the second point, I just don't think anyone is all that interested
in the OS abstraction layer; everyone deals with this issue somehow;
Paul uses sxprof constructs and plugins in LCFG, we use our group
structure and client code to do this in Bcfg2, etc.
I have not yet seen anything that I would consider to be an operating
system abstraction layer in any other tool. LCFG has very high-level,
opaque plugins that manage entire semantic chunks of work -- if you want
to convert from the sendmail plugin to the postfix plugin, well, good luck.
I don't know enough about Bcfg2 to know how well it could function as an
abstraction layer; at the least, all of the modeling is on the server
and not accessible in a library or on the agent (which I know was a
design goal of yours, whereas I wanted the exact opposite), which means
that it is not an abstraction layer that other tools could take
advantage of. However, from what I can tell, Bcfg2 knows a lot about
file formats, which are generally non-portable -- heck, even the use of
files is non-portable, as trying to create a host on an OS X box will show.
Right now, any ruby script could do any of the work Puppet does --
instrospect system state, install packages, start or stop services,
create hosts, mount file systems, etc. -- portably and easily. You can
use Puppet to copy objects from one machine to another, across platforms
-- you could copy a user from a Linux box to a Solaris box, for instance.
My theory is that system administration, operating systems, and
computing in general are all being held back by how unnecessarily
difficult it is to manage heterogeneity, and to a lesser extent by how
much legacy code there is around because of how difficult it is to
migrate off it. My corollary theory is that building an abstraction
layer capable of hiding 95% of the implementation details of operating
systems and applications will allow system administration to improve
dramatically, to the point where it will far more closely resemble
programming than today's idea of administration. I believe these are
both theories, and I have created a design that I am trying to implement
in order to test them.
Yes, Puppet also includes a simple language that you can use for
compiling configurations for your hosts, but the language is mostly
there because the library is useless without a tool that uses it. You
could think of the language as a separate tool, really, and in truth
they are almost entirely decoupled -- you could easily replace the
language with another configuration compiler, and in fact I've toyed
with creating a simple domain-specific language in ruby (that is, you'd
write valid ruby code that would compile down to client configurations,
rather than the custom Puppet language).
Again, I agree no one cares about the abstraction layer, but I am
flabbergasted that this is the case. I assume no one cared about
portable languages when C and libC were developed either; I know I don't
have the smarts of Kernighan et al, but I'll keep pushing until I fail
or someone smarter takes over, I guess.
Luke> I'm sure there are critical theoretical flaws in Puppet, but
Luke> they don't seem to be affecting me or my users. What is
Luke> affecting us is that I'm still doing 98% of the development
Luke> and I have a relatively small user base. What I want to know
Luke> as a tool developer is how to fix that, and as an
Luke> experimentalist I need the same answers so that the experiment
Luke> can be carried out with a more complete framework and a wider
Luke> set of test subjects.
This is only one aspect of being in line with current theory. I made a
big design mistake in bcfg, theory predicted it early, but I ignored
it until it became a big problem. When it happened, it became a fire
to put out. I learned my lesson there.
What was the design mistake? Did you know it was a mistake when you
made it? Did you make it because you didn't know about the theory, or
because you thought the theory was wrong?
I have done my very best to keep up on current theory and to apply it
whereever I can (although I have admittedly fallen behind recently,
since I've been so busy implementing), and Puppet's language was
designed with current theory as much as possible (e.g., I've somewhat
implemented what I see as Alva's closures within Puppet's language, to
great success).
I haven't seen much new theory recently that I can directly apply to
Puppet, though; either it's really great validation work that could be
plugged into Puppet's language if only I had the time and the ability,
or it's based on operating below the abstraction layer, which I take as
an axiomatic line for config-mgmt tools.
People at the config-mgmt workshop have told me that Puppet has flaws
that contradict current theory, but the majority of this criticism has
been dirisive to the point of being rude and was also made without much
actual knowledge of Puppet, so I have chosen to ignore most of it.
Incidentally, a customer just paid me to fix a significant problem in
Puppet's parser; the problem existed because I couldn't figure out how
to fully implement an aspect of closures, so rather than allow looseness
I left functionality out. The customer wanted that functionality
finished, so I was able to significantly enhance the language while
remaining consistent with theory.
The other thing I am trying to keep in mind is building bcfg2 in such
a way that i can plug in advanced infrastructure as it becomes
available. This isn't easy much of the time, but I think that it is
goal in the long term.
That is definitely my goal; you should be able to replace any part of
Puppet that you don't like (the client/server stuff, the language, or
the library) with minimal rewriting, and it should be very easy to
create new layers between existing layers. It should also be easy, in
general, to expand the core -- Puppet will automatically load all kinds
of code that you drop into your ruby search path, like language
functions, resource types (files, packages, filesystems, etc.), resource
providers (e.g., "package" currently has 16 different providers, like
apt, yum, blastwave), and quite a bit more.
It should take very little effort to hook a validation engine up to
Puppet's compiler, and I'd love to be able to do so; but I'm not likely
to actually write the engine unless a customer pays me for it, because I
just don't have time.
Luke> The config-mgmt BoF has averaged more than 70 people every
Luke> year since I've been running it; you just can't get the same
Luke> intimate discussion in that kind of environment. And having
Luke> the full 8 hours is very useful.
I agree. I think that the topical area for the practice workshop will
be dramatically different from the current config workshop. I would
only expect it to siphon off people that are not interested in the
research topics. I expect many people to attend both.
I expect the same thing; it's not so much a membership change I was
looking for as it was a focus change.
--
It has recently been discovered that research causes cancer in
labratory rats.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
_______________________________________________
lssconf-discuss mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
