juju deploy ignores model default-series

[Roger Peppe]

When deploying a non-multi-series charm, the juju deploy command
will take the default series from the charmstore, not from the
model default-series as specified and documented in the code.

For example, when the default series is set to "precise", it
should not deploy to trusty unless there's no "precise" version
of the charm, but that's what it does:

    % juju set-environment 'default-series=precise'
    % juju deploy wordpress
    Added charm "cs:trusty/wordpress-4" to the environment.
    Deploying charm "cs:trusty/wordpress-4" with the charm series "trusty".
    %

To fix this, I think the deploy logic needs to call Resolve twice
for non-multi-series charms - first to work out that there
is a charm that can be resolved to and that it's not multi-series;
secondly to work out if the charm URL can be resolved with
the default series (if not, then it can fall back to the first result).

[Cheryl Jennings (cherylj)]

I've also seen that it ignores specifying the series on the command line:

$ juju deploy trusty/ubuntu
Added charm "cs:ubuntu-0" to the model.
Deploying charm "cs:ubuntu-0" with the default charm metadata series "xenial".

[Nate Finch (natefinch)]

Per a discussion with william, for a multiseries charm that supports precise and xenial (for example):

juju deploy precise/foo --series xenial

will deploy without requiring --force. The user should trust that juju will always warn them if they try to deploy a charm to a series it doesn't support, and this will not warn them, because juju knows it's a multiseries charm, and therefore it should deploy just fine.

If the multiseries charm does not support the target series, or it's not a multiseries charm, this will fail without --force, since as far as juju knows, it's not supposed to work.

If you juju deploy precise/foo and foo is a multiseries charm that prefers xenial, we'll still deploy to precise, since that's pretty obviously what the user intended (and if they didn't, they can use --series as above).

[Nate Finch (natefinch)]

PR here: https://github.com/juju/juju/pull/5372

There were actually multiple bugs with the logic, in some of the edge cases, and the tests were incomplete... I reworked the logic to be a lot easier to follow (IMO), and slightly reworked the tests and added a few more.

[Andres Toomsalu (andres-active)]

Im on MAAS 2.0.0~rc4+bzr5187-0ubuntu1~xenial1 and juju 2.0~beta12-0ubuntu1.16.04.1.
Cant access LXD units in their (autocreated by juju) 10.x.x.x network. I guess no proxy is automatically setup (and have found no manual instructions either) - so doing "juju ssh unit" wont work (as it used to be working with 1.25 series and LXC).