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

[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

[ops][glance][security] looking for metadefs users
by Abhishek Kekane 12 Mar '21

12 Mar '21

Hello operators and other people interested in metadefs, The Glance team will be giving the metadefs some love in the Xena development cycle in order to address OSSN-0088 [0]. The people who designed and implemented metadefs are long gone, and in determining how to fix OSSN-0088, we would like to understand how people are actually using them in the wild so we don't restrict them so much as to make them useless. We are looking for an operator who uses metadefs to give us a walkthrough on how you are using them at the Xena (virtual) PTG. We are planning to have this session on 23rd April around 1400 UTC. You can find more details about the same in PTG planning etherpad [1]. We are also willing to meet outside the PTG schedule in case the current scheduled time might be blocking the people. I will also reply to this as a reminder mail once our PTG schedule is final. If you do not use the metadef API for some reason related to its inability to solve a problem, lack of flexibility, or other reasons (but wish you could), we would also like to hear about that. We need to know if the feature is worth fixing and maintaining going forward. And when we say "an operator", we don't mean just one ... ideally, we'd like to have a few real-life use cases to consider. If this is affecting you (as an operator) then you can reach us either by mail or #openstack-glance IRC channel or glance weekly meeting [2] which will be held every Thursday around 1400 UTC. [0] https://wiki.openstack.org/wiki/OSSN/OSSN-0088 [1] https://etherpad.opendev.org/p/xena-ptg-glance-planning [2] https://etherpad.opendev.org/p/glance-team-meeting-agenda Thank you and Best Regards, Abhishek Kekane

6 9

[Multi-arch SIG] Xena PTG
by Rico Lin 12 Mar '21

12 Mar '21

Hi all As VPTG approaches (PTG will be held April 19th through April 23rd), I reserve a room on 4/20 Tuesday from 07:00-08:00 and 15:00-16:00 (UTC time). Exactly same as meeting schedule. We will use Meetpad this time. Let me know if you have any questions. You can find us on irc #openstack-multi-arch Please put your name in the PTG etherpad [1] if you plan to join. Also putting topic suggestions or comments on is more than welcome. Note: Don't forget to register PTG (for free) on [2]. [1] https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig [2] PTG Registration: https://april2021-ptg.eventbrite.com *Rico Lin* OIF Board director, OpenSack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack *Email: ricolin(a)ricolky.com <ricolin(a)ricolky.com>* *Phone: +886-963-612-021*

1 0

[heat] Xena PTG: same schedule as meeting time (4/21)(2 hours)
by Rico Lin 12 Mar '21

12 Mar '21

Hi all As VPTG approaches (PTG will be held April 19th through April 23rd), I reserve a room on 4/21 Wed. from 14:00-16:00 (UTC time). We will use Meetpad. this time. Let me know if you have any questions. Please put your name in the PTG etherpad [1] if you plan to join. Also putting topic suggestions or comments on is more than welcome. Note: Don't forget to register PTG (for free) on [2]. [1] https://etherpad.opendev.org/p/xena-ptg-heat [2] PTG Registration: https://april2021-ptg.eventbrite.com *Rico Lin* OIF Board director, OpenSack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack *Email: ricolin(a)ricolky.com <ricolin(a)ricolky.com>* *Phone: +886-963-612-021*

1 0

[manila] [FFE] Request for "Update cephfs drivers to use ceph-mgr" and "create share from snapshot support for CephFS"
by Victoria Martínez de la Cruz 12 Mar '21

12 Mar '21

Hi, I would like to ask for an FFE for the RFEs "Update cephfs drivers to use ceph-mgr" [0] and "Create share from snapshot support for CephFS" [1] Both RFEs are related. The first one updates the cephfs drivers to use the ceph-mgr interface for all manila operations. This change is required since the library currently used is already deprecated and it is expected to be removed in the next Ceph release. The second one leverages the previous one and adds a new functionality available through the ceph-mgr interface which is the create share from snapshot support. We have been working on both features for two cycles already and we could use a few more days to finish the testing. Looking forward to a positive response. Thanks, Victoria [0] https://blueprints.launchpad.net/manila/+spec/update-cephfs-drivers [1] https://blueprints.launchpad.net/manila/+spec/create-share-from-snapshot-ce…

2 1

[masakari] The legacy (client) has been dropped... finally!
by Radosław Piliszek 12 Mar '21

12 Mar '21

Hello Fellow OpenStackers, The Masakari team is proud to announce that the legacy Masakari client is no more! It has been deprecated since Stein and was less featureful than the OpenStack client plugin that was fully supported for a long time. The OSC plugin is also entirely based on OpenStack SDK. All Masakari client parts are available there. (This applies to Wallaby [version 7.0.0] and later.) -yoctozepto

1 0

[tacker] Xena PTG
by Yasufumi Ogawa 12 Mar '21

12 Mar '21

Hi, Next vPTG is going to be held 19-23 April. I've prepared etherpad for the PTG[1] and reserved same timeslots as previous, 6-8 am UTC from 20th Apr[2]. Please register from [3] and fill "Attendees" and "Topics" in the etherpad for your proposals. [1] https://etherpad.opendev.org/p/tacker-xena-ptg [2] https://ethercalc.net/oz7q0gds9zfi [3] https://april2021-ptg.eventbrite.com/ Thanks, Yasufumi

1 0

[TripleO] next irc meeting Tuesday Mar 16 @ 1400 UTC in #tripleo
by Marios Andreou 12 Mar '21

12 Mar '21

Reminder that the next TripleO irc meeting is: ** Tuesday 16 March at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on Mar 02nd - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-03-02-14.… Hope you can make it on Tuesday, thanks, marios

1 0

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Thierry Carrez 12 Mar '21

12 Mar '21

We got two similar release processing failures: > - tag-releases https://zuul.opendev.org/t/openstack/build/707bb50b4bf645f8903d8ca59b43abbf : FAILURE in 2m 31s This one was an error running the tag-releases post-merge job after https://review.opendev.org/c/openstack/releases/+/779217 merged. It failed with: Running: git push --dry-run ssh://release@review.openstack.org:29418/openstack/tripleo-ipsec.git --all ssh://release@review.openstack.org:29418/openstack/tripleo-ipsec.git did not work. Description: Host key verification failed. > - tag-releases https://zuul.opendev.org/t/openstack/build/655e8980a53c4e829de25f0b8507b5f6 : FAILURE in 2m 57s Similar failure while running the tag-releases post-merge job after https://review.opendev.org/c/openstack/releases/+/779218 merged. Since this "host key verification failed" error hit tripleo-ipsec three times in a row, I suspect we have something stuck (or we always hit the same cache/worker). -- Thierry Carrez (ttx)

5 7

[release][OpenstackSDK][masakari] request FFE on OpenstackSDK for python-masakariclient
by Herve Beraud 12 Mar '21

12 Mar '21

Hello folks, As discussed this morning on #openstack-release the masakari team needs OpenstackSDK changes that haven't been released. They have been merged after the final release [1]. Those aren't landed in OpenstackSDK version 0.54.0 [2]. Here is the delta of changes merged between 0.54.0 and 736f3aa1 ( https://review.opendev.org/c/openstack/openstacksdk/+/777299) $ git log --no-merges --online 0.54.0..736f3aa16c7ee95eb5a42f28062305c83cfd05e1 736f3aa1 add masakari enabled to segment Only these changes are in the delta. Do you mind if we start releasing a new version 0.55.0 to land these changes and unlock the path of the masakari team? Client library deadline is today. Also this topic opens the door for another discussion. Indeed it's questionable that openstacksdk should follow the early library deadline, for that precise reason. We release python-*client the same time as parent projects so that late features can be taken into account. It seems appropriate that openstacksdk is in the same bucket All those safeguards are a lot less needed now that we move slower and break less things. That could be translated by moving OpenstackSDK from `type: library` [3] to `type: client-library` [4]. Let us know what you think about the FFE. Let's open the discussions about the type shifting. [1] https://review.opendev.org/c/openstack/openstacksdk/+/777299 [2] https://opendev.org/openstack/releases/commit/b87ad4371321d5b0dde7ed0b23623… [3] https://releases.openstack.org/reference/deliverable_types.html#library [4] https://releases.openstack.org/reference/deliverable_types.html#client-libr… -- 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-----

2 3

[all][elections][ptl][tc] Combined PTL/TC Nominations March 2021 End
by Kendall Nelson 11 Mar '21

11 Mar '21

Hello! The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 8 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Barbican, Cyborg, Keystone, Mistral, Monasca, Senlin, Zaqar, Zun -- TC Election Details -- There are 0 projects that will have elections. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Mar 12, 2021 23:45 UTC. Thank you, -Kendall Nelson (diablo_rojo) & the Election Officials [0] https://governance.openstack.org/election/#xena-ptl-candidates [1] https://governance.openstack.org/election/#xena-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

3 2

Windows vm is not launching from horizon
by Midhunlal Nb 11 Mar '21

11 Mar '21

Hi all, I successfully installed the openstack rocky version and everything is working properly. ---->Uploaded all images to openstack and I can see all images listed through openstack CLI. +--------------------------------------+---------------------+--------+ | ID | Name | Status | +--------------------------------------+---------------------+--------+ | 1912a80a-1139-4e00-b0d9-e98dc801e54b | CentOS-7-x86_64 active | | 595b928f-8a32-4107-b6e8-fea294d3f7f1 | CentOS-8-x86_64 active| | f531869a-e0ac-4690-8f79-4ff64d284576 | Ubuntu-18.04-x86_64 active| | 7860193b-81bd-4a22-846c-ae3a89117f9d | Ubuntu-20.04-x86_64 active | 1c3a9878-6db3-441e-9a85-73d3bc4a87a7 | cirros active | d321f3a3-08a3-47bf-8f53-6aa46a6a4b52 | windows10 active --->same images I can see through horizon dashboard,but i am not able to launch windows VM from horizon dashboard .Balance all images launching from dashboard. Getting below error; Error: Failed to perform requested operation on instance "windows", the instance has an error status: Please try again later [Error: Build of instance 15a3047d-dfca-4615-9d34-c46764b703ff aborted: Volume 5ca83635-a2fe-458c-9053-cb7a9804156b did not finish being created even after we waited 190 seconds or 61 attempts. And its status is downloading.]. --->I am able to launch windows VM from openstack CLI What is the issue ?why I am not able to launch from dashboard?please help me. Thanks & Regards Midhunlal N B +918921245637

3 2

[neutron] Drivers meeting - agenda for 12.03.2021
by Slawek Kaplonski 11 Mar '21

11 Mar '21

Hi, For tomorrow's drivers meeting we have 2 RFEs related to the integration of Neutron with Designate: * https://bugs.launchpad.net/neutron/+bug/1904559 * https://bugs.launchpad.net/neutron/+bug/1918424 I didn't marked them as triaged yet as I'm not really sure what more data we could need in both cases. I hope that we will get some more questions during the meeting so we can at least together triage them :) Of course, please check those RFEs and ask for anything You need there, even before the meeting :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[cinder] review priorities for the next few days
by Brian Rosmaita 11 Mar '21

11 Mar '21

Here's the list of cinder and driver features that haven't yet merged: https://etherpad.opendev.org/p/cinder-wallaby-features Please make reviewing these your top priorities. We'll get back to reviewing bug fixes next week. cheers, brian

2 1

[all][tc] Thoughts on Python 3.7 support
by Pierre Riteau 11 Mar '21

11 Mar '21

Hello, There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8. Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon: - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237 What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported? Best wishes, Pierre Riteau (priteau)

9 13

[release][oslo][monasca][keystone] Moving projects to independent
by Herve Beraud 11 Mar '21

11 Mar '21

Hello teams, We are about to move a couple of projects under the independent release models [1]. Those did not have any change merged over the cycle, we think that it is the right time to transition them to independent. Oslo: - futurist - debtcollector - osprofiler Keystone: - pycadf Monasca: - monasca-statsd Before we push the button we want to give ourselves a last chance to raise the hand if you think that it's an issue. Concerning Oslo's projects we already had a related discussion a few months ago and all participants agreed with that [2]. Please let us know ASAP if you disagree with that choice. Thanks for your attention. [1] https://review.opendev.org/q/topic:%22move-to-independent%22+(status:open%2… [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018527… -- 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

[election][zun] PTL candidacy for Xena
by ZTE 11 Mar '21

11 Mar '21

Hi! I'd like to propose my candidacy and continue serving as Zun PTL in the Xena cycle. Over the Wallaby release, the Zun team continues to keep the Zun stable and reliable, and also some great works have been done. My goals for the Xena cycle are to continue the progress made in the following areas: * zun-conductor: Add a service called zun-conductor * CRI: Use the CRI interface to get inventory when cri driver configed for Capsule. * Affinity&anti-affinity: Add the affinity and anti-affinity policies to zun. Thank you for taking the time to consider me for Xena PTL. Best regards, Shengqin Feng

1 0

[security][security-sig] No meeting tomorrow March 11th
by Gage Hugo 11 Mar '21

11 Mar '21

The security sig meeting tomorrow has been cancelled. We will meet again at the regular time next week. Thanks

1 0

[nova][neutron] Can we remove the 'network:attach_external_network' policy check from nova-compute?
by melanie witt 11 Mar '21

11 Mar '21

Hello all, I'm seeking input from the neutron and nova teams regarding policy enforcement for allowing attachment to external networks. Details below. Recently we've been looking at an issue that was reported quite a long time ago (2017) [1] where we have a policy check in nova-compute that controls whether to allow users to attach an external network to their instances. This has historically been a pain point for operators as (1) it goes against convention of having policy checks in nova-api only and (2) setting the policy to anything other than the default requires deploying a policy file change to all of the compute hosts in the deployment. The launchpad bug report mentions neutron refactoring work that was happening at the time, which was thought might make the 'network:attach_external_network' policy check on the nova side redundant. Years have passed since then and customers are still running into this problem, so we are thinking, can this policy check be removed on the nova-compute side now? I did a local test with devstack to verify what the behavior is if we were to remove the 'network:attach_external_network' policy check entirely [2] and found that neutron appears to properly enforce permission to attach to external networks itself. It appears that the enforcement on the neutron side makes the nova policy check redundant. When I tried to boot an instance to attach to an external network, neutron API returned the following: INFO neutron.pecan_wsgi.hooks.translation [req-58fdb103-cd20-48c9-b73b-c9074061998c req-4d68df7e-e0fd-4b1e-9b57-733731123d46 demo demo] POST failed (client error): Tenant 7c60976c662a414cb2661831ff41ee30 not allowed to create port on this network [...] INFO neutron.wsgi [req-58fdb103-cd20-48c9-b73b-c9074061998c req-4d68df7e-e0fd-4b1e-9b57-733731123d46 demo demo] 127.0.0.1 "POST /v2.0/ports HTTP/1.1" status: 403 len: 360 time: 0.1582518 Can anyone from the neutron team confirm whether it would be OK for us to remove our nova-compute policy check for external network attach permission and let neutron take care of the check? And on the nova side, I assume we would need a deprecation cycle before removing the 'network:attach_external_network' policy. If we can get confirmation from the neutron team, is anyone opposed to the idea of deprecating the 'network:attach_external_network' policy in the Wallaby cycle, to be removed in the Xena release? I would appreciate your thoughts. Cheers, -melanie [1] https://bugs.launchpad.net/nova/+bug/1675486 [2] https://bugs.launchpad.net/nova/+bug/1675486/comments/4

3 5

[release][heat][ironic][requirements][swift][OpenStackSDK] Cycle With Intermediary Unreleased Deliverables
by Armstrong Foundjem 11 Mar '21

11 Mar '21

Hello! Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Wallaby cycle: heat-agents ironic-prometheus-exporter ironic-ui ovn-octavia-provider python-openstackclient requirements swift Those should be released ASAP, and in all cases before 22 March, 2021, so that we have a release to include in the final Wallaby release. - Armstrong Foundjem (armstrong)

1 0

[glance] Xena PTG (Apr 19 - 23)
by Abhishek Kekane 10 Mar '21

10 Mar '21

Hello All, Greetings!!! Xena PTG is announced and if you haven't already registered, please do so as soon as possible [1]. I have created a Virtual PTG planning etherpad [2]. Please add your PTG topic in the etherpad [2]. If you feel your topic needs cross project cooperation please note that in the etherpad which other teams are needed. I am planning to reserve time slots for the PTG between 1400 UTC to 1700 UTC. Please let me know if you have any concerns or suggestions with the given time slots. [1] https://www.openstack.org/ptg/ [2] https://etherpad.opendev.org/p/xena-ptg-glance-planning Thank you, Abhishek

1 0

[ISSUE]Openstack create VNF instance ERROR
by Jhen-Hao Yu 10 Mar '21

10 Mar '21

Dear Sir, This our testbed: Openstack (stein) + Opendaylight (neon) + ovs (v2.11.1) We have trouble when creating vnf on compute node using OpenStack CLI: #openstack vnf create vnfd1 vnf1 Here are the log message and ovs information. COMPUTE NODE1: nova-compute.log [image: error1.png] [image: list1.png] [image: vsctl1.png] COMPUTE NODE 2: nova-compute.log [image: error2.png] [image: list2.png] [image: vsctl2.png] We don't use DPDK on our Openvswitch. Can anyone give us some advice on this issue? Thanks for helping us. [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/09/21, 10:20:09 PM

2 2

[neutron] Xena PTG
by Slawek Kaplonski 10 Mar '21

10 Mar '21

Hi, If You plan to attend Neutron sessions during the Xena PTG, please fill in doodle [1] with the time slots which are good for You. Please do that before 19.03.2021 (next Friday) so I will have time to book slots which are the best for most of us. Please also add any topics You want to be discussed to the etherpad [2] [1] https://doodle.com/poll/cc2ste3emzw7ekrh?utm_source=poll&utm_medium=link [2] https://etherpad.opendev.org/p/neutron-xena-ptg -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0