Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 15 September 2015 at 08:27, Mike Spreitzer wrote: > Monty Taylor wrote on 09/15/2015 11:04:07 AM: > > > a) an update to python-novaclient to allow a named network to be passed > > to satisfy the "you have more than one network" - the nics argument

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 15 September 2015 at 11:28, Matt Riedemann wrote: > > > On 9/15/2015 10:27 AM, Mike Spreitzer wrote: > >> Monty Taylor wrote on 09/15/2015 11:04:07 AM: >> >> > a) an update to python-novaclient to allow a named network to be passed >> > to

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 15 September 2015 at 10:02, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700: > > On 15 September 2015 at 08:04, Monty Taylor <mord...@inaugust.com> > wrote: > > > > > Hey all! > >

Re: [openstack-dev] [neutron] PTL Non-Candidacy

On 12 September 2015 at 18:38, Gary Kotton wrote: > Thanks! You did a great job. Looking back you made some very tough and > healthy decisions. Neutron has a new lease on life! > It is tradition that the exiting PTL buy drinks for the community :) > Ok, none of these kind

Re: [openstack-dev] [neutron] RFE process question

On 10 September 2015 at 11:04, James Dempsey wrote: > Greetings Devs, > > I'm very excited about the new RFE process and thought I'd test it by > requesting a feature that is very often requested by my users[1]. > > There are some great docs out there about how to submit

Re: [openstack-dev] [docs][networking-sfc]

On 4 September 2015 at 15:33, Paul Carver wrote: > > Can someone from the Docs team take a look at why there isn't a docs URL > for the networking-sfc repo? > Everything in OpenStack is code driven. And doc publishing happens through code review as much as anything else.

Re: [openstack-dev] [neutron] pushing changes through the gate

On 2 September 2015 at 09:40, Armando M. <arma...@gmail.com> wrote: > Hi, > > By now you may have seen that I have taken out your change from the gate > and given it a -2: don't despair! I am only doing it to give priority to > the stuff that needs to merge in order to get [

Re: [openstack-dev] [neutron] pushing changes through the gate

be merged during RC. Some other blueprints are best completed during feature freeze, because of the rebase risk they cause... Bottom line: never leave it to last minute! > Thanks, > Hirofumi > > On 2015/09/04, at 7:00, Armando M. <arma...@gmail.com> wrote: > > > > On

[openstack-dev] [neutron] pushing changes through the gate

Hi, By now you may have seen that I have taken out your change from the gate and given it a -2: don't despair! I am only doing it to give priority to the stuff that needs to merge in order to get [1] into a much better shape. If you have an important fix, please target it for RC1 or talk to me

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

like a breaking update like this always > comes around the end of a cycle or a feature freeze? > You missed 'weekends' :) Not that it is any consolation, at least there are always a few brave individuals that step in to the fire! > > Carl > > On Sun, Aug 30, 2015 at 9:54 PM, Arm

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On 31 August 2015 at 09:53, Jeremy Stanley wrote: > On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: > > I was under the impression that we had a plan to stop allowing these > > external updates break our gate jobs. > [...] > > We do, and it succeeded in protecting

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 31 August 2015 at 06:18, Ihar Hrachyshka wrote: > Hi all, > > I see neutron folks pushing more neutron patches into the gate. They are > all doomed to fail until [1] is resolved. So please stop approving patches, > we only make harm by resetting the gate, with no chance

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 31 August 2015 at 10:44, Edgar Magana <edgar.mag...@workday.com> wrote: > Yeah!! > Well don't get so excited, the check queue is hovering over the 200 mark, so. > > From: "Armando M." > Reply-To: "OpenStack Development Mailing List (not for usage q

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

On 31 August 2015 at 11:41, Armando M. <arma...@gmail.com> wrote: > > On 31 August 2015 at 10:44, Edgar Magana <edgar.mag...@workday.com> wrote: > >> Yeah!! >> > > Well don't get so excited, the check queue is hovering over the 200 mark, > so. > &

[openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

Hi, If you wonder why hell broke loose, [1] will have the answer to your questions. Armando [1] https://bugs.launchpad.net/neutron/+bug/1490380 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

Is this an example of +1+1=3? On 12 August 2015 at 07:51, Doug Wiegley doug...@parksidesoftware.com wrote: A big +1 to both!! Doug On Aug 12, 2015, at 6:45 AM, Kyle Mestery mest...@mestery.com wrote: It gives me great pleasure to propose Russell Bryant and Brandon Logan as core

Re: [openstack-dev] [neutron] till when must code land to make it in liberty

On 31 July 2015 at 20:33, Paul Carver pcar...@paulcarver.us wrote: On 7/31/2015 9:47 AM, Kyle Mestery wrote: However, it's reasonable to assume the later you propose your RFE bug, the less of a chance it has of making it. We do enforce the Feature Freeze [2], which is the week of August 31

Re: [openstack-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

On 29 July 2015 at 22:42, Anita Kuno ante...@anteaya.info wrote: On 07/29/2015 02:37 PM, Armando M. wrote: Hi, Since I was quoted, I would like to take the blame on behalf on the Neutron core reviewer/drivers team for not providing the right guidance to resolve the apparent conflict

Re: [openstack-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

Hi, Since I was quoted, I would like to take the blame on behalf on the Neutron core reviewer/drivers team for not providing the right guidance to resolve the apparent conflict between the two proposals. As some reviewers mentioned, we should really strive to catch two birds with one stone, and

Re: [openstack-dev] [neutron] why do we gate tempest using q-vpn not q-l3?

On 23 July 2015 at 05:25, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, I've stumbled on this one. It turns out we gate neutron against openstack installation that runs vpn-agent instead of l3-agent [1]. Is it really what we want to do?

Re: [openstack-dev] [oslo][neutron] oslo.policy: policy_dirs config option, why deprecated?

On 7 July 2015 at 11:56, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Ben Nemec's message of 2015-07-07 11:41:35 -0500: On 07/04/2015 12:12 AM, Akihiro Motoki wrote: Hi Oslo and Neutron folks, Why is policy_dirs option deprecated in oslo.policy? In Neutron we have

Re: [openstack-dev] [Neutron] adding new vendor driver to upstream

On 10 July 2015 at 16:01, Vadivel Poonathan vadivel.openst...@gmail.com wrote: Hi, I have a Neutron plugin (actually a mechanism_driver under ML2) developed for Alcatel-Lucent Omniswitches and is currently being used. But it is not part of Neutron upstream, nor listed in the docs/wiki

Re: [openstack-dev] [grenade] future direction on partial upgrade support

On 6 July 2015 at 13:13, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-06 11:54:45 -0700 (-0700), Armando M. wrote: [...] For what I can tell, Joe was kind to set the infra to start gathering data on the reliability of the multi-node jobs, but they are clearly flaky [1

Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team

O(1) (some of computational complexities achieved after Miguel optimizations) On 6 July 2015 at 09:24, Carl Baldwin c...@ecbaldwin.net wrote: +1! On Mon, Jul 6, 2015 at 4:02 AM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I am

Re: [openstack-dev] [oslo][neutron] oslo.policy: policy_dirs config option, why deprecated?

Hi, When reading [1], it seems that Doug is implying there will be the ability to collate multiple policy.json files together? It would be good to get this point clarified. Thanks, Armando [1] https://bugs.launchpad.net/oslo.policy/+bug/1428332 On 3 July 2015 at 22:12, Akihiro Motoki

Re: [openstack-dev] [grenade] future direction on partial upgrade support

Hi, Not sure if we reached any conclusion with this thread, and I would like to resume it so that we don't derail the initial plan set forth by Russell and agreed during the Liberty summit, among other things. If I look at the thread I think this can be summarized as follow. Please correct me if

Re: [openstack-dev] [grenade] future direction on partial upgrade support

Thanks Sean, comments inline. On 6 July 2015 at 16:58, Sean M. Collins s...@coreitpro.com wrote: I'd also like to chime in - we've had some discussions on -infra today about the partial upgrade issue, and collected the following notes on an etherpad.

Re: [openstack-dev] [Neutron] Issue with pymysql

Hi, A brief update on the issue that sparked this thread: A little over a week ago, bug [1] was filed. The gist of that was that the switch to pymysql unveiled a number of latent race conditions that made Neutron unstable. To try and nip these in the bud, the Neutron team filed a number of

Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining

On 18 June 2015 at 09:54, Jay Pipes jaypi...@gmail.com wrote: On 06/18/2015 12:46 PM, Armando M. wrote: On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your

Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining

On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its

[openstack-dev] [neutron] [networking-sfc] Project repo setup and ready to roll

Hi, The infrastructure jobs are completed. The project repository [1] has been provisioned, and it is ready to go. Spec [2] is being moved to the new repo, with patch [3]. Any documentation/specification effort that pertains, and/or is solely focused on SFC, should target the new repo from now

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 16 June 2015 at 22:36, Sam Morrison sorri...@gmail.com wrote: On 17 Jun 2015, at 10:56 am, Armando M. arma...@gmail.com wrote: On 16 June 2015 at 17:31, Sam Morrison sorri...@gmail.com wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 16 June 2015 at 17:31, Sam Morrison sorri...@gmail.com wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want. We have 10 “public networks and 10 “service networks and depending on which compute node you land on you get attached to

Re: [openstack-dev] [Openstack] What code structure is recommended for a Neutron plugin( L2 and L3)?

On 15 June 2015 at 19:34, Sam Su susltd...@gmail.com wrote: Hi stackers, I am going to implement a Neutron plugin, however when I checked the current Neutron code(master) structure, I found there are two way to organize a Neutron plugin: 1. The first one is implement all L2 and L3

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

+1 On 12 June 2015 at 13:49, Edgar Magana edgar.mag...@workday.com wrote: Excellent news! +1 Cheers, Edgar On Jun 12, 2015, at 12:50 PM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I would like Rossella Sblendido to be a

Re: [openstack-dev] [Neutron] Issue with pymysql

This is exactly what I did in [1]. Cheers, Armando [1] https://review.openstack.org/#/q/status:open+branch:master+topic:neutron-unstable,n,z On 12 June 2015 at 09:00, Clint Byrum cl...@fewbar.com wrote: Excerpts from Chris Dent's message of 2015-06-12 03:47:02 -0700: On Fri, 12 Jun 2015,

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

+1 On 11 June 2015 at 12:42, Carl Baldwin c...@ecbaldwin.net wrote: +1 On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton blak...@gmail.com wrote: Hello all! As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO Takashi to be a member of the control plane core reviewer

Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team

+1 On 11 June 2015 at 09:27, Carl Baldwin c...@ecbaldwin.net wrote: +1! On Thu, Jun 11, 2015 at 8:34 AM, Henry Gessau ges...@cisco.com wrote: As one of the Lieutenants [1] for the API and DB areas under the PTL, I would like to propose Ann Kamyshnikova as a member of the Neutron API and

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

Interestingly, [1] was filed a few moments ago: [1] https://bugs.launchpad.net/neutron/+bug/1463129 On 2 June 2015 at 22:48, Salvatore Orlando sorla...@nicira.com wrote: I'm not sure if you can test this behaviour on your own because it requires the VMware plugin and the eventlet handling of

[openstack-dev] [Neutron] Missing allowed address pairs?

You have better chances of getting an answer if you asked the -dev list and add [Neutron] to the subject (done here). That said, can you tell us a bit more about your deployment? You can also hop on #openstack-neutron on Freenode to look for neutron developers who can help you more interactively.

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

On 4 June 2015 at 14:17, Cathy Zhang cathy.h.zh...@huawei.com wrote: Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page.

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

/#/c/177946/ Thanks Vikram On Fri, Jun 5, 2015 at 6:36 AM, Armando M. arma...@gmail.com wrote: On 4 June 2015 at 14:17, Cathy Zhang cathy.h.zh...@huawei.com wrote: Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting

Re: [openstack-dev] [neutron] Impressions from Vancouver Neutron Design Summits

On 28 May 2015 at 03:09, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've heard that other projects come up with actual action lists and work assignments. I've heard Nova, Ironic, Oslo do it, and I witnessed just that in those Oslo sessions I

Re: [openstack-dev] [Neutron][DB] neutron DB migration scripts

On 25 May 2015 at 08:23, Mike Bayer mba...@redhat.com wrote: On 5/25/15 10:24 AM, Henry Gessau wrote: Yes, unfortunately the autogenerate currently generates commands to drop all the FWaaS, LBaaS and VPNaaS tables since their models are not in the neutron tree. You can and should delete

Re: [openstack-dev] [Neutron][DB] neutron DB migration scripts

On 25 May 2015 at 09:46, Mike Bayer mba...@redhat.com wrote: On 5/25/15 12:34 PM, Armando M. wrote: One thing I would like to point out is that in this cycle we'll be working extensively in this area to make the very task you are working on easier to deal with, and better documented

Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

On 21 May 2015 at 09:58, Kyle Mestery mest...@mestery.com wrote: On Thu, May 21, 2015 at 9:51 AM, Doug Wiegley doug...@parksidesoftware.com wrote: On May 21, 2015, at 9:14 AM, Armando M. arma...@gmail.com wrote: On 21 May 2015 at 08:58, Salvatore Orlando sorla...@nicira.com wrote

Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

On 21 May 2015 at 08:58, Salvatore Orlando sorla...@nicira.com wrote: After putting the whole OpenStack networking contributors community through almost 8 cycles of pedant comments and annoying what if questions, it is probably time for me to relieve neutron contributors from this burden.

Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

On 28 April 2015 at 05:52, Russell Bryant rbry...@redhat.com wrote: On 04/28/2015 06:25 AM, Rossella Sblendido wrote: On 04/28/2015 03:24 AM, Armando M. wrote: UnsupportedVersion error if the version is not bumped in their agent too. Could the server fall back

Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

On 27 April 2015 at 09:09, Rossella Sblendido rsblend...@suse.com wrote: Hello all, I am working at the blueprint Restructure the L2 agent [1] . One of the work item of this blueprint is to modify the port_update message to include the attributes of the ports that were modified. This is

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

Any project that fails to meet the criteria later can be dropped at any time. For example, if some repo is clearly unmaintained, it can be removed. If we open the door to excluding projects down the road, then wouldn't we need to take into account some form of 3rd party CI validation as

Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

On 27 April 2015 at 18:16, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: On 27 April 2015 at 09:09, Rossella Sblendido rsblend...@suse.com wrote: Hello all, I am working at the blueprint Restructure the L2 agent [1] . One of the work item of this blueprint is to modify the

Re: [openstack-dev] [all] Question for the TC candidates

On 23 April 2015 at 09:14, Chris Dent chd...@redhat.com wrote: This might be a bit presumptuous, but why not give it a try... This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Hi Armando Salvatore, On 23/4/2015, at 9:30, Salvatore Orlando sorla...@nicira.com wrote: On 23 April 2015 at 01:30, Armando M. arma...@gmail.com wrote: On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

If we've reached the point where we're arguing about naming, dos this mean we've built consensus on the yes, it makes sense for these to live under Neutron argument? I think we are in agreement that these projects need to find a more obvious home, they feel somewhat orphan otherwise. Most

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com wrote: On 04/22/2015 10:33 PM, Armando M. wrote: Would it make sense to capture these projects as simply 'affiliated', ie. with a loose relationship to Neutron, because they use/integrate with Neutron

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On 23 April 2015 at 01:49, Thierry Carrez thie...@openstack.org wrote: Armando M. wrote: Is it sensible to assume that Stackforge is going away entirely at some point in the future, and we'll have a single namespace - OpenStack? The key difference between Stackforge and OpenStack

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/22/2015 10:33 PM, Armando M. wrote: Would

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

I agree with henry here. Armando, If we use your analogy with nova that doesn't build and deliver KVM, we can say that Neutron doesn't build or deliver OVS. It builds a driver and an agent which manage OVS, just like nova which provides a driver to manage libvirt/KVM. Moreover, external

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

Would it make sense to capture these projects as simply 'affiliated', ie. with a loose relationship to Neutron, because they use/integrate with Neutron in some form or another (e.g. having 3rd-party, extending-api, integrating-via-plugin-model, etc)? Then we could simply consider extending

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

Could you please also pay some attention on Cons of this ultimate splitting Kyle? I'm afraid it would hurt the user experiences. On the position of Dev, A naked Neutron without official built-in reference implementation probably has a more clear architecture. On the other side, users would

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On 22 April 2015 at 11:19, Russell Bryant rbry...@redhat.com wrote: Hello! A couple of things I've been working on lately are project governance issues as a TC member and also implementation of a new virtual networking alternative with a Neutron driver. So, naturally I started thinking

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Hi everybody, In the latest QoS meeting, one of the topics was a discussion about how to implement QoS [1] either as in core, or as a service plugin, in, or out-tree. My apologies if I was unable to join,

[openstack-dev] TC candidacy

I would like to announce my candidacy for the OpenStack Technical Committee. I will try to be brief and to the point: I have been involved in OpenStack since the early days of the Austin release; I have worked on (perhaps) the two most prolific projects in OpenStack (Nova, and Neutron) and a few

Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

On 6 April 2015 at 08:56, Miguel Ángel Ajo majop...@redhat.com wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

From spec [1], I read: - Of the core drivers, the VLAN and OVS drivers will be marked as not supporting VLAN transparent networks and the LB, VXLAN and GRE drivers will be marked as supporting VLAN transparent networks. Other drivers will have legacy behaviour. I can't seem to find

Re: [openstack-dev] [Neutron] Neutron extenstions

. Thanks, Armando On 20 March 2015 at 09:51, Armando M. arma...@gmail.com wrote: On 19 March 2015 at 23:59, Akihiro Motoki amot...@gmail.com wrote: Forwarding my reply to the other thread too... Multiple threads on the same topic is confusing. Can we use this thread if we continue the discussion

Re: [openstack-dev] [Neutron] Neutron extenstions

+09:00 Armando M. arma...@gmail.com: Forwarding my reply to the other thread here: If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: an opt

Re: [openstack-dev] [Neutron] Neutron extenstions

Forwarding my reply to the other thread here: If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: - an opt-in approach: this means we know the expected

Re: [openstack-dev] [Neutron] VLAN transparency support

If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: - an opt-in approach: this means we know the expected behavior of the plugin as someone has coded the plugin

Re: [openstack-dev] [neutron] Proposal to add Ihar Hrachyshka as a Neutron Core Reviewer

+1! On 4 March 2015 at 22:29, Kevin Benton blak...@gmail.com wrote: +1 On Mar 4, 2015 12:25 PM, Maru Newby ma...@redhat.com wrote: +1 from me, Ihar has been doing great work and it will be great to have him finally able to merge! On Mar 4, 2015, at 11:42 AM, Kyle Mestery

Re: [openstack-dev] [Neutron] per-agent/driver/plugin requirements

On 17 February 2015 at 22:00, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, i want to add an extra requirement specific to OVS-agent. (namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1] but the question is not specific to the blueprint.) to avoid messing deployments

[openstack-dev] [neutron] neutron-drivers meeting

Hi folks, I was wondering if we should have a special neutron-drivers meeting on Wednesday Feb 18th (9:30AM CST / 7:30AM PST) to discuss recent patches where a few cores have not reached consensus on, namely: - https://review.openstack.org/#/c/155373/ - https://review.openstack.org/#/c/148318/

Re: [openstack-dev] Use of egg snapshots of neutron code in neutron-*aas projects/distributing openstack

I also failed to understand the issue, and I commented on the bug report, where it's probably best to continue this conversation. Thanks, Armando On 16 February 2015 at 07:54, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/16/2015 04:13 PM,

Re: [openstack-dev] [neutron] DVR and l2_population

L2pop is a requirement. With the existing agent-based architecture, L2pop is used to update the FDB tables on the compute hosts to make east/west traffic possible whenever a new port is created or existing one is updated. Cheers, Armando On 10 February 2015 at 23:07, Itzik Brown

Re: [openstack-dev] oslo.messaging 1.6.0 released

Is there any chance that this release might have caused bug [1]? I am still root-causing what's going on...any input highly appreciated. Thanks, Armando [1] https://bugs.launchpad.net/grenade/+bug/1415284 On 27 January 2015 at 14:23, Doug Hellmann d...@doughellmann.com wrote: There were some

Re: [openstack-dev] [neutron] Changes to the core team

+1 On 15 January 2015 at 14:46, Edgar Magana edgar.mag...@workday.com wrote: +1 For adding Doug as Core in Neutron! I have seen his work on the services part and he is a great member of the OpenStack community! Edgar From: Kyle Mestery mest...@mestery.com Reply-To: OpenStack

Re: [openstack-dev] The state of nova-network to neutron migration

If we were standing at a place with a detailed manual upgrade document that explained how to do minimal VM downtime, that a few ops had gone through and proved out, that would be one thing. And we could figure out which parts made sense to put tooling around to make this easier for everyone.

Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

On 15 December 2014 at 09:53, Neil Jerram neil.jer...@metaswitch.com wrote: Hi all, Following the approval for Neutron vendor code decomposition (https://review.openstack.org/#/c/134680/), I just wanted to comment that it appears to work fine to have an ML2 mechanism driver _entirely_ out

Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

Good questions. I'm also looking for the linux bridge MD, SRIOV MD... Who will be responsible for these drivers? Excellent question. In my opinion, 'technology' specific but not vendor specific MD (like SRIOV) should not be maintained by specific vendor. It should be accessible for all

Re: [openstack-dev] [neutron] Services are now split out and neutron is open for commits!

This was more of a brute force fix! I didn't have time to go with finesse, and instead I went in with the hammer :) That said, we want to make sure that the upgrade path to Kilo is as painless as possible, so we'll need to review the Release Notes [1] to reflect the fact that we'll be providing

Re: [openstack-dev] [neutron] Vendor Plugin Decomposition and NeutronClient vendor extension

On 12 December 2014 at 22:18, Ryu Ishimoto r...@midokura.com wrote: Hi All, It's great to see the vendor plugin decomposition spec[1] finally getting merged! Now that the spec is completed, I have a question on how this may impact neutronclient, and in particular, its handling of vendor

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

://review.openstack.org/#/c/140191/ 2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com mailto:arma...@gmail.com: By the way, if Kyle can do it in his teeny tiny time that he has left after his PTL duties, then anyone can do it! :) https://review.openstack.org/#/c/140191/ This patch looses

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

in tree whilst the others will be moved out of tree will be problematic. I think that the model will be complete if the ML2 was also out of tree. This will help crystalize the idea and make sure that the model works correctly. Thanks Gary From: Armando M. arma...@gmail.com Reply

[openstack-dev] [Neutron] Core/Vendor code decomposition

Hi folks, For a few weeks now the Neutron team has worked tirelessly on [1]. This initiative stems from the fact that as the project matures, evolution of processes and contribution guidelines need to evolve with it. This is to ensure that the project can keep on thriving in order to meet the

Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?

For anyone who had an interest in following this thread, they might want to have a look at [1], and [2] (which is the tl;dr version [1]). HTH Armando [1] https://review.openstack.org/#/c/134680 [2] http://lists.openstack.org/pipermail/openstack-dev/2014-December/052346.html

Re: [openstack-dev] [neutron] Changes to the core team

Congrats to Henry and Kevin, +1! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - the setup of a DHCP sub-group

Hi Don, You should look at this one: https://wiki.openstack.org/wiki/NeutronSubteamCharters Also, it would be good to start feeding the content of that gdoc into a neutron-specs blueprint, using template [1] and process [2], bearing in mind these dates [3] 1.

Re: [openstack-dev] [neutron] L2 gateway as a service

problem, free of any potential confusion or open to subjective interpretation; a loose API suffers from both pitfalls, hence my suggestion to go with API proposed in [1]. Make sense? cheers.. -Sukhdev On Tue, Nov 18, 2014 at 6:44 PM, Armando M. arma...@gmail.com wrote: Hi, On 18 November

Re: [openstack-dev] [neutron] L2 gateway as a service

spin-off goes ahead, so that efforts, like this one, can evolve at the pace they are comfortable with. Salvatore [1] http://openvswitch.org/pipermail/dev/2013-October/032530.html Make sense? cheers.. -Sukhdev On Tue, Nov 18, 2014 at 6:44 PM, Armando M. arma...@gmail.com wrote

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

Hi Carl, Thanks for kicking this off. I am also willing to help as a core reviewer of blueprints and code submissions only. As for the ML2 agent, we all know that for historic reasons Neutron has grown to be not only a networking orchestration project but also a reference implementation that is

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

Mark, Kyle, What is the strategy for tracking the progress and all the details about this initiative? Blueprint spec, wiki page, or something else? One thing I personally found useful about the spec approach adopted in [1], was that we could quickly and effectively incorporate community

Re: [openstack-dev] [neutron] L2 gateway as a service

November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1

Re: [openstack-dev] [neutron] L2 gateway as a service

On 17 November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood

Re: [openstack-dev] [neutron] L2 gateway as a service

Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1]

Re: [openstack-dev] [Neutron] LeastNetwork scheduling for DHCP

Benjamin, Feel free to reach out. If you are referring to my -2, that was just provisional. Before we can go ahead and see an improved scheduling capability for DHCP, you guys need to resolve the conflict between the overlapping blueprints, working together or giving up one in favor on the

[openstack-dev] [Neutron] Core/Vendor code decomposition

Hello, As follow-up action after the Design Summit Session on Core/Vendor split, please find the proposal outlined here: https://review.openstack.org/#/c/134680/ I know that Anita will tell me off since I asked for reviews on the ML, but I felt that it was important to raise awareness, even

Re: [openstack-dev] [Neutron] VMware networking support

I chimed in on another thread, but I am reinstating my point just in case. On 13 November 2014 04:38, Gary Kotton gkot...@vmware.com wrote: Hi, A few months back we started to work on a umbrella spec for Vmware networking support (https://review.openstack.org/#/c/105369). There are a number

Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support

Hi Miguel, Thanks for picking this up. Pull me in and I'd be happy to help! Cheers, Armando On 7 November 2014 10:05, Miguel Ángel Ajo majop...@redhat.com wrote: Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start

Re: [openstack-dev] [neutron] dvr l3_snat

Not sure if you've seen this one too: https://wiki.openstack.org/wiki/Neutron/DVR Hope this helps! Armando On 7 November 2014 01:50, Li Tianqing jaze...@163.com wrote: Oh, thanks, i finally find it. it's all here. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr Thanks a

[openstack-dev] Fw: [neutron] social event

I have just realized that I should have cross-reference this mail on both ML's. Same message for the dev mailing list. Thanks, Armando On 6 November 2014 00:32, Armando M. arma...@gmail.com wrote: Hi there, I know this may be somewhat short notice, but a few of us have wondered if we should

<    1   2   3   4   5   6   7   >