MCO-289: OCPBUGS-1324: Teach the MCO to use new format image #3317

jkyros · 2022-08-30T20:53:20Z

This:

Makes the MCO use the native ostree-container rhel-coreos-8/rhel-coreos-8 extensions images by default
Makes the MCO capable of rebasing pre-4.12 nodes to the new image format without an extra reboot, by using rpm-ostree's ex deploy-from-self functionality
- (for cases where what we have would be otherwise "too old" to use the new format)
Instructs the MCO to allow a mismatched OSImageURL to pass the on-disk validation check if the base commit hash still matches
- (to allow for the missing custom origin/imagerefs as a result of how ex deploy-from-self accomplishes its task)

(This PR experienced a lot of change as it progressed, so I'm retaining the original description below for posterity, but it is wrong -- we hit some snags using the extensions container as a service and had to adjust our approach)

This: - Makes the operator apply a service and deployment manifest for the extensions container if we have one - Adds a template for the `rhel-coreos-8-extensions.repo` - Allows the daemon to make "rebootless" changes to /etc/yum.repos.d/* so we don't trigger a reboot with our template - Re-enables kernel switching and extensions for the "layering" path - Tries to gate all of this behind the presence of the extensions container
Caveats:

The node doesn't have access to "pod dns" so it can't find the repo service unless it's told about it

I fixed this for my testing by adding this next to the registry in the node resolver openshift/cluster-dns-operator@71df59c and packing my own node resolver in the payload.

To try this (because we don't have a productized extensions container yet), you can pack your own release:

oc adm release new -a ~/.docker/config.json -n ocp --server https://api.ci.l2s4.p1.openshiftapps.com --from-release registry.ci.openshift.org/ocp/release:4.12 --to-image quay.io/jkyros/ocp-release:v4.12 --include=rhel-coreos-8-extensions rhel-coreos-8-extensions=registry.ci.openshift.org/rhcos-devel/rhel-coreos-extensions:latest machine-config-operator=quay.io/jkyros/machine-config-operator:latest cluster-dns-operator=quay.io/jkyros/cluster-dns-operator:latest

cgwalters

Cool, thanks so much for putting this up! It's looking quite plausible to me; some comments below

cgwalters · 2022-08-30T21:17:25Z

manifests/machineconfigcontroller/extensionsDeployment.yaml

+ restartPolicy: Always
+ securityContext:
+ runAsNonRoot: true
+ runAsUser: 65534


Hm, do we need this one?

cgwalters · 2022-08-30T21:19:21Z

templates/common/_base/files/extensions-yum-repo.yaml

@@ -0,0 +1,11 @@
+{{if .BaseOperatingSystemExtensionsContainer }}
+mode: 0600
+path: "/etc/yum.repos.d/rhel-coreos-8-extensions.repo"


It'd be a bit of a scramble but we could also try to add the long-overdue /run/yum.repos.d. That'd have different tradeoffs.

cgwalters · 2022-08-30T21:23:19Z

templates/common/_base/units/machine-config-daemon-firstboot.service.yaml

@@ -14,7 +14,7 @@ contents: |
 Type=oneshot
 RemainAfterExit=yes
 # Disable existing repos (if any) so that OS extensions would use embedded RPMs only
- ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo"
+ ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo; sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/rhel-coreos-8-extensions.repo"


Hmmmm. I wonder if we really still need this thing at all. We shouldn't have any enabled repos by default, no?

Ahhh I see this came in with 552f6d5 for OKD (FCOS) which does have repos.

Hmm. I'm thinking that if they wanted the repos disabled, they should do this process in their builds, and not here.

As is this line is going to actively fight anyone trying to add repos to RHCOS day 0, which I think is a somewhat reasonable thing to do.

Anyways, OK as is - clearly the tech debt here isn't new to this change.

cgwalters · 2022-08-30T21:24:00Z

pkg/daemon/rpm-ostree.go

@@ -89,6 +89,12 @@ func NewNodeUpdaterClient() NodeUpdaterClient {
 // and gathering stderr into a buffer which will be returned in err
 // in case of error.
 func runRpmOstree(args ...string) error {
+ // TODO(jkyros): update seems to want to check this too, so we probably just need to make sure it's there before we make an rpm-ostree call


Yeah let's move this to func (r *RpmOstreeClient) Initialize() error {

cgwalters · 2022-08-30T21:25:26Z

pkg/controller/render/render_controller.go

@@ -563,7 +563,16 @@ func generateRenderedMachineConfig(pool *mcfgv1.MachineConfigPool, configs []*mc
 }
 }

- merged, err := ctrlcommon.MergeMachineConfigs(configs, cconfig.Spec.OSImageURL)
+ // If our new image formats are populated
+ // TODO(jkyros): "properly" feature gate this? This is kind of a 'soft' gate based on the presence of extensions container,


Ah, OK. That is indeed one way to get it tested in CI.

That said it also has the effect that CI and nightlies will behave differently...so I think I'd vote for a const enableNewImage = false that can be flipped on. Or we just do the more proper feature gating via machineconfig.

cgwalters · 2022-08-30T21:27:01Z

pkg/controller/template/render.go

@@ -294,7 +294,9 @@ func generateMachineConfigForName(config *RenderConfig, role, name, templateDir,
 return nil, fmt.Errorf("error creating MachineConfig from Ignition config: %w", err)
 }
 // And inject the osimageurl here
- mcfg.Spec.OSImageURL = config.OSImageURL
+ // TODO(jkyros): if we're allowing overrides, this makes it hard to figure out of the user overrode it, or if it's just
+ // "passthrough" from here since we don't mark "system" vs "user" machineconfigs.


Yeah. Well...presumably we'll revisit this when we add a CRD or something else.

That said really short term we could introduce hotfixOverrideOSImage into machineconfig or so...did that ever get debated versus allowing htem to set osImageURL?

cgwalters · 2022-09-01T19:08:13Z

It looks like this is getting the new image correctly in e2e-aws:

I0830 21:25:49.217396    2199 daemon.go:1218] State: idle
Deployments:
* ostree-unverified-registry:registry.build02.ci.openshift.org/ci-op-549cm1gq/stable@sha256:278fefd8d944555106730b9f00ab1a3e7954e5bb823246c6f7246edfe408c0fb
                   Digest: sha256:278fefd8d944555106730b9f00ab1a3e7954e5bb823246c6f7246edfe408c0fb
                Timestamp: 2022-08-30T21:25:10Z

  a4cd5482264860d07e6830708ba5952df8ec2596feff273f8ccddf2d4331bdb6
                  Version: 412.86.202208101039-0 (2022-08-10T10:42:36Z)

cgwalters · 2022-09-01T19:46:23Z

The node doesn't have access to "pod dns" so it can't find the repo service unless it's told about it
I fixed this for my testing by adding this next to the registry in the node resolver openshift/cluster-dns-operator@71df59c and packing my own node resolver in the payload.

https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/#manually-constructing-apiserver-proxy-urls - this may require us to do something like inject Authorization: bearer http headers in the .repo files though...not pretty
~~Schedule the extensions container in the host network namespace, use service IP to talk to it. In this path, there's no auth to talk to the service, which is a bit unfortunate but not fatal I'd say~~ (edit: this was wrong)
Schedule the extensions container as a regular pod (as PR currently does), use service IP to talk to it. In this path, there's no auth to talk to the service, which is a bit unfortunate but not fatal I'd say
Change the hack which adds the registry IP to /etc/hosts to also do this service; IMO this is ugly and I'd think of it more like a last resort
Schedule a pod which mirrors the extensions to the host in e.g. /var/lib/machine-config-daemon, and uses baseurl=file:/// in the .repo file.
Run extensions as a daemonset on the host network namespace on all nodes persistently (as long as any extensions are enabled...). Ew, more daemonsets?

Long term...well, we want to cut over to a build controller, in which case we're always on the pod network.

Even a bit longer term, we want to store RPMs as OCI artifacts, in which case we can push them to the registry and we could piggyback on the registry DNS hack!

knobunc · 2022-09-01T20:02:04Z

@cgwalters I'm not sure I understand why option 2 ("Schedule the extensions container in the host network namespace, use service IP to talk to it") needs hostnet. Things running on the host can reach the pods over the SDN. The reason we need to write to /etc/hosts for the registry case is just to have a consistent name for the service that gets created that the container runtime can be configured to use statically.

If you are able to create the service and look up the address it is given, then write that into the repository information, you should be fine.

cgwalters · 2022-09-01T20:05:43Z

Oops yes sorry, I got wires crossed there. Edited the comment, thanks!

jkyros · 2022-09-02T06:19:54Z

oh no, that passed 😄. Alright, well that's promising, we know if we extract the extensions to disk everything seems to work. I'd prefer that the daemon not have to know about the extensions container URL but maybe I'm too picky.

I'll save this, and I'm going to go back and try to get it working the service way then.

LorbusChris · 2022-09-03T13:02:33Z

pkg/daemon/update.go

+ fipsFile = "/proc/sys/crypto/fips_enabled"
+ extensionsRepo = "/etc/yum.repos.d/coreos-extensions.repo"
+ osImageContentBaseDir = "/run/mco-machine-os-content/"
+ osExtensionsContentBaseDir = "/run/mco-rhel-coreos-extensions/"


Suggested change

osExtensionsContentBaseDir = "/run/mco-rhel-coreos-extensions/"

osExtensionsContentBaseDir = "/run/mco-machine-os-extensions/"

Or just mco-extensions...hopefully we can retire the machine-os-content nomenclature to make a clear break from the past.

LorbusChris · 2022-09-03T13:24:28Z

templates/common/_base/units/machine-config-daemon-firstboot.service.yaml

@@ -14,7 +14,7 @@ contents: |
 Type=oneshot
 RemainAfterExit=yes
 # Disable existing repos (if any) so that OS extensions would use embedded RPMs only
- ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo"
+ ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo; sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/rhel-coreos-8-extensions.repo"


Suggested change

ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo; sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/rhel-coreos-8-extensions.repo"

ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo; sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/coreos-extensions.repo"

Removing this requirement might be a bit tricky. In OKD, we boot an FCOS node, and then rebase that to OKD's layered image. The yum repos already exist in the FCOS that is first provisioned, and the rebase won't overwrite file contents in /etc IIUC, so we have to do it here instead.

But do we still need to disable the repo files? Now that OKD is using layering, we're no longer installing packages on each node individually right?

IOW we can just delete this line, correct?

oh right. Looks like it can just be removed then.

cgwalters · 2022-09-07T19:40:55Z

/hold
until https://issues.redhat.com/browse/ART-4750

jkyros · 2022-09-08T07:47:46Z

Added extensions container field to machineconfig, took out "service stuff" since we're extracting to disk. Still needs some cleanup.

sinnykumari · 2022-09-08T13:35:48Z

install/0000_80_machine-config-operator_05_osimageurl.yaml

@@ -12,7 +12,7 @@ data:
 # This (will eventually) replace the below when https://github.com/openshift/enhancements/pull/1032
 # progresses towards the default.
 baseOperatingSystemContainer: "placeholder.url.oc.will.replace.this.org/placeholdernamespace:rhel-coreos-8"
- #baseOperatingSystemExtensionsContainer: "placeholder.url.oc.will.replace.this.org/placeholdernamespace:rhel-coreos-8-extensions"
+ baseOperatingSystemExtensionsContainer: "placeholder.url.oc.will.replace.this.org/placeholdernamespace:rhel-coreos-8-extensions"


nit: maybe we can renamebaseOperatingSystemContainer to baseOSExtensionsContainer and baseOperatingSystemContainer to baseOSContainer . It is also consistent with OSImageURL .

I think as a general rule we should s/container/image/ - because it's relatively standard to have "container" be a running instance.

So perhaps baseOSImage? I don't otherwise have a strong opinion on that vs e.g. baseOperatingSystemImage

Though, it's tricky here because "image" can often mean virtual/physical machine image (AMI/ISO) versus "container image", and while it's usually clear from context, our use of the term image blurs those lines. Sometimes we need to spell it out fully by saying "container image" which is wordy.

yeah, baseOSImage/baseOSContainerImg/baseOSContainerImage would be more technically correct. Will leave it to John whatever he prefers among them :)

I went with baseOSContainerImage, it's still shorter than what we had 😄

sinnykumari · 2022-09-08T14:20:20Z

pkg/daemon/update.go

@@ -325,6 +336,40 @@ func ExtractOSImage(imgURL string) (osImageContentDir string, err error) {
 return
 }

+// ExtractOSImage extracts OS image content in a temporary directory under /run/machine-os-content/


comment need to be updated based on what ExtractOSImage does

sinnykumari · 2022-09-08T14:20:24Z

pkg/daemon/update.go

@@ -238,6 +239,16 @@ func addExtensionsRepo(osImageContentDir string) error {
 return nil
 }

+// addExtensionsRepo adds a repo into /etc/yum.repos.d/ which we use later to


s/addExtensionsRepo/addLayeredExtensionsRepo/

sinnykumari · 2022-09-08T14:23:20Z

pkg/daemon/update.go

+ if _, err = pivotutils.RunExtBackground(cmdRetriesCount, "oc", args...); err != nil {
+ // Workaround fixes for the environment where oc image extract fails.
+ // See https://bugzilla.redhat.com/show_bug.cgi?id=1862979
+ glog.Infof("Falling back to using podman cp to fetch OS image content")


since extensions image is relatively small image, we can skip using oc and use podmanCopy directly too

jkyros · 2022-09-08T16:57:17Z

/test e2e-agnostic-upgrade

sinnykumari · 2022-09-08T19:43:11Z

Since we already have e2e test for various platforms, let's get some better coverage by running on this PR.

/test e2e-aws-upgrade-single-node
/test e2e-gcp-op-single-node
/test e2e-metal-ipi
/test e2e-vsphere
/test e2e-vsphere-upgrade
/test e2e-aws-workers-rhel8
/test e2e-openstack

Once, these looks good we can run payload test

jkyros · 2022-09-09T08:34:56Z

Oh well that sure was fun. In hindsight I feel kind of silly, but upgrade tests were failing for this PR because:

I took the OSImageURL out that we were rendering in the templates to make it obvious when it was overridden
The resourcemerge library merges that field with setStringIfSet (which, as the name says, only merges if the string is set), so you can't blank it out
Since you can't blank it out, it keeps the last populated value, which is the old OSImageURL from the previous controllerconfig
And since this PR allows for overrides it assumes that that previous value is an "override" so it never moves off of it

TL;DR Starting from a fresh cluster everything is okay, but starting from a cluster where the templates have OSImageURL populated, you get stuck there forever.

I'll get the rest of this cleanup done today (Friday).

jkyros · 2022-09-09T17:09:16Z

/test e2e-agnostic-upgrade
/test e2e-aws

jkyros · 2022-09-09T20:28:07Z

/test e2e-aws-upgrade-single-node
/test e2e-aws-workers-rhel8
/test e2e-openstack
/test e2e-vsphere-upgrade
/test e2e-vsphere

jkyros · 2022-09-10T01:38:23Z

/test e2e-aws-upgrade-single-node

sinnykumari · 2022-09-28T14:12:21Z

@rphillips @cgwalters kube 1.25 PR has been merged openshift/kubernetes#1360 , can we merge this PR now?

cgwalters · 2022-09-28T18:14:46Z

/hold cancel
CI should be ready

vrutkovs · 2022-10-01T11:22:26Z

This broke OKD - https://amd64.origin.releases.ci.openshift.org/releasestream/4.12.0-0.okd/release/4.12.0-0.okd-2022-09-30-033411

cgwalters · 2022-10-01T11:49:09Z

Control plane is failing on

Oct 01 09:31:20 ip-10-0-169-247 machine-config-daemon[1046]: W1001 09:31:20.095787    1046 firstboot_complete_machineconfig.go:46] error: failed to update OS to registry.ci.openshift.org/origin/4.12-2022-10-01-062315@sha256:74bf5d6f3f78e8c80f834fe864df612297b6070fe6e8a8ceebb3cc6e25130ba0 : error running rpm-ostree rebase --experimental ostree-unverified-registry:registry.ci.openshift.org/origin/4.12-2022-10-01-062315@sha256:74bf5d6f3f78e8c80f834fe864df612297b6070fe6e8a8ceebb3cc6e25130ba0: error: remote error: getting username and password: 1 error occurred:
Oct 01 09:31:20 ip-10-0-169-247 machine-config-daemon[1046]:         * reading JSON file "/run/ostree/auth.json": open /run/ostree/auth.json: permission denied

This is the same issue as https://issues.redhat.com/browse/OKD-63 - we just don't have the fix on the base FCOS images yet.

We'll spin a new rpm-ostree release soon which should get that sorted. Even shorter term, we could add a quick hack here (conditional on FCOS?) to chmod it?

Sorry about the regression here, but what made this a bit less obvious to catch is that before this PR landed this code path wasn't the default, and now it is.

cgwalters · 2022-10-01T11:58:47Z

Put up #3358

openshift-ci-robot · 2022-10-06T11:45:29Z

@jkyros: All pull requests linked via external trackers have merged:

Jira Issue OCPBUGS-1324 has been moved to the MODIFIED state.

In response to this:

This:

Makes the MCO use the native ostree-container rhel-coreos-8/rhel-coreos-8 extensions images by default

Makes the MCO capable of rebasing pre-4.12 nodes to the new image format without an extra reboot, by using rpm-ostree's ex deploy-from-self functionality

(for cases where what we have would be otherwise "too old" to use the new format)

Instructs the MCO to allow a mismatched OSImageURL to pass the on-disk validation check if the base commit hash still matches

(to allow for the missing custom origin/imagerefs as a result of how ex deploy-from-self accomplishes its task)

(This PR experienced a lot of change as it progressed, so I'm retaining the original description below for posterity, but it is wrong -- we hit some snags using the extensions container as a service and had to adjust our approach)
This: - Makes the operator apply a service and deployment manifest for the extensions container if we have one - Adds a template for the `rhel-coreos-8-extensions.repo` - Allows the daemon to make "rebootless" changes to /etc/yum.repos.d/* so we don't trigger a reboot with our template - Re-enables kernel switching and extensions for the "layering" path - Tries to gate all of this behind the presence of the extensions container
Caveats:

The node doesn't have access to "pod dns" so it can't find the repo service unless it's told about it

I fixed this for my testing by adding this next to the registry in the node resolver openshift/cluster-dns-operator@71df59c and packing my own node resolver in the payload.

To try this (because we don't have a productized extensions container yet), you can pack your own release:

oc adm release new -a ~/.docker/config.json -n ocp --server https://api.ci.l2s4.p1.openshiftapps.com --from-release registry.ci.openshift.org/ocp/release:4.12 --to-image quay.io/jkyros/ocp-release:v4.12 --include=rhel-coreos-8-extensions rhel-coreos-8-extensions=registry.ci.openshift.org/rhcos-devel/rhel-coreos-extensions:latest machine-config-operator=quay.io/jkyros/machine-config-operator:latest cluster-dns-operator=quay.io/jkyros/cluster-dns-operator:latest

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.

sinnykumari · 2022-10-06T11:45:38Z

/bugzilla refresh

sinnykumari · 2022-10-06T11:45:59Z

/jira refresh

openshift-ci-robot · 2022-10-06T11:46:01Z

@sinnykumari: Jira Issue OCPBUGS-1324 is in an unrecognized state (MODIFIED) and will not be moved to the MODIFIED state.

In response to this:

/jira refresh

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.

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info. Signed-off-by: Jose Luis Ojosnegros Manchón <jojosneg@redhat.com>

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 30, 2022

openshift-ci bot requested review from sinnykumari and yuqi-zhang August 30, 2022 20:55

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 30, 2022

cgwalters reviewed Aug 30, 2022

View reviewed changes

jkyros mentioned this pull request Sep 1, 2022

[WIP] Teach MCO to use the new-format image by default #3258

Closed

LorbusChris reviewed Sep 3, 2022

View reviewed changes

cgwalters mentioned this pull request Sep 7, 2022

RHCOS 4.12 s390x - Builds are failling because extension container uses non-s390x build image openshift/os#986

Closed

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 7, 2022

jkyros force-pushed the mco-289-extensions-container branch from cc4ef5e to 01e9a0b Compare September 8, 2022 07:47

sinnykumari reviewed Sep 8, 2022

View reviewed changes

jkyros force-pushed the mco-289-extensions-container branch from 01e9a0b to c3cc527 Compare September 9, 2022 08:34

jkyros force-pushed the mco-289-extensions-container branch from c3cc527 to 1e4917b Compare September 10, 2022 09:09

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 28, 2022

openshift-merge-robot merged commit 3943ef1 into openshift:master Sep 28, 2022

This was referenced Sep 28, 2022

Switch to https://github.com/coreos/rpmostree-client-go #3302

Merged

Kube 1.25 fixes openshift/hypershift#1764

Merged

sinnykumari changed the title ~~MCO-289: Teach the MCO to use new format image~~ MCO-289: OCPBUGS-1324: Teach the MCO to use new format image Oct 6, 2022

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request Apr 17, 2023

vendor: Adapt MergeMachineConfigs to new api

01f28cf

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request Apr 19, 2023

vendor: Adapt MergeMachineConfigs to new api

2ece7df

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request Apr 20, 2023

vendor: Adapt MergeMachineConfigs to new api

016320c

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request Apr 21, 2023

ztp: Adapt MergeMachineConfigs to new api

6666671

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request Apr 21, 2023

ztp: Adapt MergeMachineConfigs to new api

e416f93

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request Apr 26, 2023

ztp: Adapt MergeMachineConfigs to new api

043a14e

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request Apr 26, 2023

ztp: Adapt MergeMachineConfigs to new api

7c47fbe

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request May 3, 2023

ztp: Adapt MergeMachineConfigs to new api

55518a6

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jlojosnegros added a commit to jlojosnegros/cnf-features-deploy that referenced this pull request May 3, 2023

ztp: Adapt MergeMachineConfigs to new api

2056b12

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

pixelsoccupied pushed a commit to pixelsoccupied/cnf-features-deploy that referenced this pull request May 18, 2023

ztp: Adapt MergeMachineConfigs to new api

df71641

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

serngawy pushed a commit to serngawy/cnf-features-deploy that referenced this pull request May 23, 2023

ztp: Adapt MergeMachineConfigs to new api

004f403

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

jgato pushed a commit to jgato/cnf-features-deploy that referenced this pull request May 24, 2023

ztp: Adapt MergeMachineConfigs to new api

9421745

Changes due to MCO adaptation to use new format image. See openshift/machine-config-operator#3317 for more info.

cgwalters mentioned this pull request Jul 25, 2023

MCO-395: daemon: Completely remove imageInspect code #3821

Closed

	osExtensionsContentBaseDir = "/run/mco-rhel-coreos-extensions/"
	osExtensionsContentBaseDir = "/run/mco-machine-os-extensions/"

	ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo; sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/rhel-coreos-8-extensions.repo"
	ExecStartPre=-/usr/bin/sh -c "sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/*.repo; sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/coreos-extensions.repo"

MCO-289: OCPBUGS-1324: Teach the MCO to use new format image #3317

MCO-289: OCPBUGS-1324: Teach the MCO to use new format image #3317

Conversation

jkyros commented Aug 30, 2022 • edited Loading

cgwalters left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cgwalters commented Sep 1, 2022

cgwalters commented Sep 1, 2022 • edited Loading

knobunc commented Sep 1, 2022

cgwalters commented Sep 1, 2022

jkyros commented Sep 2, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cgwalters commented Sep 7, 2022

jkyros commented Sep 8, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkyros commented Sep 8, 2022

sinnykumari commented Sep 8, 2022

jkyros commented Sep 9, 2022

jkyros commented Sep 9, 2022

jkyros commented Sep 9, 2022

jkyros commented Sep 10, 2022

sinnykumari commented Sep 28, 2022

cgwalters commented Sep 28, 2022

vrutkovs commented Oct 1, 2022

cgwalters commented Oct 1, 2022

cgwalters commented Oct 1, 2022

openshift-ci-robot commented Oct 6, 2022

sinnykumari commented Oct 6, 2022

sinnykumari commented Oct 6, 2022

openshift-ci-robot commented Oct 6, 2022

jkyros commented Aug 30, 2022 •

edited

Loading

cgwalters commented Sep 1, 2022 •

edited

Loading

jkyros commented Sep 2, 2022 •

edited

Loading