Re: [Openstack] [OpenStack][Compute-Neutron] Is it possible to create flat network from different NICs

[Slawomir Kaplonski]

Hi,

Yes, that should be possible. You can create 4 bridges on compute node and add 
all of them to bridge_mappings config option.
Then You can create 4 networks with different physical_network for each of them 
and agent will know which bridge should be used for ports from each network.
It is described e.g. in [1].

[1] 
https://ask.openstack.org/en/question/94206/how-to-understand-the-bridge_mappings/?answer=94230#post-id-94230

> Wiadomość napisana przez Soheil Pourbafrani  w dniu 
> 21.11.2018, o godz. 12:08:
> 
> Hi,
> 
> I installed OpenStack on One node (for test) and creating a flat external 
> network I could connect VMs to the provider network (internet).
> 
> In the production environment, we have 4 NIC on each server and each server 
> (compute node) will run 4 instances. My question is, is it possible to create 
> a separate external network based on each NIC (so 4 external networks) and 
> run each instance using one of them?
> ___
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


___
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] neutron python client stopped working

[Slawomir Kaplonski]

Hi,

Please try newest version from master branch. All works fine for me with it:

[09:15:53] vagrant@devstack-ubuntu-ovs ~ $ neutron net-list
neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.
+--+-+--+--+
| id   | name| tenant_id
| subnets  |
+--+-+--+--+
| 78e44156-4a0d-47d1-902f-91a5bab0a2f7 | private | 
e9ded0c4ea2a48ed98d77a4048176b92 | b470007a-00c9-4953-bbf2-6ef8337bbaba 
fddb:30c8:695d::/64 |
|  | |  
| b536f540-6e40-4e37-adf3-deb46733550f 10.0.0.0/26 |
| a95c7928-003b-4be5-b623-e8c608646a93 | public  | 
0b9809c9cadf44779b99680baabdf981 | e9fecfad-97b4-4998-b3f5-9f0c1f570236 
10.10.0.128/25  |
|  | |  
| be9ba7f0-3931-41e9-8492-b207a10db930 2001:db8::/64   |
+--+-+--+--+
[09:15:56] vagrant@devstack-ubuntu-ovs ~ $ openstack network list
+--+-++
| ID   | Name| Subnets  
  |
+--+-++
| 78e44156-4a0d-47d1-902f-91a5bab0a2f7 | private | 
b470007a-00c9-4953-bbf2-6ef8337bbaba, b536f540-6e40-4e37-adf3-deb46733550f |
| a95c7928-003b-4be5-b623-e8c608646a93 | public  | 
be9ba7f0-3931-41e9-8492-b207a10db930, e9fecfad-97b4-4998-b3f5-9f0c1f570236 |
+--+-++


> Wiadomość napisana przez Manuel Sopena Ballesteros  
> w dniu 15.11.2018, o godz. 08:52:
> 
> Hi,
>  
> This looks like a stupid thing but I can’t make it to work. For some reason I 
> can’t run any openstack cli command related to neutron, however using neutron 
> cli seems to work so I am guessing this is just affecting the the python 
> client. I tried pip uninstall and install it again with no success. I am 
> using Rocky deployed through kolla-ansible
>  
> [root@openstack-deployment ~]# pip show python-neutronclient
> Name: python-neutronclient
> Version: 6.10.0
> Summary: CLI and Client Library for OpenStack Networking
> Home-page: https://docs.openstack.org/python-neutronclient/latest/
> Author: OpenStack Networking Project
> Author-email: openstack-...@lists.openstack.org
> License: UNKNOWN
> Location: /usr/lib/python2.7/site-packages
> Requires: osc-lib, Babel, oslo.i18n, oslo.utils, oslo.serialization, 
> requests, netaddr, iso8601, python-keystoneclient, cliff, keystoneauth1, 
> oslo.log, os-client-config, six, pbr, debtcollector, simplejson
> Required-by:
> [root@openstack-deployment ~]# openstack server list
> +--+++---+-+---+
> | ID   | Name   | Status | Networks   
>| Image   | Flavor|
> +--+++---+-+---+
> | 6e079312-b067-4cf0-870a-c6e452b57d5c | test_gpu_small | ACTIVE | 
> private=192.168.1.108, 129.94.120.182 | ubuntu18.04 | gpu.small |
> | bd977544-a088-4365-8bed-128daca1e820 | test_gpu_large | ACTIVE | 
> private=192.168.1.117, 129.94.120.186 | ubuntu18.04 | gpu.large |
> | db439705-5b57-4a05-9bc3-74ff0f88bf87 | test   | ACTIVE | 
> private=192.168.1.120, 129.94.120.181 | cirros  | m1.tiny   |
> +--+++---+-+---+
> [root@openstack-deployment ~]# openstack network list
> __init__() got an unexpected keyword argument 'retriable_status_codes'
> [root@openstack-deployment ~]# openstack subnet list
> __init__() got an unexpected keyword argument 'retriable_status_codes'
> [root@openstack-deployment ~]# openstack port list
> __init__() got an unexpected keyword argument 'retriable_status_codes'
> [root@openstack-deployment ~]# neutron port-list
> neutron CLI is deprecated and will be removed in the future. Use openstack 
> CLI instead.
> +--+--+--+---+---

Re: [Openstack] [openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train

[Slawomir Kaplonski]

Hi,

I think it was published, see 
http://lists.openstack.org/pipermail/openstack/2018-November/047172.html

> Wiadomość napisana przez Jeremy Freudberg  w dniu 
> 14.11.2018, o godz. 06:12:
> 
> Hey Tony,
> 
> What's the reason for the results of the poll not being public?
> 
> Thanks,
> Jeremy
> On Tue, Nov 13, 2018 at 11:52 PM Tony Breeds  wrote:
>> 
>> 
>> Hi everybody!
>> 
>> As the subject reads, the "T" release of OpenStack is officially
>> "Train".  Unlike recent choices Train was the popular choice so
>> congrats!
>> 
>> Thanks to everybody who participated and help with the naming process.
>> 
>> Lets make OpenStack Train the release so awesome that people can't help
>> but choo-choo-choose to run it[1]!
>> 
>> 
>> Yours Tony.
>> [1] Too soon? Too much?
>> __
>> OpenStack Development Mailing 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


___
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][Neutron] How to configure for external network

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez Soheil Pourbafrani  w dniu 
> 04.11.2018, o godz. 11:10:
> 
> Thanks, 
> 
> Actually, I created a vxlan network and define the internal network and 
> external network in range of my network provider, 192.168.0.1. I create a 
> router and interface and lunch an instance with an internal network that has 
> floating IP, too.

As I said before, Your external network has to be vlan or flat network. Vxlan 
network can be used only as tenant network. Packets from such network can’t go 
„outside” to Your provider’s network and it’s not matter of IP addresses used 
in network.

> 
> From the controller node I can ping the instance using floating IP: "ip netns 
> exec qdhcp-9691cdb8-56f3-44b6-b501-4678eceb3866 ping 192.168.0.4", but the 
> instance is not accessible in the external network and the command ping 
> 192.168.0.4 failed!
> 
> What is the problem?
> 
> 
> On Sun, Nov 4, 2018 at 12:52 PM Slawomir Kaplonski  
> wrote:
> Hi,
> 
> For external network You should use flat or vlan type - which one of them, 
> depends on Your provider’s configuration - if You should use some VLAN, You 
> need vlan network.
> Vxlan networks can be only used for tenant networks.
> 
> > Wiadomość napisana przez Soheil Pourbafrani  w dniu 
> > 04.11.2018, o godz. 07:22:
> > 
> > Hi,
> > 
> > I installed PackStack on two nodes, one as Controller and Network, the 
> > other as the Compute Node. After installation, I created a new br-ex 
> > interface and I did OVS settings. I also define two internal and external 
> > network (flat) and router and interfaces. 
> > The internal network range IP is not a valid range and for the test, I set 
> > it in 10.10.0.0/24. I can lunch instances using internal network and VMs 
> > can connect to each other using that.
> > The external range IP is the same as our Provider range IP (the range that 
> > our devices get when connecting to the internet). But lunching instances 
> > using the external network it can't connect to the internet or ping other 
> > devices in the network (proper security groups are set). IMy question was, 
> > is there any tutorial for configuring the network in two nodes so VMs can 
> > connect to the internet? What kind of Network does it need? flat, vlan or 
> > vxlan?
> > 
> > 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
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat


___
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][Neutron] How to configure for external network

[Slawomir Kaplonski]

Hi,

For external network You should use flat or vlan type - which one of them, 
depends on Your provider’s configuration - if You should use some VLAN, You 
need vlan network.
Vxlan networks can be only used for tenant networks.

> Wiadomość napisana przez Soheil Pourbafrani  w dniu 
> 04.11.2018, o godz. 07:22:
> 
> Hi,
> 
> I installed PackStack on two nodes, one as Controller and Network, the other 
> as the Compute Node. After installation, I created a new br-ex interface and 
> I did OVS settings. I also define two internal and external network (flat) 
> and router and interfaces. 
> The internal network range IP is not a valid range and for the test, I set it 
> in 10.10.0.0/24. I can lunch instances using internal network and VMs can 
> connect to each other using that.
> The external range IP is the same as our Provider range IP (the range that 
> our devices get when connecting to the internet). But lunching instances 
> using the external network it can't connect to the internet or ping other 
> devices in the network (proper security groups are set). IMy question was, is 
> there any tutorial for configuring the network in two nodes so VMs can 
> connect to the internet? What kind of Network does it need? flat, vlan or 
> vxlan?
> 
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


___
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] To create Network after install manually

[Slawomir Kaplonski]

Hi,

What is this „OpenStack GUI” which You are using? Is it Horizon? From log which 
You sent it only looks that Your request wasn’t done in proper format. Maybe 
Your client is doing something wrong or maybe You are sending encrypted request 
to Neutron endpoint configured as not encrypted one?

> Wiadomość napisana przez Kevin Kwon  w dniu 23.06.2018, o 
> godz. 23:01:
> 
> 
> Dear All!
> 
> HI..
> I have installed the Openstack  with Controller-Compute Node by manually with 
> Provider Network.
> 
> when i tried to create the network on Openstack GUI, I couldn't create it 
> because below error messages.
> 
> would you please let me know how can i create network and check status?
> 
> 
> 
> 
> 2018-06-24 05:55:43.627 2763 INFO neutron.wsgi 
> [req-ebd9f116-16c8-4c6e-9b7e-1c30cda4c240 ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] 192.168.100.101 "GET 
> /v2.0/availability_zones HTTP/1.1" status: 200  len: 285 time: 0.0281010
> 2018-06-24 05:55:43.657 2761 INFO neutron.wsgi 
> [req-30b4b825-1e4f-48b9-a720-e31e0da62688 ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] 192.168.100.101 "GET 
> /v2.0/availability_zones HTTP/1.1" status: 200  len: 285 time: 0.0219860
> 2018-06-24 05:55:43.697 2761 INFO neutron.wsgi 
> [req-20a1c897-a416-446e-9138-d1381e416e9f ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] 192.168.100.101 "GET 
> /v2.0/subnetpools HTTP/1.1" status: 200  len: 216 time: 0.0319090
> 2018-06-24 05:55:43.836 2761 INFO neutron.pecan_wsgi.hooks.translation 
> [req-93c05a57-c5da-45c2-9fbc-aa586c6317c3 ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] POST failed (client 
> error): The server could not comply with the request since it is either 
> malformed or otherwise incorrect.
> 2018-06-24 05:55:44.081 2761 INFO neutron.wsgi 
> [req-93c05a57-c5da-45c2-9fbc-aa586c6317c3 ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] 192.168.100.101 "POST 
> /v2.0/networks HTTP/1.1" status: 400  len: 349 time: 0.3781040
> 2018-06-24 05:55:44.126 2762 INFO neutron.wsgi 
> [req-23595cd9-5746-43b5-94f9-506fcc4fcb47 ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] 192.168.100.101 "GET 
> /v2.0/extensions HTTP/1.1" status: 200  len: 6914 time: 0.0106690
> 2018-06-24 05:55:44.215 2761 INFO neutron.wsgi 
> [req-7b9896d5-694f-4e7e-b4e4-5b7cbdd7b665 ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] 192.168.100.101 "GET 
> /v2.0/networks HTTP/1.1" status: 200  len: 213 time: 0.0829711
> 2018-06-24 05:55:44.267 2763 INFO neutron.wsgi 
> [req-e56f827c-8e14-4573-91e4-6d1b7c7abb69 ea238a134257452b95e3f096d21034e1 
> 53a4a1dd44334dd29fcdbf1d514928f1 - default default] 192.168.100.101 "GET 
> /v2.0/subnets HTTP/1.1" status: 200  len: 212 time: 0.0480430
> 
> Have a nice day!
> Kevin
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


___
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] network is unreachable in instance

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez Jay See  w dniu 
> 18.06.2018, o godz. 12:48:
> 
> 
> I have created question on ask.opestack, but profile is still not approved by 
> moderators. 
> (https://ask.openstack.org/en/question/114803/network-is-unreachable-in-instance/)
>  Someone in IRC suggested to send the mail here.
> 
> 
> Problem seems to be similar to, but I am not able to follow the bug to fix 
> the issue - 
> https://ask.openstack.org/en/question/80462/network-is-unreachable-in-instance/
> 
> We have 3 controller nodes connected to 12 compute nodes. Eth3 port on all 
> the compute node is down.
> 
> [Thu Jun 14 14:38:57] root@:~# node-ping-check
> 
>  Ping check of all service-ip, vm-ip, data-ip and floating-ip, ping
>  status result after ip, 1/0 = alive/dead
> 
>  command start time 2018-06-14 14:39:00
> 
>  nodeservice-ipvm-ip  data-ipfloating-ip
> -
>  h002   10.1.12.102 1   10.2.12.102 1   10.3.13.102 1   10.4.13.102 1 
> (controller 1)
>  h003   10.1.12.103 1   10.2.12.103 1   10.3.13.103 1   10.4.13.103 1 
> (controller 2)
>  h004   10.1.12.104 1   10.2.12.104 1   10.3.13.104 1   10.4.13.104 1 
> (controller 3 + Network node)
>  h005   10.1.12.105 1   10.2.12.105 1   10.3.13.105 1   10.4.13.105 0
>  h006   10.1.12.106 1   10.2.12.106 1   10.3.13.106 1   10.4.13.106 0
>  h007   10.1.12.107 1   10.2.12.107 1   10.3.13.107 1   10.4.13.107 0
>  h008   10.1.12.108 1   10.2.12.108 1   10.3.13.108 1   10.4.13.108 0
>  h009   10.1.12.109 1   10.2.12.109 1   10.3.13.109 1   10.4.13.109 0
>  h010   10.1.12.110 1   10.2.12.110 1   10.3.13.110 1   10.4.13.110 0
>  h011   10.1.14.111 1   10.2.14.111 1   10.3.15.111 1   10.4.15.111 0
>  h012   10.1.14.112 1   10.2.14.112 1   10.3.15.112 1   10.4.15.112 0
>  h013   10.1.14.113 1   10.2.14.113 1   10.3.15.113 1   10.4.15.113 0
>  h014   10.1.14.114 1   10.2.14.114 1   10.3.15.114 1   10.4.15.114 0
>  h015   10.1.14.115 1   10.2.14.115 1   10.3.15.115 1   10.4.15.115 0
>  h016   10.1.14.116 0   10.2.14.116 0   10.3.15.116 0   10.4.15.116 0  ( Down 
> because of hardware issue)
>  h017   10.1.14.117 1   10.2.14.117 1   10.3.15.117 1   10.4.15.117 0
> 
> [Thu Jun 14 14:39:39] root@:~#
> 
> 
> To bring eth3 on Network node followed following steps:
> 
> ifconfig eth3 down
> ifconfig eth3 0.0.0.0 up
> 
> ovs-vsctl del-br br-ex
> ovs-vsctl add-br br-ex

When You removed and added again br-ex it has no any openflow rules configured. 
So there will be no traffic passed via this bridge at all please try to restart 
neutron-openvswitch-agent and check if rules are recreated.
If that will help, You can apply patch https://review.openstack.org/#/c/573696/ 
and check if that will help :)

