June 2020 - openstack-discuss - lists.openstack.org

[all][qa] uWSGI release broke devstack jobs
by Andreas Jaeger 21 Jun '20

21 Jun '20

The new uWSGI 2.0.19 release changed packaging (filename and content) and thus broke devstack. The QA team is currently fixing this, changes need backporting to fix grenade as well. On master, change [1] was merged to use distro packages for Ubuntu and Fedora instead of installation from source for uWSGI. CentOS and openSUSE installation is not fixed yet ([2] proposed for openSUSE). Thus, right now this should work again: * Fedora and Ubuntu the devstack jobs on master Other distributions and branches and grenade are still broken. Please do NOT recheck until all fixes are in. If you want to help, best reach out on #openstack-qa. Thanks especially to Jens Harbott for driving this! Andreas [1] https://review.opendev.org/577955 [2] https://review.opendev.org/735519 -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

3 3

[tripleo] CI is red
by Wesley Hayutin 19 Jun '20

19 Jun '20

Greetings, It's a been a week that started w/ CentOS mirror outage [0], followed by breaking changes caused by CentOS-8.2 [.5] and has not improved much since. The mirror issues are resolved, the updates required for CentOS-8.2 have been made here's the latest issue causing your gate jobs to fail. tripleo-common and python-tripleoclient became out of sync and started to fail unit tests. You can see this in the dlrn builds of your changes. [1] There was also a promotion to train [2] today and we noticed that mirrors were failing on container pulls for a bit (train only). This should resolve over time as the mirrors refresh themselves. Usually the mirrors handle the promotion more elegantly. CI status is updated in the $topic in #tripleo. I update the $topic as needed. Tomorrow is another day.. [0] https://bugs.launchpad.net/tripleo/+bug/1883430 [.5] https://bugs.launchpad.net/tripleo/+bug/1883937 [1] https://bugs.launchpad.net/tripleo/+bug/1884138 http://dashboard-ci.tripleo.org/d/wb8HBhrWk/cockpit?orgId=1&var-launchpad_t… http://status.openstack.org/elastic-recheck/ http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:… https://6f2b36b80678b13e4394-1a783ef91f61ec7475bcc10015912dcc.ssl.cf2.rackc… [2] https://trunk.rdoproject.org/centos7-train/

1 3

Re: Switching the Interop meeting from irc to meetpad + next week Friday 26 UTC 17 - agenda
by prakash RAMCHANDRAN 19 Jun '20

19 Jun '20

Hi all, The irc was unkind to us and cancelled today's meeting of #openstack-interop. Appreciate for your considerations - lets go back and revive meetpad from next week and we will be better off as with less than 30 people this option will be better than either zoom or irc, as we do have an "Interop-WG-weekly-meeting" established. https://meetpad.opendev.org/Interop-WG-weekly-meeting or (https://meetpad.opendev.org) After click join by entering - Interop-WG-weekly-meeting - courtesy - Kendall [extra benefit of including etherpad integration (the videoconference doubles as an etherpad document, avoiding jumping between windows).] Agenda for next Friday 26th June 17 UTC / 10 PDT call on meetpad: (If you can solve through email do answer back) (Please update if you need changes - https://etherpad.opendev.org/p/interop) 1.Interop Ussusri Guidelines established - documented the details in here and merged. https://storyboard.openstack.org/#!/story/2007510 https://storyboard.openstack.org/#!/story/2007509 2. To supersede or abandon this.https://blueprints.launchpad.net/refstack/+spec/interop-2020.06 - Ghanshyam or Mark - please confirm 3. Marketplace participants Regards to Survey questions - https://storyboard.openstack.org/#!/story/2007511 4. The Content & Procedure of Survey to be identified and agreed - How to send message to Vendors , Distro's, Hosting Partners and other Marketplace participants to test for Logo updates for 2020.06 Ussuri cycle - Consistency in meeting times on irc and websites - Update site for logo - https://www.openstack.org/brand/interop/ - update site for irc meeting time - https://refstack.openstack.org/#/about#about 5. Implementing updates to project governance - https://opendev.org/openstack/governance/src/branch/master/reference/projec… to enable tag assert:supports-api-interoperability (for Core + Add-ons for Integrated Projects) - tags: - - tc:approved-release - - starter-kit:compute - - vulnerability:managed - - assert:follows-standard-deprecation - - assert:supports-upgrade - - assert:supports-rolling-upgrade - - assert:supports-accessible-upgrade - - stable:follows-policy - - assert:supports-api-interoperability 6. Ideas for new logo programs to propose to Board working with TC- Any legal disclaimers or change required - Conformance or validation vs. compliance?- Revising Object Storage Logo for Swift Compliance (For paid partners)- Bare Metal Ironic- Container Projects - Airship Cloud to StarlingX Edge Interop,- kubernetes Conformance for OpenStack & Opne Infra Projects. Chair / Interop WG (Prakash Ramchandran)Co-Chairs (Mark V.Voelker & Ghanshyam Maan) Platinum Partner Rep. from Board (Arkady Kanevsky) On Friday, June 19, 2020, 10:27:16 AM PDT, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: Hi, All I tried to get into irc and its way slow and not sure what nic registration and are access issues are for irc.Either you would have started the meeting and continued on the topics listed in agenda or I assume its cancelled. We will regroup next week but looks like again coming back to only zoom as option and so will setup with either Openstack Staff or go back to Dell Zoom as my only option. My apology, all botched up on communication for last 4 weeks with no real verbal communications. It has been a challenge for me, previous StarlingX vs Airship meeting went off well but this happened, not sure why and still tring to track irc issues. Thanks Prakash

1 0

[tripleo] TripleO CI Summary: Unified Sprint 28
by Rafael Folco 19 Jun '20

19 Jun '20

Greetings, The TripleO CI team has just completed **Unified Sprint 28** (May 28 thru June 17). The following is a summary of completed work during this sprint cycle [1]: - Built internal component and integration pipelines by adding more baremetal and scenario jobs. OVB against PSI still in progress. - Continued to fix promoter tests on CentOS8. - Built an internal promoter server for the internal pipeline promotions. - Added TripleO IPA multinode job to integration pipeline in master, ussuri, and now train - Built CentOS8 train jobs upstream and created the CentOS8 version of promotion pipeline for train release. Still in progress, now based on a componentized DLRN - Tempest skip list and ironic plugin general improvements. - 3rd party dependency jobs for ceph-ansible. - Github pull request zuul jobs e.g. https://review.rdoproject.org/zuul/buildset/5aadebee715d49fc9f030b455a8d8f71 - Build ansible 2.9, ceph-ansible 2.4 - Execute against tripleo master, ussuri, train. - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on creating CentOS8 jobs for train release. The Ruck and Rover for this sprint are Sagi Shnaidman (sshnaidm), Soniya Vyas (soniya29) and Ronelle Landy (rlandy). 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 etherpad [4]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-28 [2] https://hackmd.io/YAqFJrKMThGghTW4P2tabA [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-29 [4] https://hackmd.io/XcuH2OIVTMiuxyrqSF6ocw

1 0

[kolla] Re: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.1.1 failed
by Sean McGinnis 19 Jun '20

19 Jun '20

