April 2019 - openstack-discuss - lists.openstack.org

[PowerVMStackers][Winstackers][uc][tc] Encourage to transform from project to SIG
by Rico Lin 11 Apr '19

11 Apr '19

Dear PowerVMStackers and Winstackers members (This idea is from Thierry, so I'm just helping to trigger discussion here.) We now have most of Working Groups migrate to SIGs, so it's governance under both TCs and UCs. And to further look through, there are some projects are potential SIG meterial. PowerVMStackers and Winstackers are two identical targets. They all required cross-project works to achieve their mission and kind of *special interest* (One for PowerVM, and one for Windows support across OpenStack). There are two questions I would hope team members from both teams can help to answer. 1. Is the mission for your project completed? 2. Is the team still active? 3. Any concerns or objections on moving from project to SIG? If we agree to change from project to SIG, I expect most of the tools will stay the way it is. The only thing for the first step should just change your project definition from project to SIG (like from PowerVMStackers to PowerVM SIG). So it will not cause the team any effort for sure. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

10 22

Proposal to move cinder backup tests out of the integrated gate
by Matt Riedemann 11 Apr '19

11 Apr '19

I wanted to send this separate from the latest gate status update [1] since it's primarily about latent cinder bugs causing failures in the gate for which no one is really investigating. Running down our tracked gate bugs [2] there are several related to cinder-backup testing: * http://status.openstack.org/elastic-recheck/#1483434 * http://status.openstack.org/elastic-recheck/#1745168 * http://status.openstack.org/elastic-recheck/#1739482 * http://status.openstack.org/elastic-recheck/#1635643 All of those bugs were reported a long time ago. I've done some investigation into them (at least at the time of reporting) and some are simply due to cinder-api using synchronous RPC calls to cinder-volume (or cinder-backup) and that doesn't scale. This bug isn't a backup issue, but it's definitely related to using RPC call rather than cast: http://status.openstack.org/elastic-recheck/#1763712 Regarding the backup tests specifically, I don't see a reason why they need to be run in the integrated gate jobs, e.g. tempest-full(-py3). They don't involve other services, so in my opinion we should move the backup tests to a separate job which only runs on cinder changes to alleviate these latent bugs failing jobs for unrelated changes and resetting the entire gate. I would need someone from the cinder team that is more involved in knowing what their job setup looks like to identify a candidate job for these tests if this is something everyone can agree on doing. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867… [2] http://status.openstack.org/elastic-recheck/ -- Thanks, Matt

6 12

[placement][ptg] Gate health management
by Chris Dent 11 Apr '19

11 Apr '19

>From the etherpad [1]: * We have to run grenade and tempest. They are both very very slow and very unreliable (compared to the other tests). That's a pain. How do we help fix it? * Profile where time is spent setting up devstack? * Figure out where the slowest tests are which aren't marked slow: http://status.openstack.org/elastic-recheck/#1783405 * Figure out which (non-interop) tests in tempest could be split out to per-project repos or tempest plugins, i.e. if there are compute API tests which don't rely on other services or a hypervisor, and are just API/DB, they could be dealt with in nova functional tests instead. * Similarly: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000868… The main thing to add here: We can come up with strategies on how to fix it, but how can we assure that there is time/energy/people to do that work? [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

5 5

[cinder][qa] Skipped the unstable test_volume_backup_create_get_detailed_list_restore_delete
by Ghanshyam Mann 11 Apr '19

11 Apr '19

Hello Cinder team, Test test_volume_backup_create_get_detailed_list_restore_delete is failing very frequently now a days. 19 fails in 24 hrs / 137 fails in 10 days [1] I have skipped this test temproarly[2]. mriedem has pointed out the failure on review and cinder channel also, please refer that for more details. Feel free to propose to unskip this test once the problem is fixed. [1] http://status.openstack.org/elastic-recheck/#1483434 [2] https://review.openstack.org/#/c/651660/ -gmann

1 0

[horizon] Cinder API version in Horizon
by Massimo Sgaravatto 11 Apr '19

11 Apr '19

Hi If Horizon uses Cinder API v3 by default since Queens ([1])], why does the installation guide for Horizon [2] suggest to set in local_settings the v2 api for volume ? OPENSTACK_API_VERSIONS = { "identity": 3, "image": 2, "volume": 2, } [1] https://docs.openstack.org/releasenotes/horizon/queens.html [2] https://docs.openstack.org/horizon/rocky/install/install-rdo.html Thanks, Massimo

2 2

[nova] instance breaks the affinity/anti-affinity of server group with force_hosts or force_nodes
by Boxiang Zhu 11 Apr '19

11 Apr '19

