The list of supported distro series is hardcoded in src/maasserver/enum.py

[Raphaël Badin]

We really should use python-distro-info using something like: http://paste.ubuntu.com/6179821/

[Gavin Panella (allenap)]

Using distro_info is a short term solution. We should really be looking at what distros the clusters have boot resources in place to boot and install from. That's the thing that really matters.

[Scott Moser (smoser)]

The attached simple patch creates the DISTRO_SERIES and DISTRO_SERIES_CHOICES variables correctly from distro_info.

That is nice, and I'd even suggest over all better.
However, we do have some things to consider here:
 * does a release immediately become uninstallable on the date it is "unsupported" (ie, does this break users). Do we need to allow some sort of config to allow the users to deploy old releases (if we did, it would be nice if we handled the archive sources.list change to old-releases.ubuntu.com for them).

 * This should be somehow filtered against the list of things that are available in pxe files or ephemeral images for fast path install (maybe that filtering is done elsewhere, i'm not sure).
 * should we make a simple toggle for "allow development release"? distro_info's policy is to show as 'supported' the development release from the moment it is announced. Clearly that is not likely to function, so maybe we dont want it there.

[Gavin Panella (allenap)]

(Scott, I don't know if you were commenting on your patch, or replying
to my comment. This is a reply to your comment on the assumption that
it was the latter, but on re-reading I realise I may have been wrong.)

There may be places where we want to say "I would like/prefer $series"
where $series is not yet available on any cluster, but when allocating
a node, for example, the only thing that matters is what a cluster is
actually capable of doing. Using distro_info just doesn't join up
there. It's like selling people on one brand of car when you only
stock a different brand.

We should only offer people what the clusters are actually capable of
fulfilling. If we want to show "here's what's coming up" or "if you
click this button you get xyz" then the cluster ought to republish the
stream data it's working from, and the region aggregate it.

Also, though there are no plans for it as yet, booting and installing
non-Ubuntu systems would make the use of distro_info only half a
solution.

[Raphaël Badin (rvb)]

@Gavin: I completely agree with the design you're talking about but I think you're missing the point of what *this* bug is about.

Let me explain: we still need the list of all the possible series to:
- use that list in the tests (to pick up a random series).
- have a correspondence between the codenames and the long, human-friendly names that we use in the UI and the API.

Now, I agree that the list of the possible series a node can use to boot should be derived from what the cluster to which that node is related has reported. But that's a different bug. The human-friendly list will be computed like this: take the series the node can really use (as reported by the cluster) and use DISTRO_SERIES_CHOICES to compute the human-friendly list of the full names.

[Gavin Panella (allenap)]

Okay. The two issues are, to me:
- the list is hard-coded,
- the region is the source of that list.

This bug report is directed at the first of those. The second can be the subject of another bug.

[Gavin Panella (allenap)]

I've reported the second as bug 1234716.

[Raphaël Badin (rvb)]

> Okay. The two issues are, to me:
> - the list is hard-coded,
> - the region is the source of that list.

My thoughts, exactly.

> I've reported the second as bug 1234716.

Thanks!

[Julian Edwards (julian-edwards)]

We are close to completing this with the recent work. It just needs to examine the BootImages to determine available releases. The cluster setup process will be responsible for getting the simplestreams index and informing the admin of the potential releases.

[Julian Edwards (julian-edwards)]

Is this fixed now?

[Blake Rouse (blake-rouse)]

This has not been fixed in 1.7 its still using the hardcoded values in the provisioningserver.drivers.osystem.UbuntuOS. Once I am done with the imaging stuff I will work on getting this completed.