Charm Store Series and Ubuntu Release

[Gustavo Niemeyer]

Hi Clint,

On Tue, Aug 28, 2012 at 2:08 PM, Clint Byrum <clint at ubuntu.com> wrote:
> At UDS-Q, we had a pretty interesting discussion of how we should set
> charm store release policy. To recap, many of us came into the discussion
> thinking we would rubber stamp a really simple idea: never freeze.
>
> But as we discussed it, it became clear that our desire for a laissez
> faire policy was misguided. While its fantastic to be on the bleeding
> edge, users also need to be able to build their applications on top of
> the infrastructure that the charm store provides. If we ship MySQL 5.5
> in the precise mysql charm, we can't just make the next 'upgrade-charm'
> ship 5.6, which will most likely include "breaking" changes. We also can't
> go re-arranging the relations, as that might break a deployed service.

"Never freeze" and "do unreasonable upgrades" are not the same thing.
Never freeze, as originally discussed, implied that it was ok to
continue improving the original charm. I still think this is a fine
idea.

> We have a bit of an issue with regard to the inter-LTS releases as well.
> Our focus is on stable deployments, and quite a large percentage of those
> come on LTS releases. But we'd like to also make sure charms can take
> advantage of the latest releases of Ubuntu (such as the upcoming quantal)
> as well.
>
> So, I'd like to get a discussion started about what to do about this issue.

What you described above sounds like normal Ubuntu lifestyle, rather
than an issue. What's the actual issue?


> One idea I have is to use an overlay system to reduce cross-series overhead.
>
> Basically it should work something like this:
>
> * Current LTS release of Ubuntu is the base.
>
> * Newer releases assume everything from base, and apply delta on top
>
> * New LTS is copied from the overlay of old LTS + newest stable
>
> * Adding charms to current LTS requires testing on newest stable (so next LTS
> has a higher probability of working).
>
> --
> Implementation Details
>
> * In doing this, we would not run the 'branch-distro' script on launchpad.
> development on quantal. Instead, we would simply change it from
> "experimental" to "development focus". We would perhaps need a variation on
> branch-distro to copy precise+delta -> "T".
>
> * We would need to change charm-tools to overlay based on the series
> requested. Currently charm-tools assumes the current dev focus will have
> all charms.
>
> * Charm store and charm world code would also need to be changed to do
> the overlay logic

I'm afraid the whole thing went over my head. I don't understand
what's an "overlay" in that sense, nor what is the actual problem.

As a base line, we have charms for specific Ubuntu releases, which
matches reality given that different Ubuntu releases have different
software in them, and different images in IaaS providers. We can
target charms to those releases, and we can have a default release.
All of this seems inherent to the problem domain. We can manipulate
the conventions that exist on top of that baseline to better fit
development practices, but given that it matches the problem
description, I don't think we need to change juju or the charm store.
Perhaps I misunderstand, but that's my impression at the moment at
least.

gustavo @ http://niemeyer.net