Re: [Openstack-operators] LBaaS V2 on multi-node Neutron Liberty

[Ihar Hrachyshka]

On Fri, Dec 30, 2016 at 8:53 AM, William Josefsson <
william.josef...@gmail.com> wrote:

> Hi everyone, I need some advice on installing LBaaS on my Liberty
> (CentOS7) deployment. I have a multi host deployment with 2 Networking
> nodes running all my agents (L3, dhcp, .. )
>
> I have reviewed this [1] documentation, and I notice there is LBaaS
> agent based V2, which is the current version, should I install this
> [2] 'yum install openstack-neutron-lbaas' package only, or should I
> install 'yum install haproxy openstack-neutron-lbaas' on my network
> nodes?
>
>
If you plan to use haproxy namespace driver, then you should install
'haproxy' package yourself. As for 'openstack-neutron-lbaas' package, I
believe it should be installed on both controller as well as network nodes.


> I have two Networking nodes, should proceed and install the agent the
> same way on both, and then just verify with neutron agent-list?
>
> This [1] Neutron documentation also mentions: "neutron-db-manage
> --service lbaas upgrade head".
> Can anyone please share what kind of modifications will occur to my DB
> and if it will affect any of my existing data with networks, subnets,
> ports etc in a harmful way, or is this a safe command to run?


This should be safe to apply. It will create some new tables in the neutron
database for LBaaS service plugin to use.

Ihar
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] Operator feedback for Neutron clarifications from Barcelona

[Ihar Hrachyshka]

Clayton O'Neill  wrote:


I was the person with issues with 10's of l3-agents not working
properly on Liberty.  With about 100 l3-agents we had issues with them
just falling over without anything going on.  We moved to 20 l3-agents
and with that config we've had good luck unless you restart all of
them at the same time.  My understanding is that in Liberty there is a
single thread per neutrons-server (we run 3) that handles agent
traffic and that this was supposed to be fixed in Mitaka and newer,
but I haven't seen that confirmed.


The patch that implemented separate workers for agent state reports is:  
https://review.openstack.org/#/c/233605/ and was indeed included in Mitaka+.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [neutron] upgrade from liberty to mitaka

[Ihar Hrachyshka]

Richard Woo  wrote:


Ihar,

Thanks for your reply, seems like the fwaas is install when installed  
neutron server:


root@controller-01:~# dpkg -l | grep neutron
ii  neutron-common
2:8.2.0-0ubuntu1~cloud0   all  Neutron is a virtual  
network service for Openstack - common
ii  neutron-plugin-ml2
2:8.2.0-0ubuntu1~cloud0   all  Neutron is a virtual  
network service for Openstack - ML2 plugin
ii  neutron-server
2:8.2.0-0ubuntu1~cloud0   all  Neutron is a virtual  
network service for Openstack - server
ii  python-neutron
2:8.2.0-0ubuntu1~cloud0   all  Neutron is a virtual  
network service for Openstack - Python library
ii  python-neutron-fwaas  
1:7.1.1-0ubuntu1~cloud0   all  Firewall-as-a-Service  
driver for OpenStack Neutron
ii  python-neutron-lib
0.0.2-2~cloud0all  Neutron shared  
routines and utilities - Python 2.7
ii  python-neutronclient  
1:3.1.0-0ubuntu1~cloud0   all  client API library for  
Neutron

root@controller-01:~# apt-get remove python-neutron-fwaas
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer  
required:

  ipset libipset3 libmnl0 python-neutron python-neutron-lib python-openvswitch
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  neutron-common neutron-plugin-ml2 neutron-server python-neutron-fwaas
0 upgraded, 0 newly installed, 4 to remove and 30 not upgraded.
After this operation, 1,149 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
root@controller-01:~#


I know you solved your issue already, but I just want to comment on the  
packaging behaviour you see.


I don’t believe that your distribution set dependencies right: you should  
be able to install your system without fwaas code at all, it’s meant to be  
a plugin, not a dependency for neutron-server.


Now, it may be the case that due to defaults chosen by debian packages  
default configuration files for the neutron-server service do not work  
unless you also pull in neutron-fwaas. Maybe it’s something historical. But  
ideally, you should be able to run a bare neutron-server with just the code  
from openstack/neutron repo.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [neutron] upgrade from liberty to mitaka