> ovs-vsctl add-port br-ex eth3
> ifconfig br-ex 10.4.13.104 netmask 255.255.255.0
> route add -net 10.4.0.0 netmask 255.255.0.0 gateway 10.4.13.1 dev br-ex
> 
> 
> On Network node:
> 
> [2018-06-18 11:38:24] root@h004:~$ ip netns exec 
> qdhcp-eb7573a0-9d91-491c-b150-90f0135778ad ping 12.12.0.4
> PING 12.12.0.4 (12.12.0.4) 56(84) bytes of data.
> 64 bytes from 12.12.0.4: icmp_seq=1 ttl=64 time=1.98 ms
> 64 bytes from 12.12.0.4: icmp_seq=2 ttl=64 time=0.529 ms
> ^C
> --- 12.12.0.4 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 0.529/1.254/1.980/0.726 ms
> [2018-06-18 11:38:33] root@h004:~$ ip netns exec 
> qdhcp-eb7573a0-9d91-491c-b150-90f0135778ad ssh cirros@12.12.0.4
> ^C
>  [SSH Not working]
> 
> [2018-06-18 11:45:51] root@h004:~$ ip netns exec 
> qrouter-d770b552-1979-4063-ae79-c6ff402c8cbc traceroute 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> connect: Network is unreachable
> [2018-06-18 11:58:01] root@h004:~$ ip netns exec 
> qrouter-d770b552-1979-4063-ae79-c6ff402c8cbc traceroute 12.12.0.4
> traceroute to 12.12.0.4 (12.12.0.4), 30 hops max, 60 byte packets
> 
> 
> On Compute node:
> [2018-06-18 11:56:12] root@h011:~$ ip netns exec 
> qrouter-d770b552-1979-4063-ae79-c6ff402c8cbc traceroute 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> connect: Network is unreachable
> 
> [2018-06-18 11:59:20] root@h011:~$ ip netns exec 
> qrouter-d770b552-1979-4063-ae79-c6ff402c8cbc ping 12.12.0.4
> PING 12.12.0.4 (12.12.0.4) 56(84) bytes of data.
> 64 bytes from 12.12.0.4: icmp_seq=1 ttl=64 time=1.61 ms
> 64 bytes from 12.12.0.4: icmp_seq=2 ttl=64 time=0.273 ms
> ^C
> --- 12.12.0.4 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 0.273/0.943/1.614/0.671 ms
> [2018-06-18 12:02:21] root@h011:~$ ip netns exec 
> qrouter-d770b552-1979-4063-ae79-c6ff402c8cbc ping x.x.170.61  (floating ip)
> connect: Network is unreachable
> 
> 
> 
> -- 
> ​P  SAVE PAPER – Please do not print this e-mail unless absolutely necessary.
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo

Re: [Openstack] OpenStack Queens Manual Installation

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez pablo brunetti  w dniu 
> 16.06.2018, o godz. 17:22:
> 
> Hello Kevin,
> 
> In installation of the Keystone OpenStack Queens the port 35357 is deprecated 
> and should be replaced by port 5000.
> 
> ConnectFailure: Unable to establish connection to 
> http://OpenStack-Controller:35357
> 
> Review the entire Neutron installation, replacing port 35357 with 5000. I 
> suggest deleting the database and popular again.

In Neutron DB there is nothing about connection to keystone, so deleting db 
shouldn’t be necessary.
I think that fixing Neutron’s config files should be enough.

