Open Stack

Yair,

I am very well plugged-in to this project and feeding the necessary
information to the weekly Tempest IRC meeting. In fact, since a few weeks
ago, I've made a point of sharing weekly with the Tempest team what I am
doing with the LBaaS team from the Tempest point of view.

Cheers


On Thu, Aug 28, 2014 at 11:31 PM, Brandon Logan <brandon.logan at rackspace.com
> wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140829/86b5b572/attachment.html>