- openstack-discuss - lists.openstack.org

[cinder] festival of XS reviews 19 March 2021
by Brian Rosmaita 17 Mar '21

17 Mar '21

Hello Cinder community members, Due to popular demand, we will hold the Second Cinder Festival of XS Reviews on Friday 19 March (yes, that's this Friday at the end of this very week). Apologies for the late notice, but with RC-1 being released next week, we need to give people time to revise and resubmit (if necessary) so the fixes can make it into the Wallaby release. what: The Second Cinder Festival of XS Reviews when: Friday 19 March 2021 from 1400-1600 UTC where: https://bluejeans.com/3228528973 See you there! brian

1 0

[blazar][ptg] Xena PTG
by Pierre Riteau 17 Mar '21

17 Mar '21

Hello, We have allocated two hours during the Xena PTG for the Blazar project. We will meet on Thursday, April 22, 2021 from 15:00 to 17:00 UTC in the Bexar room. The agenda will be decided over the coming weeks and kept at https://etherpad.opendev.org/p/xena-ptg-blazar Anyone can propose discussion topics through the Etherpad or in our IRC meeting. Feel free to join if you want to know more about Reservation as a Service. Cheers, Pierre Riteau (priteau)

1 0

How to detach cinder volume
by Md. Hejbul Tawhid MUNNA 17 Mar '21

17 Mar '21

Hi, We are using openstack rocky. One of our openstack vm was running with 3 volume , 1 is bootable and another 2 is normal volume . We have deleted 1 normal volume without properly detaching. So volume is deleted but instance is still showing 3 volume is attached. Now we can't snapshot the instance and facing some others issue. Please advise how we can detach the volume(deleted) from the instance Note: We have reset state volume attached status to detached and delete the volume. Regards, Munna

3 3

[kolla][ptg] Xena PTG slots
by Mark Goddard 17 Mar '21

17 Mar '21

Hi, The Xena PTG [1] is fast approaching, and it is time to decide on our time slots. The event will take place on 19th - 23rd April. For the last few events, we have settled on the following schedule: * Monday: 13:00 - 17:00 UTC (General & Kolla) * Tuesday: 13:00 - 17:00 UTC (Kolla Ansible) * Wednesday: 13:00 - 15:00 UTC (Kayobe) This has largely worked quite well, allowing the contributor base in Europe and the US to collaborate. This schedule does tend to exclude contributors in other timezones however, and I would like to explore ideas to increase our global coverage. I would be interested to hear from anyone who would be interested in joining one or more slots in the 6:00 - 8:00 UTC window on one or more days. Please respond here or in IRC if you are interested. PS remember to sign up [2]! Thanks, Mark [1] https://www.openstack.org/ptg/ [2] https://april2021-ptg.eventbrite.com/

2 1

[MURANO] Can not deploy environment on existing network
by İzzettin Erdem 17 Mar '21

17 Mar '21

Hi everyone, I am tryng to use Murano on OSA-stable/ussuri. I have encountered an error; when I try to deploy an environment on existing network, it creates the VM but do not attach floating IP to it. In murano-agent.log on the vm there is "rabbitmq queue not found" error -->http://paste.openstack.org/show/803667/ , rabbitmq logs ---> http://paste.openstack.org/show/803668/, murano-engine logs ---> http://paste.openstack.org/show/803669/, murano.conf on containers----> http://paste.openstack.org/show/803672/ I can attach floating IP to the VM after Murano fails and also I can deploy environment if I use "create new network" option. Do you have any suggestions about it? Thanks, İzzettin

1 0

[horizon] Welcome Tatiana Ovchinnikova in horizon-core team
by Ivan Kolodyazhny 17 Mar '21

17 Mar '21

Hi team, As agreed during the horizon meeting [1] last week, I've added Tatiana to horizon-core team. Tatiana, thanks for your contributions and welcome back to the team! [1] http://eavesdrop.openstack.org/meetings/horizon/2021/horizon.2021-03-10-15.… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[kolla] Upgrading from Centos7 Train to Centos8 Ussuri
by Braden, Albert 17 Mar '21

17 Mar '21

I'm testing the Train7->Ussuri8 upgrade on a heat stack, following this document: OpenStack Docs: CentOS 8<https://docs.openstack.org/kolla-ansible/train/user/centos8.html#migrating-…> I used the instructions here to successfully remove a controller from the cluster: https://docs.openstack.org/kolla-ansible/train/user/adding-and-removing-hos… Now I'm ready to add one, using the instructions here: https://docs.openstack.org/kolla-ansible/train/user/adding-and-removing-hos… They say to run bootstrap-servers: kolla-ansible -i <inventory> bootstrap-servers [ --limit <limit> ] The question is, how to run it? My build server is running Centos 7 and has Python 2.7.5. Should I just download Ussuri to my existing build server, or do I need to build a new Centos 8 build server with Python 3? I read the "potential issues<https://docs.openstack.org/kolla-ansible/train/reference/deployment-and-boo…>" text but it's not obvious whether it is safe to run Ussuri bootstrap-servers on Train hosts. If I don't run bootstrap-servers on the Train controllers, then how does the new Ussuri controller get integrated (RMQ, MariaDB, etc.)? I apologize for the nonsense below. I have not been able to stop it from being attached to my external emails. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 4

[telemetry][ptg] Telemetry PTG planning
by Matthias Runge 17 Mar '21

17 Mar '21

Hi there, for Telemetry, we had a short planning meeting after PTG last year. If you are interested in Telemetry, or have something Telemetry related to talk about, please add yourself and the topic to the planning etherpad [1]. Matthias [1] https://etherpad.opendev.org/p/telemetry-xena-ptg

1 0

[manila][requirements] FFE requested for python-manilaclient
by Goutham Pacha Ravi 17 Mar '21

17 Mar '21

Hello, We were tracking one last feature inclusion into python-manilaclient for the wallaby release: https://review.opendev.org/c/openstack/python-manilaclient/+/775020 The change does not introduce any new requirements, but adds new SDK methods and shell implementations for end users to harness a feature addition in manila to be able to update their security services. The release team was very gracious in allowing us to wrap up code reviews pertaining to the above change over the weekend; however, the gate was uncooperative this morning by pointing us to lingering sporadic failures that are a combination of bad test case logic as well as occasional test environment setup issues. (Zuul is awesome, but it has a way to call out our procrastinations) No projects that depend on python-manilaclient need this change in their current form because it is net new feature functionality (existing SDK/CLI functionality is unaltered). However, I thought i should check here before requesting a re-release of python-manilaclient under the Wallaby cycle. Thanks, Goutham

3 5

[cinder] Bug deputy report for week of 2021-03-08
by Sofia Enriquez 16 Mar '21

16 Mar '21

Hello, This is a bug report from 2021-03-09 to 2021-03-16. Critical: - https://bugs.launchpad.net/cinder/+bug/1832164: "SADeprecationWarning: The joinedload_all() function is deprecated, and will be removed in a future release. Please use method chaining with joinedload() instead". Assigned to Gorka Eguileor. High: - https://bugs.launchpad.net/cinder/+bug/1919161: "Automatic quota refresh counting temporary volumes". Assigned to Gorka Eguileor. Medium: - https://bugs.launchpad.net/cinder/+bug/1918229: "Nimble free space calculation". Unassigned but looks like Ajitha Robert may be working on this. Low: - https://bugs.launchpad.net/cinder/+bug/1918932: "volume delete rejection message doesn't include awaiting-transfer state". (low-hanging-fruit) Unassigned. - https://bugs.launchpad.net/cinder/+bug/1918307: " api-ref: Make documentation of HTTP 403 consistent". Unassigned. Incomplete: - https://bugs.launchpad.net/cinder/+bug/1918449: " ensure_export model_update ignored ". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1918879: "id of encryption for volume type not verified". Unassigned. Not a bug:- Feel free to reply/reach me if I missed something. Regards Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[charms] Trilio Charms 21.03 release is now available
by Peter Matulis 16 Mar '21

16 Mar '21

The 21.03 release of the Trilio charms is now available. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2103_Trilio.html == Highlights == * TrilioVault 4.1 The charms now support TrilioVault release 4.1. * OpenStack Ussuri The charms add support for OpenStack Ussuri on both Ubuntu 18.04 LTS (Bionic) and Ubuntu 20.04 LTS (Focal). This is in addition to current Bionic support for OpenStack Queens, Stein, and Train. == Thank you == Lots of thanks to the following people who contributed to this release via code changes, documentation updates and testing efforts. Alex Kavanagh Aurelien Lourot Chris MacNaughton David Ames Liam Young Marian Gasparovic Peter Matulis -- OpenStack Charms Team

1 0

[cinder] New Cinder Bug Squad Meeting
by Sofia Enriquez 16 Mar '21

16 Mar '21

Hello, As discussed in the last meeting, Cinder will have an additional mini meeting to discuss bugs. [1] Cinder Bug Squad Meeting - Weekly on Wednesday at 1500 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0> in #openstack-cinder (IRC webclient <https://webchat.freenode.net/?randomnick=1&channels=%23openstack-cinder&pro…>) - Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting Feel free to add your bugs to the Agenda if I haven't done so already. Cheers, Sofi [1] http://eavesdrop.openstack.org/#Cinder_Bug_Squad_Meeting -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[Horizon][Victoria][ops] - Scope based policies in Horizon not working
by Luke Camilleri 16 Mar '21

16 Mar '21

Hi Everyone, we had sent an email to this mailing list last week on an issue that we are having which we thought was being generated by keystone but on closer inspection it seems that this is coming actually from Horizon policy files. We would like to implement OpenStack using the scope based approach (v3) so that we could keep the main roles (reader,member and Admin) and use the scopes to differentiate the targets. We have implemented the below settings in /etc/keystone/keystone.conf: enforce_scope = true enforce_new_defaults = true All works well with the cli and the scopes except Horizon. We constantly receive errors in /var/log/keystone.log like: 2021-03-15 23:15:55.772 1611435 WARNING keystone.server.flask.application [req-a89277a2-8fb2-4fcb-b337-e76a73bb3af9 1405ecf1ff7f4e4188648dbd1fb84c07 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 but the same command (for example an "openstack domain list") works well from the CLI. We could identify the issue coming from the policy files shipped with the dashboard at /etc/openstack-dashboard/<policies.json> as the rules within these policies are not scope based and in json format while according to the roadmap it seems that yaml is being used for the policy files and they should be scope based. When we try to convert the files to json to then upgrade them (to use the scope syntax) we receive the following errors: #oslopolicy-convert-json-to-yaml --config-file /etc/keystone/keystone.conf --namespace keystone --output-file keystone_policy.yaml --policy-file keystone_policy.json Traceback (most recent call last): File "/bin/oslopolicy-convert-json-to-yaml", line 10, in <module> sys.exit(convert_policy_json_to_yaml()) File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py", line 599, in convert_policy_json_to_yaml conf.output_file) File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py", line 451, in _convert_policy_json_to_yaml scope_types=default_rule.scope_types) File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1239, in __init__ scope_types=scope_types File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1154, in __init__ self.description = description File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1251, in description raise InvalidRuleDefault('Description is required') oslo_policy.policy.InvalidRuleDefault: Invalid policy rule default: Description is required. We believe that converting such files to yaml and then upgrading them for scope based access (v3) should solve our issues based on the fact that if we disable the enforce _scope and enforce_new_defaults we can have a fully functional setup (but not scope based) which defies the initial objective Thanks in advance for anyone that may be able to assist with this issue

2 2

Properly consuming system-scope and operator workflows
by Lance Bragstad 16 Mar '21

16 Mar '21

Hey all, Several projects have made significant progress adopting default roles and system-scope during the Wallaby cycle. One part of that work is obviously testing and we've been stringing together various tempest jobs with the new policies enabled to see what falls out. Ironic was working on some of this last week and it led to an interesting discussion on Friday about how we should handle system-scope with the current assumptions about administrator (e.g., project-admin) workflows. The majority of the discussion took place in IRC, but I tried to consolidate as much of the context as I could into an etherpad [0]. I'm socializing the overall discussion so we can get feedback from users, operators, and developers, as well as summarize some comparisons to other systems. Today, by default system administrators are anyone with the 'admin' role on a project. These users are allowed to do things on behalf of users, like rebooting an instance. This mostly works because the administrator's token is project-scoped and the resource they're interacting with is owned by a project. This assumption isn't true in the new default policies. The question is, should system administrators, or users with system-scoped tokens, be allowed to use those tokens to make changes to project-specific resources (e.g., creating a private image in a project, rebooting an instance, deleting a snapshot, etc)? The general feeling was that, yes, system administrators should have the ability to interact with resources owned by projects in their deployment. The discussion then focused on how we actually make that happen. We came up with three different solutions, all of which are detailed in the etherpad [0], but I'll summarize them below. Option 1: Let system-administrators exchange system-scoped (god-mode) tokens for tokens scoped to a specific project without an explicit role assignment on the project Option 2: Require system-administrators to grant themselves authorization on the project, obtain a new token, and perform the operation Option 3: Allow system-administrators to use system-scoped tokens to operate on project-specific resources We're iterating through the pros and cons of each approach in the etherpad. If you haven't taken a look, please do so and add your thoughts. If you're an operator with an existing workflow, we want to hear your feedback. My request for additional feedback aside, several people in the discussion brought up comparison to other identity systems and frameworks (e.g., how do kerberos admins usually handle this sort of thing? how would we fix this if we were using OAuth 2.0/OIDC?) I spent some time Friday thinking through what an OAuth 2.0 flow would look like in OpenStack [1][2]. I don't think my findings were earth-shattering, and I'm sure there are other ways we could implement OAuth 2.0 flows. While adhering to a standard offers guidance and makes some things easier (like integrating with other systems), I don't think it would be the silver bullet for fixing our RBAC woes (at least not this late in the game). OpenStack APIs are massive, complex, and operate at different parts of the technology stack. Some of those APIs are meant for typical users just requesting resources. Others are written with the system administrator as the end user. OpenStack's explosive API and functionality growth out-paced its authorization tools to protect it, allowing project_id to bake itself into resources, services, and components (API code, middleware, database layers). Relaxing the assumption of an always-present project ID in every token is going to be hard and given OpenStack's distributed approach to policy enforcement, truly fixing it would require consistency across the entire ecosystem, regardless of the authentication or authorization framework. Either way, I thought that was an interesting exercise, and I'm curious if others have different opinions or perspectives on those findings. Thanks for reading, Lance [0] https://etherpad.opendev.org/p/consuming-system-scope [1] https://bit.ly/3cjUu6o My first few attempts at mapping this out were wrong, but I left links to the early drafts in the etherpad [2] I ignored a lot of assumptions about how clients interact with OpenStack, or how middleware works. This was purely a thought-experiment.

1 0

[cinder] docs job failures
by Brian Rosmaita 16 Mar '21

16 Mar '21

Note to reviewers, since all FFE patches need to be reviewed and merged by friday: Don't let a Zuul -1 for openstack-tox-docs stop you from reviewing patches. Gorka has a fix posted that we believe will address this: https://review.opendev.org/c/openstack/cinder/+/780907 but it needs to make its way through check and gate first, so it may be awhile. An example of the docs failure is: https://zuul.opendev.org/t/openstack/build/28c1d829e2d4469d82128a4f295f4dad It happens very early in the job, so even if there's a problem with the docs on a patch you're looking at, you aren't going to see it. If you want to check the docs on your patch locally, the change in this patch works for me, but YMMV: https://review.opendev.org/c/openstack/cinder/+/780696

1 1

[oslo] Xena PTG Etherpad
by Ben Nemec 16 Mar '21

16 Mar '21

Daniel created an etherpad for the Xena PTG[0]. If you have any topics to discuss please add them so we know whether we need to reserve a time. Thanks. -Ben 0: https://etherpad.opendev.org/p/oslo-xena-topics

1 0

[openstack-ansible] vPTG April 2021
by Dmitriy Rabotyagov 16 Mar '21

16 Mar '21

1 0

[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(逄立业) 15 Mar '21

15 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 15 Mar '21

15 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 15 Mar '21

15 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 15 Mar '21

15 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 15 Mar '21

15 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

[neutron][requirements] RFE requested for neutron-lib
by Slawek Kaplonski 15 Mar '21

15 Mar '21

Hi, I'm raising this RFE to ask if we can release, and include new version of the neutron-lib in the Wallaby release. Neutron already migrated all our policy rules to use new personas like system-reader or system-admin. Recently Lance found bug [1] with those new personas. Fix for that is now merged in neutron-lib [2]. This fix required bump the oslo_context dependency in lower-constraints and that lead us to bump many other dependencies versions. But in fact all those new versions are now aligned with what we already have in the Neutron's requirements so in fact neutron-lib was tested with those new versions of the packages every time it was run with Neutron master branch. I already proposed release patch for neutron-lib [3]. Please let me know if I You need anything else regrarding this RFE. [1] https://launchpad.net/bugs/1918506 [2] https://review.opendev.org/c/openstack/neutron-lib/+/780204 [3] https://review.opendev.org/c/openstack/releases/+/780550 -- Slawek Kaplonski Principal Software Engineer Red Hat

3 6

[community/MLs] Measuring ML Success
by Jimmy McArthur 15 Mar '21

15 Mar '21

Hi All - Over the last six months or so, we've had feedback from people that feel their questions die on the ML or that are missing ask.openstack.org. I don't think we should open up the ask.openstack.org can of worms, by any means. However, I wanted to find out if there was any software out there we could use to track metrics on which questions go unanswered on the ML. Everything I've found is very focused on email marketing, which is not what we're after. Would love to try to get some numbers on individuals that are trying to reach out to the ML, but just aren't getting through to anyone. Assuming we get that, I feel like it would be an easy next step to do a monthly or bi-monthly check to reach out to these potential new contributors. I realize our community is busy and people are, by and large, volunteering their time to answer these questions. But as hard as that is, it's also tough to pose new questions to a community you're unfamiliar with and then hear crickets. Open to other ideas/thoughts :) Cheers! Jimmy

5 6

[PTLs][release] Wallaby Cycle Highlights
by Kendall Nelson 15 Mar '21

15 Mar '21

Hello Everyone! It's time to start thinking about calling out 'cycle-highlights' in your deliverables! I have no idea how we are here AGAIN ALREADY, alas, here we be. As PTLs, you probably get many pings towards the end of every release cycle by various parties (marketing, management, journalists, etc) asking for highlights of what is new and what significant changes are coming in the new release. By putting them all in the same place it makes them easy to reference because they get compiled into a pretty website like this from the last few releases: Stein[1], Train[2]. We don't need a fully fledged marketing message, just a few highlights (3-4 ideally), from each project team. Looking through your release notes might be a good place to start. *The deadline for cycle highlights is the end of the R-5 week [3] (next week) on March 12th.* How To Reminder: ------------------------- Simply add them to the deliverables/$RELEASE/$PROJECT.yaml in the openstack/releases repo like this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin. The formatting options for this tag are the same as what you are probably used to with Reno release notes. Also, you can check on the formatting of the output by either running locally: tox -e docs And then checking the resulting doc/build/html/$RELEASE/highlights.html file or the output of the build-openstack-sphinx-docs job under html/$RELEASE/highlights.html. Feel free to add me as a reviewer on your patches. Can't wait to see you all have accomplished this release! Thanks :) -Kendall Nelson (diablo_rojo) [1] https://releases.openstack.org/stein/highlights.html [2] https://releases.openstack.org/train/highlights.html [3] htt <https://releases.openstack.org/train/schedule.html#t-cycle-highlights> https://releases.openstack.org/wallaby/schedule.html <https://releases.openstack.org/ussuri/schedule.html>

2 6

[queens][nova] live migration error
by Ignazio Cassano 15 Mar '21

15 Mar '21

Hello all, we are facing a problem while migrating some virtual machines on centos 7 queens. If we create a new virtual machine it migrates. Old virtual machines got the following: 37eb1d0c4c - default default] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Increasing downtime to 50 ms after 0 sec elapsed time 2021-03-15 17:26:44.428 82382 INFO nova.virt.libvirt.driver [req-2189a13d-097a-4eb0-9f9b-60767b9b0c68 66adb965bef64eaaab2af93ade87e2ca 85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Migration running for 0 secs, memory 100% remaining; (bytes processed=0, remaining=0, total=0) 2021-03-15 17:26:57.922 82382 INFO nova.compute.manager [req-83fd3d62-292e-4990-8f7a-47f404b557cc - - - - -] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] VM Paused (Lifecycle Event) 2021-03-15 17:26:58.617 82382 INFO nova.virt.libvirt.driver [req-2189a13d-097a-4eb0-9f9b-60767b9b0c68 66adb965bef64eaaab2af93ade87e2ca 85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Migration operation has completed 2021-03-15 17:26:58.618 82382 INFO nova.compute.manager [req-2189a13d-097a-4eb0-9f9b-60767b9b0c68 66adb965bef64eaaab2af93ade87e2ca 85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] _post_live_migration() is started.. 2021-03-15 17:26:58.658 82382 ERROR nova.virt.libvirt.driver [req-2189a13d-097a-4eb0-9f9b-60767b9b0c68 66adb965bef64eaaab2af93ade87e2ca 85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Live Migration failure: operation failed: domain is not running: libvirtError: operation failed: domain is not running 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [req-2189a13d-097a-4eb0-9f9b-60767b9b0c68 66adb965bef64eaaab2af93ade87e2ca 85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Post live migration at destination podto2-kvmae failed: InstanceNotFound_Remote: Instance 25fbb55c-5991-49b2-885f-26adebaeb572 could not be found. InstanceNotFound: Instance 25fbb55c-5991-49b2-885f-26adebaeb572 could not be found. 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Traceback (most recent call last): 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6505, in _post_live_migration 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] instance, block_migration, dest) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/compute/rpcapi.py", line 783, in post_live_migration_at_destination 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] instance=instance, block_migration=block_migration) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 174, in call 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] retry=self.retry) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 131, in _send 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] timeout=timeout, retry=retry) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 559, in send 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] retry=retry) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 550, in _send 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] raise result 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] InstanceNotFound_Remote: Instance 25fbb55c-5991-49b2-885f-26adebaeb572 could not be found. 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Traceback (most recent call last): 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] res = self.dispatcher.dispatch(message) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 220, in dispatch 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] return self._do_dispatch(endpoint, method, ctxt, args) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 190, in _do_dispatch 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] result = func(ctxt, **new_args) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 76, in wrapped 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] function_name, call_dict, binary) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] self.force_reraise() 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] six.reraise(self.type_, self.value, self.tb) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 67, in wrapped 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] return f(self, context, *args, **kw) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 1000, in decorated_function 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] return function(self, context, *args, **kwargs) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 203, in decorated_function 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] return function(self, context, *args, **kwargs) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6658, in post_live_migration_at_destination 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 'destination host.', instance=instance) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] self.force_reraise() 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] six.reraise(self.type_, self.value, self.tb) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6653, in post_live_migration_at_destination 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] block_device_info) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 7844, in post_live_migration_at_destination 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] self._host.get_guest(instance) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line 526, in get_guest 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] return libvirt_guest.Guest(self._get_domain(instance)) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line 546, in _get_domain 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] raise exception.InstanceNotFound(instance_id=instance.uuid) 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] InstanceNotFound: Instance 25fbb55c-5991-49b2-885f-26adebaeb572 could not be found. 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:01.259 82382 ERROR nova.compute.manager [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] 2021-03-15 17:27:05.179 82382 WARNING nova.compute.resource_tracker [req-2189a13d-097a-4eb0-9f9b-60767b9b0c68 66adb965bef64eaaab2af93ade87e2ca 85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] Instance not resizing, skipping migration.: InstanceNotFound_Remote: Instance 25fbb55c-5991-49b2-885f-26adebaeb572 could not be found. 2021-03-15 17:27:13.621 82382 INFO nova.compute.manager [-] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] VM Stopped (Lifecycle Event) 2021-03-15 17:27:13.711 82382 INFO nova.compute.manager [req-0dcd030c-d520-4223-91a6-f2fbc9f2444a - - - - -] [instance: 25fbb55c-5991-49b2-885f-26adebaeb572] During the sync_power process the instance has moved from host podto2-kvmae to host podto2-kvm01 The istances was on podto1-kvm01 and we try to migrate it on podto2-kvmae. It stops to migrate and goes in error state and stop to responding to ping requests. >From logs is seems it returned on podto2-kvm01 but it is in error state on podto2-kvmae. After hard rebooting it starts on podto2-kvmae and then we can migrate it where we want without errors. Please, any help ? Thanks Ignazio

1 1

[devstack][cinder] ceph iscsi driver support
by Brian Rosmaita 15 Mar '21

15 Mar '21

Hello devstack cores, Cinder added a ceph iscsi backend driver at Wallaby milestone 2, and CI on the original patch [0] was done via a dependency chain. Ongoing CI for this driver depends on this devstack patch: Add support for ceph_iscsi cinder driver https://review.opendev.org/c/openstack/devstack/+/668668 It's got one +2. I just want to raise awareness so it can get another review so we can get the CI running before any changes are proposed for the driver. (All dependencies for the devstack patch have merged.) thanks! brian [0] https://review.opendev.org/c/openstack/cinder/+/662829

1 0

[tripleo] TripleO CI Summary: Unified Sprint 40
by Bhagyashri Shewale 15 Mar '21

15 Mar '21

Greetings, The TripleO CI team has just completed **Unified Sprint 40** (Feb 04 thru Feb 24 2021). The following is a summary of completed work during this sprint cycle: - Deployed the new (next gen) promoter code <https://hackmd.io/team/rh-openstack-ci?nav=search&q=promoter> - Have a successful promotion of master, victoria, ussuri and train c8 on newly deployed promoter server. - Completated dependency pipeline <https://hackmd.io/team/rh-openstack-ci?nav=search&q=dependency+pipeline> work as below: - RHEL and CentOS OpenVswitch pipeline - Upstream and downstream container-tools pipeline - Downstream RHELU.next - Add centos8 stream jobs and pipeline - https://hackmd.io/Y6IGnQGXTqCl8TAX0YAeoA?view - monitoring dependency pipeline under cockpit - Created the design document for tripleo-repos <https://opendev.org/openstack/tripleo-repos> - https://hackmd.io/v2jCX9RwSeuP8EEFDHRa8g?view - https://review.opendev.org/c/openstack/tripleo-specs/+/772442 - [tempest skip list] Add addtest command to tempest-skiplist - Tempest scenario manager Many of the scenario manager methods used to be private apis. Since these methods Are supposed to be used in tempest plugins they aren’t expected to be private. Following commits are with respect to this idea except - https://review.opendev.org/c/openstack/tempest/+/774085 - https://review.opendev.org/c/openstack/tempest/+/766472 - https://review.opendev.org/c/openstack/tempest/+/773783 - https://review.opendev.org/c/openstack/tempest/+/773019 Implementation of create_subnet() api varies with manila-tempest plugin For the stable implementation of create_subnet() following parameters have been added: 1. Condition to check empty str_cidr 2. More attributes in case of ipv6 3. Usage of default_subnet_pool - https://review.opendev.org/c/openstack/tempest/+/766472 - Ruck/Rover recorded notes [1]. The planned work for the next sprint and leftover previous sprint work as following: - Migrate upstream master from CentOS-8 to CentOS-8-Stream - improving resource usage/ reduce upstream infra footprint, context <http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020235…> - Deploy the promoter server for downstream promotions - elastic-recheck containerization - https://hackmd.io/dmxF-brbS-yg7tkFB_kxXQ - Openstack health for tripleo - https://hackmd.io/HQ5hyGAOSuG44Le2x6YzUw - Tripleo-repos spec and implementation - https://hackmd.io/v2jCX9RwSeuP8EEFDHRa8g?view - https://review.opendev.org/c/openstack/tripleo-specs/+/772442 - Leftover dependency pipeline work: - ansible 2.10/11 upstream pipeline - https://hackmd.io/riLaLFcTTpybbyY51xcm9A?both - Tempest skiplist: - https://review.opendev.org/c/openstack/tripleo-quickstart/+/771593/ - https://review.opendev.org/c/openstack/tripleo-quickstart-extras/+/778157 - https://review.opendev.org/c/openstack/tripleo-ci/+/778155 - https://review.opendev.org/c/osf/python-tempestconf/+/775195 The Ruck and Rover for this sprint are Soniya Vyas (soniya29) and Bhagyashri Shewale (bhagyashri). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in hackmd [2]. Thanks, Bhagyashri Shewale [1] https://hackmd.io/Ta6fdwi2Sme4map8WEiaQA [2] https://hackmd.io/ii6M2T4RTUSFeTZqkw3uRQ

1 0

[ISSUE]instances cannot ping on different compute nodes
by Jhen-Hao Yu 15 Mar '21

15 Mar '21

Dear Sir, We are testing in OpenStack (Stein) + OpenDaylight (Neon) + Open vSwitch (v2.11.1). It's an all-in-one deployment (OPNFV-9.0.0). The instances can ping each other on the same compute node, but cannot ping each other if instances are on different compute nodes. *Cmp001: * ============================================= Manager "tcp:172.16.10.40:6640" is_connected: true Bridge br-floating Port "ens6" Interface "ens6" Port br-floating Interface br-floating type: internal Port br-floating-int-patch Interface br-floating-int-patch type: patch options: {peer=br-floating-pa} Bridge br-int Controller "tcp:172.16.10.40:6653" is_connected: true fail_mode: secure Port "tun9a4f2733bb3" Interface "tun9a4f2733bb3" type: vxlan options: {exts=gpe, key=flow, local_ip="10.1.0.5", remote_ip=flow} Port "tap59535eb9-ef" Interface "tap59535eb9-ef" Port br-floating-pa Interface br-floating-pa type: patch options: {peer=br-floating-int-patch} Port "tapc58e6fd1-cf" Interface "tapc58e6fd1-cf" Port "tap8bb9f6de-a9" Interface "tap8bb9f6de-a9" Port "tap5f490693-e5" Interface "tap5f490693-e5" Port "tund818d69b326" Interface "tund818d69b326" type: vxlan options: {exts=gpe, key=flow, local_ip="10.1.0.5", remote_ip="10.1.0.2"} Port br-int Interface br-int type: internal Port "tapef79fa77-ab" Interface "tapef79fa77-ab" Port "tapa9e63637-8a" Interface "tapa9e63637-8a" ovs_version: "2.11.1" ============================================= *Cmp002:* ============================================= Manager "tcp:172.16.10.40:6640" is_connected: true Manager "ptcp:6640:127.0.0.1" Bridge br-floating Port br-floating-int-patch Interface br-floating-int-patch type: patch options: {peer=br-floating-pa} Port br-floating Interface br-floating type: internal Port "ens6" Interface "ens6" Bridge br-int Controller "tcp:172.16.10.40:6653" is_connected: true fail_mode: secure Port br-floating-pa Interface br-floating-pa type: patch options: {peer=br-floating-int-patch} Port "tap50868440-95" Interface "tap50868440-95" Port "tapa496a81b-0c" Interface "tapa496a81b-0c" Port "tun8d223879efb" Interface "tun8d223879efb" type: vxlan options: {exts=gpe, key=flow, local_ip="10.1.0.6", remote_ip=flow} Port br-int Interface br-int type: internal Port "tun941edf0fa60" Interface "tun941edf0fa60" type: vxlan options: {exts=gpe, key=flow, local_ip="10.1.0.6", remote_ip="10.1.0.2"} ovs_version: "2.11.1" ====================================================== Could you give us some advice? Thanks. Regards, Zack [image: Mailtrack] <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> 03/15/21, 03:56:22 PM

1 0

[qa][ptg] Xena PTG
by Masayuki Igawa 13 Mar '21

13 Mar '21

Hi, If you are planning to attend QA 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/5ixvdcbm488kc2ic [2] https://etherpad.opendev.org/p/qa-xena-ptg Best Regards, -- Masayuki Igawa

1 0

[all][tc][legal] Possible GPL violation in several places
by Radosław Piliszek 13 Mar '21

13 Mar '21

Dear fellow OpenStackers, it has been brought to my attention that having any (Python) imports against a GPL lib (e.g Ansible) *might be* considered linking with all the repercussions of that (copyleft anyone?). Please see the original thread in Launchpad: https://bugs.launchpad.net/kolla-ansible/+bug/1918663 Not only the projects that have "Ansible" in name might be affected, e.g. Ironic also imports Ansible parts. Do note *I am not a lawyer* so I have no idea whether the Python importing is analogous to linking in terms of GPL. I am only forwarding the concerns reported to me in Launchpad. A quick Google search was inconclusive. I have done some analysis in the original Launchpad thread mentioned above. I am copying it here for ease of reference. """ Hmm, the reasoning is interesting. OpenStack Ansible and TripleO would probably also be interested in knowing whether GPL violation is happening or not. I am not in a position to answer this question. I will propagate this matter to the mailing list: http://lists.openstack.org/pipermail/openstack-discuss/ FWIW, TripleO is by Red Hat, just like Ansible, so one would assume they know what they are doing. OTOH, there is always room for a mistake. All in all, end users must use Ansible so they must agree to GPL anyhow, so the license switch would be mostly cosmetic: +/- the OpenStack licensing requirements [1]. That said, Ansible Collections for OpenStack are already licensed under GPL [2]. And a related (and very relevant) project using Ansible - Zuul - includes a note about partial GPL [3]. A quick search [4] reveals a lot of places that could be violating GPL in OpenStack (e.g. in Ironic, base CI jobs) if we followed this linking logic. [1] https://governance.openstack.org/tc/reference/licensing.html [2] https://opendev.org/openstack/ansible-collections-openstack [3] https://opendev.org/zuul/zuul [4] https://codesearch.opendev.org/?q=(from%7Cimport)%5Cs%2B%5Cbansible%5Cb&i=n… """ -yoctozepto

3 4

[Quuens][nova] lost config.drive file
by Ignazio Cassano 13 Mar '21

13 Mar '21

Hello, probably because an human error, we lost the file disk.config drive file for some instances under /var/lib/nova/instances/uuid directories. Please, is there something we can do for rebuild it for revert instances without rebuild ? Anycase, does the instance rebuilding regenerate the file? Thanks Ignazio

1 0

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-5 Update
by Ghanshyam Mann 13 Mar '21

13 Mar '21

Hello Everyone, Please find the week's R-5 updates on 'Migrate RBAC Policy Format from JSON to YAML' wallaby community-wide goals. Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Updates: ======= * 8 more projects merged the patches last week, thanks to everyone for active review and merging these. * Sahara and Heat are failing on config object initialization, I am debugging those and will fix them soon. * Puppet Openstack left with the last patch which is on hold due to gnoochi upgrade in RDO[1]. * Panko patch is blocked due to failed gate[2], it is all good to merge (has +A) once the gate is green. Progress Summary: =============== Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml * Projects completed: 29 * Projects required to merge the patches: 5 (Openstackm Ansible , Sahara, Heat, Puppet Openstack, Telemetry ) * Projects do not need any work: 16 [1] https://review.opendev.org/c/openstack/puppet-gnocchi/+/768690 [2] https://review.opendev.org/c/openstack/panko/+/768498 -gmann

1 0

[tc][ptl][mistral] Leadership option for Mistral for Xena cycle
by Ghanshyam Mann 13 Mar '21

13 Mar '21

Hello Mistral Team, As Renat already sent an email about Mistral maintenance and help on PTL role[1], and as per TC discussion with the Mistral team, the DPL model[2] is one of the options we can try. As the Xena cycle election is completed now and Mistral is on the leaderless list[3], it is time to apply the DPL model. For this model, we need three mandatory liaisons 1. Release, 2. TACT SIG, 3. Security and these can be a single person or multiple[4]. Step to Apply: You need to propose the patch in governance with the three liaisons info; here is the example for Oslo project moving to DPL model - https://review.opendev.org/c/openstack/governance/+/757906 [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020137… [2] https://governance.openstack.org/tc/resolutions/20200803-distributed-projec… [3] https://etherpad.opendev.org/p/xena-leaderless [4] https://governance.openstack.org/tc/resolutions/20200803-distributed-projec… -gmann

1 0

[neutron] Bug deputy report for the week of Mar-8-2021
by Hongbin Lu 13 Mar '21

13 Mar '21

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. High * Functional test test_gateway_chassis_rebalance failing due to "failed to bind logical router": https://bugs.launchpad.net/neutron/+bug/1918266 * Neutron doesn't honor system-scope: https://bugs.launchpad.net/neutron/+bug/1918506 * quota: invalid JSON for reservation value when positive: https://bugs.launchpad.net/neutron/+bug/1918565 Medium * Slownesses on neutron API with many RBAC rules: https://bugs.launchpad.net/neutron/+bug/1918145 * [QoS][SR-IOV] Minimum BW dataplane enforcement fails if NIC does not support min_tx_rate: https://bugs.launchpad.net/neutron/+bug/1918464 * [OVN] BW limit QoS rules assigned to SR-IOV ports are created on NBDB: https://bugs.launchpad.net/neutron/+bug/1918702 * Toggling dhcp on and off in a subnet causes new instances to be unreachable: https://bugs.launchpad.net/neutron/+bug/1918914 Low * Driver VLAN do not create the VlanAllocation registers if "network_vlan_ranges" only specify the network: https://bugs.launchpad.net/neutron/+bug/1918274 RFE * [RFE] RFC 2317 support in Neutron with designate provider: https://bugs.launchpad.net/neutron/+bug/1918424 Won't Fix * Can't create m2 interface on the 15.3.2: https://bugs.launchpad.net/neutron/+bug/1918155 Invalid * Designate DNS – create TLD using valid Unicode string: https://bugs.launchpad.net/neutron/+bug/1918653 Incomplete * Race between sriov_config service and openib service: https://bugs.launchpad.net/neutron/+bug/1918255 * failed to name sriov vfs because the names reserved for representors: https://bugs.launchpad.net/neutron/+bug/1918397 Best regards, Hongbin

1 0

How to enable GPU in k8s environment
by open infra 13 Mar '21

13 Mar '21

Hi, What are the config files to deal with when enabling GPU (both nvidia and itel)? Regards, Danishka

1 0

[cinder] wallaby feature freeze
by Brian Rosmaita 12 Mar '21

12 Mar '21

The Wallaby feature freeze is now in effect. The following cinder patches have already been approved, but have not yet merged, and are granted a Feature Freeze Exception: - Add support to store volume format info in Cinder https://review.opendev.org/c/openstack/cinder/+/761152 - Add Consistency Groups support in PowerStore driver https://review.opendev.org/c/openstack/cinder/+/775090 The following patch had been approved, but ran into merge conflicts and had to be resubmitted, and requires re-review and approval. It also has been granted a FFE: - NetApp ONTAP: Implement FlexGroup pool https://review.opendev.org/c/openstack/cinder/+/776713 The third party CI is not reporting on the following patch, which otherwise would have been approved at this point. It has an FFE while this gets worked out: - Revert to snapshot for volumes on DS8000 https://review.opendev.org/c/openstack/cinder/+/773937 Any other feature patch (including driver features) must apply for an FFE by responding to this email before Tuesday, 16 March at 16:00 UTC. Note that application for an FFE is not a guarantee that an FFE will be granted. Grant of an FFE is not a guarantee that the code will be merged for Wallaby. It is expected that patches granted an FFE will be merged by 21:00 UTC on Friday 19 March. Bugfixes do not require an FFE. To be included in Wallaby, they must be merged before the first Release Candidate is cut on Thursday 25 March. After that point, only release-critical bugs will be allowed into the Wallaby release.

1 0

[Consultation] SFC proxy
by Jhen-Hao Yu 12 Mar '21

12 Mar '21

Dear Sir, (We made some edits from our previous mail.) We are testing a simple SFC in OpenStack (Stein) + OpenDaylight (Neon) + Open vSwitch (v2.11.1). It's an all-in-one deployment (OPNFV-9.0.0). We have read the document: https://readthedocs.org/projects/odl-sfc/downloads/pdf/latest/ and https://github.com/opnfv/sfc/blob/master/docs/release/scenarios/os-odl-sfc-… The driver we use is odl_v2: [image: image.png] [image: image.png] Our SFC topology: [image: enter image description here] <https://i.stack.imgur.com/7QMWh.png> All on the same compute node. Build SFC through API: 1. openstack sfc flow classifier create --source-ip-prefix 10.20.0.0/24 --logical-source-port p0 FC1 2. openstack sfc port pair create --description "Firewall SF instance 1" --ingress p1 --egress p1 --service-function-parameters correlation=None PP1 3. openstack sfc port pair group create --port-pair PP1 PPG1 4. openstack sfc port chain create --port-pair-group PPG1 --flow-classifier FC1 --chain-parameters correlation=nsh PC1 we expect that the encapsulation/decapsulation will be performed by the back-end driver, so that the data packet passes through the nsh-unaware VNF like a regular data packet. However, we can see that the NSH packet reaches the VNF interface (screenshot attached). [image: 123.jpg] Flow table: [image: 螢幕擷取畫面 2021-02-06 153311.png] It seems NSH header not decapsulate before entering NSH-unaware VNF. Could you give us some advice? We really appreciate it. Regards, Zack [image: Mailtrack] <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> 03/13/21, 12:07:12 PM

1 0

[requirements][all] Openstack Requirements is now frozen
by Matthew Thode 12 Mar '21

12 Mar '21

As the title states, requirements is now frozen, any updates to the master branch not already approved from now until requirements branches the stable/wallaby branch will require a FFE email to be submitted to this (openstack-discuss) mailing list. -- Matthew Thode

1 0

Status of Qinling
by Tallman, Nathan 12 Mar '21

12 Mar '21

Hello OpenStack community, I'm trying to find out if Qinling is alive or dead. The GitHub repo<https://opendev.org/openstack/qinling/src/branch/master/README.rst> says it's archived and no longer maintained, but the project page<https://www.openstack.org/software/releases/rocky/components/qinling> on openstack.org doesn't mention anything about Qinling being abandoned. Can anyone shed light on this for me? Thanks, Nathan -- Nathan Tallman Digital Preservation Librarian Penn State University Libraries (814) 865-0860 ntt7(a)psu.edu<mailto:ntt7@psu.ediu> Schedule a Meeting<https://outlook.office365.com/owa/calendar/PennStateUniversityLibraries2@Pe…> Chat with me on Teams<https://teams.microsoft.com/l/chat/0/0?users=ntt7@psu.edu> [Microsoft Teams Logo]

2 1

[tripleo] Update: migrating master from CentOS-8 to CentOS-8-Stream - starting this Sunday (March 07)
by Ronelle Landy 12 Mar '21

12 Mar '21

Hello All, Just a reminder that we will be starting to implement steps to migrate from master centos-8 -> centos-8-stream on this Sunday - March 07, 2021. The plan is outlined in: https://hackmd.io/9Xve-rYpRaKbk5NMe7kukw#Check-list-for-dday In summary, on Sunday, we plan to: - Move the master integration line for promotions to build containers and images on centos-8 stream nodes - Change the release files to bring down centos-8 stream repos for use in test jobs (test jobs will still start on centos-8 nodes - changing this nodeset will happen later) - Image build and container build check jobs will be moved to non-voting during this transition. We have already run all the test jobs in RDO with centos-8 stream content running on centos-8 nodes to prequalify this transition. We will update this list with status as we go forward with next steps. Thanks!

3 5

Re: [openstack-community] [victoria][keystone][ops]Keystone enforced policy issues
by Amy Marrich 12 Mar '21

12 Mar '21

Adding the OpenStack discuss list > On Mar 12, 2021, at 6:34 AM, Luke Camilleri <luke.camilleri(a)zylacomputing.com> wrote: > > 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 > > > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community

1 0

[Nova][FFE] Smart-nic support
by yonglihe 12 Mar '21

12 Mar '21

Hi, Everyone Smart nics management involved Nova, Neutron and Cyborg. After 2 releases of discussing, coding and reviewing, we have merged Cyborg and Neutron support. Nova patches also got lots of attention and had many rounds of review, plus several +2. I hope we could merge Nova patches also in this release. The following is the Nova patches topic, individual patches links, and related resources links Now we blocked by lots of comments when reaching to the end of the feature freeze. Those comments could be addressed in 2-3 days, then we could get 3 more rounds review, very likely we could make it by RC1. Those comments include: • functional test -- released already. • minor typo, text changes, and needs more code comments • several codes flow refactor request • how to store arq-uuid ==nova patch topic link: https://review.opendev.org/q/topic:%22bp%252Fsriov-smartnic-support%22+(sta… ==nova individual patch link: 1) smartnic support - cyborg drive: two +2 https://review.opendev.org/c/openstack/nova/+/771362 2) smartnic support - new vnic type: rounds review https://review.opendev.org/c/openstack/nova/+/771363 3) smartnic support: main patch rounds review, one +2 https://review.opendev.org/c/openstack/nova/+/758944 4) smartnic support - reject server move and suspend, one +2 https://review.opendev.org/c/openstack/nova/+/779913 5) smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 == resource: 1) blueprint sriov-smartnic-support https://blueprints.launchpad.net/nova/+spec/sriov-smartnic-support 2) Approved spec: merged https://review.opendev.org/c/openstack/nova-specs/+/742785 3) Cyborg NIC driver: merged https://review.opendev.org/c/openstack/cyborg/+/758942 4) neutron patch sets: merged neutron patch set: merged https://review.opendev.org/q/topic:%22bug%252F1906602%22+ 5) neutron-lib: merged Add new VNIC types for Cyborg provisioned ports https://review.opendev.org/c/openstack/neutron-lib/+/768324 6) neutron ml2 plugin support: merged [SR-IOV] Add support for ACCELERATOR_DIRECT VNIC type https://review.opendev.org/c/openstack/neutron/+/779292 Yongli He Regards

2 1

[Nova][FFE] libvirt vdpa support
by Sean Mooney 12 Mar '21

12 Mar '21

Hi everyone its that time again where feature are almost ready but not quite. vDPA (vHost data path acceleration) is an option kernel device offload api that allows virtio complient software devices such as a virtio net interface to be offloaded to a software or hardware acclerator such as a nic. the full detail can be found in the spec: https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/lib… The series is up for review and gibi and stephen have been activly reviewing it over the last few day. https://review.opendev.org/q/topic:%22vhost-vdpa%22+(status:open%20OR%20sta… while the majority of the code now has +2s it wont be approved before the end of the day so i am formal asking for a feature freeze exception to allow an addtional day or to finalise the feature. the current status of the seriese id that there is one bug related to claiming pci device and marking the parent as unavaiable and claiming the parent and marking the child VF/VDPA devices as unavaiable. i have adressed this locally and will be pushing a patch to adress that later this evening once i add unit tests for thoes edgecaes. there is one patch that is pendeing to block unsupported lifecycle operation which i will be writing tomorrow. that final patch will also document them both in a release note and in the api-guide. in the evnet the full seriese is not deamed to be ready in time i have also written seperate patch to block booting vms with VDPA ports now that neutron supports it but nova does not, https://review.opendev.org/c/openstack/nova/+/780065 if we do not merge the full serise i would like to ask that we merge teh first 3 patches. openstack/nova: master: block vm boot with vdpa ports openstack/nova: master: objects: Add 'VDPA' to 'PciDeviceType' openstack/nova: master: add constants for vnic type vdpa the reason for block patch is that now that neutron support vnic-type vdpa i belive its possibel to create a port of that type and for nova to boot a vm however it will not actully use vdpa. i belvie it will take this else branch https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L… and result in the vm booting with a stansard ovs prot as if it was vnic-type=normal which will be confusing to debug since you were expecting to get hardware offloaed ovs but just got a standard ovs port instead without hardware offloads. operators can also block vnic-type vdpa in the neutron config. https://github.com/openstack/neutron/blob/a9fc746249cd34cb7cc594c0b4d74d8dd… but i think the nova solution is nicer since it does not require them to update there configs if this feature is not complted in Wallaby. i do belive we can complete this feature with only a small amount of addtional work and can continue to add more testing and lifecycle operations next cycle. stephen has submited https://review.opendev.org/c/openstack/nova/+/780112 to start extending the functional test framework to emulate vdpa devices so that we can harden the validation in the futrue via functional tests in addtion to the existing unit test coverage. i have not reviewed it yet so cant say how long that will take but i think that is something we can work and ensure it merged early next cycle if its not completed early next week. regards sean.

2 1

[release] Release countdown for week R-5 Mar 15 - Mar 19
by Herve Beraud 12 Mar '21

12 Mar '21

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the Wallaby deliverables can be proposed, well ahead of the final Wallaby release date (14 April, 2021). General Information ------------------- We are still finishing up processing a few release requests, but the Wallaby release requirements are now frozen. If new library releases are needed to fix release-critical bugs in Wallaby, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in Wallaby that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By 5 April, 2021 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/wallaby branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for Wallaby changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed Wallaby cycle-highlights yet, you are already late to the party. Please see http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020714… for details. Upcoming Deadlines & Dates -------------------------- RC1 deadline: 22 March, 2021 (R-3 week) Final RC deadline: 5 April, 2021 (R-1 week) Final Wallaby release: 14 April, 2021 Xena PTG: 19 - 23 April, 2021 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0