This should only be landed once we've landed the dependency and
confirmed all clouds have the new key value.
This does our semi regular key rotation.
Depends-On: https://review.opendev.org/727865
Change-Id: Ic55c96ad5dd867b70fa52c396e792d5a2e2e0470
These are for testing nodes without pip-and-virtualenv. They have
built correctly and can be used.
Change-Id: I1d7a78dc6bf2b225098195b22974ebe2a0d9af6d
Focal images were built with [0] and the result looks successful, so
let's start launching them.
[0] https://review.opendev.org/720719
Change-Id: I2b825178df230d13d75e782c60dd247e6d65ac8b
Since all platforms have Python 3, use the new ensure-venv element
from the dependent change to install bindep and os-testr.
Since we are no longer using pip to install anything during the
builder, this drops the dependency on pip-and-virtualenv from
nodepool-base. Avoiding this element is our long-term goal, as it's
modification to system state are problematic in a number of ways. To
maintain the status-quo, the pip-and-virtualenv element is added
explicitly to each build's element list, with a note on it's future.
The current plan for backwards compatability is to replicate the
environment pip-and-virtualenv provides in a base role/job that can be
optionally included. To test this, provide a new node type
"ubuntu-bionic-plain" that will not include the pip-and-virtualenv
element. This is put on just one provider (rax) to minimise impact.
The dependent-change (and a dib release) is required before merge so
the ensure-venv element is available.
Depends-On: https://review.opendev.org/707513
Change-Id: I85438baf5bb31790a56fe5b38327361f0a2398e9
All jobs using Fedora 29 have been removed, we can remove it from
nodepool and thus OpenDev now.
Depends-On: https://review.opendev.org/711969
Change-Id: I75c0713d164c29a47db9a0cdfc43fadb370e81f8
This removes trusty from the repo and thus from OpenDev.
Afterwards the AFS volume mirror.wheel.trustyx64 can be deleted.
Depends-On: https://review.opendev.org/702771
Depends-On: https://review.opendev.org/702818
Change-Id: I3fa4c26b0c8aeacf1af76f9046ea98edb2fcdbd0
The opensuse-150 image is being removed as the 15.0 release is EOL.
Similar to centos the expectation is that users keep up to date with
minor releases. For this we have the opensuse-15 image which should be
used instead.
Depends-On: https://review.opendev.org/#/c/682844/
Change-Id: I8db99f8f2fd4b1b7b9a5e06148ca2dc185ed682b
Flip the min ready values for Xenial and Bionic. This should've been
done when we did the initial transition from Xenial to Bionic but was
missed. We want to have ready nodes for the common up to date ubuntu
platform (Bionic) and don't as many on the previous release (Xenial).
Thank you to zbr for catching this after noticing that linter jobs took
a while to start.
Change-Id: I5e2c4b6a056b50077ab343535a4bbe3bc49a0acf
The main reason why we can do this cleanup now is because there has been a policy
change with openSUSE Leap 15: the minor releases like 15.1 and 15.2 are similarly
backwards compatible like e.g. minor releases in centos 7.x are, as such
we can build an opensuse 15 image in the ci and update all jobs to that
one to have less continuous effort in maintaining the opensuse builds.
Depends-On: https://review.opendev.org/#/c/660137/
Change-Id: I2b1f21fb6e01558c8cee27de116dfc857a1a1c91
This reverts commit 32e63aa0c8d1ac60558b09233d2d791bd4ce1c3a (and
small follow-on fix 0eeb4395d1ccac19dea0d6688d4b5712a370b89c)
The base CentOS node is switched to NetworkManager support
Change-Id: Ic254273afdf0637194b608b781ea9e3ff4bd73a3
This enables NetworkManager control of interfaces on a new centos7-nm
node type. This is intended only for short-term initial testing.
Change-Id: I43318f33d206c28e1f06ac7a8f07c3fb8c8f0626
This should happen at the same time as we switch the zuul scheduler over
to the new zk cluster and after the nodepool builders have populated
image data on the new zk cluster.
This gets us off the old nodepool.o.o server and onto newer HA cluster.
Change-Id: I9cea03f726d4acb21ad5584f8db7a4d15bc556db
We've added gentoo images for building, but no providers currently
have a gentoo image defined. Add them.
Change-Id: I89ee589df468d0eb32952fd3a899b834f823ad39
We have no jobs using these images, we can safely remove them
from nodepool.
Change-Id: I6634317838bce4f5bbffe756d96e7dc4588b46fa
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We are in the process of remove this image from nodepool, and jobs are
now using fedora-28.
Change-Id: I58db5231681ccb033f23c7110050e814266abf2a
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The new keypair object has the updated set of ssh keys. Once the new
object is in the clouds we can consume it for nodes.
Change-Id: I5d71fee91504d88129cc307d4855f83b85c6a2b4
Now that we have properly built a fedora-28 image, allow our cloud
providers to use it.
Change-Id: I3b6a333c0a19d091a2935ca422afc311fe15bc6c
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We no longer have any jobs using debian-jessie, so it is now safe to
remove debian-jessie.
Change-Id: I26d14287f8ef236ba80f24a6a45b0754043968db
Depends-On: https://review.openstack.org/562870
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We are in the process of remove debian-jessie from nodepool, this is
the first step to doing so.
Change-Id: I81a978772efa69424a2c3afdc7ced3e6ed47c847
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Ensure both amd64/arm64 DIBs for nodepool are using the same settings.
Also adds missing label for debien-stretch on nl01.o.o.
Change-Id: Ifc6759637c287754a298576cc5c0409f19ded142
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Stretch is the latest stable debian release. So add debian stretch
nodes to arm64 and amd64 clouds.
Note we're updating to use our internal debian mirrors, which now have
arm64 too.
Depends-On: https://review.openstack.org/557942
Change-Id: Idb88d863b5b13286d791970be396c92eff470a81
We've had fedora-27 nodes online for a while now, plus we've recommend
jobs be moved to fedora-27:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/127945.html
We really only want to keep a single fedora node online, due to how
long the support lifecyle is.
Change-Id: Ie13e68eb3e7a266aa51d883b6d410832565e8f16
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Start the process of removing fedora-26 nodes from nodepool. This
will happen over a series of commits.
Change-Id: I5fac84e9d21817438ba1561e8c609bd856d07985
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
As ubuntu-bionic is the new LTS for ubuntu, start providing images in
nodepool. Something to note, bionic isn't actually released yet.
However our tooling does work and is able to create workable images.
We should hold off to migrating jobs from ubuntu-xenial to
ubuntu-bionic until it is officially released, and we have a migration
plan in place.
Change-Id: If12435969ca37400bfd04abe8470048146be7aa3
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We've landed a fix in nodepool to help reduce the chance of a provider
wedge. Remove max-ready-age, to allow our nodepool fix to handle the
issue.
Change-Id: I02b7112d4fdfb0315ad964924692b0968bdf76b4
Depends-On: https://review.openstack.org/539316
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The launcher calls self.labelImageIsAvailable when calculating the
min-ready values. This doesn't work if the launcher doesn't have
entries for that label.
Move the arm64 min-ready into nl03 (and out of nl01) and add a note on
this behaviour.
[1] https://git.openstack.org/cgit/openstack-infra/nodepool/tree/nodepool/launcher.py#n946
Change-Id: I060af7501a8e1106cea673a99fce332fcda73290
Now that we've been able to build / upload an images, add
configuration and have nodepool boot it.
Change-Id: Ieaaaa8d5f3c65e41964a0eda18072d298cfb15a8
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We can use yaml anchors to help reduce duplicate data in nodepool.yaml
files.
Change-Id: I59b43d87340fc0adf37d251c01a0c3092deb3be7
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Due to how multiple nodepool-launchers work today, it is possible to
have greater then min-ready of a label. To avoid this, nl01.o.o will
now be the only launcher to send min-ready requests to zookeeper.
Ideally, nodepool will be updated to support shared configuration in
the future.
Change-Id: I1cf0253343a80146f538ca5e4c83bde5c0173be3
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The provider is no disabled, remove remaining configuration from
nodepool and grafana.
Change-Id: I61fc4871a407449317efb0d20f44fd62faff1c7a
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Now that we remove pipelines from zuul, there is no reason to keep
trpielo-test-cloud-rh1 configured in nodepool.
Change-Id: I658fda4fd979065f6783331341f0ad8b03664268
Depends-On: https://review.openstack.org/538023/
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Do not approve until ticket 180130-ord-0000697 for
mirror01.dfw.rax.openstack.org is brought to a favorable conclusion.
This reverts commit 21463ce4ffcbccecd11b0f6360355cc694a6a7f1.
Change-Id: I35b8430af4b64d36a00a3d7ab7fa89567602eccb
We're seeing an odd rate limiting behavior on our mirror server in
rax-dfw. Ticket 180130-ord-0000697 has been filed with the provider
to investigate, but while that is underway we'll reduce our
max-servers in that region from 140 to 100 to reduce network
bandwidth consumption on it and relieve the resulting packet loss
and package retrieval slowness/timeouts/errors.
Change-Id: I1ab72262bd2f9f725188a2546f92c7f515c762cc
There is an edge case in nodepool when we can have a full quota
for a provider pool of all READY and UNLOCKED nodes (meaning they
are unused and available), but if the pool thread gets a request
for a node label that it does not have ready, it will pause
request handling, waiting for one of its pre-existing nodes to
free up so it can create a new node with the requested label.
It will never unpause because none of it's available nodes will
ever get used and go away.
Ideally, nodepool would identify this situation and just decline
the request. Unfortunately, it does not yet do that, but we can
alleviate this problem by using max-ready-age to delete any unused
ready nodes after a time period. We start with 1 hour of inactive
time.
Change-Id: Ib751f4e8dddd681807b5de5cc982b3feeeb00f19