maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 22 May 2014 14:17, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:
> On 22/05/14 11:05, Gavin Panella wrote:
>> On 22 May 2014 07:36, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:
>>> Thanks Graham, sounds good.
>>>
>>> On 21/05/14 13:33, Graham Binns wrote:
>>>>  - Jeroen is working on paring back the structure of bootresources.yaml
>>>>    to its bare necessities. This is useful when someone needs to run the
>>>>    maas-import-pxe-files script manually, as you'll still need to pass
>>>>    it a config file. The new structure will reflect the structure of the DB
>>>>    models.
>>> Would command-line arguments not suffice for a one-time run?
>> I think there's a little too much structure in there to make a good
>> transition over to command-line args.
>
> Can you be more specific please? The tone of our conversation in Austin
> was that we'd fetch pretty much everything and be done, not a lot of
> need for filters / variants. I'd rather remove the complexity altogether
> than hide it behind a GUI.

On the maas-import-pxe-files side (i.e. the import script), it needs
that config to drive it. It doesn't know what to do otherwise. That
config has a nested structure which would be awkward at best to
translate to the command-line.

On the region side, MAAS will generate that config with everything in it
by default, as agreed, and pass it over to the import script to run on
the cluster.

However, we need a way to narrow that selection down for development; it
takes too long to download the ~400MB per arch+subarch per release,
especially when trying to iterate. For amd64, i386, arm, and power,
that's 1.6GB (7.2GB on disk once uncompressed) before even considering
different subarchitectures. That's not cool for someone on DSL, even
with caching.

The certification team also wants to be able to narrow down the
selection of boot resources. They'll also need to be able to use custom
resources. I imagine this is true for the Hardware Enablement team too.

The UI was mocked-up before Austin, but has not been implemented. We
need to talk to the UX team about it; my guess is that they might
recommend putting it behind a developer-only flag, or leaving it as
API-only, but that's an engineer's guess :)

To summarise:

- We need configuration to drive the import script. The region therefore
  has ultimate control over what is imported; there are no defaults
  baked into the cluster.

- We *could* change the import script to know more, and thus run without
  configuration. However, we want to get rid of the script as a directly
  runnable entity, so this would be short-lived work.

- We need a way to narrow down the boot resources we import for the sake
  of developers, both core and casual, and for the certification team.

- We already do not recommend that regular users run
  maas-import-pxe-files directly; they should use the UI or the API.
  That there is no good feedback on success/failure/progress for this is
  a problem we're working on this cycle.