Discussion/Question: Adding new functionality for octavia resources

[nikParasyr]

Hello,

This is more of a discussion/question issue to clarify some things i've noticed when adding new functionality for octavia resources. In general octavia has been adding quite some new functionality in new releases that is still missing from the provider.

Using neutronlbass for createOpts and updateOpts

Till now most resources in the Create and Update func have a helper func that creates and returns the createOpts and updateOpts but those are of type neutronlbaas. This has been ok till now but for quite some features new request fields are being added making this setup not really usable. For the resources that will handle new request fields I think just creating to helper funcs will be sufficient. Let me know if i'm missing something.

Handling microversions

Most of these features are microversion dependent., thus handling microversions properly and in a consistent way across resources is sort of needed.

I might be opening a pandora box now. I've read some of the documentation and issues in regards with microversions (openstack, gophercloud doc gophercloud issue ). There are already some helper func for microversions. I went (although not in depth) through the manilla and nova ones. Nova has a open issue. I'm not sure if these function can be re-used or help in general, and if gophercloud offers some utils for this.

From the openstack clouds i have access to (Stein/Train) and from docs there are some notes:

1. All features have a min microversion but not a max microversion (at least until now). This could simplify things.
2. Octavia api seems to support all "lower" microversions. For example even if the current and max microversion of a cloud is 2.20, 2.1 is still available. In comparison this is not the case with the nova api. That being said I would expect/assume that in later releases some of the lowest microversions will become deprecated. In such a case setting the lower microversion on the client can lead to an error even though the feature is supported.

Until now, I was just setting the client microversion to the MinMicroversion required for that feature. If a resource had multiple microversion dependant fields then i just ordered them from lower to higher ensuring that the client microversion will have the highest required microversion. This approach isn't very clear though and does not help for the 2nd point i made above.

Any input/guidance is much appreciated

[ozerovandrei]

It would be great to understand the current view on Microversion design from OpenStack developers.
This can help to create an architecture of Microversion helper implementation in this provider.

[nikParasyr]

i'll try to reach out to them (at least the octavia ones) via IRC and/or a proper mailing list

[nikParasyr]

I had a chat in the openstack-lbaas IRC regarding this. I'm posting the snippet for reference:

(09:54:05) nikparasyr: hello :). can someone give me a bit of insight on how octavia is using microversions. My question relates to: #1239 in the "handling microversions" section. I went through octavia documentation and couldnt find a section in terms of api microversions.
(09:55:29) nikparasyr: i'm also missing in the api docs anything referencing the apiversions "endpoint". For example magnum offers this: https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=#api-versions, while on octavia i couldn't find something similar. I know that the endpoint is there etc but some documentation would be helpful
(10:00:13) cgoncalves: nikparasyr, the Octavia API does not have microversions. they are not necessary as features are not removed from the LBaaS v2 API. the Octavia API has minor version so (e.g. version 2.15)
(10:00:22) cgoncalves: nikparasyr, are you looking for https://docs.openstack.org/api-ref/load-balancer/v2/#service-endpoints ?
(10:01:22) cgoncalves: also please check the note message just above it, in the "General API Overview" section
(10:11:31) nikparasyr: hi thanks for the input. Just to clarify, octavia doesn't use the microversion (by setting a header etc) similar to nova, manilla etc? For example if I use: curl -s -H "X-Auth-Token: $OS_TOKEN" "https://10.0.0.10:9876/" i get a list of versions etc. i cannot then specify which version to use by setting a microversion header?
(10:28:23) nikparasyr: cgoncalves, is it also the case than if a feature was added on minor version 2.15, that then that feature will be supported on any minor version >= 2.15? So if i need to check if that feature is supported on cloud X i just need to check that 2.15 is supported in the list returned from curl -s -H "X-Auth-Token: $OS_TOKEN" "https://10.0.0.10:9876/" or that the current in that list is basically >= 2.15?
(11:23:13) cgoncalves: nikparasyr, correct, any new feature will be supported on any later minor version

Based on that:

• The changes that have been made till now were setting the microversion. This seems to be irrelevant and wrong and thus can be removed.
• I see 2 ways of going forward:
  • We do not do any checks for minor versions. We just document in the implementation code and on the user docs the minimum minor version required for this feature. It is then left up to the user to ensure that the cloud he uses supports the required minor version. We might want to document an easy way for a user to get the list of versions.
    PROS: easy to implement, less maintanance, easier to add new features etc
    CONS: can be unclear for a user why X/Y request failed (proper documentation should mitigate this issue)
  • We do check minor versions. A simple approach would be that we make a call to take the list of the supported versions(needs to be implemented on gophercloud probably) and for every field/attribute that requires a minimal minor version we check that current >= minor version required. If that is not the case we return with a appropriate error message.
    PROS: Error message will make it easier for user to understand what went wrong
    CONS: Adds complexity

While the second approach seems to be more user-friendly I'm not 100% sure if it's worth the overhead(which isnt really that much but im just not sure that it will make it much clearer for the user)

@ozerovandrei let me know what you think about it and which way seems the preferred one. Also let me know if any further investigation is required.

[ozerovandrei]

Thanks for the research!

I guess that the first way looks more preferable because of the less amount of required maintenance.

[nikParasyr]

Sorry for the delay.

I'll prep a PR later this/next week to change the existing features and also add some documentation regarding this.

Thanks a lot :)

[nikParasyr]

Closed with #1249