[Ihar Hrachyshka]

Richard Woo  wrote:


Hello, folks,

I have a small cluster running openstack liberty, today I am starting to  
upgrading to Mitaka.


I am having a problem to launch l3 agent on network node.

I got the following error:
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward  
compatibility. SIGUSR1 will no longer be registered in a future release,  
so please use SIGUSR2 to generate reports.
Option "verbose" from group "DEFAULT" is deprecated for removal.  Its  
value may be silently ignored in the future.
2016-10-15 22:13:20.800 24466 INFO neutron.common.config [-] Logging  
enabled!
2016-10-15 22:13:20.801 24466 INFO neutron.common.config [-]  
/usr/bin/neutron-l3-agent version 8.2.0
2016-10-15 22:13:20.801 24466 DEBUG neutron.common.config [-] command  
line: /usr/bin/neutron-l3-agent --config-file=/etc/neutron/neutron.conf  
--config-file=/etc/neutron/l3_agent.ini  
--log-file=/var/log/neutron/l3-agent.log setup_logging  
/usr/lib/python2.7/dist-packages/neutron/common/config.py:269
2016-10-15 22:13:20.923 24466 DEBUG oslo_messaging._drivers.amqpdriver  
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] CALL msg_id:  
0b6eb35b95ec4edca605b2d3c6a76d37 exchange 'neutron' topic 'q-l3-plugin'  
_send  
/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:454
/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py:187:  
RuntimeWarning: You have iterated over the result of  
pkg_resources.parse_version. This is a legacy behavior which is  
inconsistent with the new version class introduced in setuptools 8.0. In  
most cases, conversion to a tuple is unnecessary. For comparison of  
versions, sort the Version instances directly. If you have another use  
case requiring the tuple, please file a bug with the setuptools project  
describing that need.

  stacklevel=1,
2016-10-15 22:13:20.951 24466 DEBUG oslo_messaging._drivers.amqpdriver  
[-] received reply msg_id: 0b6eb35b95ec4edca605b2d3c6a76d37 __call__  
/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:302
2016-10-15 22:13:20.953 24466 DEBUG neutron.callbacks.manager  
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Subscribe: after_router_added at 0x7fa2b1a82050> router after_create subscribe  
/usr/lib/python2.7/dist-packages/neutron/callbacks/manager.py:41
2016-10-15 22:13:20.954 24466 DEBUG neutron.callbacks.manager  
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Subscribe: before_router_removed at 0x7fa2b1a86230> router before_delete subscribe  
/usr/lib/python2.7/dist-packages/neutron/callbacks/manager.py:41
2016-10-15 22:13:20.955 24466 DEBUG  
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent  
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Initializing  
firewall agent __init__  
/usr/lib/python2.7/dist-packages/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py:55
2016-10-15 22:13:20.956 24466 CRITICAL neutron  
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] AttributeError:  
'module' object has no attribute 'FIREWALL_PLUGIN'
2016-10-15 22:13:20.956 24466 ERROR neutron Traceback (most recent call  
last):
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/bin/neutron-l3-agent", line 10, in 

2016-10-15 22:13:20.956 24466 ERROR neutron sys.exit(main())
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/lib/python2.7/dist-packages/neutron/cmd/eventlet/agents/l3.py",  
line 17, in main

2016-10-15 22:13:20.956 24466 ERROR neutron l3_agent.main()
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py", line 57, in  
main

