Re: [openstack-dev] [heat][neutron] Extraroute support

[Kevin Benton]

The neutron API now supports compare and swap updates with an If-Match
header so the race condition can be avoided.
https://bugs.launchpad.net/neutron/+bug/1703234



On Fri, Jun 1, 2018, 04:57 Rabi Mishra  wrote:

>
> On Fri, Jun 1, 2018 at 3:57 PM, Lajos Katona 
> wrote:
>
>> Hi,
>>
>> Could somebody help me out with Neutron's Extraroute support in Hot
>> templates.
>> The support status of the Extraroute is support.UNSUPPORTED in heat, and
>> only create and delete are the supported operations.
>> see:
>> https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/neutron/extraroute.py#LC35
>>
>>
> As I see the unsupported tag was added when the feature was moved from the
>> contrib folder to in-tree (https://review.openstack.org/186608)
>> Perhaps you can help me out why only create and delete are supported and
>> update not.
>>
>>
> I think most of the resources when moved from contrib to in-tree are
> marked as unsupported. Adding routes to an existing router by multiple
> stacks can be racy and is probably the reason use of this resource is not
> encouraged and hence it's not supported. You can see the discussion in the
> original patch that proposed this resource
> https://review.openstack.org/#/c/41044/
>
> Not sure if things have changed on neutron side for us to revisit the
> concerns.
>
> Also it does not have any update_allowed properties, hence no
> handle_update(). It would be replaced if you change any property.
>
> Hope it helps.
>
>
>
>> Thanks in advance for  the help.
>>
>> Regards
>> Lajos
>>
>>
>> __
>> 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
>>
>
>
>
> --
> Regards,
> Rabi Mishra
>
> __
> 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
>
__
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] Prevent ARP spoofing

[Kevin Benton]

I understand. I think you will likely need to run a bit of custom code for
Pike if you want to override the default behavior of the port security
extension. You should be able to use something like the following
(untested) code as a service plugin. Install it somewhere on the server and
then put the import path to it in the service_plugins configuration.




from neutron_lib.api.definitions import port_security
from neutron_lib.callbacks import events
from neutron_lib.callbacks import registry
from neutron_lib.callbacks import resources
from neutron_lib.services import base


@registry.has_registry_receivers
class NetdefaultPortSecurity(base.ServicePluginBase):

@registry.receives(resources.NETWORK, [events.BEFORE_CREATE])
def force_default_portsec_false(self, rtype, event, trigger, context,
network, **kwargs):
network[port_security.PORTSECURITY] = False

@classmethod
def get_plugin_type(cls):
return 'portsecdefaultoverride'

def get_plugin_description(self):
return "workaround"



To have this fixed in future versions I suggest filing an RFE to allow all
security to be disabled completely if the port security extension isn't
loaded.

On Mon, Mar 19, 2018 at 9:34 AM, Vadim Ponomarev <ponoma...@selectel.ru>
wrote:

> If I understood correctly, you talk about rules which are generated by
> security_group extension as default from the fixed_ips +
> allowed_address_pairs list. In our openstack installation we disabled the
> security_group and the allowed_address_pairs extensions to simplify the
> configuration the HA clusters.
>
> Currently we configure the neutron as follows:
> 1. prevent_arp_spoofing = False
> 2. disable security_group extension
> 3. disable allowed_address_pairs extension
>
> Actually, if port_security will be like a "central regulator" which
> controll all mechanisms, it's perfectly in our case. But, we will lose
> flexibility, because we can't changed default value for this option. And,
> even if we disable the port_security extension in the neutron, the prevent
> ARP-spoofing mechanism will work as default [1].
>
> It's very important question, how do we may disable globally the prevent
> ARP spoofing in the Pike release? To create all networks without specifying
> an option port_security_enabled=False.
>
> Changes that were proposed by Tatiana, just let save current flexability.
>
> [1] https://github.com/openstack/neutron/blob/stable/pike/
> neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L907
>
> 2018-03-19 16:24 GMT+03:00 Kevin Benton <ke...@benton.pub>:
>
>> Disabling ARP spoofing protection alone will not let the standby instance
>> source traffic using the active instance's IP. IP filtering rules
>> independent of ARP enforcement rules ensure the source IP is in the
>> fixed_ips or allowed_address_pairs.
>>
>> Are you already using allowed address pairs to add the shared IP to both?
>>
>> On Mon, Mar 19, 2018, 22:13 Vadim Ponomarev <ponoma...@selectel.ru>
>> wrote:
>>
>>> Yes, there's really a need for mechanisms of high availability like
>>> corosync, vrrp etc. Another simple example: we have two servers with the
>>> active/standby HA configuration  (for example keepalived + haproxy) and we
>>> have third-party monitoring system for these servers. The monitoring system
>>> gets some load metrics and when one of the servers is unavailable, the
>>> monitoring system scales architecture (adds new server to cluster) in this
>>> way saving the HA architecture. In your case, this monitoring system must
>>> do the following steps: create new instance, add new instance's MAC address
>>> to allowed_address_pairs and only after that reconfigure all other nodes.
>>> Otherwise cluster will not work. The solution to the problem is simple -
>>> disable the prevent ARP spoofing mechnism.
>>>
>>> Ok, we may used port_security options for this network with the HA
>>> cluster. For this case we must reconfigure our monitoring systems, create
>>> allowed_address_pairs for all current servers and (it's hardest) train our
>>> users how that done.
>>>
>>> Currently, we don't use the prevent ARP spoofing option
>>> (prevent_arp_spoofing = False) and honestly I don't understand why this
>>> option is enabled as default in private networks. Each such network belongs
>>> to one user, who controls all instances. Who would decide to perform a MITM
>>> attack in his own network?
>>>
>>> 2018-03-19 12:53 GMT+03:00 Kevin Benton <ke...@benton.pub>:
>>>
>>>> Do you need to spoof arbitrary addresses? If not (i.e. a set you know
>

Re: [openstack-dev] [neutron]Does neutron-server support the main backup redundancy？

[Kevin Benton]

You can run as many neutron server processes as you want in an
active/active setup.

On Tue, Mar 20, 2018, 18:35 Frank Wang  wrote:

> Hi All,
>  As far as I know, neutron-server only can be a single node, In order
> to improve the reliability of the system, Does it support the main backup
> or active/active redundancy? Any comment would be appreciated.
>
> Thanks,
>
>
>
> __
> 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
>
__
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] Prevent ARP spoofing

[Kevin Benton]

Disabling ARP spoofing protection alone will not let the standby instance
source traffic using the active instance's IP. IP filtering rules
independent of ARP enforcement rules ensure the source IP is in the
fixed_ips or allowed_address_pairs.

Are you already using allowed address pairs to add the shared IP to both?

On Mon, Mar 19, 2018, 22:13 Vadim Ponomarev <ponoma...@selectel.ru> wrote:

> Yes, there's really a need for mechanisms of high availability like
> corosync, vrrp etc. Another simple example: we have two servers with the
> active/standby HA configuration  (for example keepalived + haproxy) and we
> have third-party monitoring system for these servers. The monitoring system
> gets some load metrics and when one of the servers is unavailable, the
> monitoring system scales architecture (adds new server to cluster) in this
> way saving the HA architecture. In your case, this monitoring system must
> do the following steps: create new instance, add new instance's MAC address
> to allowed_address_pairs and only after that reconfigure all other nodes.
> Otherwise cluster will not work. The solution to the problem is simple -
> disable the prevent ARP spoofing mechnism.
>
> Ok, we may used port_security options for this network with the HA
> cluster. For this case we must reconfigure our monitoring systems, create
> allowed_address_pairs for all current servers and (it's hardest) train our
> users how that done.
>
> Currently, we don't use the prevent ARP spoofing option
> (prevent_arp_spoofing = False) and honestly I don't understand why this
> option is enabled as default in private networks. Each such network belongs
> to one user, who controls all instances. Who would decide to perform a MITM
> attack in his own network?
>
> 2018-03-19 12:53 GMT+03:00 Kevin Benton <ke...@benton.pub>:
>
>> Do you need to spoof arbitrary addresses? If not (i.e. a set you know
>> ahead of time), you can put entries in the allowed_address_pairs field of
>> the port that will allow you to send traffic using other MAC/IPs.
>>
>> On Mar 19, 2018 8:42 PM, "Vadim Ponomarev" <ponoma...@selectel.ru> wrote:
>>
>> Hi,
>>
>> I support, that is a problem. It's unclear, how after removing the option
>> prevent_arp_spoofing, I can manage the prevent ARP spoofing mechanism.
>> Example: I use security groups but I don't want to use ARP spoofing
>> protection. How do I can disable the protection?
>>
>> 2018-03-14 10:26 GMT+03:00 Tatiana Kholkina <holk...@selectel.ru>:
>>
>>> Sure, there is an ability to enable ARP spoofing for the port/network,
>>> but it is impossible to make it enabled by default for all ports.
>>> It looks a bit complicated to me and I think it would be better to have
>>> an ability to set default port security via config file.
>>>
>>> Best regards,
>>> Tatiana
>>>
>>> 2018-03-13 15:10 GMT+03:00 Claudiu Belu <cb...@cloudbasesolutions.com>:
>>>
>>>> Hi,
>>>>
>>>> Indeed ARP spoofing is prevented by default, but AFAIK, if you want it
>>>> enabled for a port / network, you can simply disable the security groups on
>>>> that neutron network / port.
>>>>
>>>> Best regards,
>>>>
>>>> Claudiu Belu
>>>>
>>>> --
>>>> *From:* Татьяна Холкина [holk...@selectel.ru]
>>>> *Sent:* Tuesday, March 13, 2018 12:54 PM
>>>> *To:* openstack-dev@lists.openstack.org
>>>> *Subject:* [openstack-dev] [neutron] Prevent ARP spoofing
>>>>
>>>> Hi,
>>>> I'm using an ocata release of OpenStack where the option
>>>> prevent_arp_spoofing can be managed via conf. But later in pike it was
>>>> removed and it was decided to prevent spoofing by default.
>>>> There are cases where security features should be disabled. As I can
>>>> see now we can use a port_security option for these cases. But this option
>>>> should be set for a particular port or network on create. The default value
>>>> is set to True [1] and itt is impossible to change it. I'd like to
>>>> suggest to get default value for port_security [2] from config option.
>>>> It would be nice to know your opinion.
>>>>
>>>> [1]
>>>> https://github.com/openstack/neutron-lib/blob/stable/queens/neutron_lib/api/definitions/port_security.py#L21
>>>> [2]
>>>> https://github.com/openstack/neutron/blob/stable/queens/neutron/objects/extensions/port_security.py#L24
>>>>
>>>> Best regards,
>

Re: [openstack-dev] [neutron] Prevent ARP spoofing

[Kevin Benton]

Do you need to spoof arbitrary addresses? If not (i.e. a set you know ahead
of time), you can put entries in the allowed_address_pairs field of the
port that will allow you to send traffic using other MAC/IPs.

On Mar 19, 2018 8:42 PM, "Vadim Ponomarev"  wrote:

Hi,

I support, that is a problem. It's unclear, how after removing the option
prevent_arp_spoofing, I can manage the prevent ARP spoofing mechanism.
Example: I use security groups but I don't want to use ARP spoofing
protection. How do I can disable the protection?

2018-03-14 10:26 GMT+03:00 Tatiana Kholkina :

> Sure, there is an ability to enable ARP spoofing for the port/network, but
> it is impossible to make it enabled by default for all ports.
> It looks a bit complicated to me and I think it would be better to have an
> ability to set default port security via config file.
>
> Best regards,
> Tatiana
>
> 2018-03-13 15:10 GMT+03:00 Claudiu Belu :
>
>> Hi,
>>
>> Indeed ARP spoofing is prevented by default, but AFAIK, if you want it
>> enabled for a port / network, you can simply disable the security groups on
>> that neutron network / port.
>>
>> Best regards,
>>
>> Claudiu Belu
>>
>> --
>> *From:* Татьяна Холкина [holk...@selectel.ru]
>> *Sent:* Tuesday, March 13, 2018 12:54 PM
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* [openstack-dev] [neutron] Prevent ARP spoofing
>>
>> Hi,
>> I'm using an ocata release of OpenStack where the option
>> prevent_arp_spoofing can be managed via conf. But later in pike it was
>> removed and it was decided to prevent spoofing by default.
>> There are cases where security features should be disabled. As I can see
>> now we can use a port_security option for these cases. But this option
>> should be set for a particular port or network on create. The default value
>> is set to True [1] and itt is impossible to change it. I'd like to
>> suggest to get default value for port_security [2] from config option.
>> It would be nice to know your opinion.
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/stable/queens/neutron_lib/api/definitions/port_security.py#L21
>> [2]
>> https://github.com/openstack/neutron/blob/stable/queens/neutron/objects/extensions/port_security.py#L24
>>
>> Best regards,
>> Tatiana
>>
>> __
>> 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
>>
>>
>
> __
> 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
>
>


-- 
Best regards,
Vadim Ponomarev
Developer of network automation department at Selectel Ltd.


This message may contain confidential information that can't be distributed
without the consent of the sender or the authorized person Selectel Ltd.
__
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
__
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] Propose Slawek Kaplonski for Neutron core

[Kevin Benton]

+1! ... even though I haven't been around. :)

On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle  wrote:

> Hi Neutron Team,
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He
> has been instrumental in the development of the QoS capabilities in
> Neutron, becoming the lead of the sub-team focused on that set of features.
> More recently, he has collaborated in the implementation of OVO and is an
> active participant in the CI sub-team. His number of code reviews during
> the Queens cycle is on par with the leading core members of the team:
> http://stackalytics.com/?module=neutron
>
> In my opinion, his efforts are highly valuable to the team and we will be
> very lucky to have him as a fully voting core.
>
> I will keep this nomination open for a week as customary,
>
> Thank you,
>
> Miguel
>
> __
> 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
>
>
__
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] [ptl][tc] Accessible upgrade support

[Kevin Benton]

Oh, I suppose it depends on what you mean by "ovs" in this context. The
Neutron OVS agent shouldn't trigger any flow losses, but restarted the OVS
vswitchd process may do that.

On Sat, Oct 7, 2017 at 2:31 AM, Sean Dague <s...@dague.net> wrote:

> On 10/06/2017 07:23 PM, Kevin Benton wrote:
>
>>  >The neutron story is mixed on accessable upgrade, because at least in
>> some cases, like ovs, upgrade might trigger a network tear down / rebuild
>> that generates an outage (though typically a pretty small one).
>>
>> This shouldn't happen. If it does it should be reported as a bug. All
>> existing OVS flows are left in place during agent initialization and we
>> don't get rid of the old ones until the agent finishes setting up the new
>> ones.
>>
>
> I thought it was literally a problem with the daemon restart where it is
> stateful and does a teardown / rebuild when started. I'd be happy to be
> wrong about that, but was told in the past that it was just an OVS
> limitation.
>
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>
__
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] [ptl][tc] Accessible upgrade support

[Kevin Benton]

>The neutron story is mixed on accessable upgrade, because at least in some
cases, like ovs, upgrade might trigger a network tear down / rebuild that
generates an outage (though typically a pretty small one).

This shouldn't happen. If it does it should be reported as a bug. All
existing OVS flows are left in place during agent initialization and we
don't get rid of the old ones until the agent finishes setting up the new
ones.

On Thu, Oct 5, 2017 at 4:42 AM, Sean Dague  wrote:

> On 10/05/2017 07:08 AM, Graham Hayes wrote:
> >
> >
> > On Thu, 5 Oct 2017, at 09:50, Thierry Carrez wrote:
> >> Matt Riedemann wrote:
> >>> What's the difference between this tag and the zero-impact-upgrades
> tag?
> >>> I guess the accessible one is, can a user still ssh into their VM while
> >>> the nova compute service is being upgraded. The zero-impact-upgrade one
> >>> is more to do with performance degradation during an upgrade. I'm not
> >>> entirely sure what that might look like, probably need operator input.
> >>> For example, while upgrading, you're live migrating VMs all over the
> >>> place which is putting extra strain on the network.
> >>
> >> The zero-impact-upgrade tag means no API downtime and no measurable
> >> impact on performance, while the accessible-upgrade means that while
> >> there can be API downtime, the resources provisioned are still
> >> accessible (you can use the VM even if nova-api is down).
> >>
> >> I still think we have too many of those upgrade tags, and amount of
> >> information they provide does not compensate the confusion they create.
> >> If you're not clear on what they mean, imagine a new user looking at the
> >> Software Navigator...
> >>
> >> In particular, we created two paths in the graph:
> >> * upgrade < accessible-upgrade
> >> * upgrade < rolling-upgrade < zero-downtime < zero-impact
> >>
> >> I personally would get rid of zero-impact (not sure there is that much
> >> additional information it conveys beyond zero-downtime).
> >>
> >> If we could make the requirements of accessible-upgrade a part of
> >> rolling-upgrade, that would also help (single path in the graph, only 3
> >> "levels"). Is there any of the current rolling-upgrade things (cinder,
> >> neutron, nova, swift) that would not qualify for accessible-upgrade as
> >> well ?
> >
> > Well, there is projects (like designate) that qualify for accessible
> > upgrade, but not rolling upgrade.
>
> The neutron story is mixed on accessable upgrade, because at least in
> some cases, like ovs, upgrade might trigger a network tear down /
> rebuild that generates an outage (though typically a pretty small one).
>
> I still think it's hard to describe to folks what is going on without
> pictures. And the tag structure might just be the wrong way to describe
> the world, because they are a set of positive assertions, and upgrade
> expectations are really about: "how terrible will this be".
>
> If I was an operator the questions I might have is:
>
> 1) Really basic, will my db roll forward?
>
> 2) When my db rolls forward, is it going to take a giant table lock that
> is effectively an outage?
>
> 3) Is whatever date I created, computes, networks going to stay up when
> I do all this? (i.e. no customer workload interuption)
>
> 4) If the service is more than 1 process, can they arbitrarily work with
> N-1 so I won't have a closet outage when services restart.
>
> 5) If the service runs on more than 1 host, can I mix host levels, or
> will there be an outage as I upgrade nodes
>
> 6) If the service talks to other openstack services, is there a strict
> version lock in which means I've got to coordinate with those for
> upgrade? If so, what order is that and is it clear?
>
> 7) Can I seamlessly hide my API upgrade behind HA-Proxy / Istio / (or
> similar) so that there is no API service interruption
>
> 8) Is there any substantial degradation in running "mixed mode" even if
> it's supported, so that I know whether I can do this over a longer
> window of time when time permits
>
> 9) What level of validation exists to ensure that any of these "should
> work" do work?
>
>
> The tags were really built around grouping a few of these, but even with
> folks that are near the problem, they got confusing quick. I really
> think that some more pictoral upgrade safety cards or something
> explaining the things you need to consider, and what parts projects
> handle for you would be really useful. And then revisit whatever the
> tagging structure is going to be later.
>
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>
__
OpenStack Development Mailing List (not for 

[openstack-dev] [neutron] team ptg photos

[Kevin Benton]

https://photos.app.goo.gl/Aqa51E2aVkv5b4ah1
__
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] Denver Team Dinner

[Kevin Benton]

+1

On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński 
wrote:

> +1
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> > Wiadomość napisana przez Miguel Lavalle  w dniu
> 12.09.2017, o godz. 17:23:
> >
> > Dear Neutrinos,
> >
> > Our social event will take place on Thursday September 12th at 7:30pm.
> The venue is going to be https://www.famousdaves.com/Denver-Stapleton. It
> is located 0.4 miles from the Renaissance Hotel, which translates to an
> easy 9 minutes walk.
> >
> > I have a reservation for a group of 30 people under my name. Please
> respond to this message with your attendance confirmation by Wednesday
> night, so I can get a more accurate head count.
> >
> > Looking forward to see y'all Thursday night
> >
> > Best regards
> >
> > Miguel
> > 
> __
> > 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
>
>
> __
> 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
>
>
__
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]OVS connection tracking cleanup

[Kevin Benton]

Can you start a bug on launchpad and upload the conntrack attachment to the
bug?

Switching to the rootwrap daemon should also help significantly.

On Mon, Sep 11, 2017 at 12:32 PM, Ajay Kalambur (akalambu) <
akala...@cisco.com> wrote:

> Hi Kevin
> The information you asked for
> For 1 compute node with 45 Vms here is the number of connection tracking
> entries getting deleted
> cat conntrack.file  | wc -l
>38528
>
> The file with output is 14MB so ill email it to Ian and he can share it if
> needed
>
> Security group rules
> Direction Ether Type IP Protocol Port Range Remote IP Prefix Remote
> Security Group Actions
> Egress IPv4 Any Any 0.0.0.0/0
> Ingress IPv6 Any Any - default
> Egress IPv6 Any Any ::/0 -
> Ingress IPv4 Any Any -
>
> Please let me know if u need the dump of conntrack entries if so I can
> email it to email address of your choice
>
>
> Ajay
>
>
>
> From: Ajay Kalambur <akala...@cisco.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, September 11, 2017 at 10:02 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron]OVS connection tracking cleanup
>
> Hi Kevin
> Thanks for your response it was about 50 vms
> Ajay
>
>
>
> On Sep 11, 2017, at 9:49 AM, Kevin Benton <ke...@benton.pub> wrote:
>
> The biggest improvement will be switching to native netlink calls:
> https://review.openstack.org/#/c/470912/
>
> How many VMs were on a single compute node?
>
> On Mon, Sep 11, 2017 at 9:15 AM, Ajay Kalambur (akalambu) <
> akala...@cisco.com> wrote:
>
>> Hi
>> I am performing a scale test and I see that after creating 500 Vms with
>> ping traffic between them it took almost 1 hr for the connection tracking
>> To clean up and ovs agent was busy doing this and unable to service any
>> new port bind requests on some computes for almost an hr
>> It took that long for conntrack clean up to complete
>>
>>
>> I see the following bug
>> https://bugs.launchpad.net/neutron/+bug/1513765
>>
>> And I also have the fix below
>> https://git.openstack.org/cgit/openstack/neutron/commit/?id=
>> d7aeb8dd4b1d122e17eef8687192cd122b79fd6e
>>
>>
>> Still see really long times for conntrack cleanup
>>
>> What is the solution to this problem in scale scenarios?
>> Ajay
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> 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
>
>
> __
> 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
>
>
__
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]OVS connection tracking cleanup

[Kevin Benton]

The biggest improvement will be switching to native netlink calls:
https://review.openstack.org/#/c/470912/

How many VMs were on a single compute node?

On Mon, Sep 11, 2017 at 9:15 AM, Ajay Kalambur (akalambu) <
akala...@cisco.com> wrote:

