maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

Ok finally found some time to reply in more detail!

On 15/04/14 02:01, Graham Binns wrote:
> - The `sources` section is the meat of the file. ISTM that we can easily
>   turn what lives in this section into a Django model so that we can
>   have this configuration managed through the web UI and stored in the
>   database.

I'd like if we could dive into this some more and come up with a schema
suggestion.  Given the multiple arrays we either cheat with json fields
or introduce many-to-many mappings.

> Keeping bootresources.yaml around
> ---------------------------------
> 
> We have a couple of options for how to do away with editing
> bootresources.yaml. We can:
> 
> 1. Get rid of the file altogether; maas-import-pxe-files would either
>    given explicit configuration when run by celery, or would request it
>    from the region on startup.
> 2. Keep the file – it's useful for being able to re-run
>    maas-import-pxe-files manually should the need arise, and have it
>    updated by a celery job or using the RPC mesh.
> 
> I favour option 2, but I'm open to suggestions.

(1) please.  We need to be driving the entire import via the API only,
where all the settings come from the DB.

> Configuration UI
> ----------------
> 
> The configuration UI for this should be fairly straightforward. The only
> real question is whether we pre-populate the form with a set of useable
> options or give a more generic form that gives users more chance to
> shoot themselves in the foot by getting things wrong.
> 
> I've attached two mockups:
> 
> 1. Form pre-filled with useable options.
> 2. Generic form that requires more knowledge.
> 
> Obviously we don't want to give people more potential foot-guns than
> necessary (though I don't think this one is by any means
> unrecoverable-from).
> 
> If we did go with option #1, we have a further problem: pre-populating
> the UI.
> 
> This is a bit of a chicken-and-egg. We already populate some UI elements
> (node architecture and power type fields) based on what a cluster knows
> it can support, but that requires the cluster to have downloaded stuff
> from simplestreams first (in the case of the architectures, anyway).
> 
> So how do we know what we can ask a cluster to download before the
> cluster downloads anything?
> 
> My first thought is that the region controller could introspect
> simplestreams somehow to find out what's availble, but that means that
> we'd have to do it on the fly every time someone puts a new
> simplestreams source into the form, which is impractical.

We could use sstreams-mirror to keep a copy of the index somewhere and
read it when presenting the form, perhaps.

I like the idea of #1 more than #2 to be honest, but it is a bit
trickier.  Also I'd use drop-downs everywhere (replace the checkboxes
for Architectures and Sub-architectures) and turn it into a table,
otherwise adding multiple entries will be tedious.

Another reason to use some sort of default setting is because Mark wants
to import everything by default.

> Any other thoughts on this are welcome, but for a first iteration I
> think that option #2 – simpler form with an accepted higher risk of user
> error – is fine.

As a first pass I think it's OK too.  We can iterate over it to improve
it in the future.  I'd still like it if we could make it more tabular
though to make entering multiple entries at once possible without
loading a page for each.

> We can also make reporting problems due to user error
> less critical by having well-thought-out error messages (e.g. "You
> configured the cluster to download images for the following
> architectures: AlphaAXP, NASA-AGC; only the following architectures are
> available from this source: amd64, i386.")
> 
> We could add an API to give maas-import-pxe-files a way to register such
> errors with the region.

If we use RPC there's no need for the usual API.  Furthermore, it may be
even a reasonable idea to put the import process inside pserv and
Twistify it.

> Finally, we need a listing page for the sources for a particular
> cluster. That's relatively easy to do, and in the case of the generic
> form above, could even benefit from some slick in-line UI to make things
> even easier to use.

Combine the two, yes, that's kind of what I imagined.  Who wants to do
all the JS for that? :)

J