March 2021 - openstack-discuss - lists.openstack.org

[live migration] [nova] [libvirt] [stein] Live migration of nested VMs fails
by Nagaraj Akkina 16 Mar '21

16 Mar '21

Hi Team, We are using live migration in our environment from some time now, recently there are nested VMs created and after that "Live migration of nested VMs fails" How to make live migration work on nested VMs? Regards, Akkina ReplyForward

2 1

[live migration] [libvirt] [nova]
by Nagaraj Akkina 16 Mar '21

16 Mar '21

Hi Team, We are using live migration in our environment from quite some time now, recently there are nested VMs created and after that "Live migration of nested VMs fails" Is there any documentation on this?. How to make live migration work on nested VMs? Regards, Akkina

2 1

[all] Help on Improving Software Documentation Through Code Reviews
by Felipe Ebert 16 Mar '21

16 Mar '21

Dear members of OpenStack, We are an international team of researchers, from the University of Bari - Italy, Federal University of Pernambuco - Brazil, University of Adelaide - Australia, and Eindhoven University of Technology - the Netherlands. The goal of our research is to improve software documentation and maintainability of open-source projects by providing automatic support of source code comments based on code review discussions. We would like to learn identifying relevant information from code review discussions such that tooling can be developed to improve software documentation and maintainability of open-source projects. Therefore, we would like to talk to open-source developers and interview them. If you are interested in talking about your experiences as an open-source reviewer then please schedule a meeting with us using YouCanBook.me here: [ https://tue-interview.youcanbook.me] We are interested in different experiences, therefore, we are looking to talk to people of all age-groups, genders, and people with different roles in open-source projects. So even whether you are a first-time contributor or a senior maintainer don’t hesitate to contact us. The interview itself will take no longer than 30 min and will be scheduled using Microsoft Teams. We will record the interview and the recording and transcript of the interview will be stored securely, and only made available to the researchers that are involved in this project. Additionally, we plan to use anonymized results of the interview in a scientific publication. Kind regards and thanks in advance, -- Nicole Novielli, University of Bari, Fernando Castor, Federal University of Pernambuco, Christoph Treude, University of Adelaide, Alexander Serebrenik, Eindhoven University of Technology, Felipe Ebert, Eindhoven University of Technology

1 0

[victoria][neutron] OVN Gateway Chassis Issue
by Ammad Syed 16 Mar '21

16 Mar '21

Hi, I have four compute nodes in my lab setup. Initially all the four compute nodes were acting as gateway chassis with priority 1, 2, 3 and 4. Then I have specifically marked two node as a gateway chassis with below command on compute nodes. ovs-vsctl set open . external-ids:ovn-cms-options="enable-chassis-as-gw" The command ovn-nbctl list gateway_chassis start showing two chassis. I have checked via tcpdump, the public traffic started flowing from both nodes. Look like its doing round robin to send packets. Then I tried to remove one chassis from gateway and used below command. ovs-vsctl remove open . external-ids ovn-cms-options=enable-chassis-as-gw The ovn-nbctl list gateway_chassis started showing one gateway chassis but I can see from tcpdump that public traffic still flows from both gateway chassis. Below is the current status of chassis. root@network:/etc/neutron# ovn-sbctl list chassis _uuid : 532bb9d0-6667-462c-9631-0cb5360bd4dc encaps : [358c4a59-0bca-459c-958c-524eb8c385ce] external_ids : {datapath-type=system, iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", "neutron:liveness_check_at"="2021-03-16T08:52:41.361302+00:00", "neutron:metadata_liveness_check_at"="2021-03-16T08:52:41.364928+00:00", "neutron:ovn-metadata-id"="2ac66785-d0c7-43ee-8c78-5fd6ed6ccc73", "neutron:ovn-metadata-sb-cfg"="6157", ovn-bridge-mappings="ext-net1:br-ext", ovn-chassis-mac-mappings="", ovn-cms-options=""} hostname : virtual-hv2 name : "fdfae005-7473-486a-b331-8a54c53c1279" nb_cfg : 6157 transport_zones : [] vtep_logical_switches: [] _uuid : a99ab389-96a5-4a58-a301-34618868450a encaps : [6e7490ce-3c58-4a1c-999d-ff1638c66feb] external_ids : {datapath-type=system, iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", neutron-metadata-proxy-networks="dc917847-f70f-4de0-9865-3e9594c65ef1", "neutron:liveness_check_at"="2021-03-16T08:52:41.368768+00:00", "neutron:metadata_liveness_check_at"="2021-03-16T08:52:41.372045+00:00", "neutron:ovn-metadata-id"="3441fc3c-ca43-4360-8210-8c9ebe4fc13d", "neutron:ovn-metadata-sb-cfg"="6157", ovn-bridge-mappings="ext-net1:br-ext", ovn-chassis-mac-mappings="", ovn-cms-options=""} hostname : kvm10-a1-khi01 name : "87504098-4474-40fc-9576-ac449c1c4448" nb_cfg : 6157 transport_zones : [] vtep_logical_switches: [] _uuid : b9bdfe12-fe27-4580-baee-159f871c442b encaps : [52a8f523-9740-4333-a4a4-69bf5e27117c] external_ids : {datapath-type=system, iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", neutron-metadata-proxy-networks="dc917847-f70f-4de0-9865-3e9594c65ef1", "neutron:liveness_check_at"="2021-03-16T08:52:41.326719+00:00", "neutron:metadata_liveness_check_at"="2021-03-16T08:52:41.342214+00:00", "neutron:ovn-metadata-id"="2a751610-97a8-4688-a719-df3616f4f770", "neutron:ovn-metadata-sb-cfg"="6157", ovn-bridge-mappings="ext-net1:br-ext", ovn-chassis-mac-mappings="", ovn-cms-options=""} hostname : kvm12-a1-khi01 name : "82630e57-668e-4f67-a3fb-a173f4da432a" nb_cfg : 6157 transport_zones : [] vtep_logical_switches: [] _uuid : 669d1ae3-7a5d-4ec3-869d-ca6240f9ae2c encaps : [ac8022b3-1ea5-45c7-a7e8-74db7b627df4] external_ids : {datapath-type=system, iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", "neutron:liveness_check_at"="2021-03-16T08:52:41.347144+00:00", "neutron:metadata_liveness_check_at"="2021-03-16T08:52:41.352021+00:00", "neutron:ovn-metadata-id"="2d5ce6fd-6a9f-4356-9406-6ca91601af43", "neutron:ovn-metadata-sb-cfg"="6157", ovn-bridge-mappings="ext-net1:br-ext", ovn-chassis-mac-mappings="", ovn-cms-options=enable-chassis-as-gw} hostname : virtual-hv1 name : "731e842a-3a69-4044-87e9-32b7517d4f07" nb_cfg : 6157 transport_zones : [] vtep_logical_switches: [] Need help how can I permanently remove a gateway chassis that it should stop serving public traffic ? also is it something to do with priority ? - Ammad

2 2

[largescale-sig] Next meeting: March 10, 15utc
by Thierry Carrez 16 Mar '21

16 Mar '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210310T15 Belmiro Moreira will chair this meeting. A number of topics have already been added to the agenda, including discussing CentOS Stream, reflecting on last video meeting and pick a topic for the next one. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

4 3

[venus][ptg] Xena PTG
by Liye Pang(逄立业) 16 Mar '21

16 Mar '21

Hi, Venus is the OpenStack project that provides a one-stop solution for log collection, indexing, analysis, alerting, visualization, report generation and other needs. Additionally, this project plans to use machine learning algorithms to locate failures and find the root causes quickly, to improve operation and maintenance efficiency. If you are planning to attend venus sessions during the Xena PTG, please fill in the doodle[1] with time slots which are good for you before 23rd March so that we can book the best time slots for most of us. And, please add any topic which you want to discuss on the etherpad[2]. [1] https://doodle.com/poll/q72urs2mk7up45pf [2] https://etherpad.opendev.org/p/venus-xena-ptg

1 0

Re: [cinder] wallaby feature freeze
by Rajesh Ratnakaram 16 Mar '21

16 Mar '21

Hi, I have added missing features to Zadara cinder driver and posted: https://review.opendev.org/c/openstack/cinder/+/774463 The corresponding bp can be found at: https://blueprints.launchpad.net/cinder/+spec/zadara-wallaby-features I wanted to push the above changes to Wallaby release, hence requesting to add FFE for the above request. Thanks and Regards, Rajesh. Sent from Mail for Windows 10

2 1

Re: [cinder] wallaby feature freeze
by Ajitha Robert 16 Mar '21

16 Mar '21

Hi team, This patch https://review.opendev.org/c/openstack/cinder/+/778886 requires a feature freeze exception. I am working on the the minor revisions and the CI will be running tomorrow. Thank you. -- *Regards,Ajitha R*

2 1

Keystone enforced policy issues - Victoria
by Luke Camilleri 16 Mar '21

16 Mar '21

Hi there, we have been troubleshooting keystone policies for a couple of days now (Victoria) and would like to reach out to anyone with some experience on the keystone policies. Basically we would like to follow the standard admin, member and reader roles together with the scopes function and have therefore enabled the below two option in keystone.conf enforce_scope = true enforce_new_defaults = true once enabled we started seeing the below error related to token validation in keystone.log: 2021-03-11 19:50:12.009 1047463 WARNING keystone.server.flask.application [req-33cda154-1d54-447e-8563-0676dc5d8471 020bd854741e4ba69c87d4142cad97a5 c584121f9d1a4334a3853c61bb5b9d93 - default default] You are not authorized to perform the requested action: identity:validate_token.: keystone.exception.ForbiddenAction: You are not authorized to perform the requested action: identity:validate_token. The policy was previously setup as: identity:validate_token: rule:service_admin_or_token_subject but has now been implemented with the new scope format to: identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject If we change the policy to the old one, we stop receiving the identity:validate_token exception. This only happens in horizon and running the same commands in the CLI (python-openstack-client) does not output any errors. To work around this behavior we place the old policy for validate_token rule in /usr/share/openstack-dashboard/openstack_dashboard/conf/keystone_policy.yaml and in the file /etc/keystone/keystone.conf A second way how we can solve the validate_token exception is to disable the option which has been enabled above "enforce_new_defaults = true" which will obviously allow the deprecated policy rules to become effective and hence has the same behavior as implementing the old policy as we did We would like to know if anyone have had this behavior and how it has been solved maybe someone can point us in the right direction to identify better what is going on. Last but not least, it seems that from Horizon, the admin user is being assigned a project scoped token instead of a system scoped token, while from the CLI the same admin user can successfully issue a system:all token and run commands across all resources. We would be very happy to receive any form of input related to the above issues we are facing Thanks in advance for any assistance

1 2

[barbican][ironic][neutron] [QA][OpenstackSDK][swift]
by Armstrong Foundjem 16 Mar '21

16 Mar '21

Hello! Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest Wallaby release available on release week. The following deliverables have done a Wallaby release, but it was not refreshed in the last two months: ansible-role-lunasa-hsm ironic-inspector ironic-prometheus-exporter ironic-ui ovn-octavia-provider patrole python-openstackclient swift You should consider making a new one very soon, so that we don't use an outdated version for the final release. - Armstrong Foundjem (armstrong)

4 3