> Hi
> I am performing a scale test and I see that after creating 500 Vms with
> ping traffic between them it took almost 1 hr for the connection tracking
> To clean up and ovs agent was busy doing this and unable to service any
> new port bind requests on some computes for almost an hr
> It took that long for conntrack clean up to complete
>
>
> I see the following bug
> https://bugs.launchpad.net/neutron/+bug/1513765
>
> And I also have the fix below
> https://git.openstack.org/cgit/openstack/neutron/commit/?id=
> d7aeb8dd4b1d122e17eef8687192cd122b79fd6e
>
>
> Still see really long times for conntrack cleanup
>
> What is the solution to this problem in scale scenarios?
> Ajay
>
>
> __
> 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
>
>
__
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

[openstack-dev] [neutron] - transitioning PTL role to Miguel Lavalle

[Kevin Benton]

Hi everyone,

Due to a change in my role at my employer, I no longer have time to be the
PTL of Neutron. Effective immediately, I will be transitioning the PTL role
to Miguel Lavalle.

Miguel is an excellent leader in the community and has experience reviewing
patches as a core, reviewing feature requests and specs as a driver,
implementing cross-project features, handling docs, and on-boarding new
contributors.

We will make the switch official next week at the PTG with the appropriate
patches to the governance repo.

If anyone has any concerns with this transition plan, please reach out to
me, Thierry, or Doug Hellmann.

Cheers,
Kevin Benton
__
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][oslo.db] db retry madness

[Kevin Benton]

 want to support, it probably
makes more sense to use a different decorator than to adjust the existing
one.

>4d. How frequent is the problem of mutable lists and dicts, and should
this complex and actually pretty expensive behavior be optional, only for
those functions that are known to receieve mutable structures and change
them in place?

It's difficult to tell. The issue was that the retry logic was added much
later to the API level so we needed a generically safe solution to protect
every possible API operation. It's copying things passed into the API
request so they are usually dictionaries with fewer than 10 keys and values
with small strings or lists of only a few entries, making the copy
operations cheap.

If we did want to get rid of the copy operation, it would probably be
quicker to add a new decorator that doesn't copy and then slowly opt into
for each function that we validate as 'side-effect free' on the inputs.


I hope that makes sense. Let me know if you have any other questions.

Cheers,
Kevin Benton

On Thu, Sep 7, 2017 at 8:11 AM, Michael Bayer <mba...@redhat.com> wrote:

> I'm trying to get a handle on neutron's retry decorators.I'm
> assisting a developer in the networking_odl project who wishes to make
> use of neutron's retry_if_session_inactive decorator.
>
> The developer has run into several problems, including that
> networking_odl methods here seem to accept a "session" directly,
> rather than the "context" as is standard throughout neutron, and
> retry_if_session_inactive assumes the context calling pattern.
> Additionally, the retry_db_errors() decorator which is also used by
> retry_if_session_inactive is doing a deepcopy operation on arguments,
> which when applied to ORM-mapped entities, makes a copy of them which
> are then detached from the Session and they fail to function beyond
> that.
>
> For context, the developer's patch is at:
> https://review.openstack.org/#/c/500584/3
>
> and the neutron features I'm looking at can be seen when they were
> reviewed at: https://review.openstack.org/#/c/356530/22
>
>
> So I have a bunch of questions, many are asking the same things: "is
> networking_odl's pattern legacy or not?" and "is this retry decorator
> buggy?"   There's overlap in these questions.  But "yes" / "no" to
> each would still help me figure out that this is a giraffe and not a
> duck :) ("does it have a long neck?" "does it quack?" etc)
>
> 1. since the retry_if_session_inactive decorator assumes functions
> that receive a "context", what does it mean that networking_odl uses
> functions that receive a "session" and not a "context" ?   Should
> networking_odl be modified such that it accepts the same "context"
> that Neutron passes around?
>
> 2. Alternatively, should the retry_if_session_inactive decorator be
> modified (or a new decorator added) that provides the identical
> behavior for functions that receive a "session" argument rather than a
> "context" argument ?  (or should this be done anyway even if
> networking_odl's pattern is legacy?)
>
> 3. I notice that the session.is_active flag is considered to be
> meaningful.   Normally, this flag is of no use, as the enginefacade
> pattern only provides for a Session that has had the begin() method
> called.  However, it looks like in neutron_lib/context.py, the Context
> class is providing for a default session
> "db_api.get_writer_session()", which I would assume is how we get a
> Session with is_active is false:
>
> 3a.  Is this a temporary measure to work around legacy patterns?
> 3b.  If 3a., is the pattern in use by networking_odl, receiving a
> "session" and not "context", the specific legacy pattern in question?
> 3c.  if 3a and 3b, are we expecting all the various plugins to
> start using "context" at some point ?  (and when they come to me with
> breakage, I can push them in that direction?)
>
> 4. What is the bug we are fixing by using deepcopy() with the
> arguments passed to the decorated function:
>
> 4a.  Is it strictly that simple mutable lists and dicts of simple
> types (ints, strings, etc.) are preserved across retries, assuming the
> receiving functions might be modifying them?
>
> 4b. Does this deepcopy() approach have any support for functions
> that are being passed not just simple structures but ORM-mapped
> objects?   Was this use case considered?
>
> 4c. Does Neutron's model base have any support for deepcopy()?  I
> notice that the base classes in model_base do **not** seem to have a
> __deepcopy__ present.  This would mean that this deepcopy() will
> definite

Re: [openstack-dev] [neutron] out-of-tree l3 service providers

[Kevin Benton]

Please add the requirements underneath the l3 flavors section of the
etherpad so we can come up with a plan during the PTG.

On Thu, Sep 7, 2017 at 11:04 PM, Isaku Yamahata <isaku.yamah...@gmail.com>
wrote:

> On Fri, Sep 08, 2017 at 12:26:56PM +0900,
> Takashi Yamamoto <yamam...@midokura.com> wrote:
>
> > hi,
> >
> > On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata <isaku.yamah...@gmail.com>
> wrote:
> > > Hi.
> > >
> > > Any update on this? Now L3 service provider got the time slot at the
> PTG.
> > >
> > > Yamamoto, do you have any proposal for the interface?
> >
> > no
> >
> > > Although ODL surely is interested in L3 flavor, the networking-odl
> team hasn't
> > > spec or experimental patch yet unfortunately.
> >
> > can you at least provide your requirements?
>
> Sure.
>
> networking-odl needs PRECOMMIT/AFTER_CREATE/UPDATE/DELETE for
> router/floaringip and PRECOMMIT for disassociate_floatingip.
> The reason why precommit_disassociate_floatingip is needed is that
> right now ODL doesn't support to updating floatingip status by ODL.
> So floatingip status is forcibly set to DOWN by the callback for now.
> (It's in future roadmap)
> networking-odl doesn't need callback for add/remove_router_interface
> because
> only db operation does. ODL identifies router interface by port:owner
> which is
> updated by update_port.
>
> Thanks,
>
> > networking-midonet needs to send the following info to its backend on
> > AFTER_CREATE/AFTER_UPDATE for router, router_interface, and
> > floating_ip.
> > https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461
> 428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161
> > (some of fields are actually unused right now. eg. tenant_id)
> > on AFTER_DELETE, we only need "id" field of the resource.
> > in feature we want to use PRECOMMIT_xxx events as well. necessary
> > fields are same as AFTER_xxx.
> >
> > > Dragon flow folks seems to have their own spec.
> > >
> > > thanks,
> > >
> > > On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> > > Takashi Yamamoto <yamam...@midokura.com> wrote:
> > >
> > >> hi,
> > >>
> > >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <ke...@benton.pub>
> wrote:
> > >> > If I understand the main issue with using regular callbacks, it's
> mainly
> > >> > just that the flavor assignment itself is in a callback, right?
> > >>
> > >> yes.
> > >>
> > >> >
> > >> > If so, couldn't we solve the problem by just moving flavor
> assignment to an
> > >> > explicit call before emitting the callbacks? Or would that still
> result in
> > >> > other ordering issues?
> > >>
> > >> it would solve the problem for CREATE.
> > >> for UPDATE and DELETE, i'm not sure.
> > >> UPDATE can change the flavor but it's supposed to be a special case
> > >> only for dvr/ha, right?
> > >> AFTER_DELETE might be tricky as we probably need to provide flavor
> > >> info to subscribers.
> > >>
> > >> >
> > >> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto <
> yamam...@midokura.com>
> > >> > wrote:
> > >> >>
> > >> >> hi,
> > >> >>
> > >> >> today i managed to play with l3 flavors.
> > >> >> i wrote a crude patch to implement midonet flavor. [1]
> > >> >>
> > >> >> [1] https://review.openstack.org/#/c/483174/
> > >> >>
> > >> >> a good news is it's somehow working.
> > >> >>
> > >> >> a bad news is it has a lot of issues, as you can see in TODO
> comments
> > >> >> in the patch.
> > >> >> given these issues, now i tend to think it's cleaner to introduce
> > >> >> ml2-like precommit/postcommit driver api (or its equivalent via
> > >> >> callbacks) rather than using these existing notifications.
> > >> >>
> > >> >> how do you think?
> > >> >
> > >> >
> > >>
> > >> 
> __
> > >> 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
> > >
> > > --
> > > Isaku Yamahata <isaku.yamah...@gmail.com>
>
> --
> Isaku Yamahata <isaku.yamah...@gmail.com>
>
__
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] - PTG neutron attendee info

[Kevin Benton]

Hello everyone,

With the help of Miguel we have a tentative schedule in the PTG. Please
check the etherpad and if there is anything missing you wanted to see
discussed, please reach out to me or Miguel right away to get it added.

Cheers,
Kevin Benton

On Thu, Jul 27, 2017 at 9:53 PM, Kevin Benton <ke...@benton.pub> wrote:

> Hi all,
>
> If you are planning on attending the PTG and the Neutron sessions, please
> add your name to the etherpad[1] so we can get a rough size estimate.
>
>
> 1. https://etherpad.openstack.org/p/neutron-queens-ptg
>
> Cheers,
> Kevin Benton
>
__
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] mod_wsgi support (pike bug?)

[Kevin Benton]

That's still going to be backwards-incompatible with the way it's been
shipped for quite a while now. Passing ENV vars or something to point to
specific config files is going to need to be explored.

On Wed, Sep 6, 2017 at 9:19 PM, Thomas Bechtold <tbecht...@suse.com> wrote:

> Hi Kevin,
>
> On 04.09.2017 15:01, Kevin Benton wrote:
>
>> Yes, unfortunately I didn't make it back to the patch in time to adjust
>> devstack to dump all of the configuration into one file (instead of
>> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).
>>
>
> You don't have to put everything into one file. oslo.config supports per
> service config files and conf.d dirs[1].
> So eg. dhcp_agent.ini could be put into 
> /etc/neutron/neutron-dhcp-agent.conf.d/foo.conf
> (it must end with .conf).
> Maybe that's more readable than a single huge config file?
>
> Best,
>
> Tom
>
> [1] https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2
>
>
__
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][puppet] mod_wsgi support (pike bug?)

[Kevin Benton]

>For the record, oslo.config already reads /etc/neutron/neutron.conf

Yeah, I think this is the only reason it even manages to get some of the
correct configuration (loading a core plugin at all).

>Also for the record, I consider not being able to load existing split 
>configuration
files a regression.

+1. That would make an upgrade nightmare. In my earlier email I didn't mean
to imply that was the only way forward. I was just curious if it still
broke when everything was in one file.

On Tue, Sep 5, 2017 at 7:01 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:

> On Mon, Sep 4, 2017 at 8:07 AM, Kevin Benton <ke...@benton.pub> wrote:
> > #2 would be preferable as well just because we have so many
> guides/distros
> > mentioning the different file locations. I'm not familiar with mod_wsgi
> > enough to know if it's possible.
> >
> > Another 3rd option may be to edit the oslo config constructor call when
> > using that entry point to add some well-known paths for additional config
> > files rather than only parsing 'sys.argv[1]'. For example, we could
> always
> > try to add /etc/neutron/plugin.ini to the list which we can document that
> > distros/deployment tools should always create or have a symbolic link to
> a
> > plugin-specific config (e.g. ml2_conf.ini).
>
> For the record, oslo.config already reads /etc/neutron/neutron.conf
> (and some other locations) when no arguments are passed:
>
> https://github.com/openstack/oslo.config/blob/master/oslo_
> config/cfg.py#L711-L739
>
> Also for the record, I consider not being able to load existing split
> configuration files a regression. We won't be able to move to the new
> operation mode unless we figure out how to load them. If mod_wsgi is
> not willing to bend their argv, a envvar could be a good option.
>
> Ihar
>
> __
> 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
>
__
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][puppet] mod_wsgi support (pike bug?)

[Kevin Benton]

Did you look into setting config files in an env var? That seemed like the
best bet given that #2 is out.

On Mon, Sep 4, 2017 at 8:19 AM, Mohammed Naser <mna...@vexxhost.com> wrote:

> On Mon, Sep 4, 2017 at 11:07 AM, Kevin Benton <ke...@benton.pub> wrote:
> > #2 would be preferable as well just because we have so many
> guides/distros
> > mentioning the different file locations. I'm not familiar with mod_wsgi
> > enough to know if it's possible.
>
> I think you might have missed my message earlier by a few seconds,
> looks like it's not really possible :(
>
> > Another 3rd option may be to edit the oslo config constructor call when
> > using that entry point to add some well-known paths for additional config
> > files rather than only parsing 'sys.argv[1]'. For example, we could
> always
> > try to add /etc/neutron/plugin.ini to the list which we can document that
> > distros/deployment tools should always create or have a symbolic link to
> a
> > plugin-specific config (e.g. ml2_conf.ini).
> >
>
> I believe that would be the best option, I did a bit of research and I
> have the following in regards to distros:
>
> - RDO uses /etc/neutron/plugin.ini:
> https://github.com/rdo-packages/neutron-distgit/blob/
> rpm-master/neutron-server.service#L8
> - Ubuntu configures `/etc/neutron/plugins/ml2/ml2_conf.ini` in
> `/etc/neutron/default` which is why in Puppet we override that to keep
> things consistent.
> (https://launchpad.net/ubuntu/+source/neutron/2:11.0.0-0ubuntu1 --
> downloaded control files from there).
>
> I have mixed feelings about this.  I think we should add
> `/etc/neutron/plugin.ini` and advice Ubuntu packaging to change their
> default (with a plugin.ini as a symlink).  If we introduce both
> `ml2_conf.ini` and `plugin.ini`, we risk creating problems if someone
> is not using the `ml2` plugin.  Alternatively, you could load
> `plugin.ini` and fallback to `/etc/neutron/plugins/ml2/ml2_conf.ini`
> if there is nothing?  It's a hard call but it should probably be
> decided by the Neutron team in coordination with the distribution
> packagers.
>
> >
> > On Mon, Sep 4, 2017 at 7:40 AM, Mohammed Naser <mna...@vexxhost.com>
> wrote:
> >>
> >> On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <ke...@benton.pub> wrote:
> >> > Yes, unfortunately I didn't make it back to the patch in time to
> adjust
> >> > devstack to dump all of the configuration into one file (instead of
> >> > /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did
> test
> >> > locally with my dev environment around the time that RPC server patch
> >> > went
> >> > in, but there may have been a regression since it went in since it's
> not
> >> > tested as Matt pointed out.
> >> >
> >>
> >> I've added Puppet into this because I think we would have to take a
> >> decision regarding this.  The reason behind the fact that we've always
> >> used the two configuration files is because distributions which ship
> >> packages actually provide 2 configuration files.
> >>
> >> We use a configuration resource called `neutron_plugin_ml2` which
> >> configures things always in `/etc/neutron/plugins/ml2/ml2_conf.ini`.
> >>
> >> In the case of Ubuntu/Debian based systems, we update
> >> `/etc/default/neutron-server` to point the plugin configuration to
> >> `/etc/neutron/plugin.ini` and then we ensure that the file is a
> >> symbolic link to `/etc/neutron/plugins/ml2/ml2_conf.ini`.
> >>
> >> Now, we have two options in my mind (and I am open for others):
> >>
> >> 1) Configure plugins entirely inside `neutron.conf`
> >> This option would solve our issue but introduce another one.  I
> >> believe that the order in the start commands would mean that the later
> >> configuration files (in this case, the plugin.ini) would have priority
> >> over the `neutron.conf` causing an inconsistency, I don't think this
> >> is possible.  However, we can work around this by ensuring that the
> >> plugin.ini file is empty.  However, we will be introducing service
> >> restarts for no reason with that change which can be very confusing
> >> for the user as to why configuration is moving.
> >>
> >> 2) Figure out a way to pass 'args' via WSGI?
> >> I'm not sure if this is entirely possible at all.  But, could there be
> >> a way that we can pass a list of configuration files in the mod_wsgi
> >> configuration?  This would make it the most transparent fix without
> >> havin

[openstack-dev] [neutron] no team meeting today

[Kevin Benton]

Due to the US holiday I will not be around to run it.

Cheers,
Kevin Benton
__
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][puppet] mod_wsgi support (pike bug?)

[Kevin Benton]

Expanding on my other email. We could alter the oslo.config constructor
call to pass in file paths from environmental variables as well. Maybe
that's the easiest path forward since it would just be a change from
sys.argv to the env vars.

On Mon, Sep 4, 2017 at 8:04 AM, Mohammed Naser <mna...@vexxhost.com> wrote:

> On Mon, Sep 4, 2017 at 10:40 AM, Mohammed Naser <mna...@vexxhost.com>
> wrote:
> > On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <ke...@benton.pub> wrote:
> >> Yes, unfortunately I didn't make it back to the patch in time to adjust
> >> devstack to dump all of the configuration into one file (instead of
> >> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test
> >> locally with my dev environment around the time that RPC server patch
> went
> >> in, but there may have been a regression since it went in since it's not
> >> tested as Matt pointed out.
> >>
> >
> > I've added Puppet into this because I think we would have to take a
> > decision regarding this.  The reason behind the fact that we've always
> > used the two configuration files is because distributions which ship
> > packages actually provide 2 configuration files.
> >
> > We use a configuration resource called `neutron_plugin_ml2` which
> > configures things always in `/etc/neutron/plugins/ml2/ml2_conf.ini`.
> >
> > In the case of Ubuntu/Debian based systems, we update
> > `/etc/default/neutron-server` to point the plugin configuration to
> > `/etc/neutron/plugin.ini` and then we ensure that the file is a
> > symbolic link to `/etc/neutron/plugins/ml2/ml2_conf.ini`.
> >
> > Now, we have two options in my mind (and I am open for others):
> >
> > 1) Configure plugins entirely inside `neutron.conf`
> > This option would solve our issue but introduce another one.  I
> > believe that the order in the start commands would mean that the later
> > configuration files (in this case, the plugin.ini) would have priority
> > over the `neutron.conf` causing an inconsistency, I don't think this
> > is possible.  However, we can work around this by ensuring that the
> > plugin.ini file is empty.  However, we will be introducing service
> > restarts for no reason with that change which can be very confusing
> > for the user as to why configuration is moving.
> >
> > 2) Figure out a way to pass 'args' via WSGI?
> > I'm not sure if this is entirely possible at all.  But, could there be
> > a way that we can pass a list of configuration files in the mod_wsgi
> > configuration?  This would make it the most transparent fix without
> > having to adjust all of the configuration files and bend against the
> > set configuration paths of the distro.
>
> I did a bit more research and unfortunately it looks like this option
> is not possible (at least with mod_wsgi):
>
> https://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/
> server/wsgi_interp.c#L546-L561
>
> mod_wsgi sets the content of sys.argv to ["mod_wsgi"] only.
> Environment variables are still a possibility.
>
> > I'd be more than happy to hear any other ideas regarding this
> > solution.  I would love to implement #2 if it is somehow possible
> > (environment variables, maybe?) but #1 would work but be very messy
> > for operators and users.
> >
> >>
> >> It appears that puppet is still spreading the config files for the
> server
> >> into multiple locations as well[1]. Does it inherit that logic from
> >> devstack? Because that will need to be changed to push all of the
> relevant
> >> server config into one conf.
> >>
> >> 1.
> >> http://logs.openstack.org/82/500182/3/check/gate-puppet-open
> stack-integration-4-scenario004-tempest-ubuntu-xenial/
> 791523c/logs/etc/neutron/plugins/
> >>
> >> On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser <mna...@vexxhost.com>
> wrote:
> >>>
> >>> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser <mna...@vexxhost.com>
> >>> wrote:
> >>> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish <
> mtrein...@kortar.org>
> >>> > wrote:
> >>> >> On Sun, Sep 03, 2017 at 01:47:24PM -0400, Mohammed Naser wrote:
> >>> >>> Hi folks,
> >>> >>>
> >>> >>> I've attempted to enable mod_wsgi support in our dev environment
> with
> >>> >>> Puppet however it results in a traceback.  I figured it was an
> >>> >>> environment thing so I looked into moving the Puppet CI to test
> using
> >

Re: [openstack-dev] [neutron][puppet] mod_wsgi support (pike bug?)

[Kevin Benton]

#2 would be preferable as well just because we have so many guides/distros
mentioning the different file locations. I'm not familiar with mod_wsgi
enough to know if it's possible.

Another 3rd option may be to edit the oslo config constructor call when
using that entry point to add some well-known paths for additional config
files rather than only parsing 'sys.argv[1]'. For example, we could always
try to add /etc/neutron/plugin.ini to the list which we can document that
distros/deployment tools should always create or have a symbolic link to a
plugin-specific config (e.g. ml2_conf.ini).


On Mon, Sep 4, 2017 at 7:40 AM, Mohammed Naser <mna...@vexxhost.com> wrote:

> On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <ke...@benton.pub> wrote:
> > Yes, unfortunately I didn't make it back to the patch in time to adjust
> > devstack to dump all of the configuration into one file (instead of
> > /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test
> > locally with my dev environment around the time that RPC server patch
> went
> > in, but there may have been a regression since it went in since it's not
> > tested as Matt pointed out.
> >
>
> I've added Puppet into this because I think we would have to take a
> decision regarding this.  The reason behind the fact that we've always
> used the two configuration files is because distributions which ship
> packages actually provide 2 configuration files.
>
> We use a configuration resource called `neutron_plugin_ml2` which
> configures things always in `/etc/neutron/plugins/ml2/ml2_conf.ini`.
>
> In the case of Ubuntu/Debian based systems, we update
> `/etc/default/neutron-server` to point the plugin configuration to
> `/etc/neutron/plugin.ini` and then we ensure that the file is a
> symbolic link to `/etc/neutron/plugins/ml2/ml2_conf.ini`.
>
> Now, we have two options in my mind (and I am open for others):
>
> 1) Configure plugins entirely inside `neutron.conf`
> This option would solve our issue but introduce another one.  I
> believe that the order in the start commands would mean that the later
> configuration files (in this case, the plugin.ini) would have priority
> over the `neutron.conf` causing an inconsistency, I don't think this
> is possible.  However, we can work around this by ensuring that the
> plugin.ini file is empty.  However, we will be introducing service
> restarts for no reason with that change which can be very confusing
> for the user as to why configuration is moving.
>
> 2) Figure out a way to pass 'args' via WSGI?
> I'm not sure if this is entirely possible at all.  But, could there be
> a way that we can pass a list of configuration files in the mod_wsgi
> configuration?  This would make it the most transparent fix without
> having to adjust all of the configuration files and bend against the
> set configuration paths of the distro.
>
> I'd be more than happy to hear any other ideas regarding this
> solution.  I would love to implement #2 if it is somehow possible
> (environment variables, maybe?) but #1 would work but be very messy
> for operators and users.
>
> >
> > It appears that puppet is still spreading the config files for the server
> > into multiple locations as well[1]. Does it inherit that logic from
> > devstack? Because that will need to be changed to push all of the
> relevant
> > server config into one conf.
> >
> > 1.
> > http://logs.openstack.org/82/500182/3/check/gate-puppet-
> openstack-integration-4-scenario004-tempest-ubuntu-
> xenial/791523c/logs/etc/neutron/plugins/
> >
> > On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser <mna...@vexxhost.com>
> wrote:
> >>
> >> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser <mna...@vexxhost.com>
> >> wrote:
> >> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish <
> mtrein...@kortar.org>
> >> > wrote:
> >> >> On Sun, Sep 03, 2017 at 01:47:24PM -0400, Mohammed Naser wrote:
> >> >>> Hi folks,
> >> >>>
> >> >>> I've attempted to enable mod_wsgi support in our dev environment
> with
> >> >>> Puppet however it results in a traceback.  I figured it was an
> >> >>> environment thing so I looked into moving the Puppet CI to test
> using
> >> >>> mod_wsgi and it resulted in the same error.
> >> >>>
> >> >>>
> >> >>> http://logs.openstack.org/82/500182/3/check/gate-puppet-
> openstack-integration-4-scenario004-tempest-ubuntu-
> xenial/791523c/logs/apache/neutron_wsgi_error.txt.gz
> >> >>>
> >> >>> Would anyone from the Neutron 

Re: [openstack-dev] [neutron] mod_wsgi support (pike bug?)

[Kevin Benton]

Yes, unfortunately I didn't make it back to the patch in time to adjust
devstack to dump all of the configuration into one file (instead of
/etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test
locally with my dev environment around the time that RPC server patch went
in, but there may have been a regression since it went in since it's not
tested as Matt pointed out.

It appears that puppet is still spreading the config files for the server
into multiple locations as well[1]. Does it inherit that logic from
devstack? Because that will need to be changed to push all of the relevant
server config into one conf.

1.
http://logs.openstack.org/82/500182/3/check/gate-puppet-openstack-integration-4-scenario004-tempest-ubuntu-xenial/791523c/logs/etc/neutron/plugins/

On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser  wrote:

> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser 
> wrote:
> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish 
> wrote:
> >> On Sun, Sep 03, 2017 at 01:47:24PM -0400, Mohammed Naser wrote:
> >>> Hi folks,
> >>>
> >>> I've attempted to enable mod_wsgi support in our dev environment with
> >>> Puppet however it results in a traceback.  I figured it was an
> >>> environment thing so I looked into moving the Puppet CI to test using
> >>> mod_wsgi and it resulted in the same error.
> >>>
> >>> http://logs.openstack.org/82/500182/3/check/gate-puppet-
> openstack-integration-4-scenario004-tempest-ubuntu-
> xenial/791523c/logs/apache/neutron_wsgi_error.txt.gz
> >>>
> >>> Would anyone from the Neutron team be able to give input on this?
> >>> We'd love to add gating for Neutron deployed by mod_wsgi which can
> >>> help find similar issues.
> >>>
> >>
> >> Neutron never got their wsgi support working in Devstack either. The
> patch
> >> adding that: https://review.openstack.org/#/c/439191/ never passed the
> gate and
> >> seems to have lost the attention of the author. The wsgi support in
> neutron
> >> probably doesn't work yet, and is definitely untested. IIRC, the issue
> they were
> >> hitting was loading the config files. [1] I don't think I saw any
> progress on it
> >> after that though.
> >>
> >> The TC goal doc [2] probably should say something about it never
> landing and
> >> missing pike.
> >>
> >
> > That would make sense.  The release notes also state that it does
> > offer the ability to run inside mod_wsgi which can be misleading to
> > deployers (that was the main reason I thought we can start testing
> > using it):
> >
> Sigh, hit send too early.  Here is the link:
>
> http://git.openstack.org/cgit/openstack/neutron/commit/?id=
> 916bc96ee214078496b4b38e1c93f36f906ce840
> >
> >>
> >> -Matt Treinish
> >>
> >>
> >> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> June/117830.html
> >> [2] https://governance.openstack.org/tc/goals/pike/deploy-api-
> in-wsgi.html#neutron
> >>
> >> 
> __
> >> 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
> >>
>
> __
> 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
>
__
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

[openstack-dev] No drivers meeting today

[Kevin Benton]

Hi everyone,

I'm canceling the drivers meeting today to allow everyone to focus on fixes
for Pike.

Let me or Armando know right away if you have have any fixes that need to
go into RC2 since he has prepared the RC2 release patch already.

Cheers,
Kevin Benton
__
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][infra] Functional job failure rate at 100%

[Kevin Benton]

This is just the code simulating the conntrack entries that would be
created by real traffic in a production system, right?

On Wed, Aug 9, 2017 at 11:46 AM, Jakub Libosvar  wrote:

> On 09/08/2017 18:23, Jeremy Stanley wrote:
> > On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> > [...]
> >> Is it possible to switch used image for jenkins machines to use
> >> back the older version? Any other ideas how to deal with the
> >> kernel bug?
> >
> > Making our images use non-current kernel packages isn't trivial, but
> > as Thierry points out in his reply this is not just a problem for
> > our CI system. Basically Ubuntu has broken OpenStack (and probably a
> > variety of other uses of conntrack) for a lot of people following
> > kernel updates in 16.04 LTS so the fix needs to happen there
> > regardless. Right now, basically, Ubuntu Xenial is not a good
> > platform to be running OpenStack on until they get the kernel
> > regression addressed.
>
> True. Fortunately, the impact is not that catastrophic for Neutron as it
> might seem on the first look. Not sure about the other projects, though.
> Neutron doesn't create conntrack entries in production code - only in
> testing. That said, agents should work just fine even with the kernel bug.
>
> >
> >
> >
> > 
> __
> > 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
> >
>
>
> __
> 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
>
__
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] - FFE for networking-bagpipe, support for MPLS-over-GRE

[Kevin Benton]

This change looks good to me since it's quite small. Make sure you leave
feedback on Armando's release patch to update the hash for the this repo
before Thursday.

On Tue, Aug 8, 2017 at 8:16 AM,  wrote:

> Hi PTL/all,
>
> I would like to request an exception for inclusion in Pike, of MPLS/GRE
> support in networking-bagpipe.
>
> The feature consists in allowing the use of a new OVS tunnel option
> added in the very recently released OVS 2.8.
>
> The code is ready, the only piece preventing the merge is that the
> fullstack functional test is not fully ready yet (but should be soon).
>
> The change: https://review.openstack.org/#/c/482571
> The RFE: https://bugs.launchpad.net/networking-bagpipe/+bug/1709338
>
> Thanks,
>
> -Thomas
>
>
> (not waiting for a confirmation that the process applies to stadium
> projects, because I'm already late to fill this in, being just back
> from PTO)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> 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
>
__
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] - FFE requests for Pike

[Kevin Benton]

Yeah, the FFE process applies to stadium projects as well.

On Tue, Aug 8, 2017 at 8:07 AM, <thomas.mo...@orange.com> wrote:

> Hi Kevin,
>
> Am I right to assume this applies to stadium projects as well ?
> (since they now are all under cycle-with-milestones)
>
> -Thomas
>
>
> Kevin Benton, 2017-07-30 23:52:
> > Hi all,
> >
> > If you have any Neutron-related FFE requests for Pike please send an
> > email to the dev list with [neutron] in the tag and FFE in the
> > subject like in [1]. We will discuss them in the drivers meetings.
> >
> >
> > 1. http://lists.openstack.org/pipermail/openstack-dev/2017-July/12031
> > 0.html
> >
> > Thanks,
> > Kevin Benton
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> 
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> 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
>
__
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][FFE] DVR support for Allowed_address_pair port that are bound to multiple ACTIVE VM ports

[Kevin Benton]

I think this is okay. It's been a long standing bug and the patch has is
very close to ready.

On Thu, Aug 3, 2017 at 4:26 PM, Swaminathan Vasudevan 
wrote:

>
> Hi PTL/all,I would like to request an exception for inclusion of
> https://bugs.launchpad.net/neutron/+bug/1583694for Pike.
>
> This fix contained two patches one for server side and the other for the
> agent side.
>
> The server side patch had already merged, but the agent side patch is yet to 
> merge but gone through
> multiple reviews.
> I would request to consider the agent side patch for the Feature Freeze 
> Exception.
>
> The RFE: https://bugs.launchpad.net/neutron/+bug/1583694
> The agent side patch: https://review.openstack.org/#/c/437986/  (FFE required)
>
> The server side patch that already merged: 
> https://review.openstack.org/#/c/466434/  (Patch already merged).
> Best regards,
> Swaminathan Vasudevan
>
>
> __
> 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
>
>
__
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][FFE]Allow DVR for E/W while leaving N/S centralized Edit

[Kevin Benton]

Based on feedback from Brian, this patch is close to ready so we should be
able to land it. It also proposes a limited risk to existing deployments
not using the new agent mode.

On Thu, Aug 3, 2017 at 4:26 PM, Swaminathan Vasudevan 
wrote:

>
>
>
> Hi PTL/all,
> I would like to request an exception for inclusion of 
> https://bugs.launchpad.net/neutron/+bug/1667877.
> This fix addresses providing option for the customers to configure a new 
> agent-type for centralizing the
> floatingip in the absence of external network connectivity.
>
>
> The RFE: https://bugs.launchpad.net/neutron/+bug/1667877
> Patch under review: https://review.openstack.org/#/c/485333/
>
> Best regards,
> Swaminathan Vasudevan
>
>
> __
> 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
>
>
__
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] FFE for net-mtu-enh api extension requested

[Kevin Benton]

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Fri, Jul 28, 2017 at 11:50 AM, Ihar Hrachyshka 
wrote:

> Hi PTL/all,
>
> I would like to request an exception for inclusion of net-mtu-enh API
> extension (with ML2 implementation) for Pike.
>
> The patch is ready for review, it includes tempest tests and docs
> update. There are several things in the patch that we will need to
> follow up in the next release (hence a lot of TODOs), but those are
> not because the patch is not complete, but because we need to
> accommodate for rolling upgrades of controllers.
>
> The RFE: https://launchpad.net/bugs/1671634
> The patch: https://review.openstack.org/#/c/483518/
>
> Best regards,
> Ihar
>
> __
> 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
>
__
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] - FFE for security-group logging requested

[Kevin Benton]

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Mon, Jul 31, 2017 at 3:19 AM, Furukawa, Yushiro <
y.furukaw...@jp.fujitsu.com> wrote:

> Hi Kevin(PTL)/all,
>
> I would like to request an exception for 'Logging feature' for Pike.
> Following patches are ready for review, it includes functional tests and
> docs
> update.  In next cycle, we need to add more tests.
>
> The RFE:
>   <https://bugs.launchpad.net/neutron/+bug/1468366>
> The Patches:
> 01.<https://review.openstack.org/#/c/468309/> - Driver manager for
> logging plugin
> 02.<https://review.openstack.org/#/c/467976/> - Validator for logging
> plugin
> 03.<https://review.openstack.org/#/c/396104/> - Logging agent
> extension
> 04.<https://review.openstack.org/#/c/468265/> - RPC stuff
> 05.<https://review.openstack.org/#/c/468281/> - OVS firewall logging
> driver
> 06.<https://review.openstack.org/#/c/409819/> - OSC plugin
> 07.<https://review.openstack.org/#/c/480117/> - Networking guide
> 08.<https://review.openstack.org/#/c/418862/> - Functional test
> 09.<https://review.openstack.org/#/c/482886/> - API test
> 10.<https://review.openstack.org/#/c/396116/> - Devstack plugin
>
> Best regards,
>
> 
> Yushiro FURUKAWA
>
> From: Kevin Benton [mailto:ke...@benton.pub]
> Sent: Monday, July 31, 2017 3:53 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [neutron] - FFE requests for Pike
>
> Hi all,
>
> If you have any Neutron-related FFE requests for Pike please send an email
> to the dev list with [neutron] in the tag and FFE in the subject like in
> [1]. We will discuss them in the drivers meetings.
>
>
> 1. http://lists.openstack.org/pipermail/openstack-dev/2017-
> July/120310.html
>
> Thanks,
> Kevin Benton
> __
> 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
>
__
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] FFE for midonet v2 plugin removal

[Kevin Benton]

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Tue, Aug 1, 2017 at 12:19 AM, Takashi Yamamoto 
wrote:

> On Tue, Aug 1, 2017 at 8:01 AM, Takashi Yamamoto 
> wrote:
> > hi,
> >
> > I'm not sure if changes like this requires an FFE, but just in case.
> > I'd like to request an FFE for midonet v2 plugin removal.
> >
> > - patches are ready for review: https://review.openstack.org/#/c/486790/
> > - https://bugs.launchpad.net/networking-midonet/
>
> oops, bad copy and paste.
> https://bugs.launchpad.net/networking-midonet/+bug/1680347
>
> > - this is a removal of an already-deprecated plugin
> > - the replacement code (midonet drivers for ml2) covers the most or
> > probably all functionalities provided by the plugin being removed
> > - the change is local to networking-midonet
>
> __
> 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
>
__
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] FFE for dns_domain for ports extension

[Kevin Benton]

Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html

On Tue, Aug 1, 2017 at 12:44 PM, Miguel Lavalle  wrote:

> Hi PTL/all
>
> I want to request an exception to include the dns_domain for ports
> extension in the Pike release.
>
> The extension is implemented by 3 patchsets, out of which [1] and [2] have
> already merged. The third patchset [3] is ready for reviews. The RFE can be
> found in [4].
>
> Best regards
> Miguel
>
>
> [1] https://review.openstack.org/#/c/457101/
> [2] https://review.openstack.org/#/c/457035/
> [3] https://review.openstack.org/#/c/468697/
> [4] https://bugs.launchpad.net/neutron/+bug/1650678
>
> __
> 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
>
>
__
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

[openstack-dev] [neutron] PTL Nomination

[Kevin Benton]

Hello!

I would like to nominate myself as PTL for the Neutron project for the
Queens cycle.

I served as the Neutron PTL for the Pike cycle, have been a core reviewer
since Kilo, and have been contributing since Havana.

I have a few new goals I would like to focus on during the Queens cycle.

* New bug triaging process. We've had a lot of trouble finding volunteers
for bug deputy duty. We need to come up with another way to share the load
of triaging reported bugs.

* Finish the multiple port-binding work. As OVSFW and other ML2 drivers
that require different VIF wiring gain popularity, we need to solve the
migration between VIF types in a generic way so operators can reasonably
switch between backends.

* Expand the routed networks work to cover the external network and
floating IPs. This will solve the issue of scaling a single broadcast
domain to every compute node that is a blocker for many large operators
with L3 fabrics.


Additionally, I would like to continue on several of the goals I suggested
during the last cycle.

* Cleanup and simplification of the existing code. Quite a bit of this has
happened server-side by leveraging the callback system to decouple things.
We merged a significant amount of OVO code to stop working with models
directly and there are a few major objects left like Ports that I would
like to see completed in Queens.

* VPNaaS: it didn't quite make it back into the stadium during Pike. There
is one remaining item to decouple their agent code and then we should be
able to make VPNaaS part of the stadium again.

* We completed the switch to Pecan and we've been running on it most of the
Pike cycle. In Queens we can pull out all of the old API code.

* Supporting stable interfaces for external projects. We have made quite a
bit of progress moving externally referenced items to neutron-lib. One of
the last items to solve is OVO definitions and then it will be feasible for
projects to stop depending on the neutron core code directly.

Goals that didn't see much progress:

* More core reviewers. Unfortunately do the change in focus for many
companies we haven't seen a lot of new contributors with enough time for a
core reviewer load.

* Tooling for review backlog. I did adjust the auto-abandon script a bit
but there is no automated process yet to help keep this under control.


Cheers,
Kevin Benton
__
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

[openstack-dev] [neutron] - FFE requests for Pike

[Kevin Benton]

Hi all,

If you have any Neutron-related FFE requests for Pike please send an email
to the dev list with [neutron] in the tag and FFE in the subject like in
[1]. We will discuss them in the drivers meetings.


1. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120310.html

Thanks,
Kevin Benton
__
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] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Kevin Benton]

Maybe we could just ban search engines from indexing the releases using
robots.txt once they go EOL. That would solve the problem of losing old
information for people that still need it while preventing people stumbling
onto old docs when they search for something.

On Fri, Jul 28, 2017 at 12:39 PM, Jeremy Stanley  wrote:

> On 2017-07-28 15:32:01 -0400 (-0400), David Desrosiers wrote:
> [...]
> > I am very opposed to removing subsets of docs, including the install
> guide,
> > after the release goes eol upstream from consumers for exactly that
> reason.
> >
> > Watermarking the upstream docs with series and version should reduce or
> > eliminate the need for people to incorrectly submit fixes, patches and
> PRs
> > for eol releases that the core team can no longer support, but that
> > shouldn't necessitate removal of the installation instructions.
>
> Perhaps a compromise is to add very visible banners that explicitly
> remind the reader they're looking at installation instructions for
> an outdated version of the software, with a link to see the current
> installation instructions instead? Simply relying on newcomers to
> recognize release series names and inherently know whether they're
> reading the latest version is an issue.
> --
> Jeremy Stanley
>
> __
> 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
>
>
__
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][vpnaas] driver removal

[Kevin Benton]

+1 to remove during Queens if we don't get maintainers.

On Thu, Jul 27, 2017 at 6:31 PM, Takashi Yamamoto 
wrote:

> hi,
>
> some of drivers in neutron-vpnaas don't have maintainers. [1]
> unless someone steps up, we might end up with removing those drivers.
>
> especially, VyattaIPsecDriver will likely be removed in near future,
> as it requires a special agent [2] which is difficult to maintain for
> those who are not familiar with it.
>
> [1] https://github.com/openstack/neutron-vpnaas/blob/master/
> doc/source/devref/team.rst
> [2] https://github.com/openstack/neutron-vpnaas/blob/
> 797c0466693108dd63415a065750e7a62a5f5ce8/setup.cfg#L36
>
> __
> 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
>
__
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

[openstack-dev] [neutron] - PTG neutron attendee info

[Kevin Benton]

Hi all,

If you are planning on attending the PTG and the Neutron sessions, please
add your name to the etherpad[1] so we can get a rough size estimate.


1. https://etherpad.openstack.org/p/neutron-queens-ptg

Cheers,
Kevin Benton
__
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] [legal-discuss] [neutron] License issue & Need help

[Kevin Benton]

Thank you. That's exactly what we needed.

On Wed, Jul 26, 2017 at 8:57 AM, Jeremy Stanley  wrote:

> On 2017-07-26 03:04:42 + (+), hoan...@vn.fujitsu.com wrote:
> > We are recently trying to propose a Netlink solution [1] in order
> > to improve performance for Neutron's Security Group.
> [...]
>
> I answered in the duplicate thread on legal-discuss:
>
> http://lists.openstack.org/pipermail/legal-discuss/2017-
> July/000477.html
>
> --
> Jeremy Stanley
>
> __
> 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
>
__
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] out-of-tree l3 service providers

[Kevin Benton]

If I understand the main issue with using regular callbacks, it's mainly
just that the flavor assignment itself is in a callback, right?

If so, couldn't we solve the problem by just moving flavor assignment to an
explicit call before emitting the callbacks? Or would that still result in
other ordering issues?

On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto 
wrote:

> hi,
>
> today i managed to play with l3 flavors.
> i wrote a crude patch to implement midonet flavor. [1]
>
> [1] https://review.openstack.org/#/c/483174/
>
> a good news is it's somehow working.
>
> a bad news is it has a lot of issues, as you can see in TODO comments
> in the patch.
> given these issues, now i tend to think it's cleaner to introduce
> ml2-like precommit/postcommit driver api (or its equivalent via
> callbacks) rather than using these existing notifications.
>
> how do you think?
>
__
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] [docs][neutron] doc-migration status

[Kevin Benton]

Yeah, the networking guide does include configuration for some of the
sub-projects (e.g. BGP is at [1]). For the remaining ones there is work
that needs to be done because their docs live in wiki pages.

1.
https://docs.openstack.org/ocata/networking-guide/config-bgp-dynamic-routing.html


On Sun, Jul 23, 2017 at 1:32 PM, Doug Hellmann 
wrote:

> Excerpts from Kevin Benton's message of 2017-07-23 01:31:25 -0700:
> > Yeah, I was just thinking it makes it more explicit that we haven't just
> > skipped doing an admin guide for a particular project.
>
> Sure, you can do that. I don't think we want to link to all of those
> pages from the list of admin guides, though.
>
> I've updated the burndown chart generator to ignore the missing
> admin guide URLs for networking subprojects.
>
> I don't see configuration or installation guides for quite a few
> of those, either. Are those also handled within the neutron main
> tree docs?
>
> Doug
>
> __
> 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
>
__
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] [docs][neutron] doc-migration status

[Kevin Benton]

Yeah, I was just thinking it makes it more explicit that we haven't just
skipped doing an admin guide for a particular project.

On Sun, Jul 23, 2017 at 1:18 AM, Andreas Jaeger <a...@suse.com> wrote:

> On 07/22/2017 11:44 PM, Kevin Benton wrote:
>
>> Could we just put a placeholder in those subprojects /admin directories
>> that redirects to the networking guide?
>>
>
> You mean a single page that basically says :
>
> All information is covered in the `Networking Guide <
> https://docs.openstack.org/neutron/latest/admin/networking-guide`_
> <https://docs.openstack.org/neutron/latest/admin/networking-guide_>.
>
> Yes, this could be done - do we really need this?
>
> Akihiro, having an admin/ directory is not a must-have,
>
> Andreas
>
> On Sat, Jul 22, 2017 at 10:50 AM, Doug Hellmann <d...@doughellmann.com
>> <mailto:d...@doughellmann.com>> wrote:
>>
>> Excerpts from Akihiro Motoki's message of 2017-07-23 02:13:40 +0900:
>> > Hi,
>> >
>> > I have a question on admin/ document related to the networking guide
>> > and would like to have advices from the documentation experts.
>> >
>> > It seems the check site by Doug expect all project have admin/ page.
>> > In the case of neutron the situation is a bit special. We have the
>> > networking guide as admin/ document
>> > in the neutron repo and it covers not only neutron itself but also
>> > neutron stadium projects.
>> > It means the neutron stadium projects sometimes (often?) have no
>> > admin/ directory in their own repos
>> > in favor of adding contents to the networking guide in neutron.
>> >
>> > Should Individual neutron stadium projects have their own admin
>> guide
>> > in their repositories,
>> > or is it better to keep the networking guide which covers all
>> > networking stuff in a single guide?
>> >
>> > What is the suggested way on the networking guide as the document
>> expert?
>>
>> If the admin guides for all of those repos are combined, then I can
>> modify the burndown chart generator to not count those as needed. Let
>> me
>> know if that's the best approach.
>>
>> Doug
>>
>>  >
>>  > Thanks,
>>  > Akihiro
>>  >
>>  > 2017-07-22 3:26 GMT+09:00 Doug Hellmann <d...@doughellmann.com
>> <mailto:d...@doughellmann.com>>:
>>  > > We've made huge progress, and are launching the updated landing
>>  > > pages for docs.openstack.org <http://docs.openstack.org> as I
>>
>> write this. Thanks to all of the
>>  > > contributors who have stepped up to write nearly 1,000 patches to
>>  > > improve the health of our documentation!
>>  > >
>>  > > We still have around 70 URLs we expected to see after the
>> migration
>>  > > was complete but that produce a 404. I know some of the patches
>> to
>>  > > produce those pages are in progress, but please check the list at
>>  > > https://doughellmann.com/doc-migration/
>> <https://doughellmann.com/doc-migration/> if your team is listed
>> below
>>  > > to ensure that nothing has been missed.
>>  > >
>>  > >   cinder
>>  > >   cloudkitty
>>  > >   congress
>>  > >   designate
>>  > >   heat
>>  > >   ironic
>>  > >   karbor
>>  > >   keystone
>>  > >   magnum
>>  > >   manila
>>  > >   murano
>>  > >   neutron
>>  > >   nova
>>  > >   sahara
>>  > >   senlin
>>  > >   swift
>>  > >   tacker
>>  > >   telementry
>>  > >   tricircle
>>  > >   trove
>>  > >   vitrage
>>  > >   watcher
>>  > >   zaqar
>>  > >   zun
>>  > >
>>  > > Reply here or ping me in #openstack-docs if you have questions
>> or need a
>>  > > hand.
>>  > >
>>  > > Doug
>>  > >
>>  > > ___
>>  > > OpenStack-docs mailing list
>>  > > openstack-d...@lists.openstack.org
>> <mailto:openstack-d...@lists.openstack.

Re: [openstack-dev] [docs][neutron] doc-migration status

[Kevin Benton]

Could we just put a placeholder in those subprojects /admin directories
that redirects to the networking guide?

On Sat, Jul 22, 2017 at 10:50 AM, Doug Hellmann 
wrote:

> Excerpts from Akihiro Motoki's message of 2017-07-23 02:13:40 +0900:
> > Hi,
> >
> > I have a question on admin/ document related to the networking guide
> > and would like to have advices from the documentation experts.
> >
> > It seems the check site by Doug expect all project have admin/ page.
> > In the case of neutron the situation is a bit special. We have the
> > networking guide as admin/ document
> > in the neutron repo and it covers not only neutron itself but also
> > neutron stadium projects.
> > It means the neutron stadium projects sometimes (often?) have no
> > admin/ directory in their own repos
> > in favor of adding contents to the networking guide in neutron.
> >
> > Should Individual neutron stadium projects have their own admin guide
> > in their repositories,
> > or is it better to keep the networking guide which covers all
> > networking stuff in a single guide?
> >
> > What is the suggested way on the networking guide as the document expert?
>
> If the admin guides for all of those repos are combined, then I can
> modify the burndown chart generator to not count those as needed. Let me
> know if that's the best approach.
>
> Doug
>
> >
> > Thanks,
> > Akihiro
> >
> > 2017-07-22 3:26 GMT+09:00 Doug Hellmann :
> > > We've made huge progress, and are launching the updated landing
> > > pages for docs.openstack.org as I write this. Thanks to all of the
> > > contributors who have stepped up to write nearly 1,000 patches to
> > > improve the health of our documentation!
> > >
> > > We still have around 70 URLs we expected to see after the migration
> > > was complete but that produce a 404. I know some of the patches to
> > > produce those pages are in progress, but please check the list at
> > > https://doughellmann.com/doc-migration/ if your team is listed below
> > > to ensure that nothing has been missed.
> > >
> > >   cinder
> > >   cloudkitty
> > >   congress
> > >   designate
> > >   heat
> > >   ironic
> > >   karbor
> > >   keystone
> > >   magnum
> > >   manila
> > >   murano
> > >   neutron
> > >   nova
> > >   sahara
> > >   senlin
> > >   swift
> > >   tacker
> > >   telementry
> > >   tricircle
> > >   trove
> > >   vitrage
> > >   watcher
> > >   zaqar
> > >   zun
> > >
> > > Reply here or ping me in #openstack-docs if you have questions or need
> a
> > > hand.
> > >
> > > Doug
> > >
> > > ___
> > > OpenStack-docs mailing list
> > > openstack-d...@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> >
>
> __
> 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
>
__
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] How should we go about removing legacy VIF types in Queens?

[Kevin Benton]

Yeah, if one clearly belongs to a single vendor moving is definitely the
way to go.

OVS itself is a good example of one that is used by lots of drivers. Since
it's in os-vif maybe we should do the same for any others without a clear
association (e.g. vif_type='tap' is about as vendor agnostic as you can
get).

On Wed, Jul 19, 2017 at 3:31 AM, Stephen Finucane <sfinu...@redhat.com>
wrote:

> On Thu, 2017-07-13 at 07:54 -0600, Kevin Benton wrote:
> > On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane <sfinu...@redhat.com>
> wrote:
> >
> > > os-vif has been integrated into nova since the newton cycle. With the
> > > integration of os-vif, the expectation is that all the old, non-os-vif
> > > plugging/unplugging code found in [1] will be replaced by code that
> > > harnesses
> > > os-vif plugins [2]. This has happened for a few of the VIF types, and
> newer
> > > VIFs are being added in this manner [3]. However, there are quite a few
> > > VIFs
> > > that are still using the legacy path, and I think it's about time we
> > > started
> > > moving things forward. Doing so allows us to continue to progress on
> > > passing
> > > os-vif objects from neutron and remove the large swathes of legacy code
> > > still
> > > found in nova.
> > >
> > > I've opened a bug against networking-bigswitch [4] for one of these VIF
> > > types,
> > > IVS, and I'm thinking I'll do the same for a lot of the other VIF types
> > > where I
> > > can find definite vendors. Is there anything else we can do though? At
> some
> > > point we're going to have to just start deleting code and I'd like to
> avoid
> > > leaving operators in the lurch.
> >
> > Some of the stuff like '802.1qbh' isn't particularly vendor specific so
> I'm
> > not sure who will host it and a repo just for that seems like a bit much.
> > Should we just bite the bullet and convert them in the nova tree or put
> them
> > in os-vif?
>
> That VIF type actually seems to be a CISCO-only option [1][2] but I get
> what
> you're saying. I think we can definitely move some of them, though (IVS,
> for a
> start). Perhaps moving the ones that *do* have clear owners to their
> respective
> packages is the way to go?
>
> Stephen
>
> [1] http://codesearch.openstack.org/?q=802.1qbh=nope==
> [2] https://git.openstack.org/cgit/openstack/networking-
> cisco/tree/networking_c
> isco/plugins/ml2/drivers/cisco/ucsm/constants.py
>
__
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

[openstack-dev] [neutron] - making external subnets visible by default

[Kevin Benton]

Hi all,

In the process of making it possible to make external subnets visible via a
policy.json entry[1] I ran into a limitation of our DB pagination in
conjunction with the policy engine.

The queries to the DB do not take into account policy.json entries so users
may get fewer subnets than requested after the policy engine has filtered
them out. This is causing the CI to fail on that patch since the default is
to not allow users to see external subnets.

Before I go through a bunch of work to adjust the tests to handle this
case, I was wondering what people thought of just making external subnets
visible by default in our default policy.json at the same time.

Does anyone have any objections to making external subnets visible by
default?

1. https://review.openstack.org/#/c/476094/

Cheers,
Kevin Benton
__
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] How should we go about removing legacy VIF types in Queens?

[Kevin Benton]

Some of the stuff like '802.1qbh' isn't particularly vendor specific so I'm
not sure who will host it and a repo just for that seems like a bit much.
Should we just bite the bullet and convert them in the nova tree or put
them in os-vif?


On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane 
wrote:

> os-vif has been integrated into nova since the newton cycle. With the
> integration of os-vif, the expectation is that all the old, non-os-vif
> plugging/unplugging code found in [1] will be replaced by code that
> harnesses
> os-vif plugins [2]. This has happened for a few of the VIF types, and newer
> VIFs are being added in this manner [3]. However, there are quite a few
> VIFs
> that are still using the legacy path, and I think it's about time we
> started
> moving things forward. Doing so allows us to continue to progress on
> passing
> os-vif objects from neutron and remove the large swathes of legacy code
> still
> found in nova.
>
> I've opened a bug against networking-bigswitch [4] for one of these VIF
> types,
> IVS, and I'm thinking I'll do the same for a lot of the other VIF types
> where I
> can find definite vendors. Is there anything else we can do though? At some
> point we're going to have to just start deleting code and I'd like to avoid
> leaving operators in the lurch.
>
> Cheers,
> Stephen
>
> [1] https://github.com/openstack/nova/blob/6205a3f8c/nova/virt/
> libvirt/vif.py#L
> 599-L764
> [2] https://github.com/openstack/nova/blob/6205a3f8c/nova/
> network/os_vif_util.p
> y#L346-L403
> [3] https://github.com/Juniper/contrail-nova-vif-driver
> [4] https://bugs.launchpad.net/networking-bigswitch/+bug/1704129
>
> __
> 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
>
__
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][ml2][drivers][openvswitch] Question

[Kevin Benton]

Yes, let's move discussion to bug report.

On Fri, Jun 23, 2017 at 5:01 AM, Margin Hu <today.g...@163.com> wrote:

> Hi kevin,
>
> [ovs]
> bridge_mappings = physnet1:br-ex,physnet2:provision,physnet3:provider
> ovsdb_connection = tcp:10.53.16.12:6640
> local_ip = 10.53.32.12
> you can check the attachement,  and more logs can be found at
> https://bugs.launchpad.net/neutron/+bug/1697243
>
>
> On 6/23 16:43, Kevin Benton wrote:
>
> Can you provide your ml2_conf.ini values you are using?
>
> On Thu, Jun 22, 2017 at 7:06 AM, Margin Hu <today.g...@163.com> wrote:
>
>> thanks.
>>
>> I met an issue , I  configured three ovs bridge ( br-ex, provision,
>> provider) in ml2_conf.ini  but after I reboot the node , found only 2
>> bridges flow table is normal , the other one bridge's flow table is empty.
>>
>> the bridge sometimes is "provision" , sometimes is "provider" ,  which
>> possibilities is there for this issue.?
>> [root@cloud]# ovs-ofctl show provision
>> OFPT_FEATURES_REPLY (xid=0x2): dpid:248a075541e8
>> n_tables:254, n_buffers:256
>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
>> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>>  1(bond0): addr:24:8a:07:55:41:e8
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  2(phy-provision): addr:2e:7c:ba:fe:91:72
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  LOCAL(provision): addr:24:8a:07:55:41:e8
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>> [root@cloud]# ovs-ofctl dump-flows  provision
>> NXST_FLOW reply (xid=0x4):
>>
>> [root@cloud]# ip r
>> default via 192.168.60.247 dev br-ex
>> 10.53.16.0/24 dev vlan16  proto kernel  scope link  src 10.53.16.11
>> 10.53.17.0/24 dev provider  proto kernel  scope link  src 10.53.17.11
>> 10.53.22.0/24 dev vlan22  proto kernel  scope link  src 10.53.22.111
>> 10.53.32.0/24 dev vlan32  proto kernel  scope link  src 10.53.32.11
>> 10.53.33.0/24 dev provision  proto kernel  scope link  src 10.53.33.11
>> 10.53.128.0/24 dev docker0  proto kernel  scope link  src 10.53.128.1
>> 169.254.0.0/16 dev vlan16  scope link  metric 1012
>> 169.254.0.0/16 dev vlan22  scope link  metric 1014
>> 169.254.0.0/16 dev vlan32  scope link  metric 1015
>> 169.254.0.0/16 dev br-ex  scope link  metric 1032
>> 169.254.0.0/16 dev provision  scope link  metric 1033
>> 169.254.0.0/16 dev provider  scope link  metric 1034
>> 192.168.60.0/24 dev br-ex  proto kernel  scope link  src 192.168.60.111
>>
>> what' the root cause ?
>>
>>  rpm -qa | grep openvswitch
>> openvswitch-2.6.1-4.1.git20161206.el7.x86_64
>> python-openvswitch-2.6.1-4.1.git20161206.el7.noarch
>> openstack-neutron-openvswitch-10.0.1-1.el7.noarch
>>
>>
>>
>> On 6/22 9:53, Kevin Benton wrote:
>>
>> Rules to allow aren't setup until the port is wired and it calls the
>> functions like this:
>> https://github.com/openstack/neutron/blob/master/neutron/plu
>> gins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L602-L606
>>
>> On Wed, Jun 21, 2017 at 4:49 PM, Margin Hu <today.g...@163.com> wrote:
>>
>>> Hi Guys,
>>>
>>> I have a question in setup_physical_bridges funtion  of
>>> neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
>>>
>>>  # block all untranslated traffic between bridges
>>> self.int_br.drop_port(in_port=int_ofport)
>>> br.drop_port(in_port=phys_ofport)
>>>
>>> [refer](https://github.com/openstack/neutron/blob/master/neu
>>> tron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1159)
>>>
>>> when permit traffic between bridges ?  when modify flow table of ovs
>>> bridge?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>
>
__
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][ml2][drivers][openvswitch] Question

[Kevin Benton]

Can you provide your ml2_conf.ini values you are using?

On Thu, Jun 22, 2017 at 7:06 AM, Margin Hu <today.g...@163.com> wrote:

> thanks.
>
> I met an issue , I  configured three ovs bridge ( br-ex, provision,
> provider) in ml2_conf.ini  but after I reboot the node , found only 2
> bridges flow table is normal , the other one bridge's flow table is empty.
>
> the bridge sometimes is "provision" , sometimes is "provider" ,  which
> possibilities is there for this issue.?
> [root@cloud]# ovs-ofctl show provision
> OFPT_FEATURES_REPLY (xid=0x2): dpid:248a075541e8
> n_tables:254, n_buffers:256
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>  1(bond0): addr:24:8a:07:55:41:e8
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  2(phy-provision): addr:2e:7c:ba:fe:91:72
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  LOCAL(provision): addr:24:8a:07:55:41:e8
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
> [root@cloud]# ovs-ofctl dump-flows  provision
> NXST_FLOW reply (xid=0x4):
>
> [root@cloud]# ip r
> default via 192.168.60.247 dev br-ex
> 10.53.16.0/24 dev vlan16  proto kernel  scope link  src 10.53.16.11
> 10.53.17.0/24 dev provider  proto kernel  scope link  src 10.53.17.11
> 10.53.22.0/24 dev vlan22  proto kernel  scope link  src 10.53.22.111
> 10.53.32.0/24 dev vlan32  proto kernel  scope link  src 10.53.32.11
> 10.53.33.0/24 dev provision  proto kernel  scope link  src 10.53.33.11
> 10.53.128.0/24 dev docker0  proto kernel  scope link  src 10.53.128.1
> 169.254.0.0/16 dev vlan16  scope link  metric 1012
> 169.254.0.0/16 dev vlan22  scope link  metric 1014
> 169.254.0.0/16 dev vlan32  scope link  metric 1015
> 169.254.0.0/16 dev br-ex  scope link  metric 1032
> 169.254.0.0/16 dev provision  scope link  metric 1033
> 169.254.0.0/16 dev provider  scope link  metric 1034
> 192.168.60.0/24 dev br-ex  proto kernel  scope link  src 192.168.60.111
>
> what' the root cause ?
>
>  rpm -qa | grep openvswitch
> openvswitch-2.6.1-4.1.git20161206.el7.x86_64
> python-openvswitch-2.6.1-4.1.git20161206.el7.noarch
> openstack-neutron-openvswitch-10.0.1-1.el7.noarch
>
>
>
> On 6/22 9:53, Kevin Benton wrote:
>
> Rules to allow aren't setup until the port is wired and it calls the
> functions like this:
> https://github.com/openstack/neutron/blob/master/neutron/
> plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L602-L606
>
> On Wed, Jun 21, 2017 at 4:49 PM, Margin Hu <today.g...@163.com> wrote:
>
>> Hi Guys,
>>
>> I have a question in setup_physical_bridges funtion  of
>> neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
>>
>>  # block all untranslated traffic between bridges
>> self.int_br.drop_port(in_port=int_ofport)
>> br.drop_port(in_port=phys_ofport)
>>
>> [refer](https://github.com/openstack/neutron/blob/master/neu
>> tron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1159)
>>
>> when permit traffic between bridges ?  when modify flow table of ovs
>> bridge?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
__
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][ml2][drivers][openvswitch] Question

[Kevin Benton]

Rules to allow aren't setup until the port is wired and it calls the
functions like this:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L602-L606

On Wed, Jun 21, 2017 at 4:49 PM, Margin Hu  wrote:

> Hi Guys,
>
> I have a question in setup_physical_bridges funtion  of
> neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
>
>  # block all untranslated traffic between bridges
> self.int_br.drop_port(in_port=int_ofport)
> br.drop_port(in_port=phys_ofport)
>
> [refer](https://github.com/openstack/neutron/blob/master/neu
> tron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1159)
>
> when permit traffic between bridges ?  when modify flow table of ovs
> bridge?
>
>
>
>
>
>
>
>
>
> __
> 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
>
__
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][horizon][fwaas][vpnaas] fwaas/vpnaas dashboard split out

[Kevin Benton]

Some context here:
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115200.html

On Wed, Jun 21, 2017 at 2:33 AM, Thomas Morin 
wrote:

> Hi Akihiro,
>
> While I understand the motivation to move these dashboards from
> openstack/horizon, what is the reason to prefer a distinct repo for the
> dashboard rather than hosting it in the main repo of these projects ?
>
> (networking-bgpvpn has had a dashboard for some time already, it is hosted
> under networking-bgpvpn/bgpvpn_dashboard and we haven't heard about any
> drawback)
>
> Thanks,
>
> -Thomas
>
>
>
> Akihiro Motoki :
>
> Hi neutron and horizon teams (especially fwaas and vpnaas folks),
>
> As we discussed so far, I prepared separate git repositories for FWaaS
> and VPNaaS 
> dashboards.http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/
>
> All new features will be implemented in the new repositories, for
> example, FWaaS v2 support.
> The initial core members consist of neutron-fwaas/vpnaas-core
> (respectively) + horizon-core.
>
> There are several things to do to complete the split out.
> I gathered a list of work items at the etherpad and we will track the
> progress here.https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
> If you are interested in helping the efforts, sign up on the etherpad
> or contact me.
>
> I would like to release the initial release which is compatible with
> the current horizon
> FWaaS/VPNaaS dashboard (with no new features).
> I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).
>
> It also will be good examples for neutron stadium/related projects
> which are interested in
> adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
> interested in it.
>
> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __
> 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
>
>
__
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] Do we still support core plugin not based on the ML2 framework?

[Kevin Benton]

Why not just delete the service plugins you don't support from the default
plugins dict?

On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau <edouard.thul...@gmail.com>
wrote:

> Ok, we would like to help on that. How we can start?
>
> I think the issue I raise in that thread must be the first point to
> address and my second proposition seems to be the correct one. What do
> you think?
> But it will needs some time and not sure we'll be able to fix all
> service plugins loaded by default before the next Pike release.
>
> I like to propose a workaround until all default service plugins will
> be compatible with non-DB core plugins. We can continue to load that
> default service plugins list but authorizing a core plugin to disable
> it completely with a private attribut on the core plugin class like
> it's done for bulk/pagination/sorting operations.
>
> Of course, we need to add the ability to report any regression on
> that. I think unit tests will help and we can also work on a
> functional test based on a fake non-DB core plugin.
>
> Regards,
> Édouard.
>
> On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton <ke...@benton.pub> wrote:
> > The issue is mainly developer resources. Everyone currently working
> upstream
> > doesn't have the bandwidth to keep adding/reviewing the layers of
> interfaces
> > to make the DB optional that go untested. (None of the projects that
> would
> > use them run a CI system that reports results on Neutron patches.)
> >
> > I think we can certainly accept patches to do the things you are
> proposing,
> > but there is no guarantee that it won't regress to being DB-dependent
> until
> > there is something reporting results back telling us when it breaks.
> >
> > So it's not that the community is against non-DB core plugins, it's just
> > that the people developing those plugins don't participate in the
> community
> > to ensure they work.
> >
> > Cheers
> >
> >
> > On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau <
> edouard.thul...@gmail.com>
> > wrote:
> >>
> >> Oops, sent too fast, sorry. I try again.
> >>
> >> Hi,
> >>
> >> Since Mitaka release, a default service plugins list is loaded when
> >> Neutron
> >> server starts [1]. That list is not editable and was extended with few
> >> services
> >> [2]. But all of them rely on the Neutron DB model.
> >>
> >> If a core driver is not based on the ML2 core plugin framework or not
> >> based on
> >> the 'neutron.db.models_v2' class, all that service plugins will not
> work.
> >>
> >> So my first question is Does Neutron still support core plugin not based
> >> on ML2
> >> or 'neutron.db.models_v2' class?
> >>
> >> If yes, I would like to propose two solutions:
> >> - permits core plugin to overload the service plugin class by it's own
> >> implementation and continuing to use the actual Neutron db based
> services
> >> as
> >> default.
> >> - modifying all default plugin service to use service plugin driver
> >> framework [3], and set the actual Neutron db based implementation as
> >> default driver for services. That permits to core drivers not based on
> the
> >> Neutron DB to specify a driver. We can see that solution was adopted in
> >> the
> >> networking-bgpvpn project, where can find two abstract driver classes,
> one
> >> for
> >> core driver based on Neutron DB model [4] and one used by core driver
> not
> >> based
> >> on the DB [5] as the Contrail driver [6].
> >>
> >> [1]
> >> https://github.com/openstack/neutron/commit/
> aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-
> 9169a6595980d19b2649d5bedfff05ce
> >> [2]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> plugins/common/constants.py#L43
> >> [3]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> services/service_base.py#L27
> >> [4]
> >> https://github.com/openstack/networking-bgpvpn/blob/master/
> networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
> >> [5]
> >> https://github.com/openstack/networking-bgpvpn/blob/master/
> networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
> >> [6]
> >> https://github.com/Juniper/contrail-neutron-plugin/blob/
> master/neutron_plugin_contrail/plugins/opencontrail/
> networking_bgpvpn/contrail.py#L36
> >>
> >> Regards,
> >> Édouard.
> >>
> >> On Mon, Jun 

