Charm Store Series and Ubuntu Release

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of 2012-08-28 10:55:23 -0700:
> 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.
> 

The line that we draw with releases of Ubuntu is too extreme for Juju's
more focused goals and more limited scope, so yes, we can continue to
improve the charm. We can add new relations, update to reasonably compatible
releases of the core software for the charm, etc.

However, asking for MySQL 5.6 is not all that unreasonable of an upgrade.
Especially if they were to release it as GA right now, in a year it would
be the one people are starting to migrate to. But we can't just make it
the default, as that will break peoples' deployments. So we need to decide
how and when to introduce breaking changes. Waiting 2 years is too long,

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

The difference is subtle. The LTS of Ubuntu itself cannot receive *any*
changes that are not important bug fixes, including that it cannot add
any new software that doesn't enable new hardware or or fix a major bug.

Because of this, the inter-LTS releases receive the bulk of development.

But with the charms in the charm store, we are suggesting that we can
add capabilities and new software to the LTS.  This changes the dynamics
in a way that will have an impact on the inter-LTS releases, and thus, on
the next LTS.

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

The problem is that we want to develop these charms with a focus on the
LTS, instead of on the current dev release of Ubuntu. Because of this,
we need to encourage development and testing of the current dev releases
of Ubuntu, which will be *harder* to do since we are not rejecting new
development from the LTS.

The overlay is meant to provide an easier way to use the dev releases.
Its taken from the way Debian experimental works. Its likely that a large
portion of the charms will "just work" in the new release, so we can
just keep using the LTS charms without changing them and without going
through the trouble of copying branches/merging/auto-pushing or anything.
Just assume, if there's no charm X in this release of the charm store,
then use charm X from the last LTS.

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

A good example of why this matters is PHP. PHP in quantal is 5.4, but
is 5.3 in precise. Its likely that charms installing PHP will have to
vary slightly based on some details. But if we just let people develop
on the LTS without encouraging them to push changes forward to quantal,
to "R", and beyond, etc., then we will have a massive debt built up when
the next LTS arrives, as PHP 5.3 dependent apps will have to be tested
and ported forward to 5.4.