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.
Change-Id: I17e1002012e9ac6abc434454af989f1da1c379b7
Depends-On: https://review.opendev.org/c/zuul/zuul/+/826772
The new cryptography release needs either a recent pip to be able to
use abi3 wheels or a rust compiler on the system to make the source
installation work. Thus upgrade pip to use the wheels.
Change-Id: I4024a89e54de8bbb4e90cbe152a1504e31515fa8
Depends-On: https://review.opendev.org/c/zuul/zuul-jobs/+/775511
For some reason, something changed and fake-image-create no longer
gets installed with execute permissions. Something to do with the
wheel generation and installation ...
Anyway, switch to an editable install which should run directly out of
the checkout. The code already uses relative paths to find
fake-image-create, this should work without further modifications.
Change-Id: Iefbd40ef8f2a2dee84d232de355e369788f0ab2d
This change allows you to specify a dib-cmd parameter for disk images,
which overrides the default call to "disk-image-create". This allows
you to essentially decide the disk-image-create binary to be called
for each disk image configured.
It is inspired by a couple of things:
The "--fake" argument to nodepool-builder has always been a bit of a
wart; a case of testing-only functionality leaking across into the
production code. It would be clearer if the tests used exposed
methods to configure themselves to use the fake builder.
Because disk-image-create is called from the $PATH, it makes it more
difficult to use nodepool from a virtualenv. You can not just run
"nodepool-builder"; you have to ". activate" the virtualenv before
running the daemon so that the path is set to find the virtualenv
disk-image-create.
In addressing activation issues by automatically choosing the
in-virtualenv binary in Ie0e24fa67b948a294aa46f8164b077c8670b4025, it
was pointed out that others are already using wrappers in various ways
where preferring the co-installed virtualenv version would break.
With this, such users can ensure they call the "disk-image-create"
binary they want. We can then make a change to prefer the
co-installed version without fear of breaking.
In theory, there's no reason why a totally separate
"/custom/venv/bin/disk-image-create" would not be valid if you
required a customised dib for some reason for just one image. This is
not currently possible, even modulo PATH hacks, etc., all images will
use the same binary to build. It is for this flexibility I think this
is best at the diskimage level, rather than as, say a global setting
for the whole builder instance.
Thus add a dib-cmd option for diskimages. In the testing case, this
points to the fake-image-create script, and the --fake command-line
option and related bits are removed.
It should have no backwards compatibility effects; documentation and a
release note is added.
Change-Id: I6677e11823df72f8c69973c83039a987b67eb2af
This changes implements a Kubernetes resource provider.
The driver supports namespace request and pod request to enable both
containers as machine and native containers workflow.
Depends-On: https://review.openstack.org/605823
Change-Id: I81b5dc5abe92b71cc98b0d71c8a2863cddff6027