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

[David Cheney]

Hello Clint,

I agree with your position. One question, does this observation about apache and the http server interface extend to any charm that fulfils an interface?

Does it follow that if an interface is bound to a particular release, all the implementations of that interface inherit this property?

Dave 

On 04/10/2012, at 8:15, Clint Byrum <clint at ubuntu.com> wrote:

> 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?
> 
> -- 
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju