Juju shouldn't pick an EOL ubuntu release if a valid one is available

[Andreas Hasenack]

This came up while trying a simple "juju deploy mysql" (and I'm aware of https://discourse.jujucharms.com/t/whats-up-with-mysql/149/6 yes).

The mysql charm in the store currently declares its series support like this:
series:
   - zesty
   - xenial
   - trusty

I was told the "algorithm" of picking a series, when an unqualified deploy command such as "juju deploy <name>" is received, is:
The final charm/machine series is determined using an order of precedence (most
preferred to least):
 - the '--series' command option
 - the series stated in the charm URL
 - for a bundle, the series stated in each charm URL (in the bundle file)
 - for a bundle, the series given at the top level (in the bundle file)
 - the 'default-series' model key
 - the top-most series specified in the charm's metadata file
   (this sets the charm's 'preferred series' in the Charm Store)

May I suggest the last item be augmented with "unless that series is EOL, then the next one is tried". If none are found to be valid (all series are EOL), then juju could fail and ask the user to qualify the series, or issue a warning and pick the top-most one as originally planned, or something else.

The way it is now, "juju deploy mysql" is failing for a silly reason, when it could have picked up "xenial" as a good alternative, which is even an LTS. Furthermore, the mysql deploy failure takes a while to show up, because the charm keeps retrying apt commands against an EOL release, and the user will have to dig into juju logs to find a puzzling "404" error, and figure out ubuntu release and EOL schedules.

[Richard Harding (rharding)]

Thanks for filing this. I can understand the request but I feel like honestly the root here is that the charm failed to be maintained and we should have been more proactive in pulling this down vs trying to sugar coat the series to keep it limping along. That's on us for not pushing to get it pulled sooner.

I'd prefer not to put extra complexity into the process in order to cover that up. I'm marking this as won't fix but I'm happy to get feedback that I'm not thinking fairly about the proposal.

[Andreas Hasenack (ahasenack)]

If you can put a process in place to crawl through all charms and unpromulgate the ones that have an EOL series as the preferred one (top of the list), then sure. TBH, I thought the default was to always pick the latest LTS (if listed in the charm, of course).

[Richard Harding (rharding)]

I think that'd it'd be very good of us to query charms supporting EOL and reaching out to those charm authors. We know who's they are and should be touching base with the charming community like that imo.

If we're going to spend engineering effort I'd rather script that setup and improvement our charming community engagement over adjusting Juju's code to cover it up.

I'll file a bug to that effect on the charmstore itself though tbh I think this is something that we can script outside of it and I'll see if we can get that setup to be done once a cycle as the series update to the next one.

[Dean Henrichsmeyer (dean)]

I do think it's appropriate for Juju to pick the latest LTS if multiple releases are declared as supported. This will avoid this particular issue and seems like a reasonable decision for Juju to make.

[Ryan Beisner (1chb1n)]

I like the approach proposed in comment #4. +1 to that.

[Richard Harding (rharding)]

We do now make sure to now choose EOL'd series and go to the next valid one unless the operator uses force. I'm going to mark this fix committed.