Open Stack

Hi John,
Comments in-line

On Sun, 2014-08-24 at 16:37 +0300, 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.

I actually don't think a real decision was made at the hackathon for
this.  I know we were originally going to do a shim layer to translate
v1 calls into v2 and v2 object model to v1 for v1 driver consumption.  I
am, however, fine with that rule and it will make things much simpler.
There will definitely need to be code in the intiialization of both v1
and v2 plugins that check whether the other version has been
initialized, since we cannot guarantee an order in which
extensions/service plugins are loaded.  This should be trivial to do
though.

> 
> 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?)

A /version endpoint can be added for both v1 and v2 extensions and
service plugins.  If it doesn't already exist, it would be nice if
neutron had an endpoint that would return the list of loaded extensions
and their 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?

That is the reason we with with lbaas because lbv2 looks ugly and we'd
be stuck with it for the lifetime of v2, unless we did another migration
back to lb for it.  Which seemed wrong to do, since then we'd have to
accept both lbv2 and lb commands, and then deprecate lbv2.

I assume this also means you are fine with the prefix in the API
resource of /lbaas as well then?

> 
> 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.

Could you elaborate on this? I don't understand what you mean by
"different API between version."

> 
> 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