maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On 07/05/14 16:09, Julian Edwards wrote:
> On 07/05/14 15:37, Scott Moser wrote:
> 
>> look at
>> http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.json
>>
>> There you'll see a couple things.
>> a.) Any entry that supports hwe-s also supports hwe-t ('subarches')
>>     That implies that something from
>>     product of com.ubuntu.maas.daily:v2:boot:14.04:i386:hwe-t
>>     is sufficient to support a subarch of hwe-s.
> 
> Gotcha.  That stuff simply isn't getting imported into MAAS at the
> moment, I'll have to ponder a model change to capture this data.

This is an interesting problem because there's no easy way at this time
to put extra data from simplestreams into the maas database.

To remind you of the current processes that take place:

1. maas-import-pxe-files runs and writes the required images to the file
system
2. A separate job runs inside celery to scan the written images and
report them back to the region controller.

The communication between stage one and stage two is effectively via files.

Now, I remember the separate celery job getting written in the first
place because at the time the import script was a Great Wall-o'Shell™
which didn't lend itself well to maintainable and tested code.  However,
I suspect we don't really need to have that separate scan any more, we
can just report via the API after m-i-p-f knows it has downloaded them.

This would allow us to extend that API to support m-i-p-f also reporting
the list of "subarches" that comes from simplestreams:

   "release": "trusty",
   "version": "14.04",
   "subarch": "hwe-t",
   "label": "daily",
   "arch": "i386",
   "krel": "trusty",
   "subarches": "generic,hwe-p,hwe-q,hwe-r,hwe-s,hwe-t",
   "kflavor": "generic"
  },


So my suggestion to fix this bug becomes:
 1. Throw away the boot image scanner job and move its reporting code
into m-i-p-f
 2. Add a field "supported_subarches" (bikeshed over the name later
please) to BootImage which would store the value coming from "subarches"
as above.
 3. When choosing a boot image, compare the Node's subarch against
"BootImage.supported_subarches" instead of just "BootImage.subarch".

Thoughts?