#964 Download page for Fedora CoreOS
Opened a year ago by bgilbert. Modified 11 months ago

With Fedora CoreOS entering preview within the next month or two, we'll need a download page on getfedora.org, and that page will need several unusual elements:

  • All release image URLs, cloud image IDs, etc., will come from stream metadata JSON documents which are fetched client-side and rendered into the page. That metadata will be hosted alongside the artifacts, and will change at least every two weeks.
  • We'll need to link to release images for three different streams: stable, testing, and next. We'll need language explaining the difference (similar to this), and a recommendation to run a small percentage of nodes on testing and next and report problems to our issue tracker.
  • Each OS platform will have a separate release image. There will be an initial set of platforms, and more will be added over time:
    • Bare metal and virtualized images (e.g. QEMU, VMware) will have downloadable artifacts, with corresponding hashes and GPG signatures. Hashes will come from stream metadata; detached signatures will be a separate artifact.
    • Cloud images will have image identifiers (e.g. AMI IDs on AWS) and corresponding instructions (such as a launch button or sample command line) for running the image.
  • Preferably, we'd include a recommendation to subscribe to the coreos-status mailing list, to ensure we have a way to send operational notifications to our users.

The above is a lot of requirements, I know. It might be too much to fit on one page, even with most of the content shown conditionally; I'd like some input there. CoreOS Container Linux addressed a similar problem by having distinct pages for each platform, which was a maintenance nightmare and probably too complex. I'm happy to work with folks to arrive at something implementable.

As to timing: this doesn't need to be ready for the preview release in the next month or two, but it would help. (If that's infeasible, the Fedora CoreOS team will need to put together a temporary page elsewhere with substantially the items listed above.) The page must be ready before Fedora CoreOS goes stable, which will be ~6 months after the preview release.

Thanks!


Websites team -- this is high importance and falls under the "new editions success" priority I've been talking about with Jim and Leigh. Thanks!

@bgilbert hey I had a draft logo for Fedora CoreOS a while back that I did for bbread but I think it may have been updated / modified by the Brand team - do you know about this or know how I can get the latest / official / approved Fedora CoreOS logo?

This is not something that CPE will be progressing. We don't have the resources due to other in flight commitments and websites is not part of our Mission Statement or future. The recent getfedora updates left an extensible system which can be utilised here.

I'll see what I can do to possibly find OSPO resources, or maybe @pfrields can help outside of the CPE team.

@duffy The latest I have is attached, from the end of September. It's possible that the logo has changed since then, but if so I'm not aware of it.

fedora_coreos-wordmark-horiz-color_paths.svg

These are some mockups I worked on based on the new getfedora.org design. The only thing kind of funky here is the filters for viewing only stable / testing / next releases... I don't know if they are necessary or not; it's mocked up to show the 'view all streams' view.

baremetal.png

cloudlaunch.png

cloudop.png

drawing.svg

@bgilbert does the above design look reasonable?

@duffy Apologies for the slow reply. These look great! I'm not sure whether the filters are necessary either; I'd be inclined to try them out and see how they feel.

A couple minor difficulties on the cloud launch page:

  • There are currently 16 AWS regions. If we list each one as though it were a full cloud, AWS will overwhelm the other cloud options. Can we limit the impact of AWS on that page? Is a region selector a good idea?
  • For certain clouds, such as DigitalOcean and Packet, we know what OS version we want the cloud to provide (and can reflect that on the "for cloud operators" page) but there's no guarantee that they're actually shipping that version. (On Packet, at least, the OS version can also vary by region.) I'm not sure of the right approach there: should we list aspirational version numbers? Should we omit OS versions entirely for the affected clouds?

Thanks!

Login to comment on this ticket.

Metadata
Attachments 5
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment
Attached a year ago View Comment