Hi All My openstack all-in-one environment is setup by devstack. I created a server-group with anti-affinity policy. Then an instance was created with this server-group successfully with command[1]. Another instance was also created with this server-group and with force_host successfully with command[2]. But if I did not specify the force_host, the instance failed to create[3]. I think the second instance had broken the anti-affinity server-group. So my question is that whether the result is within design scope or it is a issue and needs to be discussed : ) [1] nova boot <instance-name> --flavor <flavor> --image <image> --availability-zone <az> --security-groups <sec-group> --nic net-id=<net-id> --hint group=<server-group> [2] nova boot <instance-name> --flavor <flavor> --image <image> --availability-zone <az>:<host> --security-groups <sec-group> --nic net-id=<net-id> --hint group=<server-group> [3] nova boot <instance-name> --flavor <flavor> --image <image> --availability-zone <az> --security-groups <sec-group> --nic net-id=<net-id> --hint group=<server-group> Best Regards Boxiang

2 6

[tripleo] tripleoclient stable/stein is now branched
by Emilien Macchi 11 Apr '19

11 Apr '19

1) Make sure you do the backports to stable/stein as usual, when needed. 2) We'll branch the rest of TripleO projects once we know CI works fine on this branch and once we are sure no blockers hit current master. Thanks, -- Emilien Macchi

1 0

Re: [tricircle][heat] Tricircle or Trio2o
by Zane Bitter 11 Apr '19

11 Apr '19

On 1/08/18 12:55 PM, Andrea Franceschini wrote: > Actually a heat multisite solution would work too, but I cannot find > any reference to this kind of solutions. You can use the OS::Heat::Stack resource to create stacks in remote regions: https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::He… In Stein you can also use it to create stacks in remote clouds (note: requires Barbican in the local cloud, and of course Heat in the remote cloud). Full docs for that haven't landed yet but they're in review here: https://review.openstack.org/649220 cheers, Zane.

1 0

[sahara][ptg] Preliminary poll for scheduling Sahara virtual PTG
by Jeremy Freudberg 11 Apr '19

11 Apr '19

Hello Saharans and other interested parties: For the Train cycle our PTG will only be virtual. I have assembled here some possible days on which to hold the virtual PTG: https://doodle.com/poll/228ppwvqg488n3c5 We'll probably meet for about 2 hours on Bluejeans (DESPITE the poll the showing huge chunks of time). There'll be an Etherpad and outcomes will be logged to this mailing list too. All are welcome. Best, Jeremy

1 1

RuntimeError: OVS transaction timed out - After minor upgrade
by Yedhu Sastri 11 Apr '19

11 Apr '19

