default-series ignored in environments.yaml

[Christophe Sauthier]

Trying to create a juju charms that aims at deploying on a lucid setup, I have done a configuration usage of default-series: lucid in my environments.yaml, but the produced environnement is always oneiric, according to the ssh session I can do on it.

[Gustavo Niemeyer (niemeyer)]

FWIW, this option should be killed. The right approach is to take the series defined in the charm URI itself in consideration, and deploy it in the respective Ubuntu release.

[Christophe Sauthier (christophe.sauthier)]

Do you have any exemple how to do that ?

[Clint Byrum (clint-fewbar)]

Excerpts from Gustavo Niemeyer's message of Mon Nov 07 15:53:45 UTC 2011:
> FWIW, this option should be killed. The right approach is to take the
> series defined in the charm URI itself in consideration, and deploy it
> in the respective Ubuntu release.
>

I do agree that the charm's series should be what determines the
container/machine series.

However, we must keep the option for use in selecting which series to
use if it is left unspecified on the CLI.

The series of the machine which is doing the deployment is *completely*
irrelevant, especially as we start seeing Juju run on Mac OS or other
distros. So it actually needs to stay as a required option.

We can't require local:oneiric/mysql .. we need local:mysql to work, else
we will break many deployment scripts.

[Gustavo Niemeyer (niemeyer)]

On bootstrap, one must be able to tell what's the default series by saying --default-series. If that's not specified, the series of the current machine is used instead.

We should enable local:mysql indeed, and that will default to the series used to bootstrap the environment too.

[Clint Byrum (clint-fewbar)]

Excerpts from Gustavo Niemeyer's message of Mon Nov 07 17:01:31 UTC 2011:
> On bootstrap, one must be able to tell what's the default series by
> saying --default-series. If that's not specified, the series of the
> current machine is used instead.
>

I can't imagine how the fact that the client is on Ubuntu and on a
release of Ubuntu that has juju support is at all relevant to the
desired deployment.

Given this scenario, if admin A is on 11.04, and admin B is on 11.10,
they may run a full test deploy with bootstrap and get different results.
That seems a bit silly.

This default requires thought. If juju makes anything the default, I'd
suggest the most recent stable release of Ubuntu, and have that maintained
as a static string that is updated whenever Ubuntu is released and some
testing has been done on said release.

[Gustavo Niemeyer (niemeyer)]

Following your same line of thought, it feels even worse that admin A
would be bootstrapping Natty one day and then the same admin A would
be bootstrapping Oneiric on the next day without any kind of change in
his configuration.

[Clint Byrum (clint-fewbar)]

Excerpts from Gustavo Niemeyer's message of Tue Nov 08 10:25:17 UTC 2011:
> Following your same line of thought, it feels even worse that admin A
> would be bootstrapping Natty one day and then the same admin A would
> be bootstrapping Oneiric on the next day without any kind of change in
> his configuration.
>

Changing the juju version I'm running does come with an expectation for
a change in juju, while changing the OS, I wouldn't expect something
like that to change. The OS I'm running is completely irrelevant to the
OS I want to deploy, whereas the version of juju will actually be tied
in some way to the charm store and the charm store releases.

Tied to the OS seems like a path of great surprise, while tied to the
version of juju would seem like the path of least surprise.

[Gustavo Niemeyer (niemeyer)]

You won't necessarily have to upgrade juju to deploy charms on a new release when it
comes out. It works like that today because it's only partially implemented.

Then, if you find that the current _Ubuntu_ version isn't relevant for knowing the
deployed _Ubuntu_ version, it surprises me you think the _juju_ version in use
can freely decide the _Ubuntu_ version deployed.

Feels like we're going down a rabbit hole here.

[Clint Byrum (clint-fewbar)]

Excerpts from Gustavo Niemeyer's message of Tue Nov 08 16:35:09 UTC 2011:
> You won't necessarily have to upgrade juju to deploy charms on a new release when it
> comes out. It works like that today because it's only partially implemented.
>
> Then, if you find that the current _Ubuntu_ version isn't relevant for knowing the
> deployed _Ubuntu_ version, it surprises me you think the _juju_ version in use
> can freely decide the _Ubuntu_ version deployed.
>

A default is just an informed decision, a cultivated experience for
those who aren't sure what decision to make.

In that context, I find the juju developers' intentions to be a more
relevant source of information than the user's chosen platform for their
laptop/desktop/test server.

This is purely philosophical, and so is probably inappropriate to discuss
further in a bug report. I'd rather see this bug fixed than see things
work 100% the way I think they should work.

[Gustavo Niemeyer (niemeyer)]

The reasonable choices for bootstrapping an environment are either:

a) The last LTS
b) The Ubuntu running the juju command

After that, every other command should default to the series that
originally bootstrapped the environment.

[Kapil Thangavelu (hazmat)]

while the conversation has diverged in interesting ways from the the original bug report. its good to note that it was fixed per bug:914392

also per #12 an additional reasonable choice is c) constraints passed to bootstrap.

[Gustavo Niemeyer (niemeyer)]

Option (c) Is not a choice for the *default* behavior of "juju bootstrap". Must be either (a) or (b), and it sounds like Clint is happier with (a).

If --default-series is provided to bootstrap, it should indeed be used for further commands, though.