Re: [openstack-dev] [neutron] [nova] [os-vif] OVS plugin assumes an incorrect datapath_type in os-vif

[Kevin Benton]

vif_details has always been a bag of goodies for mech drivers to pack in
information relevant to wiring up the vif_type. This sounds like a pretty
standard addition so I don't see any blockers.

On Tue, Jun 20, 2017 at 9:16 AM, Alonso Hernandez, Rodolfo <
rodolfo.alonso.hernan...@intel.com> wrote:

> Hello fellows:
>
>
>
> Currently there is a bug in os-vif [1
> ]. When os-vif tries to
> plug an OVS interface, the datapath type is hardcoded:
>
> -  https://github.com/openstack/os-vif/blob/
> 9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L100-L101
>
> -  https://github.com/openstack/os-vif/blob/
> 9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L127-L128
>
> -  https://github.com/openstack/os-vif/blob/
> 9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L135-L136
>
> -  https://github.com/openstack/os-vif/blob/
> 9fb7fe512902a37432e38d884b8be59ce91582db/vif_plug_ovs/ovs.py#L149-L150
>
>
>
> The problem is os-vif doesn’t have this information now. I’m proposing the
> following solution:
>
> -  Nova: https://review.openstack.org/#/c/474892/
>
> -  Neutron: https://review.openstack.org/#/c/474588/
>
> -  Neutron-lib: https://review.openstack.org/#/c/474248/
>
> -  os-vif: https://review.openstack.org/#/c/474914/
>
>
>
> Neutron will add to VIF details the datapath type to the vif details dict.
> If this information is not given in the config file, the default parameter
> written will be OVS_DATAPATH_SYSTEM, which is the default value. The change
> in neutron-lib is needed for Neutron to keep the same dict key name
> (matching the name set in nova.network.model)
>
> 1)
>
> 2)  Nova will receive this information (if given in the dict),
> getting the value stored in vif['details']. If the key is not set, the
> default datapath will be None. Because currently no information is passed
> and Nova doesn’t know about the different datapath types (this information
> is in Neutron), it makes sense not to assign any value. Nova is protected
> in case the dict doesn't have this information.
>
>
>
> Finally, os-vif will receive the VIF information given by Nova. If the
> datapath_type is not given in the variable (dict) or the value is None, the
> default value (OVS_DATAPATH_SYSTEM) will be set.
>
>
>
> As you can see, it's indeed an API change, but the projects affected are
> protected in case the information expected in the variable passed is not
> present.
>
>
>
> What do you think?
>
>
>
> Thank you in advance.
>
>
>
> [1] https://bugs.launchpad.net/os-vif/+bug/1632372
>
>
>
>
>
>
>
>
>
> __
> 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
>
>
__
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] security group OVO change

[Kevin Benton]

Does this fix your issue? https://review.openstack.org/#/c/475445/

On Mon, Jun 19, 2017 at 12:21 AM, Gary Kotton <gkot...@vmware.com> wrote:

> Sorry for being vague – have been debugging.
>
> We overwrite the base method:
>
>
>
> with db_api.context_manager.writer.using(context):
>
> secgroup_db = (
>
> super(NsxV3Plugin, self).create_security_group(
>
> context, security_group, default_sg))
>
> nsx_db.save_sg_mappings(context,
>
> secgroup_db['id'],
>
> ns_group['id'],
>
> firewall_section['id'])
>
> self._process_security_group_
> properties_create(context,
>
>
> secgroup_db,
>
>
> secgroup,
>
>
> default_sg)
>
>
>
> The secgroup_db that returns always has empty rules. If I remove the
> transaction then it works.
>
> Still trying to figure out why when we call:
>
> with db_api.context_manager.writer.using(context):
>
> secgroup_db = (
>
> super(NsxV3Plugin, self).create_security_group(…
>
>
>
> The rules are not populated. The db_api.context_manager.writer.using is
> what is causing the problem.
>
>
>
> As a work around we reread the object when we need to process the rules.
> Not sure if anyone else has hit this
>
> Thanks
>
> Gary
>
>
>
> *From: *Kevin Benton <ke...@benton.pub>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Monday, June 19, 2017 at 10:01 AM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Cc: *"isaku.yamah...@gmail.com" <isaku.yamah...@gmail.com>
> *Subject: *Re: [openstack-dev] [neutron] security group OVO change
>
>
>
> Do you mean the callback event for AFTER_CREATE is missing the rules when
> it's for default security groups?
>
>
>
> On Sun, Jun 18, 2017 at 4:44 AM, Gary Kotton <gkot...@vmware.com> wrote:
>
> Hi,
> That patch looks good. We still have an issue in that the create security
> groups does not return the list of the default rules.
> Thanks
> Gary
>
>
> On 6/17/17, 2:33 AM, "Isaku Yamahata" <isaku.yamah...@gmail.com> wrote:
>
> It also broke networking-odl.
> The patch[1] is needed to unbreak.
> [1] https://review.openstack.org/#/c/448420/
>
> necessary db info is taken from context.session.new.
> But with OVO, those expunge themselves with create method.
> Those info needs to be passed as callback argument.
>
> Thanks,
>
> On Fri, Jun 16, 2017 at 01:25:28PM -0700,
> Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>
> > To close the loop here,
> >
> > - this also broke heat py3 job (https://launchpad.net/bugs/1698355)
> > - we polished https://review.openstack.org/474575 to fix both
> > vmware-nsx and heat issues
> > - I also posted a patch for oslo.serialization for the bug that
> > triggered MemoryError in heat gate:
> > https://review.openstack.org/475052
> > - the vmware-nsx adoption patch is at:
> > https://review.openstack.org/#/c/474608/ and @boden is working on
> it,
> > should be ready to go in due course.
> >
> > Thanks and sorry for inconveniences,
> > Ihar
> >
> > On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton <gkot...@vmware.com>
> wrote:
> > > Hi,
> > >
> > > The commit https://review.openstack.org/284738 has broken
> decomposed plugins
> > > (those that extend security groups and rules). The reason for this
> is that
> > > there is a extend callback that we use which expects to get a
> database
> > > object and the aforementioned patch passes a new neutron object.
> > >
> > > I have posted [i] to temporarily address the issue. An alternative
> is to
> > > revert the patch until the decomposed plugins can figure out how to
> > > correctly address this.
> > >
> > > Thanks
> > >
> > > Gary
> > >
> > > [i] https://review.openstack.org/474575
> > >
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.or

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Kevin Benton]

The issue is mainly developer resources. Everyone currently working
upstream doesn't have the bandwidth to keep adding/reviewing the layers of
interfaces to make the DB optional that go untested. (None of the projects
that would use them run a CI system that reports results on Neutron
patches.)

I think we can certainly accept patches to do the things you are proposing,
but there is no guarantee that it won't regress to being DB-dependent until
there is something reporting results back telling us when it breaks.

So it's not that the community is against non-DB core plugins, it's just
that the people developing those plugins don't participate in the community
to ensure they work.

Cheers


On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau 
wrote:

> Oops, sent too fast, sorry. I try again.
>
> Hi,
>
> Since Mitaka release, a default service plugins list is loaded when Neutron
> server starts [1]. That list is not editable and was extended with few
> services
> [2]. But all of them rely on the Neutron DB model.
>
> If a core driver is not based on the ML2 core plugin framework or not
> based on
> the 'neutron.db.models_v2' class, all that service plugins will not work.
>
> So my first question is Does Neutron still support core plugin not based
> on ML2
> or 'neutron.db.models_v2' class?
>
> If yes, I would like to propose two solutions:
> - permits core plugin to overload the service plugin class by it's own
> implementation and continuing to use the actual Neutron db based services
> as
> default.
> - modifying all default plugin service to use service plugin driver
> framework [3], and set the actual Neutron db based implementation as
> default driver for services. That permits to core drivers not based on the
> Neutron DB to specify a driver. We can see that solution was adopted in the
> networking-bgpvpn project, where can find two abstract driver classes, one
> for
> core driver based on Neutron DB model [4] and one used by core driver not
> based
> on the DB [5] as the Contrail driver [6].
>
> [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
> [2] https://github.com/openstack/neutron/blob/master/neutron/plu
> gins/common/constants.py#L43
> [3] https://github.com/openstack/neutron/blob/master/neutron/ser
> vices/service_base.py#L27
> [4] https://github.com/openstack/networking-bgpvpn/blob/master/n
> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
> [5] https://github.com/openstack/networking-bgpvpn/blob/master/n
> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
> [6] https://github.com/Juniper/contrail-neutron-plugin/blob/mast
> er/neutron_plugin_contrail/plugins/opencontrail/networkin
> g_bgpvpn/contrail.py#L36
>
> Regards,
> Édouard.
>
> On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau
>  wrote:
> > Hi,
> > Since Mitaka release [1], a default service plugins list is loaded
> > when Neutron server starts. That list is not editable and was extended
> > with few services [2]. But none of th
> >
> > [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
> > [2] https://github.com/openstack/neutron/blob/master/neutron/plu
> gins/common/constants.py#L43
>
> __
> 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
>
__
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] tempest failures when deploying neutron-server in wsgi with apache

[Kevin Benton]

Thanks. Maybe this would be a good opportunity to just have people start
putting everything in neutron.conf if they want to switch to wsgi.

On Mon, Jun 19, 2017 at 12:21 AM, Matthew Treinish <mtrein...@kortar.org>
wrote:

> On Mon, Jun 19, 2017 at 12:09:12AM -0700, Kevin Benton wrote:
> > I've been working on Victor's patch a bit. One thing that isn't clear to
> me
> > is how we can get the neutron.conf options loaded when using WSGI. How
> are
> > other projects doing this?
>
> Most projects are using a default location, for example:
>
> https://review.openstack.org/#/c/459450/11/glance/common/wsgi_app.py
>
> Which IIRC I just looked at how other project's wsgi entrypoints were
> doing it
> when I wrote that. The issue I think we'll hit with Neutron is that by
> default
> we tell everyone to do that annoying multi-file config setup, which makes
> doing
> a default like this difficult. Personally I think we need to change that,
> because it's not needed and makes it generally confusing, but even if we
> did
> it wouldn't solve the upgrade path from non-wsgi to wsgi.
>
> -Matt Treinish
>
> >
> > On Fri, Jun 2, 2017 at 7:44 AM, Emilien Macchi <emil...@redhat.com>
> wrote:
> >
> > > On Thu, Jun 1, 2017 at 10:28 PM, Morales, Victor
> > > <victor.mora...@intel.com> wrote:
> > > > Hi Emilien,
> > > >
> > > > I noticed that the configuration file was created using puppet.  I
> > > submitted a patch[1] that was targeting to include the changes in
> Devstack.
> > > My major concern is with the value of WSGIScriptAlias which should be
> > > pointing to WSGI script.
> > >
> > > Thanks for looking, the script that is used is from
> > > /usr/bin/neutron-api which is I think correct. If you look at logs,
> > > you can see that API actually works but some tempest tests fail
> > > though...
> > >
> > > > Regards/Saludos
> > > > Victor Morales
> > > >
> > > > [1] https://review.openstack.org/#/c/439191
> > > >
> > > > On 5/31/17, 4:40 AM, "Emilien Macchi" <emil...@redhat.com> wrote:
> > > >
> > > > Hey folks,
> > > >
> > > > I've been playing with deploying Neutron in WSGI with Apache and
> > > > Tempest tests fail on spawning Nova server when creating Neutron
> > > > ports:
> > > > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> > > openstack-integration-4-scenario001-tempest-centos-7/
> > > f2ee8bf/console.html#_2017-05-30_13_09_22_715400
> > > >
> > > > I haven't found anything useful in neutron-server logs:
> > > > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> > > openstack-integration-4-scenario001-tempest-centos-7/
> > > f2ee8bf/logs/apache/neutron_wsgi_access_ssl.txt.gz
> > > >
> > > > Before I file a bug in neutron, can anyone look at the logs with
> me
> > > > and see if I missed something in the config:
> > > > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> > > openstack-integration-4-scenario001-tempest-centos-7/
> > > f2ee8bf/logs/apache_config/10-neutron_wsgi.conf.txt.gz
> > > >
> > > > Thanks for the help,
> > > > --
> > > > Emilien Macchi
> > > >
> > > > 
> > > __
> > > > 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
> > > >
> > > >
> > > > 
> > > __
> > > > 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
> > >
> > >
> > >
> > > --
> > > Emilien Macchi
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman

Re: [openstack-dev] [neutron] tempest failures when deploying neutron-server in wsgi with apache

[Kevin Benton]

I've been working on Victor's patch a bit. One thing that isn't clear to me
is how we can get the neutron.conf options loaded when using WSGI. How are
other projects doing this?

On Fri, Jun 2, 2017 at 7:44 AM, Emilien Macchi  wrote:

> On Thu, Jun 1, 2017 at 10:28 PM, Morales, Victor
>  wrote:
> > Hi Emilien,
> >
> > I noticed that the configuration file was created using puppet.  I
> submitted a patch[1] that was targeting to include the changes in Devstack.
> My major concern is with the value of WSGIScriptAlias which should be
> pointing to WSGI script.
>
> Thanks for looking, the script that is used is from
> /usr/bin/neutron-api which is I think correct. If you look at logs,
> you can see that API actually works but some tempest tests fail
> though...
>
> > Regards/Saludos
> > Victor Morales
> >
> > [1] https://review.openstack.org/#/c/439191
> >
> > On 5/31/17, 4:40 AM, "Emilien Macchi"  wrote:
> >
> > Hey folks,
> >
> > I've been playing with deploying Neutron in WSGI with Apache and
> > Tempest tests fail on spawning Nova server when creating Neutron
> > ports:
> > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> openstack-integration-4-scenario001-tempest-centos-7/
> f2ee8bf/console.html#_2017-05-30_13_09_22_715400
> >
> > I haven't found anything useful in neutron-server logs:
> > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> openstack-integration-4-scenario001-tempest-centos-7/
> f2ee8bf/logs/apache/neutron_wsgi_access_ssl.txt.gz
> >
> > Before I file a bug in neutron, can anyone look at the logs with me
> > and see if I missed something in the config:
> > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> openstack-integration-4-scenario001-tempest-centos-7/
> f2ee8bf/logs/apache_config/10-neutron_wsgi.conf.txt.gz
> >
> > Thanks for the help,
> > --
> > Emilien Macchi
> >
> > 
> __
> > 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
> >
> >
> > 
> __
> > 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
>
>
>
> --
> Emilien Macchi
>
> __
> 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
>
__
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] security group OVO change

[Kevin Benton]

Do you mean the callback event for AFTER_CREATE is missing the rules when
it's for default security groups?

On Sun, Jun 18, 2017 at 4:44 AM, Gary Kotton  wrote:

> Hi,
> That patch looks good. We still have an issue in that the create security
> groups does not return the list of the default rules.
> Thanks
> Gary
>
> On 6/17/17, 2:33 AM, "Isaku Yamahata"  wrote:
>
> It also broke networking-odl.
> The patch[1] is needed to unbreak.
> [1] https://review.openstack.org/#/c/448420/
>
> necessary db info is taken from context.session.new.
> But with OVO, those expunge themselves with create method.
> Those info needs to be passed as callback argument.
>
> Thanks,
>
> On Fri, Jun 16, 2017 at 01:25:28PM -0700,
> Ihar Hrachyshka  wrote:
>
> > To close the loop here,
> >
> > - this also broke heat py3 job (https://launchpad.net/bugs/1698355)
> > - we polished https://review.openstack.org/474575 to fix both
> > vmware-nsx and heat issues
> > - I also posted a patch for oslo.serialization for the bug that
> > triggered MemoryError in heat gate:
> > https://review.openstack.org/475052
> > - the vmware-nsx adoption patch is at:
> > https://review.openstack.org/#/c/474608/ and @boden is working on
> it,
> > should be ready to go in due course.
> >
> > Thanks and sorry for inconveniences,
> > Ihar
> >
> > On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton 
> wrote:
> > > Hi,
> > >
> > > The commit https://review.openstack.org/284738 has broken
> decomposed plugins
> > > (those that extend security groups and rules). The reason for this
> is that
> > > there is a extend callback that we use which expects to get a
> database
> > > object and the aforementioned patch passes a new neutron object.
> > >
> > > I have posted [i] to temporarily address the issue. An alternative
> is to
> > > revert the patch until the decomposed plugins can figure out how to
> > > correctly address this.
> > >
> > > Thanks
> > >
> > > Gary
> > >
> > > [i] https://review.openstack.org/474575
> > >
> > >
> > > 
> __
> > > 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
> > >
> >
> > 
> __
> > 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
>
> --
> Isaku Yamahata 
>
> 
> __
> 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
>
>
> __
> 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
>
__
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] does neutron actually use the salve_connection ?

[Kevin Benton]

No, it currently does not. As we implement
https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch that
will change, but that won't be available until Pike or Queens.

On Thu, Jun 15, 2017 at 5:47 AM,  wrote:

> Hello,
>
>
>
>
>
>
>
> I am looking to improve the database load distribution and one of the
> things that may help with this is to spread out the reads.
>
> From the configuration reference it looks like neutron dues support a
> slave_connection parameter but when I enabled it and enabled query logging
> on the secondary databases there aren’t any queries being executed on the
> secondaries. Is there anything I am missing ?
>
>
>
> Sorry for CC’ing the dev list as well but someone in the dev teams may
> have an answer from a developer point of view.
>
>
>
>
>
> My setup is like this:
>
>
>
> Openstack stable/mitaka (built from git)
>
> 3 galera nodes
>
> 1 haproxy running on each node with active/backup with local node as
> single active configuration for the frontend listening on :3306 and
> active/backup with the other nodes as active for the frontend listening on
> :3308
>
>
>
> In neutron.conf in the [database] section I set up the the connection and
> slave_connection parameters like this:
>
>
>
> [database]
>
> connection = mysql+pymysql://neutron:XXX@neutron-db.service:
> 3306/neutron?charset=utf8
>
> slave_connection = mysql+pymysql://neutron: XXX@neutron-db.service:
> 3308/neutron?charset=utf8
>
> idle_timeout = 1800
>
> max_retries = -1
>
> retry_interval = 5
>
> min_pool_size = 8
>
> max_pool_size = 32
>
> max_overflow = 16
>
>
>
>
>
> Loooking on a slave it opens a single connection which is eventually
> closed because of lack of activity.
>
>
>
>
> Thanks,
>
> Cristian
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> __
> 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
>
>
__
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] how to set default security group rules?

[Kevin Benton]

This isn't about the operating system of the instance or even the host.
It's the behavior of the Neutron API WRT what traffic will be filtered by
the default security group.

If we go down this route, users will have to expect effectively random sets
of security group rules from cloud to cloud and manually inspect each one.
If those are the semantics we want to provide, why have a default security
group at all?

Is your suggestion that since clouds are already inconsistent, we should
make it easier for operators to make it worse? It sounds silly, but the
main supporting argument for this seems to be that operators are already
breaking consistency using other scripts, etc so we shouldn't care.

On Fri, Jun 9, 2017 at 6:03 AM, Paul Belanger <pabelan...@redhat.com> wrote:

> On Fri, Jun 09, 2017 at 05:20:03AM -0700, Kevin Benton wrote:
> > This was an intentional decision. One of the goals of OpenStack is to
> > provide consistency across different clouds and configurable defaults for
> > new tenants default rules hurts consistency.
> >
> > If I write a script to boot up a workload on one OpenStack cloud that
> > allows everything by default and it doesn't work on another cloud that
> > doesn't allow everything by default, that leads to a pretty bad user
> > experience. I would now need logic to scan all of the existing security
> > group rules and do a diff between what I want and what is there and have
> > logic to resolve the difference.
> >
> FWIW: While that argument is valid, the reality is every cloud provider
> runs a
> different version of operating system you boot up your workload on, so it
> is
> pretty much assume that every cloud is different out of box.
>
> What we do now in openstack-infra, is place expected cloud
> configuration[2] in
> ansible-role-cloud-launcher[1], and run ansible against the cloud. This
> has been
> one of the ways we ensure consistency between clouds. Bonus point, we
> build and
> upload images daily to ensure our workloads are also the same.
>
> [1] http://git.openstack.org/cgit/openstack/ansible-role-cloud-launcher
> [2] http://git.openstack.org/cgit/openstack-infra/system-config/
> tree/playbooks/clouds_layouts.yml
>
> > It's a backwards-incompatible change so we'll probably be stuck with the
> > current behavior.
> >
> >
> > On Fri, Jun 9, 2017 at 2:27 AM, Ahmed Mostafa <ahmedmostafa...@gmail.com
> >
> > wrote:
> >
> > > I believe that there are no features impelemented in neutron that
> allows
> > > changing the rules for the default security group.
> > >
> > > I am also interested in seeing such a feature implemented.
> > >
> > > I see only this blueprint :
> > >
> > > https://blueprints.launchpad.net/neutron/+spec/default-
> > > rules-for-default-security-group
> > >
> > > But no work has been done on it so far.
> > >
> > >
> > >
> > > On Fri, Jun 9, 2017 at 9:16 AM, Paul Schlacter <wlfigh...@gmail.com>
> > > wrote:
> > >
> > >> I see the neutron code, which added the default rules to write
> very
> > >> rigid, only for ipv4 ipv6 plus two rules. What if I want to customize
> the
> > >> default rules?
> > >>
> > >> 
> > >> __
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscrib
> > >> e
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >>
> > >
> > > 
> __
> > > 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
> > >
> > >
>
> > 
> __
> > 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
>
>
> __
> 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
>
__
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] how to set default security group rules?

