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

Producing images for the IBM Cloud chimera #1119

Closed
lucab opened this issue Feb 10, 2020 · 6 comments · Fixed by #1118
Closed

Producing images for the IBM Cloud chimera #1119

lucab opened this issue Feb 10, 2020 · 6 comments · Fixed by #1118

Comments

@lucab
Copy link
Contributor

lucab commented Feb 10, 2020

This is a followup to coreos/fedora-coreos-tracker#277 (comment), specifically concerning coreos-assembler.

I started some work on IBM Cloud VPC Generation 2, which resulted in #1118.
Afterward I moved onto IBM Cloud Classic and sadly discovered that it would need another separate image because:

  • it takes a VHD (while Gen 2 needs a qcow2)
  • it needs specific kargs (as it doesn't have DHCP, so no rd.neednet=1 ip=dhcp to dracut)

At this point I'm thus asking how to proceed. Two possible paths:

  1. keep ibmcloud platform ID only for Gen2, later (maybe) allocate specific IDs for Classic / Gen1
  2. keep ibmcloud as the single umbrella platform ID, produce multiple image "formats" akin to what we do for metal images

#1118 goes with the first option (platform: ibmcloud, format: qcow2), however the second option would instead require a slightly different arrangement since the beginning (platform: ibmcloud, format: gen2).

As a sidenote to option 1, it could be a good idea to make it more explicit and rename the platform ID to ibmcloud-gen2.

@jlebon
Copy link
Member

jlebon commented Feb 10, 2020

So summing up, the two clouds have different mechanisms for (1) how user-data is fetched, (2) how network is set up, and (3) which disk format is accepted? Are there things that are the same between the two, yet not shared with other clouds? If not, this strongly suggests to me making them separate platform IDs entirely.

@ashcrow
Copy link
Member

ashcrow commented Feb 10, 2020

Are there things that are the same between the two, yet not shared with other clouds? If not, this strongly suggests to me making them separate platform IDs entirely.

I agree with ☝️. If there isn't much that unites the two platforms I'd suggest noting ibmcloud for the gen 2 and ibmcloud-classic or something like that for the classic version.

@dustymabe
Copy link
Member

Dumb question.. Since gen2 already exists - could we just not support classic?

@ashcrow
Copy link
Member

ashcrow commented Feb 10, 2020

Dumb question.. Since gen2 already exists - could we just not support classic?

Not a dumb question. For FCOS I think that focusing on the latest and greatest makes a lot of sense. However, it's expected RHCOS will work on both.

@lucab
Copy link
Contributor Author

lucab commented Feb 11, 2020

Ack, looking at the thumbs-up it seems there is general consensus to proceed as follow:

  • keep ibmcloud as the platform identifier for IBM Cloud VPC Generation 2
  • explore IBM Cloud Classic under a specific identifier ibmcloud-classic
  • purposely ignore IBM Cloud VPC Generation 1, as it is not relevant to either RHCOS nor FCOS

@ashcrow
Copy link
Member

ashcrow commented Feb 11, 2020

Agreed @lucab

lucab added a commit to lucab/fedora-coreos-docs that referenced this issue Feb 13, 2020
This adds `ibmcloud-classic` as the platform ID for IBM Cloud
Classic instances.

Ref: coreos/coreos-assembler#1119 (comment)
jcajka pushed a commit to jcajka/coreos-assembler that referenced this issue Mar 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants