Ticket #164 (closed defect: fixed)

Opened 13 years ago

Last modified 10 years ago

installer should know about apt-release clusterinfo

Reported by: broder Owned by: amb
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

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.

Change History

comment:1 Changed 13 years ago by 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.

comment:2 Changed 12 years ago by jdreed

  • Milestone set to The Distant Future

comment:3 follow-up: ↓ 4 Changed 11 years ago by amb

  • Owner set to amb
  • Status changed from new to assigned

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

comment:4 in reply to: ↑ 3 Changed 11 years ago by amb

  • Status changed from assigned to committed

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

comment:5 Changed 11 years ago by amb

  • Status changed from committed to assigned

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.)

comment:6 Changed 10 years ago by amb

  • Status changed from assigned to proposed

Multi-clusterinfo machines fixed in r25222.

comment:7 Changed 10 years ago by 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)

comment:8 Changed 10 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.