"Why wouldn't apache make a good charm?" -- Some more thoughts

[Clint Byrum]

I get this question a lot, and I've debated the issue in public and private
quite a few times now, with no clear answer.

I have given it some solid thought though, and here is what it boils down to:

* The charm store is about real deployments *

With Ubuntu, we release every 6 months. The cycle goes something like this:

* Open dev, update a bunch of new libraries/subsystem changes/etc
* Rebuild everything in the archive that deps on old library versions
* Patch things that break because of ABI/API changes
* Remove old library versions
* Test Upgrades
* Fix bugs
* Release

This works great for tightly integrated software, but it leaves us
with *exactly* the problem Juju is trying to solve. Wordpress works
with a number of ways to configure it. The packager can be a tiny bit
opinionated with Recommends, but this usually leaves users with a lot
of steps between 'apt-get install wordpress' and a running blog.

However, if we look at how things went down for OMG Ubuntu, we see that
a real deployment became a real charm that is generic for wordpress users.

Now, there's been some desire to make a generic Nginx charm that will
allow other deployments to work like Wordpress. This is where it gets
tricky. Because now, the nginx charm starts having residual, unintended
effects. One can't be sure that by changing the nginx charm to work
better for their particular deployment story, they're not breaking it
for the other users. This is true for the Nginx package as well, but we
have release cycles to test for this. Thus far, the charm store has no
such thing.

We can of course start versioning the interfaces. But because we don't
have a release/freeze policy, its not clear how long we'll carry the
old interfaces.. but one would think, nearly forever. Its not enough to
just look in the store for consumers of an interface, you have to have
a way to communicate to users that the interface they're used to using
is going away.

So, that, combined with the complexity it adds in deploying has me still
in the camp that, at least for now, we should not do generic charms for
things like Nginx or Apache. For now, copying the goodness between charms
is going to result in more user confidence because they'll at least know
that the maintainer has tried it *as it is*.

Now, there is a way out of this mess. We have all talked about stacks
quite a bit, and the suspense is starting to kill me. But I do think that
having stacks plus same machine placement will give us a more compelling
reason to go ahead and start versioning interfaces, and maybe even to
have frozen releases of the stack collection.

Thoughts?