maas-devel team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 22/05/14 16:16, Gavin Panella wrote:
> 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. 

It has to decide what to download. If it downloads "everything" then the
"config" can be hardcoded - it's everything that we, Canonical, publish
for this purpose. That way one MAAS region is the same as the next MAAS
region. They have all the bits we publish.

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

U... you are adding a lot of complexity - and configurability - for
this? Seems like you could have a much simpler outcome that just focuses
on a single version / architecture then lets the rest go on in the
background.

> 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 :)

So you want us to do a lot of design and implementation then hide it
away? PLEASE STOP.

> To summarise: - We need configuration to drive the import script.

No we don't. We need to stop, think carefully, and come up with a
simpler approach that does not invite:

 * bastard complex stupid config ("I want the arm-hf and my own custom
hackery over there please"). Our goal is to deliver Ubuntu, CentOS,
Windows, period. The rest are custom uploads.
 * unnecessary code
 * design work that gets hidden away

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

The certification team can use a custom image for testing purposes but
remember they WILL NOT CERTIFY anything that requires something special,
so you don't really have to argue for hackery on their behalf, they are
just normal Ubuntu users. There is a requirement to be able to use
pre-production versions of Ubuntu kernels, yes, but that's a specific
use case.

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

Thank you, but hiding the complexity from users is not the same as
eliminating complexity. Think more carefully about this please, you're
just moving the complexity, not addressing it directly.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature