June 2019 - openstack-discuss - lists.openstack.org

[infra] Elections for Airship
by MCEUEN, MATT 03 Jun '19

03 Jun '19

OpenStack Infra team, As the Airship project works to finalize our governance and elected positions [1], we need to be ready to hold our first elections. I wanted to reach out and ask for any experience, guidance, materials, or tooling you can share that would help this run correctly and smoothly? This is an area where the Airship team doesn't have much experience so we may not know the right questions to ask. Aside from a member of the Airship community creating a poll in CIVS [2], is there anything else you would recommend? Is there any additional tooling in place in the OpenStack world? Any potential pitfalls, or other hard-won advice for us? [1] https://review.opendev.org/#/c/653865/ [2] https://civs.cs.cornell.edu/ Thank you for your help! Matt

4 4

[nova] Bug #1755266: How to proceed with test failures
by Clemens Hardewig 03 Jun '19

03 Jun '19

Hi there, Since Pike I am struggling with instance migration/instance resize for flavors whose swap space is provided via an lvm volume; according to my understanding the default behavior if cinder uses lvm as a backend driver (at least I could not convince cinder to behave different …). I am somewhat surprised that I seem to be the only one who has some problems with that behavior - according to my understanding you are coming into this constellation automatically when simply following the manual installation procedure as being described in the official Openstack docs... Anyway I opened the bug above, however it did not find some interest and I tried then as a python newbie to get it fixed by my own. After a lengthy live test phase of my changes in the driver.py across Pike, Queens, Rocky, and now also Stein, I made then my first commit (yeee - got it done) to the master branch, had a good short conversation with Eric in Berlin on it, fixed some code format issues Zuul was rightfully complaining about but then unfortunately failed some further tests in Zuul and other test areas. (see https://review.opendev.org/#/c/618621/ <https://review.opendev.org/#/c/618621/>). Related to my changes, tox gets me an error: nova.tests.unit.virt.libvirt.test_driver.LibvirtDriverTestCase.test_finish_migration_power_on --------------------------------------------------------------------------------------------- Captured traceback: ~~~~~~~~~~~~~~~~~~~ Traceback (most recent call last): File "nova/tests/unit/virt/libvirt/test_driver.py", line 18707, in test_finish_migration_power_on self._test_finish_migration() File "/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova/tests/unit/virt/libvirt/test_driver.py", line 18662, in _test_finish_migration mock_raw_to_qcow2.assert_has_calls(convert_calls, any_order=True) File "/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py", line 983, in assert_has_calls ), cause) File "/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/six.py", line 737, in raise_from raise value AssertionError: (call('/tmp/tmpC60sPk/tmpOHikWL/8ea1de33-64d7-4d1d-af02-88e6f7ec91c1/disk.swap'),) not all found in call list but I failed yet to develop any idea what needs to be done to get the test failure fixed. I am missing context here how the logic of the test code works; therefore I would like to ask whether somebody could point me in the right direction what needs to be done to get the failed unit/Zuul/other Tests passed. Are there any docs or helps alongside testing in Nova where to learn what to do? Perhaps also someone could give me a hint whether there are some conceptually misleading ideas behind my fix proposal which need to be driven into another direction … I am looking forward to your reply Best regards Clemens Clemens Hardewig

2 3

[Floating IP][Networking issue] Not able to connect to VM using Floating IP
by Jay See 03 Jun '19

03 Jun '19

Hi, I have followed OpenStack installation guide for Queens [0][1]. In my setup: I have 3 servers. 1 controller , 2 compute nodes - with Ubuntu 16.04, behind my firewall (OpenBSD) *Issue 1:* All my severs have several NIC, but I wanted to use at least two NIC, but I am able to connect to my servers only with one of the NIC. I could not figure, what is wrong with my settings. root@h018:~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback iface eth5 inet static iface eth4 inet static auto eth3 iface eth3 inet static address 10.4.15.118 netmask 255.255.255.0 network 10.4.15.0 broadcast 10.4.15.255 gateway 10.4.15.1 auto eth2 iface eth2 inet static address 10.3.15.118 netmask 255.255.255.0 network 10.3.15.0 broadcast 10.3.15.255 gateway 10.3.15.1 auto eth1 iface eth1 inet static address 10.2.14.118 netmask 255.255.255.0 network 10.2.14.0 broadcast 10.2.14.255 gateway 10.2.14.1 # The primary network interface auto eth0 iface eth0 inet static address 10.1.14.118 netmask 255.255.255.0 network 10.1.14.0 broadcast 10.1.14.255 gateway 10.1.14.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 10.1.14.1 8.8.8.8 8.8.4.4 *Issue 2:* I have completed my OpenStack installation by following [1], after creating the VM and associating the floating IP, everything is fine. But I am not able to ping or SSH to the VM. I have add the ICMP and SSH to my security group rules. I configured my l2 bridge to use Eth1, which is not reachable from firewall or this might be all together a different problem, as my VM creation is successful without any errors. root@h018:~# openstack network create --share --external --provider-physical-network provider --provider-network-type flat provider-network +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | | | availability_zones | | | created_at | 2019-06-03T09:45:20Z | | description | | | dns_domain | None | | id | 5e8f5ec9-9a65-4259-a246-1c7f95a2f33a | | ipv4_address_scope | None | | ipv6_address_scope | None | | is_default | False | | is_vlan_transparent | None | | mtu | 1500 | | name | provider-network | | port_security_enabled | True | | project_id | bb0f22d6efd64b31be6c37edc796d53e | | provider:network_type | flat | | provider:physical_network | provider | | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 5 | | router:external | External | | segments | None | | shared | True | | status | ACTIVE | | subnets | | | tags | | | updated_at | 2019-06-03T09:45:20Z | +---------------------------+--------------------------------------+ root@h018:~# root@h018:~# openstack subnet create --network provider-network \ > --allocation-pool start=XX.XX.169.101,end=XX.XX.169.250 \ > --dns-nameserver 8.8.4.4 --gateway XX.XX.169.1 \ > --subnet-range XX.XX.169.0/24 provider +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools | XX.XX.169.101-XX.XX.169.250 | | cidr | XX.XX.169.0/24 | | created_at | 2019-06-03T09:49:45Z | | description | | | dns_nameservers | 8.8.4.4 | | enable_dhcp | True | | gateway_ip | XX.XX.169.1 | | host_routes | | | id | 51fb740f-1f06-4f6c-93c5-3690488e3980 | | ip_version | 4 | | ipv6_address_mode | None | | ipv6_ra_mode | None | | name | provider | | network_id | 5e8f5ec9-9a65-4259-a246-1c7f95a2f33a | | project_id | bb0f22d6efd64b31be6c37edc796d53e | | revision_number | 0 | | segment_id | None | | service_types | | | subnetpool_id | None | | tags | | | updated_at | 2019-06-03T09:49:45Z | +-------------------+--------------------------------------+ root@h018:~# neutron net-external-list neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +--------------------------------------+------------------+----------------------------------+------------------------------------------------------+ | id | name | tenant_id | subnets | +--------------------------------------+------------------+----------------------------------+------------------------------------------------------+ | 5e8f5ec9-9a65-4259-a246-1c7f95a2f33a | provider-network | bb0f22d6efd64b31be6c37edc796d53e | 51fb740f-1f06-4f6c-93c5-3690488e3980 XX.XX.169.0/24 | +--------------------------------------+------------------+----------------------------------+------------------------------------------------------+ root@h018:~# openstack network list +--------------------------------------+------------------+--------------------------------------+ | ID | Name | Subnets | +--------------------------------------+------------------+--------------------------------------+ | 3ee95928-012f-4a55-a0b3-e277c2d45080 | demo-network | 3427b6ac-3bc0-4529-9035-33e1ab05cb64 | | 5e8f5ec9-9a65-4259-a246-1c7f95a2f33a | provider-network | 51fb740f-1f06-4f6c-93c5-3690488e3980 | +--------------------------------------+------------------+--------------------------------------+ root@h018:~# nova list +--------------------------------------+--------+--------+------------+-------------+----------------------------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+--------+--------+------------+-------------+----------------------------------------+ | 3f8ab4c2-9047-47c4-8634-0c93cf7d7460 | test15 | ACTIVE | - | Running | demo-network=10.1.0.12, XX.XX.169.108 | +--------------------------------------+--------+--------+------------+-------------+----------------------------------------+ root@h018:~# openstack port list +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------+--------+ | 037d801d-5cae-4d88-ae2d-a4289a542057 | | fa:16:3e:a6:68:7b | ip_address='10.1.0.2', subnet_id='3427b6ac-3bc0-4529-9035-33e1ab05cb64' | ACTIVE | | 327fe5fe-4288-4d80-850c-fa7d7e29d3aa | | fa:16:3e:2f:0f:dd | ip_address='XX.XX.169.101', subnet_id='51fb740f-1f06-4f6c-93c5-3690488e3980' | ACTIVE | | 4208ac23-42bf-44ed-8b0d-af1e615b2542 | | fa:16:3e:c5:cb:94 | ip_address='XX.XX.169.108', subnet_id='51fb740f-1f06-4f6c-93c5-3690488e3980' | N/A | (VM) | 642729e6-f84c-4742-89b2-e5924d8e188e | | fa:16:3e:37:97:eb | ip_address='XX.XX.169.107', subnet_id='51fb740f-1f06-4f6c-93c5-3690488e3980' | ACTIVE | | bf5c3061-0c40-41da-bebf-95650e055ce2 | | fa:16:3e:03:bd:f8 | ip_address='10.1.0.1', subnet_id='3427b6ac-3bc0-4529-9035-33e1ab05cb64' | ACTIVE | | fdf976c0-99c6-49e4-b3db-9f26a09da7a9 | | fa:16:3e:c0:be:e9 | ip_address='10.1.0.12', subnet_id='3427b6ac-3bc0-4529-9035-33e1ab05cb64' | ACTIVE | +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------+--------+ root@h018:~# ping -c4 XX.XX.169.101 PING XX.XX.169.101 (XX.XX.169.101) 56(84) bytes of data. --- XX.XX.169.101 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3024ms root@h018:~# ping -c4 XX.XX.169.107 PING XX.XX.169.107 (XX.XX.169.107) 56(84) bytes of data. --- XX.XX.169.107 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3023ms root@h018:~# ping -c4 XX.XX.169.108 PING XX.XX.169.108 (XX.XX.169.108) 56(84) bytes of data. --- XX.XX.169.108 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3001ms root@h018:~# openstack server list +--------------------------------------+--------+--------+----------------------------------------+-------------+----------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+--------+--------+----------------------------------------+-------------+----------+ | 3f8ab4c2-9047-47c4-8634-0c93cf7d7460 | test15 | ACTIVE | demo-network=10.1.0.12, XX.XX.169.108 | Ubuntu16.04 | m1.small | +--------------------------------------+--------+--------+----------------------------------------+-------------+----------+ root@h018:~# ip route default via 10.1.14.1 dev eth0 10.1.14.0/24 dev eth0 proto kernel scope link src 10.1.14.118 10.2.14.0/24 dev brq5e8f5ec9-9a proto kernel scope link src 10.2.14.118 10.3.15.0/24 dev eth2 proto kernel scope link src 10.3.15.118 10.4.15.0/24 dev eth3 proto kernel scope link src 10.4.15.118 root@h018:~# ifconfig brq3ee95928-01 Link encap:Ethernet HWaddr 72:77:4f:54:6a:93 inet6 addr: fe80::4459:b6ff:feb0:3352/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1 RX packets:34 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3144 (3.1 KB) TX bytes:828 (828.0 B) brq5e8f5ec9-9a Link encap:Ethernet HWaddr 24:6e:96:84:25:1a inet addr:10.2.14.118 Bcast:10.2.14.255 Mask:255.255.255.0 inet6 addr: fe80::286d:e0ff:fefa:15a4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:118004 errors:0 dropped:0 overruns:0 frame:0 TX packets:10175 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5834402 (5.8 MB) TX bytes:1430189 (1.4 MB) eth0 Link encap:Ethernet HWaddr 24:6e:96:84:25:18 inet addr:10.1.14.118 Bcast:10.1.14.255 Mask:255.255.255.0 inet6 addr: fe80::266e:96ff:fe84:2518/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1977142 errors:0 dropped:0 overruns:0 frame:0 TX packets:2514801 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1013827869 (1.0 GB) TX bytes:1529933345 (1.5 GB) eth1 Link encap:Ethernet HWaddr 24:6e:96:84:25:1a inet6 addr: fe80::266e:96ff:fe84:251a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2622581 errors:0 dropped:14027 overruns:0 frame:0 TX packets:327841 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:166482697 (166.4 MB) TX bytes:28701550 (28.7 MB) eth2 Link encap:Ethernet HWaddr b4:96:91:0f:cd:28 inet addr:10.3.15.118 Bcast:10.3.15.255 Mask:255.255.255.0 inet6 addr: fe80::b696:91ff:fe0f:cd28/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:272 errors:0 dropped:0 overruns:0 frame:0 TX packets:45 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16452 (16.4 KB) TX bytes:2370 (2.3 KB) eth3 Link encap:Ethernet HWaddr b4:96:91:0f:cd:2a inet addr:10.4.15.118 Bcast:10.4.15.255 Mask:255.255.255.0 inet6 addr: fe80::b696:91ff:fe0f:cd2a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7546483 errors:0 dropped:0 overruns:0 frame:0 TX packets:43 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:452789254 (452.7 MB) TX bytes:2118 (2.1 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:42373349 errors:0 dropped:0 overruns:0 frame:0 TX packets:42373349 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:12244256693 (12.2 GB) TX bytes:12244256693 (12.2 GB) tap037d801d-5c Link encap:Ethernet HWaddr ba:7a:4c:72:fb:05 UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1 RX packets:9 errors:0 dropped:0 overruns:0 frame:0 TX packets:40 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1950 (1.9 KB) TX bytes:4088 (4.0 KB) tap327fe5fe-42 Link encap:Ethernet HWaddr 6e:a2:fd:08:dc:bb UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:107768 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:618 (618.0 B) TX bytes:6253098 (6.2 MB) tap642729e6-f8 Link encap:Ethernet HWaddr 5a:11:77:05:54:e0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11858 errors:0 dropped:0 overruns:0 frame:0 TX packets:94601 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:498656 (498.6 KB) TX bytes:5676060 (5.6 MB) tapbf5c3061-0c Link encap:Ethernet HWaddr 72:77:4f:54:6a:93 UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1 RX packets:9122 errors:0 dropped:0 overruns:0 frame:0 TX packets:9186 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:928979 (928.9 KB) TX bytes:711090 (711.0 KB) vxlan-8 Link encap:Ethernet HWaddr a6:77:6e:2b:f7:1f UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1 RX packets:9186 errors:0 dropped:0 overruns:0 frame:0 TX packets:9113 errors:0 dropped:19 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:582486 (582.4 KB) TX bytes:801919 (801.9 KB) root@h018:~# If any other information is required , please let me know. I will share the info. I have seen many posts with similar issues, steps which worked for them are not working in my setup. May be I have done something wrong, not able to figure out that on my own. Thanks and regards, Jayachander. [0] https://docs.openstack.org/install-guide/. [1] https://docs.openstack.org/install-guide/openstack-services.html#minimal-de… -- P *SAVE PAPER – Please do not print this e-mail unless absolutely necessary.*

1 0

RE: [tc][all] Github mirroring (or lack thereof) for unofficial projects
by Roman Gorshunov 03 Jun '19

03 Jun '19

Hello Jim, team, I'm from Airship project. I agree with archival of Github mirrors of repositories. One small suggestion: could we have project descriptions adjusted to point to the new location of the source code repository, please? E.g. "The repo now lives at opendev.org/x/y". Thanks to AJaeger & clarkb. Thank you. Best regards, -- Roman Gorshunov

7 17

[openstack-ansible] Installing Third-Party drivers into the Cinder-Volume container during playbook execution
by Henry Bonath 03 Jun '19

03 Jun '19

Hello, I asked this into IRC but I thought this might be a more appropriate place to ask considering the IRC channel usage over the weekend. If I wanted to deploy a third party driver along with my Cinder-Volume container, is there a built-in mechanism for doing so? (I am specifically wanting to use: https://github.com/iXsystems/cinder) I am able to configure a cinder-backend in the "openstack_user_config.yml" file which works perfectly if I let it fail during the first run, then copy the driver into the containers and run "os-cinder-install.yml" a second time. I've found that you guys have built similar stuff into the system (e.g. Horizon custom Theme installation via .tgz) and was curious if there is a similar mechanism for Cinder Drivers that may be undocumented. http://paste.openstack.org/show/752132/ This is an example of my working config, which relies on the driver being copied into the /openstack/venvs/cinder-19.x.x.x/lib/python2.7/site-packages/cinder/volume/drivers/ixsystems/ folder. Thanks in advance!

3 5

[placement] Office Hours
by Ed Leafe 03 Jun '19

03 Jun '19

A recent poll of our members resulted in the decision to no longer hold our regular weekly meetings, but to instead switch to an Office Hour format. Now the question is when to hold them, and how often. A time between 1400—2200 UTC would work well for US-based people, while times between 0900—1700 UTC would be best for Europe people, and 0100—0900 UTC for Asia-Pacific. It would seem that holding it at 1600 UTC would be a good compromise for both US and Europe, but that leaves out the other half of the world. So perhaps our members in that side of the globe might be interested in holding their own Office Hour? So I'd like your input. Respond with your preference, and after a week if there is an overwhelming favorite, we'll go with that. If there is a range of preferences, we can hold another poll to settle on one. I'll start: my preference would be to hold weekly office hours every Wednesday at 1600 UTC. -- Ed Leafe

4 4

[searchlight] Team meeting today cancelled
by Trinh Nguyen 03 Jun '19

03 Jun '19

Hi team, I'm in a middle of something right now and will not expect to finish at 13:30 UTC today so we have to cancel the team meeting today. Ping me on the #openstack-searchlight channel. Sorry for this late notice. dangtrinhnt -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

ovn L3 TCP protocol has a large number of retransmissions
by liujinxin＠xiangcloud.com.cn 03 Jun '19

03 Jun '19

Hi： I have the following two questions. What shall I do? problem1：When the cloud host accesses the external network through L3 router. TCP protocol has a large number of retransmissions, leading to TCP link failure, TCP data transmission error problem2：TCP links data packets, duplicates ACK and TCP data transmission disorderly when the instances communicate across hosts through geneve, but the quality impact of TCP is relatively acceptable. openstack queens with ovn environment OS： CentOS Linux release 7.3.1611 (Core) kernel： 3.10.0-514.el7.x86_64 openstack： kolla-ansible queens networking-ovn：python-networking-ovn-4.0.3 ovs and ovn： openvswitch-ovn-central-2.10.90 openvswitch-2.10.90 openvswitch-ovn-host-2.10.90 openvswitch-ovn-common-2.10.90 topology： openstack controller 10.200.105.19 openstack compute 10.200.105.16，10.200.105.17，10.200.105.18 openstack gateway 10.200.105.20 openstack controller gateway compute 10.200.105.19 10.200.105.20 10.200.105.[16-18] neutron_server ovn-northd ---------bond0------------|------------------------------------------------------------------| | | | ovn-controller ovn-controller ovn-controller | | | ovs ovs ovs | | | | | | | |----------------------------------|--|------bond0-------------------------------------------------|--| |-------------------------------------|--------bond1--------------------------------------------------| Packet forwarding： | compute1 | compute2 | gateway | | 10.200.105.16 | 10.200.105.17 | 10.200.105.20 | | vm1 | vm2 | | | | | | | | | br-int <-> br-ex | br-int <-> br-ex | br-int <-> br-ex | | |_____bond1_vlan___|___________|____________|________| |__________bond0_____________|_______________________| 1、L3 data flow 10.200.100.16 | 10.200.105.20 vm1<--->br-int<-->geneve <->bond0 <―-> bond0<-->geneve<--->br-ex<-->bond1<-->vlan<---->internet 2、vm1<->vm2 10.200.100.16 | 10.200.105.17 vm1<--->br-int<-->geneve <->bond0 <―-> bond0<-->geneve<--->br-int<--->vm2 Configure： Openstack Configure 1、neutron.conf ... service_plugins = networking_ovn.l3.l3_ovn.OVNL3RouterPlugin,qos ... 2、cat /etc/kolla/neutron-server/ml2_conf.ini [ml2] type_drivers = flat,vlan,local,geneve tenant_network_types = geneve mechanism_drivers = ovn extension_drivers = port_security,qos overlay_ip_version = 4 [ml2_type_vlan] network_vlan_ranges = physnet1 [securitygroup] enable_security_group = true [ml2_type_geneve] vni_ranges = 1:65536 max_header_size = 38 [ovn] ovn_nb_connection = tcp:10.200.105.19:6641 ovn_sb_connection = tcp:10.200.105.19:6642 ovn_l3_mode = True ovn_l3_scheduler = leastloaded ovn_native_dhcp = True neutron_sync_mode = repair enable_distributed_floating_ip = True ovsdb_log_level = DEBUG [qos] notification_drivers = ovn-qos Ovn Configure 10.200.105.19 ovs-vsctl get open . external_ids {hostname="10-200-105-19", ovn-bridge-mappings="physnet1:br-ex", ovn-encap-ip="10.200.105.19", ovn-encap-type="geneve,vxlan", ovn-remote="tcp:10.200.105.19:6642", rundir="/var/run/openvswitch", system-id="160e569c-a12f-41a3-8d2a-37bd9af0c7ed"} 10.200.105.20 ovs-vsctl get open . external_ids {hostname="10-200-105-20", ovn-bridge-mappings="physnet1:br-ex", ovn-cms-options=enable-chassis-as-gw, ovn-encap-ip="10.200.105.20", ovn-encap-type="geneve,vxlan", ovn-remote="tcp:10.200.105.19:6642", rundir="/var/run/openvswitch", system-id="96e89c3c-5c85-498d-b42f-5aea559bdd42"} 10.200.105.[16-18] ovs-vsctl get open . external_ids {hostname="10-200-105-17", ovn-bridge-mappings="physnet1:br-ex", ovn-encap-ip="10.200.105.17", ovn-encap-type="geneve,vxlan", ovn-remote="tcp:10.200.105.19:6642", rundir="/var/run/openvswitch", system-id="a768ca6e-905d-4aac-aa1e-d18b38dedadf"} ovn-nbctl show 2019-06-03T10:51:46Z|00001|ovsdb_idl|WARN|NB_Global table in OVN_Northbound database lacks ipsec column (database needs upgrade?) 2019-06-03T10:51:46Z|00002|ovsdb_idl|WARN|NB_Global table in OVN_Northbound database lacks options column (database needs upgrade?) switch eddff890-b515-41d3-ad49-edcae9a3197b (neutron-7489be65-074f-49f0-9cf3-c520dcd3b08d) (aka v) port 066c4c72-a1f7-4311-8d40-ed7ca0f942b3 addresses: ["fa:16:3e:a8:9d:05 192.168.2.212"] port edc6e2a9-47db-4a8a-8857-d8afa63d900d type: router router-port: lrp-edc6e2a9-47db-4a8a-8857-d8afa63d900d port provnet-7489be65-074f-49f0-9cf3-c520dcd3b08d type: localnet addresses: ["unknown"] switch 23d3676d-9d95-403e-947c-bcd4b298bde0 (neutron-7dd91bd0-10dd-4022-868c-6d17be7380f7) (aka bb) port a764f462-7897-475f-9ef0-04b7c83e44db addresses: ["fa:16:3e:cd:23:b2 10.0.0.11"] port 71247f19-21bd-4eac-b3db-94e770abb50c type: router router-port: lrp-71247f19-21bd-4eac-b3db-94e770abb50c port 659f304c-266f-4b3f-946a-b3cf4ea988c5 addresses: ["fa:16:3e:f8:5f:1b 10.0.0.9"] router 3c5d2c44-e3c4-46e9-9f43-64c1cbc7e065 (neutron-f8611590-42a1-4c6a-b433-db9ade3194a2) (aka v) port lrp-edc6e2a9-47db-4a8a-8857-d8afa63d900d mac: "fa:16:3e:06:f4:ca" networks: ["192.168.2.205/16"] gateway chassis: [311c4582-71d1-4886-baf0-1aefa5f2ceab d61a09c2-87e2-4dff-91be-82e705ab85f4] port lrp-71247f19-21bd-4eac-b3db-94e770abb50c mac: "fa:16:3e:ef:06:c6" networks: ["10.0.0.1/24"] nat 4bc0e7cf-3bdb-4725-94e4-a29b62f7d8e0 external ip: "192.168.2.205" logical ip: "10.0.0.0/24" type: "snat" liujinxin(a)xiangcloud.com.cn

1 0

[swift] How to track the rest api call count
by Manu K M 03 Jun '19

03 Jun '19

Hi there I have to keep track of the no of rest call made by a specific account/tenant to my swift cluster. Ceilometer provides only the number of incoming and outgoing bytes. -- Regards Manu K M

1 0

[neutron][networking-ovn] Core team updates
by Lucas Alvares Gomes 01 Jun '19

01 Jun '19

Hi all, I'd like to welcome Jakub Libosvar to the networking-ovn core team. The team was in need for more reviewers with +2/+A power and Jakub's reviews have been super high quality [0][1]. He's also helping the project out in many other different efforts such as bringing in the full stack test suit and bug fixes. Also, Miguel Ajo has changed focus from OVN/networking-ovn and is been dropped from the core team. Of course, we will welcome him back when his activity picks back up again. Thank you Jakub and Miguel! [0] https://www.stackalytics.com/report/contribution/networking-ovn/30 [1] https://www.stackalytics.com/report/contribution/networking-ovn/90 Cheers, Lucas

4 3