Setup a native Zuul v3 grenade-base job that defines base folders and
base devstack settings. The grenade play checks out repositories
in two locations, old and new, and sets up devstack config
in old and new as well.
Define a grenade job that sets up devstack services.
This job runs:
- devstack from grenade_from_branch (without tempest)
- grenade from grenade_to_branch
- projects in old from grenade_from_branch
and then tries to run grenade and then tempest.
The configure-grenade-branches role sets the base/target
branch variables (grenade_{from,to}_branch) and must be
updated when cutting a new branch.
Also, define the native versions of the grenade-postgresql
and grenade-multinode jobs, replacing non-native jobs
(like neutron-grenade and neutron-grenade-multinode) when possible.
Even though Python 3 is now the default, define grenade-py3
for compatibility reasons.
Finally, define a basic grenade-forward job which should
be used for forward upgrade testing. Forward testing
requires the user to set the destination branch,
and it is relevant for stable branches only, so disable it
from master.
At least for legacy grenade jobs, Zuul seems to be taking care
of Depends-On on the stable branch.
It is worth noting that tls-proxy is set to False as
it happens with the current legacy jobs. It does not
work by just flipping it to true.
Co-Authored-By: Luigi Toscano <ltoscano@redhat.com>
Depends-On: https://review.opendev.org/637523
Depends-On: https://review.opendev.org/649275
Change-Id: Iefe8d1d7d13bb56cbc9e80fb009d19218f8b1a64
When GRENADE_USE_EXTERNAL_DEVSTACK is set to True,
the initial steps performed by grenade are skipped, namely:
- grabbing and configuring the base and the target devstacks;
- running devstacks on the base target.
This change is required to allow a native Zuul v3 job to use
the existing workflow to setup and run devstack.
Change-Id: I232db8de05141849c81851dd29440959cb0d8533
Every time I have to figure out where in the sequence
of upgrade events the per-release within-$base and
from-$base scripts run, I have to dig into the doc.
We have a pretty good document already on the sequence
of phases in a grenade run, but the upgrade section is
pretty fuzzy, and with no mention of when the per-release
scripts run relative to when new code is installed, which
is pretty important if you're going to write one of these
scripts.
So this adds some docs related to when those per-release
upgrade scripts happen relative to installing new code
during the upgrade.
Change-Id: Ic79cd10b2df5fa54a13f73cf49c8f73fa93e9381
This makes the resource verify commands take a second argument that
indicates if we are pre-upgrade or post-upgrade. This may be needed
in order to validate things that will not be true before, but must
be true after an upgrade.
Change-Id: I6383c5f641bb8eb7fee6f1fbd41bca3a281d9636
For projects that need to setup custom networking we need an
early_create phase that has only gotten the base neutron network setup
which they can then work with and make changes as appropriate.
Create this new hook point, and move the neutron create to this early
phase.
Change-Id: Ifb1903f8d3cb11bc4db33f8acdea342e6373f864
Add some documentation when using a plugin and devstack-gate.
Information about the GRENADE_PLUGINRC environment variable.
Change-Id: I688ba69435a40fb7dc11844e0780e0d1dcd10db5
This commit adds basic docs building support to grenade. Previously
we just had rst files in the root of the repo and relied on github
or something else to render them. After this commit we'll support
sphinx built docs.
The next step after this is to add a docs publishing job to infra so
we'll have hosted grenade documentation like other projects.
Change-Id: I505c1d5e250d103b6e0f9da008f44d3ce28df94f
Implement an external plugin mechanism for grenade in the spirit of
devstack plugins. This assumes that external plugins will live in the
devstack/upgrade tree in their respective repository.
External plugins are enabled by adding
enable_grenade_plugin <name> <giturl> [branch]
to ``pluginrc`` at the top of the grenade directory. (``localrc``
could not be used due to timing issues on parsing)
a new ``devstack_localrc <base|target> ...`` is also added to grenade
that allows settings files to add content to base and target devstack
localrcs. This is quite critical for out of tree support, because for
upgrade testing there will often be a need to add services to the
localrc.
Partially tested on the existing Heat plugin implemented in
I0847004a8ac023a113cabaee46896abc823a01da, though that doesn't yet
fully pass due to conflicts in it's upgrade process.
Include documentation for out of tree best practices.
Change-Id: I02a777077d40408766204b05ed284fe98efbce8e
This should bring the PLUGINS.rst document up to date with the current
implementation in the code. There are still things to design and say
about external from tree support, as well as the 'settings' file,
however this covers the resources.sh.
Change-Id: Id7e2e7db4f5160d9019d76717db356518bfb5931