2016-10-15 22:13:20.956 24466 ERROR neutron manager=manager)
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 331, in create
2016-10-15 22:13:20.956 24466 ERROR neutron  
periodic_fuzzy_delay=periodic_fuzzy_delay)
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 264, in  
__init__
2016-10-15 22:13:20.956 24466 ERROR neutron self.manager =  
manager_class(host=host, *args, **kwargs)
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/lib/python2.7/dist-packages/neutron/agent/l3/agent.py", line 635,  
in __init__
2016-10-15 22:13:20.956 24466 ERROR neutron  
super(L3NATAgentWithStateReport, self).__init__(host=host, conf=conf)
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/lib/python2.7/dist-packages/neutron/agent/l3/agent.py", line 243,  
in __init__
2016-10-15 22:13:20.956 24466 ERROR neutron super(L3NATAgent,  
self).__init__(conf=self.conf)
2016-10-15 22:13:20.956 24466 ERROR neutron   File  
"/usr/lib/python2.7/dist-packages/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py",  
line 77, in __init__
2016-10-15 22:13:20.956 24466 ERROR neutron self.fwplugin_rpc =  
FWaaSL3PluginApi(topics.FIREWALL_PLUGIN,

Re: [Openstack-operators] [Puppet][Neutron] Mitaka ML2/OVS config file mismatch

[Ihar Hrachyshka]

Jonathan D. Proulx <j...@csail.mit.edu> wrote:


On Thu, Sep 01, 2016 at 01:50:40PM +0200, Ihar Hrachyshka wrote:

:ml2_conf.ini is to be loaded by neutron-server only. The agent should
:not load it, instead relying on openvswitch_agent.ini file for
:anything agent specific. If for some reason puppet does put agent
:configuration options into ml2_conf.ini, it does it wrong.

I've been wondering what the intended distiction between those conf
files was since ml2 came out thanks...

Given your email address I doubt you'll have much sympathy for this :)
but Ubuntu previously (as of Kilo at least I don't have a Liberty to
look at right now) seems to have used ml2_conf.ini for both in their
packaged start up files.


Yeah, I know. It took Debian and Ubuntu a while to fix the packaging. Part  
of the problem was, neutron shipped openvswitch_plugin.ini file instead of  
openvswitch_agent.ini to be loaded by the agent, so deb folks were misled  
by the naming, because plugins are neutron-server things, not agent things.  
This was fixed only recently in neutron, so now that new naming is  
self-explanatory, distributions adopted the correct approach.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Puppet][Neutron] Mitaka ML2/OVS config file mismatch

[Ihar Hrachyshka]

Jonathan D. Proulx  wrote:


Hi All,

I'm woking on testing my jump from Kilo->Mitaka

Using puppet on ubuntu 14.04 with cloud archive packages.

Puppet seems to be writing the ml2/ovs configs into
/etc/neutron/plugins/ml2/ml2_conf.ini

which is where the previously were, so I've spent a few day going
around on this thinking I'd missed adding a newly reqired bit or
something ...

But /etc/init/neutron-openvswitch-agent.conf doesn't reference this
file, it uses:

--config-file=/etc/neutron/neutron.conf \
--config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini

I must have done something weird since lots of people must have used
puppet on mitaka by now.  Anyone know what?


ml2_conf.ini is to be loaded by neutron-server only. The agent should not  
load it, instead relying on openvswitch_agent.ini file for anything agent  
specific. If for some reason puppet does put agent configuration options  
into ml2_conf.ini, it does it wrong.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] can we lock RPC version with upgrade_levels on neutron-openvswitch-agent ?

[Ihar Hrachyshka]

(Adding back ops@)

Michał Jastrzębski  wrote:


Yes, but it's a bit different. Difference being if you're doing it
right, you can keep nova running during upgrade. Can't say the same
for neutron.


There is ongoing work to make it possible. The way it looks now, it will  
take Ocata the least. Till that happy time, you should indeed all  
controllers before upgrading database.


That said, you can still run your agents while you upgrade your controller  
nodes. Once you are done with controllers, you can upgrade one remaining  
node running agents at a time.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] can we lock RPC version with upgrade_levels on neutron-openvswitch-agent ?

[Ihar Hrachyshka]

Steven Dake (stdake)  wrote:


Saverio,

We sorted this out in Kolla with the Nova community defining the upgrade
process.  Michal (cc) led that work in the Kolla community.  I believe you
need to upgrade compute ahead of other services so the upgrade works
properly, but I'm not certain.


The last time I heard, Nova required controller first, then computes:

http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/

(Note the order of steps 3 and 5.)

Same is true for neutron: you upgrade controller, then compute/network node  
agents, never the other way around.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] can we lock RPC version with upgrade_levels on neutron-openvswitch-agent ?

[Ihar Hrachyshka]

