This allows users to create tags (or properties in the case of OpenStack)
on instances using string interpolation values. The use case is to be
able to add information about the tenant* which requested the instance
to cloud-provider tags.
* Note that ultimately Nodepool may not end up using a given node for
the request which originally prompted its creation, so care should be
taken when using information like this. The documentation notes that.
This feature uses a new configuration attribute on the provider-label
rather than the existing "tags" or "instance-properties" because existing
values may not be safe for use as Python format strings (e.g., an
existing value might be a JSON blob). This could be solved with YAML
tags (like !unsafe) but the most sensible default for that would be to
assume format strings and use a YAML tag to disable formatting, which
doesn't help with our backwards-compatibility problem. Additionally,
Nodepool configuration does not use YAML anchors (yet), so this would
be a significant change that might affect people's use of external tools
on the config file.
Testing this was beyond the ability of the AWS test framework as written,
so some redesign for how we handle patching boto-related methods is
included. The new approach is simpler, more readable, and flexible
in that it can better accomodate future changes.
Change-Id: I5f1befa6e2f2625431523d8d94685f79426b6ae5
For drivers that support tagging/metadata (openstack, aws, azure),
Add or enhance support for supplying tags for uploaded diskimages.
This allows users to set metadata on the global diskimage object
which will then be used as default values for metadata on the
provider diskimage values. The resulting merged dictionary forms
the basis of metadata to be associated with the uploaded image.
The changes needed to reconcile this for the three drivers mentioned
above are:
All: the diskimages[].meta key is added to supply the default values
for provider metadata.
OpenStack: provider diskimage metadata is already supported using
providers[].diskimages[].meta, so no further changes are needed.
AWS, Azure: provider diskimage tags are added using the key
providers[].diskimages[].tags since these providers already use
the "tags" nomenclature for instances.
This results in the somewhat incongruous situation where we have
diskimage "metadata" being combined with provider "tags", but it's
either that or have images with "metadata" while we have instances
with "tags", both of which are "tags" in EC2. The chosen approach
has consistency within the driver.
Change-Id: I30aadadf022af3aa97772011cda8dbae0113a3d8
The default zookeeper session timout is 10 seconds which is not enough
on a highly loaded nodepool. Like in zuul make this configurable so we
can avoid session losses.
Change-Id: Id7087141174c84c6cdcbb3933c233f5fa0e7d569
Require TLS Zookeeper connections before making the 4.0 release.
Change-Id: I69acdcec0deddfdd191f094f13627ec1618142af
Depends-On: https://review.opendev.org/776696
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 config option, available under each provider pool section, can
contain static key-value pairs that will be stored in ZooKeeper on
each Node znode. This will allow us to pass along abitrary data from
nodepool to any user of nodepool (specifically, zuul). Initially, this
will be used to pass along zone information to zuul executors.
Change-Id: I126d37a8c0a4f44dca59c11f76a583b9181ab653
This updates the builder to store individual build logs in dedicated
files, one per build, named for the image and build id. Old logs are
automatically pruned. By default, they are stored in
/var/log/nodepool/builds, but this can be changed.
This removes the need to specially configure logging handler for the
image build logs.
Change-Id: Ia7415d2fbbb320f8eddc4e46c3a055414df5f997
This change is a follow-up to the drivers spec and it makes the fake provider
a real driver. The fakeprovider module is merged into the fake provider and
the get_one_cloud config loader is simplified.
Change-Id: I3f8ae12ea888e7c2a13f246ea5f85d4a809e8c8d
It's possible that it's easier for a nodepool user to just specify a
name or id of a flavor in their config instead of the combo of min-ram
and name-filter.
In order to not have two name related items, and also to not have the
pure flavor-name case use a term called "name-filter" - change
name-filter to flavor-name, and introduce the semantics that if
flavor-name is given by itself, it will look for an exact match on
flavor name or id, and if it's given with min-ram it will behave as
name-filter did already.
Change-Id: I8b98314958d03818ceca5abf4e3b537c8998f248
This was an unused setting which was left over from when we supported
snapshots.
Change-Id: I940eaa57f5dad8761752d767c0dfa80f2a25c787
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Before os-client-config and shade, we would include cloud credentials
in nodepool.yaml. But now comes the time where we can remove these
settings in favor of using a local clouds.yaml file.
Change-Id: Ie7af6dcd56dc48787f280816de939d07800e9d11
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Remove files and fakes related to Jenkins. Since the 'targets'
config section was for mapping to Jenkins, this isn't needed either.
Change-Id: Ib5c615a95fcdce5234b3c63957171d77b8fbc65d
An AZ is chosen at random when selecting a node set for a node request.
If the AZs are not listed within the config, then we cannot guarantee
AZ grouping.
To avoid selecting an AZ that may not match any nodes within our READY
pool (because we ALWAYS want to use READY nodes when they're available),
we use the AZ from the first READY node for the random AZ choice. If we
bypass the READY pool (e.g, min-ready requests), or if the READY pool is
depleted, then we randomly select an AZ from the config.
Change-Id: I97bdda2c4b6952f1cea18f72927ed1e8ccff9787
Sets up a shim for the new nodepool.NodePool.run() method that does
not require any service except ZooKeeper and removes all references
to Gearman/ZMQ.
Change-Id: I452c24d631592f47eb3f4cbffb56f3252f36c298
Script-dir was only used for snapshot building. Since that is no
longer supported, remove it.
It was also passed through to DIB as an evironment variable.
However, the OpenStack infra element that used it defaults to
a sensible value. Users who still want to use that can add it
as an environment variable to appropriate diskimage entries.
Change-Id: Ie72bb9675fdad6364589a6e3823f4ef9a0228e86
Now that we only support DIB for testing, start to simplify our
configuration files for testing. For example, replace fake-dib-image
with fake-image.
Change-Id: Iaf7a7ff714ab2d22f220e497def7c1cb6987c386
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Now we globally assume that the name of an image specified in a
provider is the name of the diskimage that should be uploaded for
it. This removes a layer of indirection which was causing
confusion in the builder (and is not supported by our new zookeeper
data model).
Change-Id: Ic4200693ad49cb05d5f1a52ddb6a41e66dbeb5e5
We don't have plans to support building images from snapshots in the
future. If we add it back, it will require a new builder implementation
(with zookeeper interface, etc) anyway.
In addition to removing essentially dead code, this also begins the
process of simplifying the configuration file. It removes 'base-image'
and 'setup' from the provider image attributes since they are only used
for snapshot images.
Change-Id: I68e0d2c7017cfebe35341189b5aedb0556bcd78b
Instead, move this feature to be an attribute of the diskimages.
A "rebuild-age" is set for each diskimage (defaults to 24 hours),
and when a given diskimage becomes older than this age, the builder
will attempt to rebuild it (regardless of the time of day).
This makes more sense for a system that will retry failed builds
as well as being generally more idempotent, but also means that
when builds and uploads occur will be slightly less predictable.
Change-Id: I4725383158d5baf8fb67e86cb014d2db122e71a0
This is the building block for the structure that nodepool builder will
take going forward. It introduces a new scheduling thread, and moves all
current build and upload worker threads underneath that. A new thread
for receiving ZooKeeper watch events is also introduced.
This code will run, but isn't currently functional because the worker
and watch threads just sleep. Later reviews will begin to add the
functionality.
A supporting developer's guide is added that shows the main components
and communication channels.
Since this is a partial implementation, several tests have to be
temporarily disabled until the ZooKeeper functionality is in place.
Change-Id: I210bb6ba1580403ddc3e5d87eb9bf60ffc7433d8
Depends on a new secure.conf file to grab mysql
connection and jenkins credentials. By this way,
nodepool.yaml is just a flat file without credentials,
that can be passed externally.
Co-Authored-By: Ramy Asselin <ramy.asselin@hpe.com>
Depends-On: Ie9381740e3644feaee1f1b201499e3a253677f39
Change-Id: Ifa4d500c52974b9fd3a0b7fd9c28cf8f52899ca9
We currently branch based on the names of providers, images, etc in
order to test with our fakes. We can get a lot more coverage by
monkeypatching our fakes over the clients they are faking for.
Change-Id: If80eb1f4d914f8b2fbd914311ecda2cf66e7a803
Override tox's pip install command so that prereleases (alphas, betas,
broken things) aren't installed by default. Instead only install release
versions unless a prerelease version is specifically provided. Do this
by overriding the tox install command value.
This fixes doc builds that use `tox -evenv python setup.py
build_sphinx`.
Also, remove the gearman servers from the test configuration (since there
is not yet any support for it).
Change-Id: I31913420adcb48866d3996f2dd3b605c55acce2e
Some misc changes related to running this:
* Set log/stdout/err capture vars as in ZUUL
* Give the main loop a configurable sleep value so tests can run faster
* Fix a confusing typo in the node.yaml config
Additionally, a better method for waiting for test completion is added
which permits us to use assert statements in the tests.
Change-Id: Icddd2afcd816dbd5ab955fa4ab5011ac8def8faf
It starts the daemon with a simple config file and ensures that
it spins up a node.
A timeout is added to the zmq listener so that its run loop can
be stopped by the 'stopped' flag. And the shutdown procedure
for nodepool is altered so that it sets those flags and waits
for those threads to join before proceeding. The previous method
could occasionally cause assertion errors (from C, therefore
core dumps) due to zmq concurrency issues.
Change-Id: I7019a80c9dbf0396c8ddc874a3f4f0c2e977dcfa
James E. Blair