On 6/19/20 5:45 AM, zuul(a)openstack.org wrote: > Build failed. > > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/3bb83ca0c7344c7cac47d912a724ea07 : SUCCESS in 1m 03s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/a54166b5f31340b1bdb6f28e4b4a8e61 : SUCCESS in 5m 22s > - announce-release https://zuul.opendev.org/t/openstack/build/5cee678de9b447428ca26b8b3ffd6ee7 : SUCCESS in 4m 07s > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/fb96f3ad6edd43d7a611377542db95bc : SUCCESS in 3m 22s > - kolla-publish-centos-source https://zuul.opendev.org/t/openstack/build/9c7921b0b4a64641974ae616b27f03dc : RETRY_LIMIT in 3m 18s > - kolla-publish-centos-binary https://zuul.opendev.org/t/openstack/build/0388a788ca8a48949c20f48c60b2b7ba : RETRY_LIMIT in 2m 42s (non-voting) > - kolla-publish-centos8-source https://zuul.opendev.org/t/openstack/build/eac8ad3447bc49c1b3d306bffd7f905d : RETRY_LIMIT in 3m 14s > - kolla-publish-centos8-binary https://zuul.opendev.org/t/openstack/build/e68f3f687d3c452c823017a355049f5d : RETRY_LIMIT in 5m 04s (non-voting) > - kolla-publish-debian-source https://zuul.opendev.org/t/openstack/build/4c5a39b30f834bd597b167208c8cf322 : RETRY_LIMIT in 2m 51s (non-voting) > - kolla-publish-debian-source-aarch64 https://zuul.opendev.org/t/openstack/build/None : NODE_FAILURE in 0s (non-voting) > - kolla-publish-debian-binary https://zuul.opendev.org/t/openstack/build/144b9b8109804f8daa23bca8cc4a41d6 : RETRY_LIMIT in 2m 36s (non-voting) > - kolla-publish-ubuntu-source https://zuul.opendev.org/t/openstack/build/23f44f0a4ccb484c81abc76d0a7627d7 : RETRY_LIMIT in 3m 52s > - kolla-publish-ubuntu-binary https://zuul.opendev.org/t/openstack/build/a2ba0db9d974424f9f8424fef14d8e38 : RETRY_LIMIT in 3m 29s (non-voting) I haven't looks at all of these, but it looks like these kolla jobs need to be updated to have the ensure_pip role added like we've had to do for some of the other release jobs. My guess would be ensure_pip needs to be added somewhere like here: https://opendev.org/openstack/kolla/src/branch/master/tests/playbooks/pre.y… But I think someone from that team will need to look into that. Sean

3 2

[kolla] Kolla Klub meeting
by Mark Goddard 19 Jun '20

19 Jun '20

Hi, The next Kolla klub meeting is scheduled for Thursday at 15:00 UTC. We'll have a summary of the recent PTG discussions and some open discussion. Please bring ideas for discussion topics! https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Thanks, Mark

1 1

[nova][oslo][rabbitmq][compute]
by Amjad Kotobi 19 Jun '20

19 Jun '20

Hi all, After trying to upgrade last piece of release Stein to Train which were all “python-oslo*” & “python2-oslo*” packages along with some others, nova computes status changed to “DOWN”, and from nova-compute.log below logs ERROR oslo.messaging._drivers.impl_rabbit [req-de95c598-8e72-46ad-aba6-1b26893ccad7 - - - - -] [739dc403-021e-4bba-a31a-3d86f3d7a908] AMQP server on controller5:5672 is unreachable: Server unexpectedly closed connection. Trying again in 1 seconds.: IOError: Server unexpectedly closed connection 2020-06-19 17:40:20.681 5518 INFO oslo.messaging._drivers.impl_rabbit [req-de95c598-8e72-46ad-aba6-1b26893ccad7 - - - - -] [739dc403-021e-4bba-a31a-3d86f3d7a908] Reconnected to AMQP server on controller5:5672 via [amqp] client with port 32894 This happened every two minutes or so. Connection between rabbitmq servers all looks fine and tested on port accessibility. Logs in rabbitmq got really nasty and after downgrading below packages(downgrade to Stein) all got to normal ############################# openvswitch.x86_64 python-openvswitch.x86_64 python-pycadf-common.noarch python2-automaton.noarch python2-barbicanclient.noarch python2-castellan.noarch python2-cliff.noarch python2-debtcollector.noarch python2-django-horizon.noarch python2-etcd3gw.noarch python2-eventlet.noarch python2-futurist.noarch python2-kombu.noarch python2-os-brick.noarch python2-os-client-config.noarch python2-os-ken.noarch python2-os-vif.noarch python2-os-win.noarch python2-osprofiler.noarch python2-ovsdbapp.noarch python2-pycadf.noarch python2-qpid-proton.x86_64 python2-simplejson.x86_64 python2-stevedore.noarch python2-swiftclient.noarch python2-taskflow.noarch python2-tenacity.noarch python2-tooz.noarch qpid-proton-c.x86_64 ########################## I’m not sure completely but suspecting in “kombu”. Also after rabbitmq got in high load and high ratio of failure “cinder” services got to DOWN too. Any idea will be great, thanks

1 0

[Neutron] Drivers meeting agenda - 19.06.2020
by Slawek Kaplonski 19 Jun '20

19 Jun '20

Hi, Here is the agenda for tomorrows drivers meeting. I want to discuss few RFEs there: - https://bugs.launchpad.net/neutron/+bug/1880532 - L3 Router should support ECMP - this is continuation of the discussion from previous meeting. There is also spec proposed for that one https://review.opendev.org/#/c/729532/ - https://bugs.launchpad.net/neutron/+bug/1751040 - Extended resources should not always calculate all attributes - old RFE but we should discuss that finally, - https://bugs.launchpad.net/neutron/+bug/1882804 - allow replacing the QoS policy of bound port - this one is follow up after nova-neutron discussion during the PTG. TBH I don't think we will need a lot of discussion about that but still it needs an approval. There are also 2 items in "On demand agenda": - (ralonsoh) [RFE] Optional NUMA affinity for neutron ports (commented in the PTG and scheduled to be commented here before). BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1791834. No LP or BP created, this is just to present and discuss the idea of **using or not the QoS API** for this RFE. - (slaweq) We are deprecating neutron-fwaas. What with the API-REF? It's question from the ML http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015508.html As agenda is pretty busy, I would like to start with On Demand agenda tomorrow and then continue with RFEs according to how much time we will have. See You on the meeting tomorrow. -- Slawek Kaplonski Senior software engineer Red Hat

2 2

[neutron][fwaas] Removal of neutron-fwaas projects from the neutron stadium
by Slawek Kaplonski 19 Jun '20

19 Jun '20

Hi, In Shanghai PTG we agreed that due to lack of maintainers of neutron-fwaas project we are going to deprecate it in neutron stadium in Ussuri cycle. Since then we asked couple of times about volunteers who would like to maintain this project but unfortunatelly there is still lack of such maintainers. So now, as we are already in Victoria cycle, I just proposed serie of patches [1] to remove master branch of neutron-fwaas and neutron-fwaas-dashboard from the neutron stadium. Stable branches will be still there and can be maintained but there will be no any code in master branch and there will be no new releases of those 2 projects in Victoria. If You are using this project and wants to maintain it, You can respin it in x/ namespace if needed. Feel free to ping me on IRC (slaweq) or by email if You would have any questions about that. [1] https://review.opendev.org/#/q/topic:retire-neutron-fwaas+(status:open+OR+s… -- Slawek Kaplonski Senior software engineer Red Hat

3 3

[release] Release countdown for week R-16, Jun 22 - Jun 26
by Sean McGinnis 19 Jun '20

19 Jun '20

Development Focus ----------------- We are now past the victoria-1 milestone. Teams should now be focused on feature development and completion of release cycle goals [0]. [0] https://governance.openstack.org/tc/goals/selected/victoria/index.html General Information ------------------- Our next milestone in this development cycle will be victoria-2, on July 30. This milestone is when we freeze the list of deliverables that will be included in the Victoria final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/victoria directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Victoria-2 milestone: July 30 Ussuri cycle-trailing deadline: August 13

1 0

Re: [Release-job-failures] Release of openstack/puppet-nova for ref refs/tags/15.6.0 failed
by Thierry Carrez 19 Jun '20

19 Jun '20

zuul(a)openstack.org wrote: > Build failed. > > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/fd8c86f9b57947239bd0273424e1d4d5 : FAILURE in 2m 30s > - release-openstack-puppet https://zuul.opendev.org/t/openstack/build/05dd9c7ffdc74af5ae4065eb16a522f9 : SUCCESS in 5m 40s > - announce-release https://zuul.opendev.org/t/openstack/build/188851ebacf9455ab50edc2101ae02bc : SUCCESS in 5m 31s Github mirroring failure as a concurrent mirror operation already synced that tag up. Can be safely ignored. -- Thierry Carrez (ttx)

1 0

[all][InteropWG] Request to review tests your Distro for 2020.06 draft guidelines
by prakash RAMCHANDRAN 18 Jun '20

