GCP: plumb through GCP info to our download page

[dustymabe]

There were a flurry of PRs over the past few weeks to get GCP images created in GCP itself for users to use. Now that we have those we should update the Cloud Launchable tab to include some information about the GCP images.

The entry in the meta.json looks like:

    "gcp": {
        "image": "fedora-coreos-31-20200522-dev-7-gcp-x86-64",
        "project": "fedora-coreos-devel",
        "url": "https://storage.googleapis.com/fedora-coreos-devel-image-uploads/image-import/fedora-coreos-31-20200522-dev-7-gcp-x86-64.tar.gz",
        "family": "fedora-coreos-testing-devel"
    }

We'll want to plumb some of that information through the stream metadata and then display it for the user to use. While I think it is important to include the image name in the downloads web UI we should also note that image families exist and we should encourage the use of them so that the users automatically get new images when they are released.

[zonggen]

Is the URL publicly accessible, I got a "403 Forbidden" when accessing it..

[dustymabe]

Is the URL publicly accessible, I got a "403 Forbidden" when accessing it..

Try again :) - I tweaked some settings.

[zonggen]

This time is a "404 Not Found"..
Used wrong link, checked with latest release and worked without issue

[zonggen]

Might be related but should we consider limiting the number of AWS regions shown since right now AWS is overwhelming other cloud platform (xref: https://pagure.io/fedora-websites/issue/964#comment-578973).

For example, an option will be to hide other regions and add a button to show more regions. But I'm not sure which regions are more popular than others.

[dustymabe]

Might be related but should we consider limiting the number of AWS regions shown since right now AWS is overwhelming other cloud platform (xref: https://pagure.io/fedora-websites/issue/964#comment-578973).

For example, an option will be to hide other regions and add a button to show more regions. But I'm not sure which regions are more popular than others.

Yes please! Options:

• Make the region selectable and show us-east-1 by default.
• Just somehow compact the information into a much smaller table.

Also, can we make the For Cloud Operators page have two columns? Right now it's just a single column that takes up less than half of the horizontal space. I guess it depends on the user's display so maybe we can try for two columns and fall back if the window size below a certain threshold.

[zonggen]

we can try for two columns and fall back if the window size below a certain threshold.

Yes I agree with the idea. Also I'd like to experiment with the options above to see which works better.

[bgilbert]

I really like the idea of collapsing all the AWS regions into a single block with a region-selector dropdown.

@dustymabe, what's your reasoning for exposing the image ID? AWS is special, since users must know an individual image ID in order to launch an instance. On other clouds, I don't feel great about helping users hardcode image IDs in their infrastructure. They can always query the image family themselves if they want to get an ID to hardcode.

Also, is there any value to publishing the GS URL? Isn't it an exact copy of the tar.gz from our artifact bucket, and deleted after image creation is complete?

[dustymabe]

I really like the idea of collapsing all the AWS regions into a single block with a region-selector dropdown.

👍

@dustymabe, what's your reasoning for exposing the image ID? AWS is special, since users must know an individual image ID in order to launch an instance. On other clouds, I don't feel great about helping users hardcode image IDs in their infrastructure. They can always query the image family themselves if they want to get an ID to hardcode.

I definitely think we should highlight and prefer the image family usage, but I would like to also include the image name information, even if we put it behind some clickable popup or otherwise make it less prominent. As you point out users can still get the image name if they want it and I'd prefer to have that information in a logical place where they find all the other information about a release.

This is only my opinion. I'm interested in what others think.

Also, is there any value to publishing the GS URL? Isn't it an exact copy of the tar.gz from our artifact bucket, and deleted after image creation is complete?

It's the same file. It used to be deleted within a day (garbage collection), but @vrutkovs highlighted the fact that OKD (like OCP) doesn't use the images we create directly, but rather the GCS file to then create an image. I've got some conversations going on to try to change this in the future.

So.. we could decide to not publish the GCS file on the website now, and then also stop putting it in the meta.json at all when OKD stops using it directly (assuming that happens).

[bgilbert]

I would like to also include the image name information, even if we put it behind some clickable popup or otherwise make it less prominent. As you point out users can still get the image name if they want it and I'd prefer to have that information in a logical place where they find all the other information about a release.

Makes sense. I think I could live with the idea of burying it under some UI. I'm also interested in others' thoughts.

So.. we could decide to not publish the GCS file on the website now, and then also stop putting it in the meta.json at all when OKD stops using it directly (assuming that happens).

👍 We can always add it to stream metadata later. Removing it is harder.

[dustymabe]

This is done now. Thanks for the hard work @zonggen !