Re: [Openstack] Help with hardcoded project_id query_filter in neutron when not admin

[Kevin Benton]

This isn't a direct answer to your question, but you can use service
subnets to avoid the routers burning public IP addresses to make per-tenant
routers feasible:
https://docs.openstack.org/neutron/pike/admin/config-service-subnets.html

As for enabling the shared router use case, I recommend filing a request
for enhancement (RFE) bug because it seems reasonable to allow tenant
floating IP allocations via a router attached to a subnet owned by the
tenant.


On Aug 17, 2018 06:17, "Johan Jatko"  wrote:

Hi!

I got a problem with neutron-server, and I am not sure if I should
consider it a bug, a platform limitation, or a future improvement.

My scenario is that I want to allocate floating ips from project "admin"
to project "project1".
On project admin, I have an external network, and a router connecting
the external network "external" and a internal network "access-network"

"access-network" is shared to "user1".

When a user in "project1" (non-admin) tries to assign floating ip to an
instance that is connected to "access-network", the returned error is
"Router {ID} could not be found".

Letting our projects create their own routers on the external network
wastes a lot of IPs for us, so we would like to use a shared router.

After debugging I have found out that this is due to a check in
neutron/_model_query.py in query_with_hooks that checks if the current
context is service or admin, and IF NOT, adds a query_filter that limits
the query to the current project.

This seems by design but I cannot for the life of me understand why the
policy system cannot enforce this instead (or the rbac system?).


For now I have decided to just patch it myself and push the change to my
cluster, but it would be interesting to hear if there are any design
decisions for it.



Regards
Johan Jatko
Luleå Academic Computer Society

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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-operators] [openstack operators][neutron] Neutron Router getting address not inside allocation range on provider network

[Kevin Benton]

I think you might have uncovered an edge-case that should probably be filed
as a bug against Neutron.

If a router interface is attached using a reference to a subnet, it always
tries to use the address in the "gateway_ip" of the subnet:
https://github.com/openstack/neutron/blob/282d3da614f24a6385c63a926a48845d3f6d72a3/neutron/db/l3_db.py#L797-L798

My opinion is that Neutron probably shouldn't allow grabbing the default
gateway if you aren't the owner of the subnet, but that is a fix that might
not land for a while depending on their priorities (I'm no longer an active
developer).


In the meantime, I recommend that you create a neutron port as an admin on
the public network using the gateway_ip of the network to represent your
real gateway router. This will prevent anyone from being able to attach a
router using the subnet as a reference since the gateway_ip address will
already be in use.

Cheers,
Kevin Benton


On Sat, Mar 17, 2018 at 4:10 PM, Chris Apsey <bitskr...@bitskrieg.net>
wrote:

> All,
>
> Had a strange incident the other day that seems like it shouldn't be
> possible inside of neutron...
>
> We are currently running Queens on Ubuntu 16.04 w/ the linuxbridge ml2
> plugin with vxlan overlays.  We have a single, large provider network that
> we have set to 'shared' and 'external', so people who need to do things
> that don't work well with NAT can connect their instances directly to the
> provider network.  Our 'allocation range' as defined in our provider subnet
> is dedicated to tenants, so there should be no conflicts.
>
> The other day, one of our users connected a neutron router to the provider
> network (not via the 'external network' option, but rather via the normal
> 'add interface' option) and neglected to specify an IP address.  The
> neutron router decided that it was now the gateway for the entire provider
> network and began arp'ing as such (I'm sure you can imagine the results).
>
> To me, this seems like it should be disallowed inside of neutron (you
> shouldn't be able to specify an IP address for a router interface that
> isn't explicitly part of your allocation range on said subnet).  Does
> neutron just expect issues like this to be handled by the physical provider
> infrastructure (spoofing prevention, etc.)?
>
> Thanks,
>
> ---
> v/r
>
> Chris Apsey
> bitskr...@bitskrieg.net
> https://www.bitskrieg.net
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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 

Re: [Openstack] Disable distributed loadbalancers (LBaaSv2)?

[Kevin Benton]

Not really. Just bring some stuff up. Even if the routers are messed up the
compute instances won't get hurt.

The snat stuff sounds right.

On Sep 25, 2017 2:45 PM, "Turbo Fredriksson" <tu...@bayour.com> wrote:

On 21 Sep 2017, at 04:45, Kevin Benton <ke...@benton.pub> wrote:

> If you wanted to do it purely with an SQL hack you might be able to set
distributed to False in the router_extra_attributes table. Additionally you
would need to delete any entries from the routerports table with the type
'network:router_centralized_snat' and update any with the type
'network:router_interface_distributed' to 'network:router_interface’.

Thanx! That seems to have done the trick. I think:

bladeA01:~# neutron router-list
+--++---


---+
-+---+
| id   | name   |
external_gateway_info

  | distributed | ha|
+--++---


---+
-+---+
| d9c39638-51b5-481a-a60d-df79b6a06f9d | infrastructure | {"network_id":
"b74570c9-f40f-4c64-9e4c-9bf0c9978d2e", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "7bc73f7a-f07e-4ad7-bcd8-1fd77f46c888",
"ip_address": "10.0.5.1"}]} | False   | False |
| dac1e4f4-dd02-4f97-bc77-952906e8daa7 | tenant | {"network_id":
"b74570c9-f40f-4c64-9e4c-9bf0c9978d2e", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "ab4da704-0ed2-4e54-89e4-afc98b8bb631",
"ip_address": "10.0.6.1"}]} | False   | False |
+--++---


---+
-+———+

The “external_gateway_info” still say “enable_snat=true” on both of them…
Is that correct?

But at least both “distributed” and “ha” is “False” now, so there’s a lot
of progress! :). Million thanx.


All my compute nodes are still down, haven’t dared start them up yet.
Any way I can know for sure that this actually worked, without spinning
up everything?

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Disable distributed loadbalancers (LBaaSv2)?

[Kevin Benton]

If you wanted to do it purely with an SQL hack you might be able to set
distributed to False in the router_extra_attributes table. Additionally you
would need to delete any entries from the routerports table with the type
'network:router_centralized_snat' and update any with the type
'network:router_interface_distributed' to 'network:router_interface'.

You'll want to do that while all of the L3 and L2 agents are offline. Then
delete all of the router namespaces using the netns cleanup tool and
restart the agents.

That *might* do the trick, but I haven't tested this any time recently so
unfortunately I can't guarantee that it will be enough. :/

On Wed, Sep 20, 2017 at 6:12 AM, Turbo Fredriksson  wrote:

> On 18 Sep 2017, at 21:19, Turbo Fredriksson  wrote:
>
> > No way I can convince someone to do it, for a (small) monetary donation?
>
> No-one?
>
>
> Any SQL query hack I could use to get rid of it?
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[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

Re: [Openstack] transfer of IP address between ports

[Kevin Benton]

If re-using the port isn't feasible. You can update the allocation pools on
the subnet to exclude the IP address in question. It's hacky, but doing
that before removing it from the original port will ensure it's not
automatically allocated to another port.

On Wed, Aug 23, 2017 at 8:17 AM, 공용준  wrote:

> Hi
>
> You can use fixed ip port for this.
> create neutron port and attach it to the one vm.
> or
> you can use floating ip for this purpose as well
>
> Regards,
> Andrew
>
>
> 2017. 8. 23. 오후 10:58, Volodymyr Litovka  작성:
>
> Hi colleagues,
>
> imagine, somebody (e.g. me :-) ) needs to transfer IP address between two
> ports. The straight way is: release IP address and then assign it to
> another port.
>
> The possible problem with this way is time between release and assignment
> - during this time, this IP address is in DHCP pool and can be
> automatically assigned to some another port upon request.
>
> Any ideas how to prevent leasing this IP address during this time?
>
> Thank you.
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Acquire UUID of Agent

[Kevin Benton]

Use '--agent-type' and/or '--host' to filter the results based on those
fields.

https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/network-agent.html


On Aug 22, 2017 5:15 PM, "Sterdnot Shaken"  wrote:

> Is there a programmatic way to get what UUID is associated with, for
> example, an l3-agent?
>
> I know I can run "neutron agent-list" and grep based on agent type\name of
> server, but I don't want to have to grep for it… Is there a more direct API
> way of getting this info?
>
> Is there a command that lists all the UUID's associated with a particular
> server hostname for example?
>
> Thanks in advance!!
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [dnsmasq] setting ntp-server

[Kevin Benton]

You may also be able to do this with the neutron API on a per network basis
using the extra dhcp options.

On Aug 18, 2017 6:15 PM, "David Medberry"  wrote:

> Cool beans. Thanks for asking/answering your own question!
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[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-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Kevin Benton]

Unfortunately Neutron doesn't know anything about the hypervisor to make
that type of call. That will require support in Nova to listen for the port
admin state change from Neutron and reflect it in the loaded hypervisor.

It's worth filing a request with Nova to see if that's something they would
accept.

Nova already listens for port data plane status to unpause the VM on boot
so that communication channel is already in place.

On Aug 11, 2017 01:21, "Volodymyr Litovka" <doka...@gmx.com> wrote:

