Re: [openstack-dev] OpenStack Heat installation guide and Heat utilisation manual

This is good work. However, I would suggest you check with some deployment tools such as devstack to understand additional steps needed for configuring Heat. For example: http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/heat#n215 There you can see the role creation work and domain

Re: [openstack-dev] [nova] Manage multiple clusters using a single nova service

Hi, Sorry for taking such long time to chime in but these mails were sadly missed. Please see my inline comments below. My original concerns for the revert of the service were as follows: 1. What do we do about existing installation. This support was added at the end of Havana and it is in produc

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

I am one of the developers on the project, so I have a strong preference for option (1). I think a 3rd option is also possible, which offers a scale down version of GBP APIs. Contracts could be added in kilo. Provide EndPoints, EndPointGroups, Rules and Policies. This is the simpler approach sugge

Re: [openstack-dev] [git-review] Supporting development in local branches

On 08/06/2014 05:41 PM, Zane Bitter wrote: On 06/08/14 18:12, Yuriy Taraday wrote: 2. since hacking takes tremendous amount of time (you're doing a Cool >>Feature (tm), nothing less) you need to update some code from master, so >>you're just merging master in to your branch (i.e. using Git as yo

Re: [openstack-dev] [Neutron][Nova] API design and usability

On 7 August 2014 15:31, Christopher Yeoh wrote: > On Thu, 7 Aug 2014 11:58:43 +1200 > Robert Collins wrote: ... > At the moment when cleaning up we don't know if a port was autocreated > by Nova or was passed to us initially through the API. That seems like a very small patch to fix - record the

Re: [openstack-dev] Which program for Rally

I agree with Duncan and John here, I am not as old contributor in OpneStack as most of the people commenting here are, but I see we have done this right throughout the OpenStack lifecycle, at the start we only had Nova and we could have always said "hey lets have everything in Nova" but we went ahe

Re: [openstack-dev] [all] The future of the integrated release

On 08/06/2014 06:10 PM, Michael Still wrote: > > We also talked about tweaking the ratio of "tech debt" runways vs > 'feature" runways. So, perhaps every second release is focussed on > burning down tech debt and stability, whilst the others are focussed > on adding features. I would suggest if

[openstack-dev] [Octavia] Minutes from 8/6/2014 meeting

Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Octavia Constitution and Project Direction Documents (Road map) a) Constitution and Road map will potentially be adopted after another couple days; providing those who were busy more time to review

[openstack-dev] [Ironic] Exceptional approval request for Cisco Driver Blueprint

Hi, I've submitted Ironic Cisco driver blueprint post proposal freeze date. This driver is critical for Cisco and few customers to test as part of their private cloud expansion. The driver implementation is ready along with unit-tests. Will submit the code for review once blueprint is accepted. T

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

Apologies for the late notice... The Neutron L3 Subteam will meet tomorrow at the regular time in #openstack-meeting-3. The agenda [1] is posted, please update as needed. Carl [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda ___

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

+1 I believe Pedro has a very valid point here, and that is the "the community to approve the spec and that decision should be respected". It makes sense to again clearly denote the "process and governance" and have this noted on the thread Stefano started earlier today. /Alan -Original M

Re: [openstack-dev] [Neutron][Nova] API design and usability

On Thu, 7 Aug 2014 11:58:43 +1200 Robert Collins wrote: > On 6 August 2014 22:23, Christopher Yeoh wrote: > > > > On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen > > wrote: > >> > >> > >> > >> > >> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton > >> wrote: > >>> > >>> > >>> > >>> From: Aaron Rosen

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and theway forward

Its good to see such a lively debate about this topic. With the disclaimer of someone who has worked on this project, I have a strong preference towards Option 1 as well (ie. merging it in the tree). We’ve actually already heard from users on this thread who want to use this([1] and [2]), others

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

When is the plan to move the meeting to IRC? On Wed, 2014-08-06 at 15:30 -0700, Stephen Balukoff wrote: > Action items from today's Octavia meeting: > > > 1. We're going to hold off for a couple days on merging the > constitution and preliminary road map to give people (and in > particular Ebay)

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Do you not see a difference between explicitly configuring networks, a router and FWaaS rules with logging and just stating that two groups of servers can only communicate via one TCP port with all connections logged? The first is very prone to errors for someone deploying an application without a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

I don't think people are choosing because of the shortest route but rather these may be two different items that are not completely exclusive but different enough. Nova parity addresses the scope to have existing well understood and stable api currently supported in nova to be supported in neutron

Re: [openstack-dev] Well-tested guides for OpenStack Icehouse installation and Instance creation with Neutron

Nice work. Suggest add some watch points/problem solution/diagnosis in the installations. Btw, recently we find both the RDO and devstack are very unstable for installation, wish there will be more test and improvements soon. On Wed, Aug 6, 2014 at 3:27 AM, chayma ghribi wrote: > > Hi all, > >

Re: [openstack-dev] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

Nice work Sukhdev, worth commending! Thanks for sharing!! On Wed, Aug 6, 2014 at 7:06 PM, Baohua Yang wrote: > Woo~ > Really nice work! > > > On Thu, Aug 7, 2014 at 7:09 AM, Sukhdev Kapur > wrote: >> >> Folks, >> >> Just wanted to share with you that Arista CI has been up and running 24x7 >> sin

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 6:40 PM, Aaron Rosen wrote: > > On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton wrote: > >> Web tier can communicate with anything except for the DB. >> App tier can only communicate with Web and DB. >> DB can communicate with App. >> >> These high-level constraints can then

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

+1. And the review process should be more efficient! On Thu, Aug 7, 2014 at 3:07 AM, Stefano Maffulli wrote: > On 08/06/2014 11:19 AM, Edgar Magana wrote: > > That is the beauty of the open source projects, there is always a > smartest > > reviewer catching out the facts that you don¹t. > > An

Re: [openstack-dev] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

Woo~ Really nice work! On Thu, Aug 7, 2014 at 7:09 AM, Sukhdev Kapur wrote: > Folks, > > Just wanted to share with you that Arista CI has been up and running 24x7 > since the beginning of this year with no down time. > > This morning it posted a vote on 10,000th Neutron patch > > cheers.. >

Re: [openstack-dev] [OpenStack-Infra] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

Thanks Salvatore. I originally started with all tests and then started to back off to come up with a set of tests which gave good stable results. Otherwise I was getting 65% - 80% pass rates. And, when a test fails, I will go back and triage it only to realize that running that test did not really

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton wrote: > Web tier can communicate with anything except for the DB. > App tier can only communicate with Web and DB. > DB can communicate with App. > > These high-level constraints can then be implemented as security groups > like you showed, or network

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

>I think this could be another reason why people associated GBP and nova-network parity in this thread: the fact that new abstractions are introduced without solidifying the foundations of the project is a risk to GBP as well as Neutron itself. How does a separate project fix this? It seems to me

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On 6 August 2014 17:34, Prasad Vellanki wrote: > It seems like Option 1 would be preferable. User can use this right away. > > People choosing Option 1 may think that the shortest route may be the best, that said the drawback I identified is not to be dismissed either (and I am sure there many m

Re: [openstack-dev] Which program for Rally

From a user’s aspect i do think Rally is more suitable for a product-ready cloud, and seems like it is where it focused on. It’s very easy to evaluate that if the performance of the cloud is better after we adjust some configs or some other tuning. It also provides SLA which maybe not so powerf

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Hi, Thanks to Armando for steering the discussion back to the original intent. On Wed, 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

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

I definitely agree that such cross-pollination across projects is ideal. However, I think (and not to deviate from the general discussion on making blueprint specs review more effective), Kevin's question was specifically in the context of the GBP blueprint. It is not clear in that case that a Nov

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

I agreed with Jay. Nova is one of the consumer of Neutron project, someone from Nova project should participate reviewing related blueprint in neutron project. Richard On Wed, Aug 6, 2014 at 8:28 PM, Jay Pipes wrote: > On 08/06/2014 07:54 PM, Kevin Benton wrote: > >> I'm curious, how would hav

Re: [openstack-dev] [all] The future of the integrated release

On Thu, Aug 7, 2014 at 10:05 AM, Stefano Maffulli wrote: > On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote: >> - we rate limit the total number of blueprints under code review at >> any one time to a fixed number of "slots". I secretly prefer the term >> "runway", so I am going to use tha

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

It seems like Option 1 would be preferable. User can use this right away. The code and to a large extent BP has gone through quite a bit of review already so it seems to me that there actually going lot less than usual. I dont see a whole of lot Con on this. Though there are still some issues wit

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

On 08/06/2014 07:54 PM, Kevin Benton wrote: I'm curious, how would having Nova reviewers look at this have helped? As I mentioned on a previous email, Nova is the pre-eminent consumer of Neutron's API. Best, -jay On Wed, Aug 6, 2014 at 5:41 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Web tier can communicate with anything except for the DB. App tier can only communicate with Web and DB. DB can communicate with App. These high-level constraints can then be implemented as security groups like you showed, or network hardware ACLs like I had shown. But if you start with the securi

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

Re: [openstack-dev] [Neutron][LBaaS] Weekly IRC Agenda

You should be able to, if logged into launchpad. I edited it for you. Doug On 8/6/14, 6:07 PM, "Vijay Venkatachalam" wrote: >I couldn't edit the wiki. Want to add 2 items >1. Separating deployment and operational status. >2. Can driver interface be called for every API request? > Ex. It

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

I prefer merged because moving it to a separate project blocks it from enforcing policy on the current API (including calls between service plugins). On Wed, Aug 6, 2014 at 4:56 PM, Armando M. wrote: > > On 6 August 2014 15:47, Kevin Benton wrote: > >> I think we should merge it and just prefi

Re: [openstack-dev] How to improve the specs review process

On 08/06/2014 04:54 PM, Kevin Benton wrote: > I'm curious, how would having Nova reviewers look at this have helped? In general, we should try to involve users in all spec reviews. With Nova being a (heavy) user of Neutron, I think, in general, having Nova people involved would help. In general.

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On 08/06/2014 04:57 PM, Aaron Rosen wrote: > Gah, clearly hitting some kind of gmail bug as i replied to the right > thread all 3 times i believe. gmail is the new Outlook ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.op

Re: [openstack-dev] [Neutron][LBaaS] Weekly IRC Agenda

I couldn't edit the wiki. Want to add 2 items 1. Separating deployment and operational status. 2. Can driver interface be called for every API request? Ex. It is not called for create pool. Sent using CloudMagic On Thu, Aug 07,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton wrote: > That's the point. By using security groups, you are forcing a certain kind > of enforcement that must be honored and might not be necessary if the > original intent was just to isolate between groups. In the example you > gave, it cannot be im

Re: [openstack-dev] [all] The future of the integrated release

On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote: > - we rate limit the total number of blueprints under code review at > any one time to a fixed number of "slots". I secretly prefer the term > "runway", so I am going to use that for the rest of this email. A > suggested initial number of r

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

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:

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

+1 On Aug 6, 2014 7:07 PM, "Salvatore Orlando" wrote: > I was asked beforehand what I mean with > > * consider GBP an 'experimental' V3 tenant API (this was mentioned > somewhere in this thread) and treat it accordingly > > The group based policies, although implemented as a service plugin, are >

[openstack-dev] [Neutron][Nova] API design and usability

On 6 August 2014 22:23, Christopher Yeoh wrote: > > On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen wrote: >> >> >> >> >> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton wrote: >>> >>> >>> >>> From: Aaron Rosen >>> Reply-To: OpenStack List >>> Date: Wednesday, August 6, 2014 at 10:09 AM >>> >>> To: O

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Gah, clearly hitting some kind of gmail bug as i replied to the right thread all 3 times i believe. On Wed, Aug 6, 2014 at 4:56 PM, Aaron Rosen wrote: > [Moving my reply to the correct thread as someone changed the subject > line. Attempt 3 :'( ] > > > > On Wed, Aug 6, 2014 at 4:18 PM, Kevin Be

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Moving my reply to the correct thread as someone changed the subject line. Attempt 3 :'( ] On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton wrote: > >Given this information I don't see any reason why the backend system > couldn't do enforcement at the logical router and if it did so neither > par

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

I'm curious, how would having Nova reviewers look at this have helped? On Wed, Aug 6, 2014 at 5:41 PM, Jay Pipes wrote: > On 08/06/2014 07:08 PM, CARVER, PAUL wrote: > >> On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi > m...@us.ibm.com>> >> wrote: >> >> Yes, indeed. >>> I do not want to be

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Moving my reply to the correct thread as someone changed the subject line. Attempt 2 :) ] On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton wrote: > >Given this information I don't see any reason why the backend system > couldn't do enforcement at the logical router and if it did so neither > parti

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Moving my reply to the correct thread as someone changed the subject line.] On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton wrote: > >Given this information I don't see any reason why the backend system > couldn't do enforcement at the logical router and if it did so neither > parties would know.

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