Saverio Proto  wrote:


Hello,

we are doing the upgrade Kilo to Liberty pet by pet.

We already upgraded successfully Keystone and Glance.

Now I started the Nova pet upgrade. For the controller node it was ok.

As soon as I upgraded the compute nodes I had a problem with neutron.

I can't lock the neutron-openvswitch-agent to and earlier RPC version,
so I get in my logs:

RemoteError: Remote error: UnsupportedVersion Endpoint does not
support RPC version 1.5. Attempted method:
get_devices_details_list_and_failed_devices

Do I must upgrade also the neutron server di Liberty before upgrading
the compute nodes ?

In nova.conf there are the [upgrade_levels]. Looks like these are
ignored by the neutron-openvswitch-agent. There is not any similar
settings in the neutron.conf ?


Neutron so far does not support RPC pinning. There is ongoing preparatory  
work running in Newton to allow to take more control of RPC payload on the  
wire, though the path taken will probably differ from Nova implementation  
(providing multiple RPC payload versions depending on agents running in the  
cluster, instead of downgrading all of them to the lowest common version.)  
The work will take a while to shape.


As for your particular problem, it seems like you run Kilo Neutron  
controller while Liberty OVS agents? That’s not going to work. The only  
upgrade order supported is: first server, then agents:


http://docs.openstack.org/developer/neutron/devref/upgrade.html#rolling-upgrade

If you still have issues once you adopt the correct upgrade order in your  
procedure, please comment.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [neutron][horizon][announce] Introducing DON

[Ihar Hrachyshka]

Amit Kumar Saha (amisaha)  wrote:


Hi,

We would like to introduce the community to a new Python based project  
called DON – Diagnosing OpenStack Networking. More details about the  
project can be found at https://github.com/openstack/python-don.


DON, written primarily in Python, and available as a dashboard in  
OpenStack Horizon, Libery release, is a network analysis and diagnostic  
system and provides a completely automated service for verifying and  
diagnosing the networking functionality provided by OVS. The genesis of  
this idea was presented at the Vancouver summit, May 2015. Hopefully the  
community will find this project interesting and will give us valuable  
feedback.


Amit,

neutron team currently works on defining a new diagnostics API:  
https://review.openstack.org/#/c/308973/


Please work with the community on API definition, and later, on backend  
specific implementation of desired checks.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Neutron database upgrade kilo-liberty and parallel Alembic migration branches

[Ihar Hrachyshka]

> On 01 Jun 2016, at 14:49, Saverio Proto  wrote:
> 
> Hello,
> 
> reading this documentation page:
> 
> http://docs.openstack.org/mitaka/networking-guide/migration-neutron-database.html
> 
> I dont get what means having two parallel migration branches.
> 
> Do you have to choose one of the branches ? If yes how ?
> 
> 
> Or it just means that some operations can be safely run when Neutron
> Server API is running, (e.g.
> neutron-db-manage upgrade --expand)
> 
> while other operations (e.g. neutron-db-manage upgrade --contract)
> require the Neutron Server to be stopped ??
> 

The latter. If you think the documentation is deficient, please propose a patch 
that would clarify that.

> Anyone has some upgrade notes to share that can clarify the procedure ?
> 
> Thank you
> 
> Saverio
> 
> ___
> 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] Neutron upgrade from Kilo to Mitaka

[Ihar Hrachyshka]

Akshik, please include the address of the original mailing list in your replies.

> On 19 May 2016, at 22:17, Akshik dbk <aks...@outlook.com> wrote:
> 
> Hi Ihar,
> 
> Thanks for the response, 
> 
> yes, Fuel does not run in containers
> 
> correct me if I’m wrong, so upgrading neutron dependencies would have impact 
> on other services as well?  
> 

If you colocate neutron (mitaka) services with other (kilo) services on the 
same node, and if they are not isolated in a container, they share runtime 
environment, including their python dependencies. I am not even sure your 
packaging system will allow you to install such a mixed environment. But if it 
will, all bets are off on whether it will work in any way since now kilo 
services will use (some) mitaka dependencies, which is definitely not supported 
by upstream.