>
> On 8/8/17 7:18 PM, Kevin Benton wrote:
>
> The best way to completely ensure the instance isn't trying to use it is
> to detach it from the instance using the 'nova interface-detach' command.
>
> Sure, but this introduces additional complexity in complex environments
> when it's required to have predictable interface naming accordingly to
> roles (e.g. eth0 is always WAN connection, eth1 is always LAN1, eth2 is
> always control/mgmt, etc etc). Attaching/detaching interfaces changes this
> and requires to manage udev rules, which adds issues when creating new VM
> from snapshot, ... :-)
>
> Not too critical, everything can be handled using more or less complex
> workarounds, but, since libvirt has support to set interface state (using 
> '*virsh
> domif-setlink domain interface-device state*'), why don't use this call
> to reflect interface state according to Openstack's settings?
>
> Thanks.
>
>
> On Tue, Aug 8, 2017 at 7:49 AM, Volodymyr Litovka <doka...@gmx.com> wrote:
>
>> Hi Kevin,
>> see below
>>
>> On 8/8/17 1:06 AM, Kevin Benton wrote:
>>
>> What backend are you using? That bug is about the port showing ACTIVE
>> when admin_state_up=False but it's still being disconnected from the
>> dataplane. If you are seeing dataplane traffic with admin_state_up=False,
>> then that is a separate bug.
>>
>> I'm using OVS
>>
>> Also, keep in mind that marking the port down will still not be reflected
>> inside of the VM via ifconfig or ethtool. It will always show active in
>> there. So even after we fix bug 1672629, you are going to see the port is
>> connected inside of the VM.
>>
>> Is there way to disconnect port, thus putting it into DOWN state on VM,
>> using Openstack API ? This is important for *public clouds* when it can
>> be necessary to shutdown port of unmanaged (customer's) VM. The only idea I
>> have is to set admin_state_up to False and, actually, it's the only
>> command, which control port state.
>>
>> As I mentioned earlier, it seems it was working in Kilo ("I have checked
>> the behavior of admin_state_up of Kilo version, when port admin-state-up is
>> set to False, the port status will be DOWN.") but Ocata shows another
>> behaviour, ignoring this parameter.
>>
>> So, any ideas on how to shutdown port on VM using Openstack API?
>>
>> Thank you!
>>
>>
>> On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka <doka...@gmx.com>
>> wrote:
>>
>>> Hi colleagues,
>>>
>>> am I the only who care about this case? - https://bugs.launchpad.net/neu
>>> tron/+bug/1672629
>>>
>>> The problem is when I set port admin_state_up to False, it still UP on
>>> the VM thus continuing to route statically configured networks (e.g.
>>> received from DHCP host_routes), sending DHCP reqs, etc
>>>
>>> As people discovered, in Kilo everything was ok - "I have checked the
>>> behavior of admin_state_up of Kilo version, when port admin-state-up is set
>>> to False, the port status will be DOWN." - but at least in Ocata it is
>>> broken.
>>>
>>> Anybody facing this problem too? Any ideas on how to work around it?
>>>
>>> Thank you.
>>>
>>> --
>>> Volodymyr Litovka
>>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>>
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>> --
>> Volodymyr Litovka
>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>
>>
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Kevin Benton]

Once that bug is fixed, the port status will show DOWN in the Neutron API,
but that doesn't affect how it appears inside of the instance.

The best way to completely ensure the instance isn't trying to use it is to
detach it from the instance using the 'nova interface-detach' command.

On Tue, Aug 8, 2017 at 7:49 AM, Volodymyr Litovka <doka...@gmx.com> wrote:

> Hi Kevin,
> see below
>
> On 8/8/17 1:06 AM, Kevin Benton wrote:
>
> What backend are you using? That bug is about the port showing ACTIVE when
> admin_state_up=False but it's still being disconnected from the dataplane.
> If you are seeing dataplane traffic with admin_state_up=False, then that is
> a separate bug.
>
> I'm using OVS
>
> Also, keep in mind that marking the port down will still not be reflected
> inside of the VM via ifconfig or ethtool. It will always show active in
> there. So even after we fix bug 1672629, you are going to see the port is
> connected inside of the VM.
>
> Is there way to disconnect port, thus putting it into DOWN state on VM,
> using Openstack API ? This is important for *public clouds* when it can
> be necessary to shutdown port of unmanaged (customer's) VM. The only idea I
> have is to set admin_state_up to False and, actually, it's the only
> command, which control port state.
>
> As I mentioned earlier, it seems it was working in Kilo ("I have checked
> the behavior of admin_state_up of Kilo version, when port admin-state-up is
> set to False, the port status will be DOWN.") but Ocata shows another
> behaviour, ignoring this parameter.
>
> So, any ideas on how to shutdown port on VM using Openstack API?
>
> Thank you!
>
>
> On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka <doka...@gmx.com> wrote:
>
>> Hi colleagues,
>>
>> am I the only who care about this case? - https://bugs.launchpad.net/neu
>> tron/+bug/1672629
>>
>> The problem is when I set port admin_state_up to False, it still UP on
>> the VM thus continuing to route statically configured networks (e.g.
>> received from DHCP host_routes), sending DHCP reqs, etc
>>
>> As people discovered, in Kilo everything was ok - "I have checked the
>> behavior of admin_state_up of Kilo version, when port admin-state-up is set
>> to False, the port status will be DOWN." - but at least in Ocata it is
>> broken.
>>
>> Anybody facing this problem too? Any ideas on how to work around it?
>>
>> Thank you.
>>
>> --
>> Volodymyr Litovka
>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Kevin Benton]

What backend are you using? That bug is about the port showing ACTIVE when
admin_state_up=False but it's still being disconnected from the dataplane.
If you are seeing dataplane traffic with admin_state_up=False, then that is
a separate bug.

Also, keep in mind that marking the port down will still not be reflected
inside of the VM via ifconfig or ethtool. It will always show active in
there. So even after we fix bug 1672629, you are going to see the port is
connected inside of the VM.

On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka  wrote:

> Hi colleagues,
>
> am I the only who care about this case? - https://bugs.launchpad.net/
> neutron/+bug/1672629
>
> The problem is when I set port admin_state_up to False, it still UP on the
> VM thus continuing to route statically configured networks (e.g. received
> from DHCP host_routes), sending DHCP reqs, etc
>
> As people discovered, in Kilo everything was ok - "I have checked the
> behavior of admin_state_up of Kilo version, when port admin-state-up is set
> to False, the port status will be DOWN." - but at least in Ocata it is
> broken.
>
> Anybody facing this problem too? Any ideas on how to work around it?
>
> Thank you.
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Rescheduling neutron dhcp agents?

[Kevin Benton]

Yep, also note that you have to wait 2x whatever the agent down time is set
to before the rescheduling occurs.

On Aug 6, 2017 20:46, "Curtis" <serverasc...@gmail.com> wrote:

> On Sun, Aug 6, 2017 at 8:38 PM, Kevin Benton <ke...@benton.pub> wrote:
> > If you have 'allow_automatic_dhcp_failover' set to True then it will
> > automatically remove networks from DHCP agents that are offline.
> >
> > However, this only applies to networks that are in the
> admin_state_up=True
> > condition. If you explicitly set them to admin_state_up=False then
> automatic
> > rescheduling won't occur. This was intentionally done so operators could
> > avoid having networks rescheduled from DHCP agents they were performing
> > short term maintenance on.
> >
> > So next time just start by shutting the agent down and ensuring that
> > 'allow_automatic_dhcp_failover' is set to True in your server config
> and it
> > should work.
>
> Ok great, that makes sense to me. So if I had that
> allow_automatic_dhcp_failover set, and I was doing maintenance, then I
> could set admin_state_up to false. Or if I was migrating, leave it as
> true. Seems like a good setup.
>
> Thanks,
> Curtis.
>
> >
> > On Sun, Aug 6, 2017 at 3:16 PM, Xav Paice <xavpa...@gmail.com> wrote:
> >>
> >> Yeah, it's an odd one for sure, in my experience at least they do need
> to
> >> be manually re-scheduled.
> >>
> >> On Sun, 6 Aug 2017 at 11:27 Curtis <serverasc...@gmail.com> wrote:
> >>>
> >>> I'm in the process of testing out moving around some neutron services.
> >>> I'm starting with dhcp-agent. I've got neutron set to have 3 dhcp
> >>> instances per network.
> >>>
> >>> I set the admin state of a single dhcp agent to down, then all the
> >>> dhcp namespaces were automatically removed from the node running dhcp
> >>> agent. Then I deleted the agent thinking the dhcp services would get
> >>> rescheduled to another node, but they were not. So now I've just got
> >>> two dhcp servers for most networks.
> >>>
> >>> Am I, as admin, expected to now do something like add all the networks
> >>> with only 2 dhcp servers to a new dhcp-agent (using neutron
> >>> dhcp-agent-network-add) or should neutron reschedule them
> >>> automagically?
> >>>
> >>> I'm hoping I just missed a step here. :)
> >>>
> >>> Thanks,
> >>> Curtis.
> >>>
> >>> ___
> >>> OpenStack-operators mailing list
> >>> OpenStack-operators@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
> >>
> >>
> >> ___
> >> OpenStack-operators mailing list
> >> OpenStack-operators@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >
>
>
>
> --
> Blog: serverascode.com
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Rescheduling neutron dhcp agents?

[Kevin Benton]

If you have 'allow_automatic_dhcp_failover' set to True then it will
automatically remove networks from DHCP agents that are offline.

However, this only applies to networks that are in the admin_state_up=True
condition. If you explicitly set them to admin_state_up=False then
automatic rescheduling won't occur. This was intentionally done so
operators could avoid having networks rescheduled from DHCP agents they
were performing short term maintenance on.

So next time just start by shutting the agent down and ensuring that
'allow_automatic_dhcp_failover' is set to True in your server config and it
should work.

On Sun, Aug 6, 2017 at 3:16 PM, Xav Paice  wrote:

> Yeah, it's an odd one for sure, in my experience at least they do need to
> be manually re-scheduled.
>
> On Sun, 6 Aug 2017 at 11:27 Curtis  wrote:
>
>> I'm in the process of testing out moving around some neutron services.
>> I'm starting with dhcp-agent. I've got neutron set to have 3 dhcp
>> instances per network.
>>
>> I set the admin state of a single dhcp agent to down, then all the
>> dhcp namespaces were automatically removed from the node running dhcp
>> agent. Then I deleted the agent thinking the dhcp services would get
>> rescheduled to another node, but they were not. So now I've just got
>> two dhcp servers for most networks.
>>
>> Am I, as admin, expected to now do something like add all the networks
>> with only 2 dhcp servers to a new dhcp-agent (using neutron
>> dhcp-agent-network-add) or should neutron reschedule them
>> automagically?
>>
>> I'm hoping I just missed a step here. :)
>>
>> Thanks,
>> Curtis.
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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] [neutron] cannot list "default" security group with Neutron API?

[Kevin Benton]

Hi,

This sounds like it may be a bug. My guess is that when we switched to
project ID a hook was not updated to create the default security group when
a project ID is passed instead of a tenant ID (this logic [1] in
particular).

Can you please file a bug on launchpad and reference this email thread and
we should be able to get it fixed pretty quickly.

1.
https://github.com/openstack/neutron/blob/71d9aab87e37b5162ef09b8cbe3b72709fc88a8b/neutron/db/securitygroups_db.py#L146-L153

Cheers,
Kevin Benton

On Tue, Jun 27, 2017 at 3:30 AM, Riccardo Murri <riccardo.mu...@uzh.ch>
wrote:

> Hello,
>
> I'm trying to add some rules to the "default" security group of a
> newly-created project, using the Neutron API 2.0.
>
> However, it seems that the "default" security group is automatically
> created but it is not returned by Neutron client's
> `list_security_groups()` API call.  My code works just fine if I use any
> security group name other than "default".
>
> This is an example interaction, which shows that there is no security
> group returned for the project::
>
> >>> project.id
> u'b26ed1aa29e64c3abeade0a47867eee3'
> >>> response = self.neutron.list_security_groups()  # self.neutron is
> a neutron_client.v2.Client instance
> >>> secgroups = response['security_groups']
> >>> all_sg_ids = [(sg['id'], sg['tenant_id']) for sg in secgroups]
> >>> all_sg_ids
> [(u'01de4e38-55ea-4b82-8583-274b1bded41a', u'
> 0ff1f3d07fbd4d41892cdf85d7a7d1a9'), ... ]
> >>> len(all_sg_ids)
> 17
> >>> project_sg_ids = [(sg['id'], sg['tenant_id']) for sg in secgroups
> if sg['tenant_id'] == project.id]
> >>> project_sg_ids
> []
>
> Shouldn't the "default" security group be listed there?
>
> In more details, this is the code I'm using (which, again, works as
> expected if I use any security group name other than "default")::
>
> class Projects(object):
> def __init__(self):
> self.session = get_session()
> self.keystone = keystone_client.Client(session=self.session)
> self.neutron = neutron_client.Client(session=self.session)
> self.nova = nova_client('2', session=self.session)
> # ...
>
> # ...
>
> def create(self, form):
> domain = self.keystone.domains.get(
> config.os_project_domain_id)
> project = self.keystone.projects.create(
> form.name.data,
> domain,
> description=form.description.data,
> enabled=False,  # will enable after configuring it
> # ...
> )
> try:
> response = self.neutron.create_security_group({
> 'security_group': {
> 'tenant_id': project.id,
> 'name': 'default',  # works if I change to e.g.
> 'TEST'
> 'description': "Default security group",
> }
> })
> except Conflict:
> # security group already exists, fetch it
> # `find_security_group_by_name()` is a small filter
> # for `list_security_groups()` results
> default_sg = find_security_group_by_name(self.neutron,
> project.id, 'default')
> # ... do something with the sec group ...
>
> What am I doing wrong?
>
> Thanks,
> Riccardo
>
> --
> Riccardo Murri
> http://www.s3it.uzh.ch/about/team/#Riccardo.Murri
>
> S3IT: Services and Support for Science IT
> University of Zurich
> Winterthurerstrasse 190, CH-8057 Zürich (Switzerland)
>
> Tel: +41 44 635 4208
> Fax: +41 44 635 6888
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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] [OpenStack] [nova] How can I release PCI device resources without delete instance?

[Kevin Benton]

As a stop gap for the IP problem, keep in mind that you can create a
neutron port separately and boot the instance to it. Then when you delete
the instance the port will remain and hold onto the IP so you can boot to
it with a different instance later.

On Jul 5, 2017 18:31, "Eddie Yen"  wrote:

> Hi, thanks for reply first!
>
> After I tried shelve instance, yes it really release GPU resources.
> But as Dinesh said, can't unshelve this instance if all GPUs occupied.
>
> Before known about shelve instance, I have do few approach.
>
> One is using "resize" the instance's flavor to non-GPU flavor, but can't
> do this if all GPUs occupied.
>
> Another one is like Jay's recommend is that create instance as volume, and
> delete instance but keep volume if this VM not going to use GPU.
> Then re-create instance with previous volume and non-GPU flavor.
> And yes, this approach have IP address problem that may cause application
> atypical.
>
> I'll try how to make my application not to rely on a persistent IP.
>
> Thanks,
> Eddie.
>
> 2017-07-05 19:36 GMT+08:00 Jay Pipes :
>
>> On 07/05/2017 04:18 AM, Eddie Yen wrote:
>>
>>> Hi everyone,
>>>
>>> I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU
>>> things.
>>>
>>> I got a problem is I need to delete current instance which contains GPU
>>> to release device if I want assign GPU to another new instance temperately.
>>>
>>> I'll got "No valid host was found" if I creating new instance contains
>>> GPU flavor without delete present instance, even the instance is shutdown.
>>>
>>> Is there any way that I just shutdown the instance rather than delete it
>>> to release GPU device?
>>>
>>
>> As Dinesh mentioned you *can* use shelve for this, but frankly, I think
>> the shelve API leads to more problems than it solves (see his response
>> about needing to delete the new instance before unshelving).
>>
>> I'd recommend redesigning your application to be more cloud-native. In
>> other words, separate operating system state from application state, use
>> volumes for all persistent application state, and do not rely on a
>> persistent IP address. [1]
>>
>> Once you've done that, you can just treat your VMs like cattle and
>> terminate them.
>>
>> Best,
>> -jay
>>
>> [1] Please note I did not use the word "container" in this description of
>> cloud-native application.
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Packstack Installation on CentOS 7, Networking problem (possibly External Bridge)

[Kevin Benton]

How did you create the external network? When you create it you have to
provide the physical network that corresponds to the mapping to br-ex that
you have in bridge_mappings in /etc/neutron/plugins/ml2/ml2_conf.ini (or
wherever packstack sets up the config file for the plugin).

On Wed, Jun 28, 2017 at 12:34 PM, Reza Shaikhly 
wrote:

> Hello eyeryone,
>
>
>
> I'm kind of new with OpenStack.
>
>
>
> Three months ago I managed to deploy OpenStack using Packstack on three
> nodes. Three VMs with CentOS 7 minimal created using VM Ware ESXI
> hypervisor: a controller node, a network controller node (Neutron) and a
> compute node (Nova). Things worked all right there as a test bed for PoC
> and lunching a few instances. That was OpenStack Newton.
>
> Yesterday I followed the very same procedure and I ran into two problems:
> first problem was related to NTP, and I finally found a workaround for it.
> However the second problem I couldn't handle it so far and I hope to get
> some kind recommendations here. The problem is that it seems the traffic
> does not go off to the External network
>
>
>
> I create an external network and a Router on a project using Horizon and
> connect the external network to the gateway of the Router. Everything seems
> fine, but I can't ping the router's gateway from my own client which are on
> the same subnet. It seems that External Bridge does not route the traffic
> outside.
>
> I can't ping the router's gateway from Neutron server. With this big
> problem I can't go further, because instances won't be able to ping outside
> network, also they won't be reachable from outside.
>
> I checked the firewall on my client and even turned it off. Also I checked
> Neutron server's firewall status using: "systemctl status firewalld" and
> service seemed dead.
>
>
>
> Here is my eth0 and External bridge configurations on Neutron server:
>
>
>
> eth0:
>
> DEVICETTYPE=ovs
>
> TYPE=OVSPort
>
> OVS_BRIDGE=br-ex
>
> DEVICE=eth0
>
> NAME=eth0
>
> BOOTPROTO=none
>
> ONBOOT=yes
>
>
>
> External bridge:
>
> TYPE=OVSBridge
>
> DEVICE=br-ex
>
> NAME=br-ex
>
> BOOTPROTO=static
>
> DEVICETYPE=ovs
>
> ONBOOT=yes
>
> IPADDR=172.16.10.123
>
> NETMASK=255.255.255.0
>
> GATEWAY=172.16.10.1
>
> DNS1=8.8.8.8
>
> PEERDNS=yes
>
> USERCTL=yes
>
>
>
>
>
> Even I lunched three instances using Cirros image and they able to ping
> each other, also able to ping the gateway of the router, However nothing
> seems reachable from outside.
>
>
>
> That's why I think there should be something wrong with External Bridge.
>
>
>
> Please Help, if you have any alternative config for external bridge and
> NIC card, or whatever useful to help my limit knowledge...
>
>
>
> Thank you
>
> Rez
>
>
>
> P.S: Is the NIC card type in VM has anything to do with this problem? I
> mean when I created the Virtual machines, I chose VMXNET3 as NIC card type,
> should I try another type, something like E1000, maybe for compatibility?
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [openstack][nova] Changes-Since parameter in Nova API not working as expected

[Kevin Benton]

Keep in mind that security groups are still a property of the port, so you
have to decide what to do when a server has two ports in the same security
group and one of the ports is removed from that group. In that scenario the
security groups of the instance haven't changed even though one of the
ports was removed. Do you adjust the updated_at timestamp then?

On Mon, Jun 26, 2017 at 12:32 PM, Jay Pipes  wrote:

> On 06/26/2017 02:27 PM, Jose Renato Santos wrote:
>
>> Jay,
>> Thanks for your response
>>
>> Let me clarify my point.
>> I am not expecting to see a change in the updated_at column of a server
>> when the rules of its security group changes.
>> I agree that would be a change to be handled by the Neutron Api, and
>> would be too much to ask for Nova to keep track of that
>> But I would expect to see a change in updated_at column of a server
>> instance when I associated(attach) a new security group to that server.
>> For me that is a change in the server and not on the security group. The
>> security group was not changed, but the server was, as it is now associated
>> with a different set of security groups
>> I hope that clarifies my question.
>>
>
> I think that's a pretty reasonable request actually. Care to create a bug
> on Launchpad for it?
>
>
> Best,
> -jay
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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-operators] [neutron] ML2/OVS dropping packets?

[Kevin Benton]

Can you do a tcpdump to see if the VM is sending any packets out that other
interface with the source mac of the primary interface?

We make use of the NORMAL action which does mac learning so it's possible
something is slipping through that is causing OVS to get the wrong port
association.

The other possibility is that the ARP entry on the upstream router is
learning the secondary MAC for the IP of the primary due to some traffic
slipping out.

Seeing the dest MAC of upstream traffic going into the filtering bridge of
the secondary interface should tell you if it's a Mac learning problem or
an arp problem.


On Jun 21, 2017 10:52, "Jonathan Proulx" <j...@csail.mit.edu> wrote:



So this all gets more interesting the packets aren't lost they get
routed (switched?) to the wrong interface...


The VM has two interfaces on the same network. Not sure this makes
sense and wes done because this was a straight physical to virtual
migration.  But seems like it should work

so VM is sending SYN from it's (vm)eth0 -> tap0 -> qvb0 -> qvo0 ->
int-eth1-br
-> phy-eht1-br -> (hypervisor)eth1 -> WORLD

but the ACK is coming back (hypervisor)eth1 ->  phy-eht1-br ->
int-eth1-br -> qvo1 !!! -> qvb1 -> tap1 where presumablely sec-group
rules see it as invalid and drop it.

This is quite odd.  Default route on VM is through eth0 where packets
are originatine and where teh ipv4 address it should return to is.

really puzzled why OVS is sending packets back through wrong path.

on the one hand I want to say stop doing that just put both addresses
on one port, on the other I see no reason why it shouldn't work.

-Jon


On Wed, Jun 21, 2017 at 05:35:02PM +0100, Stig Telfer wrote:
:Hi Jon -
:
:From what I understand, while you might have gone to the trouble of
configuring a lossless data centre ethernet, that guarantee of packet loss
ends at the hypervisor. OVS (and other virtual switches) will drop packets
rather than exert back pressure.
:
:I saw a useful paper from IBM Zurich on developing a flow-controlled
virtual switch:
:
:http://researcher.ibm.com/researcher/files/zurich-DCR/
Got%20Loss%20Get%20zOVN.pdf <http://researcher.ibm.com/
researcher/files/zurich-DCR/Got%20Loss%20Get%20zOVN.pdf>
:
:It’s a bit dated (2013) but may still apply.
:
:If you figure out a way of preventing this with modern OVS, I’d be very
interested to know.
:
:Best wishes,
:Stig
:
:
:> On 21 Jun 2017, at 16:24, Jonathan Proulx <j...@csail.mit.edu> wrote:
:>
:> On Wed, Jun 21, 2017 at 02:39:23AM -0700, Kevin Benton wrote:
:> :Are there any events going on during these outages that would cause
:> :reprogramming by the Neutron agent? (e.g. port updates) If not, it's
likely
:> :an OVS issue and you might want to cross-post to the ovs-discuss mailing
:> :list.
:>
:> Guess I'll have to wander deeper into OVS land.
:>
:> No agent updates and nothing in ovs logs (at INFO), flipping to Debug
:> and there's so many messages they get dropped:
:>
:> 017-06-21T15:15:36.972Z|00794|dpif(handler12)|DBG|Dropped 35 log
messages in last 0 seconds (most recently, 0 seconds ago) due to excessive
rate
:>
:> /me wanders over to ovs-discuss
:>
:> Thanks,
:> -Jon
:>
:> :Can you check the vswitch logs during the packet loss to see if there
are
:> :any messages indicating a reason? If that doesn't show anything and it
can
:> :be reliably reproduced, it might be worth increasing the logging for the
:> :vswitch to debug.
:> :
:> :
:> :
:> :On Tue, Jun 20, 2017 at 12:36 PM, Jonathan Proulx <j...@csail.mit.edu>
wrote:
:> :
:> :> Hi All,
:> :>
:> :> I have a very busy VM (well one of my users does I don't have access
:> :> but do have cooperative and copentent admin to interact with on th
:> :> eother end).
:> :>
:> :> At peak times it *sometimes* misses packets.  I've been didding in for
:> :> a bit ant it looks like they get dropped in OVS land.
:> :>
:> :> The VM's main function in life is to pull down webpages from other
:> :> sites and analyze as requested.  During peak times ( EU/US working
:> :> hours ) it sometimes hangs some requests and sometimes fails.
:> :>
:> :> Looking at traffic the out bound SYN request from VM is always good
:> :> and returning ACK always gets to physical interface of the hypervisosr
:> :> (on a provider vlan).
:> :>
:> :> When packets get dropped they do not make it to the qvo-XX on
:> :> the integration bridge.
:> :>
:> :> My suspicion is that OVS isn't keeping up eth1-br flow rules remaping
:> :> from external to internal vlan-id but neither quite sure how to prove
:> :> that or what to do about it.
:> :>
:> :> My initial though had been to blame contrack but drops are happening
:> :> before the iptables rules and while there's a lo

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-operators] [neutron] ML2/OVS dropping packets?