Dear All, We did a minor upgrade on our OpenStack environment Newton HA cluster from 14.2.12 to 14.2.16 using the following link. https://docs.openstack.org/openstack-ansible/newton/upgrade-guide/minor-upg… The upgrade was successful and we tested creation of VM's and it was also successful we were able to ssh into the VM's. Then we rebooted the controllers one by one. But after that we can create the VM's but it is not getting IP from dhcp agent. In the openvswitch-agent.log we are getting 'OVS transaction timeout'. Any help is much appreciated. 2019-04-09 17:25:29.063 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.088 3504 INFO neutron.agent.common.ovs_lib [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 04275c8a-2d12-477b-b435-f6483d418e93 not present in bridge br-int 2019-04-09 17:25:29.089 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.198 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.228 3504 INFO neutron.agent.common.ovs_lib [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 5c25b580-9dcb-4930-a2fe-9cab951114dd not present in bridge br-int 2019-04-09 17:25:29.228 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.229 3504 INFO neutron.agent.securitygroups_rpc [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Remove device filter for [u'63cb0c6a-6e82-41a8-ad46-511ee84579ad', u'9764e98a-bb32-4d37-9460-5a546f351e5a', u'2c075f29-156c-4787-b40f-434c437164e4', u'f00de46f-301a-4789-add1-a8239ee6c859', u'e26c1806-8041-4ce2-aea0-74ca469add67', u'9fa17447-d25d-441b-9983-b81e43c6e6d2', u'3ef24ce6-19b5-47c8-9510-767e64d33e9f', u'c2d37add-65a0-4fc9-914c-2382af70b1ca', u'a8b7c7aa-a5d0-47b3-a944-7b6c4428eda8', u'bf6f7608-0573-43f7-822a-878d7708d985', u'046670cd-77dd-4ce8-bb4b-f1489264375b', u'b7aefa18-d768-47a8-bb5f-6b1e838deaeb', u'04275c8a-2d12-477b-b435-f6483d418e93', u'124eb5e6-2b8a-44a9-aa8b-f6d9bc87f13f', u'5c25b580-9dcb-4930-a2fe-9cab951114dd'] 2019-04-09 17:27:09.740 3504 INFO neutron.agent.securitygroups_rpc [req-5984df4b-c30f-403c-8e87-86c4ccf50a9f - - - - -] Provider rule updated 2019-04-09 17:27:41.961 3504 INFO neutron.agent.securitygroups_rpc [req-67c36a44-f778-48f0-b7ae-0a5244ff95c1 - - - - -] Provider rule updated 2019-04-09 17:28:28.334 3504 INFO neutron.agent.securitygroups_rpc [req-aeffc24f-a354-412e-b458-950c1d4b52ef - - - - -] Provider rule updated 2019-04-09 17:28:46.276 3504 INFO neutron.agent.securitygroups_rpc [req-2dd51325-40c4-4ff0-a384-bccbe3ca0bfc - - - - -] Provider rule updated 2019-04-09 17:28:46.278 3504 INFO neutron.agent.securitygroups_rpc [req-6d48bfd9-0230-4a82-a477-d9e4171db519 - - - - -] Provider rule updated 2019-04-09 17:30:32.695 3504 INFO neutron.agent.securitygroups_rpc [req-01b9b7a8-84a4-42cc-aebb-db846eb2b8f0 - - - - -] Provider rule updated 2019-04-09 17:30:54.288 3504 INFO neutron.agent.securitygroups_rpc [req-de1755bd-0e21-4b75-9fde-db422ee9a79a - - - - -] Provider rule updated 2019-04-09 17:32:12.377 3504 INFO neutron.agent.securitygroups_rpc [req-26bc4547-edb7-4092-b4f4-6465c29dfbe4 - - - - -] Provider rule updated 2019-04-09 17:32:21.444 3504 WARNING neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Device 0d535260-dd98-4027-a2ba-4c5412d4eab0 not defined on plugin or binding failed 2019-04-09 17:32:21.461 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port d3baa557-a367-4a6d-8d58-7183df4243a6 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'680c9bdd-9cea-4059-8c8c-2928dd0ee48f', u'segmentation_id': 65606, u'device_owner': u'network:router_ha_interface', u'physical_network': None, u'mac_address': u'fa:16:3e:b3:9a:60', u'device': u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'port_security_enabled': False, u'port_id': u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'fixed_ips': [{u'subnet_id': u'5b49f8e5-991d-4ecd-a584-df605063aecb', u'ip_address': u'169.254.192.9'}], u'network_type': u'vxlan'} 2019-04-09 17:32:21.461 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 1 as local vlan for net-id=680c9bdd-9cea-4059-8c8c-2928dd0ee48f 2019-04-09 17:32:35.477 3504 INFO oslo_messaging._drivers.amqpdriver [-] No calling threads waiting for msg_id : a9314d944ff8486abf909d4cc271f9a0 2019-04-09 17:32:39.016 3504 INFO neutron.agent.securitygroups_rpc [req-51453b2c-b454-45bd-b7f8-c78560437016 - - - - -] Provider rule updated 2019-04-09 17:32:54.141 3504 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Switch connection timeout 2019-04-09 17:32:57.964 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_bridge [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Bridge br-tun changed its datapath-ID from 6a740a5da349 to 00006a740a5da349 2019-04-09 17:32:58.015 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 0d8dc3c9-c115-45f8-bbb2-cc715b7c1079 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'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625, u'device_owner': u'network:router_gateway', u'physical_network': u'outbound1', u'mac_address': u'fa:16:3e:aa:d7:56', u'device': u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'port_security_enabled': False, u'port_id': u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'fixed_ips': [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address': u'10.97.179.34'}], u'network_type': u'vlan'} 2019-04-09 17:32:58.016 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 2 as local vlan for net-id=4ffb2c28-f9f1-4a25-82a0-df7f7a002434 2019-04-09 17:32:58.030 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 1239fa6c-265a-4f16-ab00-c86fe40545d9 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'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625, u'device_owner': u'network:router_gateway', u'physical_network': u'outbound1', u'mac_address': u'fa:16:3e:4d:73:46', u'device': u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'port_security_enabled': False, u'port_id': u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'fixed_ips': [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address': u'10.97.179.99'}], u'network_type': u'vlan'} 2019-04-09 17:33:13.289 3504 ERROR neutron.agent.ovsdb.impl_idl [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Traceback (most recent call last): File "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/native/connection.py", line 117, in run txn.results.put(txn.do_commit()) File "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/impl_idl.py", line 91, in do_commit raise RuntimeError(_("OVS transaction timed out")) RuntimeError: OVS transaction timed out -- With kind regards, Yedhu Sastri

2 2