Add OpenNebula provider #478
Conversation
| @@ -63,6 +64,7 @@ pub fn fetch_metadata(provider: &str) -> errors::Result<Box<dyn providers::Metad | |||
| "ibmcloud" => box_result!(IBMGen2Provider::try_new()?), | |||
| // IBM Cloud - Classic infrastructure. | |||
| "ibmcloud-classic" => box_result!(IBMClassicProvider::try_new()?), | |||
| "one" => box_result!(ContextDrive::try_new()?), | |||
There was a problem hiding this comment.
Is this an arbitrary ID or is there prior usage of this specific value anywhere in the CoreOS world?
There was a problem hiding this comment.
I'm not aware of "one" being used as the short moniker for OpenNebula within the CoreOS world, but it is the predominantly used short reference name for OpenNebula in other areas, like oneadmin as the default login user, or the command line tools onevm, etc. I chose the short name here to match the other used short references like "gcp" and "aws", but I'll leave the final decision up to you.
There was a problem hiding this comment.
Thanks for the feedback. I brought this up yesterday in the weekly FCOS meeting and the broad consensus was to use opennebula as the ID for this platform.
Part of the rationale is that one is too easy to cause confusion when casually mentioned in isolation, outside of the specific OpenNebula context.
We can freely keep the ONE_ prefix for attributes, I think the shorthand makes sense there.
There was a problem hiding this comment.
We can freely keep the
ONE_prefix for attributes, I think the shorthand makes sense there.
Shouldn't we keep the prefix consistent with the platform ID? The only case where we currently diverge is the -configdrive and -metadata providers.
|
@FrankPetrilli thanks for the PR! I have not done a review pass yet, but from a first skim it looks ok. However, the process for adding new platforms usually starts from the other end of the pipe, with an umbrella integration ticket for Fedora CoreOS (FCOS). We already have coreos/fedora-coreos-tracker#166 which we can use for that, and just pinning the platform ID there would be a good start to unblock this. For context, where are you currently using (or planning to use) this? Development here usually targets FCOS, but I do understand that there is a whole world outside of that. |
|
Hi Luca! Great - I've offered some discussion around the platform ID in the in-line comment above, and I'm open to your comments on that matter. With respect to the target, I've been testing with Flatcar Linux and initially developed this for the flatcar-linux/afterburn repo. However, this repo's #362 is semi-integral to my use case, and I'm not stuck on either Flatcar vs. FCOS. I would like to get this change percolated over to Flatcar as well if feasible, but that can come in time, since it's much more helpful with the initrd networking PR included. |
|
For transparency, I'm not actively pursuing #362 anymore. But that topic can be resurrected, possibly involving the NM folks and the systemd / Flatcar ones (for networkd). |
|
I'm interested in this, too. My plan is to use it for okd development (on opennebula). Has work on this stopped? The current commit defines "one" as the platform id, but coreos/fedora-coreos-tracker#166 (comment) says the consensus is that it should be "opennebula". Any hope of moving this forward? |
|
I'm not presently working on this since the initrd networking change (#362) is needed for this to be very helpful. I've also moved away from using Flatcar or its siblings for my current projects. |
OpenNebula is an open-source private cloud system. Its metadata context is passed to VMs through a virtual disk which contains a shell script with bash variables.
This provider supports:
Due to networks in OpenNebula not always containing a DHCP server, this PR would be greatly improved by #362 once that's merged.