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.lo...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