That's the point. By using security groups, you are forcing a certain kind of enforcement that must be honored and might not be necessary if the original intent was just to isolate between groups. In the example you gave, it cannot be implemented on the router without violating the constraints of t

Re: [openstack-dev] [git-review] Supporting development in local branches

On 06/08/14 18:12, Yuriy Taraday wrote: 2. since hacking takes tremendous amount of time (you're doing a Cool >>Feature (tm), nothing less) you need to update some code from master, so >>you're just merging master in to your branch (i.e. using Git as you'd >>use it normally); >> > >This is not h

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

On 08/06/2014 07:08 PM, CARVER, PAUL wrote: On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi mailto:m...@us.ibm.com>> wrote: Yes, indeed. I do not want to be over dramatic but the discussion on the original "Group Based Policy and the way forward" thread is nothing short of heartbreaking. Aft

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

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

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton wrote: > >Given this information I don't see any reason why the backend system > couldn't do enforcement at the logical router and if it did so neither > parties would know. > > With security groups you are specifying that nothing can contact these > d

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

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

Re: [openstack-dev] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

Congratulations! And to celebrate this milestone, I would consider running something more than ~280 api tests... perhaps also a few scenario tests? Salvatore On 7 August 2014 01:09, Sukhdev Kapur wrote: > Folks, > > Just wanted to share with you that Arista CI has been up and running 24x7 > si

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

>Given this information I don't see any reason why the backend system couldn't do enforcement at the logical router and if it did so neither parties would know. With security groups you are specifying that nothing can contact these devices on those ports unless they come from the allowed IP addres

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

On Aug 5, 2014, at 4:52 PM, Joshua Harlow wrote: > I'm pretty sure yahoo is another case, with a large set of clusters on > nova-network still ;) > > I believe we have been active in these discussions, although I'm unsure what > was discussed at the meetup (being that I had planned vacation,

[openstack-dev] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

Folks, Just wanted to share with you that Arista CI has been up and running 24x7 since the beginning of this year with no down time. This morning it posted a vote on 10,000th Neutron patch cheers.. -Sukhdev ___ OpenStack-dev mailing list OpenStack-

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi mailto:m...@us.ibm.com>> wrote: >Yes, indeed. >I do not want to be over dramatic but the discussion on the original "Group >Based Policy and the way forward" thread is nothing short of heartbreaking. >After months and months of discussions, three p

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

I was asked beforehand what I mean with * consider GBP an 'experimental' V3 tenant API (this was mentioned somewhere in this thread) and treat it accordingly The group based policies, although implemented as a service plugin, are quite different from the ones we have now. Things like firewall, lo

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton wrote: > By working at the port level you have already eliminated your ability to > implement the filtering at different components of the network. They now > need to be implemented in stateful rules at the port level and the device > has to support se

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Ivar, You are totally right. I just want to clarify that I haven’t express any disagreement on the plugin, I actually (as Sumit mentioned) +2 this patch before. I just pointed our that I have expressed previously that GBP should use the standard Policy Terminology. I did not push hard enough at

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

I would reword that to: '/your_application_may_break_after_juno_if_you_use_this/' in the event of the possibility that it doesn't break. ;-) On Wed, Aug 6, 2014 at 3:47 PM, Kevin Benton wrote: > I think we should merge it and just prefix the API for now with > '/your_application_will_break_afte

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

I think we should merge it and just prefix the API for now with '/your_application_will_break_after_juno_if_you_use_this/' On Aug 6, 2014 4:41 PM, "Armando M." wrote: > This thread is moving so fast I can't keep up! > > The fact that troubles me is that I am unable to grasp how we move > forward

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

This thread is moving so fast I can't keep up! The fact that troubles me is that I am unable to grasp how we move forward, which was the point of this thread to start with. It seems we have 2 options: - We make GBP to merge as is, in the Neutron tree, with some minor revision (e.g. naming?); - We

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

By working at the port level you have already eliminated your ability to implement the filtering at different components of the network. They now need to be implemented in stateful rules at the port level and the device has to support security groups. On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen

Re: [openstack-dev] [git-review] Supporting development in local branches

Oh, looks like we got a bit of a race condition in messages. I hope you don't mind. On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec wrote: > On 08/06/2014 01:42 PM, Yuriy Taraday wrote: > > On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec > wrote: > > > >> On 08/06/2014 03:35 AM, Yuriy Taraday wrote: > >>

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

Action items from today's Octavia meeting: 1. We're going to hold off for a couple days on merging the constitution and preliminary road map to give people (and in particular Ebay) a chance to review and comment. 2. Stephen is going to try to get Octavia v0.5 design docs into gerrit review by the

[openstack-dev] [Neutron][LBaaS] Weekly IRC Agenda

Hey LBaaS folks, This is you friendly reminder to provide any agenda items for tomorrow's weekly IRC meeting. Please add them to the agenda wiki ==> https://wiki.openstack.org/wiki/Network/LBaaS#Agenda. The agenda currently has these items: * Review Updates Cheers, --Jorge P.S. Also, ple

Re: [openstack-dev] [git-review] Supporting development in local branches

I'll start using pictures now, so let's assume M is the latest commit on the master. On Wed, Aug 6, 2014 at 9:31 PM, Zane Bitter wrote: > On 04/08/14 19:18, Yuriy Taraday wrote: > >> Hello, git-review users! >> >> I'd like to gather feedback on a feature I want to implement that might >> turn ou

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote: > >I believe the referential security group rules solve this problem > (unless I'm not understanding): > > I think the disconnect is that you are comparing the way to current > mapping driver implements things for the reference implementation w

[openstack-dev] Win The Enterprise Work Group Update

I want to provide the community an update on the Win The Enterprise work group that came together in a BoF session in Atlanta. The work group led a discussion with the OpenStack Board at their 7/22 meeting on the findings of our analysis of Enterprise IT requirements gaps. A summary of the pres

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

+1 Kevin. I really fail to see how a patch which has been ready for a long time now is the worst enemy of Nova Parity. This is starting to feel kind of ad-hoc... On Aug 6, 2014 11:42 PM, "Kevin Benton" wrote: > >In all seriousness, folks, I'm bringing up points about the proposed API > because I

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Edgar, Actually, As Pedro said, I think that the time for discussing these kind of concerns was the BP approval. The fact that it has been approved after many proposals and reviews means that a community effort wanted the GBP to be implemented in this release cycle the way it was presented at that

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

+1, I think in future we should invite the other project(i.e. Nova) core member to review the blueprint if it is related to that specific project. On Wed, Aug 6, 2014 at 5:01 PM, Mohammad Banikazemi wrote: > Yes, indeed. > I do not want to be over dramatic but the discussion on the original

Re: [openstack-dev] Which program for Rally

I have to agree with Duncan here. I also don't know if I fully understand the limit in options. Stress test seems like it could/should be different (again overlap isn't a horrible thing) and I don't see it as siphoning off resources so not sure of the issue. We've become quite wrapped up in proj

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

+1 Mohammad. On Aug 6, 2014 11:08 PM, "Mohammad Banikazemi" wrote: > Yes, indeed. > I do not want to be over dramatic but the discussion on the original "Group > Based Policy and the way forward" thread is nothing short of heartbreaking. > After months and months of discussions, three presentatio

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

>In all seriousness, folks, I'm bringing up points about the proposed API because I see the current mess of Neutron integration with Nova, I see that nova-network has been "undeprecated" due to continuing lack of parity and HA concerns in Neutron, and I want things to be better, not worse. Again,

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

Given how this discussion has gone, I understand Mohammad's despair. But it seems like people are treating the Stackforge proposal as really nothing more than a black hole. I'm a relative newcomer to this community, so that's probably why I took Mark at his word when he presented it as a way t

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On 08/06/2014 04:51 PM, Pedro Marques wrote: Neutron allows vendors to speak to proprietary device APIs, it was designed to do so, AFAIK. It is also possibly to "entirely swap out all of the Neutron core"... the proponents of the group based policy didn't have to go through so much trouble if tha

Re: [openstack-dev] [all] The future of the integrated release

On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez wrote: > We seem to be unable to address some key issues in the software we > produce, and part of it is due to strategic contributors (and core > reviewers) being overwhelmed just trying to stay afloat of what's > happening. For such projects, is it

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

I also am in favor of this. +1 Chris Krelle On Wed, Aug 6, 2014 at 9:04 AM, Jay Faulkner wrote: > Similarly, I appreciated this idea when we discussed it at the mid-cycle > and doing so here. > > +1 > > -Jay Faulkner > > > From: Lucas Alvares Gomes > S

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[snipping to save BW] Aaron Rosen wrote on 08/06/2014 03:26:24 PM: > Note: I'm not going to use the pure group policy API as I have been > a fan of the > 2-group approach from day 1, I'm going to use the commands as stated > in the patch set, and I'm going to assume (dangerous I know) that I >

Re: [openstack-dev] [git-review] Supporting development in local branches

On 08/06/2014 01:14 PM, Yuriy Taraday wrote: On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec mailto:openst...@nemebean.com>> wrote: Again, this is why the tests should pass against all of your commits. If that's the case, you can verify your changes as you rebase before you update the c

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

Yes, indeed. I do not want to be over dramatic but the discussion on the original "Group Based Policy and the way forward" thread is nothing short of heartbreaking. After months and months of discussions, three presentations at the past three summits, a design session at the last summit, and (most

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On 08/06/2014 04:51 PM, Prasad Vellanki wrote: Jay Doesnt the current plugin model in neutron work the way you are saying. We have a a core set of APIs that there is a reference model for and individual vendors have substituted plugins that enhance and sometimes replace networking component. GBP

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 1:52 PM, Jay Pipes wrote: > On 08/06/2014 04:36 PM, Sumit Naiksatam wrote: >> >> On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes wrote: >>> >>> On 08/06/2014 04:13 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote: >> >> >>

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

Maybe we should change how we wait? I get that we don't want to sit around forever, but perhaps we should specify a total maximum time to wait instead of a number of iterations of a loop? Something like "15 minutes should be long enough for anyone!". Eventlet sleeps are also pretty cheap, so havin

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Ivar, Of course and this is why we are having this conversation, in order to merge our different opinions. Edgar From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On 08/06/2014 04:36 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes wrote: On 08/06/2014 04:13 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote: I believe the referential security group rules solve this problem (unless I'm not understandin

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Jay Doesnt the current plugin model in neutron work the way you are saying. We have a a core set of APIs that there is a reference model for and individual vendors have substituted plugins that enhance and sometimes replace networking component. GBP in that respect does not change. There is a refer

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Aug 6, 2014, at 1:27 PM, Jay Pipes wrote: > > However, it seems to me that the end-goal of the GBP effort is *actually* to > provide a higher-layer API to Neutron that would essentially enable > proprietary vendors to entirely swap out all of Neutron core for a new set of > drivers that sp

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

On Wed 06 Aug 2014 01:21:26 PM PDT, Eugene Nikanorov wrote: > So I don't think it's fair to blame reviewers here. Just want to be super clear: there is no 'blaming' here. This is a request to regroup and look at why we are having this conversation about GBP now, this late in cycle, and about such

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Edgar, Actually, I think that other reviewers saw that name clash, and still thought it was ok to use the same terminology in such a different context. BP reviews are a community effort right? So of course someones' idea may be different from yours. Regards, Ivar. On Wed, Aug 6, 2014 at 10:2

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes wrote: > On 08/06/2014 04:13 PM, Sumit Naiksatam wrote: >> >> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote: I believe the referential security group rules solve this problem (unless I'm not understanding): >>> >>> >>> I think th

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Vendors swapping out components is only one possibility. Once people use this declarative model, optimizations can be made on the reference side as well. ACLs can be placed on L3 agents to reduce the rule count on individual compute nodes, etc. Everyone benefits from the abstraction, not just hardw

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Jay Pipes wrote on 08/06/2014 04:09:20 PM: > From: Jay Pipes > To: openstack-dev@lists.openstack.org > Date: 08/06/2014 04:12 PM > Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy > and the way forward > > On 08/06/2014 03:46 PM, Kevin Benton wrote: > > >I believe the refer

[openstack-dev] [Ironic] call for operator-focused docs

Hi all! Short version: if you have operational knowledge setting up Ironic (either the Icehouse release or current trunk), you can help out a lot right now by sharing that knowledge. Long version... I've seen an influx of folks interested in deploying Ironic over the past few months, which is fa

  1   2   3   >