Don't need to worry, you are perfectly right, GBP API is not replacing
Also thanks for sharing your opinion on this matter.
On Fri, Aug 8, 2014 at 5:46 PM, CARVER, PAUL pc2...@att.com wrote:
Wuhongning [mailto:wuhongn...@huawei.com] wrote:
Does it make
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
That's ok for me as well!
On Aug 8, 2014 10:04 PM, Prasad Vellanki
It sounds good
On Fri, Aug 8, 2014 at 12:44 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
Thanks Jay for your constructive feedback on this. I personally think
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
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
with a basic change in the Neutron DB code. That
should be covered by almost all CI systems.
From: Ivar Lazzaro ivarlazz...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
Date: Friday, August 15, 2014 at 3:47 PM
Quoting Stefano from a different thread :
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
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
+1 for 1700UTC Thursday on IRC
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
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,
From: Nachi Ueno [mailto:na...@ntti3.com]
Sent: Monday, January
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.
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
Embrane's CI was blocked by some nasty bugs affecting the testing
environment. It resumed yesterday (6/12) .
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
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.
On Fri, Jul 25,
On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi hemanthrav...@gmail.com
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
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
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.
On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon
of the service plugin to stackforge as suggested to
More options are obviously welcome!
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
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
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 :)
On Wed, Aug 6, 2014 at 10:21 PM, Eugene Nikanorov enikano...@mirantis.com
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.
On Wed, Aug 6, 2014 at
On Aug 6, 2014 11:08 PM, Mohammad Banikazemi m...@us.ibm.com wrote:
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
On Aug 6, 2014 11:00 PM, Edgar Magana edgar.mag...@workday.com wrote:
Of course and this is why we are having this conversation, in order to
merge our different opinions.
From: Ivar Lazzaro ivarlazz...@gmail.com
Reply-To: OpenStack Development Mailing List
+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
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
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.
On Thu, Aug 7, 2014 at 1:28 AM, Pedro Marques
Review commitment sound like a good idea. Is this aiming core reviewers
What number of cores / non cores are you ideally trying to reach?
On Fri, May 30, 2014 at 7:21 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
During the Neutron Advanced Services'
Following up the latest GBP team meeting :
As we keep going with our Juno stackforge implementation , 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
I believe Group-based Policy (which this thread is about) will use the
database configuration for its dependent database.
If Neutron is configured for:
connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
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
compatibility or performance issue anyone is aware of about in using cross
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
On Fri, Oct 10, 2014 at 2:59 PM, Robert Kukura kuk...@noironetworks.com
On 10/7/14 6:36 PM, Ivar Lazzaro wrote:
I posted a patch that implements the Different DB Different Chain
That does not mean that this approach is the chosen one! It's just to have
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
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
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
] [Neutron] Embrane's Neutron Plugin
thanks for your interest in Openstack and Neutron.
A few replies inline; I hope you'll find them useful.
On 10 July 2013 02:40, Ivar Lazzaro i...@embrane.commailto:i...@embrane.com
My name is Ivar Lazzaro, I’m an Italian developer
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 ). That in
orthogonal discussion though, it doesn't change the fact that IMHO we could
handle the standard split differently.
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
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
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
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.
As a follow up on  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
As a follow up of  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
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,
On Fri Feb 20 2015 at 11:06:11 AM Ihar Hrachyshka ihrac...@redhat.com
-BEGIN PGP SIGNED MESSAGE-
does anyone know
I'd like to request a freeze exception for the following changeset:
I believe that's an unharmful change, I apologize for getting it under
review so late :)
As per discussion in the latest GBP meeting  I'm hunting down all the
backward incompatible changes made on DB migrations regarding the removal
of unnamed constraints.
In this report  you can find the list of affected commits.
The problem is that some of the affected commits
Mail list logo