[Kevin Benton]

Are there any events going on during these outages that would cause
reprogramming by the Neutron agent? (e.g. port updates) If not, it's likely
an OVS issue and you might want to cross-post to the ovs-discuss mailing
list.

Can you check the vswitch logs during the packet loss to see if there are
any messages indicating a reason? If that doesn't show anything and it can
be reliably reproduced, it might be worth increasing the logging for the
vswitch to debug.



On Tue, Jun 20, 2017 at 12:36 PM, Jonathan Proulx  wrote:

> Hi All,
>
> I have a very busy VM (well one of my users does I don't have access
> but do have cooperative and copentent admin to interact with on th
> eother end).
>
> At peak times it *sometimes* misses packets.  I've been didding in for
> a bit ant it looks like they get dropped in OVS land.
>
> The VM's main function in life is to pull down webpages from other
> sites and analyze as requested.  During peak times ( EU/US working
> hours ) it sometimes hangs some requests and sometimes fails.
>
> Looking at traffic the out bound SYN request from VM is always good
> and returning ACK always gets to physical interface of the hypervisosr
> (on a provider vlan).
>
> When packets get dropped they do not make it to the qvo-XX on
> the integration bridge.
>
> My suspicion is that OVS isn't keeping up eth1-br flow rules remaping
> from external to internal vlan-id but neither quite sure how to prove
> that or what to do about it.
>
> My initial though had been to blame contrack but drops are happening
> before the iptables rules and while there's a lot of connections on
> this hypervisor:
>
> net.netfilter.nf_conntrack_count = 351880
>
> There should be plent of overhead to handle:
>
> net.netfilter.nf_conntrack_max = 1048576
>
> Anyone have thought son where to go with this?
>
> version details:
> Ubuntu 14.04
> OpenStack Mitaka
> ovs-vsctl (Open vSwitch) 2.5.0
>
> Thanks,
> -Jon
>
> --
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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] Routed provider networks

[Kevin Benton]

Cool. I also filed a bug against the openstack client to provide a better
error message:
https://bugs.launchpad.net/python-openstackclient/+bug/1698668

On Sun, Jun 18, 2017 at 9:20 AM, Alex Evonosky <alex.evono...@gmail.com>
wrote:

> Kevin-
>
> you nailed it:
>
>
> openstack network create --share --provider-physical-network provider1
> --provider-network-type vlan --provider-segment 2016 multisegment1
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| UP   |
> | availability_zone_hints   |  |
> | availability_zones|  |
> | created_at| 2017-06-18T16:19:33Z |
> | description   |  |
> | dns_domain| None |
> | id| d607c5db-cd30-4e60-8ba9-d84f82a1e6bd |
> | ipv4_address_scope| None |
> | ipv6_address_scope| None |
> | is_default| None |
> | mtu   | 1500 |
> | name  | multisegment1|
> | port_security_enabled | True |
> | project_id| 664dc5e6023140eca0faeb2d0ecc31c2 |
> | provider:network_type | vlan |
> | provider:physical_network | provider1|
> | provider:segmentation_id  | 2016 |
> | qos_policy_id | None |
> | revision_number   | 3|
> | router:external   | Internal |
> | segments  | None |
> | shared| True |
> | status| ACTIVE   |
> | subnets   |  |
> | updated_at| 2017-06-18T16:19:33Z |
> +---+--+
>
>
> Thank you for helping on a Sunday!
>
>
>
> On Sun, Jun 18, 2017 at 12:16 PM, Remo Mattei <r...@italy1.com> wrote:
>
>> Its not going to be there.. you need to look into the plugins directory.
>>
>>
>>  grep provider *
>> ml2_conf.ini:# Default network type for external networks when no
>> provider attributes are
>> ml2_conf.ini:# specified. By default it is None, which means that if
>> provider attributes are
>> ml2_conf.ini:# specifying physical_network names usable for VLAN provider
>> and tenant
>>
>>
>>
>>
>> On Jun 18, 2017, at 9:13 AM, Alex Evonosky <alex.evono...@gmail.com>
>> wrote:
>>
>> Thank you Kevin,
>>
>> In the /etc/neutron/neutron.conf file, there is no [ml2_type_vlan]
>> section under ocata.  Do I need to add this section in?
>>
>> Thank you.
>>
>> On Sun, Jun 18, 2017 at 12:08 PM, Kevin Benton <ke...@benton.pub> wrote:
>>
>>> Ok. So the actual error message is "Invalid input for operation:
>>> physical_network 'provider1' unknown  for VLAN provider network.".
>>>
>>> That means that in your Neutron server configuration file under the
>>> [ml2_type_vlan] section you need to add 'provider1' to the
>>> 'network_vlan_ranges' option.
>>>
>>>
>>>
>>> On Sun, Jun 18, 2017 at 9:04 AM, Alex Evonosky <alex.evono...@gmail.com>
>>>  wrote:
>>>
>>>> Kevin-
>>>>
>>>> Thank you for the tip.  The Debug is attached as well.
>>>>
>>>> Thank you.
>>>>
>>>> On Sun, Jun 18, 2017 at 11:54 AM, Kevin Benton <ke...@benton.pub> wrot
>>>> e:
>>>>
>>>>> The openstack command should have an option to enable debugging so you
>>>>> can get the error message. Try openstack --debug
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jun 18, 2017 at 7:27 AM, Alex Evonosky <alex.evonosky@gmail.
>>>>> com> wrote:
>>>>>
>>>>>> Gary-
>>>>>>
>>>>>> Thank you for the feedback.  I issued the 

Re: [Openstack] Routed provider networks

[Kevin Benton]

It may be in /etc/neutron/plugins/ml2_conf.ini or somewhere in there. Run
'ps -ef | grep neutron-server' to see which config files are being
referenced in your deployment.

On Sun, Jun 18, 2017 at 9:13 AM, Alex Evonosky <alex.evono...@gmail.com>
wrote:

