Open Stack

Hi Clark,
From my understanding the keystone catalog will not contain endpoints
for neutron extensions.  I could see it being allowed but since Neutron
can enable/disable extensions on a whim, there would need to be some
cross project communication between keystone and neutron.  I'm sure
there are other issues that would arise from this too.  Then again, I
could be wrong and this is already both solved for and allowed in
Keystone.

Regarding having two separate commands for each version; Since neutron
extensions don't have any kind of versioning built it, it would be tough
to do through the API at least.  The client can make smart decisions
though and make it easier for a user.  However, if lb-<object>-<action>
worked for both v1 and v2, and the user has no idea what Neutron has
loaded, I don't see that being a better user experience when they try to
do a v1 command when v2 has been loaded.

Thanks,
Brandon
On Sun, 2014-08-24 at 11:50 -0700, Clark Boylan wrote:
> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev