With the ongoing development of LBaaS v2, support for v2 of LBaaS in
neutronclient is also being developed, as can be seen in [1].
The current implementation adds a new syntax for v2; Whereas the v1
syntax is 'neutron lb-<object>-<command>', the new v2 syntax is 'neutron

We fear that this can lead to some level of confusion on the users'
side. Currently, nothing prevents a user from trying to create a v1 pool
and then trying to add v2 members. Of course the second command will
fail, but the error message will be a non-intuitive one.

This was discussed at the last weekly IRC meeting ([2]). Some bulletins:

1. As was discussed in the hackathon, there shouldn't be more than one
version active at any given time - either v1 or v2. Also, using the same
syntax for both v1 and v2 is not a good idea (db migration will be
difficult when both version share syntax). We believe this should also
be enforced in the server side.

2. Therefor, there should be some configuration to specifically enable
either version (not both) in case LBaaS is needed. In this case, the
other version is disabled (ie. a REST query for non-active version
should return a "not activated" error). Additionally, adding a
'lb-version' command to return the version currently active seems like a
good user-facing idea. We should see how this doesn't negatively effect
the db migration process (for example, allowing read-only commands for
both versions?)

3. Another decision that's needed to be made is the syntax for v2. As
mentioned, the current new syntax is 'neutron lbaas-<object>-<command>'
(against the old 'lb-<object>-<action>'), keeping in mind that once v1
is deprecated, a syntax like 'lbv2-<object>-<action>' would be probably
unwanted. Is 'lbaas-<object>-<command>' okay with everyone?

4. If we are going for different API between versions, appropriate
patches also need to be written for lbaas-related scripts and also
Tempest, and their maintainers should probably be notified.

Are there any issues with one of the points raised above? Does anyone
see any other problems which we forgot to write down?

Thanks a lot,

John Schwarz, Yair Fried,

[1]: https://review.openstack.org/#/c/111475

OpenStack-dev mailing list

Reply via email to