maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 22 April 2014 01:06, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> wrote:
> Super quick reply while skimming inbox 1500:
>
>  Tuesday 15 Apr 2014 13:44:44 Gavin Panella wrote:
>> > 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.
>>
>> I'm in favour of option 1, but Tycho's point about being able to run
>> maas-import-pxe-files manually makes me think again. I don't mind
>> keeping it, but it ought to move into /var/lib/maas if we do, and we
>> make no promises about preserving manual edits.
>
> I don't care a fig about running mipf manually.  Let's hook it in to the
> database and rely on maas-cli for cmd line access.

No, but Tycho does care a fig, and he's speaking for the community cloud
installer. It needs to be able to run m-i-p-f and know that it has
finished. There's no good way to do that right now via the API. We
should add it, but in the meantime it would be sensible to preserve
invocation from the command-line. Also, for better or worse, m-i-p-f
forms part of MAAS's API, in a broad sense of the term.

>
> It will need some thought, of course, of how to overcome the cumbersome
> reference to a cluster every time you use maas-cli, unless we default to
> kicking all clusters at the same time.  Better hope the proxy works ;)

We can add an API method on nodegroups to do all.

>
>> As for writing it, I suggest we send the sources list to the m-i-p-f
>> job, and it can write out a new bootresources.yaml file just before
>> running m-i-p-f.
>
> *eaaaurrghh*
>
>> Also, we ought to rename m-i-pxe-f to, say, maas-import-boot-resources.
>
> Let's just get rid of it.  We don't need it at all, now that the code is all a
> python module.