1st Time user feedback
gustavo.niemeyer at canonical.com
Sun Apr 10 14:14:12 UTC 2011
Ahmed, I'm moving that to the public Ensemble mailing list, I hope you
> I had played hands-on with ensemble a few days ago for the first time, and I
> really liked what I saw! Awesome work. "Service" management is most
> definitely the future. Gustavo had asked me to take notes of my first
> impressions, so here it is. This is basically things that I found confusing
> or have thoughts/comments/wishes for. I'm just dumping them here, maybe they
> would be useful to anyone.
Awesome, thanks Ahmed.
Please note that at this point in time we don't really have the "best
practices" part well nailed down, though. We've just started writing
our first formulas, and will be understanding how to best use the
mechanisms of Ensemble as we go, so no conventions you see being used
within formula hooks are settled on stone.
> 1- For the mediawiki formula, db-relation-changed hook. Line 206 I see
> parameter validation. Since it's should be quite common to validate
> parameters from formulas that someone else has written, it strikes me as a
> point where the ensemble framework can really help by allowing a formula
> writer to attach "validators" to the relation data expected (number, text,
> file path, email address ...etc)
We may do something about that in the future, but I don't see that
kind of validation being performed in that file. It's checking to see
if the other side of the relation has provided the necessary settings
and it may move on.
> 2- For the mediawiki formula, db-relation-changed hook. Line 248, The
> mediawiki formula is reaching over the network, directly connecting to the
> mysql database and injecting a sql statement to create a table. What I find
> most irritating is that specific mysql syntax is written inside mediawiki.
mediawiki's db relation is necessary to mysql. E.g. from its formula:
> 3- In metadata.yaml, a relation has an interface type like
> interface: mysql
> I am not sure if "mysql" is just free-form text, or if it actually specifies
> an "interface" which if implemented by a formula, that formula would qualify
It actually means something. It defines, in a loose way, the protocol
in which formulas communicate to each other through that specific
> 4- Is there a way to share code, or provide some "utility" functions that
> are going to be most commonly needed. For example I see some Clint magic to
> create a random password using
> secret_key = open("/dev/urandom","r").read(32).encode('hex')
Ensemble can make use of everything Ubuntu offers in packaged form,
and any other tools necessary can also be shared among formulas by
putting them in packages. Soon we'll enable the package dependencies
to be declared in the formula itself, to make that even more
Clint could have opted to use makepasswd instead in the case you
mention, for instance.
> 5- For the mediawiki formula, db-relation-changed hook. Line 249, I see
> Clint needed to write code to detect whether or not this is the first time
> for the hook to run. Again, I see this as being a common enough need, that
> perhaps ensemble should provide a generic solution for.
Not entirely. He's checking if the table existed previously, which may
happen after an arbitrary number of executions from the hook, even the
first one since another equivalent formula may have created it
beforehand. In other words, this is a convention from the formula
> 6- Related to the previous point, I just found the x-relation-changed hooks
> to be too loosely defined. i.e. it's a bit confusing exactly when events
It's not loosely defined. It necessarily fires after settings in the
relation have changed.
> dpkg has (prerm, postrm, preinst, postinst) which are crystal clear, perhaps
> we could have similar hooks allowing clear (initialization, teardown,
> node-added, node-removed...etc). It's a hard problem defining those
Yes, we've actually changed a bit recently to go a bit more into that
direction. We now have:
So that's pretty much where we're going indeed.
> 7- Is there anything in the system to guarantee idempotency? Should a
I'm not sure about what you mean here. There are lots of things in
the system to guarantee idempotency in unrelated areas, but you
probably have something specific in mind which is not clear to me.
> formula writer worry about the order of hooks firing, and whether or not
> they would fire more than once
Hooks fire in the order that the events themselves happen. E.g. you
won't see db-relation-departed before you see db-relation-joined.
That's unrelated to idempotency, though.
Thanks again for taking the time to present that feedback, Ahmed.
More information about the Ensemble