maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

Hey Scott, thanks for this useful email.

On Tuesday 11 September 2012 09:29:26 Scott Moser wrote:
> 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.

Agreed.

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

This all seems very reasonable to me.

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

Why the oldest?

>  * Given knowledge of hardware, an api 'start' request could fail as
>    "unsupported release" for a given node.

We also might want to put support in the "acquire" API call to hint that we 
want support for a particular release, otherwise it will get tedious trying to 
find a node that does.

>  * 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".

We can add an optional release picker in the UI easily enough.

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

I'm not sure how we'll model it yet but putting deployment info on the node 
row doesn't seem bad to me (and it avoids a join).

Thanks
J