Open Stack

On Sun, Aug 24, 2014, at 06:37 AM, John Schwarz wrote:
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

As a user of both the neutron API and python-neutronclient it would be
much better to have the client use a common set of commands for both v1
and v2 where the specific version used is determined by the keystone
catalog or other overriding information. I don't want to have to
remember two different sets of commands with potentially two different
outputs. Client libraries exist so that users don't have to think about
this stuff.

This should prevent confusion as users will use a common version unless
they specifically provide an override of some sort.

Clark