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

2014-08-08 Thread Ivar Lazzaro
Hi Paul, Don't need to worry, you are perfectly right, GBP API is not replacing anything :). Also thanks for sharing your opinion on this matter. Thanks, Ivar. On Fri, Aug 8, 2014 at 5:46 PM, CARVER, PAUL pc2...@att.com wrote: Wuhongning [mailto:wuhongn...@huawei.com] wrote: Does it make

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

2014-08-08 Thread Ivar Lazzaro
Hi Jay, You can choose. The whole purpose of this is about flexibility, if you want to use GBP API 'only' with a specific driver you just can. Additionally, given the 'ML2 like' architecture, the reference mapping driver can ideally run alongside by filling the core Neutron constructs without

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Ivar Lazzaro
That's ok for me as well! +1 On Aug 8, 2014 10:04 PM, Prasad Vellanki prasad.vella...@oneconvergence.com wrote: It sounds good +1 On Fri, Aug 8, 2014 at 12:44 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Thanks Jay for your constructive feedback on this. I personally think that

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-08 Thread Ivar Lazzaro
Hi Robert, I think this is a great proposal. Easy to understand and (at a first glance) easy to implement. Also, it seems the perfect compromise for those who wanted GBP (as a representative for this kind of extension) in tree, and those who wanted it to be more mature first. Fwiw, You have my

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

2014-08-15 Thread Ivar Lazzaro
Hi Edgar, Nice shot, to be the inquisitor is not necessarily a bad thing :) I know some CIs are 'stuck' waiting for bugs to be fixed or certain patches to be merged, but I was wondering if it is a requirement that CIs vote *ALL* the Neutron patches. Some may have missed your call just because of

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

2014-08-15 Thread Ivar Lazzaro
with a basic change in the Neutron DB code. That should be covered by almost all CI systems. Edgar From: Ivar Lazzaro ivarlazz...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Friday, August 15, 2014 at 3:47 PM

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Ivar Lazzaro
Quoting Stefano from a different thread [0]: The rationale for the separate repository is that Neutron's code needs a lot of love for the *existing* codebase, before new features can be added (and before core team can accept more responsibilities for it). But progress is unstoppable: new

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-27 Thread Ivar Lazzaro
On Wed, Aug 27, 2014 at 5:06 PM, Jeremy Stanley fu...@yuggoth.org wrote: Good point, and that definitely is a reason to just keep those pieces in their own separate Git repositories outside of the core Neutron repository in perpetuity (even after they graduate from incubation). One package

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Ivar Lazzaro
+1 for 1700UTC Thursday on IRC -Original Message- From: Kyle Mestery [mailto:mest...@siliconloons.com] Sent: Tuesday, December 10, 2013 9:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testing

Re: [openstack-dev] [Neturon][CI] Embrane CI is attacking gerrit

2014-01-13 Thread Ivar Lazzaro
Hi Nachi, Russel I've stopped our Jenkins server... That should stop this crazy attack. However, I am wondering how this happened, we didn't set any voting mechanism on it yet... Sorry about that, Ivar. -Original Message- From: Nachi Ueno [mailto:na...@ntti3.com] Sent: Monday, January

[openstack-dev] [Neutron] Tenant's info from plugin/services

2013-10-16 Thread Ivar Lazzaro
Hello Everyone, I was wondering if there's a standard way within Neutron to retrieve tenants' specific information (e.g. name) from a plugin/service. The call context already provides the tenant's UUID, but that may be useful to have some extra info in certain cases. Thanks, Ivar.

Re: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed

2013-12-04 Thread Ivar Lazzaro
Hi Eugene, Right now (before the model change discussed during the summit) our implementation, in regards to your question, can be summarized as follows: - Whenever a Pool is created, a port on the specific subnet/network is created and associated to it; - Whenever a VIP is

Re: [openstack-dev] [neutron] [third-party] Current status of Neutron 3rd Party CI and how to move forward

2014-06-13 Thread Ivar Lazzaro
Hi Kyle, Embrane's CI was blocked by some nasty bugs affecting the testing environment. It resumed yesterday (6/12) [0]. Unfortunately it's still non voting (only commenting so far). Not sure if this is a requirement or not, but it should be able to put +1/-1 immediately after the voting right is

Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions

2014-07-25 Thread Ivar Lazzaro
I agree that it's important to set a guideline for this topic. What if the said reviewer is on vacation or indisposed? Should a fallback strategy exist for that case? A reviewer could indicate a delegate core to review its -2s whenever he has no chance to do it. Thanks, Ivar. On Fri, Jul 25,

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

2014-08-04 Thread Ivar Lazzaro
+1 Hemanth. On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi hemanthrav...@gmail.com wrote: Hi, I believe that the API has been reviewed well both for its usecases and correctness. And the blueprint has been approved after sufficient exposure of the API in the community. The best way to

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