> 
> From: Ihar Hrachyshka <ihrac...@redhat.com>
> Date: 20 May 2016 at 1:24:31 AM
> To: Akshik dbk <aks...@outlook.com>
> CC: openstack-operators@lists.openstack.org 
> <openstack-operators@lists.openstack.org>
> Subject:  Re: [Openstack-operators] Neutron upgrade from Kilo to Mitaka 
> 
>> 
>> > On 19 May 2016, at 21:43, Akshik dbk <aks...@outlook.com> wrote: 
>> > 
>> >> Hi, 
>> >> 
>> >> I’m have a Fuel 7.0 based environment [kilo], wanted to upgrade the 
>> >> Neutron to Mitaka version. is it possible to upgrade Neutron alone to the 
>> >> Mitaka version. 
>> 
>> Developers don’t make any special effort to support mixed environments that 
>> span more than +1 release. It may or may not work. 
>> 
>> Even then the assumption is that your neutron services are using a runtime 
>> environment that is isolated from other (kilo) services. I think Fuel does 
>> not install services in containers, so they would need to run on separate 
>> nodes. 
>> 
>> Ihar


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Neutron upgrade from Kilo to Mitaka

[Ihar Hrachyshka]

> On 19 May 2016, at 21:43, Akshik dbk  wrote:
> 
>> Hi,
>> 
>> I’m have a Fuel 7.0 based environment [kilo], wanted to upgrade the Neutron 
>> to Mitaka version. is it possible to upgrade Neutron alone to the Mitaka 
>> version.

Developers don’t make any special effort to support mixed environments that 
span more than +1 release. It may or may not work.

Even then the assumption is that your neutron services are using a runtime 
environment that is isolated from other (kilo) services. I think Fuel does not 
install services in containers, so they would need to run on separate nodes.

Ihar
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators][neutron][telemetry] manual creation of metering labels and rules

[Ihar Hrachyshka]

Rubab Syed  wrote:


Hi folks,

I'm trying to understand the metering of network traffic at l3 level with  
neutron-metering-agent [1]. In order to meter the traffic, we have to  
create explicit labels and rules. When we have a very large setup, is  
this still handled manually? Do we have some kind of automation script  
that detects all the networks attached to all routers of all the tenants  
and creates labels and rules accordingly? All traffic in case we want to  
monitor per interface bandwidth through ceilometer/monasca.


That kind of orchestration would be out of neutron scope. I assume other  
projects should be utilized for what you want to achieve, like Heat.


Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron] network issue with separate subnets under single public-network

[Ihar Hrachyshka]

Rahul Sharma  wrote:


Hi All,

I am trying to fix a network-issue in our environment and would like to  
know some suggestions on how I can achieve it. Here is the issue:-


I have two subnets(10.10.10.0/25 and 10.10.10.128/26) with separate  
gateways for each subnet and I expose the whole to end users as public  
network. Diagram1 attached lists the configuration done on horizon.


The setup works fine for some users but it starts failing for the others.  
The issue occurs when the router connecting to the public network gets  
gateway in one subnet and the floating-ip gets allocated from the second  
subnet. Looking at the routes configured within the router, it seems that  
the router is unable to route the packets to the correct gateway. Its  
sending packets to a wrong gateway which will drop packets as they don't  
belong to the right subnet.


# ip netns exec qrouter-8790f703-85ed-44e4-7a96-251b26572457 ip r
default via 10.10.10.1 dev qg-ee39897d-d3 <-- default Gateway
10.10.10.0/25 dev qg-ee39897d-d3  proto kernel  scope link  src  
10.10.10.115 <--- Gateway for Router

10.10.10.128/26 dev qg-ee39897d-d3  scope link
192.168.10.0/24 dev qr-0c9694f8-9d  proto kernel  scope link  src  
192.168.10.1


However, one of the floating-ip allocated in 10.10.10.168 which lies in  
other subnet. This router will send packets from 10.10.10.128/26subnet to  
10.10.10.1 and they will get dropped.


# ip netns exec qrouter-8790f703-85ed-44e4-7a96-251b26572457 ip addr