18 Jun '20

Hi all, Please review your tests for Draft 2020.06 guidelines to be proposed to Board.You can do that on and should start appearing in next 24-48 hours depending on Zuulhttps://refstack.openstack.org/#/community_results Plus please register for InteropWG PTG meet on June 1 st 6AM-*AM PDT slot See etherpadsPTG eventhttps://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020S… invite Tempest, TC members, QA/API SIG teams, Edge SIG WG , Baremetal SIG (for Ironic), K8s SIG (for OoK / KoO) & Scientific SIG teams. Other discussions https://etherpad.opendev.org/p/interop2020 Welcome to join weekly Friday Meetings (Refer NA/EU/APJ in etherpad below) https://etherpad.opendev.org/p/interop Appreciate all support from committee and special appreciation to Mark T Voelker for providing the bridge.He has been immensely valuable in bringing as Vice Chair the wealth of history to enable this Interop WG. ThanksPrakash

2 3

[cinder] impending SPECS FREEZE
by Brian Rosmaita 18 Jun '20

18 Jun '20

To all people with unmerged proposed Cinder specs: The spec freeze is less than 2 weeks away (Wed 1 July at 23:59 UTC). If you have questions or want live discussion of issues, take advantage of next week's Cinder virtual mid-cycle: DATE: 24 JUNE 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 Add your spec to the list of topics: https://etherpad.opendev.org/p/cinder-victoria-mid-cycles All proposed specs were discussed at the Victoria Virtual Midcycle; see the PTG etherpad for comments about yours: https://etherpad.opendev.org/p/victoria-ptg-cinder Additionally, the etherpad has links to recordings of the discussions. cheers, brian

1 0

[OSSN-0086] erratum: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
by Brian Rosmaita 18 Jun '20

18 Jun '20

As you may recall, the fix for this issue required patches for both Cinder and the os-brick library. The original patch for os-brick contained a flaw [0] that prevented the scaleio connector from operating when run under Python 2.7. Thus for OpenStack releases supporting Python 2.7 (that is, Train and earlier), a second os-brick patch is required and is listed below. (The Cinder and first os-brick patch are unchanged, but are listed below for completeness). [0] https://bugs.launchpad.net/os-brick/+bug/1883654 #### Patches #### Queens * cinder: https://review.opendev.org/733110 * os-brick: https://review.opendev.org/733104 and https://review.opendev.org/736749 Rocky * cinder: https://review.opendev.org/733109 * os-brick: https://review.opendev.org/733103 and https://review.opendev.org/736415 Stein * cinder: https://review.opendev.org/733108 * os-brick: https://review.opendev.org/733102 and https://review.opendev.org/736395 Train * cinder: https://review.opendev.org/733107 * os-brick: https://review.opendev.org/733100 and https://review.opendev.org/735989 Updated releases of os-brick incorporating the second patch are now available: Stein: os-brick 2.8.6 Train: os-brick 2.10.4 Point releases of cinder for Stein and Train will be made as soon as possible. These will be: Stein: cinder 14.1.1, requires os-brick 2.8.6 Train: cinder 15.2.1, requires os-brick 2.10.4 ### Contacts / References ### Author: Brian Rosmaita, Red Hat OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-10755

1 0

Re: [Release-job-failures] Release of openstack/puppet-nova for ref refs/tags/15.6.0 failed
by Emilien Macchi 18 Jun '20

18 Jun '20

Interesting. The tag was pushed but upload-git-mirror role failed: https://22ce6cebe995c8915d66-868b7eb6ba44b32e3b412bc5acf60e73.ssl.cf5.rackc… Is this a known issue? On Thu, Jun 18, 2020 at 2:23 PM <zuul(a)openstack.org> wrote: > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/fd8c86f9b57947239bd0273424e1d4d5 > : FAILURE in 2m 30s > - release-openstack-puppet > https://zuul.opendev.org/t/openstack/build/05dd9c7ffdc74af5ae4065eb16a522f9 > : SUCCESS in 5m 40s > - announce-release > https://zuul.opendev.org/t/openstack/build/188851ebacf9455ab50edc2101ae02bc > : SUCCESS in 5m 31s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Emilien Macchi

