maas-devel team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

In current MAAS, there is is no way to specify what release (12.04, 12.10
... 14.04) of Ubuntu should be deployed.  Ubuntu release is relevant for
the following reasons:
 A. A node is deployed with a planned purpose, and that purpose likely has
    OS restrictions due to available package versions or driver support.
 B. the commissioning and ephemeral environments are essentially a
    specific case of 'A' above, but as these are 'admin' rather than 'user'
    and a higher emphasis is likely placed on consistency and reliability.
    Simply put a admin is likely to want these consistent changing as
    infrequently as possible.
 C. a given release may not support or reliably boot/detect the hardware
    in a given node.

As a result of the above, I think that the cases of "deployment" and
"ephemeral / commissioning" are unrelated.

Also, consider that upon hardware inventory collection ('lshw' output) the
list of releases that can be installed onto a node can be considered
derived information.  Further along that path, the admin could actually
then define is actually "Policies" such has "newest supported" or
"supported LTS".

== Proposed short term solution ==
 A. There needs to be global MAAS settings for:
    * 'default_ephemeral' release: to be used for ephemeral/commissioning
    * 'default_start' release: to be used if no release variable is
    * provided to 'start' api call.
 B. Each node has attributes for both 'default_ephemeral' and 'start'.  If
    these are set to non NULL, then they'll be used where appropriate.  If
    set to NULL, they default to values from 'A'.
 C. The 'start' api should accept a release parameter where the api user
    can specify the release that should be installed.  If there not
    provided, it should default to values in 'B'.  Specifying 'release'
    here should not permanently change a setting from 'B'.
 D. ephemeral and commissioning tasks could have similar input to C.

== Proposed long term solution / Thoughts ==
 * "Discovery environment" (currently this is 'enlistment') could have a
   default to be "newest release", assuming that the newest release would
   always have the best hardware support.
 * Commissioning and Ephemeral tasks could query hardware database select
   the oldest release that fully supports the hardware (or make other
   informed decisions based on data collected during discovery/enlistment).
 * Given knowledge of hardware, an api 'start' request could fail as
   "unsupported release" for a given node.
 * The value of 'release' as specified in 'start' is a value of the
   instance, not of the node.
 * default_start as an attribute of 'node' can go away entirely.

== Considerations ==
 * deployment via web UI: In the short term, selection of release would
   only be possible by changing the nodes 'default_start' and then
   deploying it.  'Null' should somehow be  referenced here, to indicate
   "use global default".
 * deployment via api: api 'start' accepts a 'release' input. This does
   not change the default for this node.
 * There is currently no separation in the database between a node and a
   particular deployment of that node [1].  This means that there is no
   place in the database to store deployment specific information such as
   "release" other than the node itself.

== Links ==
 * bug 944325: no separation of instance-id from node-id
   [1] http://pad.lv/944325
 * maas api
   [2] http://people.canonical.com/~gavin/docs/lp%3Amaas/api.html