Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gcp: use GCP Image published by RHCOS instead of creating per cluster #3808

Merged

Conversation

abhinavdahiya
Copy link
Contributor

@abhinavdahiya abhinavdahiya commented Jun 25, 2020

pkg/rhcos: allow fetching GCP image and url from metadata

The rhcos.json contains the GCP image project name and resource name.

Based on instance.insert api https://cloud.google.com/compute/docs/reference/rest/v1/instances/insert the source image
for instance can use of the form projects/debian-cloud/global/images/debian-9-stretch-vYYYYMMDD where the image is in debian-cloud
project.

So this updates the rhcos.GCP to return the sourceImage in the form of projects/<project name>/global/images/<image name>

Since we still need to create GCP images in cases like where licenses are provided, we still need to link to GCS bucket with raw image.
So this adds a rhcos.GCPRaw function to return that URL.

machines/gcp: use GCP image when licenses are not required

The machines will use the osImage as is for re-using the RHCOS published images. But for
cases where the licenses are set for platform, the installer will have to create a new GCP image
using the raw image. Therefore set the image for machines when platform.Licenses is provided to <cluster-id>-rhcos-image
to match the name of the image that will be created later on.

gcp: only create new image when licenses are specified

Tf templates are provided with gcp_image_uri which is the location of the raw image, and
gcp_image which is the gcp image sources from one of the master machine objects.

Tf templates always use the gcp_image which is a pre-existing image published by RHCOS, but
in cases like where the Licenses are set for the GCP platform we will create a new image using the uri.

@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 25, 2020
@abhinavdahiya
Copy link
Contributor Author

/test e2e-gcp

@abhinavdahiya
Copy link
Contributor Author

RHCOS images are not yet accessible, see coreos/coreos-assembler#1561

@abhinavdahiya
Copy link
Contributor Author

/test e2e-gcp
/test e2e-azure

@abhinavdahiya
Copy link
Contributor Author

/test e2e-gcp

The rhcos.json contains the GCP image project name and resource name.

Based on instance.insert api https://cloud.google.com/compute/docs/reference/rest/v1/instances/insert the source image
for instance can use of the form `projects/debian-cloud/global/images/debian-9-stretch-vYYYYMMDD` where the image is in `debian-cloud`
project.

So this updates the rhcos.GCP to return the sourceImage in the form of `projects/<project name>/global/images/<image name>`

Since we still need to create GCP images in cases like where licenses are provided, we still need to link to GCS bucket with raw image.
So this adds a rhcos.GCPRaw function to return that URL.
The machines will use the osImage as is for re-using the RHCOS published images. But for
cases where the licenses are set for platform, the installer will have to create a new GCP image
using the raw image. Therefore set the image for machines when platform.Licenses is provided to `<cluster-id>-rhcos-image`
to match the name of the image that will be created later on.
@abhinavdahiya abhinavdahiya changed the title WIP: gcp: only create new image when licenses are specified gcp: use GCP Image published by RHCOS instead of creating per cluster Jul 23, 2020
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 23, 2020
@abhinavdahiya
Copy link
Contributor Author

/test e2e-gcp

@abhinavdahiya
Copy link
Contributor Author

/assign @jstuever

Tf templates are provided with `gcp_image_uri` which is the location of the raw image, and
`gcp_image` which is the gcp image sources from one of the master machine objects.

Tf templates always use the `gcp_image` which is a pre-existing image published by RHCOS, but
in cases like where the Licenses are set for the GCP platform we will create a new image using the uri.
@abhinavdahiya
Copy link
Contributor Author

/test e2e-gcp

@jstuever
Copy link
Contributor

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 23, 2020
@cgwalters
Copy link
Member

I think we are now publishing the RHCOS GCP images with nested virt enabled by default since coreos/coreos-assembler#1477 - hm, well let me double check. But I think we should, so after this there's no reason for the installer to handle licenses at all (and in retrospect...sorry, I guess all that work wasn't necessary, but we have had multiple personality disorder around public images in clouds).

@abhinavdahiya
Copy link
Contributor Author

Personally I would not have added the use existing image support if GCP wasn't changing the API quota to force one image per 10mins...

Also we have licenses support now so take backsies.. ;p

/approve

@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 23, 2020
cgwalters added a commit to cgwalters/coreos-assembler that referenced this pull request Jul 23, 2020
Per comment from a GCP engineer, this is basically saying our
OS supports KVM, which it does.

We're enabling this only in the FCOS pipeline right now but
it makes sense to enable for RHCOS too.

See openshift/installer#3808
@cgwalters
Copy link
Member

coreos/coreos-assembler#1618 so this should be in the next 4.6 build.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@abhinavdahiya
Copy link
Contributor Author

/test e2e-aws

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

3 similar comments
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@abhinavdahiya
Copy link
Contributor Author

/override ci/prow/e2e-aws-upgrade

@openshift-ci-robot
Copy link
Contributor

@abhinavdahiya: Overrode contexts on behalf of abhinavdahiya: ci/prow/e2e-aws-upgrade

In response to this:

/override ci/prow/e2e-aws-upgrade

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-robot
Copy link
Contributor

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

Test name Commit Details Rerun command
ci/prow/e2e-azure b25cced link /test e2e-azure
ci/prow/e2e-crc 1f2d071 link /test e2e-crc
ci/prow/e2e-openstack 1f2d071 link /test e2e-openstack
ci/prow/e2e-aws-scaleup-rhel7 1f2d071 link /test e2e-aws-scaleup-rhel7
ci/prow/e2e-libvirt 1f2d071 link /test e2e-libvirt

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.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit fdc683a into openshift:master Jul 24, 2020
openshift-merge-robot pushed a commit to coreos/coreos-assembler that referenced this pull request Jul 30, 2020
Per comment from a GCP engineer, this is basically saying our
OS supports KVM, which it does.

We're enabling this only in the FCOS pipeline right now but
it makes sense to enable for RHCOS too.

See openshift/installer#3808
enxebre added a commit to enxebre/machine-api-operator that referenced this pull request Aug 3, 2020
This openshift/installer#3808 changed the expectation for the GCP default image. It reuses now published RHCOS images, projects/rhcos-cloud/global/images/*
enxebre added a commit to enxebre/machine-api-operator that referenced this pull request Aug 3, 2020
This openshift/installer#3808 changed the expectation for the GCP default image. It reuses now published RHCOS images, projects/rhcos-cloud/global/images/*
enxebre added a commit to enxebre/machine-api-operator that referenced this pull request Aug 3, 2020
This openshift/installer#3808 changed the expectation for the GCP default image. It reuses now published RHCOS images, projects/rhcos-cloud/global/images/*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants