Migrate to Ignition config spec v3.1 and bump RHCOS#3871
Migrate to Ignition config spec v3.1 and bump RHCOS#3871openshift-merge-robot merged 3 commits intoopenshift:masterfrom
Conversation
openshift-ci-robot
added
the
do-not-merge/work-in-progress
|
/retest |
|
Note: All e2e tests except AWS are expected to fail at this point (and it requires e2e-aws to run in the us-east-1 region) |
|
@travier e2e ran in us-east-2 this time, so no wonder it didn't work. I'm not sure whether they always do that or how one could determine where they'd run. To be on the safe side, can you replicate the AMI to all regions? (or build anew with |
|
I restarted an RHCOS build that will upload to all the US regions. |
|
@travier The pipeline should grant access to the CI account automatically - https://gitlab.cee.redhat.com/coreos/redhat-coreos/-/blob/master/scripts/upload-ami#L13 Looking at your most recent pipeline run, it looks like it should have been successfully granted to the CI account
|
|
/test e2e-aws |
|
|
|
/test e2e-aws |
|
edit: nvm I think when I overrode the payload it was using the wrong ami |
|
@yuqi-zhang there does seem to be a problem though, as bootstrap's API never comes up. Will investigate further next week. |
LorbusChris
force-pushed
the
ign3
branch
2 times, most recently
from
f18c1cd to
b8b500f
Compare
|
/retest |
1 similar comment
|
/retest |
|
/test e2e-aws-upgrade |
|
e2e-aws passed 🎉 |
|
The MCS logs look right, I see the v3 user agent. One thing to keep in mind here is...since we're overriding just the bootimage but not the Which is totally fine - Ignition only runs in the initramfs on the first boot. I can't think of a reason this would break or fail. But, let's just keep it in mind in case we hit anything strange. |
|
Was able to get a full spec 3 cluster from this PR 🎉 |
openshift-ci-robot
added
the
needs-rebase
openshift-ci-robot
removed
the
needs-rebase
|
I think we should get e2e-aws-upi to pass. I don't think retesting is going to do that, it doesn't seem like a flake. We already found out that the CloudFormation templates were broken by this, there is probably something else. I filed #3974 to use as a reference point. One interesting thing here is this ignition-exporter log - there's a whole lot of requests for I'm wondering if the default e2e-aws-upi is entangled with the proxy stuff in openshift/release#10534 - it doesn't look like it should be, but maybe it is. |
|
It seems that the failure in aws-upi is directly related to the fact that workers don't go up - and thus operators like monitoring fails to rollout properly and we get the failure. As noticed in my previous comment, it seems this was already happening prior to this PR but sure it's worth understanding how this could impact that as well @cgwalters |
I don't see |
Right, I missed on that, but I found https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_installer/3626/pull-ci-openshift-installer-master-e2e-aws-upi/1287951297437241344 (related to PR https://prow.ci.openshift.org/pr-history/?org=openshift&repo=installer&pr=3626) Which is another PR showing the very same symptom (also, I'm agreeing it needs investigation anyway :)) |
OK yeah, So I'm back in the "land and iterate on these jobs after" camp: |
|
Filed https://bugzilla.redhat.com/show_bug.cgi?id=1861828 to track this. |
|
/test e2e-aws-fips |
|
/test e2e-aws-upi |
shows that the compute is booting and sending CSR but those are not getting approved. So I think we should be good wrt ignition change in vSphere UPI |
OK, just need someone to |
So it seems like aws upi is also facing the same issue described in #3871 (comment) The nodes are booting but failing to join the cluster due to CSR not getting approved. |
|
Based on those, it seems like the ignition work should be fine. and i will update the BZ https://bugzilla.redhat.com/show_bug.cgi?id=1861828 to reflect our CSR being broken due to oc rebase. /approve /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, cgwalters The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
|
|
|
Adding overrides based on above |
|
@cgwalters: cgwalters unauthorized: /override is restricted to Repo administrators, approvers in top level OWNERS file. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
7 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
@LorbusChris: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
🎉 |
14 participants
The installer now generates spec v3.1 ignition config,
instead of v2.2 (and v2.4 for openstack) as before.
The v3.1 ignition config specification can be found at [1].
A detailed overview of the differences between specs v2 and v3 can be found at [2].
Notable differences are:
Filesystemidentifier on ignition file configs no longer existsOverwritenow defaults tofalse(wastruein spec v2), which is whyit is now set explicitly to keep the same behaviour.
all appendices must be defined in a single config.
and all dropins must be defined in a single config.
This commit:
Also adds downloading of the provider binary to
images/installer/Dockerfile.upi.ciwhich is necessary because the ignition v2/spec3 version from the
community-terraform-providers/terraform-ignition-providerfork is notpresent in the provider registry that is maintained by Hashicorp and can
therefore not be pulled in automatically by terraform.
is not present in the
(latest commit at the time of this writing).
This is a dropin replacement for "encoding/json" that supports zero values of
structs with omittempty annotations when marshaling.
In effect, this will exclude empty pointer struct fields from the
marshaled data instead of inserting nil values into them, which do not
pass openAPI validation on fields that are supposed to contain e.g. strings.
The same library is used by machine-config-operator and ignition itself.
[1] https://github.com/coreos/ignition/blob/master/doc/configuration-v3_1.md
[2] https://github.com/coreos/ignition/blob/master/doc/migrating-configs.md#from-version-230-to-300
Co-authored-by: Vadim Rutkovsky vrutkovs@redhat.com