Open Stack

I would like to add a question to John's list



----- Original Message -----
> From: "John Schwarz" <jschwarz at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Tuesday, August 26, 2014 2:22:33 PM
> Subject: Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax	additions/changes
> 
> 
> 
> On 08/25/2014 10:06 PM, Brandon Logan wrote:
> >>
> >> 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.
> > 
> There is 'neutron ext-list', but I'm not familiar enough with it or with
> the REST API to say if we can use that.
> >>
> >> 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?
> > 
> I don't mind, as long there is a similar mechanism which disables the
> non-active REST API commands. Does anyone disagree?
> >>
> >> 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."
> > 
> The intention was that the change of the user-facing API also forces
> changes on other levels - not only neutronclient needs to be modified
> accordingly, but also tempest system tests, horizon interface regarding
> LBaaS...


5. If we accept #3 and #4 to mean that the python-client API and CLI must be 
changed/updated and so does Tempest clients and tests, then what about other 
projects consuming the Neutron API? How are Heat and Ceilometer going to be 
affected by this change?

Yair


> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>