2014-08-06 Thread Ivar Lazzaro
Hi Joe, Are you suggesting to stop/remove everything that is not related to Nova Parity for the Juno release? Because then I fail to see why this and Mark's proposal are targeted only to GBP. In my humble opinion, these kind of concerns should be addressed at BP approval time. Otherwise the

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

2014-08-06 Thread Ivar Lazzaro
Which kind of uncertainty are you referring to? Given that the blueprint was approved long ago, and the code has been ready and under review following those specs... I think GBP is probably the patch with the least effort to be merged right now. Ivar. On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon

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

2014-08-06 Thread Ivar Lazzaro
of the service plugin to stackforge as suggested to this thread. More options are obviously welcome! Regards, Salvatore On 6 August 2014 19:40, Ivar Lazzaro ivarlazz...@gmail.com wrote: Which kind of uncertainty are you referring to? Given that the blueprint was approved long ago, and the code

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

2014-08-06 Thread Ivar Lazzaro
Hi Aaron, Please note that the user using the current reference implementation doesn't need to create Networks, Ports, or anything else. As a matter of fact, the mapping is done implicitly. Also, I agree with Kevin when he says that this is a whole different discussion. Thanks, Ivar. On Wed,

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

2014-08-06 Thread Ivar Lazzaro
+1 Eugene, Still, there's a point in Stefano's thread: There's a time for discussing merging strategies, models, and naming conventions... And this time is called BP approval :) Just saying. Ivar. On Wed, Aug 6, 2014 at 10:21 PM, Eugene Nikanorov enikano...@mirantis.com wrote: On Wed,

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

2014-08-06 Thread Ivar Lazzaro
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

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

2014-08-06 Thread Ivar Lazzaro
+1 Mohammad. On Aug 6, 2014 11:08 PM, Mohammad Banikazemi 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

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

2014-08-06 Thread Ivar Lazzaro
unfair. Ivar. On Aug 6, 2014 11:00 PM, Edgar Magana edgar.mag...@workday.com wrote: Ivar, Of course and this is why we are having this conversation, in order to merge our different opinions. Edgar From: Ivar Lazzaro ivarlazz...@gmail.com Reply-To: OpenStack Development Mailing List

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

2014-08-06 Thread Ivar Lazzaro
+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 blak...@gmail.com wrote: In all seriousness, folks, I'm bringing up points about the proposed

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

2014-08-06 Thread Ivar Lazzaro
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

Re: [openstack-dev] [Neutron][Advanced Services] Requesting reviewers

2014-05-31 Thread Ivar Lazzaro
Hi Sumit, Review commitment sound like a good idea. Is this aiming core reviewers only? What number of cores / non cores are you ideally trying to reach? Thanks, Ivar. On Fri, May 30, 2014 at 7:21 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: During the Neutron Advanced Services'

[openstack-dev] [Group-based Policy] Database migration chain

2014-10-03 Thread Ivar Lazzaro
Hi, Following up the latest GBP team meeting [0][1]: As we keep going with our Juno stackforge implementation [2], although the service is effectively a Neutron extension, we should avoid breaking Neutron's migration chain by adding our model on top of it (and subsequently changing Neutron's

Re: [openstack-dev] [Group-based Policy] Database migration chain

2014-10-06 Thread Ivar Lazzaro
I believe Group-based Policy (which this thread is about) will use the Neutron database configuration for its dependent database. If Neutron is configured for: connection = mysql://user:pass@locationX:3306/neutron then GBP would use: connection =

Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?

