default-series choice is inconsistent

I'm not sure where distro-info is coming into play when determining what machines should be deployed.

It is supposed to always deploy a machine based on the series of the charm.
So doing "juju deploy mysql" will do a lookup in the charm store (via the API Server) for what series "mysql" should use, and that should return precise/trusty based on what versions of charms are available.

At which point, the juju client finishes its request to deploy exactly either cs:trusty/mysql or cs:precise/mysql.

Now *that* may fail because tools aren't available, or it might be that we then do some other lookup as to whether we even know what that means.

Or perhaps this bug isn't about a charm, but instead only affects the "ensure-state-availability" code since that doesn't actually have a charm that it is deploying.

I certainly *would* expect that juju ensure-state-availability would prefer to deploy more nodes with the same series as the current API servers.

I hope the fix for this issue can be backported to 1.18 for release into trusty. Is this problem averted when default-series is set in the env?

If this is about ensure-availability, it would only affect 1.19 (as that
functionality isn't exposed in 1.18).
Certainly if you had default-series set, it should override any detected
values.

On Thu, Apr 17, 2014 at 4:42 PM, Curtis Hovey <email address hidden> wrote:

> I hope the fix for this issue can be backported to 1.18 for release into
> trusty. Is this problem averted when default-series is set in the env?
>
> ** Changed in: juju-core
> Status: New => Triaged
>
> ** Changed in: juju-core
> Importance: Undecided => High
>
> ** Changed in: juju-core
> Milestone: None => 1.19.1
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https://bugs.launchpad.net/bugs/1308966
>
> Title:
> default-series choice is inconsistent
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1308966/+subscriptions
>

On 17 April 2014 05:12, John A Meinel <email address hidden> wrote:
> I'm not sure where distro-info is coming into play when determining what
> machines should be deployed.
>
> It is supposed to always deploy a machine based on the series of the charm.
> So doing "juju deploy mysql" will do a lookup in the charm store (via the API Server) for what series "mysql" should use, and that should return precise/trusty based on what versions of charms are available.

distro-info is used when we are creating a machine without a charm.
This happens when bootstrapping, when using add-machine
and when using ensure-availability.

> Or perhaps this bug isn't about a charm, but instead only affects the
> "ensure-state-availability" code since that doesn't actually have a
> charm that it is deploying.

Yes. I should have made that clearer.

On 20 April 2014 00:40, John A Meinel <email address hidden> wrote:
> If this is about ensure-availability, it would only affect 1.19 (as that
> functionality isn't exposed in 1.18).
> Certainly if you had default-series set, it should override any detected
> values.

I believe it will affect add-machine too, although I haven't verified that
live.

I split out the ensure-availability portion of this to bug #1308966

bah, that's this bug, I actually meant: bug #1311089

The part of this that was important for ensure-availability has been done. This question remains open.

By my observations, presence of distro-info package is unrelated.

I do:
juju switch ec2vladk
juju bootstrap --upload-tools --constraints "instance-type=t1.micro" --debug
juju deploy ubuntu
juju run --all "sudo apt-get install -y distro-info"
juju add-machine
juju stat

environment: ec2vladk
machines:
  "0": series: trusty (from bootstrap)
  "1": series: trusty (from deploy)
  "2": series: precise (from add-machine)

juju version: 1.19.3-trusty-amd64

There has been a lot of changes in the area, including with --upload-tools being deprecated.
We believe this issue now to be resolved in Juju2.