[Kevin Benton]

This was an intentional decision. One of the goals of OpenStack is to
provide consistency across different clouds and configurable defaults for
new tenants default rules hurts consistency.

If I write a script to boot up a workload on one OpenStack cloud that
allows everything by default and it doesn't work on another cloud that
doesn't allow everything by default, that leads to a pretty bad user
experience. I would now need logic to scan all of the existing security
group rules and do a diff between what I want and what is there and have
logic to resolve the difference.

It's a backwards-incompatible change so we'll probably be stuck with the
current behavior.


On Fri, Jun 9, 2017 at 2:27 AM, Ahmed Mostafa 
wrote:

> I believe that there are no features impelemented in neutron that allows
> changing the rules for the default security group.
>
> I am also interested in seeing such a feature implemented.
>
> I see only this blueprint :
>
> https://blueprints.launchpad.net/neutron/+spec/default-
> rules-for-default-security-group
>
> But no work has been done on it so far.
>
>
>
> On Fri, Jun 9, 2017 at 9:16 AM, Paul Schlacter 
> wrote:
>
>> I see the neutron code, which added the default rules to write very
>> rigid, only for ipv4 ipv6 plus two rules. What if I want to customize the
>> default rules?
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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
>
>
__
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][l2gw] OVS code currently broken

[Kevin Benton]

Can you file a bug against Neutron and reference it here?

On Thu, Jun 8, 2017 at 8:28 AM, Ricardo Noriega De Soto  wrote:

> There is actually a bunch of patches waiting to be reviewed and approved.
>
> Please, we'd need core reviewers to jump in.
>
> I'd like to thank Gary for all his support and reviews.
>
> Thanks Gary!
>
> On Tue, May 30, 2017 at 3:56 PM, Gary Kotton  wrote:
>
>> Hi,
>>
>> Please note that the L2 GW code is currently broken due to the commit
>> e6333593ae6005c4b0d73d9dfda5eb47f40dd8da
>>
>> If someone has the cycles can they please take a look.
>>
>> Thanks
>>
>> gary
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>
> __
> 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
>
>
__
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] pep8 broken

[Kevin Benton]

I think this was meant to fix it. https://review.openstack.org/#/c/471512/

On Wed, Jun 7, 2017 at 4:51 AM, Gary Kotton  wrote:

> Hi,
>
> It seems that the pep8 is broken due to https://github.com/openstack/
> requirements/commit/99fae827973465147359cc7032c83003802612a7
>
> Should we revert this?
>
> Thanks
>
> Gary
>
> __
> 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
>
>
__
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

[openstack-dev] No drivers meeting 6/1

[Kevin Benton]

Hi,

Due to a conflict today I am canceling the drivers meeting.

Cheers,
Kevin Benton
__
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][L3][HA] 2 masters after reboot of node

[Kevin Benton]

I recommend a completely new RPC endpoint to trigger this behavior that the
L3 agent calls before sync routers. Don't try to add it to sync routers
which is already quite complex. :)

On Fri, May 26, 2017 at 7:53 AM, Anil Venkata <anilvenk...@redhat.com>
wrote:

> Thanks Kevin, Agree with you. I will try to implement this suggestion.
>
> On Fri, May 26, 2017 at 7:01 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> Just triggering a status change should just be handled as a port update
>> on the agent side which shouldn't interrupt any existing flows. So an l3
>> agent reboot should be safe in this case.
>>
>> On May 26, 2017 6:06 AM, "Anil Venkata" <anilvenk...@redhat.com> wrote:
>>
>>> On Fri, May 26, 2017 at 6:14 PM, Kevin Benton <ke...@benton.pub> wrote:
>>>
>>>> Perhaps when the L3 agent starts up we can have it explicitly set the
>>>> port status to DOWN for all of the HA ports on that node. Then we are
>>>> guaranteed that when they go to ACTIVE it will be because the L2 agent has
>>>> wired the ports.
>>>>
>>>>
>>> Thanks Kevin. Will it create dependency of dataplane on controlplane.
>>> For example, if the node is properly configured(l2 agent wired up,
>>> keepalived configured, VRRP exchange happening) but user just restarted
>>> only l3 agent, then with the suggestion we won't break l2
>>> connectivity(leading to multiple HA masters) by re configuring again?
>>>
>>> Or is there a way server can detect that node(not only agent) is down
>>> and set port status?
>>>
>>>
>>>> On Fri, May 26, 2017 at 5:27 AM, Anil Venkata <anilvenk...@redhat.com>
>>>> wrote:
>>>>
>>>>> This is regarding https://bugs.launchpad.net/neutron/+bug/1597461
>>>>> Earlier to fix this, we added code [1] to spawn keepalived only when
>>>>> HA network port status is active.
>>>>>
>>>>> But, on reboot, node will get HA network port's status as ACTIVE from
>>>>> server(please see comment [2]),
>>>>> though l2 agent might not have wired[3] the port, resulting in
>>>>> spawning  keepalived. Any suggestions
>>>>> how l3 agent can detect that l2 agent has not wired the port and
>>>>> then avoid spawning keepalived?
>>>>>
>>>>> [1] https://review.openstack.org/#/c/357458/
>>>>> [2] https://bugs.launchpad.net/neutron/+bug/1597461/comments/26
>>>>> [3] l2 agent wiring means setting up ovs flows on br-tun to make port
>>>>> usable
>>>>>
>>>>> Thanks
>>>>> Anilvenkata
>>>>>
>>>>> 
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>>> enstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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
>
>
__
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][L3][HA] 2 masters after reboot of node

[Kevin Benton]

Just triggering a status change should just be handled as a port update on
the agent side which shouldn't interrupt any existing flows. So an l3 agent
reboot should be safe in this case.

On May 26, 2017 6:06 AM, "Anil Venkata" <anilvenk...@redhat.com> wrote:

> On Fri, May 26, 2017 at 6:14 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> Perhaps when the L3 agent starts up we can have it explicitly set the
>> port status to DOWN for all of the HA ports on that node. Then we are
>> guaranteed that when they go to ACTIVE it will be because the L2 agent has
>> wired the ports.
>>
>>
> Thanks Kevin. Will it create dependency of dataplane on controlplane. For
> example, if the node is properly configured(l2 agent wired up, keepalived
> configured, VRRP exchange happening) but user just restarted only l3 agent,
> then with the suggestion we won't break l2 connectivity(leading to multiple
> HA masters) by re configuring again?
>
> Or is there a way server can detect that node(not only agent) is down and
> set port status?
>
>
>> On Fri, May 26, 2017 at 5:27 AM, Anil Venkata <anilvenk...@redhat.com>
>> wrote:
>>
>>> This is regarding https://bugs.launchpad.net/neutron/+bug/1597461
>>> Earlier to fix this, we added code [1] to spawn keepalived only when HA
>>> network port status is active.
>>>
>>> But, on reboot, node will get HA network port's status as ACTIVE from
>>> server(please see comment [2]),
>>> though l2 agent might not have wired[3] the port, resulting in spawning
>>>  keepalived. Any suggestions
>>> how l3 agent can detect that l2 agent has not wired the port and
>>> then avoid spawning keepalived?
>>>
>>> [1] https://review.openstack.org/#/c/357458/
>>> [2] https://bugs.launchpad.net/neutron/+bug/1597461/comments/26
>>> [3] l2 agent wiring means setting up ovs flows on br-tun to make port
>>> usable
>>>
>>> Thanks
>>> Anilvenkata
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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
>
>
__
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][L3][HA] 2 masters after reboot of node

[Kevin Benton]

Perhaps when the L3 agent starts up we can have it explicitly set the port
status to DOWN for all of the HA ports on that node. Then we are guaranteed
that when they go to ACTIVE it will be because the L2 agent has wired the
ports.

On Fri, May 26, 2017 at 5:27 AM, Anil Venkata 
wrote:

> This is regarding https://bugs.launchpad.net/neutron/+bug/1597461
> Earlier to fix this, we added code [1] to spawn keepalived only when HA
> network port status is active.
>
> But, on reboot, node will get HA network port's status as ACTIVE from
> server(please see comment [2]),
> though l2 agent might not have wired[3] the port, resulting in spawning
>  keepalived. Any suggestions
> how l3 agent can detect that l2 agent has not wired the port and
> then avoid spawning keepalived?
>
> [1] https://review.openstack.org/#/c/357458/
> [2] https://bugs.launchpad.net/neutron/+bug/1597461/comments/26
> [3] l2 agent wiring means setting up ovs flows on br-tun to make port
> usable
>
> Thanks
> Anilvenkata
>
> __
> 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
>
>
__
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]VM packet lost on qbr bridge

[Kevin Benton]

Is it being dropped by iptables? Check the following:

* Your VM using the correct IPv6 address assigned to it by Neutron
* The security group associated with the port allows outbound IPv6 traffic
* ensure bridge-nf-call-ip6tables is set to 1 in the kernel of the compute
node

On Thu, May 25, 2017 at 9:28 PM, zhouzhih...@cmss.chinamobile.com <
zhouzhih...@cmss.chinamobile.com> wrote:

> Hi All,
>
>
> I met a problem of dns packet lost in openstack environment. I need help.
>
> The problem desc:
>
> In the vm, I use "curl http://www.baidu.com;  to do
> test. And the cmd takes almost 5 seconds return.
> So I use tcpdump to capture the packets. And found a dns packet lost which
> is  packet for ipv6.
>
> The packet-lost-on-qbr.zip are the captured packets which is from qbr to
> qvb. It clearly shows the lost packet.
>
> In my another openstack environment, the problem can not occur.  The 
> qbr-no-packet-lost.zip
> is the captured packets.
>
> Thanks
>
>
> __
> 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
>
>
__
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][heat] - making Neutron more friendly for orchestration

[Kevin Benton]

We chatted a bit about this on IRC. The issue here is that subnets that
belong to router:external networks are not visible unless the network is
shared as well.
So the only way the users can learn about which subnets to pick are in the
list of subnet UUIDs in the json body of the network 'subnets' field.[1]
They would basically be picking blindly because they don't know any details
about the subnets on the external network.

I think for us to allow a reasonable workflow where they pick an external
subnet instead, we would need to revisit the decision to hide external
subnets from users.


1.
https://github.com/openstack/neutron-lib/blob/ca299b8e47fdd5030dda596fd779beb3e5bea6cf/neutron_lib/api/definitions/network.py#L43

On Fri, May 19, 2017 at 3:27 PM, Armando M. <arma...@gmail.com> wrote:

>
>
> On 19 May 2017 at 14:54, Clark Boylan <cboy...@sapwetik.org> wrote:
>
>> On Fri, May 19, 2017, at 02:03 PM, Kevin Benton wrote:
>> > I split this conversation off of the "Is the pendulum swinging on PaaS
>> > layers?" thread [1] to discuss some improvements we can make to Neutron
>> > to
>> > make orchestration easier.
>> >
>> > There are some pain points that heat has when working with the Neutron
>> > API.
>> > I would like to get them converted into requests for enhancements in
>> > Neutron so the wider community is aware of them.
>> >
>> > Starting with the port/subnet/network relationship - it's important to
>> > understand that IP addresses are not required on a port.
>> >
>> > >So knowing now that a Network is a layer-2 network segment and a Subnet
>> > is... effectively a glorified DHCP address pool
>> >
>> > Yes, a Subnet controls IP address allocation as well as setting up
>> > routing
>> > for routers, which is why routers reference subnets instead of networks
>> > (different routers can route for different subnets on the same network).
>> > It
>> > essentially dictates things related to L3 addressing and provides
>> > information for L3 reachability.
>>
>> One thing that is odd about this is when creating a router you specify
>> the gateway information using a network which is l2 not l3. Seems like
>> it would be more correct to use a subnet rather than a network there?
>>
>
> I think this is due the way external networks ended up being modeled in
> neutron. I suppose we could have allowed the user to specify a subnet, so
> long that it fell in the bucket of subnets that belong to a router:external
> network.
>
>
>>
>> Clark
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> 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
>
>
__
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

[openstack-dev] [neutron] - may 23rd team meeting cancelled

[Kevin Benton]

Hi,

There will be no neutron team meeting today due to a conflict on my end.

If you have any announcements, please direct them to the mailing list. Ask
any questions about bugs or blueprints in the #openstack-neutron channel.

Cheers,
Kevin Benton
__
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] [nova][vlan trunking] Guest networking configuration for vlan trunk

[Kevin Benton]

I think we just need someone to volunteer to do the work to expose it as
metadata to the VM in Nova.

On May 22, 2017 1:27 PM, "Robert Li (baoli)"  wrote:

> Hi Levi,
>
>
>
> Thanks for the info. I noticed that support in the nova code, but was
> wondering why something similar is not available for vlan trunking.
>
>
>
> --Robert
>
>
>
>
>
> On 5/22/17, 3:34 PM, "Moshe Levi"  wrote:
>
>
>
> Hi Robert,
>
> The closes thing that I know about is tagging of SR-IOV physical
> function’s VLAN tag to guests see [1]
>
> Maybe you can leverage the same mechanism to config vlan trunking in guest.
>
>
>
> [1] - https://specs.openstack.org/openstack/nova-specs/specs/
> ocata/implemented/sriov-pf-passthrough-neutron-port-vlan.html
>
>
>
>
>
> *From:* Robert Li (baoli) [mailto:ba...@cisco.com]
> *Sent:* Monday, May 22, 2017 8:49 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [nova][vlan trunking] Guest networking
> configuration for vlan trunk
>
>
>
> Hi,
>
>
>
> I’m trying to find out if there is support in nova (in terms of metadata
> and cfgdrive) to configure vlan trunking in the guest. In the ‘CLI usage
> example’ provided in this wiki https://wiki.openstack.org/
> wiki/Neutron/TrunkPort, it indicates:
>
>
>
> # The typical cloud image will auto-configure the first NIC (eg. eth0)
> only and not the vlan interfaces (eg. eth0.VLAN-ID).
>
> ssh VM0-ADDRESS sudo ip link add link eth0 name eth0.101 type vlan id 101
>
>
>
> I’d like to understand why the support of configuring vlan interfaces in
> the guest is not added. And should it be added?
>
>
>
> Thanks,
>
> Robert
>
> __
> 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
>
>
__
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] [puppet] [tempest] L2GW not standard Tempest Plugin. How to get tests into CI?

[Kevin Benton]

Can you file a patch to adjust tox.ini of l2gw to make it the same as the
others?

On May 22, 2017 7:35 AM, "Ricardo Noriega De Soto" 
wrote:

> Hello guys,
>
> I'm trying to enable some tempest tests into puppet-openstack-integration
> project. I basically did the same procedure as with other Neutron drivers
> but tests were not being executed:
>
> https://review.openstack.org/#/c/460080/
>
> If you check the puppet-tempest patch, I enable the "l2gw" driver in
> tempest.conf under the service_avaiblable section:
>
> https://review.openstack.org/#/c/459712/
>
> However, the way these tests are called slightly different:
>
> https://github.com/openstack/networking-l2gw/tree/master/
> networking_l2gw/tests
>
> https://github.com/openstack/networking-l2gw/blob/master/tox.ini#L50-L53
>
> Is there any recommendation on how to approach this?? I don't think
> setting environment variables in puppet-openstack-integration is
> acceptable. I would love to get some advice around this.
>
> Thank you guys!!
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>
> __
> 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
>
>
__
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][heat] - making Neutron more friendly for orchestration

[Kevin Benton]

So making a subnet ID mandatory for a port creation and a RouterInterface
ID mandatory for a Floating IP creation are both possible in Heat without
Neutron changes. Presumably you haven't done that because it's
backwards-incompatible, but you would need to implement the change anyway
if the Neutron API was changed to require it.

It seems like Heat has a backwards-compatibility requirement for supporting
old templates that aren't explicit. That will be the real blocker to
actually making any of these changes, no? i.e. Neutron isn't preventing
Heat from being more strict, it's the legacy Heat modeling that is
preventing it.

>(a) drop the requirement that the Network has to be connected to the
external network with the FloatingIPs with a RouterInterface prior to
creating the FloatingIP. IIUC only *some* Neutron backends require this.

This can produce difficult to debug situations when multiple routers
attached to different external networks are attached to different subnets
of the same network and the user associates a floating IP to the wrong
fixed IP of the instance. Right now the interface check will prevent that,
but if we remove it the floating IP would just sit in the DOWN state.

If a backend supports floating IPs without router interfaces entirely, it's
likely making assumptions that prevent it from supporting multi-router
scenarios. A single fixed IP on a port can have multiple floating IPs
associated with it from different external networks. So the only way to
distinguish which floating IP to translate to is which router the traffic
is being directed to by the instance, which requires router interfaces.

Cheers

On Fri, May 19, 2017 at 3:29 PM, Zane Bitter <zbit...@redhat.com> wrote:

> On 19/05/17 17:03, Kevin Benton wrote:
>
>> I split this conversation off of the "Is the pendulum swinging on PaaS
>> layers?" thread [1] to discuss some improvements we can make to Neutron
>> to make orchestration easier.
>>
>> There are some pain points that heat has when working with the Neutron
>> API. I would like to get them converted into requests for enhancements
>> in Neutron so the wider community is aware of them.
>>
>> Starting with the port/subnet/network relationship - it's important to
>> understand that IP addresses are not required on a port.
>>
>> So knowing now that a Network is a layer-2 network segment and a Subnet
>>>
>> is... effectively a glorified DHCP address pool
>>
>> Yes, a Subnet controls IP address allocation as well as setting up
>> routing for routers, which is why routers reference subnets instead of
>> networks (different routers can route for different subnets on the same
>> network). It essentially dictates things related to L3 addressing and
>> provides information for L3 reachability.
>>
>> But at the end of the day, I still can't create a Port until a Subnet
>>> exists
>>>
>>
>> This is only true if you want an IP address on the port. This sounds
>> silly for most use cases, but there are a non-trivial portion of NFV
>> workloads that do not want IP addresses at all so they create a network
>> and just attach ports without creating any subnets.
>>
>
> Fair. A more precise statement of the problem would be that given a
> template containing both a Port and a Subnet that it will be attached to,
> there is a specific order in which those need to be created that is _not_
> reflected in the data flow between them.
>
> I still don't know what Subnet a Port will be attached to (unless the
>>>
>> user specifies it explicitly using the --fixed-ip option... regardless
>> of whether they actually specify a fixed IP),
>>
>> So what would you like Neutron to do differently here? Always force a
>> user to pick which subnet they want an allocation from
>>
>
> That would work.
>
> if there are
>> multiple?
>>
>
> Ideally even if there aren't.
>
> If so, can't you just force that explicitness in Heat?
>>
>
> I think the answer here is exactly the same as for Neutron: yes, we
> totally could have if we'd realised that it was a problem at the time.
>
> and I have no way in general of telling which Subnets can be deleted
>>> before a given Port is and which will fail to delete until the Port
>>> disappears.
>>>
>>
>> A given port will only block subnet deletions from subnets it is
>> attached to. Conversely, you can see all ports with allocations from a
>> subnet with 'neutron port-list --fixed-ips subnet_id='.  So
>> is the issue here that the dependency wasn't made explicit in the heat
>> modeling (leading to the problem above and this one)?
>>
>
> Yes, that's exactly the issue. The H

[openstack-dev] [neutron] - Summit "The Future of VPN as a Service (VPNaaS)" summary and next steps

[Kevin Benton]

Hi,

Here are the key points from "The Future of VPN as a Service" session:
https://etherpad.openstack.org/p/boston-vpnaas

We had a good showing of operators that have VPNaaS deployed who are
relatively happy with it and definitely want to see it continue being
developed. We have a list of 9 people who have volunteered to help keep the
repo maintained, which should be plenty to at least keep it from bit
rotting.

The assessment is in process upstream to make it part of the stadium again (
https://review.openstack.org/#/c/452032/) and it looks like we have the
community to back it.

Here are a few pain points using VPNaaS:

- Better error details need to be reported back to user (e.g. which IPsec
phase failed). Currently this requires a support call to the operator.[1]
- VPN code should load in the existing L3 agent using some kind of
extension framework so there doesn't need to be a separate subclass for
VPNaaS with its own binary.[2]
- IPv6 support needs to be covered with tests [3]
- Improved documentation [4]:
- installation (maybe an entry in the networking guide)
- behavior in L3 HA failover scenarios
- several useful documentation links from user's perspective available
in etherpad

1. https://bugs.launchpad.net/neutron/+bug/1692126
2. https://bugs.launchpad.net/neutron/+bug/1692128
3. https://bugs.launchpad.net/neutron/+bug/1692130
4. https://bugs.launchpad.net/neutron/+bug/1692131

Cheers,
Kevin Benton
__
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

[openstack-dev] [neutron] - Summit "Distributed SNAT with DVR" summary and next steps

[Kevin Benton]

Hi,

https://etherpad.openstack.org/p/boston-dvr

The summary from this session is somewhat short. It looks like for this
cycle we don't have the bandwidth to either implement or review the data
model, API, and agent changes required to implement this feature in the
in-tree DVR implementation.

If this is a burning point for you as an operator, consider looking into
Dragonflow, which now has support for distributed SNAT.

Cheers,
Kevin Benton
__
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

[openstack-dev] [neutron] - Summit "Neutron Pain points session" summary and next steps

[Kevin Benton]

Hi,

Here are the key points from the "Neutron Pain Points" session:
https://etherpad.openstack.org/p/neutron-boston-painpoints


FWaaS v1 to v2 - We should try to support running both v1 and v2
concurrently so operators aren't forced to immediately kill all existing v1
users just to start to switch to v2. If not, we need some sort of migration
at minimum if v1 is to be removed at some point.[1]

dsnmasq alternatives for DHCP - There was some interest in using other DHCP
servers. If you are interested, contact the people listed on the volunteer
list to work with them on putting up patches.

Security groups API docs needs improvement - security groups support more
than just ICMP, UDP, TCP but that isn't clear via the docs.[2]

Altering the preset default security group rules - this came up again, but
I don't think any different conclusions were reached other than "make your
on-boarding script do it".  This is because we can't really change them at
this point without a big backwards compatibility problem and if we make
them easily configurable we end up with a cross-cloud compatibility problem.

Let me know if I left out anything important. Also, keep an eye out for the
summary of the closely related session "Making Neutron easy for people who
want basic Networking" from Sukhdev if your topics were covered that
session.

1. https://bugs.launchpad.net/neutron/+bug/1692133
2. https://bugs.launchpad.net/neutron/+bug/1692134

Cheers,
Kevin Benton
__
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][heat] - making Neutron more friendly for orchestration

