cluster-api-provider-openstack
cluster-api-provider-openstack copied to clipboard
kubernetes-sigs
Enhance openstack flavor information
/kind feature
Describe the solution you'd like
I'm facing a little trouble trying to return some useful data. I'm creating OpenStack instances using flavors and I want to return the vCPU, memory, and disk size/type for any instance created on Openstack by CAPO through API calls. The problem with it is that the only source of information of the Disk, for example, that is accessible using CAPO Objects is RootVolume and DiskType, which are empty by default when the instance is created using an OpenStack instance flavor.
My suggestion is to turn the Flavor field, which is a string, into a struct, and add some fields in it like name, ID, memory, etc. I'm trying to come up with a solution myself, but I would like to start the discussion on whether something like this is a fit for the project.
Anything else you would like to add: A workaround to this would be using gophercloud to return specific OpenStack information, but I think consulting CAPO would be a more elegant approach.
are you looking for https://docs.openstack.org/api-ref/compute/?expanded=list-servers-detail,list-servers-detailed-detail#list-servers-detailed
this information to be obtained through CAPO? e.g you can describe the openstackmachine
and get those information ?
<html><body>
<!--StartFragment-->
flavor | body | object | Before microversion 2.47 this contains the ID and links for the flavor used to boot the server instance. This can be an empty object in case flavor information is no longer present in the system. As of microversion 2.47 this contains a subset of the actual flavor information used to create the server instance, represented as a nested dictionary.
-- | -- | -- | --
<!--EndFragment-->
</body>
</html>
more like https://docs.openstack.org/api-ref/compute/?expanded=show-flavor-details-detail, make the openstackmachine hold information about the flavor
that's exactly I am saying .. if you check the microversion I posted above, flavor from ID become detailed info in nova's response in that microversion so just use that should be good enough
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
My suggestion is to turn the Flavor field, which is a string, into a struct, and add some fields in it like
name,ID,memory, etc. I'm trying to come up with a solution myself, but I would like to start the discussion on whether something like this is a fit for the project.
The problem with this is that as much as we like it, flavour is not actually an immutable object because of extra_specs, so it wouldn't be all that accurate.
It's probably better to go by the API.
@jfcavalcante: Closing this issue.
In response to this:
/close
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.
