installer should know about apt-release clusterinfo

[broder]

Soon, hopefully, machines in various Moira clusters around campus will have "production", "proposed", and/or "development" values for the "apt-release" key in clusterinfo.

The Debathena installer script should somehow know about this field, and should use it to frob /etc/apt/sources.list.d/debathena.list appropriately at install time.

This allows us to test how a system handles being installed with the packages in -proposed (or -development).

This one is a little trickier than #163 because we don't have debathena-clusterinfo or debathena-getcluster installed when /etc/apt/sources.list.d/debathena.list is written.

It may be that we want to install debathena-getcluster, find out the clusterinfo, and then re-generate /etc/apt/sources.list.d/debathena.list, but even this seems slightly non-ideal, as for a small period packages will only be pulled from production.

[geofft]

Is there a use case for this other than "This allows us to test how a system handles being installed with the packages in -proposed (or -development)."? auto-update should bring in packages from the other releases soon enough...

It might be more helpful, especially for virtual machines, if the installer could let you manually specify which release you want to install.

[amb]

There's a fix for this checked in which needs a bit of rework; see r24765 and subsequent debate.

[amb]

The requested reworking was done a while ago; this is checked in and tested and awaits deployment.

[amb]

This support doesn't actually work because hesiod contains both apt_release entries on development machines. Unclear if we want hesiod cluster info to have both apt_releases, but the installer should probably cope with it anyway if it does. (This should still be fine on proposed machines, though.)

[amb]

Multi-clusterinfo machines fixed in r25222.

[jdreed]

This was deployed, but see the thread on source-commits about whether we want to go back to "development implies proposed" or what? Arguably, it's Wrong(tm) to have two unversioned cluster tags of the same name (because the second one always wins in getcluster)