Re: [openstack-dev] [neutron][ml2] - driver capability/feature verification framework

RFE is at https://bugs.launchpad.net/neutron/+bug/1673142. -Bob On 3/13/17 2:37 PM, Robert Kukura wrote: Hi Kevin, I will file the RFE this week. -Bob On 3/13/17 2:05 PM, Kevin Benton wrote: Hi, At the PTG we briefly discussed a generic system for verifying that the appropriate

Re: [openstack-dev] [neutron][ml2] - driver capability/feature verification framework

Hi Kevin, I will file the RFE this week. -Bob On 3/13/17 2:05 PM, Kevin Benton wrote: Hi, At the PTG we briefly discussed a generic system for verifying that the appropriate drivers are enforcing a particular user-requested feature in ML2 (e.g. security groups, qos, etc). Is someone

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

+1 On 2/17/17 2:18 PM, Kevin Benton wrote: Hi all, I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere near the venue for dinner/drinks. If you're interested, please reply to this email with a "+1" so I can get a general count for a reservation. Cheers, Kevin

Re: [openstack-dev] Why ML2 does not supprot update network provider attributes

I'm not sure unbinding ports is necessary unless the segment that a port has bound is removed or modified. A reasonable compromise might be for ML2 to allow adding new segments, which should not require unbinding/rebinding ports, but not allow removing or modifying existing segments. -Bob

Re: [openstack-dev] [neutron] Social at the summit

+1 On 4/25/16 1:07 PM, Kyle Mestery wrote: OK, there is enough interest, I'll find a place on 6th Street for us and get a reservation for Thursday around 7 or so. Thanks folks! On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han wrote: +1 :) Han Zhou Irc: zhouhan On Monday,

Re: [openstack-dev] [Neutron]Relationship between physical networks and segment

My answers below are from the perspective of normal (non-routed) networks implemented in ML2. The support for routed networks should build on this without breaking it. On 3/29/16 3:38 PM, Miguel Lavalle wrote: Hi, I am writing a patchset to build a mapping between hosts and network

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

Is Manila actually connecting (i.e. binding) something it controls to a Neutron port, similar to how a Neutron L3 or DHCP agent connects a network namespace to a port? Or does it just need to know the details about a port bound for a VM (or a service)? If the former, it should probably be

Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

The process_[create|update]_resource() extension driver methods are intended to validate user input. Exceptions raised by these need to be returned to users so they know what they did wrong. These exceptions should not be logged as anything higher than info level, since user errors generally

Re: [openstack-dev] [neutron] Adding results to extension callbacks (ml2 port_update ext handling).

I haven't had a chance to review this patch in detail yet, but am wondering if this is being integrated with ML2 as an extension driver? If so, that should clearly address how dictionaries are extended and input values are validated. If not, why? -Bob On 7/13/15 10:50 PM, Miguel Angel Ajo

Re: [openstack-dev] [GBP][Heat] Group-based Policy plug-in for Heat

Zane, I will fix this (and the other GBP packages) as soon as I possibly can. I agree it would be better to move the GBP heat support into the heat repo, either main tree or /contrib, but others on the GBP team would most likely handle that. Seem reasonable for liberty. Thanks, -Bob On

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

From a driver's perspective, it would be simpler, and I think sufficient, to change ML2 to call initialize() on drivers after the forking, rather than requiring drivers to know about forking. -Bob On 6/8/15 2:59 PM, Armando M. wrote: Interestingly, [1] was filed a few moments ago: [1]

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

I believe that, on the stable branch at least, we need to fix the migrations so that upgrades are possible. This probably means fixing them the same way on the master branch first and backporting the fixes to stable/juno. All migrations that were present in the initial juno release need to be

Re: [openstack-dev] ML2 port binding?