3 4

[all][api] Service discovery guidelines moving into frozen state
by Michael McCune 18 Jun '20

18 Jun '20

hello all, this is a general advisory from the API SIG to inform the wider community that we are moving 2 guidelines[0][1] into a frozen state for final review. You can learn more about the API SIG guideline process in this document[2]. These guidelines have been in the drafting stage for quite a long time and it is with much exuberance that i send this message. I would also like to give special thanks to Monty Taylor for his continued guidance and oversight. if you are listed as a cross project liaison for the API SIG, you have automatically been added to the reviewer list for these merge requests. these guidelines will be merged in 1 week if there are no objections on the reviews. peace o/ [0] https://review.opendev.org/#/c/459710 [1] https://review.opendev.org/#/c/459405 [2] https://specs.openstack.org/openstack/api-sig/process.html

1 0

[edge] Edge summaries from the virtual PTG
by Ildiko Vancsa 18 Jun '20

18 Jun '20

Hi, It was great seeing many of you at the virtual PTG two weeks ago. I wrote up two blog posts to summarize edge related sessions at the event: * Edge Computing Group recap: https://superuser.openstack.org/articles/osf-edge-computing-group-ptg-overv… * StarlingX recap: https://www.starlingx.io/blog/starlingx-vptg-june-2020-recap/ The articles have pointers to the etherpads we used at the event and include further pointers as well in case you would like to follow up on either discussion item or missed the event and would like to get a somewhat detailed view of what was discussed. Thanks and Best Regards, Ildikó

1 0

mox3 project retirement
by Sean McGinnis 18 Jun '20

18 Jun '20

Hey everyone, Way back in Rocky, we had a cycle goal to stop using mox/mox3: https://governance.openstack.org/tc/goals/selected/rocky/mox_removal.html The mox library itself is from the broader community, but mox3 specifically was a fork we were maintaining of that lib to add Python 3.x support. Not a lot has been happening there (or luckily needed either), but it is still a repo we have had to maintain while we were transitioning away from mox to mock. There were still a few repos that had mox3 in their requirements files, even though I think in most cases the actual use was dropped awhile ago. With these recent set of patches to clean that up, and remove it from global requirements, we now no longer have any repos in the openstack/* namespace referencing mox3: https://review.opendev.org/#/q/topic:remove-mox3+(status:open+OR+status:mer… This is to announce my intent to officially retire the mox3 repo and clean things up. Of course the lib is still out there in pypi, and can be used by others. It is also possible for the repo to be restored or forked elsewhere if someone not in openstack/* has a strong need for it. But at least within the OpenStack community, I think our time is better spent elsewhere. https://docs.openstack.org/mox3/latest/ https://opendev.org/openstack/mox3 Please raise any concerns here. Thanks, Sean

2 1

no-cache-dir patch bomb
by Monty Taylor 18 Jun '20

18 Jun '20

Hi all! We’ve apparently just gotten a bazillion patches uploaded that do a global search and replace to add —no-cache-dir to all of the pip commands it can find. I have a couple of issues with this and think people should be very careful about landing them a) —no-cache-dir is NOT universally a good idea, and in many cases for interactive install using it will be a worse user experience. The linked post is specifically about reducing docker image size. b) Importantly, it’s updating all of the end-user installation docs. That is highly inappropriate and makes our docs much more user unfriendly, especially given (a) c) In some install scripts we’re going to run them potentially in devstack. While constraints SHOULD prevent a large amount of reinstalling of different versions of things over and over, we all know reality is messier. I think we want to think carefully about removing cache dir usage in devstack as it could actually lead to an increase in install time, and optimizing for docker image size is not a thing we’re attempting to do in functional tests. Regarding the docker image size optimization, for those who are building docker images, I would highly recommend either installing from bistro packages or using builder-image pattern instead. We have one implemented in opendevorg/python-builder and opendevorg/python-base - but the pattern can be implemented elsewhere. The main idea/benefit is to use a builder image to install dev tools and -dev packages with headers and things needed to build wheels, build wheels for all of the dependencies - then in a second build stage copy the wheels from the builder image and install them. We’re using a “compile” tag in binder to indicate what packages are needed for compile-time tasks. The savings from this can be substantial - obviously at the cost of greater complexity. In any case, I HIGHLY recommend not landing any of these patches as submitted. Monty

