← Back to team overview

maas-devel team mailing list archive

Re: Forward compatibility of subarches (was Re: Problems with the hwe work)

 

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



Follow ups

References