Open Stack

On Tue, 2014-08-26 at 14:22 +0300, John Schwarz wrote:
> 
> 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.

Looks like this will be sufficient.  No new rest endpoint needed.

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

Oh yes this is in the works.  Miguel is spearheading the tempest tests
and has made good progress on it.  Horizon integration hasn't begun yet
though.  Definitely something we want to get in though.  Have to wait
until more information about the incubator comes out and where these
patches for other products need to go.

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