165: qg-7523dad9-a7: mtu 1500 qdisc noqueue state UNKNOWN
link/ether fa:16:3e:a3:8a:61 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.115/25 brd 10.10.10.127 scope global qg-ee39897d-d3 <--- 
Gateway for router
   valid_lft forever preferred_lft forever
inet 10.10.10.72/32 brd 10.10.10.72 scope global qg-ee39897d-d3  <--- 
floating ip in subnet1 (no issues)
   valid_lft forever preferred_lft forever
inet 10.10.10.168/32 brd 10.10.10.168 scope global qg-ee39897d-d3 <--- 
floating ip in subnet2 (issues)
   valid_lft forever preferred_lft forever

I went through one comment against a bug:  
https://bugs.launchpad.net/neutron/+bug/1312467/comments/12


This is something on the same lines. Is there any solution other than  
deleting the public network and exposing it as two separate public  
networks because I don't have access to the physical routers/switches and  
cannot merge the two subnets into one. Any pointers would be really  
helpful.


[Also commented on the bug.]

I believe the setup with two independent gateways on the same NIC is not  
supported by L3 agent, though from API perspective everything should be  
available already.


I suggest you report the use case as a new RFE.

Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Openstack liberty neutron vmware nsx plugin

[Ihar Hrachyshka]

Ignazio Cassano  wrote:


Hi all,
I am going to configure openstack liberty with vmware nsx.
I am using centos 7 controller but I cannot find the neutron plugin  
package for

vmware nsx .
It seems to exist in kilo but not in liberty repositories.
Regards
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


I guess you want to ask in rdo-list instead.

https://www.redhat.com/mailman/listinfo/rdo-list

Ihar

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [Neutron] Allowing DNS suffix to be set per subnet (at least per tenant)

[Ihar Hrachyshka]

> On 04 Sep 2015, at 08:14, Daniel Comnea  wrote:
> 
> Kevin,
> 
> am i right in saying that the merge above was packaged into Liberty ?
> 
> Any chance to be ported to Juno?
> 

There is no chance a new feature will be backported to any stable branch, even 
Kilo. At least in upstream.

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Mapping of routers and urls in Neutron API

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sounds like a question for openstack-dev@ actually...

On 07/02/2015 02:08 AM, Rajat Nagpal wrote:
 Hi guys,
 
 I want to add a new method i.e add some extension method in the
 neutron service and want to call this method from the command line
 interface.The method would actually show the quota usage(absolute
 limits) just like it shows in nova usage.
 
 Now I created a new command but I am not able to call the required 
 method.I am entangled in how the request is being converted to
 routes and how the controller and the specific action is being
 called and how the mapping is being done.In the following logs, the
 request url is being converted to some actions and controllers I am
 specifically interested in how this is happening.

You may be interested in checking:

https://github.com/openstack/neutron/blob/master/neutron/api/v2/base.py#
L106

And overall the whole file. That's where API requests map to plugin
methods.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVnltMAAoJEC5aWaUY1u573sUIANjrKCt8fDJ6iICl9gUdmHoY
IBnowofIpD5E6Y2ekFvEBKoZYZNEFVjc+7P/95KUEIEGlBh98u7HB9NtsFMFcUv4
Ux+s+FipIEooa0lVK1Jo0LQb6XktTlVyoOl03D0ASkJYMQqcg2Oin2+C/r54L1/1
x16nI+EtVg4/dv2TJQ/qCxEvPT3l7NVZgElw+TbQ4Z8iHQTY6vC0umP0tKbLtwut
CbvJhYmEvHiF2j84r+3yrL1mZCBXRYUDJpHYbqpr0e+PZXmZsi1H/7y4qokYS7Lq
7XELOnPnORK+7Yhk4itUo5821BGEGsSSDSdcSv2Su2aJb1bSXNL4cm0/QmWV1dY=
=UX/k
-END PGP SIGNATURE-

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [oslo][all] openstack context change for user_name and project_name

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi operators/devs,

I have a patch [1] for oslo.context (the library that is used by most
projects to create context objects to pass around) that introduces the
following change for the context:

user_identity is now constructed from user and project names instead
of user-id and project-id, in case names are available.

The change introduces a slight incompatibility in context aware logs
[2] (controlled by oslo.log library). Specifically, before the change,
those log messages looked like:

