Hi, 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 lbaas-<object>-<command>'.
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, Redhat. [1]: https://review.openstack.org/#/c/111475 [2]: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
