Sprint Feedback

[Tom Haddon]

On Tue, 2011-06-07 at 09:44 -0300, Gustavo Niemeyer wrote:
> > I guess I'm meaning in a more comprehensive way in terms of managing the
> > state of the servers as a whole rather than the specific service we're
> > talking about. Since Ensemble seems to work in terms of executing
> > scripts, this means you know that certain scripts have been run, but you
> > don't know the end state that that's achieved in terms of configuration
> > files on disk, for example.
> (...)
> > Ok, this would be kind of crucial to us (and I'm sure others too). Being
> > able to preview changes and confirming they'll do what you expect is key
> > to being happy with making changes on production systems.
> 
> Yes, this is analogous to installing a package, for instance.  When
> you tell a configuration management system "ensure apache is
> installed", what's actually happening is that some files are being put
> on disk, and some scripts are being run, but you can't tell for sure
> which ones, because the package abstracts that away for you, and in
> many cases people trust those that put the package in place to do it
> properly. 

This is actually specifically why we don't use Puppet to install
packages for us in the normal case. Instead we use it to mark "dpkg
--set-selections" and then take care of the package install itself
manually. Basically we try and avoid any time that we might be telling
Puppet to dump bits onto a server in a way that we can't be sure what
the outcome of that might be.

>  Similarly, when you change a setting in the kernel with
> such configuration managements, all they will present you is that they
> are changing something, but what is actually happening when the kernel
> receives such request?
> 
> What is happening in both of those cases is that the complexity of
> configuring and running software is being taken away from the person
> running the system.  We all feel much more comfortable when we know
> _exactly_ what is going on about _everything_, but as time passes and
> things become more complex, we have to acknowledge our own inability
> of knowing it all, and instead trusting other people in the area they
> excel at.

Sure, we're all abstracting things out and trusting other people with
certain parts of the system. I'm not writing all the code that runs on
my system, I'm using packaged code, etc., but that doesn't mean you
still don't have visibility on the changes being made or having control
over what changes you're comfortable with. For instance, managing /etc
in bzr allows you to see any configuration changes made by either a
package install or a changed kernel setting, or whatever.

> In that spirit, unlike existing systems, Ensemble does more than
> simply reacting to the administrator's requests, and that's why we
> call it a service orchestration framework.  The system is alive at all
> times, reacting to changes in an event-based fashion.  When a new
> dependency is plugged, the other services have a chance to execute
> code for adapting themselves to the new setup.  When someone is
> scaling up a service by adding a new unit, the other services will
> react accordingly.

So fwiw, we can (and are) doing much of this in Puppet as well. I won't
say it's as easy syntactically as Ensemble promises to be, but we do
have services that we can scale up very trivially and other parts of the
system will react accordingly (as an example, we say we want two new
application server instances on a specific server, and they get
automatically added into nagios and cricket monitoring, the haproxy
frontend for the service they are part of, etc.).

> That's not to say we disagree with your vision.  We understand it, and
> we already have started acting on introspection and observation
> capabilities (debug-log, debug-hooks, etc), and will investigate how
> to do more in the area of dry-running as you're suggesting.  What I'm
> saying is just that there's an underlying capacity that we can't
> compromise, and it's based on the fact services are encapsulated,
> autonomous, replaceable, reactive, and so on. These are the reasons
> why we're doing Ensemble in the first place, and that's why and how
> we're taking configuration management a step beyond.
>