Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree
Hi, Robert Kukura's proposal does address the following: 1. Make it explicit to the user that an API is in "preview" until it's moved out of the preview directories 2. One of the criteria to accept a BP for preview is for the functionality to be optional via configuration. This will not impact the stability of neutron in the general case 3. Allows for new API/functionality to be built leveraging all the neutron infrastructure available 4. Allows for users to adopt new API, increasing the footprint of neutron users +1 on this proposal from my side. Regards, -hemanth On Fri, Aug 8, 2014 at 3:28 PM, Salvatore Orlando wrote: > "If we want to keep everything the way it is, we have to change > everything" [1] > > This is pretty much how I felt after reading this proposal, and I felt > that this quote, which Ivar will probably appreciate, was apt to the > situation. > Recent events have spurred a discussion about the need for a change in > process. It is not uncommon indeed to believe that by fixing the process, > things will inevitably change for better. While no-one argues that flaws in > processes need to be fixed, no process change will ever change anything, in > my opinion, unless it is aimed at spurring change in people as well. > > From what I understand, this proposal starts with the assumption that any > new feature which is committed to Neutron (ie: has a blueprint approved), > and is not a required neutron component should be considered as a preview. > This is not different from the process, which, albeit more informally, has > been adopted so far. Load Balancing, Firewall, VPN, have all been > explicitly documented as experimental in their first release; I would argue > that even if not experimental anymore, they may not be considered stable > until their stability was proven by upstream QA with API and scenario tests > - but this is not sanctioned anywhere currently, I think. > > According to this proposal, for preview features: > - all the code would be moved to a "preview" package > - Options will be marked as "preview" > - URIs should be prefixed with "preview" > - CLIs will note the features are "preview" in their help strings > - Documentation will explicitly state this feature is "preview" (I think > we already mark them as experimental, frankly I don't think there are a lot > of differences in terminology here) > - Database migrations will be in the main alembic path as usual > - CLI, Devstack and Heat support will be available > - Can be used by non-preview neutron code > - Will undergo the usual review process > - QA will be desirable, but will done either with "WIP" tempest patches or > merging the relevant scenario tests in the preview feature iself > - The feature might be promoted or removed, but the process for this is > not yet defined. > > I don't think this change in process will actually encourage better > behaviour both by contributors and core reviewers. > I reckon that better behaviour might be encouraged by forcing developer > and reviewers to merge in the neutron source code tree only code which > meets the highest quality standards. A change in process should enforce > this - and when I think about the criteria, I think at the same kind of > criteria we're being imposed to declare parity with nova. Proven > reliability, and scalability should be a must. Proven usability should be a > requirement for all new APIs. > On the other hand we also need to avoid to over bureaucratise Neutron - > nobody loves that - and therefore ensure this process is enforced only when > really needed. > > Looking at this proposal I see a few thing I'm not comfortable with: > - having no clear criterion for exclusion a feature might imply that will > be silently bit-rotting code in the preview package. Which what would > happen for instance if we end up with a badly maintained feature , but > since one or two core devs care about it, they'll keep vetoing the removal > - using the normal review process will still not solve the problem of slow > review cycles, pointless downvotes for reviewers which actually just do not > understand the subject matter, and other pains associated with lack of > interest from small or large parts of the core team. For instance, I think > there is a line of pretty annoyed contributors as we did not even bother > reviewing their specs. > - The current provision about QA seems to state that it's ok to keep code > in the main repo that does not adhere to appropriate quality standards. > Which is the mistake we did with lbaas and other features, and I would like > to avoid. And to me it is not sufficient that the code is buried in the > 'preview' package. > - Mostly important, this process provides a justification for contributors > to push features which do not meet the same standards as other neutron > parts and expect them to be merged and eventually promoted, and on the > other hand provides the core team with the entitlement for merging them - > therefore my main
Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward
On Fri, Aug 8, 2014 at 5:38 PM, Armando M. wrote: > > >> One advantage of the service plugin is that one can leverage the neutron >> common framework such as Keystone authentication where common scoping is >> done. It would be important in the policy type of framework to have such >> scoping >> > > The framework you're referring to is common and already reusable, it's not > a prerogative of Neutron. > Are you suggesting that Service Plugins, L3, IPAM etc become individual endpoints, resulting in redundant authentication round-trips for each of the components. Wouldn't this result in degraded performance and potential consistency issues? > > >> >> While the service plugin has scalability issues as pointed above that it >> resides in neutron server, it is however stable and user configurable and a >> lot of common code is executed for networking services. >> > > This is what static or dynamic libraries are for and reused for; I can > have a building block and reuse it many times the way I see fit keeping my > components' lifecycles separate. > > >> So while we make the next generation services framework more distributed >> and scalable, it is ok to do it under the current framework especially >> since it has provision for the user to opt in when needed. >> > > A next generation services framework is not a prerequisite to integrating > two OpenStack projects via REST APIs. I don't see how we would associate > the two concepts together. > > >> >> >>> >>> ___ >>> 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 > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward
On Fri, Aug 8, 2014 at 7:13 PM, Armando M. wrote: > >> On Fri, Aug 8, 2014 at 5:38 PM, Armando M. wrote: >> >>> >>> One advantage of the service plugin is that one can leverage the neutron common framework such as Keystone authentication where common scoping is done. It would be important in the policy type of framework to have such scoping >>> >>> The framework you're referring to is common and already reusable, it's >>> not a prerogative of Neutron. >>> >> >> Are you suggesting that Service Plugins, L3, IPAM etc become individual >> endpoints, resulting in redundant authentication round-trips for each of >> the components. >> >> Wouldn't this result in degraded performance and potential consistency >> issues? >> > > The endpoint - in the OpenStack lingo - that exposes the API abstractions > (concepts and operations) can be, logically and physically, different from > the worker that implements these abstractions; authentication is orthogonal > to this and I am not suggesting what you mention. > >From what I understand, you are saying that the implementation could be done via a mechanism different than a service plugin. Would this be done by implementing the service plugin as a different process? This would imply making changes to the the neutron server - plugin interface. If this is the case, wouldn't it be better to use the existing mechanism to avoid introducing any instability at this stage of the Juno cycle. > ___ > 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
Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron
Kyle, One Convergence third-party CI is failing due to https://bugs.launchpad.net/neutron/+bug/1353309. Let me know if we should turn off the CI logs until this is fixed or if we need to fix anything on the CI end. I think one other third-party CI (Mellanox) is failing due to the same issue. Regards, -hemanth On Tue, Jul 29, 2014 at 6:02 AM, Kyle Mestery wrote: > On Mon, Jul 28, 2014 at 1:42 PM, Hemanth Ravi > wrote: > > Kyle, > > > > One Convergence CI has been fixed (setup issue) and is running without > the > > failures for ~10 days now. Updated the etherpad. > > > Thanks for the update Hemanth, much appreciated! > > Kyle > > > Thanks, > > -hemanth > > > > > > On Fri, Jul 11, 2014 at 4:50 PM, Fawad Khaliq > wrote: > >> > >> > >> On Fri, Jul 11, 2014 at 8:56 AM, Kyle Mestery < > mest...@noironetworks.com> > >> wrote: > >>> > >>> PLUMgrid > >>> > >>> Not saving enough logs > >> > >> All Jenkins slaves were just updated to upload all required logs. > PLUMgrid > >> CI should be good now. > >> > >> > >> Thanks, > >> Fawad Khaliq > >> > >> > >> ___ > >> 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron
Anita, Yes, I'm the contact for One Convergence CI. Thanks, -hemanth On Tue, Aug 12, 2014 at 3:12 PM, Anita Kuno wrote: > On 08/12/2014 03:23 PM, Hemanth Ravi wrote: > > Kyle, > > > > One Convergence third-party CI is failing due to > > https://bugs.launchpad.net/neutron/+bug/1353309. > > > > Let me know if we should turn off the CI logs until this is fixed or if > we > > need to fix anything on the CI end. I think one other third-party CI > > (Mellanox) is failing due to the same issue. > > > > Regards, > > -hemanth > Are you One Convergence CI, hemanth? > > Sorry I don't know who is admin'ing this account. > > Thanks, > Anita. > > > > > > On Tue, Jul 29, 2014 at 6:02 AM, Kyle Mestery > wrote: > > > >> On Mon, Jul 28, 2014 at 1:42 PM, Hemanth Ravi > >> wrote: > >>> Kyle, > >>> > >>> One Convergence CI has been fixed (setup issue) and is running without > >> the > >>> failures for ~10 days now. Updated the etherpad. > >>> > >> Thanks for the update Hemanth, much appreciated! > >> > >> Kyle > >> > >>> Thanks, > >>> -hemanth > >>> > >>> > >>> On Fri, Jul 11, 2014 at 4:50 PM, Fawad Khaliq > >> wrote: > >>>> > >>>> > >>>> On Fri, Jul 11, 2014 at 8:56 AM, Kyle Mestery < > >> mest...@noironetworks.com> > >>>> wrote: > >>>>> > >>>>> PLUMgrid > >>>>> > >>>>> Not saving enough logs > >>>> > >>>> All Jenkins slaves were just updated to upload all required logs. > >> PLUMgrid > >>>> CI should be good now. > >>>> > >>>> > >>>> Thanks, > >>>> Fawad Khaliq > >>>> > >>>> > >>>> ___ > >>>> 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 > >> > > > > > > > > ___ > > 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
Re: [openstack-dev] [neutron] [third-party] What tests are required to be run
Edgar, Our CI is running the tests (non voting), but don't see it listed on the review for any patch. Is this due to missing logs? I would like to confirm this is the issue, will resolve this. Thanks, -hemanth On Mon, Aug 18, 2014 at 8:35 AM, Edgar Magana wrote: > Thank you Akihiro. > > I will propose a better organization for this section. Stay tune! > > Edgar > > On 8/17/14, 10:53 PM, "Akihiro Motoki" wrote: > > > > >On 2014/08/18 0:12, Kyle Mestery wrote: > >> On Fri, Aug 15, 2014 at 5:35 PM, Edgar Magana > >> wrote: > >>> Team, > >>> > >>> I did a quick audit on the Neutron CI. Very sad results. Only few > >>>plugins > >>> and drivers are running properly and testing all Neutron commits. > >>> I created a report here: > >>> > >>> > https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plu > >>>gin > >>> _and_Drivers > >>> > >> Can you link this and/or move it to this page: > >> > >> https://wiki.openstack.org/wiki/NeutronPlugins > >> > >> This is under the "NeutronPolicies" wiki page which I did at the start > >> of Juno. This tracks all policies and procedures for Neutron, and > >> there's a Plugins page (which I linked to above) where this should > >> land. > > > >I just added the link Neutron_Plugins_and_Drivers#Existing_Plugin > >to NeutronPlugins wiki. > > > >The wiki pages NeutronPlugins and Neutron_Plugins_and_Drivers > >cover the similar contents. According to the history of the page, > >the latter one was created by Mark at Nov 2013 (beginning of Icehouse > >cycle). > >It seems better to merge these two pages to avoid the confusion. > > > >Akihiro > > > >> > >>> > >>> We will discuss the actions to take on the next Neutron IRC meeting. So > >>> please, reach me out to clarify what is the status of your CI. > >>> I had two commits to quickly verify the CI reliability: > >>> > >>> https://review.openstack.org/#/c/114393/ > >>> > >>> https://review.openstack.org/#/c/40296/ > >>> > >>> > >>> I would expect all plugins and drivers passing on the first one and > >>> failing for the second but I got so many surprises. > >>> > >>> Neutron code quality and reliability is a top priority, if you ignore > >>>this > >>> report that plugin/driver will be candidate to be remove from Neutron > >>>tree. > >>> > >>> Cheers, > >>> > >>> Edgar > >>> > >>> P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty > >>>job! > >>> > >> Thanks for sending this out Edgar and doing this analysis! Can you > >> please put an agenda item on Monday's meeting to discuss this? I won't > >> be at the meeting as I'm on PTO (Mark is running the meeting in my > >> absence), but I'd like the team to discuss this and allow all > >> third-party people a chance to be there and share their feelings here. > >> > >> Thanks, > >> Kyle > >> > >>> > >>> On 8/14/14, 8:30 AM, "Kyle Mestery" wrote: > >>> > Folks, I'm not sure if all CI accounts are running sufficient tests. > Per the requirements wiki page here [1], everyone needs to be running > more than just Tempest API tests, which I still see most neutron > third-party CI setups doing. I'd like to ask everyone who operates a > third-party CI account for Neutron to please look at the link below > and make sure you are running appropriate tests. If you have > questions, the weekly third-party meeting [2] is a great place to ask > questions. > > Thanks, > Kyle > > [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting > [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty > > ___ > 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 > >> > >___ > >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
Re: [openstack-dev] [neutron] [third-party] What tests are required to be run
Edgar, CI name: One Convergence CI The logs issue has been fixed and earlier tests were failing due to https://review.openstack.org/#/c/114146 For reference: 1. Please take a look at the vote on patchset 7 in https://review.openstack.org/#/c/114968/ 2. Logs at https://www.dropbox.com/sh/czydzz5bn2rc2lp/AABZByV8UQUIqWaZSSrZvzvDa Thanks, -hemanth On Thu, Aug 21, 2014 at 12:41 PM, Kevin Benton wrote: > Our system would get backed up with patches and sometimes take up to 10 > hours to respond with results for a change. > We should establish some maximum acceptable time to get the results for a > patch. > > > On Thu, Aug 21, 2014 at 11:59 AM, Edgar Magana > wrote: > >> Maximum time to vote, can you clarify? >> >> Edgar >> >> From: Kevin Benton >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> >> Date: Tuesday, August 19, 2014 at 1:11 PM >> >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> Subject: Re: [openstack-dev] [neutron] [third-party] What tests are >> required to be run >> >> I also added a two more nodes to our cluster to reduce the delay. Can >> we establish a maximum time to vote on the wiki? >> On Aug 19, 2014 9:39 AM, "Edgar Magana" wrote: >> >>> Kevin, >>> >>> I just verified, Thanks a lot. >>> >>> Edgar >>> >>> From: Kevin Benton >>> Reply-To: "OpenStack Development Mailing List (not for usage >>> questions)" >>> Date: Friday, August 15, 2014 at 4:56 PM >>> To: "OpenStack Development Mailing List (not for usage questions)" < >>> openstack-dev@lists.openstack.org> >>> Subject: Re: [openstack-dev] [neutron] [third-party] What tests are >>> required to be run >>> >>> You didn't wait long enough for the Big Switch CI to reach your >>> negative test. :-) >>> Currently the CI system is backed by about 100 patches to push >>> responses out ~22 hours. >>> >>> This does bring up an old discussion that was never resolved. >>> What is the minimum expected response time for CI systems? >>> >>> >>> On Fri, Aug 15, 2014 at 3:35 PM, Edgar Magana >>> wrote: >>> Team, I did a quick audit on the Neutron CI. Very sad results. Only few plugins and drivers are running properly and testing all Neutron commits. I created a report here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin _and_Drivers We will discuss the actions to take on the next Neutron IRC meeting. So please, reach me out to clarify what is the status of your CI. I had two commits to quickly verify the CI reliability: https://review.openstack.org/#/c/114393/ https://review.openstack.org/#/c/40296/ I would expect all plugins and drivers passing on the first one and failing for the second but I got so many surprises. Neutron code quality and reliability is a top priority, if you ignore this report that plugin/driver will be candidate to be remove from Neutron tree. Cheers, Edgar P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job! On 8/14/14, 8:30 AM, "Kyle Mestery" wrote: >Folks, I'm not sure if all CI accounts are running sufficient tests. >Per the requirements wiki page here [1], everyone needs to be running >more than just Tempest API tests, which I still see most neutron >third-party CI setups doing. I'd like to ask everyone who operates a >third-party CI account for Neutron to please look at the link below >and make sure you are running appropriate tests. If you have >questions, the weekly third-party meeting [2] is a great place to ask >questions. > >Thanks, >Kyle > >[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting >[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty > >___ >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 >>> >>> >>> >>> -- >>> Kevin Benton >>> >>> ___ >>> 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 >> >> > > > -- > Kevin Benton > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
[openstack-dev] [neutron] [third-party-testing] Tests against vendor controller
Hi, We are developing a neutron plugin that works with our network controller. Do we need to have 2 sets of tests for the plugin i) tests that can be run against the network controller in our third party test setup (to vote on changes to the plugin) ii) tests that can be run in the OpenStack test setup Thanks, -hemanth ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][3rd Party Testing] Jenkins setup
Hi, Below are the set of steps we are using for Jenkins setup and would like some clarifications reg some of the steps. Under Jenkins/Configure 1. Source Code Management: to be git and point to the devstack URL 2. Build Triggers: Gerrit Event 3. Build/Execute Shell: Sequence of commands to be executed 1. unstack.sh 2. configure localrc 3. configure 3rd party plugin 4. stack.sh 5. sequence of "nosetests" cmds with the tests to be run. 4. Post build Actions: Gerrit Integration to post the event (not configured currently) For step 3/5, is the right procedure. Or is there a way to use a cmd to run all the tests and use a different mechanism to specify a filter for the tests to be run. Thanks, -hemanth ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party-testing] Sharing information
Hi, Resending on this thread Below are the set of steps we are using for Jenkins setup and would like some clarifications reg some of the steps. Under Jenkins/Configure 1. Source Code Management: to be git and point to the devstack URL 2. Build Triggers: Gerrit Event 3. Build/Execute Shell: Sequence of commands to be executed 1. unstack.sh 2. configure localrc 3. configure 3rd party plugin 4. stack.sh 5. sequence of "nosetests" cmds with the tests to be run. 4. Post build Actions: Gerrit Integration to post the event (not configured currently) For step 3/5, is the right procedure. Or is there a way to use a cmd to run all the tests and use a different mechanism to specify a filter for the tests to be run. Thanks, -hemanth On Wed, Jan 15, 2014 at 2:49 AM, Mathieu Rohon wrote: > Hi, > > does anyone knows if the multi-node environnement is targeted by the > openstack-infra team? > > > On Tue, Jan 14, 2014 at 6:22 PM, Anita Kuno wrote: > > On 01/14/2014 11:34 AM, Kyle Mestery wrote: > >> Given the Tempest Sprint in Montreal, I still think we should have this > meeting > >> on IRC. > > Shouldn't this be, "given OpenStack is an open project [0], this meeting > > will take place on irc, just like all our other meetings."? > > > > Thanks, > > Anita. > > > > [0] https://wiki.openstack.org/wiki/Governance/Foundation/Mission > > > > So, lets nail down the time as 2200 UTC on #openstack-meeting-alt > >> for tomorrow. If you can’t make it, I’ll send the meeting logs out. > >> > >> Thanks, look forward to seeing people there tomorrow! > >> > >> Kyle > >> > >> On Jan 14, 2014, at 9:49 AM, Lucas Eznarriaga > wrote: > >> > >>> Hi, > >>> I will also be available for a meeting tomorrow. > >>> @Mohammad, we are still working on our 3rd party testing setup so do > not take Midokura CI Bot votes too seriously yet. > >>> So far I have followed the links on the etherpad to have the > jenkins+gerrit trigger plugin working with the current setup that's what I > haven't added anything else yet. > >>> > >>> Cheers, > >>> Lucas > >>> > >>> > >>> > >>> On Tue, Jan 14, 2014 at 3:55 PM, Edgar Magana > wrote: > >>> I like it and I am in favor. > >>> Some of us, will be in Montreal attending the sprint tempest session. > Hopefully we can all take it from there. > >>> > >>> Edgar > >>> > On Jan 14, 2014, at 6:31 AM, Kyle Mestery > wrote: > > Thanks for sending this note Mohammad. I am all in favor of another > 3rd party testing meeting on IRC. How about if we shoot for tomorrow, > Wednesday the 15, at 2200 UTC? Please ack if that works for everyone. > > Thanks, > Kyle > > > On Jan 13, 2014, at 5:08 PM, Mohammad Banikazemi > wrote: > > > > Hi everybody, > > > > I see that we already have at least two 3rd party testing setups > (from Arista and Midokura) up and running. Noticed their votes on our newly > submitted plugin. > > The etherpad which is to be used for sharing information about > setting up 3rd party testing (as well as multi-node testing) [1] seems to > have not been updated recently. Would those who have setup their 3rd party > testing successfully be willing to share more information as to what they > have done and possibly update the etherpad? > > > > Would it be of value to others if we have another IRC meeting to > discuss this matter? > > (Kyle, I am sure you are busy so I took the liberty to send this > note. Please let us know what you think.) > > > > Thanks, > > > > Mohammad > > > > > > [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest > > > > Kyle Mestery ---12/19/2013 09:17:44 AM---Apologies > folks, I meant 2200 UTC Thursday. We'll still do the meeting today. > > > > From:Kyle Mestery > > To:"OpenStack Development Mailing List \(not for usage > questions\)" , > > Date:12/19/2013 09:17 AM > > Subject:Re: [openstack-dev] [neutron] [third-party-testing] > Reminder:Meeting tomorrow > > > > > > > > Apologies folks, I meant 2200 UTC Thursday. We'll still do the > > meeting today. > > > >> On Dec 18, 2013, at 4:40 PM, Don Kehn wrote: > >> > >> Wouldn't 2200 UTC be in about 20 mins? > >> > >> > >> On Wed, Dec 18, 2013 at 3:32 PM, Itsuro ODA > wrote: > >> Hi, > >> > >> It seems the meeting was not held on 2200 UTC on Wednesday (today). > >> > >> Do you mean 2200 UTC on Thursday ? > >> > >> Thanks. > >> > >> On Thu, 12 Dec 2013 11:43:03 -0600 > >> Kyle Mestery wrote: > >> > >>> Hi everyone: > >>> > >>> We had a meeting around Neutron Third-Party testing today on IRC. > >>> The logs are available here [1]. We plan to host another meeting > >>> next week, and it will be at 2200 UTC on Wednesday in the > >>> #openstack-meeting-alt channel on IRC. Please attend and update > >>> the
Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?
Hi, I would be interested in this discussion. Below are some time slot suggestions: Mon: 19:00, 20:00 UTC (11:00, 12:00 PST) Wed: 20:00, 21:00 UTC (12:00, 13:00 PST) Thu: 19:00, 20:00, 21:00 UTC (11:00, 12:00, 13:00 PST) Thanks, -hemanth On Mon, Feb 3, 2014 at 2:19 PM, Paul Michali wrote: > I'd like to see if there is interest in discussing vendor plugins for L3 > services. The goal is to strive for consistency across vendor > plugins/drivers and across service types (if possible/sensible). Some of > this could/should apply to reference drivers as well. I'm thinking about > these topics (based on questions I've had on VPNaaS - feel free to add to > the list): > > >- How to handle vendor specific validation (e.g. say a vendor has >restrictions or added capabilities compared to the reference drivers for >attributes). >- Providing "client" feedback (e.g. should help and validation be >extended to include vendor capabilities or should it be delegated to server >reporting?) >- Handling and reporting of errors to the user (e.g. how to indicate >to the user that a failure has occurred establishing a IPSec tunnel in >device driver?) >- Persistence of vendor specific information (e.g. should new tables >be used or should/can existing reference tables be extended?). >- Provider selection for resources (e.g. should we allow --provider >attribute on VPN IPSec policies to have vendor specific policies or should >we rely on checks at connection creation for policy compatibility?) >- Handling of multiple device drivers per vendor (e.g. have service >driver determine which device driver to send RPC requests, or have agent >determine what driver requests should go to - say based on the router type) > > If you have an interest, please reply to me and include some days/times > that would be good for you, and I'll send out a notice on the ML of the > time/date and we can discuss. > > Looking to hearing form you! > > PCM (Paul Michali) > > MAIL p...@cisco.com > IRCpcm_ (irc.freenode.net) > TW@pmichali > GPG key4525ECC253E31A83 > Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 > > > ___ > 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] [Neutron] Adding package to requirements.txt
Hi, We are in the process of submitting a third party Neutron plugin that uses urllib3 for the connection pooling feature available in urllib3. httplib2 doesn't provide this capability. Is it possible to add urllib3 to requirements.txt? If this is OK, please advise on the process to add this. Thanks, -hemanth ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Adding package to requirements.txt
Mark, We had started the plugin dev with grizzly initially and the grizzly distribution included httplib2. We used urllib3 for the HTTPConnectionPool object. Overlooked the requests module included in the master when we migrated. I'll take a look at using requests for the same support. Thanks, -hemanth On Mon, Feb 3, 2014 at 6:08 PM, Mark McClain wrote: > I'm interested to know why you are using urllib3 directly. Have you > considered using the requests module? requests is built upon urllib3 and > already a dependency of Neutron. > > mark > > On Feb 3, 2014, at 6:45 PM, Hemanth Ravi wrote: > > > Hi, > > > > We are in the process of submitting a third party Neutron plugin that > uses urllib3 for the connection pooling feature available in urllib3. > httplib2 doesn't provide this capability. > > > > Is it possible to add urllib3 to requirements.txt? If this is OK, please > advise on the process to add this. > > > > Thanks, > > -hemanth > > ___ > > 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
[openstack-dev] [Neutron] adding handler to neutron logger in neutron.openstack.common
Hi, We are in the process of submitting a neutron third-party plugin and need some advise on logging configuration to resolve the review comments for this. The plugin currently defines a log format and adds a log handler to forward logs to a remote syslog server in this format. We would like to leave the logs from the rest of neutron to be as configured by the log options in neutron.conf. Is it possible to change the format and handler only for the logs generated by the plugin using the log module in neutron.openstack.common? Appreciate any help to resolve this. -hemanth ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] False Positive testing for 3rd party CI
One Convergence CI did report the third party tests as failed, but is configured not to vote. Should we turn on the voting? Thanks, -hemanth On Fri, Feb 21, 2014 at 1:29 PM, Carl Baldwin wrote: > Aaron, > > I was thinking the same thing recently with this patch [1]. Patch > sets 1-5 should have failed for any plugin besides ml2 yet some passed > and I wondered how that could happen. Kudos to those patches that > failed my patch sets correctly. > > Carl > > [1] https://review.openstack.org/#/c/72565/ > > On Fri, Feb 21, 2014 at 11:34 AM, Aaron Rosen > wrote: > > Hi, > > > > Yesterday, I pushed a patch to review and was surprised that several of > the > > third party CI systems reported back that the patch-set worked where it > > definitely shouldn't have. Anyways, I tested out my theory a little more > and > > it turns out a few of the 3rd party CI systems for neutron are just > > returning SUCCESS even if the patch set didn't run successfully > > (https://review.openstack.org/#/c/75304/). > > > > Here's a short summery of what I found. > > > > Hyper-V CI -- This seems like an easy fix as it's posting "build > succeeded" > > but also puts to the side "test run failed". Would probably be a good > idea > > to remove the "build succeeded" message to avoid any confusion. > > > > > > Brocade CI - From the log files it posts it shows that it tries to apply > my > > patch but fails: > > > > 2014-02-20 20:23:48 + cd /opt/stack/neutron > > 2014-02-20 20:23:48 + git fetch > > https://review.openstack.org/openstack/neutron.gitrefs/changes/04/75304/1 > > 2014-02-20 20:24:00 From https://review.openstack.org/openstack/neutron > > 2014-02-20 20:24:00 * branchrefs/changes/04/75304/1 -> > > FETCH_HEAD > > 2014-02-20 20:24:00 + git checkout FETCH_HEAD > > 2014-02-20 20:24:00 error: Your local changes to the following files > would > > be overwritten by checkout: > > 2014-02-20 20:24:00 etc/neutron/plugins/ml2/ml2_conf_brocade.ini > > 2014-02-20 20:24:00 > > neutron/plugins/ml2/drivers/brocade/mechanism_brocade.py > > 2014-02-20 20:24:00 Please, commit your changes or stash them before you > can > > switch branches. > > 2014-02-20 20:24:00 Aborting > > 2014-02-20 20:24:00 + cd /opt/stack/neutron > > > > but still continues running (without my patchset) and reports success. -- > > This actually looks like a devstack bug (i'll check it out). > > > > PLUMgrid CI - Seems to always vote +1 without a failure > > (https://review.openstack.org/#/dashboard/10117) though the logs are > private > > so we can't really tell whats going on. > > > > I was thinking it might be worth while or helpful to have a job that > tests > > that CI is actually fails when we expect it to. > > > > Best, > > > > Aaron > > > > > > ___ > > 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
Re: [openstack-dev] [Heat] Combination of Heat ResourceGroup(index) with Fn::Select doesnt work ?
On Tue, Oct 21, 2014 at 12:32 PM, Zane Bitter wrote:
> On 21/10/14 14:05, Subrahmanyam Ongole wrote:
>
>> Hi
>>
>> We are in fact using OS::Neutron::PoolMember resource. I guess
>> ResourceGroup is the only iterative construct in Heat. Is the use case
>> supported today? I think this is more than a simple usage question, hence
>> posting it here. Thank you.
>>
>> Regards
>> Subra
>>
>> On Tue, Oct 21, 2014 at 8:55 AM, Fox, Kevin M wrote:
>>
>>use a OS::Neutron::PoolMember instead. Then each member template can
>>> add
>>> itself to the pool.
>>>
>>> --
>>> *From:* Magesh GV [magesh...@oneconvergence.com]
>>> *Sent:* Tuesday, October 21, 2014 12:07 AM
>>> *To:* openstack-dev@lists.openstack.org
>>> *Subject:* [openstack-dev] Combination of Heat ResourceGroup(index) with
>>> Fn::Select doesnt work ?
>>>
>>>I am trying to find a way of creating a dynamic List of
>>> Resources(Loadbalancer PoolMembers to be exact) using Heat.
>>>
>>> The idea is that the number of PoolMembers and the required Addresses
>>> would be received as Heat parameters.
>>>
>>> However, I am unable to get %index% working inside a Fn:Select block.
>>>
>>
> Yeah, it doesn't work inside intrinsic functions.
>
>Is this a bug with Heat or am I doing something wrong ?
>>>
>>
> It's arguable ;)
>
> If this is a
>>> bug/limitation in heat is there some other way to get what I am trying to
>>> do working with heat ?
>>>
>>
> You should define the PoolMember near the server it is linking to the
> pool, not in a separate ResourceGroup. Group together the things you want
> to scale as a group in a separate template and scale them as a unit.
>
>IMO this is a very important usecase for the %index%.
>>>
>>
> I'm very uneasy about %index% existing at all, and I'm not at all
> convinced that allowing something like this would achieve anything beyond
> making bad template design more tempting.
>
> Can you talk more about why you need to define the PoolMember resources in
> a different place to the actual pool members?
>
The use-case is to define a template for an LB service and customize it.
The parameters i) number of members in the pool and ii) IP addr of each of
these members are not known when the template is defined. When the service
is instantiated using the template the code that generates the values for
these params will pass these in as parameter values to heat.
>
> cheers,
> Zane.
>
>
>"Parameters": {
>>> "NumberOfMembers": {
>>> "Description": "Number of Pool Members to be created",
>>> "Type": "Number",
>>> "Default": 1
>>> },
>>> "MembersList": {
>>> "Description": "Pool Member IP Address",
>>> "Type": "Json",
>>> "Default": {"key0":"11.0.0.43"}
>>> }
>>> },
>>>
>>> "MemberList": {
>>> "Type": "OS::Heat::ResourceGroup",
>>> "Properties": {
>>>"count": {"Ref":"NumberOfMembers"},
>>>"resource_def": {
>>> "type": "OS::Neutron::PoolMember",
>>> "properties": {
>>> "address": { "Fn::Select" : [ "key%index%", {"Ref":"MembersList"}] },
>>> "admin_state_up": true,
>>> "pool_id": {"Ref":"HaproxyPool"},
>>> "protocol_port": "80",
>>> "weight": 1
>>> }
>>> }
>>>}
>>> }
>>>
>>> Regards,
>>> Magesh
>>>
>>
>
> ___
> 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
Re: [openstack-dev] [Heat] Combination of Heat ResourceGroup(index) with Fn::Select doesnt work ?
On Tue, Oct 21, 2014 at 4:43 PM, Hemanth Ravi
wrote:
>
>
> On Tue, Oct 21, 2014 at 12:32 PM, Zane Bitter wrote:
>
>> On 21/10/14 14:05, Subrahmanyam Ongole wrote:
>>
>>> Hi
>>>
>>> We are in fact using OS::Neutron::PoolMember resource. I guess
>>> ResourceGroup is the only iterative construct in Heat. Is the use case
>>> supported today? I think this is more than a simple usage question,
>>> hence
>>> posting it here. Thank you.
>>>
>>> Regards
>>> Subra
>>>
>>> On Tue, Oct 21, 2014 at 8:55 AM, Fox, Kevin M
>>> wrote:
>>>
>>>use a OS::Neutron::PoolMember instead. Then each member template can
>>>> add
>>>> itself to the pool.
>>>>
>>>> --
>>>> *From:* Magesh GV [magesh...@oneconvergence.com]
>>>> *Sent:* Tuesday, October 21, 2014 12:07 AM
>>>> *To:* openstack-dev@lists.openstack.org
>>>> *Subject:* [openstack-dev] Combination of Heat ResourceGroup(index) with
>>>> Fn::Select doesnt work ?
>>>>
>>>>I am trying to find a way of creating a dynamic List of
>>>> Resources(Loadbalancer PoolMembers to be exact) using Heat.
>>>>
>>>> The idea is that the number of PoolMembers and the required Addresses
>>>> would be received as Heat parameters.
>>>>
>>>> However, I am unable to get %index% working inside a Fn:Select block.
>>>>
>>>
>> Yeah, it doesn't work inside intrinsic functions.
>>
>>Is this a bug with Heat or am I doing something wrong ?
>>>>
>>>
>> It's arguable ;)
>>
>> If this is a
>>>> bug/limitation in heat is there some other way to get what I am trying
>>>> to
>>>> do working with heat ?
>>>>
>>>
>> You should define the PoolMember near the server it is linking to the
>> pool, not in a separate ResourceGroup. Group together the things you want
>> to scale as a group in a separate template and scale them as a unit.
>>
>>IMO this is a very important usecase for the %index%.
>>>>
>>>
>> I'm very uneasy about %index% existing at all, and I'm not at all
>> convinced that allowing something like this would achieve anything beyond
>> making bad template design more tempting.
>>
>> Can you talk more about why you need to define the PoolMember resources
>> in a different place to the actual pool members?
>>
>
> The use-case is to define a template for an LB service and customize it.
> The parameters i) number of members in the pool and ii) IP addr of each of
> these members are not known when the template is defined. When the service
> is instantiated using the template the code that generates the values for
> these params will pass these in as parameter values to heat.
>
The servers (to be configured as pool members) are instantiated outside the
heat template independently. The heat template is created only with the LB
service definition and needs to be customized for these parameters.
>
>>
>> cheers,
>> Zane.
>>
>>
>>"Parameters": {
>>>> "NumberOfMembers": {
>>>> "Description": "Number of Pool Members to be created",
>>>> "Type": "Number",
>>>> "Default": 1
>>>> },
>>>> "MembersList": {
>>>> "Description": "Pool Member IP Address",
>>>> "Type": "Json",
>>>> "Default": {"key0":"11.0.0.43"}
>>>> }
>>>> },
>>>>
>>>> "MemberList": {
>>>> "Type": "OS::Heat::ResourceGroup",
>>>> "Properties": {
>>>>"count": {"Ref":"NumberOfMembers"},
>>>>"resource_def": {
>>>> "type": "OS::Neutron::PoolMember",
>>>> "properties": {
>>>> "address": { "Fn::Select" : [ "key%index%", {"Ref":"MembersList"}] },
>>>> "admin_state_up": true,
>>>> "pool_id": {"Ref":"HaproxyPool"},
>>>> "protocol_port": "80",
>>>> "weight": 1
>>>> }
>>>> }
>>>>}
>>>> }
>>>>
>>>> Regards,
>>>> Magesh
>>>>
>>>
>>
>> ___
>> 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
Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron
Kyle, One Convergence CI has been fixed (setup issue) and is running without the failures for ~10 days now. Updated the etherpad. Thanks, -hemanth On Fri, Jul 11, 2014 at 4:50 PM, Fawad Khaliq wrote: > > On Fri, Jul 11, 2014 at 8:56 AM, Kyle Mestery > wrote: >> >> >>1. PLUMgrid >> 1. Not saving enough logs >> >> All Jenkins slaves were just updated to upload all required logs. > PLUMgrid CI should be good now. > >> >> >> > Thanks, > Fawad Khaliq > > > ___ > 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
Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy
Hi, Adding this CLI command seems to be a good way to provide support for the second model. This can be submitted as a new review patch to work through the approaches to implement this. I suggest the current CLI patch [1] be reviewed for the existing spec and completed. Ryan, would it possible for you to start a new review submit for the new command(s). Could you also provide any references for "profiled" API in IETF, CCITT. Thanks, -hemanth [1] https://review.openstack.org/#/c/104013 On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats wrote: > As promised in Monday's Neutron IRC minutes [1], this mail is a "trip down > memory lane" looking at the history of the > Neutron GP project.. The original GP google doc [2] included specifying > policy via both a produce/consume 1-group > approach and as a link between two groups. There was an email thread [3] > that discussed the relationship between > these models early on, but that discussion petered out and during a later > IRC meeting [4] the concept of contracts > were added, but without changing the basic use case requirements from the > original document. A followup meeting [5] > began the discussion of how to express the original model from the > contract data model but that discussion doesn't > appear to have been completed either. The PoC in Atlanta raised a set of > issues [6],[7] around the complexity of the > resulting PoC code. > > The good news is that having looked through the proposed GP code commits > (links to which can be found at [8) I > believe that folks that want to be able to specify policies via the > 2-group approach (and yes, I'm one of them) can have > that without changing the model encoded in those commits. Rather, it can > be done via the WiP CLI code commit by > providing a "profiled" API - this is a technique used by the IETF, CCITT, > etc. to allow a rich API to be consumed in > common ways. In this case, what I'm envisioning is something like > > neutron policy-apply [policy rule] [src group] [destination group] > > in this case, the CLI would perform the contract creation for the policy > rule, and assigning the proper produce/consume > edits to the specified source and destination groups. Note: this is in > addition to the CLI providing direct access to the > underlying data model. I believe that this is the simplest way to "bridge > the gap" and provide support to folks who want > to specify policy as something between two groups. > > Ryan Moats (regXboi) > > References: > [1] > http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt > [2] > https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit# > [3] > http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html > [4] > http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html > [5] > http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html > [6] > http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html > [7] > http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html > [8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy > > ___ > 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
Re: [openstack-dev] [Neutron] Group Based Policy and the way forward
Hi, I believe that the API has been reviewed well both for its usecases and correctness. And the blueprint has been approved after sufficient exposure of the API in the community. The best way to enable users to adopt GBP is to introduce this in Juno rather than as a project in StackForge. Just as in other APIs any evolutionary changes can be incorporated, going forward. OS development processes are being followed in the implementation to make sure that there is no negative impact on Neutron stability with the inclusion of GBP. Thanks, -hemanth On Mon, Aug 4, 2014 at 1:27 PM, Mark McClain wrote: > All- > > tl;dr > > * Group Based Policy API is the kind of experimentation we be should > attempting. > * Experiments should be able to fail fast. > * The master branch does not fail fast. > * StackForge is the proper home to conduct this experiment. > > > Why this email? > --- > Our community has been discussing and working on Group Based Policy (GBP) > for many months. I think the discussion has reached a point where we need > to openly discuss a few issues before moving forward. I recognize that > this discussion could create frustration for those who have invested > significant time and energy, but the reality is we need ensure we are > making decisions that benefit all members of our community (users, > operators, developers and vendors). > > Experimentation > > I like that as a community we are exploring alternate APIs. The process > of exploring via real user experimentation can produce valuable results. A > good experiment should be designed to fail fast to enable further trials > via rapid iteration. > > Merging large changes into the master branch is the exact opposite of > failing fast. > > The master branch deliberately favors small iterative changes over time. > Releasing a new version of the proposed API every six months limits our > ability to learn and make adjustments. > > In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs. > The results have been very mixed as operators either shy away from > testing/offering the API or embrace the API with the expectation that the > community will provide full API support and migration. In both cases, the > experiment fails because we either could not get the data we need or are > unable to make significant changes without accepting a non-trivial amount > of technical debt via migrations or draft API support. > > Next Steps > -- > Previously, the GPB subteam used a Github account to host the development, > but the workflows and tooling do not align with OpenStack's development > model. I’d like to see us create a group based policy project in > StackForge. StackForge will host the code and enable us to follow the same > open review and QA processes we use in the main project while we are > developing and testing the API. The infrastructure there will benefit us as > we will have a separate review velocity and can frequently publish > libraries to PyPI. From a technical perspective, the 13 new entities in > GPB [1] do not require any changes to internal Neutron data structures. > The docs[2] also suggest that an external plugin or service would work to > make it easier to speed development. > > End State > - > APIs require time to fully bake and right now it is too early to know the > final outcome. Using StackForge will allow the team to retain all of its > options including: merging the code into Neutron, adopting the repository > as sub-project of the Network Program, leaving the project in StackForge > project or learning that users want something completely different. I > would expect that we'll revisit the status of the repo during the L or M > cycles since the Kilo development cycle does not leave enough time to > experiment and iterate. > > > mark > > [1] > http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370 > [2] > https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078 > [3] > > ___ > 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
Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward
Hi, I agree that Option 1 would be best way to make the GBP API available to operators and to make forward progress with the API. Regards, -hemanth On Wed, Aug 6, 2014 at 5:04 PM, Ivar Lazzaro wrote: > Hi Pedro, > > I agree that having as much users/operators as possible using the API is > the winner option. > I think you should move this comment also in the main thread since it > looks that the Subject has been accidentally modified. > > Cheers, > Ivar. > > > On Thu, Aug 7, 2014 at 1:28 AM, Pedro Marques > wrote: > >> >> On Aug 6, 2014, at 3:56 PM, Armando M. wrote: >> >> >> On 6 August 2014 15:47, Kevin Benton wrote: >> >>> I think we should merge it and just prefix the API for now with >>> '/your_application_will_break_after_juno_if_you_use_this/' >>> >> >> And you make your call based and what pros and cons exactly, If I am ask? >> >> Let me start: >> >> Option 1: >> - pros >> - immediate delivery vehicle for consumption by operators >> >> >> Since our collective goal is to maximize the benefits for OpenStack >> users/operators, that seems to be the winner. >> >> - cons >> - code is burder from a number of standpoints (review, test, etc) >> >> >> Any piece of code is a burden. >> >> >> Option 2: >> - pros >> - enable a small set of Illuminati to iterate faster >> >> >> This is probably not intentional from your part ,but your choice of words >> make it seem that you are deriding the efforts of the team behind this >> effort. While i may disagree technically here and there with their current >> design, it seems to me that the effort in question is rather broad based in >> terms of support (from multiple different organizations) and that the team >> has put a non trivial effort in making the effort public. I don't think we >> can characterize the team either as a "secret group" or a "small set". >> >> Pedro. >> >> >> - cons >> - integration burden with other OpenStack projects (keystone, nova, >> neutron, etc) >> >> Cheers, >> Armando >> ___ >> 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 > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] HK Neutron Icehouse Design Meetings
Hi, Is there a schedule published for the Neutron Icehouse design meetings listed at http://summit.openstack.org/ Thanks, -hemanth ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
