[Maas-devel] Forward compatibility of subarches (was Re: Problems with the hwe work)

[Raphaël Badin]

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