** 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.
These changes will update the RHCOS 4.13 boot image metadata in the
installer which includes the fixes for the following:
OCPBUGS-2926 - Unable to gather OpenStack console logs since kernel cmd line has no console args
OCPBUGS-3361 - RHCOS VM fails to boot on IBM Power (ppc64le) - 4.13
```
plume cosa2stream --target data/data/coreos/rhcos.json --distro rhcos --no-signatures --url https://rhcos.mirror.openshift.com/art/storage/releases x86_64=412.86.202209302317-0 aarch64=412.86.202210031918-0 s390x=412.86.202209302317-0 ppc64le=412.86.202209302326-0
```
Since the apply-host-config service is oneshot, not simple, systemd
doesn't consider it 'started' until it completes. We want the
install-status to show any errors from apply-host-config, so start it
at the same time (i.e. when create-cluster-and-infraenv has finished).
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.
Make the main message specific to the agent installer, and put it inside
motd.d so that it does not get overwritten on the bootstrap node.
Put info about the primary service to watch (assisted-service on node 0;
agent on other hosts) directly in /etc/motd. On node 0, this will be
overwritten to say that bootkube is the primary service once
bootstrapping starts. Writing this data to /etc/motd also has the effect
of overwriting the stuff about using Machine Config Operator to
configure the host, which CoreOS automatically puts in there but which
doesn't make sense until the cluster is booted.
# Background
#5258 introduced a mechanism to tell CVO to not manage some cluster resources,
as that management was creating races between bootkube and CVO.
In #5271, this mechanism was removed from bootstrap-in-place
installations.
The reason for the removal was because attempting to apply
`original_cvo_overrides.patch` after the cluster-bootstrap podman
container was done wasn't working, as in BIP by the time that that
container is down, there's no longer a running kube-apiserver apply the
patch on (unlike regular installations with a bootstrap node where the
API server keeps running on the actual nodes). The justification for
simply disabling the mechanism instead of finding a solution was based
on an incorrect assumption that "CVO doesn't even run in BIP pre-pivot
so there's no need to perform overrides anyway as there's no CVO to race
with".
# Issue
Naturally, since CVO *is* actually running in the pre-pivot phase of
bootstrap-in-place, not applying CVO overrides to disable the CVO
management of bootkube-created resources led to the same races #5258 was
aiming to solve in bootstrap-in-place installations.
One manifestation of that is OCPBUGS-4125.
# Solution
This commit re-introduces the mechanism that was originally introduced in #5258
(and removed in #5271).
To solve the issue that motivated #5271, this commit doesn't attempt to
apply the `original_cvo_overrides.patch` in bootstrap-in-place
pre-reboot, and instead will transfer `original_cvo_overrides.patch` through
`master-update.fcc` to the post-pivot phase and the bootstrap-in-place
post-reboot script will make sure to apply the patch after the API
server is running again.
Since the folder resource might not be ran because there could be
user defined folder per failure domain if a folder is created
the import resource is not waiting. Adding
this depends_on so the import happens after creating
folder(s).
As described in https://issues.redhat.com/browse/OCPBUGS-3277, there have
been occasional failures in the create-cluster-and-infraenv service
due to the agentbasedinstaller being unable to retrieve the release image.
This changes to the service to allow a retry on failure.
In the transition from v2 to v3 of the azurerm terraform provider, not
only was an option renamed from `allow_blob_public_access` to
`allow_nested_items_to_be_public` but its default value was also changed
from `false` to `true` [1].
So to restore the previous access setting for the RHCOS Storage Account,
we need to explicitly set the new option to `false`.
Thanks Jinyun Ma for pointing this out.
[1] https://github.com/hashicorp/terraform-provider-azurerm/blob/main/CHANGELOG.md#300-march-24-2022
Although we should never log the value of a pull-secret, to be on the
safe side redact any of the pull secret auth values that we know about
from the journal before saving it in the agent-gather archive.
The exported journal format is binary[1], so we must ensure that the
redacted output has the same length as the input.
[1] https://systemd.io/JOURNAL_EXPORT_FORMATS/#journal-export-format
