Add oc ignition convert3
#628
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: cgwalters The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
cgwalters
force-pushed
the
ignition-convert
branch
from
c343ed7
to
6b63fc3
Compare
|
This seems like a good idea to me!! LGTM |
cgwalters
force-pushed
the
ignition-convert
branch
from
6b63fc3
to
a0dca82
Compare
|
OK resolved outstanding comments so far. |
|
I tested if we can add new nodes to the upgraded cluster using the converted Ignition Config by this tool [ Test conditions ]
It failed to add new nodes and the following error is repeated: This issue is caused by missing "X509v3 Subject Alternative Name"(SAN) field in the OpenSSL x509 certificate of https://api-int.share.test:22623/config/worker. The following patch is related to this issue: openshift/installer@b2d424b So this converter tool won't work in Sphere platform. To avoid this issue, the following steps are required:
Or The X.509 certificate for the api-int endpoint should be re-created with the SNA field. If this pr is not the right place to discuss, please correct me. |
|
Hi right, you hit an unrelated issue in 4.5 ➡️ 4.6 upgrades. This is https://bugzilla.redhat.com/show_bug.cgi?id=1886134 for Ignition, and probably warrants an entry in the knowledge base and explicitly tracking a fix. Perhaps that fix could go alongside here in Alternatively we could fix the above bug for Ignition and work around the behavior for a while longer. |
Thank you for informing me. I will follow the bugzilla.
I have a question regarding adding new nodes to the upgraded OCP4.6 cluster by using RHCOS 4.6 boot images directly. There are two ways to achieve the above:
Is there any difference between "Option 1" and "Option 2"? |
|
Looks like the new subcommand is missing a help string: |
| cfg, rpt, err := ignv2.Parse(data) | ||
| fmt.Fprintf(os.Stderr, "%s", rpt.String()) | ||
| if err != nil || rpt.IsFatal() { | ||
| return errors.Errorf("Error parsing spec v2 config: %v\n%v", err, rpt) |
There was a problem hiding this comment.
If a user feeds a v3 config to the command, it returns this same error.
$ jq .ignition.version < ignitionv3.json
"3.1.0"
$ ./oc ignition convert3 --in ignitionv3.json --out ignitionv3a.json
error: Error parsing spec v2 config: unsupported config version
Could we check the incoming config version before trying to parse?
There was a problem hiding this comment.
Could we check the incoming config version before trying to parse?
Not really, to get the version we need to parse... I think you're just asking for a better error message? Makes total sense but I think the fix would probably be in ign-converter.
There was a problem hiding this comment.
Ignition now has config.util.GetConfigVersion(), which should work with 2.x configs also.
No, that's going to cause problems because you're getting the full config and not just the pointer. We don't expose an explicit API to retrieve the pointer config today, see discussions in openshift/enhancements#540 |
The transition to Ignition Spec 3 with 4.6 creates a discontinuity. Some users want to update their bootimages, e.g. for a cluster originally provisioned as 4.4 but upgraded in place to 4.6, it should be possible to directly use RHCOS 4.6 bootimages for new workers. In some cases in fact, this could be required for things like adding a node with newer hardware. The main stumbling block here is the pointer ignition config which is generated by `openshift-install`. Since the idea is `openshift-install` should in theory be disposable after a cluster is provisioned, let's add this to `oc` which admins will need anyways. Vendor and use https://github.com/coreos/ign-converter the same as the MCO uses. xref openshift/enhancements#492 (comment) xref https://bugzilla.redhat.com/show_bug.cgi?id=1884750
cgwalters
force-pushed
the
ignition-convert
branch
from
a0dca82
to
358978d
Compare
Fixed. |
|
@cgwalters: The following tests failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
|
/cc @soltysh |
|
/hold |
openshift-ci-robot
added
the
do-not-merge/hold
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
openshift-ci-robot
removed
the
lifecycle/stale
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
@cgwalters: PR needs rebase. 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. |
openshift-ci
bot
added
the
needs-rebase
|
/remove-lifecycle stale |
openshift-ci
bot
removed
the
lifecycle/stale
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
We are now several releases past this migration so we should probably give up on this one. |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. In 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. |
The transition to Ignition Spec 3 with 4.6 creates a
discontinuity. Some users want to update their bootimages,
e.g. for a cluster originally provisioned as 4.4 but upgraded
in place to 4.6, it should be possible to directly use RHCOS 4.6
bootimages for new workers.
In some cases in fact, this could be required for things like
adding a node with newer hardware.
The main stumbling block here is the pointer ignition config
which is generated by
openshift-install. Since the idea isopenshift-installshould in theory be disposable after a clusteris provisioned, let's add this to
ocwhich admins will need anyways.Vendor and use
https://github.com/coreos/ign-converter
the same as the MCO uses.
xref openshift/enhancements#492 (comment)
xref https://bugzilla.redhat.com/show_bug.cgi?id=1884750