In order to remove the dependency on providing baremetal hosts, the
"agent" string is checked in the CLI command. This fixes the
requirement that it always be after the "create".
(Note that this solution is an improvement, but not perfect, as it can
result in a false positive if "agent" is used elsewhere in the command
line. A more complete solution will come in a later release).
When running the 'agent wait-for install-complete' command, we first
check that bootstrapping is complete (by running the equivalent of
'agent wait-for bootstrap-complete'. However, if this failed because the
bootstrapping timed out, we would report it as an install failure along
with the corresponding debug messages (stating that the problem is with
the cluster operators, and inevitably failing to fetch data about
which).
If the failure occurs during bootstrapping, report it as a bootstrap
error the same as you would get from 'agent wait-for
bootstrap-complete'.
err is always nil at this point, because we check it further up and it
is not overwritten by the variable of the same name that is shadowing it
inside the anonymous function, as was probably intended.
The installer bootstrap destroy command does not locate the
clouds.yaml file containing the credentials when it's present
in the current directory. This commit fixes the issue by ensuring
that prior to destroying the resources, the installer attempts to
look for the OS_CLIENT_CONFIG_FILE env var and if unset looks for
any clouds.yaml file in the current directory.
**Search for DNS private and public zones in the host and service project.
**Attempt to match DNS records between entries from different projects.
**Loop over all of the possible public zones instead of assuming the first that is found
with a matching domain.
** Create Firewall permissions option is removed from the install config. The
terraform vars checks the user permissions in the project to determine if the
user can create firewall rules. If the user does not have permissions to create firewall
rules then the firewall rules are skipped.
Some OpenStack object storages respond with `204 No Content` to list
requests when there are no containers or objects to list. In these
cases, when responding to requests with an `Accept: text/plain` or no
`Accept` header, some object storages omit the `content-type` header in
their status-204 responses.
Now, Gophercloud throws an error when the response does not contain a
`content-type` header.
With this change, we work around the issue by forcing Gophercloud to
request a JSON response from the object storage when listing objects.
When passed an `Accept: application/json` header, the server responds
with `200 Ok` and a `content-type` header in our tests.
This solution gives us a fix that is easily backportable because it
doesn't require any dependency bump.
* Azure: toggle image in machinesets
Hive vendors the installer and uses the asset package to generate
machinesets for scaleup. Because Hive is using the latest code version
but installing multiple previous versions, the machinesets--particularly
the values--need to be backward compatible.
In this particular case, the installer switched from using Azure
managed images to image galleries in 4.12. In 4.12+ Azure machinesets
expect an image referencing an image gallery, while prior to this change
the machinesets looked for a managed image.
This commit updates the machineset code to allow a toggle which will
allow Hive to generate Azure machinesets utilizing managed images,
which should be done with 4.11 and earlier clusters.
This change also future proofs the 4.12+ by switching the machinesets
to use the latest version, rather than tying them to a particular RHCOS
version.
* fixup! hyperv gen support for managed image
When updating the console debug messages, don't wait for the next
refresh. Issue a reload, which will cause the console to be redisplayed
unless the user has already started logging in.
Every place where this occurs:
ctx, _ := o.contextWithTimeout()
Change to:
ctx, cancel := o.contextWithTimeout()
defer cancel()
NOTE:
For the functions instance.NewIBMPI.*Client(, we now use context.Background()
because o.contextWithTimeout() and then cancel() will cause future calls to
these functions to error out with "context canceled."
The NMStateConfig data in agent-config.yaml was not being validated,
it was only checked in the Load() i.e. the data in nmstateconfig.yaml.
This can result in invalid configurations being stored in ignition
and then the install would fail when these configs were validated
by assisted-service.
The change is to do the same checks in Load() and Generate().
In the destroy logic, use wait.ExponentialBackoffWithContext while
deleting and waiting for PowerVS objects to delete. Also consistently
use the process of deleting and then requerying to see if they have
been deleted.
