The inspection functionality is now provided by ironic proper.
Also fixes a few minor quirks in the baremetal config, such as:
- Passing htpasswd variables to BMO (it cannot use them)
- Creating auth-config files (only required for cross-service calls).
** Removed the Example and terraform data in upi/metal
** Updated the docs in docs/user/metal to reflect the changes above. Pointing the user towards the official docs.
The current patch allows the user to specify the content of the install-config networkConfig field directly as a yaml object. Content validation (for a generic yaml) is now carried on by the install config asset
Allow to specify desidered host networking settings yaml
compatible with NMState as a new install-config field.
Validation rule ensures that the string is at least a
valid generic yaml.
This implements part of the plan from:
https://github.com/openshift/os/issues/477
When we originally added the pinned RHCOS metadata `rhcos.json`
to the installer, we also changed the coreos-assembler `meta.json`
format into an arbitrary new format in the name of some cleanups.
In retrospect, this was a big mistake because we now have two
formats.
Then Fedora CoreOS appeared and added streams JSON as a public API.
We decided to unify on streams metadata; there's now a published
Go library for it: https://github.com/coreos/stream-metadata-go
Among other benefits, it is a single file that supports multiple
architectures.
UPI installs should now use stream metadata, particularly
to find public cloud images. This is exposed via a new
`openshift-install coreos print-stream-json` command.
This is an important preparatory step for exposing this via
`oc` as well as having something in the cluster update to
it.
HOWEVER as a (really hopefully temporary) hack, we *duplicate*
the metadata so that IPI installs use the new stream format,
and UPI CI jobs can still use the old format (with different RHCOS versions).
We will port the UPI docs and CI jobs after this merges.
Co-authored-by: Matthew Staebler <staebler@redhat.com>
Uses the new baremetal-operator BootMode value UEFISecureBoot to request
Ironic to automatically configure secure boot during the instance start.
Metal3 design: https://github.com/metal3-io/metal3-docs/pull/161
The ClusterProvisioningIP field in the baremetal platform had an
incorrect JSON annotation for serialization/deserialization, using
"provisioningHostIP" instead of "clusterProvisioningIP." This name is
incorrect and doesn't adequately reflect it's purpose. This field is
the IP used in the cluster for provisioning.
This commit deprecates the old JSON field, and uses the correct JSON
annotation for ClusterProvisioningIP.
If users are unable to define the mac addresses for the bootstrap host,
they won't be able to set static DHCP reservations for the host. Many
corporate environments do not allow unrestricted DHCP.
Co-authored-by: Matthew Staebler <staebler@redhat.com>
This implements the enhancement request that makes the provisioning
network optional. It introduces a new platform configuration called
"provisioningNetwork" that takes 3 possible values: managed, unmanaged,
and disabled. The "unmanaged" option replaces the external DHCP flag
that was previously used.
When the network is set to "disabled," it is expected that users use
virtualmedia configuration. We will deploy no DHCP/TFTP provisioning
services for a user to use.
Give the user a bootMode field for each host so they can control whether
the host should be booted using UEFI or BIOS mode. Pass the value to
Ironic for control plane nodes and include it in the BareMetalHost
resources created for all hosts.
Change the Ironic parameter to use instance_info/deploy_boot_mode instead
of the capabilities, based on feedback from the Ironic team.
Signed-off-by: Doug Hellmann <dhellmann@redhat.com>
Hardware profiles don't allow for all of the use cases
required in some baremetal environments, allow the
root hints associated with them to be overridden.
e.g. to specifiy a device by serial number
- name: openshift-master-0
rootDeviceHints:
serialNumber: 1111
This commit adds a way to know beforehand which virtual router IDs a
baremetal IPI deployment will use in order to know, pre-deployment, if
those happen to conflict with already used virtual router IDs
pre-existent in the network.
The other sections show an example that places the configuration
parameter in the right part of the structure in the YAML document. Add
a similar example for the libvirtURI.
Signed-off-by: Doug Hellmann <dhellmann@redhat.com>
Provide a table describing the basic configuration parameters for IPI
deployments on bare metal. Include examples of BMC address values.
Update the customization docs to include a more verbose description of
all of the parameters, including libvirtURI and the context in which
specifying it is useful.
Signed-off-by: Doug Hellmann <dhellmann@redhat.com>
When starting the static pods on a host, we determine the correct
address to use by comparing its subnet with the VIP subnet. If the
external address assigned by DHCP is in a different subnet from the
VIPs then we can't determine which address to use and deployment
will fail. This change makes the requirement for addresses to be in
the same subnet explicit.