> Thank you Kevin,
>
> In the /etc/neutron/neutron.conf file, there is no [ml2_type_vlan]
> section under ocata.  Do I need to add this section in?
>
> Thank you.
>
> On Sun, Jun 18, 2017 at 12:08 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> Ok. So the actual error message is "Invalid input for operation:
>> physical_network 'provider1' unknown  for VLAN provider network.".
>>
>> That means that in your Neutron server configuration file under the
>> [ml2_type_vlan] section you need to add 'provider1' to the
>> 'network_vlan_ranges' option.
>>
>>
>>
>> On Sun, Jun 18, 2017 at 9:04 AM, Alex Evonosky <alex.evono...@gmail.com>
>> wrote:
>>
>>> Kevin-
>>>
>>> Thank you for the tip.  The Debug is attached as well.
>>>
>>> Thank you.
>>>
>>> On Sun, Jun 18, 2017 at 11:54 AM, Kevin Benton <ke...@benton.pub> wrote:
>>>
>>>> The openstack command should have an option to enable debugging so you
>>>> can get the error message. Try openstack --debug
>>>>
>>>>
>>>>
>>>> On Sun, Jun 18, 2017 at 7:27 AM, Alex Evonosky <alex.evono...@gmail.com
>>>> > wrote:
>>>>
>>>>> Gary-
>>>>>
>>>>> Thank you for the feedback.  I issued the command while tailing the
>>>>> log:
>>>>>
>>>>> *2017-06-18 10:24:51.841 12018 INFO neutron.api.v2.resource
>>>>> [req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66
>>>>> 664dc5e6023140eca0faeb2d0ecc31c2 - - -] create failed (client error): The
>>>>> server could not comply with the request since it is either malformed or
>>>>> otherwise incorrect.*
>>>>> *2017-06-18 10:24:51.843 12018 INFO neutron.wsgi
>>>>> [req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66
>>>>> 664dc5e6023140eca0faeb2d0ecc31c2 - *
>>>>>
>>>>>
>>>>> As for the ocata config, this was built by using the ocata:
>>>>>
>>>>> https://docs.openstack.org/ocata/install-guide-ubuntu/
>>>>>
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jun 18, 2017 at 10:17 AM, Gary Kotton <gkot...@vmware.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please look in /var/log/neutron/neutron-server.log
>>>>>>
>>>>>> That should provide and exception trace
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Alex Evonosky <alex.evono...@gmail.com>
>>>>>> *Date: *Sunday, June 18, 2017 at 5:04 PM
>>>>>> *To: *"openstack@lists.openstack.org" <openstack@lists.openstack.org>
>>>>>> *Subject: *[Openstack] Routed provider networks
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello-
>>>>>>
>>>>>>
>>>>>>
>>>>>> I wanted to test the routed provider networks of Ocata, and following
>>>>>> the example config:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://docs.openstack.org/ocata/networking-guide/config-rou
>>>>>> ted-networks.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> I typed in the following on my controller node:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> @openstack-controller1:~# openstack network create --share
>>>>>> --provider-physical-network provider1 --provider-network-type vlan
>>>>>> --provider-segment 2016 multisegment1
>>>>>>
>>>>>>
>>>>>>
>>>>>> and I receive this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Error while executing command: Bad Request*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is there a log that may show what this error is referring to?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Mailing list: http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>> Post to : openstack@lists.openstack.org
>>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>
>>>
>>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Routed provider networks

[Kevin Benton]

Ok. So the actual error message is "Invalid input for operation:
physical_network 'provider1' unknown  for VLAN provider network.".

That means that in your Neutron server configuration file under the
[ml2_type_vlan] section you need to add 'provider1' to the
'network_vlan_ranges' option.



On Sun, Jun 18, 2017 at 9:04 AM, Alex Evonosky <alex.evono...@gmail.com>
wrote:

> Kevin-
>
> Thank you for the tip.  The Debug is attached as well.
>
> Thank you.
>
> On Sun, Jun 18, 2017 at 11:54 AM, Kevin Benton <ke...@benton.pub> wrote:
>
>> The openstack command should have an option to enable debugging so you
>> can get the error message. Try openstack --debug
>>
>>
>>
>> On Sun, Jun 18, 2017 at 7:27 AM, Alex Evonosky <alex.evono...@gmail.com>
>> wrote:
>>
>>> Gary-
>>>
>>> Thank you for the feedback.  I issued the command while tailing the log:
>>>
>>> *2017-06-18 10:24:51.841 12018 INFO neutron.api.v2.resource
>>> [req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66
>>> 664dc5e6023140eca0faeb2d0ecc31c2 - - -] create failed (client error): The
>>> server could not comply with the request since it is either malformed or
>>> otherwise incorrect.*
>>> *2017-06-18 10:24:51.843 12018 INFO neutron.wsgi
>>> [req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66
>>> 664dc5e6023140eca0faeb2d0ecc31c2 - *
>>>
>>>
>>> As for the ocata config, this was built by using the ocata:
>>>
>>> https://docs.openstack.org/ocata/install-guide-ubuntu/
>>>
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>> On Sun, Jun 18, 2017 at 10:17 AM, Gary Kotton <gkot...@vmware.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please look in /var/log/neutron/neutron-server.log
>>>>
>>>> That should provide and exception trace
>>>>
>>>> Thanks
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>> *From: *Alex Evonosky <alex.evono...@gmail.com>
>>>> *Date: *Sunday, June 18, 2017 at 5:04 PM
>>>> *To: *"openstack@lists.openstack.org" <openstack@lists.openstack.org>
>>>> *Subject: *[Openstack] Routed provider networks
>>>>
>>>>
>>>>
>>>> Hello-
>>>>
>>>>
>>>>
>>>> I wanted to test the routed provider networks of Ocata, and following
>>>> the example config:
>>>>
>>>>
>>>>
>>>> https://docs.openstack.org/ocata/networking-guide/config-rou
>>>> ted-networks.html
>>>>
>>>>
>>>>
>>>> I typed in the following on my controller node:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> @openstack-controller1:~# openstack network create --share
>>>> --provider-physical-network provider1 --provider-network-type vlan
>>>> --provider-segment 2016 multisegment1
>>>>
>>>>
>>>>
>>>> and I receive this:
>>>>
>>>>
>>>>
>>>> *Error while executing command: Bad Request*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Is there a log that may show what this error is referring to?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thank you.
>>>>
>>>>
>>>>
>>>
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Routed provider networks

[Kevin Benton]

The openstack command should have an option to enable debugging so you can
get the error message. Try openstack --debug



On Sun, Jun 18, 2017 at 7:27 AM, Alex Evonosky 
wrote:

> Gary-
>
> Thank you for the feedback.  I issued the command while tailing the log:
>
> *2017-06-18 10:24:51.841 12018 INFO neutron.api.v2.resource
> [req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66
> 664dc5e6023140eca0faeb2d0ecc31c2 - - -] create failed (client error): The
> server could not comply with the request since it is either malformed or
> otherwise incorrect.*
> *2017-06-18 10:24:51.843 12018 INFO neutron.wsgi
> [req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66
> 664dc5e6023140eca0faeb2d0ecc31c2 - *
>
>
> As for the ocata config, this was built by using the ocata:
>
> https://docs.openstack.org/ocata/install-guide-ubuntu/
>
>
> Thank you.
>
>
>
>
> On Sun, Jun 18, 2017 at 10:17 AM, Gary Kotton  wrote:
>
>> Hi,
>>
>> Please look in /var/log/neutron/neutron-server.log
>>
>> That should provide and exception trace
>>
>> Thanks
>>
>> Gary
>>
>>
>>
>> *From: *Alex Evonosky 
>> *Date: *Sunday, June 18, 2017 at 5:04 PM
>> *To: *"openstack@lists.openstack.org" 
>> *Subject: *[Openstack] Routed provider networks
>>
>>
>>
>> Hello-
>>
>>
>>
>> I wanted to test the routed provider networks of Ocata, and following the
>> example config:
>>
>>
>>
>> https://docs.openstack.org/ocata/networking-guide/config-rou
>> ted-networks.html
>>
>>
>>
>> I typed in the following on my controller node:
>>
>>
>>
>>
>>
>> @openstack-controller1:~# openstack network create --share
>> --provider-physical-network provider1 --provider-network-type vlan
>> --provider-segment 2016 multisegment1
>>
>>
>>
>> and I receive this:
>>
>>
>>
>> *Error while executing command: Bad Request*
>>
>>
>>
>>
>>
>> Is there a log that may show what this error is referring to?
>>
>>
>>
>>
>>
>> Thank you.
>>
>>
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

But how is the gateway device configured. Have you setup NAT or routing on
it so traffic can get back?

On Jun 13, 2017 4:07 AM, "xiaotie" <xiao...@ywe.cc> wrote:

> screenshot has eth0 up, but without IP address on it.
> I use following command to configure network:
> ifconfig eth0 192.168.5.204 netmask 255.255.255.0
> route add default gw 192.168.5.1
>
>
> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>
> -原始邮件-
> *发件人:* Kevin Benton <ke...@benton.pub>
> *发送时间:* 2017年6月13日 星期二
> *收件人:* xiaotie <xiao...@ywe.cc>
> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
> *主题:* Re: Re: Re: Re: Re: Re: [Openstack-operators] IP not been
> configured in VM os, but openstanck assign IP for it
>
> The screenshot in your other email didn't work. It's just a huge chunk of
> base64 data.
>
> How is 192.168.5.1 configured to perform routing?
>
> On Mon, Jun 12, 2017 at 8:09 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> Also, what did you mean by this sentence?
>>
>> "I relance an instance, but the problem is as before. how can i fix
>> this? There is no error in log file."
>>
>>
>> On Mon, Jun 12, 2017 at 7:47 PM, Kevin Benton <ke...@benton.pub> wrote:
>>
>>> I don't understand your topology now.  If 192.168.5.0/24 has a floating
>>> IP on it, that means it's an external network and that you have some other
>>> external router on it. What is the device at the gateway IP of the 
>>> 192.168.5.0
>>> network?
>>>
>>> On Mon, Jun 12, 2017 at 7:06 PM, xiaotie <xiao...@ywe.cc> wrote:
>>>
>>>> So sorry, use neutron port-show, I find 192.168.5.207 is floating IP.
>>>> dhcp IP is 192.168.5.200,it is pingable
>>>> You know 192.168.5.208 is my cloud vm ip address. It is automaticaly
>>>> configuer to vm os, I manually config it in the vm os. When I shutdown
>>>> network on the cloud vm, I use port-show to see 192.168.5.208's state, it
>>>> is the same as before.
>>>>
>>>> I relance an instance, but the problem is as before. how can i fix
>>>> this? There is no error in log file.
>>>>
>>>>
>>>> neutron port-show f24b534e-b1e3-4496-9dc0-b4408610b7de
>>>> neutron CLI is deprecated and will be removed in the future. Use
>>>> openstack CLI instead.
>>>> +---+---
>>>> ---+
>>>> | Field | Value
>>>>|
>>>> +---+---
>>>> ---+
>>>> | admin_state_up| True
>>>>|
>>>> | allowed_address_pairs |
>>>>  |
>>>> | binding:host_id   | controller
>>>>|
>>>> | binding:profile   | {}
>>>>|
>>>> | binding:vif_details   | {"port_filter": true}
>>>>|
>>>> | binding:vif_type  | bridge
>>>>|
>>>> | binding:vnic_type | normal
>>>>|
>>>> | created_at| 2017-06-11T05:40:32Z
>>>>|
>>>> | description   |
>>>>  |
>>>> | device_id | dhcpd3377d3c-a0d1-5d71-9947-f1
>>>> 7125c357bb-1807f022-b989-4725-9d25-7d176b28ec72|
>>>> | device_owner  | network:dhcp
>>>>|
>>>> | extra_dhcp_opts   |
>>>>  |
>>>> | fixed_ips | {"subnet_id": 
>>>> "59fc76f2-c666-4693-b0f6-2a96a0189ef7",
>>>> "ip_address": "192.168.5.200"} |
>>>> | id| f24b534e-b1e3-4496-9dc0-b44086
>>>> 10b7de |
>>>> | mac_address   | fa:16:3e:7a:0e:72

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

The screenshot in your other email didn't work. It's just a huge chunk of
base64 data.

How is 192.168.5.1 configured to perform routing?

On Mon, Jun 12, 2017 at 8:09 PM, Kevin Benton <ke...@benton.pub> wrote:

> Also, what did you mean by this sentence?
>
> "I relance an instance, but the problem is as before. how can i fix this?
> There is no error in log file."
>
>
> On Mon, Jun 12, 2017 at 7:47 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> I don't understand your topology now.  If 192.168.5.0/24 has a floating
>> IP on it, that means it's an external network and that you have some other
>> external router on it. What is the device at the gateway IP of the 
>> 192.168.5.0
>> network?
>>
>> On Mon, Jun 12, 2017 at 7:06 PM, xiaotie <xiao...@ywe.cc> wrote:
>>
>>> So sorry, use neutron port-show, I find 192.168.5.207 is floating IP.
>>> dhcp IP is 192.168.5.200,it is pingable
>>> You know 192.168.5.208 is my cloud vm ip address. It is automaticaly
>>> configuer to vm os, I manually config it in the vm os. When I shutdown
>>> network on the cloud vm, I use port-show to see 192.168.5.208's state, it
>>> is the same as before.
>>>
>>> I relance an instance, but the problem is as before. how can i fix this?
>>> There is no error in log file.
>>>
>>>
>>> neutron port-show f24b534e-b1e3-4496-9dc0-b4408610b7de
>>> neutron CLI is deprecated and will be removed in the future. Use
>>> openstack CLI instead.
>>> +---+---
>>> ---+
>>> | Field | Value
>>>|
>>> +---+---
>>> ---+
>>> | admin_state_up| True
>>>|
>>> | allowed_address_pairs |
>>>  |
>>> | binding:host_id   | controller
>>>|
>>> | binding:profile   | {}
>>>|
>>> | binding:vif_details   | {"port_filter": true}
>>>|
>>> | binding:vif_type  | bridge
>>>|
>>> | binding:vnic_type | normal
>>>|
>>> | created_at| 2017-06-11T05:40:32Z
>>>|
>>> | description   |
>>>  |
>>> | device_id | dhcpd3377d3c-a0d1-5d71-9947-f1
>>> 7125c357bb-1807f022-b989-4725-9d25-7d176b28ec72|
>>> | device_owner  | network:dhcp
>>>|
>>> | extra_dhcp_opts   |
>>>  |
>>> | fixed_ips | {"subnet_id": 
>>> "59fc76f2-c666-4693-b0f6-2a96a0189ef7",
>>> "ip_address": "192.168.5.200"} |
>>> | id| f24b534e-b1e3-4496-9dc0-b44086
>>> 10b7de |
>>> | mac_address   | fa:16:3e:7a:0e:72
>>>|
>>> | name  |
>>>  |
>>> | network_id| 1807f022-b989-4725-9d25-7d176b
>>> 28ec72 |
>>> | port_security_enabled | False
>>>|
>>> | project_id| 9ffad77b319f4025a7a048b8f358b0
>>> 47 |
>>> | revision_number   | 25
>>>        |
>>> | security_groups   |
>>>  |
>>> | status| ACTIVE
>>>|
>>> | tags  |
>>>  |
>>> | tenant_id | 9ffad77b319f4025a7a048b8f358b0
>>> 47  

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

Also, what did you mean by this sentence?

"I relance an instance, but the problem is as before. how can i fix this?
There is no error in log file."


On Mon, Jun 12, 2017 at 7:47 PM, Kevin Benton <ke...@benton.pub> wrote:

> I don't understand your topology now.  If 192.168.5.0/24 has a floating
> IP on it, that means it's an external network and that you have some other
> external router on it. What is the device at the gateway IP of the 192.168.5.0
> network?
>
> On Mon, Jun 12, 2017 at 7:06 PM, xiaotie <xiao...@ywe.cc> wrote:
>
>> So sorry, use neutron port-show, I find 192.168.5.207 is floating IP.
>> dhcp IP is 192.168.5.200,it is pingable
>> You know 192.168.5.208 is my cloud vm ip address. It is automaticaly
>> configuer to vm os, I manually config it in the vm os. When I shutdown
>> network on the cloud vm, I use port-show to see 192.168.5.208's state, it
>> is the same as before.
>>
>> I relance an instance, but the problem is as before. how can i fix this?
>> There is no error in log file.
>>
>>
>> neutron port-show f24b534e-b1e3-4496-9dc0-b4408610b7de
>> neutron CLI is deprecated and will be removed in the future. Use
>> openstack CLI instead.
>> +---+---
>> ---+
>> | Field | Value
>>|
>> +---+---
>> ---+
>> | admin_state_up| True
>>|
>> | allowed_address_pairs |
>>  |
>> | binding:host_id   | controller
>>|
>> | binding:profile   | {}
>>|
>> | binding:vif_details   | {"port_filter": true}
>>|
>> | binding:vif_type  | bridge
>>|
>> | binding:vnic_type | normal
>>|
>> | created_at| 2017-06-11T05:40:32Z
>>|
>> | description   |
>>  |
>> | device_id | dhcpd3377d3c-a0d1-5d71-9947-f1
>> 7125c357bb-1807f022-b989-4725-9d25-7d176b28ec72|
>> | device_owner  | network:dhcp
>>|
>> | extra_dhcp_opts   |
>>  |
>> | fixed_ips | {"subnet_id": 
>> "59fc76f2-c666-4693-b0f6-2a96a0189ef7",
>> "ip_address": "192.168.5.200"} |
>> | id| f24b534e-b1e3-4496-9dc0-b44086
>> 10b7de |
>> | mac_address   | fa:16:3e:7a:0e:72
>>|
>> | name  |
>>  |
>> | network_id| 1807f022-b989-4725-9d25-7d176b
>> 28ec72 |
>> | port_security_enabled | False
>>|
>> | project_id| 9ffad77b319f4025a7a048b8f358b0
>> 47 |
>> | revision_number   | 25
>>|
>> | security_groups   |
>>  |
>> | status| ACTIVE
>>        |
>> | tags  |
>>          |
>> | tenant_id | 9ffad77b319f4025a7a048b8f358b0
>> 47 |
>> | updated_at| 2017-06-12T21:23:08Z
>>|
>> +---+---
>> ---+
>>
>>
>> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>>
>> -原始邮件-
>> *发件人:* Kevin Benton <ke...@benton.pub>
>> *发送时间:* 2017年6月13日 星期二
>> *收件人:* xiaotie <xiao...@ywe.cc>
>> *抄送:* O

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

If you're booting a VM directly on the provider network, then you don't
need to worry about the openstack router. It should be able to ping
192.168.5.1 directly and get outside of the network that way.

On Mon, Jun 12, 2017 at 8:04 PM, xiaotie <xiao...@ywe.cc> wrote:

> I use vituralbox on mac pro, I user two vm on vitualbox to set up
> openstack.
> Each vm has two ethernet:
>  one is use bridge on en0 wifi, which local net is 192.168.5.0/24
> ，its gateway ip is 192.168.5.1。I use it to simulate provider network
>  the other nat network，which net is 10.0.2.0/24 . I use it to
> simulate the self-service network
>
> openstack router ip is 192.168.5.203, and the ip range I assign to
> openstack is 192.168.5.200 -- 192.168.5.250
>
> Is this information is enough?
>
> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>
> -原始邮件-
> *发件人:* Kevin Benton <ke...@benton.pub>
> *发送时间:* 2017年6月13日 星期二
> *收件人:* xiaotie <xiao...@ywe.cc>
> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
> *主题:* Re: Re: Re: Re: Re: Re: [Openstack-operators] IP not been
> configured in VM os, but openstanck assign IP for it
>
>
> I don't understand your topology now.  If 192.168.5.0/24 has a floating
> IP on it, that means it's an external network and that you have some other
> external router on it. What is the device at the gateway IP of the 192.168.5.0
> network?
>
> On Mon, Jun 12, 2017 at 7:06 PM, xiaotie <xiao...@ywe.cc> wrote:
>
>> So sorry, use neutron port-show, I find 192.168.5.207 is floating IP.
>> dhcp IP is 192.168.5.200,it is pingable
>> You know 192.168.5.208 is my cloud vm ip address. It is automaticaly
>> configuer to vm os, I manually config it in the vm os. When I shutdown
>> network on the cloud vm, I use port-show to see 192.168.5.208's state, it
>> is the same as before.
>>
>> I relance an instance, but the problem is as before. how can i fix this?
>> There is no error in log file.
>>
>>
>> neutron port-show f24b534e-b1e3-4496-9dc0-b4408610b7de
>> neutron CLI is deprecated and will be removed in the future. Use
>> openstack CLI instead.
>> +---+---
>> ---+
>> | Field | Value
>>|
>> +---+---
>> ---+
>> | admin_state_up| True
>>|
>> | allowed_address_pairs |
>>  |
>> | binding:host_id   | controller
>>|
>> | binding:profile   | {}
>>|
>> | binding:vif_details   | {"port_filter": true}
>>|
>> | binding:vif_type  | bridge
>>|
>> | binding:vnic_type | normal
>>|
>> | created_at| 2017-06-11T05:40:32Z
>>|
>> | description   |
>>  |
>> | device_id | dhcpd3377d3c-a0d1-5d71-9947-f1
>> 7125c357bb-1807f022-b989-4725-9d25-7d176b28ec72|
>> | device_owner  | network:dhcp
>>|
>> | extra_dhcp_opts   |
>>  |
>> | fixed_ips | {"subnet_id": 
>> "59fc76f2-c666-4693-b0f6-2a96a0189ef7",
>> "ip_address": "192.168.5.200"} |
>> | id| f24b534e-b1e3-4496-9dc0-b44086
>> 10b7de |
>> | mac_address   | fa:16:3e:7a:0e:72
>>|
>> | name  |
>>  |
>> | network_id| 1807f022-b989-4725-9d25-7d176b
>> 28ec72 |
>> | port_security_enabled | False
>>|
>> | project_id| 9ffad77b319f4025a7a048b8f358b0
>> 47 |
>&g

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

I don't understand your topology now.  If 192.168.5.0/24 has a floating IP
on it, that means it's an external network and that you have some other
external router on it. What is the device at the gateway IP of the 192.168.5.0
network?

On Mon, Jun 12, 2017 at 7:06 PM, xiaotie <xiao...@ywe.cc> wrote:

> So sorry, use neutron port-show, I find 192.168.5.207 is floating IP.
> dhcp IP is 192.168.5.200,it is pingable
> You know 192.168.5.208 is my cloud vm ip address. It is automaticaly
> configuer to vm os, I manually config it in the vm os. When I shutdown
> network on the cloud vm, I use port-show to see 192.168.5.208's state, it
> is the same as before.
>
> I relance an instance, but the problem is as before. how can i fix this?
> There is no error in log file.
>
>
> neutron port-show f24b534e-b1e3-4496-9dc0-b4408610b7de
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
> +---+---
> ---+
> | Field | Value
>|
> +---+---
> ---+
> | admin_state_up| True
>|
> | allowed_address_pairs |
>  |
> | binding:host_id   | controller
>|
> | binding:profile   | {}
>|
> | binding:vif_details   | {"port_filter": true}
>|
> | binding:vif_type  | bridge
>|
> | binding:vnic_type | normal
>|
> | created_at| 2017-06-11T05:40:32Z
>|
> | description   |
>  |
> | device_id | dhcpd3377d3c-a0d1-5d71-9947-
> f17125c357bb-1807f022-b989-4725-9d25-7d176b28ec72|
> | device_owner  | network:dhcp
>|
> | extra_dhcp_opts   |
>  |
> | fixed_ips | {"subnet_id": 
> "59fc76f2-c666-4693-b0f6-2a96a0189ef7",
> "ip_address": "192.168.5.200"} |
> | id| f24b534e-b1e3-4496-9dc0-
> b4408610b7de |
> | mac_address   | fa:16:3e:7a:0e:72
>|
> | name  |
>  |
> | network_id| 1807f022-b989-4725-9d25-
> 7d176b28ec72 |
> | port_security_enabled | False
>|
> | project_id| 9ffad77b319f4025a7a048b8f358b0
> 47 |
> | revision_number   | 25
>|
> | security_groups   |
>  |
> | status| ACTIVE
>|
> | tags  |
>  |
> | tenant_id | 9ffad77b319f4025a7a048b8f358b0
> 47     |
> | updated_at| 2017-06-12T21:23:08Z
>    |
> +---+---
> ---+
>
>
> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>
> -原始邮件-
> *发件人:* Kevin Benton <ke...@benton.pub>
> *发送时间:* 2017年6月13日 星期二
> *收件人:* xiaotie <xiao...@ywe.cc>
> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
> *主题:* Re: Re: Re: Re: Re: [Openstack-operators] IP not been configured in
> VM os, but openstanck assign IP for it
>
>
> Name is just a field that can be set by users to track things.
>
> Do a neutron port-show on e949854e-3533-48c5-8a1a-3dc455dfa59c to see the
> details of that DHCP agent port.
>
> On Mon, Jun 12, 2017 at 5:53 PM, xiaotie <xiao...@ywe.cc> wrote:
>
>> its result is
>> [root@controller neutron]# neutron port-list
>> neutron CLI is deprecated and will be 

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

Name is just a field that can be set by users to track things.

Do a neutron port-show on e949854e-3533-48c5-8a1a-3dc455dfa59c to see the
details of that DHCP agent port.

On Mon, Jun 12, 2017 at 5:53 PM, xiaotie <xiao...@ywe.cc> wrote:

> its result is
> [root@controller neutron]# neutron port-list
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
> +--+--+-
> -+---+--
> +
> | id   | name |
> tenant_id| mac_address   |
> fixed_ips
> |
> +--+--+-
> -+---+--
> +
> | 40b6d8da-01a9-41ab-a48f-a7b00185853e |  |
> dfeb844b4942417e9e2d1299c49d1a3a | fa:16:3e:59:91:c0 | {"subnet_id":
> "f12e2ca7-133e-4b46-ad9b-8784d509eb0a", "ip_address": "172.16.1.1"}|
> | 793528db-e2c5-4b39-8f18-246362dd4a03 |
> |  | fa:16:3e:43:03:a0 | {"subnet_id":
> "59fc76f2-c666-4693-b0f6-2a96a0189ef7", "ip_address": "192.168.5.203"} |
> | e949854e-3533-48c5-8a1a-3dc455dfa59c |
> |  | fa:16:3e:c6:0a:ff | {"subnet_id":
> "59fc76f2-c666-4693-b0f6-2a96a0189ef7", "ip_address": "192.168.5.207"} |
> | f24b534e-b1e3-4496-9dc0-b4408610b7de |  |
> 9ffad77b319f4025a7a048b8f358b047 | fa:16:3e:7a:0e:72 | {"subnet_id":
> "59fc76f2-c666-4693-b0f6-2a96a0189ef7", "ip_address": "192.168.5.200"} |
> | f74ad12c-0134-4a33-bf32-e6dd12535673 |  |
> dfeb844b4942417e9e2d1299c49d1a3a | fa:16:3e:ac:45:41 | {"subnet_id":
> "f12e2ca7-133e-4b46-ad9b-8784d509eb0a", "ip_address": "172.16.1.2"}|
> | ffac71c1-cda8-4431-896c-a0e48515ea8f |  |
> dfeb844b4942417e9e2d1299c49d1a3a | fa:16:3e:63:8b:26 | {"subnet_id":
> "59fc76f2-c666-4693-b0f6-2a96a0189ef7", "ip_address": "192.168.5.208"} |
> +--+--+-
> -+---+--
> +
>
> 192.168.5.200 is provider network's start IP,192.168.5.203 is router IP,
> 192.168.5.208 is openstack vm instance IP, I configure it in vm os
> manually, they can ping from controller;
> may be 192.168.5.207 is dhcp agent IP, I can't confirm this , and can't
> ping.
>
> 172.16 is self-service network
>
> Why name field has no value? if 5.207 is dhcp agent ip and is not
> pingable, is this the root cause? how can i fix this
>
>
> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>
> -原始邮件-
> *发件人:* Kevin Benton <ke...@benton.pub>
> *发送时间:* 2017年6月13日 星期二
> *收件人:* xiaotie <xiao...@ywe.cc>
> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
> *主题:* Re: Re: Re: Re: [Openstack-operators] IP not been configured in VM
> os, but openstanck assign IP for it
>
>
> If you do a 'neutron port-list' do you see the DHCP agent port and is it
> ACTIVE?
>
> On Mon, Jun 12, 2017 at 3:19 PM, xiaotie <xiao...@ywe.cc> wrote:
>
>> Is your mean as follow:
>> [root@controller ~]# neutron agent-list
>> neutron CLI is deprecated and will be removed in the future. Use
>> openstack CLI instead.
>> +--+
>> ++---+---++-
>> --+
>> | id   | agent_type | host
>> | availability_zone | alive | admin_state_up | binary|
>> +--+
>> ++---+---++-
>> --+
>> | 214ea02c-ee30-4b0d-850e-09a78040531d | Linux bridge agent | controller
>> |   | :-)   | True   | neutron-linuxbridge-agent |
>> | 3a72b736-91b9-40d0-a202-265417760d7d | L3 agent   | controller
>> | nova  | :-)   | True   | neutron-l3-agent  |
>> | 42ca2ff4-ec58-4a38-afef-6a728347b3e6 | Metadata agent | controller
>> |   | :-)   | True   | neutron-metadata-agent|
>> | 82b060a1-94bd-4d03-a39f-894f251a9557 | Linux bridge agent | compute01
>> |

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