[Kevin Benton]

We could potentially alter Neutron to inspect each of the fixed IPs to see
if it's eligible to be associated to that floating IP to find the one that
works. Unfortunately that still won't solve multiple eligible fixed IPs. So
is the right thing to do to just always force the user to specify port+IP?

On Fri, May 19, 2017 at 2:13 PM, Monty Taylor <mord...@inaugust.com> wrote:

> On 05/19/2017 04:03 PM, Kevin Benton wrote:
>
>> I split this conversation off of the "Is the pendulum swinging on PaaS
>> layers?" thread [1] to discuss some improvements we can make to Neutron
>> to make orchestration easier.
>>
>> There are some pain points that heat has when working with the Neutron
>> API. I would like to get them converted into requests for enhancements
>> in Neutron so the wider community is aware of them.
>>
>> Starting with the port/subnet/network relationship - it's important to
>> understand that IP addresses are not required on a port.
>>
>> So knowing now that a Network is a layer-2 network segment and a Subnet
>>>
>> is... effectively a glorified DHCP address pool
>>
>> Yes, a Subnet controls IP address allocation as well as setting up
>> routing for routers, which is why routers reference subnets instead of
>> networks (different routers can route for different subnets on the same
>> network). It essentially dictates things related to L3 addressing and
>> provides information for L3 reachability.
>>
>> But at the end of the day, I still can't create a Port until a Subnet
>>> exists
>>>
>>
>> This is only true if you want an IP address on the port. This sounds
>> silly for most use cases, but there are a non-trivial portion of NFV
>> workloads that do not want IP addresses at all so they create a network
>> and just attach ports without creating any subnets.
>>
>> I still don't know what Subnet a Port will be attached to (unless the
>>>
>> user specifies it explicitly using the --fixed-ip option... regardless
>> of whether they actually specify a fixed IP),
>>
>> So what would you like Neutron to do differently here? Always force a
>> user to pick which subnet they want an allocation from if there are
>> multiple? If so, can't you just force that explicitness in Heat?
>>
>> and I have no way in general of telling which Subnets can be deleted
>>> before a given Port is and which will fail to delete until the Port
>>> disappears.
>>>
>>
>> A given port will only block subnet deletions from subnets it is
>> attached to. Conversely, you can see all ports with allocations from a
>> subnet with 'neutron port-list --fixed-ips subnet_id='.  So
>> is the issue here that the dependency wasn't made explicit in the heat
>> modeling (leading to the problem above and this one)?
>>
>>
>> For the individual bugs you highlighted, it would be good if you can
>> provide some details about what changes we could make to help.
>>
>>
>> https://bugs.launchpad.net/heat/+bug/1442121 - This looks like a result
>> of partially specified floating IPs (no fixed_ip). What can we
>> add/change here to help? Or can heat just always force the user to
>> specify a fixed IP for the case where disambiguation on multiple
>> fixed_ip ports is needed?
>>
>
> If the server has more than one fixed_ip ports, it's possible that only
> one of them will be able to receive a floating ip. The subnet a port comes
> from must have gateway_ip set for a floating_ip to attach to it. So if you
> have a server, you can poke and find the right fixed_ip in all cases except
> when the server has more than one fixed_ip and each of them are from a
> subnet with a gateway_ip. In that case, a user _must_ provide a fixed_ip,
> because there is no way to know what they intend.
>
> https://launchpad.net/bugs/1626607 - I see this is about a dependency
>> between RouterGateways and RouterInterfaces, but it's not clear to me
>> why that dependency exists. Is it to solve a lack of visibility into the
>> interfaces required for a floating IP?
>>
>> https://bugs.launchpad.net/heat/+bug/1626619,
>> https://bugs.launchpad.net/heat/+bug/1626630, and
>> https://bugs.launchpad.net/heat/+bug/1626634 - These seems similar to
>> 1626607. Can we just expose the interfaces/router a floating IP is
>> depending on explicitly in the API for you to fix these? If not, what
>> can we do to help here?
>>
>>
>> 1. http://lists.openstack.org/pipermail/openstack-dev/2017-May/
>> 117106.html
>>
>> Cheers,
>> Kevin Benton
>>
>> On F

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

[Kevin Benton]

Started a new Neutron-specific thread so we can get some stuff turned into
improvements in Neutron from this:
http://lists.openstack.org/pipermail/openstack-dev/2017-May/117112.html

On Fri, May 19, 2017 at 1:05 PM, Zane Bitter <zbit...@redhat.com> wrote:

> On 19/05/17 15:06, Kevin Benton wrote:
>
>> Don't even get me started on Neutron.[2]
>>>
>>
>> It seems to me the conclusion to that thread was that the majority of
>> your issues stemmed from the fact that we had poor documentation at the
>> time.  A major component of the complaints resulted from you
>> misunderstanding the difference between networks/subnets in Neutron.
>>
>
> It's true that I was completely off base as to what the various primitives
> in Neutron actually do. (Thanks for educating me!) The implications for
> orchestration are largely unchanged though. It's a giant pain that we have
> to infer implicit dependencies between stuff to get them to create/delete
> in the right order, pretty much independently of what that stuff does.
>
> So knowing now that a Network is a layer-2 network segment and a Subnet
> is... effectively a glorified DHCP address pool, I understand better why it
> probably seemed like a good idea to hook stuff up magically. But at the end
> of the day, I still can't create a Port until a Subnet exists, I still
> don't know what Subnet a Port will be attached to (unless the user
> specifies it explicitly using the --fixed-ip option... regardless of
> whether they actually specify a fixed IP), and I have no way in general of
> telling which Subnets can be deleted before a given Port is and which will
> fail to delete until the Port disappears.
>
> There are some legitimate issues in there about the extra routes
>> extension being replace-only and the routers API not accepting a list of
>> interfaces in POST.  However, it hardly seems that those are worthy of
>> "Don't even get me started on Neutron."
>>
>
> https://launchpad.net/bugs/1626607
> https://launchpad.net/bugs/1442121
> https://launchpad.net/bugs/1626619
> https://launchpad.net/bugs/1626630
> https://launchpad.net/bugs/1626634
>
> It would be nice if you could write up something about current gaps that
>> would make Heat's life easier, because a large chunk of that initial
>> email is incorrect and linking to it as a big list of "issues" is
>> counter-productive.
>>
>
> Yes, agreed. I wish I had a clean thread to link to. It's a huge amount of
> work to research it all though.
>
> cheers,
> Zane.
>
> On Fri, May 19, 2017 at 7:36 AM, Zane Bitter <zbit...@redhat.com
>> <mailto:zbit...@redhat.com>> wrote:
>>
>> On 18/05/17 20:19, Matt Riedemann wrote:
>>
>> I just wanted to blurt this out since it hit me a few times at the
>> summit, and see if I'm misreading the rooms.
>>
>> For the last few years, Nova has pushed back on adding
>> orchestration to
>> the compute API, and even define a policy for it since it comes
>> up so
>> much [1]. The stance is that the compute API should expose
>> capabilities
>> that a higher-level orchestration service can stitch together
>> for a more
>> fluid end user experience.
>>
>>
>> I think this is a wise policy.
>>
>> One simple example that comes up time and again is allowing a
>> user to
>> pass volume type to the compute API when booting from volume
>> such that
>> when nova creates the backing volume in Cinder, it passes
>> through the
>> volume type. If you need a non-default volume type for boot from
>> volume,
>> the way you do this today is first create the volume with said
>> type in
>> Cinder and then provide that volume to the compute API when
>> creating the
>> server. However, people claim that is bad UX or hard for users to
>> understand, something like that (at least from a command line, I
>> assume
>> Horizon hides this, and basic users should probably be using
>> Horizon
>> anyway right?).
>>
>>
>> As always, there's a trade-off between simplicity and flexibility. I
>> can certainly understand the logic in wanting to make the simple
>> stuff simple. But users also need to be able to progress from simple
>> stuff to more complex stuff without having to give up and start
>> over. There's a danger of leading them down the garden path.
>>
>>

[openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

[Kevin Benton]

I split this conversation off of the "Is the pendulum swinging on PaaS
layers?" thread [1] to discuss some improvements we can make to Neutron to
make orchestration easier.

There are some pain points that heat has when working with the Neutron API.
I would like to get them converted into requests for enhancements in
Neutron so the wider community is aware of them.

Starting with the port/subnet/network relationship - it's important to
understand that IP addresses are not required on a port.

>So knowing now that a Network is a layer-2 network segment and a Subnet
is... effectively a glorified DHCP address pool

Yes, a Subnet controls IP address allocation as well as setting up routing
for routers, which is why routers reference subnets instead of networks
(different routers can route for different subnets on the same network). It
essentially dictates things related to L3 addressing and provides
information for L3 reachability.

>But at the end of the day, I still can't create a Port until a Subnet
exists

This is only true if you want an IP address on the port. This sounds silly
for most use cases, but there are a non-trivial portion of NFV workloads
that do not want IP addresses at all so they create a network and just
attach ports without creating any subnets.

>I still don't know what Subnet a Port will be attached to (unless the user
specifies it explicitly using the --fixed-ip option... regardless of
whether they actually specify a fixed IP),

So what would you like Neutron to do differently here? Always force a user
to pick which subnet they want an allocation from if there are multiple? If
so, can't you just force that explicitness in Heat?

> and I have no way in general of telling which Subnets can be deleted
before a given Port is and which will fail to delete until the Port
disappears.

A given port will only block subnet deletions from subnets it is attached
to. Conversely, you can see all ports with allocations from a subnet with
'neutron port-list --fixed-ips subnet_id='.  So is the issue
here that the dependency wasn't made explicit in the heat modeling (leading
to the problem above and this one)?


For the individual bugs you highlighted, it would be good if you can
provide some details about what changes we could make to help.


https://bugs.launchpad.net/heat/+bug/1442121 - This looks like a result of
partially specified floating IPs (no fixed_ip). What can we add/change here
to help? Or can heat just always force the user to specify a fixed IP for
the case where disambiguation on multiple fixed_ip ports is needed?

https://launchpad.net/bugs/1626607 - I see this is about a dependency
between RouterGateways and RouterInterfaces, but it's not clear to me why
that dependency exists. Is it to solve a lack of visibility into the
interfaces required for a floating IP?

https://bugs.launchpad.net/heat/+bug/1626619,
https://bugs.launchpad.net/heat/+bug/1626630, and
https://bugs.launchpad.net/heat/+bug/1626634 - These seems similar to
1626607. Can we just expose the interfaces/router a floating IP is
depending on explicitly in the API for you to fix these? If not, what can
we do to help here?


1. http://lists.openstack.org/pipermail/openstack-dev/2017-May/117106.html

Cheers,
Kevin Benton

On Fri, May 19, 2017 at 1:05 PM, Zane Bitter <zbit...@redhat.com> wrote:

> On 19/05/17 15:06, Kevin Benton wrote:
>
>> Don't even get me started on Neutron.[2]
>>>
>>
>> It seems to me the conclusion to that thread was that the majority of
>> your issues stemmed from the fact that we had poor documentation at the
>> time.  A major component of the complaints resulted from you
>> misunderstanding the difference between networks/subnets in Neutron.
>>
>
> It's true that I was completely off base as to what the various primitives
> in Neutron actually do. (Thanks for educating me!) The implications for
> orchestration are largely unchanged though. It's a giant pain that we have
> to infer implicit dependencies between stuff to get them to create/delete
> in the right order, pretty much independently of what that stuff does.
>
> So knowing now that a Network is a layer-2 network segment and a Subnet
> is... effectively a glorified DHCP address pool, I understand better why it
> probably seemed like a good idea to hook stuff up magically. But at the end
> of the day, I still can't create a Port until a Subnet exists, I still
> don't know what Subnet a Port will be attached to (unless the user
> specifies it explicitly using the --fixed-ip option... regardless of
> whether they actually specify a fixed IP), and I have no way in general of
> telling which Subnets can be deleted before a given Port is and which will
> fail to delete until the Port disappears.
>
> There are some legitimate issues in there about the extra routes
>> extension being replace-only and the route

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

[Kevin Benton]

>Don't even get me started on Neutron.[2]

It seems to me the conclusion to that thread was that the majority of your
issues stemmed from the fact that we had poor documentation at the time.  A
major component of the complaints resulted from you misunderstanding the
difference between networks/subnets in Neutron.

There are some legitimate issues in there about the extra routes extension
being replace-only and the routers API not accepting a list of interfaces
in POST.  However, it hardly seems that those are worthy of "Don't even get
me started on Neutron."

It would be nice if you could write up something about current gaps that
would make Heat's life easier, because a large chunk of that initial email
is incorrect and linking to it as a big list of "issues" is
counter-productive.


On Fri, May 19, 2017 at 7:36 AM, Zane Bitter  wrote:

> On 18/05/17 20:19, Matt Riedemann wrote:
>
>> I just wanted to blurt this out since it hit me a few times at the
>> summit, and see if I'm misreading the rooms.
>>
>> For the last few years, Nova has pushed back on adding orchestration to
>> the compute API, and even define a policy for it since it comes up so
>> much [1]. The stance is that the compute API should expose capabilities
>> that a higher-level orchestration service can stitch together for a more
>> fluid end user experience.
>>
>
> I think this is a wise policy.
>
> One simple example that comes up time and again is allowing a user to
>> pass volume type to the compute API when booting from volume such that
>> when nova creates the backing volume in Cinder, it passes through the
>> volume type. If you need a non-default volume type for boot from volume,
>> the way you do this today is first create the volume with said type in
>> Cinder and then provide that volume to the compute API when creating the
>> server. However, people claim that is bad UX or hard for users to
>> understand, something like that (at least from a command line, I assume
>> Horizon hides this, and basic users should probably be using Horizon
>> anyway right?).
>>
>
> As always, there's a trade-off between simplicity and flexibility. I can
> certainly understand the logic in wanting to make the simple stuff simple.
> But users also need to be able to progress from simple stuff to more
> complex stuff without having to give up and start over. There's a danger of
> leading them down the garden path.
>
> While talking about claims in the scheduler and a top-level conductor
>> for cells v2 deployments, we've talked about the desire to eliminate
>> "up-calls" from the compute service to the top-level controller services
>> (nova-api, nova-conductor and nova-scheduler). Build retries is one such
>> up-call. CERN disables build retries, but others rely on them, because
>> of how racy claims in the computes are (that's another story and why
>> we're working on fixing it). While talking about this, we asked, "why
>> not just do away with build retries in nova altogether? If the scheduler
>> picks a host and the build fails, it fails, and you have to
>> retry/rebuild/delete/recreate from a top-level service."
>>
>
> (FWIW Heat does this for you already.)
>
> But during several different Forum sessions, like user API improvements
>> [2] but also the cells v2 and claims in the scheduler sessions, I was
>> hearing about how operators only wanted to expose the base IaaS services
>> and APIs and end API users wanted to only use those, which means any
>> improvements in those APIs would have to be in the base APIs (nova,
>> cinder, etc). To me, that generally means any orchestration would have
>> to be baked into the compute API if you're not using Heat or something
>> similar.
>>
>
> The problem is that orchestration done inside APIs is very easy to do
> badly in ways that cause lots of downstream pain for users and external
> orchestrators. For example, Nova already does some orchestration: it
> creates a Neutron port for a server if you don't specify one. (And then
> promptly forgets that it has done so.) There is literally an entire inner
> platform, an orchestrator within an orchestrator, inside Heat to try to
> manage the fallout from this. And the inner platform shares none of the
> elegance, such as it is, of Heat itself, but is rather a collection of
> cobbled-together hacks to deal with the seemingly infinite explosion of
> edge cases that we kept running into over a period of at least 5 releases.
>
> The get-me-a-network thing is... better, but there's no provision for
> changes after the server is created, which means we have to copy-paste the
> Nova implementation into Heat to deal with update.[1] Which sounds like a
> maintenance nightmare in the making. That seems to be a common mistake: to
> assume that once users create something they'll never need to touch it
> again, except to delete it when they're done.
>
> Don't even get me started on Neutron.[2]
>
> Any orchestration that is done behind-the-scenes needs to be 

[openstack-dev] [neutron] - neutron social

[Kevin Benton]

See message below from Miguel for details on the neutron social.


Dear Neutrinos,

We have a plan for tomorrow night, Wednesday 10th at 7pm. We are going to
meet at UNO Pizzeria and Grill, 731 Boylston Street Boston, MA 02116, phone
number (617) 267-8554. This location is a very easy walk of less than 5
minutes from the convention center

We are going to have an "all you can eat" menu with the following options:

House Salad
Deep Dish Pizza (cheese, pepperoni, veggie)
Pasta (penne marinara, chicken broccoli alfredo)
Fountain Soda drinks and Ice tea are included are at $16.50 per person.

They will present present each person with an individual check for this
package and charge separately for any other requests

Looking forward to see you all tomorrow night!

Regards

Miguel
__
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] - are you attending the Boston summit?

[Kevin Benton]

Let's plan for a social Wednesday night. I'll update this with a location
once we find a place.

On May 8, 2017 08:50, "MCCASLAND, TREVOR" <tm2...@att.com> wrote:

> Looking forward to it! RSVP? +1
>
>
>
> *From:* Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
> *Sent:* Saturday, May 06, 2017 12:31 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [neutron] - are you attending the Boston
> summit?
>
>
>
> Hey Neutron Folks,
>
>
>
> Following our past tradition, we should have Neutron dinner while we are
> all in Boston.
>
> Miguel has few places in mind. I would propose that we nominate him as the
> dinner organizer lieutenant.
>
>
>
> Miguel, I hope you will take us to some cool place.
>
>
>
> Thanks
>
> -Sukhdev
>
>
>
>
>
> On Thu, Apr 20, 2017 at 4:31 PM, Kevin Benton <ke...@benton.pub> wrote:
>
> Hi,
>
>
>
> If you are a Neutron developer attending the Boston summit, please add
> your name to the etherpad here so we can plan a Neutron social and easily
> coordinate in person meetings: https://etherpad.openstack.org/p/neutron-
> boston-summit-attendees
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_neutron-2Dboston-2Dsummit-2Dattendees=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=5B3JeBxxBxSVSDyEE4CrscFosRJrbSlh0iHA6KKtPp0=aiu832G95vnwmAese4JWyLFwm99d1p4m8LE0iNWjDtc=>
>
>
>
> Cheers,
>
> Kevin Benton
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=5B3JeBxxBxSVSDyEE4CrscFosRJrbSlh0iHA6KKtPp0=GvGDJtQQuOUlcPAlm42SYXhLvjxuyBONmUgyN3kMKZk=>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=5B3JeBxxBxSVSDyEE4CrscFosRJrbSlh0iHA6KKtPp0=7ej2hONs5HQNYT6DFBNgXciUgX3MhlugE9_6YALd7i0=>
>
>
>
> __
> 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
>
>
__
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] stepping down from core

[Kevin Benton]

Thanks for all of your contributions. Good luck in your new role!

Cheers

On Thu, May 4, 2017 at 9:52 AM, Rossella Sblendido 
wrote:

> Hi all,
>
> I've moved to a new position recently and despite my best intentions I
> was not able to devote to Neutron as much time and energy as I wanted.
> It's time for me to move on and to leave room for new core reviewers.
>
> It's been a great experience working with you all, I learned a lot both
> on the technical and on the human side.
> I won't disappear, you will see me around in IRC, etc, don't hesitate to
> contact me if you have any question or would like my feedback on something.
>
> ciao,
>
> Rossella
>
__
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

[openstack-dev] [neutron] - no drivers meeting today or next week (May 4th and May 11th)

[Kevin Benton]

Hi all,

I'm canceling the drivers meeting May 4th and 11th to avoid discussion of
new features until after the summit when we have collected user/operator
feedback.

Cheers,
Kevin Benton
__
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] stepping down from neutron core team

[Kevin Benton]

Thanks for all of your work. Come back soon. ;)

On Apr 28, 2017 05:02, "Miguel Angel Ajo Pelayo" 
wrote:

>
> Hi everybody,
>
> Some of you already know, but I wanted to make it official.
>
> Recently I moved to work on the networking-ovn component,
> and OVS/OVN itself, and while I'll stick around and I will be available
> on IRC for any questions I'm already not doing a good work with
> neutron reviews, so...
>
> It's time to leave room for new reviewers.
>
> It's always a pleasure to work with you folks.
>
> Best regards,
> Miguel Ángel Ajo.
>
__
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] keeping on top of neutron reviews

[Kevin Benton]

Thanks! Do you have the link to where that script lives? It would be good
to have it in the neutron devref.

On Thu, Apr 20, 2017 at 9:23 AM, Rossella Sblendido <rsblend...@suse.com>
wrote:

> Hi all,
>
> I'd like to remind that there's a dashboard that it's populated every
> day showing patches that are fixes for high/critical bugs, approved
> blueprints and RFE. You can find it here [1] under "Gerrit Dashboard links"
>
> cheers,
>
> Rossella
>
> [1] http://status.openstack.org/reviews/
>
> On 04/18/2017 12:45 AM, Kevin Benton wrote:
> > Hello Neutron reviewers,
> >
> > Please keep an eye on the review links
> > in https://docs.openstack.org/developer/neutron/dashboards/index.html as
> > part of your review routine.
> >
> > I went through and reviewed a lot of old patches over the weekend so if
> > we keep on top of that list it shouldn't get out of hand.
> >
> > Cheers,
> > Kevin Benton
> >
> >
> > 
> __
> > 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
> >
>
> __
> 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
>
__
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

[openstack-dev] [neutron] - are you attending the Boston summit?

[Kevin Benton]

Hi,

If you are a Neutron developer attending the Boston summit, please add your
name to the etherpad here so we can plan a Neutron social and easily
coordinate in person meetings:
https://etherpad.openstack.org/p/neutron-boston-summit-attendees

Cheers,
Kevin Benton
__
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] Emails for OpenStack R Release Name voting going out - please be patient

[Kevin Benton]

FWIW mine just came through yesterday.

On Wed, Apr 19, 2017 at 12:13 PM, Jay S Bryant  wrote:

