maas-devel team mailing list archive

[Graham Binns <graham.binns@xxxxxxxxxxxxx>]

Hi all,

Julian's asked me to take charge of the work to rid us of the need to
edit bootresources.yaml on the cluster controllers (or indeed get rid of
the file altogether).

Here are my initial thoughts; I'd appreciate your feedback so that we
can get cracking. All questions, comments and thoughts welcome.

bootresources.yaml
------------------

1. bootresources.yaml's contents can be reasonably easily held in the
   database.  A standard bootresources.yaml looks like this:

    boot:
      storage: "/var/lib/maas/boot-resources/"
      sources:
        - path: "http://maas.ubuntu.com/images/ephemeral-v2/daily/";
          keyring: "/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg"
          selections:
            - release: "trusty"
              arches: ["i386", "amd64"]
              subarches: ["generic"]
              labels: ["daily"]

- The `storage` variable can easily be made a default.
- 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.

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.

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.

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

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.

Attachment: Pre-filled add-new-source form 1.png
Description: PNG image

Attachment: Simple add-new-source form.png
Description: PNG image