Re: [openstack-dev] [placement] The "intended purpose" of traits

Hi All, I'm quite late to the discussion, because I'm on vacation and I missed the beginning of this thread, but let me share a few thoughts. On Fri, Sep 28, 2018 at 6:13 PM Jay Pipes wrote: > * Does the provider belong to physical network "corpnet" and also > support creation of virtual NICs

Re: [openstack-dev] [neutron][nova] Small bandwidth demo on the PTG

Hi, At the demo it turned out that people were interested in a written version of the demo, so here you can find a blog post about the current state of the guaranteed minimum bandwidth feature: https://rubasov.github.io/2018/09/21/openstack-qos-min-bw-demo.html Cheers, Bence On Thu, Sep 13,

Re: [openstack-dev] [neutron] Does neutron support QinQ(vlan transparent) ?

also cc-ed this mail so he/she can chime in. Cheers, Bence Romsics On Tue, Aug 7, 2018 at 1:32 PM Sean Mooney wrote: > > TL;DR > it wont work with the ovs agent but "should" work with linux bridge. > see full message below for details. > regards > sean. > &g

Re: [openstack-dev] [horizon] bp/neutron-trunk-ui

Sorry for the double post, I forgot the subject. On Thu, Oct 12, 2017 at 2:29 PM, Bence Romsics <bence.roms...@gmail.com> wrote: > Hi Horizon Folks, > > After the PTG I'm back from vacation and I'd like to ask for reviews > for bp/neutron-trunk-ui: > > https://review.opens

[openstack-dev] [horizon]

: https://review.openstack.org/489186 The new panel should automatically appear as Project/Network/Trunks. Background info on Neutron trunks: * https://docs.openstack.org/neutron/pike/admin/config-trunking.html * https://wiki.openstack.org/wiki/Neutron/TrunkPort Thanks in advance, Bence Romsics

Re: [openstack-dev] [nova][vlan trunking] Guest networking configuration for vlan trunk

Hi Robert, I'm late to this thread, but let me add a bit. There was an attempt for trunk support in nova metadata on the Pike PTG: https://review.openstack.org/399076 But that was abandoned right after the PTG, because the agreement seemed to be in favor of putting the trunk details into the

Re: [openstack-dev] rebuild_instance (nova evacuate) failed to add trunk port

Hi, On Thu, Mar 30, 2017 at 10:14 PM, KHAN, RAO ADNAN wrote: > In Juno, there is an issue with instance rebuild (nova evacuate) when trunk > port is associated with that instance. I have a feeling you're not using the publicly available trunk port version as available in Neutron

Re: [openstack-dev] [heat][neutron]PTG session about implement Neutron Trunks resource in heat

The spec proposed can be found here: https://review.openstack.org/424571 Cheers, Bence Romsics __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org

Re: [openstack-dev] [horizon] [neutron] Horizon support for Neutron Trunks - PTL approval needed

> If this is inside the Neutron tree, then support should live in the Horizon > repo This sounds like a conclusion. So I have abandoned the requests on gerrit for the new repo. Instead I just uploaded a Horizon blueprint draft for Pike:

[openstack-dev] [horizon] [neutron] Horizon support for Neutron Trunks - PTL approval needed

And the corresponding governance change: https://review.openstack.org/428796 Please review them and if you agree approve. Or guide me to a better change. Thanks in advance, Bence Romsics [1] https://github.com/openstack/openstack-manuals/blob/master/doc/networking-guide/source/config-trunking.rst [2] https

[openstack-dev] [neutron] trunk api performance and scale measurments

. Cheers, Bence Romsics __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Nova] Expose trunk details over metadata API

Jay, let me correct myself. After a round of discussion with Armando I'm no longer sure exactly what nova changes would be needed. The discussion went into a direction where we started to question which part of the change should fall into neutron and which part into nova. I think joint

Re: [openstack-dev] [Neutron][Nova] Expose trunk details over metadata API

09:43 AM, Bence Romsics wrote: >> >> Hi, >> >> To follow up on the complications of bringing up trunk subports [1] I >> have written up a small proposal for a tiny new feature affecting >> neutron and nova. That is how to expose trunk details over metadata >&g

Re: [openstack-dev] [Neutron][Nova] Expose trunk details over metadata API

Hi, To follow up on the complications of bringing up trunk subports [1] I have written up a small proposal for a tiny new feature affecting neutron and nova. That is how to expose trunk details over metadata API. To avoid big process overhead I have opened a newton rfe ticket [2], plus a nova

Re: [openstack-dev] [Neutron] ARP spoofing in VLAN aware VMs

Hi Kuba, On Fri, Sep 30, 2016 at 3:38 PM, Jakub Libosvar wrote: > The issue was with subports having different MAC addresses > than MAC address of the parent port. Packets leaving virtual instance via > VLAN interfaces (e.g. eth0.1) have always source MAC address of VLAN

[openstack-dev] [neutron] place of subport details in the API

implemented approach I guess we can drop the get_subports action, right? Cheers, Bence Romsics __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Neutron] IRC meeting for VLAN-aware VM's

Today there's no IRC meeting dedicated to the trunk port work. Most of the discussion is going on in gerrit: https://review.openstack.org/#/q/topic:bp/vlan-aware-vms+-status:abandoned Or here in the mailing list. If you feel the need for it let us know and we can easily revive it. -- Bence On

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

and the change had to be reverted recently. Would be good to hear your opinions on how to solve the remaining problems. Bence Romsics On Wed, Jun 15, 2016 at 8:01 PM, Peters, Rawlin <rawlin.pet...@hpe.com> wrote: > On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub) wrote: >> &

Re: [openstack-dev] [neutron] extension implemented by multiple plugins

stuff. Thanks. Cheers, Bence On Tue, Aug 18, 2015 at 4:02 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/18/2015 03:11 PM, Bence Romsics wrote: Hi Ihar, Thank you. Just rebased my patch and following the example of the qos feature now I

Re: [openstack-dev] [neutron] extension implemented by multiple plugins

(the 'extension_alias' property seems to be better not used, or I still have the same error). Is that intentional? Cheers, Bence On Mon, Aug 17, 2015 at 4:46 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/17/2015 04:35 PM, Bence Romsics wrote: Hi

[openstack-dev] [neutron] extension implemented by multiple plugins

Hi All, How do I implement one extension by two plugins? If I extend the API by: * a first class resource, and * attributes to an already existing resource (the port resource in my case). These two parts don't make sense without each other, so I'd like to keep this as one extension, not two.

Re: [openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.

a noop driver should look like it is present (in the list of available extensions), but does nothing. The patch in review #23160 believes an other way and makes the noop driver look like as if it wasn't even present. Which may lead to your current bug. Best regards, Bence Romsics On Sat, Oct 19

Re: [openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.

Hi, When firewall_driver is set to NoopFirwallDriver in Neutron agent, uses can create security group and its rules, but no packet filtering is enforced. If neutron security group is enabled, users should expect packet filtering is enabled I think this behavior is confusing from Neutron API