Hi Harish, Port binding in ML2 is the process by which a mechanism driver (or once https://blueprints.launchpad.net/openstack/?searchtext=ml2-hierarchical-port-binding is merged, potentially a set of mechanism drivers) is selected for the port, determining how connectivity is provided for that

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

Assuming I still have a vote, I vote +1 for adding Henry and Kevin, both of whom I am confident will do a great job as core reviewer. I'd ask people to consider voting against dropping me from core (and I vote -1 on that if I get a vote). During Juno, my plan was to balance my time between

[openstack-dev] [Neutron][ML2] no ML2 IRC meeting today

Let's skip the ML2 IRC meeting this week, while some people are still traveling and/or recovering. Next week I hope to have good discussions regarding a common ML2 driver repo vs. separate repos per vendor, as well as the ML2 BPs for Kilo. -Bob

Re: [openstack-dev] [Neutron] Why doesn't ml2-ovs work when it's host != the dhcp agent's host?

Hi Noel, The ML2 plugin uses the binding:host_id attribute of port to control port binding. For compute ports, nova sets binding:host_id when creating/updating the neutron port, and ML2's openvswitch mechanism driver will look in agents_db to make sure the openvswitch L2 agent is running on

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

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 of what the change looks like. The Same DB different chain solution is much simpler to

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

If you are thinking about adding a new neutron core plugin, please consider whether you could accomplish what you need with an ML2 MechanismDriver instead. Its a lot less code to write, review, and maintain. -Bob On 10/6/14 12:51 AM, thanh le giang wrote: Hi all I want to add a plugin to

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

can't agree on whether GBP is in an experimentation/rapid-prototyping phase vs. an almost-ready-to-beta-test phase, I don't see how can we get consensus on the next steps for its development. -Bob On Wed, Sep 10, 2014 at 7:22 AM, Robert Kukura kuk...@noironetworks.com mailto:kuk

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

On 9/9/14, 7:51 PM, Jay Pipes wrote: On 09/09/2014 06:57 PM, Kevin Benton wrote: Hi Jay, The main component that won't work without direct integration is enforcing policy on calls directly to Neutron and calls between the plugins inside of Neutron. However, that's only one component of GBP.

Re: [openstack-dev] [neutron] Status of Neutron at Juno-3

Kyle, Please consider an FFE for https://blueprints.launchpad.net/neutron/+spec/ml2-hierarchical-port-binding. This was discussed extensively at Wednesday's ML2 meeting, where the consensus was that it would be valuable to get this into Juno if possible. The patches have had core reviews

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

Sure, Horizon (or Heat) support is not always required for new features entering incubation, but when a goal in incubating a feature is to get it packaged with OpenStack distributions and into the hands of as many early adopters as possible to gather feedback, these integrations are very

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

One thing to keep in mind is that the ML2 driver API does sometimes change, requiring updates to drivers. Drivers that are in-tree get updated along with the driver API change. Drivers that are out-of-tree must be updated by the owner. -Bob On 8/13/14, 6:59 AM, ZZelle wrote: Hi, The

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

On 8/11/14, 4:52 AM, Thierry Carrez wrote: gustavo panizzo (gfa) wrote: only one think i didn't like it why all url,api, etc has to include the word 'preview'? i imagine that i would be consuming the new feature using heat, puppet, local scripts, custom horizon, whatever. Why do you make me

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

(english name: The Leopard) On 8 August 2014 22:21, Robert Kukura kuk...@noironetworks.com mailto:kuk...@noironetworks.com wrote: [Note - I understand there are ongoing discussion that may lead to a proposal for an out-of-tree incubation process for new Neutron features

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

[Note - I understand there are ongoing discussion that may lead to a proposal for an out-of-tree incubation process for new Neutron features. This is a complementary proposal that describes how our existing development process can be used to stabilize new features in-tree over the time frame

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

On 8/4/14, 4:27 PM, Mark McClain wrote: All- tl;dr * Group Based Policy API is the kind of experimentation we be should attempting. * Experiments should be able to fail fast. * The master branch does not fail fast. * StackForge is the proper home to conduct this experiment. The disconnect

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

, slight enhancements to Nova would allow using commands such as nova boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic epg-id=endpoint-group-uuid -Bob Thanks Gary From: Robert Kukura kuk...@noironetworks.com mailto:kuk...@noironetworks.com Reply-To: OpenStack List openstack

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

in Nova's Neutron integration would handle the epg-id by passing it to create_endpoint, and then using the port_id that is returned in the result. -Bob Thanks Gary From: Robert Kukura kuk...@noironetworks.com mailto:kuk...@noironetworks.com Reply-To: OpenStack List openstack-dev

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

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 in on the specifics of how we intend to do that integration. But if what you

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

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 design for integration with Neutron core, I would be worried about

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

On 5/23/14, 3:07 PM, Paul Michali (pcm) wrote: Thanks for the comments Gary! Typically, the device driver (backend) and service driver, for a provider won't have any database requirements (at least for VPN). For the Cisco VPN, the service driver has one additional table that it maintains

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

On 5/21/14, 4:59 PM, Kyle Mestery wrote: Neutron cores, please vote +1/-1 for the proposed addition of Carl Baldwin to Neutron core. +1 -Bob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

[openstack-dev] [Neutron][ML2] No ML2 sub-team meeting today (4/30/2014)

Today's ML2 sub-team meeting is cancelled. -Bob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Multiprovider API documentation

On 4/10/14, 6:35 AM, Salvatore Orlando wrote: The bug for documenting the 'multi-provider' API extension is still open [1]. The bug report has a good deal of information, but perhaps it might be worth also documenting how ML2 uses the segment information, as this might be useful to understand

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

another topic, it would be easier to follow. FYI, robert kukura is currently refactoring the MD binding, please have a look here : https://bugs.launchpad.net/neutron/+bug/1276391. As i understand, there won't be priority between MD that can bind a same port. The first that will respond

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

On 3/7/14, 3:53 AM, Édouard Thuleau wrote: Yes, that sounds good to be able to load extensions from a mechanism driver. But another problem I think we have with ML2 plugin is the list extensions supported by default [1]. The extensions should only load by MD and the ML2 plugin should only

Re: [openstack-dev] [neutron]The mechanism of physical_network segmentation_id is logical?

On 02/24/2014 07:09 AM, 黎林果 wrote: Hi stackers, When create a network, if we don't set provider:network_type, provider:physical_network or provider:segmentation_id, the network_type will be from cfg, but the other tow is from db's first record. Code is (physical_network,

Re: [openstack-dev] [neutron][ml2] Port binding information, transactions, and concurrency

On 02/10/2014 05:46 AM, Mathieu Rohon wrote: Hi, one other comment inline : Hi Mathieu, see below: On Wed, Feb 5, 2014 at 5:01 PM, Robert Kukura rkuk...@redhat.com wrote: On 02/05/2014 09:10 AM, Henry Gessau wrote: Bob, this is fantastic, I really appreciate all the detail. A couple

Re: [openstack-dev] [neutron][ml2] Port binding information, transactions, and concurrency

... On Wed, Feb 05, at 2:16 am, Robert Kukura rkuk...@redhat.com wrote: A couple of interrelated issues with the ML2 plugin's port binding have been discussed over the past several months in the weekly ML2 meetings. These effect drivers being implemented for icehouse, and therefore need to be addressed

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

On 02/10/2014 06:28 PM, Mark McClain wrote: All- I’d like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg has been valuable contributor to Neutron by actively reviewing, working on bugs, and contributing code. Neutron cores please reply back with +1/0/-1 votes. +1

Re: [openstack-dev] [nova][neutron][ml2] Proposal to support VIF security, PCI-passthru/SR-IOV, and other binding-specific data

On 01/31/2014 03:47 PM, Robert Kukura wrote: On 01/29/2014 10:26 AM, Robert Kukura wrote: The neutron patch [1] and nova patch [2], proposed to resolve the get_firewall_required should use VIF parameter from neutron bug [3], replace the binding:capabilities attribute in the neutron

Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id

On 02/09/2014 12:56 PM, Kyle Mestery wrote: On Feb 6, 2014, at 5:24 PM, Vinay Bannai vban...@gmail.com wrote: Hello Folks, We are running into a situation where we are not able to create multiple provider networks with the same VLAN id. We would like to propose a solution to remove this

Re: [openstack-dev] Agenda for todays ML2 Weekly meeting

On 02/05/2014 06:06 AM, trinath.soman...@freescale.com wrote: Hi- Kindly share me the agenda for today weekly meeting on Neutron/ML2. I just updated https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_February_5.2C_2014. Mestery has a conflict for today's meeting. -Bob

Re: [openstack-dev] [neutron][ml2] Port binding information, transactions, and concurrency

On 02/05/2014 09:10 AM, Henry Gessau wrote: Bob, this is fantastic, I really appreciate all the detail. A couple of questions ... On Wed, Feb 05, at 2:16 am, Robert Kukura rkuk...@redhat.com wrote: A couple of interrelated issues with the ML2 plugin's port binding have been discussed over

[openstack-dev] [neutron][ml2] Port binding information, transactions, and concurrency

A couple of interrelated issues with the ML2 plugin's port binding have been discussed over the past several months in the weekly ML2 meetings. These effect drivers being implemented for icehouse, and therefore need to be addressed in icehouse: * MechanismDrivers need detailed information about

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

On 01/30/2014 03:44 PM, Robert Li (baoli) wrote: Hi, We made a lot of progress today. We agreed that: -- vnic_type will be a top level attribute as binding:vnic_type -- BPs: * Irena's https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for binding:vnic_type *

Re: [openstack-dev] [nova][neutron][ml2] Proposal to support VIF security, PCI-passthru/SR-IOV, and other binding-specific data

On 01/29/2014 10:26 AM, Robert Kukura wrote: The neutron patch [1] and nova patch [2], proposed to resolve the get_firewall_required should use VIF parameter from neutron bug [3], replace the binding:capabilities attribute in the neutron portbindings extension with a new binding:vif_security

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Thanks, Sandhya From: Irena Berezovsky ire...@mellanox.com mailto:ire...@mellanox.com Date: Thursday, January 30, 2014 4:13 PM To: Robert Li (baoli) ba...@cisco.com mailto:ba...@cisco.com, Robert Kukura rkuk...@redhat.com mailto:rkuk...@redhat.com, Sandhya Dasu sad...@cisco.com mailto:sad

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

-through SRIOV on Jan. 29th On 29 January 2014 23:50, Robert Kukura rkuk...@redhat.com mailto:rkuk...@redhat.com wrote: On 01/29/2014 05:44 PM, Robert Li (baoli) wrote: Hi Bob, that's a good find. profileid as part of IEEE 802.1br needs to be in binding:profile

[openstack-dev] [nova][neutron][ml2] Proposal to support VIF security, PCI-passthru/SR-IOV, and other binding-specific data

The neutron patch [1] and nova patch [2], proposed to resolve the get_firewall_required should use VIF parameter from neutron bug [3], replace the binding:capabilities attribute in the neutron portbindings extension with a new binding:vif_security attribute that is a dictionary with several keys

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

On 01/29/2014 09:46 AM, Robert Li (baoli) wrote: Another issue that came up during the meeting is about whether or not vnic-type should be part of the top level binding or part of binding:profile. In other words, should it be defined as binding:vnic-type or binding:profile:vnic-type. I'd

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

(or host aggregate or whatever) pre-configured by the admin? -Bob If it's not appropriate, then I agree with you we may need another extension. --Robert On 1/29/14 4:57 PM, Robert Kukura rkuk...@redhat.com wrote: On 01/29/2014 09:46 AM, Robert Li (baoli) wrote: Another issue

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

On 01/16/2014 04:43 AM, Mathieu Rohon wrote: Hi, your proposals make sense. Having the firewall driver configuring so much things looks pretty stange. Agreed. I fully support proposed fix 1, adding enable_security_group config, at least for ml2. I'm not sure whether making this sort of

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

view on that. But a decision on D can be deferred for now, at least until we have a choice of firewall drivers. -Bob 2014/1/16 Robert Kukura rkuk...@redhat.com: On 01/16/2014 04:43 AM, Mathieu Rohon wrote: Hi, your proposals make sense. Having the firewall driver configuring so much

Re: [openstack-dev] [oslo.config] Centralized config management

On 01/09/2014 02:34 PM, Nachi Ueno wrote: Hi Doug 2014/1/9 Doug Hellmann doug.hellm...@dreamhost.com: On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno na...@ntti3.com wrote: Hi folks Thank you for your input. The key difference from external configuration system (Chef, puppet etc) is

Re: [openstack-dev] [Neutron] ML2 improvement, more extensible and more modular

On 12/04/2013 05:37 AM, Zang MingJie wrote: Hi, all: I have already written a patch[1] which makes ml2 segment more extensible, where segments can contains more fields other than physical network and segmentation id, but there is still a lot of work to do to make the ml2 more extensible.

Re: [openstack-dev] [Neutron] L3 agent external networks

On 12/03/2013 04:23 AM, Sylvain Afchain wrote: Hi, I was reviewing this patch (https://review.openstack.org/#/c/52884/) from Oleg and I thought that is a bit tricky to deploy an l3 agent with automation tools like Puppet since you have to specify the uuid of a network that doesn't

Re: [openstack-dev] [Neutron] Find the compute host on which a VM runs

On 11/21/2013 04:20 AM, Stefan Apostoaie wrote: Hello again, I studied the portbindings extension (the quantum.db.portbindings_db and quantum.extensions.portbindings modules). However it's unclear for me who sets the portbindings.HOST_ID attribute. I ran some tests with OVS: called quantum

Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation

On 11/18/2013 03:25 PM, Edgar Magana wrote: Developers, This topic has been discussed before but I do not remember if we have a good solution or not. The ML2 plugin addresses this by calling each MechanismDriver twice. The create_network_precommit() method is called as part of the DB

Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation

, Robert Kukura rkuk...@redhat.com wrote: On 11/18/2013 03:25 PM, Edgar Magana wrote: Developers, This topic has been discussed before but I do not remember if we have a good solution or not. The ML2 plugin addresses this by calling each MechanismDriver twice. The create_network_precommit

Re: [openstack-dev] [Neutron] tempest failure: No more IP addresses available on network

On 10/23/2013 07:22 PM, Nachi Ueno wrote: Hi folks This patch was the culprit, so we have reverted it. https://review.openstack.org/#/c/53459/1 (Note, this is revert of revert ) However even if it is reverted, the error happens

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

On 09/10/2013 10:45 AM, Mark McClain wrote: I think Gary and Kyle have answered this very well; however I do have a few things to add. It is definitely too late for Havana, so Icehouse is next available release for new plugins. I can work with you offline to find you a core sponsor. One

Re: [openstack-dev] [Neutron] Proposal to add new neutron-core members

On 07/23/2013 03:15 PM, Mark McClain wrote: All- I'd like to propose that Kyle Mestery and Armando Migliaccio be added to the Neutron core team. Both have been very active with valuable reviews and contributions to the Neutron community. Neutron core team members please respond with

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

On 07/11/2013 04:30 PM, Aaron Rosen wrote: Hi, I think we should revert this patch that was added here (https://review.openstack.org/#/c/29767/). What this patch does is when nova-compute calls into quantum to create the port it passes in the hostname on which the instance was booted on.