The "init" repo has a systemd unit with lines that should be kept in
sync with upstream. Normally changes are not expected but in case there
are some, it may be good to be aware.
this is required to keep "packet" in the SDK linguo while the user can
use "equinix_metal" term.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
Co-authored-by: Krzesimir Nowak <knowak@microsoft.com>
The container performs multi-queue optimizations for ssd and network devices
which requires touching /proc and /sys/ mounts which systemd-nspawn usually
mounts readonly. Allow the container to modify those by setting the appropriate
environment variable (found via https://systemd.io/ENVIRONMENT/).
and add missing dependencies on dev-python/distro and sys-apps/coreutils. We
need to bump the version to 20190124 because:
* 20180611 is not compatible with python 3.9 because of missing distro module and
trying to access os.errno (instead of importing the errno module). Also why we
need the dependency on dev-python/distro
* 20190124 is the last version before the repo was split and reorganized which
would require more work to the ebuilds
The coreutils dependency is necessary because the scripts call basename/nproc/cat
but previously coreutils was pulled in by the following dependency chain:
(dependency required by "app-admin/eselect-1.4.16::portage-stable" [binary])
(dependency required by "app-eselect/eselect-python-20160516::portage-stable" [binary])
(dependency required by "dev-lang/python-2.7.15::portage-stable" [binary])
(dependency required by "dev-python/boto-2.48.0::portage-stable" [binary])
(dependency required by "app-emulation/google-compute-engine-20180611::coreos" [binary])
(dependency required by "coreos-base/coreos-oem-gce-0.0.1-r5::coreos" [binary])
(dependency required by "coreos-base/coreos-oem-gce" [argument])
This chain seems to not hold any longer and we should be explicit about
dependencies.
The oem-aci profile previously removed python3 from the produced oem
images by having an entry saying dev-lang/python-3.X is provided and
removing all python3 files. This only worked as long as python2 was
available and installed instead, but since python2 was removed from the
tree these entries in the profile resulted in oem-aci having no python
at all. This prevents the oem-gce service from working, since a lot of
what it does is python.
Remove the INSTALL_MASK and package.provided entries for python3 to
allow python3 into oem-aci images.
This package is needed by the current version of google-compute-engine that we
ship but the dependency has been missing. We haven't noticed because the
package has actually been broken since python2 was dropped from the tree.
distro is needed to replace some functionality removed from the python standard
library around python 3.7.
Upstream commit 7f74353b350b409329b5bb37aea3c05fbb8cb00d
This enables support for the Intel Running Average Power Limit (RAPL)
technology via MSR interface, which allows power limits to be enforced
and monitored on modern Intel processors.
It can be useful for energy consumption monitoring tools.
src: https://github.com/torvalds/linux/blob/master/drivers/powercap/Kconfig
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
GCP Pro is failing because hostname is > 63 char:
```
Apr 5 19:52:27.522820 kubelet[1762]: E0405 19:52:27.522513 1762 kubelet_node_status.go:93] "Unable to register node with API server" err="Node \"jenkins-gce-pro-5-91a967ef5450cb932bc5.c.flatcar-212911.internal\" is invalid: metadata.labels: Invalid value: \"jenkins-gce-pro-5-91a967ef5450cb932bc5.c.flatcar-212911.internal\": must be no more than 63 characters" node="jenkins-gce-pro-5-91a967ef5450cb932bc5.c.flatcar-212911.internal"
```
Let's remove `jenkins` and `gce` from the hostname, these
information are not critical for debugging purposes.
Hostname should now looks like
"basic-5-91a967ef5450cb932bc5.c.flatcar-212911.internal" or
"pro-5-91a967ef5450cb932bc5.c.flatcar-212911.internal"
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
This pulls in
https://github.com/flatcar-linux/init/pull/66
to fix the problem that Ignition keys would be lost as soon as
update-ssh-keys runs. This is done by placing Ignition's keys in as
files in the authorized_keys.d folder and calling update-ssh-keys after
Ignition ran.
Usually last two versions are supported, so make sure we keep them
both updated, not only just the latest. But try to also update the
newest unsupported version in case there was a window where the update
happened and then new major version was released.
When an action generates a couple of patches separately, then it might
be a good idea to specify a numbering, so applying the patches is done
in the desired order. Without that, all the generated patches would
start with "0001-" prefix.
The pipeline created two tags if an SDK was built, one for the SDK and
one for the OS build (which was a free-standing tag or a local state
that was equivalent to the existing tag of the same name). The
nightlies created update commits on the main branch, even if no change
was done, and on the release branches we lacked these commits.
Create the release tag in the nightly SDK bootstrap already and reuse
it for the nightly OS build. Instead of local state, checkout the
existing tags explicitly. Extend the nightly update commit logic to
cover release branches and detect if we can skip building because no
changes were done.
