Scott Moser reported that we are currently evaluating the architecture
at the time we create the initramfs script, not when we run the initramfs
script, which was the intent.
Cleanup: be more specific about what should be created.
This puts more information in the config files on what output is expected.
Previously we were relying on the input type format in some cases to
determine what output to create.
The desire to do this was really to safely add '--no-gzip'
to the maas-cloudimg2eph2 if we were going to throw away the root-image.gz.
The gzip of root-image.gz would typically take > 2 minutes and then
the output would be promptly thrown away.
Now, in the configs we have:
meph-v2.yaml:
squashfs: False
root_image: True
enable_di: True
There is one inconsitency there that we've addressed with an 'if release'
section in the code. meph-v3.yaml will build a root image for trusty.
Also added here is information about 'known_callers' and the start of
a shell test suite. At very least it allowed me to manually verify the
output of a before and after run.
Ideally we'd have tests that assert files created and contents look good.
CentOS uses a mirrorlist system which works by downloading a list of mirrors
and using an algorithm in yum to determine the fastest. The build system lp:maas-images runs on only has white listed Internet access. Disable using
mirrorlist during build and consistently use mirrors.centos.org so we don't
have to keep updating the whitelist.
Recent versions of Curtin have full internal support for CentOS. If storage
information is included in the Curtin config the internal hooks are used,
otherwise the in image hooksare used if available. MAAS credentials, which are
used by cloud-init to finalize deployment, are sent by MAAS in the Curtin
config in both the cloudconfig and debconf_selections sections.
LP:1791189 prevents finalize from writing 90_datasource.cfg if Curtin has
internal support for CentOS as the credentials are already included in the
cloudconfig. This works when using the internal Curtin hooks or old versions of
Curtin that do not support CentOS at all. When a new version of Curtin is used
and no storage information is sent the in-image hooks are run for backwards
compatibility. bff4eaa introduced a bug which caused cloudconfig data written
by the internal hooks to be stored in the wrong location. This fixes that
location so they are always written to the correct location and credentials are
accessible in all scenarios. finalize is only needed for MAAS 1.9 as it does
not ship cloudconfig.
To publish this fix CentOS 7 has been locked to the latest CentOS image from
upstream.
kpack-from-image: show less confusing error-like messages.
A normal run of kpack-from-image will have the following output on stderr:
dpkg-query: no path found matching pattern /boot/vmlinux
verflav is 4.18.0-11-generic
ls: cannot access '/boot/vmlinux-4.18.0-11-generic*signed':
No such file or directory
When examining error logs, both the 'dpkg-query' and 'ls:' output look
like errors but they are not.
The changes here silence both those errors and give better messages.
Add 2018-09-17 archive signing key to local keyring.gpg
maas images needs to validate signatures from trusty and later.
For that reason, we can't just use and assume that package provided
/usr/share/keyrings/ubuntu-archive-keyring.gpg
as current versions (disco) will not include the signing key for trusty
(2012-05-11), and older versions do not include the most recent
signing key (2018-09-17).
Because we want to be able to verify data of archive content back
to trusty, we just maintain our own keyring here.
Support building a specific revision of CentOS with a specific release.
revision and release may now be defined in centos.yaml. When revision is
defined only upstream builds with a matching revision will be built. A
release may also be specified to allow revisions to be rebuilt.
Scan for CentOS images using the image-index provided by upstream
When CentOS support was initially added, we decided that CentOS should
follow the same path as Ubuntu. Upstream generates a generic cloud-image
and then lp:maas-images modifies the image to work for MAAS. When this was
first implemented upstream only supplied a sha256sum.txt file[1] for us to
scan for new images. Now, upstream is providing an
image-index [2] file which uses config file format.
The image-index[2] file is missing some older images the sha256sum.txt[1]
has but both contain the latest image file.