date time DEBUG python-path [req-283bde30-6f3d-4f20-83c9-17c3185e2b88
049f3e6a87a649b288bed5543a052dd3 231bb797af67435fa6603282aa461c9a - -
- -] log-message

where 049f3e6a87a649b288bed5543a052dd3 is user-id and
231bb797af67435fa6603282aa461c9a is projects.

While after the change, the same log message would look like:

date time DEBUG python-path [req-283bde30-6f3d-4f20-83c9-17c3185e2b88
username projectname - - -] log-message

The incompatibility would show up only if someone relies on those
fields to represent user and project IDs.

The change is to avoid the need for devstack to override oslo.log for
particular services [3] to get those user and project names, so that
we consume the default format string from oslo.log everywhere and make
our logs consistent and probably more user friendly (it's probably
easier to read user name than user id in your logs). Also we would
avoid bugs like [4] where we miss valuable log info because of old,
inadequate configuration.

The question is: does anyone know of any piece of software or an
operator who relies on particular format of those fields? Does anyone
think that such a change should not go in?

[1]: https://review.openstack.org/#/c/176333/1/oslo_context/context.py
[2]:
http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/_options.
py#n100
[3]: https://review.openstack.org/#/c/172508/
[4]: https://bugs.launchpad.net/neutron/+bug/1433687

Thanks for your consideration
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVduzBAAoJEC5aWaUY1u577E8H/2MtiFtRRal2KEj23p9Uzt68
Lk3xgAZxr++txM+n8qrSlU24544QMFn9tDXxW7A69lKpHRnyKnB2wnLnC5DCLmFq
LfXgkUZf5Ea+VF6fMNGMYfZT7ljDhsypNqjt49QIAfgZ6pHCLy4JatqYAjte3uus
g5+bt3RoQTwLOPZWU89xsFLkZVpfF31ex/UAkpmo7nvtwsahrXXeJ6KrJMLpA8BW
MELsLbIhuF+pSzhBPyT5S8inQGj5ohtaQU5ybKdCMw+WgoiwqDfGjLOSxSs/gpB9
CSm/grUKhj2dLJkMcwwN+ufuQejVs2p247mBMsYJtXN0KV9JKjdDbKonNTlGhrk=
=H24e
-END PGP SIGNATURE-

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Multi-host network with NEUTRON in ICEHOUSE version

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/09/2015 02:45 PM, car.cuevas wrote:
 Thanks very much for your answer Anne, so now I am thinking what
 to do with this because I know that the nova-network will be
 deprecated (if it isn't yet) so to install from the beginning
 something which is deprecated (or nearly) I guess it's not good
 idea.
 
 Do you know if in Juno or Kilo is already implemented the Neutron 
 with multi-host capabilities?
 
 Once more many thanks for your help !
 
 Carlos
 

You may be interested in distributed router (DVR):
http://specs.openstack.org/openstack/neutron-specs/specs/juno/neutron-ov
s-dvr.html

Or L3 HA:
http://specs.openstack.org/openstack/neutron-specs/specs/juno/l3-high-av
ailability.html

Note that as of Liberty, they are mutually exclusive, so it depends on
what your priorities for multi host setup are.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVdubKAAoJEC5aWaUY1u570UUIALmf942F02a/5s3gj41L4tqt
bGDFziRyVG5qHqN3G+Rkxf/VNuL3WEvA1ssiy2GjjBw9CM/qBK8c4mlF1dCt5+Xi
1czNP6W+vFDNr0HRUvFErcZgspzq9TmfjaP2VYxGVGiDKHY+ZSsGMEMi1Fds0gYd
hH68pm9yjq1Vnu5dYAeRBkTNiVW7FK4EGSTQ7cu2Y6gLdeQRqcPfwQ3+gci5Igxp
GcmgHdQl9PRm7qbCrPnSfJUPh5/XZvMkk205PYfsxIm/C3IU47GpF2PIZ3CEPA7k
6Qv3JD3UmYW2KhcFHP6x62vVVPWLCBBKjLYfl1zDIjOG8ZhfjzM8pxAm9j6nd9E=
=OS/C
-END PGP SIGNATURE-

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators