Icc9adcbfae7a37c335ce4586741cb27d6e0f5c66 pins the openstacksdk
requirement to <0.99, but this fails when we try to use the zuul
checkout of master openstacksdk in the siblings job.
For now, we just need to drop it from the siblings job.
The rbac.authorization.k8s.io/v1beta1 API was deprecated and replaced
with rbac.authorization.k8s.io/v1. Version 1.22.0 of Kuberenetes removes
the deprecated API which means Nodepool needs to stop using it.
According to the docs  version 1.8 and newer support the new APIs.
To address this we update our RBAC client instance to use the non beta
version client and update our version specification in the manifests to
drop the beta version.
Add a release note indicating that K8s 1.8 and newer is now required.
Additionally we unpin minikube in testing to ensure we have test
coverage of this change against newer Kuberentes.
As described in the dependent change, the testing done here is better
done by the quickstart jobs these days. The dependent change has
removed the tox environment this calls in Zuul. This removes the job
definiton and related files from nodepool.
This re-enables the siblings job in nodepool but omits master
openstacksdk which is currently in an incompatible state. This
also fixes the dib gate, which uses this job as the basis for
its functional testing.
The OpenStackSDK project is in the process of making a breaking
API change and has stopped running this job on master. Without
an interest in adjusting Nodepool to match before the release,
it is no longer useful to run this job on this repo. Stop running
it until the sdk project is ready to re-establish co-gating.
We also set a constraint to avoid installing SDK 1.0.0 since we
expect that to include the breaking API change.
Similar to Zuul (I71182e9d3e6e930977a9f983b37743ee3300ec91), the base
images have updated to Bullseye.
This updates various things to get a building Bullseye image.
We have upgrade to 3.9-based images here because OpenDev builds ARM64
wheels for a bullseye+arm64 combo, which we use to speed up the ARM64
cross-build (we do not have any repository of <3.7|3.8>+bullseye ARM64
wheels, so it makes it difficult to use these combos as the
cross-build can take a very long time)
Version 1.23.0 is failing; create_namespace_role gets a 404. It's
unclear whether this is due to the k8s version change
(v1.21.2 -> v1.22.1) or minikube itself (v1.22.0 -> v1.23.0).
Until we learn more, pin to the previously working k8s version to
unblock the rest of Nodepool.
This fixes libffi bindep installation on Ubuntu Focal
The Python 3.6 tox tests are switched back to bionic, as Focal nodes
don't have Python 3.6.
Additionally, we squashed the following change into this to unblock
This test installs devstack and then nodepool on a bionic host (in
contrast to the -containers variant that builds a container from the
Dockerfile and installs/runs that).
Firstly, devstack support for Bionic is going away soon so we have to
update this. We don't really need to test if we run ontop of a plain
Bionic/Focal host. We have tox jobs testing various Python versions
for compatability, so running on here isn't providing any extra
coverage. DIB can't build many things on plain Bionic/Focal due to
updates or incompatabilities in "alien" versions of RPM, Zypper,
debootstrap, etc. The container incorporates fixes as required and is
where anyone is going to put attention if there are build issues;
hence we're not testing anything useful for image building paths.
Finally we also have nodepool-zuul-functional, which brings up Zuul
and nodepool on a plain Bionic host anyway. Per the prior reasons,
that covers basically the same thing this is providing anyway.
openstacksdk is using this on older branches, but is switched to using
the container job in the dependent changes.
(was : Change-Id: I87318e9101b982f3cafcf82439fdcb68767b602b)
We did this in zuul already so drop python 3.5 in nodepool as
well. The py35 job now fails with .
 ERROR: Package 'keystoneauth1' requires a different Python: 3.5.2 not in '>=3.6'