2014-10-07 Thread Ivar Lazzaro
the commit format, unit testing, and other things that would be useless to overload here. More than that, I suggest you to go on the IRC channels and look for help there. My IRC alias is ivar-lazzaro, feel free to contact me :) Last but not least, the first push in Openstack (especially if it's

Re: [openstack-dev] [Group-based Policy] Database migration chain

2014-10-07 Thread Ivar Lazzaro
of compatibility or performance issue anyone is aware of about in using cross schema FKs? Thanks, Ivar. [0] https://review.openstack.org/#/c/126383/ On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro ivarlazz...@gmail.com wrote: I believe Group-based Policy (which this thread is about) will use

Re: [openstack-dev] [Group-based Policy] Database migration chain

2014-10-10 Thread Ivar Lazzaro
. Ivar. On Fri, Oct 10, 2014 at 2:59 PM, Robert Kukura kuk...@noironetworks.com wrote: On 10/7/14 6:36 PM, Ivar Lazzaro wrote: I posted a patch that implements the Different DB Different Chain approach [0]. That does not mean that this approach is the chosen one! It's just to have a grasp

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

2014-11-18 Thread Ivar Lazzaro
There would not be a service or REST API associated with the Advanced Services code base? Would the REST API to talk to those services be part of the Neutron repository? This is a good question. Also, I would love to have more details about the following point: - The Advance Service

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

2014-11-19 Thread Ivar Lazzaro
While I agree that a unified endpoint could be a good solution for now, I think that the easiest way of doing this would be by implementing it as an external Neutron service. Using python entry_points, the advanced service extensions can be loaded in Neutron just like we do today (using

[openstack-dev] [Neutron] Embrane's Neutron Plugin

2013-07-09 Thread Ivar Lazzaro
Hi, My name is Ivar Lazzaro, I’m an Italian developer currently employed at Embrane. Embrane provides L3 to L7 network services, (including routing, load balancing, SSL offloads, firewalls and IPsec VPNs), and we have developed a Neutron plugin that we would like to share and contribute

Re: [openstack-dev] [Neutron] Embrane's Neutron Plugin

2013-07-10 Thread Ivar Lazzaro
] [Neutron] Embrane's Neutron Plugin Hi Ivar, thanks for your interest in Openstack and Neutron. A few replies inline; I hope you'll find them useful. Salvatore On 10 July 2013 02:40, Ivar Lazzaro i...@embrane.commailto:i...@embrane.com wrote: Hi, My name is Ivar Lazzaro, I’m an Italian developer

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

2014-12-09 Thread Ivar Lazzaro
I agree with Salvatore that the split is not an easy thing to achieve for vendors, and I would like to bring up my case to see if there are ways to make this at least a bit simpler. At some point I had the need to backport vendor code from Juno to Icehouse (see first attempt here [0]). That in

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

2014-12-09 Thread Ivar Lazzaro
orthogonal discussion though, it doesn't change the fact that IMHO we could handle the standard split differently. Ivar. [0] https://review.openstack.org/#/c/134680 On Tue, Dec 9, 2014 at 2:21 PM, Armando M. arma...@gmail.com wrote: On 9 December 2014 at 13:59, Ivar Lazzaro ivarlazz...@gmail.com

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

2014-12-12 Thread Ivar Lazzaro
In general, I agree with Jay about the opaqueness of the names. I see however good reasons for having user-defined unique attributes (see Clint's point about idempotency). A middle ground here could be granting to the users the ability to specify the resource ID. A similar proposal was made some

Re: [openstack-dev] [neutron] moving openvswitch ports between namespaces considered harmful

2015-02-16 Thread Ivar Lazzaro
I agree with Kevin that we should adopt veth pairs for fixing the issue in the short term, at least until CT gets merged and distributed in OVS. At that point the transition to a OVS based solution will make a lot of sense, given that the numbers show that it's worth of course ;) On Sun Feb 15

[openstack-dev] [Group-Based-Policy] Service Chain Instance ownership

2015-03-19 Thread Ivar Lazzaro
Hello Folks, [tl;dr] On implicit chains, the Service Chain Instance ownership in GBP is inconsistent, depending on the actor triggering the chain. Possible solution is to have all the implicit SCI owned by an admin, or by the provider of the chain. Any suggestion is welcome.

[openstack-dev] [Group-Based-Policy] Use cases for External Policy chains

2015-03-19 Thread Ivar Lazzaro
Hello, As a follow up on [0] I have a question for the community. There are multiple use cases for a PTG *providing* a ServiceChain which is *consumed* by an External Policy (think about LB/FW/IDS and so forth). However, given the current set of services we support, I don't see any use case for

[openstack-dev] [Group-Based-Policy] How to deal with improvements

2015-03-11 Thread Ivar Lazzaro
Hello Folks, As a follow up of [0] I was working on a proposal for adding the same sharing capabilities to servicechain constructs. While thinking about the use cases for doing this, a question came to my mind: How should I deal with this improvement from a process perspective? I'm not sure

Re: [openstack-dev] [neutron][cisco][apic] entry point for APIC agent

2015-02-20 Thread Ivar Lazzaro
Hi Ihar, That was missed for the Juno release, I'll post a patch on master and then backport it to stable/juno. Thanks for catching that, Ivar. On Fri Feb 20 2015 at 11:06:11 AM Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, does anyone know

[openstack-dev] [stable] freeze exception

2015-04-03 Thread Ivar Lazzaro
Hello Folks, I'd like to request a freeze exception for the following changeset: https://review.openstack.org/169844 I believe that's an unharmful change, I apologize for getting it under review so late :) Ivar. __

[openstack-dev] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal

2015-04-13 Thread Ivar Lazzaro
Hello Team, As per discussion in the latest GBP meeting [0] I'm hunting down all the backward incompatible changes made on DB migrations regarding the removal of unnamed constraints. In this report [1] you can find the list of affected commits. The problem is that some of the affected commits