maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 14 May 2014 08:37, Raphaël Badin <raphael.badin@xxxxxxxxxxxxx> wrote:
> [...]
>
>> 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.
>
>
> Yes, the only reason why we have a separate scanning job that runs after the
> import job runs is because we initially chose to re-use the existing (Shell)
> import script.
>
> Now that the import script is a part of MAAS (i.e. properly unit-tested
> Python code), there is no need to do go through: Import script → files →
> scanning → MAAS API to report images; we can have the import script report
> things directly to the API.  I think the code simplification will be
> significant and it will open the door for things like download progress
> reports.
>
>
>> 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?
>
>
> This sounds good to me.
>
> My first instinct was to look for an easy way out: I figured that maybe we
> could change the import script to create symlinks for all the supported
> architectures.  But, for the reasons mentioned above, I think your plan to
> fold the importing and the reporting into step is a better one: it's a big
> simplification and it opens up new possibilities to improve the user
> experience.

Do we do complex joins against the BootImages table? If not, we could
remove it from the region's database and instead ask the clusters for
that information. The clusters are the database by virtue of having
the files and the simplestreams index; BootImages is a cache, with the
same problems as other caches.