> 
> I made a notification on bugs.launchpad, but was flagged as invalid, stating 
> that the problem has already been fixed.
> 
> https://bugs.launchpad.net/neutron/+bug/1773585
> 
> 
> Best Regards.
> 
> 
> De: Kevin Kwon 
> Enviado: sábado, 16 de junho de 2018 11:30
> Para: openstack@lists.openstack.org
> Assunto: [Openstack] OpenStack Queens Manual Installation
>  
> Dear All!
> 
> Hi.. Would you please help to install the Openstack on Ubunto 16.04.4 Server 
> manually.
> 
> I have installed the Keystone, Glance and Nova with One Controller Node and 
> One Compute node with Installation guide on OpenStack.org.
> 
> after installed the Neutron and ran the "openstack network" command, i got 
> below errors.
> 
> Would you please let me know know how can solve this problem?
> 
> 
> root@OpenStack-Controller:~#
> root@OpenStack-Controller:~# openstack network list
> HttpException: Unknown error
> root@OpenStack-Controller:~#
> 
> 
> 2018-06-16 23:25:23.187 10706 INFO neutron.wsgi [-] 192.168.56.101 "GET / 
> HTTP/1.1" status: 200  len: 262 time: 0.0008469
> 2018-06-16 23:25:23.192 10706 WARNING keystoneauth.identity.generic.base [-] 
> Failed to discover available identity versions when contacting 
> http://OpenStack-Controller:35357. Attempting to parse version from URL.: 
> ConnectFailure: Unable to establish connection to 
> http://OpenStack-Controller:35357: 
> HTTPConnectionPool(host='openstack-controller', port=35357): Max retries 
> exceeded with url: / (Caused by 
> NewConnectionError(' 0x7ffa93656d50>: Failed to establish a new connection: [Errno 111] 
> ECONNREFUSED',))
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors [-] An error 
> occurred during processing the request: GET /v2.0/networks HTTP/1.0
> Accept: application/json
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Content-Type: text/plain
> Host: openstack-controller:9696
> User-Agent: osc-lib/1.9.0 keystoneauth1/3.4.0 python-requests/2.18.4 
> CPython/2.7.12
> X-Auth-Token: *: DiscoveryFailure: Could not determine a suitable URL for 
> the plugin
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors Traceback 
> (most recent call last):
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/oslo_middleware/catch_errors.py", line 40, 
> in __call__
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors response 
> = req.get_response(self.application)
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/webob/request.py", line 1316, in send
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors 
> application, catch_exc_info=False)
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/webob/request.py", line 1280, in 
> call_application
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors app_iter 
> = application(self.environ, start_response)
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/webob/dec.py", line 131, in __call__
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors resp = 
> self.call_func(req, *args, **self.kwargs)
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/webob/dec.py", line 196, in call_func
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors return 
> self.func(req, *args, **kwargs)
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", 
> line 334, in __call__
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors response 
> = self.process_request(req)
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", 
> line 633, in process_request
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors resp = 
> super(AuthProtocol, self).process_request(request)
> 2018-06-16 23:25:23.192 10706 ERROR oslo_middleware.catch_errors   File 
> "/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", 
> line 407, in process_request
> 2018-06-16 23:25:23.192 

Re: [Openstack] Geneve isn't working on Queens, Ubuntu 18.04 - Failed to bind port type geneve

[Slawomir Kaplonski]

Hi,

You probably need also change in L2 agent’s config as it needs to report that 
it supports Geneve tunnel types as well. It’s defined in 
https://github.com/openstack/neutron/blob/2820c25e3a67e1cc747abdd6d69e4a0331425904/neutron/conf/plugins/ml2/drivers/ovs_conf.py#L107

> Wiadomość napisana przez Martinx - ジェームズ  w dniu 
> 05.06.2018, o godz. 00:59:
> 
> Hello!
> 
>  I have OpenStack Queens up and running on Ubuntu 18.04 with VXLAN!
> 
>  It is awesome!
> 
>  However, I want to use it with Geneve, instead of VXLAN.
> 
>  But, it doesn't work!
> 
>  With VXLAN, I have the following ml2_conf.ini:
> 
> ---
> [ml2]
> type_drivers = vxlan,flat,vlan
> tenant_network_types = vxlan,flat,vlan
> mechanism_drivers = openvswitch,l2population
> extension_drivers = port_security
> overlay_ip_version = 4
> ---
> 
>  All good! I can launch instances and ping the Internet from within an 
> instance.
> 
>  So, when I try the Geneve instead, like this:
> 
> ---
> [ml2]
> type_drivers = geneve,vxlan,flat,vlan
> tenant_network_types = geneve,vxlan,flat,vlan
> mechanism_drivers = openvswitch,l2population
> extension_drivers = port_security
> overlay_ip_version = 4
> ---
> 
> NOTE: I can easily bring up a clean Ubuntu 18.04 server image, and install 
> OpenStack from scratch, to do the each test independently. I have my own 
> Ansible automation to deploy OpenStack Queens on Ubuntu 18.04. As I've said, 
> it works fine with VXLAN but, not with Geneve (2 lines change from one 
> deployment, to another).
> 
> 
> So, while trying to create an instance with Geneve, the following error 
> appear on Neutron logs:
> 
> ---
> 2018-06-04 22:55:40.677 11426 ERROR neutron.plugins.ml2.managers 
> [req-c988c769-690e-45db-b810-3b35f0e8cba8 bda3aed0ccae46008f9928885280c085 
> 46f4131518fd4b699ac80bc867fd1832 - default default] Failed to bind port 
> 17e4dd94-7655-40f5-9077-b6e7c583c7eb on host queens-1 for vnic_type normal 
> using segments [{'network_id': '6f805d1f-dfb6-42f6-846a-e39fac80ca8c', 
> 'segmentation_id': 19, 'physical_network': None, 'id': 
> '51a89942-5a91-47c6-872b-b33d2e6d418d', 'network_type': u'geneve'}]
> ---
> 
>  Is it a bug?
> 
>  I appreciate any help!
> 
> Cheers!
> Thiago
> 
> 
> 
> ___
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


___
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