DNM - RHCOS: devel build of GCP artifacts to test LB handling

[miabbott]

!!! DO NOT MERGE !!!

This is a partial build of RHCOS that just updates the GCP artifact
and oscontainer to test changes to the LB handling.

[miabbott]

/hold

[miabbott]

/test e2e-gcp

[miabbott]

Not sure if partially updating the JSON is going to work, so here goes nothing...

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign sdodson
You can assign the PR to them by writing /assign @sdodson in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[miabbott]

/test e2e-gcp-upgrade

[cgwalters]

I don't think the bootimage matters for this, does it? IOW we only need an updated machine-os-content.

[cgwalters]

(And in fact, without also pointing to an updated machine-os-content here, changing only the bootimage will only test the pivot time, which I don't think matters)

[openshift-ci-robot]

@miabbott: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
ci/prow/e2e-libvirt	3a60595	link	/test e2e-libvirt

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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.

[miabbott]

(And in fact, without also pointing to an updated machine-os-content here, changing only the bootimage will only test the pivot time, which I don't think matters)

I updated the oscontainer section in the JSON. Do I need a full release payload?

[cgwalters]

I updated the oscontainer section in the JSON.

The cluster doesn't use that for anything.

Do I need a full release payload?

Yes; see https://github.com/openshift/machine-config-operator/blob/master/docs/HACKING.md#replacing-machine-os-content-in-a-new-release-image (and above that).

So specifically what I'd do is create that release payload, push it somewhere, and then probably the most convenient is to use cluster-bot test upgrade quay.io/openshift-release-dev/ocp-release:4.4.0-rc.6-x86_64 registry.svc.ci.openshift.org/rhcos-devel/gcp-lb:latest or so (assuming you push to the second place).
/close

[openshift-ci-robot]

@cgwalters: Closed this PR.

In response to this:

I updated the oscontainer section in the JSON.

The cluster doesn't use that for anything.

Do I need a full release payload?

Yes; see https://github.com/openshift/machine-config-operator/blob/master/docs/HACKING.md#replacing-machine-os-content-in-a-new-release-image (and above that).

So specifically what I'd do is create that release payload, push it somewhere, and then probably the most convenient is to use cluster-bot test upgrade quay.io/openshift-release-dev/ocp-release:4.4.0-rc.6-x86_64 registry.svc.ci.openshift.org/rhcos-devel/gcp-lb:latest or so (assuming you push to the second place).
/close

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.

[miabbott]

I updated the oscontainer section in the JSON.

The cluster doesn't use that for anything.

Do I need a full release payload?

Yes; see https://github.com/openshift/machine-config-operator/blob/master/docs/HACKING.md#replacing-machine-os-content-in-a-new-release-image (and above that).

So specifically what I'd do is create that release payload, push it somewhere, and then probably the most convenient is to use cluster-bot test upgrade quay.io/openshift-release-dev/ocp-release:4.4.0-rc.6-x86_64 registry.svc.ci.openshift.org/rhcos-devel/gcp-lb:latest or so (assuming you push to the second place).
/close

Well that sucks.

OK, I'll try a different attempt.

[cgwalters]

Well that sucks.

Ideally the thought here is more like "oh yeah we don't need to mess around with making VM images! We can just push container images" - that should be easier, but actually today for various reasons it's not completely obvious.

I think one thing that would help is a single wrapper command like cosa build && cosa openshift-release --from 4.4 --push quay.io/myuser/myrelease:latest.

[cgwalters]

The other gap here today is that the existing machine-os-content promotion gate AFAIK only tests on AWS. Which is something we'll need to fix eventually. When we move the OS content into a public repo we can easily get the same /test e2e-gcp integration that exists on this repo.

[miabbott]

Ideally the thought here is more like "oh yeah we don't need to mess around with making VM images! We can just push container images" - that should be easier, but actually today for various reasons it's not completely obvious.

Yeah, once I sorted out the oc adm release new command it was a lot easier. 😄

My frustration was self-inflicted because I didn't pay attention to the upgrade path we wanted to execute. I have a new payload already created and cluster-bot is testing it.

Thanks for the pointers @cgwalters!

I think one thing that would help is a single wrapper command like cosa build && cosa openshift-release --push quay.io/myuser/myrelease:latest.

👍