maas-devel team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Fri, 14 Sep 2012, Julian Edwards wrote:

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

Or newest. the point was just that it can have a "policy" rather than a
hard coded value.  Personally, I would expect that commissioning and
ephemeral would be used for things that people want to be stable.  So
"oldest supported" seems like what I would choose.  I wouldn't want to
have my commissioning scripts broken every 6 months just because of
'cadence'.

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

Right. I'm not sure how acquire and start will end up being used in the
long run.  Whether I would "own" (acquire) 30 nodes and just sit on them,
or pretty much just acquire, start, release.

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

Andreas wanted this.  It would seem useful.

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

Right, and you at least potentially have a couple order of magnitude more
"instances" than you do nodes.  But please *keep* all those instance
records somewhere.  I want to look at them and be able to determine that:
 * only .5% of instances choose to use 13.04, while 98% use 12.04
 * user 'bob' is the reason that there never are free resources.