2 1

[nova] stein to train upgrade
by Amjad Kotobi 18 Jun '20

18 Jun '20

Hi all, I tried to upgrade nova-compute from stein -> train release and “openstack-nova-compute” couldn’t able to start and from log here is coming up ################### 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service Traceback (most recent call last): 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 810, in run_service 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service service.start() 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/service.py", line 174, in start 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service self.manager.init_host() 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1337, in init_host 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service expected_attrs=['info_cache', 'metadata', 'numa_topology']) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 177, in wrapper 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service args, kwargs) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 241, in object_class_action_versions 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service args=args, kwargs=kwargs) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 181, in call 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=self.transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 129, in _send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 646, in send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 636, in _send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service raise result 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service RemoteError: Remote error: DBError (pymysql.err.InternalError) (1054, u"Unknown column 'instances.hidden' in 'field list ……. ################### I only took beginning part, the field doesn’t exist in DB, or? I also upgrade rest of the nova components[api-scheduler-conductor,…] but that didn’t go away. Any idea how to tackle this?

3 4

[all][release] One following-cycle release model to bind them all
by Thierry Carrez 18 Jun '20

18 Jun '20

Hi everyone, As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models. We used to have a single model (with milestones and RCs) but over time we grew a number of alternative models to accommodate corner cases. The result is a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid. I'd like to suggest we simplify this and have a single model for things that follow the development cycle: the "follows-cycle" model. The only alternative, its nemesis, its Wario would be the "independent" release model. In the "follows-cycle" model, deliverables would be released at least once per cycle, but could be released more often. The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release. The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. I feel like this would not change that much for deliverables following the cycle-with-rc model. It would not change anything for cycle-with-intermediary, libraries or cycle-trailing deliverables. But it would simplify our processes quite a bit, and generally make our releases more consistent. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.ht… -- Thierry Carrez (ttx)

12 31

[neutron] Tap-as-a-service releases on pypi behind
by Sam Morrison 17 Jun '20

17 Jun '20

It looks like tap-as-a-service project isn’t getting it’s latest releases pushed to pypi and this is breaking networking-midonet in train release. Source [1] has tags for releases 4.0.0, 5.0.0 and 6.0.0 but these aren’t in pypi [2] I need a fix [3] to upper-constraints to get this to work but just realised pypi is behind Can someone help me please. Thanks, Sam [1] https://opendev.org/x/tap-as-a-service/ <https://opendev.org/x/tap-as-a-service/> [2] https://pypi.org/project/tap-as-a-service/ <https://pypi.org/project/tap-as-a-service/> [3] https://review.opendev.org/#/c/735754/ <https://review.opendev.org/#/c/735754/>

4 8

[cinder] victoria virtual mid-cycle next week
by Brian Rosmaita 17 Jun '20

17 Jun '20

I know it seems early, but next week is R-16, and the spec freeze is R-15, so: Session One of the Cinder Victoria virtual mid-cycle will be held: DATE: 24 JUNE 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the etherpad: https://etherpad.opendev.org/p/cinder-victoria-mid-cycles (Session Two will be held during the R-9 week. We'll do a poll to select the day/time around R-11.) cheers, brian

1 0

[tc] weekly update
by Mohammed Naser 17 Jun '20

17 Jun '20