> All,
>
> For those of you haven't received an e-mail, check the inbox you use for
> Gerrit.  You can verify what that is by going to review.openstack.org ,
> click your name, go to settings, the e-mail address is set there.
>
> The naming vote and the TC vote e-mails got lost in that inbox for me.
>
> Hopes this helps.
>
> Jay
>
>
>
>
> On 4/12/2017 7:09 AM, Dulko, Michal wrote:
>
>> On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
>>
>>> On 04/06/2017 07:34 AM, Monty Taylor wrote:
>>>
 Hey all!

 I've started the R Release Name poll and currently am submitting
 everyone's email address to the system. In order to not make our fine
 friends at Carnegie Mellon (the folks who run the CIVS voting service)
 upset, I have a script that submits the emails one at a time with a
 half-second delay between each email. That means at best, since there
 are 40k people to process it'll take ~6 hours for them all to go out.

 Which is to say - emails are on their way - but if you haven't gotten
 yours yet, that's fine. I'll send another email when they've all gone
 out, so don't worry about not receiving one until I've sent that mail.

>>> Well- that took longer than I expected. Because of some rate limiting,
>>> 1/2 second delay was not long enough...
>>>
>>> Anyway - all of the emails should have gone out now. Because that took
>>> so long, I'm going to hold the poll open until next Wednesday.
>>>
>>> Monty
>>>
>> Not sure why, but I haven't received an email yet.
>>
>> Thanks,
>> Michal
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> 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
>
__
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] Development workflow for bunch of patches

[Kevin Benton]

Whenever you want to work on the second patch you would need to first
checkout the latest version of the first patch and then cherry-pick the
later patch on top of it. That way when you update the second one it won't
affect the first patch.

The -R flag can also be used to prevent unexpected rebases of the parent
patch. More details here:

https://docs.openstack.org/infra/manual/developers.html#adding-a-dependency

On Wed, Apr 19, 2017 at 1:11 AM, Sławek Kapłoński 
wrote:

> Hello,
>
> I have a question about how to deal with bunch of patches which depends
> one on another.
> I did patch to neutron (https://review.openstack.org/#/c/449831/) which
> is not merged yet but I wanted to start also another patch which is depend
> on this one (https://review.openstack.org/#/c/457816/).
> Currently I was trying to do something like:
> 1. git review -d 
> 2. git checkout -b new_branch_for_second_patch
> 3. Make second patch, commit all changes
> 4. git review <— this will ask me if I really want to push two patches to
> gerrit so I answered „yes”
>
> Everything is easy for me as long as I’m not doing more changes in first
> patch. How I should work with it if I let’s say want to change something in
> first patch and later I want to make another change to second patch? IIRC
> when I tried to do something like that and I made „git review” to push
> changes in second patch, first one was also updated (and I lost changes
> made for this one in another branch).
> How I should work with something like that? Is there any guide about that
> (I couldn’t find such)?
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> __
> 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
>
>
__
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

[openstack-dev] [neutron] keeping on top of neutron reviews

[Kevin Benton]

Hello Neutron reviewers,

Please keep an eye on the review links in
https://docs.openstack.org/developer/neutron/dashboards/index.html as part
of your review routine.

I went through and reviewed a lot of old patches over the weekend so if we
keep on top of that list it shouldn't get out of hand.

Cheers,
Kevin Benton
__
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] Emails for OpenStack R Release Name voting going out - please be patient

[Kevin Benton]

I haven't received one either.

Perhaps Monty has simply embraced the 'cattle not pets' approach and we
were the unlucky ones. :)

On Apr 12, 2017 07:49, "Lance Bragstad"  wrote:

>
> On Wed, Apr 12, 2017 at 9:42 AM, Amrith Kumar 
> wrote:
>
>> Hmm, all the cool kids didn’t receive the email but I did. Now I feel bad
>> ☹
>>
>>
>>
>> -amrith
>>
>>
>>
>> *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
>> *Sent:* Wednesday, April 12, 2017 9:53 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] Emails for OpenStack R Release Name
>> voting going out - please be patient
>>
>>
>>
>> I also have not received a poll email.
>>
>
> Same here - I haven't received one.
>
>
>>
>>
>> On Apr 12, 2017 6:13 AM, "Neil Jerram"  wrote:
>>
>> Nor me.
>>
>>
>>
>> On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann 
>> wrote:
>>
>> Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
>> > On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
>> > > On 04/06/2017 07:34 AM, Monty Taylor wrote:
>> > > >
>> > > > Hey all!
>> > > >
>> > > > I've started the R Release Name poll and currently am submitting
>> > > > everyone's email address to the system. In order to not make our
>> fine
>> > > > friends at Carnegie Mellon (the folks who run the CIVS voting
>> service)
>> > > > upset, I have a script that submits the emails one at a time with a
>> > > > half-second delay between each email. That means at best, since
>> there
>> > > > are 40k people to process it'll take ~6 hours for them all to go
>> out.
>> > > >
>> > > > Which is to say - emails are on their way - but if you haven't
>> gotten
>> > > > yours yet, that's fine. I'll send another email when they've all
>> gone
>> > > > out, so don't worry about not receiving one until I've sent that
>> mail.
>> > > Well- that took longer than I expected. Because of some rate
>> limiting,
>> > > 1/2 second delay was not long enough...
>> > >
>> > > Anyway - all of the emails should have gone out now. Because that
>> took
>> > > so long, I'm going to hold the poll open until next Wednesday.
>> > >
>> > > Monty
>> >
>> > Not sure why, but I haven't received an email yet.
>> >
>> > Thanks,
>> > Michal
>>
>> Nor I.
>>
>> Doug
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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
>
>
__
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] [Openstack] How to get all detail RPC message and detail context in neutron docs?

[Kevin Benton]

I would strongly recommend that you don't build anything based on these
messages. The contents change from release to release since this is an
internal API between the agents and the server.

On Apr 6, 2017 00:48, "Sam"  wrote:

> Thank you, use debug option will also help us to get detail of RPC
> message, good luck~
>
> 2017-04-06 14:20 GMT+08:00 김기석 [Kiseok Kim] :
>
>> Sam,
>>
>>
>>
>> I have no idea whether or not the document exists. (I want to read too)
>>
>>
>>
>> about L3 RPC messages(L3_AGENT topic), its client-side is implemented in
>> l3_router_plugin.[1]
>>
>> There is an oslo_meessaging document.[2] I guess it would help.
>>
>>
>>
>> [1] https://github.com/openstack/neutron/blob/master/neutron/api
>> /rpc/agentnotifiers/l3_rpc_agent_api.py#L37
>>
>> [2] https://docs.openstack.org/developer/oslo.messaging/
>>
>>
>>
>> good luck!
>>
>>
>>
>> *From:* Sam [mailto:batmanu...@gmail.com]
>> *Sent:* Thursday, April 06, 2017 10:56 AM
>> *To:* 김기석 [Kiseok Kim]
>> *Cc:* OpenStack General; OpenStack Development Mailing List (not for
>> usage questions)
>> *Subject:* Re: [Openstack] How to get all detail RPC message and detail
>> context in neutron docs?
>>
>>
>>
>> For example, detail of the messages of topics.L3_AGENT
>>
>>
>>
>> 2017-04-06 9:38 GMT+08:00 Sam :
>>
>> Thank you all.
>>
>>
>>
>> For 'context', I got it.
>>
>> For RPCs, is there some document or blog or some debug method to get its
>> detal contains in neutron L3 Agent?
>>
>>
>>
>> 2017-04-06 9:33 GMT+08:00 김기석 [Kiseok Kim] :
>>
>> Hi Sam,
>>
>>
>>
>> that 'context' is olso_context and neutron use it with addition
>> attributes.
>>
>>
>>
>> oslo.context has to_dict method,
>>
>> so you could add debug log in 'agent_updated' method like:
>>
>>
>>
>>LOG.debug("context in agent_updated: %s", context.to_dict())
>>
>>
>>
>> and you can find out the attributes of context in
>>
>> https://github.com/openstack/neutron-lib/blob/master/neutron
>> _lib/context.py#L83-L92,
>>
>> https://github.com/openstack/oslo.context/blob/master/oslo_c
>> ontext/context.py#L310-L332
>>
>> .
>>
>>
>>
>> *From:* Sam [mailto:batmanu...@gmail.com]
>> *Sent:* Wednesday, April 05, 2017 7:10 PM
>> *To:* OpenStack General; OpenStack Development Mailing List (not for
>> usage questions)
>> *Subject:* [Openstack] How to get all detail RPC message and detail
>> context in neutron docs?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I'm working on neutron L3 Agent and some other Agent. I found that there
>> are lots of RPCs including RPC call and notification and lots of 'context'
>> as bellow. But I don't know its detail context, can I get these from some
>> docs?
>>
>>
>>
>> If there are no docs, could I get these using some debug method? Like
>> '--debug' option or using pdb or something?
>>
>>
>>
>> RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.
>>
>>
>>
>> context: it's param in some function like 'def
>> router_added_to_agent(self, context, payload):' in
>> neutron/neutron/agent/l3/agent.py.
>>
>>
>>
>>
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
__
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][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Kevin Benton]

I think 'a' is probably the way to go since we can mainly rely on existing
horizon guides for creating new dashboard repos.

On Apr 10, 2017 08:11, "Akihiro Motoki"  wrote:

> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since
> then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium
> inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a
> repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months
> ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro
>
> __
> 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
>
__
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] Engine facade

[Kevin Benton]

I worked with Gary on IRC and discovered that we aren't making use of the
flag added in [1], which makes adoption harder. I've proposed a patch to
neutron-lib[2] that should alleviate some of these issues.

1. https://bugs.launchpad.net/oslo.db/+bug/1664643
2. https://review.openstack.org/#/c/453063/

On Tue, Apr 4, 2017 at 3:11 AM, Anna Taraday <akamyshnik...@mirantis.com>
wrote:

> Hi!
>
> This errors does not mean that foreign key usage is broken. This means
> that there is a mess with transactions. As you paste small piece of trace
> it is hard to say why this happen, but during my work I saw such errors and
> resolve them. And probably you need to revisit your unit tests.
>
> Please, send me email directly with links for traces, does this happen on
> master branch, does it happen on one of your changes - it is hard to guess.
>
>
>
> On Tue, Apr 4, 2017 at 11:16 AM Gary Kotton <gkot...@vmware.com> wrote:
>
> Hi,
>
> The problem that we have is that any foreign key usage under transactions
> is now broken. An example of an exception that is raised is:
>
>
>
> DBReferenceError: (sqlite3.IntegrityError) FOREIGN KEY constraint
> failed [SQL: u'INSERT INTO neutron_nsx_firewall_section_mappings
> (created_at, updated_at, neutron_id, nsx_id) VALUES (?, ?, ?, ?)']
> [parameters: ('2017-04-04 06:48:25.595118', None, 
> '6a086bf1-b1c9-495f-bfca-810d6638e3fa',
> '2563cd05-edd9-4c7f-9708-857a129e2642')]
>
>
>
> This is a major refactor in the plugin (which I guess is part and parcel
> of rolling with the punches). I am just concerned if we are the only folks
> that have affected by this.
>
> Thanks
>
> Gary
>
>
>
> *From: *Gary Kotton <gkot...@vmware.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Monday, April 3, 2017 at 3:14 PM
>
>
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Hi,
>
> We needed to make all of those changes to just get the plugin to pass unit
> tests and CI. We are still seeing lots of issues and need to look deeper.
> The façade changes have caused a lot of instability issues. I am not 100%
> sure why. Issues that we have seen:
>
> 1. object creation under a transaction broke
>
> 2. deleting DB entries under transaction also broke
>
> Thanks
>
> Gary
>
>
>
>
>
> *From: *Anna Taraday <akamyshnik...@mirantis.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Monday, April 3, 2017 at 11:53 AM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Hi!
>
> I'm a little confused change https://review.openstack.org/#/c/452539/ is
> about switching for new facade, does the master branch fails the same?
>
>
>
> On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton <gkot...@vmware.com> wrote:
>
> Yes, sorry my bad for not adding it - http://logs.openstack.org/39/
> 452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/
> 14c019c/testr_results.html.gz
>
> Please see the test *test_create_port_dns_name*
>
> Thanks
>
> Gary
>
>
>
> *From: *Kevin Benton <ke...@benton.pub>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Monday, April 3, 2017 at 12:56 AM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Do you have a link to a traceback?
>
>
>
> On Apr 2, 2017 09:25, "Gary Kotton" <gkot...@vmware.com> wrote:
>
> Hi,
>
> The change https://review.openstack.org/#/c/402750/ has broken the
> vmware-nsx plugin. I am not sure if this has had effect on any other
> decomposed plugins.
>
> One of the issues that we have is when we create a PortDNS object under a
> transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError)
> FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id,
> current_dns_name, current_dns_domain, previous_dns_name,
> previous_dns_domain, dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters:
> ('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'',
> u'port-dns-name')]
>
> Any ideas?
>
> Thanks
>
> Gary
>
>
> __
> 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
>
> __
> Op

Re: [openstack-dev] [neutron][ml2] - heads up for mechanism drivers that don't use in tree DHCP agent

[Kevin Benton]

Yes. The code will still require something to acknowledge that DHCP has
been wired for a port whether or not the agent extension is present.

On Fri, Mar 31, 2017 at 3:39 AM, Neil Jerram <n...@tigera.io> wrote:

> Thanks for the heads up, Kevin!
>
> Is this still necessary if a deployment disables the Neutron server's DHCP
> scheduling, with
>
> self._supported_extension_aliases.remove("dhcp_agent_
> scheduler")
>
> ?
>
> Thanks,
>   Neil
>
>
> On Fri, Mar 31, 2017 at 12:52 AM Kevin Benton <ke...@benton.pub> wrote:
>
>> Hi,
>>
>> Once [1] merges, a port will not transition to ACTIVE on a subnet with
>> enable_dhcp=True unless something clears the DHCP provisioning block.
>>
>> If your mechanism driver uses the in-tree DHCP agent, there is nothing
>> you need to do. However, if you do not utilize the DHCP agent in your
>> deployment scenarios and you offload DHCP to something else, your mechanism
>> driver must now explicitly acknowledge that DHCP has been provisioned for
>> that port.
>>
>> Acknowledging that DHCP is ready for a port is a one-line call to the
>> provisioning_blocks module[2]. For more information on provisioning blocks,
>> see [3].
>>
>> 1. https://review.openstack.org/452009
>> 2. https://github.com/openstack/neutron/blob/
>> 4ed53a880714fd33280064c58e6f91b9ecd3823e/neutron/api/rpc/
>> handlers/dhcp_rpc.py#L292-L294
>> 3. https://docs.openstack.org/developer/neutron/devref/
>> provisioning_blocks.html
>>
>> Cheers,
>> Kevin Benton
>>
>> 
>> __
>> 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
>>
>
> __
> 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
>
>
__
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

[openstack-dev] [neutron] - meeting reminder for today

[Kevin Benton]

Hello all,

This is just a quick reminder that the team meeting will be at the old time
today of 2100 UTC in openstack-meeting due to the revert if the alteration.

Cheers
__
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] Engine facade

[Kevin Benton]

Do you have a link to a traceback?

On Apr 2, 2017 09:25, "Gary Kotton"  wrote:

> Hi,
>
> The change https://review.openstack.org/#/c/402750/ has broken the
> vmware-nsx plugin. I am not sure if this has had effect on any other
> decomposed plugins.
>
> One of the issues that we have is when we create a PortDNS object under a
> transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError)
> FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id,
> current_dns_name, current_dns_domain, previous_dns_name,
> previous_dns_domain, dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters:
> ('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'',
> u'port-dns-name')]
>
> Any ideas?
>
> Thanks
>
> Gary
>
> __
> 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
>
>
__
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]: floating IP not being set for L2 GRE packets

[Kevin Benton]

I would file a bug against devstack to get some feedback on the best place
to automatically load that module.

On Thu, Mar 30, 2017 at 11:47 AM, Anil Rao <anil@gigamon.com> wrote:

> I manually loaded the specified kernel module (nf_conntrack_proto_gre) in
> the network node and now the translation between the VM’ local IP and its
> assigned floating IP is working as expected for L2 GRE traffic.
>
>
>
> Thanks a million, Kevin. J
>
>
>
> Is there something I need to do to automate this step for DevStack
> installations?
>
>
>
> Regards,
>
> Anil
>
>
>
> *From:* Anil Rao [mailto:anil@gigamon.com]
> *Sent:* Thursday, March 30, 2017 11:36 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron]: floating IP not being set for
> L2 GRE packets
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> <http://aka.ms/LearnAboutSpoofing>
>
> Feedback <http://aka.ms/SafetyTipsFeedback>
>
> Hi,
>
>
>
> Thanks for the reply. I checked the network node and the
> nf_conntrack_proto_gre kernel module is not loaded. Among the loaded kernel
> modules the only ones bearing the ‘nf_conntrack’ prefix are the following:
>
>
>
> -  nf_conntrack
>
> -  nf_conntrack_ipv4
>
> -  nf_conntrfack_ipv6
>
> -  nf_conntrack_netlink
>
>
>
> -Anil
>
>
>
> *From:* Kevin Benton [mailto:ke...@benton.pub <ke...@benton.pub>]
> *Sent:* Thursday, March 30, 2017 12:41 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron]: floating IP not being set for
> L2 GRE packets
>
>
>
> Do you have the nf_conntrack_proto_gre kernel module loaded on the network
> node?
>
>
>
> On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao <anil@gigamon.com> wrote:
>
> Strangely enough, there is no problem when I make use of a VxLAN tunnel to
> communicate between the VM (inside the cloud) and an external machine. In
> this case, the network node is performing the correct translation between
> the VM’s local IP and the floating IP currently assigned to it.
>
> So far I have only seen this problem when using L2 GRE tunnels.
>
> Thanks,
>
> Anil
>
>
>
> *From:* Anil Rao [mailto:anil@gigamon.com]
> *Sent:* Wednesday, March 29, 2017 3:17 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [neutron]: floating IP not being set for L2
> GRE packets
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> <http://aka.ms/LearnAboutSpoofing>
>
> Feedback <http://aka.ms/SafetyTipsFeedback>
>
> Hi,
>
> I am seeing a strange behavior when it comes to floating IPs and L2 GRE
> tunnels that I was hoping someone could shed light on.
>
> Inside a tenant (project) I have a VM that wants to communicate with a
> machine residing outside the cloud. For this purpose, a floating IP has
> been assigned to the VM’s interface.
>
> *Case 1: VM communicates with external machine using ‘ping’.*
>
> This is successful.
>
> At the network node (from where the packets leave the OpenStack cloud),
> the VM’s local IP address is replaced with its floating IP for outgoing
> packets. Similarly, for incoming packets, the floating IP is replaced with
> the VM’s local IP address.
>
> *Case 2: VM communicates with the external machine using an L2 GRE tunnel.*
>
> This is not successful.
>
> At the network node, the outgoing packets [still] have the VM’ local IP
> address. It is not surprising that no packets come back for the VM from the
> external machine.
>
> My question is:  why didn’t the network node replace the VM’s IP address
> with its floating IP for the L2 GRE case although it did this for the
> simple ping case?
>
> I see this behavior on a multi-node DevStack based on stable/ocata as well
> as a multi-node production Newton cloud.
>
> Thanks and regards,
>
> Anil
>
>
>
>
> __
> 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
>
>
>
> __
> 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
>
>
__
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

[openstack-dev] [neutron][ml2] - heads up for mechanism drivers that don't use in tree DHCP agent

[Kevin Benton]

Hi,

Once [1] merges, a port will not transition to ACTIVE on a subnet with
enable_dhcp=True unless something clears the DHCP provisioning block.

If your mechanism driver uses the in-tree DHCP agent, there is nothing you
need to do. However, if you do not utilize the DHCP agent in your
deployment scenarios and you offload DHCP to something else, your mechanism
driver must now explicitly acknowledge that DHCP has been provisioned for
that port.

Acknowledging that DHCP is ready for a port is a one-line call to the
provisioning_blocks module[2]. For more information on provisioning blocks,
see [3].

1. https://review.openstack.org/452009
2. https://github.com/openstack/neutron/blob/4ed53a880714fd33280064c58e6f91
b9ecd3823e/neutron/api/rpc/handlers/dhcp_rpc.py#L292-L294
3. https://docs.openstack.org/developer/neutron/devref/
provisioning_blocks.html

Cheers,
Kevin Benton
__
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

[openstack-dev] [neutron] - Adding Miguel Lavalle to neutron-drivers team

[Kevin Benton]

Hi,

I would like to add Miguel Lavalle (mlavalle) to the Neutron drivers team
[1].

Miguel has been instrumental in implemented features across Neutron and
Nova (routed networks, DNS, etc) and is now leading the L3 team. He has a
very good high level architectural view of Neutron necessary for deciding
what features are feasible for the platform.



1.
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team

Cheers,
Kevin Benton
__
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]: floating IP not being set for L2 GRE packets

[Kevin Benton]

Do you have the nf_conntrack_proto_gre kernel module loaded on the network
node?

On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao  wrote:

> Strangely enough, there is no problem when I make use of a VxLAN tunnel to
> communicate between the VM (inside the cloud) and an external machine. In
> this case, the network node is performing the correct translation between
> the VM’s local IP and the floating IP currently assigned to it.
>
> So far I have only seen this problem when using L2 GRE tunnels.
>
> Thanks,
>
> Anil
>
>
>
> *From:* Anil Rao [mailto:anil@gigamon.com]
> *Sent:* Wednesday, March 29, 2017 3:17 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [neutron]: floating IP not being set for L2
> GRE packets
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> 
>
> Feedback 
>
> Hi,
>
> I am seeing a strange behavior when it comes to floating IPs and L2 GRE
> tunnels that I was hoping someone could shed light on.
>
> Inside a tenant (project) I have a VM that wants to communicate with a
> machine residing outside the cloud. For this purpose, a floating IP has
> been assigned to the VM’s interface.
>
> *Case 1: VM communicates with external machine using ‘ping’.*
>
> This is successful.
>
> At the network node (from where the packets leave the OpenStack cloud),
> the VM’s local IP address is replaced with its floating IP for outgoing
> packets. Similarly, for incoming packets, the floating IP is replaced with
> the VM’s local IP address.
>
> *Case 2: VM communicates with the external machine using an L2 GRE tunnel.*
>
> This is not successful.
>
> At the network node, the outgoing packets [still] have the VM’ local IP
> address. It is not surprising that no packets come back for the VM from the
> external machine.
>
> My question is:  why didn’t the network node replace the VM’s IP address
> with its floating IP for the L2 GRE case although it did this for the
> simple ping case?
>
> I see this behavior on a multi-node DevStack based on stable/ocata as well
> as a multi-node production Newton cloud.
>
> Thanks and regards,
>
> Anil
>
>
>
> __
> 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
>
>
__
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