During a process of building BMC image, CentOS 7 gets certificate
error.
It needs to be updated, before the process continues.
Change-Id: Id90883fbcc9410040fa7c7889b555ccc8da6db1c
This change allows the BMC to install and run on centos9-stream.
centos-8 is skipped to reduce the required support matrix, centos-7
support can be removed once known OVB tooling is upgraded.
Then, pre-built image support can be restored, and also feature work
can be resumed in a modern python3 environment (such as implementing a
redfish endpoint).
Change-Id: I81565726f18d11c906ed23295d8acf5e18a9c2fe
This makes the following changes to simplify the install of pyghmi and
its dependencies:
- Bootstrap installing tripleo-repo by curling delorean.repo instead
of a wget tree search to find the tripleo-repo rpm
- Install pyghmi from rpm, it has been packaged for years and
installing by pip was intended to be temporary
- Do not install unused jq, git, pip
Change-Id: I43206770283cf9a8a6cc7ac2e71f7800238e1690
This change removes the pre-built image support and explicitly
installs for centos-7 base images. There are likely no pre-built image
deployments in the wild, they all appear to use a base centos-7 image
(this includes the bmc-template image used in RDO CI).
This change is the first in a series to upgrade the BMC host to CentOS
versions 8 and 9-stream.
Change-Id: I136b16528b722a6d38235ffcd571f3591d29e679
The openstackcli is super slow at scale (e.g. many nodes) so this change
inlines a python script ot leverage openstacksdk to query the network
and port information to writeout the bmc service files and os-net-config
configuration files.
Change-Id: I1e3d8934071cde12a6be7f1212eb6a85aa2eeafd
The output format when using --format value has changed
with the recent version of openstacksdk. To fix this use
--format json instead and parse the json output using
jq
This is to workaround this bug(?) in openstacksdk.
https://storyboard.openstack.org/#!/story/2006659
Change-Id: Ie196ce1144eea76b8cb081c4cfe434c157510ae9
Replaces --centos-mirror with --mirror as we are going to remove
the old parameter completely. Deprecation was made a very long time ago.
Change-Id: Ieb2a2fb1b9fe5927d97409c0b626033c548fd92e
Master deployments have been failing for me for a long time now.
Since rocky still works, I'm inclined to believe it's not a problem
with OVB.
Change-Id: I2f0f7867e6306e568a587e25ced21ca0cdf096ae
When the pep8 check that environments are up to date was added it
added a mandatory output_path parameter. This wasn't intentional
as it should have still defaulted to 'environments' and it broke the
genconfig tox target.
This change correctly makes the parameter optional so both the pep8
check and genconfig will work as expected.
Change-Id: I2e80956f3c433d2f09966364a7d53cf56114ea21
Instead of having Heat fire-and-forget the bmc deployment, have the
bmc explicitly signal back to Heat. This way bmc failures can be
caught at env deployment time instead of the first time the
undercloud tries to make an IPMI call.
This allows the path-specific registry entries to be static and
doesn't impose any requirements on where the environment containing
parameters lives. The documentation is also updated, which required
a newer version of sphinx to allow automatic references to headings.
Previously the network templates were always pulled from github, but
that means changes involving the templates can't be tested easily.
This change copies the local version of the network templates to
the undercloud so they will be used for the deployment.
The env* name scheme was mildly annoying for tab completion because
it required four characters to be typed before the intended command
was disambiguated. This rename drops that to three characters, which
I find much more usable. It's also more consistent with the naming
of the other scripts.
This was some copy-pasta from my more general deployment process.
In OVB test jobs we always use the default CIDR so there's only one
set of addresses we need to no_proxy.
Ironic is removing the pxe_ipmitool driver shortly, and the ipmi
driver should work fine today. Explicitly start using it so we
don't break when the deprecated one goes away.
After an upstream release, there is a period of time where the RDO
release of TripleO has not yet happened, and as a result the
rdo-release.rpm repo will not contain TripleO packages. This breaks
the BMC because it relies on os-net-config. Using the tripleo-repos
package to set up the RDO repos avoids this problem.
Previously if a user had a shell character like ` in, for instance,
a password, it would cause the install_openstackbmc.sh script to
fail because bash would attempt to expand such characters. Quoting
the delimiter tells bash not to expand anything in the heredoc and
just use it verbatim. This is what we want.
This is just a simple helper script that restarts the undercloud and
bmc instances for a given environment. I shut down my local cloud
when it isn't going to be used for a while, so when I bring it back
up I have to restart all the existing instances. This saves a little
bit of typing.
Ideally we would be testing directly against the TripleO commands
themselves instead of the wrapper script. This change removes most
use of the wrapper script, with the exception of the ping test.
This is added as a completely separate script so that we can keep
testing the previous style of deployment too. The new script uses
the option environments for configuring the OVB stack instead of a
monolithic env file. It also tests network isolation since that is
more common and provides more test coverage of things like the
overcloud network templates too.
Big changes here. This will make it easier to deploy some of the
more advanced OVB options like network-isolation. Instead of users
having to figure out which lines in the sample env.yaml to uncomment
when deploying advanced options, they will simply be able to include
one environment file that contains all the appropriate parameters
to turn on the option.
This _should_ be backwards compatible with existing monolithic
env.yaml configurations. If it is not, that is a bug.
To create the option environments, a slightly modified copy of the
sample environment generator from tripleo-heat-templates has been
copied into the project. The sample environments should _not_ be
edited directly. Instead, the definition in the sample-env-generator
directory should be altered and the tool re-run to update the
environment.
It turns out to be a giant PITA to do keystone v3 auth by hand, as
the bmc install script was trying to. Different clouds require a
different combination of auth values set, and os-client-config
already exists to handle these variations.
To do this, the os-client-config data is passed directly into the
bmc install script as json, which is then written to clouds.yaml
so it can be used by the clients. In theory this should mean that
the bmc can handle any cloud where we were able to deploy the heat
stack because it's using the exact same auth data.
In addition, this change makes os-client-config mandatory on the bmc
image. This is not a meaningful change though because it was already
pulled in by the clients, so it should already exist on any bmc
images in the wild.
It also deprecates the old method of providing auth data to the bmc.
For the moment it should continue to work, but the os-client-config
method should be used going forward. Note that by default the bmc
will now read auth parameters from the environment, which is
actually an improvement over how it worked before when running
interactively.
Even the new and improved ssh opts are not handling all of the
possible ways ssh'ing to the undercloud can fail, so let's just add
a retry loop that ensure it's responding before trying to do
anything else with it.
os-client-config can handle a lot of the complexity around this that
was previously in auth.py (and the auth.py version was not entirely
correct, so it didn't work in every case). This reduces the amount
of code that has to live in OVB considerably and should be more
robust.
The one place we continue to support directly creating clients is
in openstackbmc because there may be existing images out there that
don't have os-client-config installed and I don't want to break them.
However, that path is now deprecated and may be removed at some
point in the future. The preferred method there is still to use
os-client-config.
Ghanshyam Mann