Fedora 30 is old. Fedora 32 is available, lets use it. We use the new
ensure-zookeeper role as Fedora 32 does not have zookeeper packages
Co-Authored-By: Tristan Cacqueray <email@example.com>
We updated python-base and python-builder to include arm64 images in
support of nodepool's arm64 python-builder image. In doing so we have
discovered a number of issues, but the biggest is slowness of building
python packages in an emulated environment.
In order to speed up package builds we consume the OpenDev linaro
cloud arm64 wheel cache. This doesn't have wheels for every package we
need, but for the things that it does have it will speed up our builds.
One of the risks with this setup is that we're relying on wheels built
for openstack on arm64 and those follow openstack's contraints. In order
to mitigate this risk we set pip install's --prefer-binary flag in the
pip.conf. This means that if openstack's constraints lag what is
availale on pypi we should use the existing wheels as long as they are
valid version according to requirements rather than trying to build from
Co-Authored-By: James E. Blair <firstname.lastname@example.org>
Co-Authored-By: Ian Wienand <email@example.com>
We set this for the check and gate pipelines but not release which
made us very surprised and sad.
We made project vars to avoid this problem. This patch uses them.
Now that the underlying images are correctly being built for arm,
we see that several dependencies are missing wheels, and compiling
them under emulation takes a very long time. Until we resolve that,
only build container images for amd64.
When devstack is enabled with TLS support
(If607caf301211181b4f37a2c7012f875de3d285c) the cloud config has a
reference to the CA in /opt/stack/data; thus we need to map it into
the builder/launcher container. We missed this with testing in
Iacc71e9e744249c7ce585ab7131cc9e905d600ff because the image build
failed and thus the container-based job didn't run.
When we tag a release of Nodepool, run the upload-docker-image job, but
tell it to do so in a non-promote mode. This will cause it to
directly upload the images to Docker Hub with the final tags applied.
We want to do this in the release pipeline so that we get images
built with the correct version number based on the git tag.
When run in a pipeline with a tag attribute set, this will use all
three lengths of the version number (3.19.0, 3.19, 3) as tags instead
of the single 'latest' tag which is what is applied in the promote
This temporarily comments out the other release jobs so that we can
manually enqueue the most recent tag and retroactively build and
publish it to Docker Hub. Once this works, we will re-enable those
Apparently we also need to use python3 in this job now. We were
already doing that for Zuul. The default will be switching soon,
and we can remove that var entry then.
So that we can run nodepool-builder in containers on arm
hosts to better build arm images, update our zuul config
to build multi-arch docker images.
We have versioned base images now. Pin to 3.7 (the current default)
so that we're explicit. We can update to 3.8 in a followup if we
Replace our tox-py36 job with tox-py38, extend the list of trove
classifiers for Python versions in package metadata, and replace the
"py35" in the tox.ini envlist with just "py3" so that folks running
`tox` unqualified on their systems will use whatever python3
interpreter they have on hand (odds are it's in our supported range
these days). Also uncap python-daemon so we use a version compatible
with Python >=3.8.
Rather than rely on the implicit docker-image provides/requires
list explicit per-image requirements for related jobs to reduce,
unecessarily serialization in change queues.
This job, in contrast to the siblings job from
I0b8c309fe3284a2824a38d343fca168441f20471, uses released versions of
dependencies inside the containers.
This adds an initial container-based test. We use the "siblings"
containers, which thus makes this job roughly equate to the extant
non-container "-src" jobs that install dependencies from source (a
follow-on If510238c6ab2b8f6570848f76e84383925c73d87 will add jobs
based on released dependencies).
These are tagged as sibling images, and use openstacksdk/dib from Zuul
checkouts. Since we don't want them released to dockerhub, keep the
We are very close to being able to remove our fedora-28 images as this
release is now EOL. Use fedora-29 in the openshift job so that we can
remove fedora-28 without affecting nodepool's testing.
As a follow on to If1434378b325d6115b45e66b3c42c824e083100e, enable
the debug flag for these tests to get DEBUG level output from nodepool
This is particularly helpful for booting tests because the console of
any nodes that fail to boot is dumped at DEBUG level. Otherwise they
disappear without a trace.
These are fairly stable and don't take exceptionally long (compared
to other lengths we endure) now. Since we no longer have clean
check, it's more important to gate on these now.