Sprint Feedback

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Tue Jun 7 12:44:59 UTC 2011

> 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.  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.

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.

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.

Gustavo Niemeyer

More information about the Ensemble mailing list