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

2014-08-08 Thread Armando M.
On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote: There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron project. If someone uses the current APIs, the group policy plugin

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

2014-08-08 Thread Armando M.
Adding the GBP extension to Neutron does not change the nature of the software architecture of Neutron making it more or less monolithic. I agree with this statement...partially: the way GBP was developed is in accordance to the same principles and architectural choices made for the service

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

2014-08-08 Thread Armando M.
optimal one? On Fri, Aug 8, 2014 at 1:45 PM, Armando M. arma...@gmail.com wrote: On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote: There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated

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

2014-08-08 Thread Armando M.
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

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

2014-08-08 Thread Armando M.
On Fri, Aug 8, 2014 at 5:38 PM, Armando M. arma...@gmail.com 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

Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

2014-08-09 Thread Armando M.
On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote: Paul, does this friend of a friend have a reproduceable test script for this? Thanks! -jay We would also need to know the OpenStack release where this issue manifest itself. A number of bugs have been raised in the past around

Re: [openstack-dev] [neutron] Which changes need accompanying bugs?

2014-08-13 Thread Armando M.
I am gonna add more color to this story by posting my replies on review [1]: Hi Angus, You touched on a number of points. Let me try to give you an answer to all of them. (I'll create a bug report too. I still haven't worked out which class of changes need an accompanying bug report and which

Re: [openstack-dev] [neutron] Which changes need accompanying bugs?

2014-08-13 Thread Armando M.
At the moment pylint on neutron is *very* noisy, and I've been looking through the reported issues by hand to get a feel for what's involved. Enabling pylint is a separate discussion that I'd like to have - in some other thread. I think enabling pylint check was discussed at the

[openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-21 Thread Armando M.
Hi folks, According to [1], we have ways to introduce external references to commit messages. These are useful to mark certain patches and their relevance in the context of documentation, upgrades, etc. I was wondering if it would be useful considering the addition of another tag:

Re: [openstack-dev] Adding GateFailureFix tag to commit messages

2014-08-21 Thread Armando M.
A concern with this approach is it's pretty arbitrary, and not always clear which bugs are being addressed and how severe they are. Well, establishing whether LP reports are actual bugs and assigning the severity isn't what triaging is for? An idea that came up in the Infra/QA meetup was

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-10 Thread Armando M.
Hi, I devoured this thread, so much it was interesting and full of insights. It's not news that we've been pondering about this in the Neutron project for the past and existing cycle or so. Likely, this effort is going to take more than two cycles, and would require a very focused team of people

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-11 Thread Armando M.
On 10 September 2014 22:23, Russell Bryant rbry...@redhat.com wrote: On 09/10/2014 10:35 PM, Armando M. wrote: Hi, I devoured this thread, so much it was interesting and full of insights. It's not news that we've been pondering about this in the Neutron project for the past and existing

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

2014-09-17 Thread Armando M.
VLAN is on the radar, vxlan/gre was done to start with. I believe Vivek mentioned the rationale in some other thread. The gist of it below: In the current architecture, we use a unique DVR MAC per compute node to forward DVR Routed traffic directly to destination compute node. The DVR routed

Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron

2014-09-22 Thread Armando M.
What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 On 22 September 2014 10:23, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: My team just ran into an issue where neutron was not passing unit tests when run under Python 2.6. We tracked this down to

Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron

2014-09-22 Thread Armando M.
of python 2.6, and move on, but then I'd also like to get rid of 2.7 and move on also ;) - Josh On Sep 22, 2014, at 11:17 AM, Monty Taylor mord...@inaugust.com wrote: On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https

Re: [openstack-dev] [Neutron][Testr] Brand new checkout of Neutron... getting insane unit test run results

2014-01-02 Thread Armando M.
To be fair, neutron cores turned down reviews [1][2][3] for fear that the patch would break Hyper-V support for Neutron. Whether it's been hinted (erroneously) that this was a packaging issue is irrelevant for the sake of this discussion, and I suggested (when I turned down review [3]) if we

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

2014-02-16 Thread Armando M.
+1 On Feb 13, 2014 5:52 PM, Nachi Ueno na...@ntti3.com wrote: +1 2014年2月12日水曜日、Mayur Patilram.nath241...@gmail.comさんは書きました: +1 *--* *Cheers,* *Mayur* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [neutron] Fixes for the alembic migration (sqlite + postgress) aren't being reviewed

2014-02-20 Thread Armando M.
Thomas, I feel your frustration, however before complaining please do follow the actual chain of events. Patch [1]: I asked a question which I never received an answer to. Patch [2]: I did put a -1, but I have nothing against this patch per se. This was only been recently abandoned and my -1

Re: [openstack-dev] [neutron] Fixes for the alembic migration (sqlite + postgress) aren't being reviewed

2014-02-20 Thread Armando M.
On 20 February 2014 14:13, Vincent Untz vu...@suse.com wrote: Le jeudi 20 février 2014, à 12:02 -0800, Armando M. a écrit : Thomas, I feel your frustration, however before complaining please do follow the actual chain of events. Patch [1]: I asked a question which I never received an answer

Re: [openstack-dev] False Positive testing for 3rd party CI

2014-02-21 Thread Armando M.
Nice one! On 21 February 2014 11:22, Aaron Rosen aaronoro...@gmail.com wrote: This should fix the false positive for brocade: https://review.openstack.org/#/c/75486/ Aaron On Fri, Feb 21, 2014 at 10:34 AM, Aaron Rosen aaronoro...@gmail.com wrote: Hi, Yesterday, I pushed a patch to

Re: [openstack-dev] [Neutron] minimal scope covered by third-party testing

2014-04-04 Thread Armando M.
Hi Simon, You are absolutely right in your train of thoughts: unless the third-party CI monitors and vets all the potential changes it cares about there's always a chance something might break. This is why I think it's important that each Neutron third party CI should not only test Neutron

Re: [openstack-dev] [Neutron] Stop logging non-exceptional conditions as ERROR

2013-11-28 Thread Armando M.
I have been doing so in the number of patches I pushed to reduce error traces due to the communication between server and dhcp agent. I wanted to take care of the l3 agent too, but one thing I noticed is that I couldn't find a log for it (I mean on the artifacts that are published at job's

Re: [openstack-dev] [Neutron] - Location for common third-party libs?

2014-06-16 Thread Armando M.
I believe the Brocade's mech driver might have the same problem. That said, if the content of the rpm that installs the BigSwitch plugin is just the sub-tree for bigswitch (plus the config files, perhaps), you might get away with this issue by just installing the bigswitch-plugin package. I

Re: [openstack-dev] [Neutron] - Location for common third-party libs?

2014-06-17 Thread Armando M.
code. Sort of like: common/brocade/templates common/bigswitch/* -Shiv From: Armando M. arma...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org To: OpenStack Development Mailing List (not for usage questions) openstack

Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load

2014-06-17 Thread Armando M.
I wonder what the turnaround of trivial patches actually is, I bet you it's very very small, and as Daniel said, the human burden is rather minimal (I would be more concerned about slowing them down in the gate, but I digress). I think that introducing a two-tier level for patch approval can only

Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture

2014-06-17 Thread Armando M.
just a provocative thought: If we used the ovsdb connection instead, do we really need an L2 agent :P? On 17 June 2014 18:38, Kyle Mestery mest...@noironetworks.com wrote: Another area of improvement for the agent would be to move away from executing CLIs for port commands and instead use

Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture

2014-06-17 Thread Armando M.
more intelligently/appropriately. -- Thanks, Vivek *From:* Armando M. [mailto:arma...@gmail.com] *Sent:* Tuesday, June 17, 2014 10:26 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture

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

2014-06-30 Thread Armando M.
Hi Gary, Thanks for sending this out, comments inline. On 29 June 2014 00:15, Gary Kotton gkot...@vmware.com wrote: Hi, At the moment there are a number of different BP’s that are proposed to enable different VMware network management solutions. The following specs are in review: 1.

[openstack-dev] [Neutron] DVR demo and how-to

2014-06-30 Thread Armando M.
Hi folks, The DVR team is working really hard to complete this important task for Juno and Neutron. In order to help see this feature in action, a video has been made available and link can be found in [2]. There is still some work to do, however I wanted to remind you that all of the relevant

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

2014-07-14 Thread Armando M.
try again next week Monday at 14:00 UTC. The meeting will take place on #openstack-vmware channel Alut a continua Gary On 6/30/14, 6:38 PM, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Jun 30, 2014 at 10:18 AM, Armando M. arma...@gmail.com wrote: Hi Gary

Re: [openstack-dev] [Neutron] [Spec freeze exception] VMware DVS support

2014-07-21 Thread Armando M.
I think the specs under the umbrella one can be approved/treated individually. The umbrella one is an informational blueprint, there is not going to be code associated with it, however before approving it (and the individual ones) we'd need all the parties interested in vsphere support for

Re: [openstack-dev] [Neutron] [Spec freeze exception] VMware DVS support

2014-07-21 Thread Armando M.
That would be my thinking as well, but if we managed to make an impressive progress from now until the Feature Freeze proposal deadline, I'd be willing to reevaluate the situation. A. On 21 July 2014 12:13, Kyle Mestery mest...@mestery.com wrote: On Mon, Jul 21, 2014 at 2:03 PM, Armando M

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

2014-07-31 Thread Armando M.
It is not my intention debating, pointing fingers and finding culprits, these issues can be addressed in some other context. I am gonna say three things: 1) If a core-reviewer puts a -2, there must be a good reason for it. If other reviewers blindly move on as some people seem to imply here,

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

2014-08-04 Thread Armando M.
Hi, When I think about Group-Based Policy I cannot help myself but think about the degree of variety of sentiments (for lack of better words) that this subject has raised over the past few months on the mailing list and/or other venues. I speak for myself when I say that when I look at the

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

2014-08-06 Thread Armando M.
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?); -

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

2014-08-06 Thread Armando M.
On 6 August 2014 15:47, Kevin Benton blak...@gmail.com 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

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

2014-08-06 Thread Armando M.
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

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

2014-08-06 Thread Armando M.
On 6 August 2014 17:34, Prasad Vellanki prasad.vella...@oneconvergence.com 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

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

2014-08-07 Thread Armando M.
Hi Salvatore, I did notice the issue and I flagged this bug report: https://bugs.launchpad.net/nova/+bug/1352141 I'll follow up. Cheers, Armando On 7 August 2014 01:34, Salvatore Orlando sorla...@nicira.com wrote: I had to put the patch back on WIP because yesterday a bug causing a 100%

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread Armando M.
If the consensus is to unify all the config options into a single configuration file, I'd suggest following what the Nova folks did with [1], which I think is what Salvatore was also hinted. This will also help mitigate needless source code conflicts that would inevitably arise when merging

Re: [openstack-dev] [neutron] Proposed changes to core team

2014-05-21 Thread Armando M.
+1 from me too: Carl's contributions, code and reviews, have helped raise the quality of this project. Cheers, Armando On 21 May 2014 15:05, Maru Newby ma...@redhat.com wrote: On May 21, 2014, at 1:59 PM, Kyle Mestery mest...@noironetworks.com wrote: Neutron cores, please vote +1/-1 for the

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

2014-05-22 Thread Armando M.
I would second Maru's concerns, and I would also like to add the following: We need to acknowledge the fact that there are certain architectural aspects of Neutron as a project that need to be addressed; at the summit we talked about the core refactoring, a task oriented API, etc. To me these

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

2014-05-22 Thread Armando M.
AM, Armando M. arma...@gmail.com wrote: I would second Maru's concerns, and I would also like to add the following: We need to acknowledge the fact that there are certain architectural aspects of Neutron as a project that need to be addressed; at the summit we talked about the core

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

2014-05-23 Thread Armando M.
On 23 May 2014 12:31, Robert Kukura kuk...@noironetworks.com wrote: On 5/23/14, 12:46 AM, Mandeep Dhami wrote: Hi Armando: Those are good points. I will let Bob Kukura chime in on the specifics of how we intend to do that integration. But if what you see in the prototype/PoC was our final

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-05-24 Thread Armando M.
On 24 May 2014 05:20, Robert Kukura kuk...@noironetworks.com wrote: On 5/23/14, 10:54 PM, Armando M. wrote: On 23 May 2014 12:31, Robert Kukura kuk...@noironetworks.com wrote: On 5/23/14, 12:46 AM, Mandeep Dhami wrote: Hi Armando: Those are good points. I will let Bob Kukura chime

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-05-26 Thread Armando M.
as through the REST API. Is this a misunderstanding? That was not my understanding, but I'll let Mark chime in on this. Many thanks Armando Best, Mohammad Armando M. arma...@gmail.com wrote on 05/24/2014 01:36:35 PM: From: Armando M. arma...@gmail.com To: OpenStack Development Mailing

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-05-27 Thread Armando M.
/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/ - GP PoC document [image: Inactive hide details for Armando M. ---05/26/2014 09:46:34 PM---On May 26, 2014 4:27 PM, Mohammad Banikazemi m...@us.ibm.co]Armando M. ---05/26/2014 09:46:34 PM---On May 26, 2014 4:27 PM, Mohammad Banikazemi m...@us.ibm.com wrote

Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?

2014-05-28 Thread Armando M.
Hi Keshava, To the best of my knowledge Nova does not have an explicit way to determine VM placements based on network attributes. That said, it does have a general mechanism called host-aggregates [1] that can be leveraged to address what you are looking for. How certain hosts are grouped

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-29 Thread Armando M.
Hi Paul, Just out of curiosity, I am assuming you are using the client that still relies on httplib2. Patch [1] replaced httplib2 with requests, but I believe that a new client that incorporates this change has not yet been published. I wonder if the failures you are referring to manifest

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-29 Thread Armando M.
here as it seems like an ssl thing itself. But... who knows?? I'm not sure how consistently we can recreate this, but if we can, I'll try using that patch to use requests and see if that helps. Armando M. arma...@gmail.com wrote on 05/29/2014 11:52:34 AM: From: Armando M. arma

Re: [openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno

2014-10-03 Thread Armando M.
I have all of these bugs on my radar, and I want to fast track them for merging in the next few days. Please tag the bug reports with 'juno-rc-potential'. For each of them we can discuss the loss of functionality they cause. If no workaround can be found, we should definitely cut an RC2.

Re: [openstack-dev] [neutron] HA of dhcp agents?

2014-10-21 Thread Armando M.
As far as I can tell when you specify: dhcp_agents_per_network = X 1 The server binds the network to all the agents (up to X), which means that you have multiple instances of dnsmasq serving dhcp requests at the same time. If one agent dies, there is no fail-over needed per se, as the other

Re: [openstack-dev] [neutron][stable] metadata agent performance

2014-10-21 Thread Armando M.
It sounds like the only reasonable option we are left with right now is to document. Even if we enabled/removed the backport, it would take time until users can get their hands on a new cut of the stable branch. We would need to be more diligent in the future and limit backports to just bug

Re: [openstack-dev] [neutron] HA of dhcp agents?

2014-10-22 Thread Armando M.
on. I have the same problem wit L3 agents by the way, that's next on my list -- Noel On Tue, Oct 21, 2014 at 12:52 PM, Armando M. arma...@gmail.com wrote: As far as I can tell when you specify: dhcp_agents_per_network = X 1 The server binds the network to all the agents (up to X

Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-10-28 Thread Armando M.
Sorry for jumping into this thread late...there's lots of details to process, and I needed time to digest! Having said that, I'd like to recap before moving the discussion forward, at the Summit and beyond. As it's being pointed out, there are a few efforts targeting this area; I think that is

Re: [openstack-dev] [neutron] Clear all flows when ovs agent start? why and how avoid?

2014-10-29 Thread Armando M.
I must admit I haven't digged up too much, but this might also look suspicious: https://review.openstack.org/#/c/96782/ Perhaps it's a combination of both? :) On 29 October 2014 08:17, Kyle Mestery mest...@mestery.com wrote: On Wed, Oct 29, 2014 at 7:25 AM, Hly henry4...@gmail.com wrote:

Re: [openstack-dev] [Neutron] Improving dhcp agent scheduling interface

2014-11-05 Thread Armando M.
Hi Eugene thanks for bringing this up for discussion. My comments inline. Thanks, Armando On 5 November 2014 12:07, Eugene Nikanorov enikano...@mirantis.com wrote: Hi folks, I'd like to raise a discussion kept in irc and in gerrit recently: https://review.openstack.org/#/c/131944/ The

Re: [openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?

2014-11-05 Thread Armando M.
I would be open to making this toggle switch available, however I feel that doing it via static configuration can introduce unnecessary burden to the operator. Perhaps we could explore a way where the agent can figure which state it's supposed to be in based on its reported status? Armando On 5

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

2014-11-06 Thread Armando M.
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

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

2014-11-07 Thread Armando M.
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

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

2014-11-08 Thread Armando M.
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] VMware networking support

2014-11-13 Thread Armando M.
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] L2 gateway as a service

2014-11-14 Thread Armando M.
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

2014-11-14 Thread Armando M.
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

2014-11-14 Thread Armando M.
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] L2 gateway as a service

2014-11-17 Thread Armando M.
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 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

2014-11-18 Thread Armando M.
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

2014-11-18 Thread Armando M.
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

2014-11-18 Thread Armando M.
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

2014-11-20 Thread Armando M.
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

2014-11-20 Thread Armando M.
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] - the setup of a DHCP sub-group

2014-11-26 Thread Armando M.
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] Changes to the core team

2014-12-02 Thread Armando M.
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

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

2014-12-05 Thread Armando M.
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?

2014-12-05 Thread Armando M.
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] Core/Vendor code decomposition

2014-12-09 Thread Armando M.
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

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

2014-12-12 Thread Armando M.
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

2014-12-12 Thread Armando M.
://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] Services are now split out and neutron is open for commits!

2014-12-13 Thread Armando M.
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] Minimal ML2 mechanism driver after Neutron decomposition change

2014-12-15 Thread Armando M.
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

2014-12-15 Thread Armando M.
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] Changes to the core team

2015-01-15 Thread Armando M.
+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] [neutron] DVR and l2_population

2015-02-11 Thread Armando M.
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] [Neutron] per-agent/driver/plugin requirements

2015-02-18 Thread Armando M.
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

2015-02-17 Thread Armando M.
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

2015-02-17 Thread Armando M.
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] oslo.messaging 1.6.0 released

2015-01-27 Thread Armando M.
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] The state of nova-network to neutron migration

2015-01-09 Thread Armando M.
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] [Neutron] Neutron extenstions

2015-03-19 Thread Armando M.
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

2015-03-19 Thread Armando M.
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] Neutron extenstions

2015-03-20 Thread Armando M.
. 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

2015-03-20 Thread Armando M.
+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] Proposal to add Ihar Hrachyshka as a Neutron Core Reviewer

2015-03-04 Thread Armando M.
+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] VLAN trunking network for NFV

2015-03-24 Thread Armando M.
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] A big tent home for Neutron backend code

2015-04-23 Thread Armando M.
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

2015-04-23 Thread Armando M.
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

2015-04-23 Thread Armando M.
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

2015-04-23 Thread Armando M.
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][QoS] service-plugin or not discussion

2015-04-24 Thread Armando M.
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

2015-04-24 Thread Armando M.
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

  1   2   3   4   5   6   7   >