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
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 plan
+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 B
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
O
+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, April 25, 2016, Korzen
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
segments.
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 usin
The process_[create|update]_() 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 are not of
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 wro
Hi Swami,
My fix for 1367391 will eventually eliminate the special DVRPortBinding
table, so would presumably eliminate this bug, but you are correct that
the current WIP patch (https://review.openstack.org/#/c/189410/) isn't
quite that far along yet. I'll look for an interim fix.
-Bob
On 6
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 6/17/
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] https:
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 r
Kyle, What happened to the long-term potential goal of ML2 driver APIs
becoming neutron's core APIs? Do we really want to encourage new
monolithic plugins?
ML2 is not a control plane - its really just an integration point for
control planes. Although co-existence of multiple mechanism drivers
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
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 neu
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
___
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 t
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
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 th
ons may still be the real issues:-( . If we 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, Robe
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.
Al
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 from
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 impo
Actually, whether the incubator is involved for not, this might be a
great candidate for implementation using an ML2 extension driver. See
https://review.openstack.org/#/c/89211/ for the code under review for
Juno, and also
https://docs.google.com/a/noironetworks.com/document/d/14T-defRnFl6M2xR
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 import
arity about
exactly what inclusion would mean can't hurt that discussion.
Thanks for your indulgence as well,
-Bob
Have a good weekend,
Salvatore
[1] Quote from "Il Gattopardo" by Giuseppe Tomasi di Lampedusa
(english name: The Leopard)
On 8 August 2014 22:21, Robert Kukur
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 to
[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 of
e 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 <mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List <mailto:openstack-dev@lists.openstack
to Nova. Later,
slight enhancements to Nova would allow using commands such as "nova
boot ... --nic ep-id= ..." or "nova boot ... --nic
epg-id= ...".
-Bob
Thanks
Gary
From: Robert Kukura <mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List <mailto:openstack-dev
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 her
On 5/23/14, 10:54 PM, Armando M. wrote:
On 23 May 2014 12:31, Robert Kukura 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
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 for
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 tha
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
http://lists.openstack.org/cgi-bin/mailm
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
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
create 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 fi
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
im
tch
monolithic plugin, since that is being deprecated.
>
> what's your opinion?
If I understand it correctly, I agree this feature could be useful.
-Bob
>
> Thanks!
>
> 2014-02-24 21:50 GMT+08:00 Robert Kukura :
>> On 02/24/2014 07:09 AM, 黎林果 wrote:
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,
>
gt; questions ...
>>
>> On Wed, Feb 05, at 2:16 am, Robert Kukura 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 d
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 wrote:
>> On 02/05/2014 09:10 AM, Henry Gessau wrote:
>>> Bob, this is fantastic, I really apprecia
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.
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:capabi
On 02/09/2014 12:56 PM, Kyle Mestery wrote:
> On Feb 6, 2014, at 5:24 PM, Vinay Bannai 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 restr
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 wrote:
>
>> A couple of interrelated issues with the ML2 plugin's port binding have
>&
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
>
>
>
>
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 al
stack-dev@lists.openstack.org>>
> Date: Monday, February 3, 2014 3:14 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> <mailto:openstack-dev@lists.openstack.org>>, Irena Berezovsky
> mailto:ire...@mellanox.com>>, "Robert Li (baoli)
it. This approach is a prime
example of the "modular" goal of "Modular Layer 2".
-Bob
>
> Thanks,
> Sandhya
>
> From: Irena Berezovsky mailto:ire...@mellanox.com>>
> Date: Thursday, January 30, 2014 4:13 PM
> To: "Robert Li (baoli)" m
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
>
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
>
dev] [nova][neutron] PCI pass-through SRIOV on
> Jan. 29th
>
>
>
> On 29 January 2014 23:50, Robert Kukura <mailto:rkuk...@redhat.com>> wrote:
>
> On 01/29/2014 05:44 PM, Robert Li (baoli) wrote:
> > Hi Bob,
> >
> &
e?
Isn't all this kind of detail hidden from a normal user within the nova
VM flavor (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 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
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
gt;>>>
>>>> (A) Remove firewall_driver from server side
>>>>Remove Noop <-- I'll write patch for this
This gets replaced with the enable_security_groups server config, right?
>>>>
>>>> (B) update ML2 with extend_port_dict <-- B
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
ch
On 01/09/2014 02:34 PM, Nachi Ueno wrote:
> Hi Doug
>
> 2014/1/9 Doug Hellmann :
>>
>>
>>
>> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
>>>
>>> Hi folks
>>>
>>> Thank you for your input.
>>>
>>> The key difference from external configuration system (Chef, puppet
>>> etc) is integration wit
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 extensibl
On 11/28/2013 07:01 AM, Gopi Krishna B wrote:
>
> Hi
> I am configuring Havana on fedora 19. Observing the below errors in case
> of neutron.
> Please help me resolve this issue.
> copied only few lines from the server.log, in case full log is
> required, let me know.
You may have resolved this
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 a
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 qua
> Thanks,
>
> Edgar
>
> On 11/18/13 12:55 PM, "Robert Kukura" 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
>>
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
tran
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
> http://logstash.openstack.org/index.html#eyJzZWFyY2giOi
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.
O
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 w
On 07/15/2013 03:54 PM, Aaron Rosen wrote:
>
>
>
> On Sun, Jul 14, 2013 at 6:48 PM, Robert Kukura <mailto:rkuk...@redhat.com>> wrote:
>
> On 07/12/2013 04:17 PM, Aaron Rosen wrote:
> > Hi,
> >
> >
> > On Fri, Jul 1
On 07/12/2013 04:17 PM, Aaron Rosen wrote:
> Hi,
>
>
> On Fri, Jul 12, 2013 at 6:47 AM, Robert Kukura <mailto:rkuk...@redhat.com>> wrote:
>
> On 07/11/2013 04:30 PM, Aaron Rosen wrote:
> > Hi,
> >
> > I think we should revert
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
73 matches
Mail list logo