If you do a 'neutron port-list' do you see the DHCP agent port and is it
ACTIVE?

On Mon, Jun 12, 2017 at 3:19 PM, xiaotie <xiao...@ywe.cc> wrote:

> Is your mean as follow:
> [root@controller ~]# neutron agent-list
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
> +--+
> ++---+---++-
> --+
> | id   | agent_type | host
> | availability_zone | alive | admin_state_up | binary|
> +--+
> ++---+---++-
> --+
> | 214ea02c-ee30-4b0d-850e-09a78040531d | Linux bridge agent | controller
> |   | :-)   | True   | neutron-linuxbridge-agent |
> | 3a72b736-91b9-40d0-a202-265417760d7d | L3 agent   | controller
> | nova  | :-)   | True   | neutron-l3-agent  |
> | 42ca2ff4-ec58-4a38-afef-6a728347b3e6 | Metadata agent | controller
> |   | :-)   | True   | neutron-metadata-agent|
> | 82b060a1-94bd-4d03-a39f-894f251a9557 | Linux bridge agent | compute01
> |   | :-)   | True   | neutron-linuxbridge-agent |
> | 99e9f7f8-1823-416a-ab09-987f88ce1b2c | DHCP agent | controller
> | nova  | :-)   | True   | neutron-dhcp-agent|
> +--+
> ++---+---++-
> --+
>
> I run dhcp agent on the controller, as the quick install doc suggest
> artechure. and I can see some port as follow
> [root@controller ~]# netstat -tunlp | grep dh
> udp0  0 0.0.0.0:68  0.0.0.0:*
> 696/dhclient
> udp0  0 0.0.0.0:44070.0.0.0:*
> 696/dhclient
> udp6   0  0 :::21133:::*
> 696/dhclient
>
> you mean: I lanch another vm not on openstack platform, set its ethernet
> proto to dhcp?
>
>
> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>
> -原始邮件-
> *发件人:* Kevin Benton <ke...@benton.pub>
> *发送时间:* 2017年6月13日 星期二
> *收件人:* xiaotie <xiao...@ywe.cc>
> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
> *主题:* Re: Re: Re: [Openstack-operators] IP not been configured in VM os,
> but openstanck assign IP for it
>
>
> You need to run the DHCP agent on either the compute node or the same node
> running the L3 agent. It will get a port on the same network and offer DHCP
> addresses to the devices on that network.
>
> On Mon, Jun 12, 2017 at 3:09 PM, xiaotie <xiao...@ywe.cc> wrote:
>
>> Thank you kevin.
>> I just edit neutone code file and log nosise disapper.
>>
>> As you say, the vm does not automate be configured ip address. But when I
>> configure the address that openstack assign to it in the vm os, I can ping
>> local network,but I can't
>> ping 8.8.8.8. On my physical server in the same local network , I can
>> ping 8.8.8.8
>>
>> And another tiny question, how can I get dhcp address, and can you give
>> me some advice about which doc I can get experiencd with openstack's common
>> command and case.
>>
>>
>> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>>
>> -原始邮件-
>> *发件人:* Kevin Benton <ke...@benton.pub>
>> *发送时间:* 2017年6月13日 星期二
>> *收件人:* xiaotie <xiao...@ywe.cc>
>> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
>> *主题:* Re: Re: [Openstack-operators] IP not been configured in VM os, but
>> openstanck assign IP for it
>>
>>
>> That bug just fixes the log noise. That was not the cause of the failure.
>>
>> Check my suggestion about confirming that DHCP is working.
>>
>> On Mon, Jun 12, 2017 at 4:11 AM, xiaotie <xiao...@ywe.cc> wrote:
>>
>>> hi,kevin
>>> From this link， I think you have fix this bug. But how can I use it in
>>> my environment?
>>> Please forgive me, I'm newbie to openstack.
>>> In my environment, I use centos7.3, and use yum to install openstack.
>>>
>>> 在2017-06-12，Kevin Benton <ke...@benton.pub> 写道:
>>>
>>> -原始邮件-
>>> *发件人:* Kevin Benton <ke...@benton.pub>
>>> *发送时间:* 2017年6月12日 星期一
>>> *收件人:* xiaotie <xiao...@ywe.cc>
>>> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
>>> *主题:* Re: [Openstack-operators] IP not b

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

You need to run the DHCP agent on either the compute node or the same node
running the L3 agent. It will get a port on the same network and offer DHCP
addresses to the devices on that network.

On Mon, Jun 12, 2017 at 3:09 PM, xiaotie <xiao...@ywe.cc> wrote:

> Thank you kevin.
> I just edit neutone code file and log nosise disapper.
>
> As you say, the vm does not automate be configured ip address. But when I
> configure the address that openstack assign to it in the vm os, I can ping
> local network,but I can't
> ping 8.8.8.8. On my physical server in the same local network , I can ping
> 8.8.8.8
>
> And another tiny question, how can I get dhcp address, and can you give me
> some advice about which doc I can get experiencd with openstack's common
> command and case.
>
>
> 在2017-06-13，Kevin Benton <ke...@benton.pub> 写道:
>
> -原始邮件-
> *发件人:* Kevin Benton <ke...@benton.pub>
> *发送时间:* 2017年6月13日 星期二
> *收件人:* xiaotie <xiao...@ywe.cc>
> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
> *主题:* Re: Re: [Openstack-operators] IP not been configured in VM os, but
> openstanck assign IP for it
>
>
> That bug just fixes the log noise. That was not the cause of the failure.
>
> Check my suggestion about confirming that DHCP is working.
>
> On Mon, Jun 12, 2017 at 4:11 AM, xiaotie <xiao...@ywe.cc> wrote:
>
>> hi,kevin
>> From this link， I think you have fix this bug. But how can I use it in my
>> environment?
>> Please forgive me, I'm newbie to openstack.
>> In my environment, I use centos7.3, and use yum to install openstack.
>>
>> 在2017-06-12，Kevin Benton <ke...@benton.pub> 写道:
>>
>> -原始邮件-
>> *发件人:* Kevin Benton <ke...@benton.pub>
>> *发送时间:* 2017年6月12日 星期一
>> *收件人:* xiaotie <xiao...@ywe.cc>
>> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
>> *主题:* Re: [Openstack-operators] IP not been configured in VM os, but
>> openstanck assign IP for it
>>
>>
>> I believe that error is actually unrelated (bug reported here for that
>> https://bugs.launchpad.net/neutron/+bug/1697383 ).
>>
>> Do you have the DHCP agent running and is it's port active on the
>> network? You should be able to ping the DHCP address from the 192.168.5
>> network.
>>
>> If you don't have the DHCP agent, you will need to manually assign the IP
>> in your instance.
>>
>> On Sun, Jun 11, 2017 at 11:40 PM, xiaotie <xiao...@ywe.cc> wrote:
>>
>>>
>>> I lanch an instance, but the instance has not IP when I run command
>>>   'ip addr'.But router has assign ip for it.
>>>
>>>   My environment is:
>>>   two vms in virtualbox
>>>   each vm has two ethernet, 192.168.5.0/24 use bridge network; 10.0.0.0/24 
>>> use nat network, both is ok
>>>   I lanch provider network, and router ip is 192.168.5.203, I can ping it 
>>> on the host.
>>>   openstack instance has got an ip,192.168.5.205, I can see it in network 
>>> top0loy of the dashboard, and I can see provider network port is up,but I 
>>> can't ping it.
>>>
>>>   Router info
>>>   
>>> +--++--+-+-+---+
>>>   | id   | name   | tenant_id   
>>>  | external_gateway_info   | distributed | ha|
>>>   
>>> +--++--+-+-+---+
>>>   | efdc40ab-9425-4795-949e-6774eabceed0 | router | 
>>> dfeb844b4942417e9e2d1299c49d1a3a | {"network_id":  
>>> | False   | False |
>>>   |  || 
>>>  | "1807f022-b989-4725-9d25-7d176b28ec72", | |   |
>>>   |  || 
>>>  | "enable_snat": true,| |   |
>>>   |  || 
>>>  | "external_fixed_ips": [{"subnet_id":| |   |
>>>   |  || 
>>>  | "59fc76f2-c666-4693-b0f6-2a96a0189ef7", | |   |
>>>   |  

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

That bug just fixes the log noise. That was not the cause of the failure.

Check my suggestion about confirming that DHCP is working.

On Mon, Jun 12, 2017 at 4:11 AM, xiaotie <xiao...@ywe.cc> wrote:

> hi,kevin
> From this link， I think you have fix this bug. But how can I use it in my
> environment?
> Please forgive me, I'm newbie to openstack.
> In my environment, I use centos7.3, and use yum to install openstack.
>
> 在2017-06-12，Kevin Benton <ke...@benton.pub> 写道:
>
> -原始邮件-
> *发件人:* Kevin Benton <ke...@benton.pub>
> *发送时间:* 2017年6月12日 星期一
> *收件人:* xiaotie <xiao...@ywe.cc>
> *抄送:* OpenStack Operators <openstack-operators@lists.openstack.org>
> *主题:* Re: [Openstack-operators] IP not been configured in VM os, but
> openstanck assign IP for it
>
>
> I believe that error is actually unrelated (bug reported here for that
> https://bugs.launchpad.net/neutron/+bug/1697383 ).
>
> Do you have the DHCP agent running and is it's port active on the network?
> You should be able to ping the DHCP address from the 192.168.5 network.
>
> If you don't have the DHCP agent, you will need to manually assign the IP
> in your instance.
>
> On Sun, Jun 11, 2017 at 11:40 PM, xiaotie <xiao...@ywe.cc> wrote:
>
>>
>> I lanch an instance, but the instance has not IP when I run command
>>   'ip addr'.But router has assign ip for it.
>>
>>   My environment is:
>>   two vms in virtualbox
>>   each vm has two ethernet, 192.168.5.0/24 use bridge network; 10.0.0.0/24 
>> use nat network, both is ok
>>   I lanch provider network, and router ip is 192.168.5.203, I can ping it on 
>> the host.
>>   openstack instance has got an ip,192.168.5.205, I can see it in network 
>> top0loy of the dashboard, and I can see provider network port is up,but I 
>> can't ping it.
>>
>>   Router info
>>   
>> +--++--+-+-+---+
>>   | id   | name   | tenant_id
>> | external_gateway_info   | distributed | ha|
>>   
>> +--++--+-+-+---+
>>   | efdc40ab-9425-4795-949e-6774eabceed0 | router | 
>> dfeb844b4942417e9e2d1299c49d1a3a | {"network_id":  | 
>> False   | False |
>>   |  ||  
>> | "1807f022-b989-4725-9d25-7d176b28ec72", | |   |
>>   |  ||  
>> | "enable_snat": true,| |   |
>>   |  ||  
>> | "external_fixed_ips": [{"subnet_id":| |   |
>>   |  ||  
>> | "59fc76f2-c666-4693-b0f6-2a96a0189ef7", | |   |
>>   |  ||  
>> | "ip_address": "192.168.5.203"}]}| |   |
>>   
>> +--++--+-+-+---+
>>
>>   Port status
>>   名称 固定IP连接设备状态  管理状态动作
>>   (85f154ee-1dd6)192.168.5.205 compute:None  运行中 UP
>>
>>   when i lanch an instance, I  got the following error on the compute node:
>>   2017-06-12 06:49:43.610 20776 INFO neutron.agent.securitygroups_rpc 
>> [req-4fcd8220-8713-469c-9564-1d1eebf30675 472ca430fc46406abac12d2bb877326f 
>> dfeb844b4942417e9e2d1299c49d1a3a - - -] Security group member updated 
>> [u'b7da029d-70f0-4ac2-af09-fea4d0e8e516']
>>   2017-06-12 06:49:45.354 20776 INFO neutron.agent.securitygroups_rpc 
>> [req-bfc74178-179f-4abd-bdb2-25d66ce36107 - - - - -] Refresh firewall rules
>>   2017-06-12 06:49:47.358 20776 INFO neutron.agent.securitygroups_rpc 
>> [req-bfc74178-179f-4abd-bdb2-25d66ce36107 - - - - -] Preparing filters for 
>> devices set(['tap9db05558-8e'])
>>   2017-06-12 06:49:49.273 20776 INFO 
>> neutron.plugins.ml2.drivers.agent._common_agent 
>> [req-bfc74178-179f-4abd-bdb2-25d66ce36107 - - - - -] Port tap9db05558-8e 
>> updated. Details: {u'profile': {}, u'network_qos_policy_id': None, 
>> u'q

Re: [Openstack-operators] IP not been configured in VM os, but openstanck assign IP for it

[Kevin Benton]

I believe that error is actually unrelated (bug reported here for that
https://bugs.launchpad.net/neutron/+bug/1697383 ).

Do you have the DHCP agent running and is it's port active on the network?
You should be able to ping the DHCP address from the 192.168.5 network.

If you don't have the DHCP agent, you will need to manually assign the IP
in your instance.

On Sun, Jun 11, 2017 at 11:40 PM, xiaotie  wrote:

>
> I lanch an instance, but the instance has not IP when I run command
>   'ip addr'.But router has assign ip for it.
>
>   My environment is:
>   two vms in virtualbox
>   each vm has two ethernet, 192.168.5.0/24 use bridge network; 10.0.0.0/24 
> use nat network, both is ok
>   I lanch provider network, and router ip is 192.168.5.203, I can ping it on 
> the host.
>   openstack instance has got an ip,192.168.5.205, I can see it in network 
> top0loy of the dashboard, and I can see provider network port is up,but I 
> can't ping it.
>
>   Router info
>   
> +--++--+-+-+---+
>   | id   | name   | tenant_id 
>| external_gateway_info   | distributed | ha|
>   
> +--++--+-+-+---+
>   | efdc40ab-9425-4795-949e-6774eabceed0 | router | 
> dfeb844b4942417e9e2d1299c49d1a3a | {"network_id":  | 
> False   | False |
>   |  ||   
>| "1807f022-b989-4725-9d25-7d176b28ec72", | |   |
>   |  ||   
>| "enable_snat": true,| |   |
>   |  ||   
>| "external_fixed_ips": [{"subnet_id":| |   |
>   |  ||   
>| "59fc76f2-c666-4693-b0f6-2a96a0189ef7", | |   |
>   |  ||   
>| "ip_address": "192.168.5.203"}]}| |   |
>   
> +--++--+-+-+---+
>
>   Port status
>   名称  固定IP连接设备状态  管理状态动作
>   (85f154ee-1dd6) 192.168.5.205 compute:None  运行中 UP
>
>   when i lanch an instance, I  got the following error on the compute node:
>   2017-06-12 06:49:43.610 20776 INFO neutron.agent.securitygroups_rpc 
> [req-4fcd8220-8713-469c-9564-1d1eebf30675 472ca430fc46406abac12d2bb877326f 
> dfeb844b4942417e9e2d1299c49d1a3a - - -] Security group member updated 
> [u'b7da029d-70f0-4ac2-af09-fea4d0e8e516']
>   2017-06-12 06:49:45.354 20776 INFO neutron.agent.securitygroups_rpc 
> [req-bfc74178-179f-4abd-bdb2-25d66ce36107 - - - - -] Refresh firewall rules
>   2017-06-12 06:49:47.358 20776 INFO neutron.agent.securitygroups_rpc 
> [req-bfc74178-179f-4abd-bdb2-25d66ce36107 - - - - -] Preparing filters for 
> devices set(['tap9db05558-8e'])
>   2017-06-12 06:49:49.273 20776 INFO 
> neutron.plugins.ml2.drivers.agent._common_agent 
> [req-bfc74178-179f-4abd-bdb2-25d66ce36107 - - - - -] Port tap9db05558-8e 
> updated. Details: {u'profile': {}, u'network_qos_policy_id': None, 
> u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': 
> True, u'network_id': u'1807f022-b989-4725-9d25-7d176b28ec72', 
> u'segmentation_id': None, u'device_owner': u'compute:nova', 
> u'physical_network': u'provider', u'mac_address': u'fa:16:3e:61:90:f5', 
> u'device': u'tap9db05558-8e', u'port_security_enabled': True, u'port_id': 
> u'9db05558-8e87-4a24-928c-cd97b777', u'fixed_ips': [{u'subnet_id': 
> u'59fc76f2-c666-4693-b0f6-2a96a0189ef7', u'ip_address': u'192.168.5.211'}], 
> u'network_type': u'flat'}
>   2017-06-12 06:49:50.591 20776 ERROR neutron.callbacks.manager 
> [req-bfc74178-179f-4abd-bdb2-25d66ce36107 - - - - -] Error during 
> notification for 
> neutron.services.trunk.drivers.linuxbridge.agent.driver.LinuxBridgeTrunkDriver.agent_port_change--9223372036853960796
>  port_device, after_update
>   2017-06-12 06:49:50.591 20776 ERROR neutron.callbacks.manager Traceback 
> (most recent call last):
>   2017-06-12 06:49:50.591 20776 ERROR neutron.callbacks.manager   File 
> "/usr/lib/python2.7/site-packages/neutron/callbacks/manager.py", line 146, in 
> _notify_loop
>   2017-06-12 06:49:50.591 20776 ERROR neutron.callbacks.manager 
> callback(resource, event, trigger, **kwargs)
>   2017-06-12 06:49:50.591 20776 ERROR neutron.callbacks.manager   File 
> 

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

Re: [Openstack] Failed to add_interface: Bad router request: Router already has a port on subnet

[Kevin Benton]

What plugin are you using?

On Jun 3, 2017 6:21 AM, "Muhammad Asif"  wrote:

> Hi Geeks,
>
> I have deployed openstack OCATA. I have created a private network connect
> it with provider network using router. Everything was working fine without
> pinging instance from controller. But later all of sudden a link between
> router and private network disappear. I try to add interface again but it
> prmpt the following error.
>
> Failed to add_interface: Bad router request: Router already has a port on
> subnet 162233cb-5280-4d00-b8e0-0e85bbe3d7a9. Neutron server returns
> request_ids: ['req-04888d6d-a68f-482e-9bd0-a20f62628f72']
>
> What problem can be and how to fix it.
>
> Thanks
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[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] Strange: lost physical connectivity to compute hosts when using native (ryu) openflow interface

[Kevin Benton]

No prob. Thanks for replying.

On May 31, 2017 10:11 AM, "Gustavo Randich" <gustavo.rand...@gmail.com>
wrote:

> Hi Kevin, I confirm that applying the patch the problem is fixed.
>
> Sorry for the inconvenience.
>
>
> On Tue, May 30, 2017 at 9:36 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> Do you have that patch already in your environment? If not, can you
>> confirm it fixes the issue?
>>
>> On Tue, May 30, 2017 at 9:49 AM, Gustavo Randich <
>> gustavo.rand...@gmail.com> wrote:
>>
>>> While dumping OVS flows as you suggested, we finally found the cause of
>>> the problem: our br-ex OVS bridge lacked the secure fail mode configuration.
>>>
>>> May be the issue is related to this: https://bugs.launchpad.net/neu
>>> tron/+bug/1607787
>>>
>>> Thank you
>>>
>>>
>>> On Fri, May 26, 2017 at 6:03 AM, Kevin Benton <ke...@benton.pub> wrote:
>>>
>>>> Sorry about the long delay.
>>>>
>>>> Can you dump the OVS flows before and after the outage? This will let
>>>> us know if the flows Neutron setup are getting wiped out.
>>>>
>>>> On Tue, May 2, 2017 at 12:26 PM, Gustavo Randich <
>>>> gustavo.rand...@gmail.com> wrote:
>>>>
>>>>> Hi Kevin, here is some information aout this issue:
>>>>>
>>>>> - if the network outage lasts less than ~1 minute, then connectivity
>>>>> to host and instances is automatically restored without problem
>>>>>
>>>>> - otherwise:
>>>>>
>>>>> - upon outage, "ovs-vsctl show" reports "is_connected: true" in all
>>>>> bridges (br-ex / br-int / br-tun)
>>>>>
>>>>> - after about ~1 minute, "ovs-vsctl show" ceases to show
>>>>> "is_connected: true" on every bridge
>>>>>
>>>>> - upon restoring physical interface (fix outage)
>>>>>
>>>>> - "ovs-vsctl show" now reports "is_connected: true" in all
>>>>> bridges (br-ex / br-int / br-tun)
>>>>>
>>>>>- access to host and VMs is NOT restored, although some pings
>>>>> are sporadically answered by host (~1 out of 20)
>>>>>
>>>>>
>>>>> - to restore connectivity, we:
>>>>>
>>>>>
>>>>>   - execute "ifdown br-ex; ifup br-ex" -> access to host is
>>>>> restored, but not to VMs
>>>>>
>>>>>
>>>>>   - restart neutron-openvswitch-agent -> access to VMs is restored
>>>>>
>>>>> Thank you!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 28, 2017 at 5:07 PM, Kevin Benton <ke...@benton.pub>
>>>>> wrote:
>>>>>
>>>>>> With the network down, does ovs-vsctl show that it is connected to
>>>>>> the controller?
>>>>>>
>>>>>> On Fri, Apr 28, 2017 at 2:21 PM, Gustavo Randich <
>>>>>> gustavo.rand...@gmail.com> wrote:
>>>>>>
>>>>>>> Exactly, we access via a tagged interface, which is part of br-ex
>>>>>>>
>>>>>>> # ip a show vlan171
>>>>>>> 16: vlan171: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
>>>>>>> noqueue state UNKNOWN group default qlen 1
>>>>>>> link/ether 8e:14:8d:c1:1a:5f brd ff:ff:ff:ff:ff:ff
>>>>>>> inet 10.171.1.240/20 brd 10.171.15.255 scope global vlan171
>>>>>>>valid_lft forever preferred_lft forever
>>>>>>> inet6 fe80::8c14:8dff:fec1:1a5f/64 scope link
>>>>>>>valid_lft forever preferred_lft forever
>>>>>>>
>>>>>>> # ovs-vsctl show
>>>>>>> ...
>>>>>>> Bridge br-ex
>>>>>>> Controller "tcp:127.0.0.1:6633"
>>>>>>> is_connected: true
>>>>>>>     Port "vlan171"
>>>>>>> tag: 171
>>>>>>> Interface "vlan171"
>>>>>>> type: internal
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>

Re: [Openstack-operators] [Openstack] Strange: lost physical connectivity to compute hosts when using native (ryu) openflow interface

[Kevin Benton]

No prob. Thanks for replying.

On May 31, 2017 10:11 AM, "Gustavo Randich" <gustavo.rand...@gmail.com>
wrote:

> Hi Kevin, I confirm that applying the patch the problem is fixed.
>
> Sorry for the inconvenience.
>
>
> On Tue, May 30, 2017 at 9:36 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> Do you have that patch already in your environment? If not, can you
>> confirm it fixes the issue?
>>
>> On Tue, May 30, 2017 at 9:49 AM, Gustavo Randich <
>> gustavo.rand...@gmail.com> wrote:
>>
>>> While dumping OVS flows as you suggested, we finally found the cause of
>>> the problem: our br-ex OVS bridge lacked the secure fail mode configuration.
>>>
>>> May be the issue is related to this: https://bugs.launchpad.net/neu
>>> tron/+bug/1607787
>>>
>>> Thank you
>>>
>>>
>>> On Fri, May 26, 2017 at 6:03 AM, Kevin Benton <ke...@benton.pub> wrote:
>>>
>>>> Sorry about the long delay.
>>>>
>>>> Can you dump the OVS flows before and after the outage? This will let
>>>> us know if the flows Neutron setup are getting wiped out.
>>>>
>>>> On Tue, May 2, 2017 at 12:26 PM, Gustavo Randich <
>>>> gustavo.rand...@gmail.com> wrote:
>>>>
>>>>> Hi Kevin, here is some information aout this issue:
>>>>>
>>>>> - if the network outage lasts less than ~1 minute, then connectivity
>>>>> to host and instances is automatically restored without problem
>>>>>
>>>>> - otherwise:
>>>>>
>>>>> - upon outage, "ovs-vsctl show" reports "is_connected: true" in all
>>>>> bridges (br-ex / br-int / br-tun)
>>>>>
>>>>> - after about ~1 minute, "ovs-vsctl show" ceases to show
>>>>> "is_connected: true" on every bridge
>>>>>
>>>>> - upon restoring physical interface (fix outage)
>>>>>
>>>>> - "ovs-vsctl show" now reports "is_connected: true" in all
>>>>> bridges (br-ex / br-int / br-tun)
>>>>>
>>>>>- access to host and VMs is NOT restored, although some pings
>>>>> are sporadically answered by host (~1 out of 20)
>>>>>
>>>>>
>>>>> - to restore connectivity, we:
>>>>>
>>>>>
>>>>>   - execute "ifdown br-ex; ifup br-ex" -> access to host is
>>>>> restored, but not to VMs
>>>>>
>>>>>
>>>>>   - restart neutron-openvswitch-agent -> access to VMs is restored
>>>>>
>>>>> Thank you!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 28, 2017 at 5:07 PM, Kevin Benton <ke...@benton.pub>
>>>>> wrote:
>>>>>
>>>>>> With the network down, does ovs-vsctl show that it is connected to
>>>>>> the controller?
>>>>>>
>>>>>> On Fri, Apr 28, 2017 at 2:21 PM, Gustavo Randich <
>>>>>> gustavo.rand...@gmail.com> wrote:
>>>>>>
>>>>>>> Exactly, we access via a tagged interface, which is part of br-ex
>>>>>>>
>>>>>>> # ip a show vlan171
>>>>>>> 16: vlan171: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
>>>>>>> noqueue state UNKNOWN group default qlen 1
>>>>>>> link/ether 8e:14:8d:c1:1a:5f brd ff:ff:ff:ff:ff:ff
>>>>>>> inet 10.171.1.240/20 brd 10.171.15.255 scope global vlan171
>>>>>>>valid_lft forever preferred_lft forever
>>>>>>> inet6 fe80::8c14:8dff:fec1:1a5f/64 scope link
>>>>>>>valid_lft forever preferred_lft forever
>>>>>>>
>>>>>>> # ovs-vsctl show
>>>>>>> ...
>>>>>>> Bridge br-ex
>>>>>>> Controller "tcp:127.0.0.1:6633"
>>>>>>> is_connected: true
>>>>>>>     Port "vlan171"
>>>>>>> tag: 171
>>>>>>> Interface "vlan171"
>>>>>>> type: internal
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>

Re: [Openstack-operators] [Openstack] Strange: lost physical connectivity to compute hosts when using native (ryu) openflow interface

[Kevin Benton]

Do you have that patch already in your environment? If not, can you confirm
it fixes the issue?

On Tue, May 30, 2017 at 9:49 AM, Gustavo Randich <gustavo.rand...@gmail.com>
wrote:

> While dumping OVS flows as you suggested, we finally found the cause of
> the problem: our br-ex OVS bridge lacked the secure fail mode configuration.
>
> May be the issue is related to this: https://bugs.launchpad.net/
> neutron/+bug/1607787
>
> Thank you
>
>
> On Fri, May 26, 2017 at 6:03 AM, Kevin Benton <ke...@benton.pub> wrote:
>
>> Sorry about the long delay.
>>
>> Can you dump the OVS flows before and after the outage? This will let us
>> know if the flows Neutron setup are getting wiped out.
>>
>> On Tue, May 2, 2017 at 12:26 PM, Gustavo Randich <
>> gustavo.rand...@gmail.com> wrote:
>>
>>> Hi Kevin, here is some information aout this issue:
>>>
>>> - if the network outage lasts less than ~1 minute, then connectivity to
>>> host and instances is automatically restored without problem
>>>
>>> - otherwise:
>>>
>>> - upon outage, "ovs-vsctl show" reports "is_connected: true" in all
>>> bridges (br-ex / br-int / br-tun)
>>>
>>> - after about ~1 minute, "ovs-vsctl show" ceases to show "is_connected:
>>> true" on every bridge
>>>
>>> - upon restoring physical interface (fix outage)
>>>
>>> - "ovs-vsctl show" now reports "is_connected: true" in all
>>> bridges (br-ex / br-int / br-tun)
>>>
>>>- access to host and VMs is NOT restored, although some pings are
>>> sporadically answered by host (~1 out of 20)
>>>
>>>
>>> - to restore connectivity, we:
>>>
>>>
>>>   - execute "ifdown br-ex; ifup br-ex" -> access to host is
>>> restored, but not to VMs
>>>
>>>
>>>   - restart neutron-openvswitch-agent -> access to VMs is restored
>>>
>>> Thank you!
>>>
>>>
>>>
>>>
>>> On Fri, Apr 28, 2017 at 5:07 PM, Kevin Benton <ke...@benton.pub> wrote:
>>>
>>>> With the network down, does ovs-vsctl show that it is connected to the
>>>> controller?
>>>>
>>>> On Fri, Apr 28, 2017 at 2:21 PM, Gustavo Randich <
>>>> gustavo.rand...@gmail.com> wrote:
>>>>
>>>>> Exactly, we access via a tagged interface, which is part of br-ex
>>>>>
>>>>> # ip a show vlan171
>>>>> 16: vlan171: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue
>>>>> state UNKNOWN group default qlen 1
>>>>> link/ether 8e:14:8d:c1:1a:5f brd ff:ff:ff:ff:ff:ff
>>>>> inet 10.171.1.240/20 brd 10.171.15.255 scope global vlan171
>>>>>valid_lft forever preferred_lft forever
>>>>> inet6 fe80::8c14:8dff:fec1:1a5f/64 scope link
>>>>>valid_lft forever preferred_lft forever
>>>>>
>>>>> # ovs-vsctl show
>>>>> ...
>>>>> Bridge br-ex
>>>>> Controller "tcp:127.0.0.1:6633"
>>>>> is_connected: true
>>>>> Port "vlan171"
>>>>> tag: 171
>>>>> Interface "vlan171"
>>>>> type: internal
>>>>> ...
>>>>>
>>>>>
>>>>> On Fri, Apr 28, 2017 at 3:03 PM, Kevin Benton <ke...@benton.pub>
>>>>> wrote:
>>>>>
>>>>>> Ok, that's likely not the issue then. I assume the way you access
>>>>>> each host is via an IP assigned to an OVS bridge or an interface that
>>>>>> somehow depends on OVS?
>>>>>>
>>>>>> On Apr 28, 2017 12:04, "Gustavo Randich" <gustavo.rand...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Kevin, we are using the default listen address of loopback
>>>>>>> interface:
>>>>>>>
>>>>>>> # grep -r of_listen_address /etc/neutron
>>>>>>> /etc/neutron/plugins/ml2/openvswitch_agent.ini:#of_listen_address =
>>>>>>> 127.0.0.1
>>>>>>>
>>>>>>>
>>>>>>> tcp/127.0.0.1:6640 -> ovsdb-server /etc/openvswitch/conf.db
>>>>>>> -vc