Hi everyone, Here’s an update for what happened in the OpenStack TC last week. You can get more information by checking for changes in openstack/governance repository. We have some reviews that have been open for quite some time without many reviews. I’d like to kindly ask our technical committee members to review them. # OPEN REVIEWS - [draft] Add assert:supports-standalone https://review.opendev.org/#/c/722399/ [open for 42 days] - Update joining-tc.rst to be general tc-guide.rst https://review.opendev.org/#/c/732983/ - Remove grace period on resolutions https://review.opendev.org/#/c/735361/ - Deprecatre neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/#/c/735828/ - Record deprecated cycle for deprecated project https://review.opendev.org/#/c/736084/ - Add openstack-ansible-os_adjutant repo https://review.opendev.org/#/c/736140/ - Merging TC and UC into a single body https://review.opendev.org/#/c/734074/ # PROJECT UPDATES - Add whitebox-tempest-plugin under QA https://review.opendev.org/#/c/714480/ - Clarify the support for linux distro https://review.opendev.org/#/c/727238/ - Rename ansible-role-lunasa-hsm deliverable https://review.opendev.org/#/c/731313/ - Select migrate-to-focal goal for Victoria cycle https://review.opendev.org/#/c/731213/ # PROJECTS RETIRED - Remove congress project team https://review.opendev.org/#/c/728818/ # GENERAL CHANGES - Propose Kendall Nelson for vice-chair https://review.opendev.org/#/c/733141/ - Add njohnston liaison preference https://review.opendev.org/#/c/733269/ - Add diablo_rojo liaison preferences https://review.opendev.org/#/c/733284/ - Add gmann liaison preference https://review.opendev.org/#/c/734894/ - Fix Rally PTL email address https://review.opendev.org/#/c/735342/ # GOAL UPDATES - Add QA branchless projects also in py3.5 support list https://review.opendev.org/#/c/729325/ Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[cyborg][neutron][nova] Networking support in Cyborg
by Nadathur, Sundar 17 Jun '20

17 Jun '20

Hi all, Based on the Victoria PTG discussion [1], here's a stab at making some aspects of the Nova-Neutron-Cyborg interaction more concrete. * Background: A smart NIC may have a single 'device' that combines the accelerator and the NIC, or two (or more) components in a single PCI card, with separate accelerator and NIC components. * What we said in the PTG: We should model the smart NIC as a single RP representing the combined accelerator/NIC for the first case. For the second case, we could have a hierarchy with separate RPs for the accelerator and the NICs, and a top-level resource-less RP which aggregates all the children RPs and combines their traits. (Correspondingly, Cyborg may represent it as a single object, which we call a Deployable, or as a hierarchy of such objects. There is already support in Cyborg for creating a tree of such objects, though it may need validation for this use case.) * Who creates these RPs? I suggest Cyborg create it in all cases, to keep it uniform. Neutron creates RPs today for the bandwidth provider. But, if different services create RPs depend on which feature is enabled and whether it is a single/multi-component device, that can get complex and problematic. So, could we discuss the possibility of Neutron not creating the RP? The admin should not configure Neutron to handle such NICs. * Ideally, the admin should be able to formulate the device profile in the same way, independent of whether it is a single-component or multi-component device. For that, the device profile must have a single resource group that includes the resource, traits and Cyborg properties for both the accelerator and NIC. The device profile for a Neutron port will presumably have only one request group. So, the device profile would look something like this: { "name": "my-smartnic-dp", "groups": [{ "resources:FPGA": "1", "resources:CUSTOM_NIC_X": "1", "trait:CUSTOM_FPGA_REGION_ID_FOO": "required", "trait:CUSTOM_NIC_TRAIT_BAR": "required", "trait:CUSTOM_PHYSNET_VLAN3": "required", "accel:bitstream_id": "3AFE" }] } Having a single resource group for resources/traits for both accelerator and NIC would ensure that a single RP would provide all those resources, thus ensuring resource co-location in the same device. That single RP could be the top-level RP of a hierarchy. (If they were separate request groups, there is no way to ensure that the resources come from a single RP, even if we set group_policy to None.) * During ARQ binding, Cyborg would still get a single RP as today. In the case of a multi-component device, Cyborg would translate that to the top-level Deployable object, and figure out what constituent components are present. For this scheme to work, it is important that the resource classes and traits for the accelerator RP and the NIC RP be totally disjoint (no overlapping resource classes or traits). * We discussed the physnet trait at the PTG. My suggestion is to keep Cyborg out of this, and out of networking in general, if possible. [1] https://etherpad.opendev.org/p/nova-victoria-ptg "Cyborg-Nova" Lines 104-164 Regards, Sundar

5 7