March 2020 - openstack-discuss - lists.openstack.org

Re: [Release-job-failures] Tag of openstack/glance_store for ref refs/tags/rocky-em failed
by Sean McGinnis 19 Mar '20

19 Mar '20

On 3/19/20 4:56 PM, zuul(a)openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 https://zuul.opendev.org/t/openstack/build/66b1173250724747bc9b7630277a5b1a : POST_FAILURE in 4m 24s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures This failure appears to be from a temporary glitch that we've seen time to time in the gate: "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" This was on publishing release notes. Since no new release notes have been added as part of this (just tagging rocky-em) it is safe to ignore this failure. Sean

1 0

[nova] bug triage
by Balázs Gibizer 19 Mar '20

19 Mar '20

Hi, We surpassed the somewhat magical line of having more than 100 untriaged nova bugs [1]. For me it seems that how we, as a team, are handling the incoming bugs is not sustainable. I'm guilty as well of not doing bug triage in a last two months. So I'm personally trying to change now and dedicate a weekly times lot to look at the bug list. But I also want to open a discussion about bug triage in genera. How can we handle the incoming bugs? I see that neutron does a weekly rotation of bug deputy and for them it works nicely. What do you think? Do we want to try that? Do we have enough volunteers to create a nice rotation period? Cheers, gibi [1] https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New

2 1

[python-openstackclient] --force bug
by jayaditya gupta 19 Mar '20

19 Mar '20

Hello all, new contributor/developer here. I have just submitted a bug for python-openstackclient project : https://storyboard.openstack.org/#!/story/2007440 I am not sure how to provide --force option to openstackclient .. I am comparing quota.py files in nova-client and in openstackclient.but can't seem to understand how to provide --force option. Any suggestions? Best Regards

3 3

[neutron]Drivers meeting cancelled
by Slawek Kaplonski 19 Mar '20

19 Mar '20

Hi, Due to lack of agenda, lets cancel tomorrows (20.03.2020) drivers meeting and lets focus on reviewing patches related to the already accepted RFEs [1]. [1] https://tinyurl.com/vezk6n6 — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][tc] Moving PTL role to "Maintainers"
by Mohammed Naser 19 Mar '20

19 Mar '20

Hi everyone: We're now in a spot where we have an increasing amount of projects that don't end up with a volunteer as PTL, even if the project has contributors .. no one wants to hold that responsibility alone for many reasons. With time, the PTL role has become far more overloaded with many extra responsibilities than what we define in our charter: https://governance.openstack.org/tc/reference/charter.html#project-team-lea… I think it's time to re-evaluate the project leadership model that we have. I am thinking that perhaps it would make a lot of sense to move from a single PTL model to multiple maintainers. This would leave it up to the maintainers to decide how they want to sort the different requirements/liaisons/contact persons between them. The above is just a very basic idea, I don't intend to diving much more in depth for now as I'd like to hear about what the rest of the community thinks. Thanks, Mohammed

24 34

[ops][cinder] deprecation notice: os-reset_status notifications
by Brian Rosmaita 19 Mar '20

19 Mar '20

tl;dr: the notifications themselves aren't being deprecated, there's a change in where they're being sent While working on https://launchpad.net/bugs/1863806, Walt discovered that notifications associated with the Block Storage API os-reset_status calls were being sent to nonstandard publisher_ids, namely: * 'volumeStatusUpdate' for volume status resets * 'volumeStatusUpdate' for snapshot status resets * 'backupStatusUpdate' for backup status resets Walt has a patch up to direct these notifications to the same publisher_id as other Cinder resource actions: * 'volume' for volume status resets * 'snapshot' for snapshot status resets * 'backup' for backup status resets Walt's patch continues to send the notifications to the nonstandard publisher_ids, but this behavior is DEPRECATED. In Ussuri, notifications will be sent to *both* publisher_ids. We propose to remove sending notifications to the nonstandard publisher_ids during the Victoria development cycle. This deprecation will be announced in the cinder release notes, but we wanted to give operators advance notice. No one currently working on cinder knows why these notifications were being sent to nonstandard publisher_ids, which makes it difficult to assess what, if any, impact this change will have on operators. If you have concerns about either the nonstandard publisher_ids being deprecated and removed, or about these notifications being sent to the standard publisher_ids, please express them on the following review before Tuesday 24 March: https://review.opendev.org/#/c/708563/ Thank you.

1 0

upgrade qemu 4.2 on CentOS 7.x for openstack
by Satish Patel 18 Mar '20

18 Mar '20

Folk, I am running openstack stein on CentOS 7.5 so default version of qemu-kvm is 2.12.x. as we know current qemu version is 4.2. Question: If i compile/install latest version of qemu 4.2 using source tarball on compute node in that case do i need to compile/install kvm or Libvirt? ~S

1 0

[all][elections][ptl][tc] Combined PTL/TC Election Season
by Kendall Nelson 18 Mar '20

18 Mar '20

Hello Everyone! Election details: https://governance.openstack.org/election/ The nomination period officially begins Mar 24, 2020 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you! -Kendall Nelson (diablo_rojo) & the Election Officials [1] https://governance.openstack.org/election/#election-officials

1 0

FW: 2020 OSF Events & coronavirus
by Mark Collier 18 Mar '20

18 Mar '20

I wanted to make sure everyone saw this thread on the foundation mailing list, since I know not everyone is subscribed to both lists: Archive: http://lists.openstack.org/pipermail/foundation/2020-March/002852.html Please join that ML thread to share feedback on this topic, or you can reach out directly to myself or jonathan(a)openstack.org I saw first hand how we all pulled together during the Snowpenstack in Dublin, so I know we'll once again pull together as a community to get through this! Mark On Friday, March 6, 2020 12:55pm, "Mark Collier" <mark(a)openstack.org> said: > Stackers, > > Before I get into the current plans for the OSF events in Vancouver and Berlin, I > wanted to say a few words in general about the virus impacting so many people > right now. > > First, I wanted to acknowledge the very difficult situation many are facing > because of COVID-19 (Coronavirus), across open source communities and local > communities in general (tech or otherwise). I also want to say to everyone who is > on the front lines managing events, from the full time staffers to the volunteers, > to the contractors and production partners, that we have some idea of what you're > going through and we know this is a tough time. If there's anything we can do to > help, please reach out. In the best of times, event organization can be grueling > and thankless, and so I just want to say THANK YOU to everyone who does the > organizing work in the communities we all care so much about. > > OSF 2020 EVENTS > > When it comes to the 2020 events OSF is managing, namely the OpenDev + PTG in > Vancouver June 8-11 and the Open Infrastructure Summit in Berlin October 19-23, > please read and bookmark this status page which we will continue to update: > https://www.openstack.org/events/covid-19-coronavirus-disease-updates > > When it comes to our community, the health of every individual is of paramount > concern. We have always aimed to produce events "of the community, by the > community" and the upcoming event in Vancouver is no exception. The OpenDev tracks > each morning will be programmed by volunteers from the community, and the project > teams will be organizing their own conversations as well each afternoon M-W, and > all day Thursday. > > But the larger question is here: should the show go on? > > The short answer is that as of now, the Vancouver and Berlin events are still > scheduled to happen in June (8-11) and October (19-23), respectively. > > However, we are willing to cancel or approach the events in a different way (i.e. > virtual) if the facts indicate that is the best path, and we know the facts are > changing rapidly. One of the most critical inputs we need is to hear from each of > you. We know that many of you rely on the twice-annual events to get together and > make rapid progress on the software, which is one reason we are not making any > decisions in haste. We also know that many of you may be unable or unwilling to > travel in June, and that is critical information to hear as we get closer to the > event so that we can make the most informed decision. > > I also wanted to answer a FAQ by letting everyone know that if either event is > cancelled, event tickets and sponsorships will be fully refunded. Please note that > if you're making travel arrangements (e.g. flights, hotels) those are outside of > our control. > > So as we continue to monitor the news and listen to health experts to make an > informed decision on any changes to our event plans, we'd like to hear from > everyone in the community who has a stake in these events. Our most pressing topic > is of course Vanvouver, but if you have questions or concerns about the Berlin > plan feel free to share those as well. > > If you'd like to connect directly, you can always contact Executive Director > Jonathan Bryce (jonathan(a)openstack.org) or myself (mark(a)openstack.org) > > Key Links: > - STATUS PAGE: > https://www.openstack.org/events/covid-19-coronavirus-disease-updates > - Vancouver OpenDev + PTG https://www.openstack.org/events/opendev-ptg-2020/ > - Berlin Open Infrastructure Summit: https://www.openstack.org/summit/berlin-2020/ > > Key Dates for OpenDev + PTG in Vancouver: > - Schedule will be published in early April > - Early bird deadline is April 4 > - Final day to sponsor will be May 4 > - Final registration price increase will be in early May > > Mark Collier > COO, OpenStack Foundation > @sparkycollier > >

11 11

Not running for TC this round
by Thierry Carrez 18 Mar '20

18 Mar '20

Hi everyone, I've been elected on the TC (or its previous incarnations) since we had community-elected seats in that body (2011). However, as announced during the previous election round (and in the discussion about reducing the number of TC seats) I do not plan to run for the TC in the upcoming election round. There are multiple reasons for this. The main one is that with name recognition and a Condorcet voting system, it's relatively easy for incumbents to be reelected. We only elect 5 seats this time, so I think it's important to make room for new names to step up. The second reason is that I'd like more people with an operational background to be present on the TC. I think we can simplify our governance by having a single elected body handling the open source project, rather than maintain separate representation for users and developers. As we get more people bringing operational perspective to the TC, that simplification will be even more obvious. The final reason is that I've always been saying that you can work on governance issues and voice your opinion on them, without being elected on the TC and formally voting on things. It's time for me to walk that talk. I do not intend to go anywhere, and I'll be as present as always in proposing the OpenStack governance changes that I deem needed in this day and age. I'll finish this email by encouraging anyone interested in open source project governance, or wanting to help shape the next chapter of the OpenStack story, to step up and run for TC election. As for all governance bodies, the experience can be frustrating, as you'd like to fix more things but there is only so much you can do. But it's a great experience, one that I recommend everyone working on open source project should have. The only prerequisite is an interest and care for "OpenStack" as a whole. No specific experience or diploma needed. If you wonder if you can do it, the answer is yes. Nominations[1] open up March 24. Please consider running, especially if you have operational experience with some cycles to spare. If you have any questions on the job, feel free to reach out to me -- you know where to find me. [1] https://governance.openstack.org/election/ -- Thierry Carrez (ttx)

3 2

[all][PTL][tc] U Community Goal: Project PTL & Contrib Docs Update #5
by Kendall Nelson 17 Mar '20

17 Mar '20

Hello Everyone! First off, I want to say thank you so much to Watcher, Trove, Searchlight, Qinling, Nova, Neutron, Kolla, Ironic, i18n, Glance, Cinder, and Blazar for getting started/completing the goal! For those projects that have not started yet, you can take a look at what the others have done for some inspiration[1], or simply fill in the template[2]. We did our best to make the process as low effort as possible. If you have any questions, please let me know or refer to the goal[3]. Once you get started, please make sure to keep the story up to date[4]. I look forward to reviewing your patches!! If there is anything I can do to help, please let me know. -Kendall (diablo_rojo) [1] Progress: https://review.opendev.org/#/q/topic:project-ptl-and-contrib-docs+(status:o… [2] Cookiecutter Template: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecu… [3] Accepted Goal: https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-c… [4] Task Tracking: https://storyboard.openstack.org/#!/story/2007236

1 0

Using #opendev on Freenode for OpenDev Infrastructure Discussions
by Clark Boylan 17 Mar '20

17 Mar '20

Hello all, We have reached a point in time where it now makes sense for us to use #opendev on Freenode for OpenDev discussions, rather than #openstack-infra. We are updating our various bots to reflect this change and are asking you to find us in the new channel. We expect this to be a time of transition so don't be afraid of bringing things up in either the old or new channel if you are unsure of where you should go; we'll get you pointed in the right direction. The old channel, #openstack-infra, won't be going away. We expect it to become more OpenStack specific. Topics like how to use Zuul for OpenStack jobs could go here. This likely will have some overlap with the #openstack-qa channel and we may end up collapsing them, but that can happen if we notice the conversations do overlap significantly. We hope this gives non OpenStack users a friendly neutral location to engage us. Sorry, for any disruptions this may cause. Clark

1 0

[all] Guides for newbies to OpenStack
by Mike Carden 17 Mar '20

17 Mar '20

Our small team at ${DAYJOB} has built a handful of OpenStack clusters based on Red Hat OpenStack 13 (aka Queens) over the last couple of years. We now find ourselves in the position of being 'gifted' human resources in the shape of mid-level 'IT people' who are sent to join our team for a short time to 'Learn OpenStack'. These tend to be people for whom, "Here's a Horizon URL and some creds - go log in and launch a VM"[1]... is a bit much. I've done a wee bit of web searching (enough to find the dead links) trying to find some newbie friendly tutorials on OpenStack basics. Before I attempt to re-invent the wheel, can anyone suggest some public resources I might point people to? Deity help us if we have to explain Tripleo's Undercloud, Overcloud, partially containered, partially pacemakered, fully flaky... underpinnings. Thanks, MC [1] Even with a step by step guide

5 4

[openstack-helm] Virtual Midcycle
by Gage Hugo 17 Mar '20

17 Mar '20

Good afternoon, The openstack-helm team will be hosting their virtual midcycle next Tuesday, March 24th 2020 at 1400 to 1700 UTC. Please check out the etherpad link for more details about the agenda and conferencing tool. Since this meeting is overlapping our normal meeting time, the actual IRC meeting will be canceled for next week. https://etherpad.openstack.org/p/osh-virtual-ptg-2020-03 Hope to see you all there.

1 0

OpenStack support for msgpack 1.0.0
by Thomas Goirand 17 Mar '20

17 Mar '20

Hi, msgpack 1.0.0 was released last Sept. I'm being pressed by the rest of Debian people to upload 1.0.0 to Sid. I'm concern by it: will this break any of the OpenStack package, like oslo.messaging? Is there any plan to have support for 1.0.0 for Ussuri? Cheers, Thomas Goirand (zigo)

5 5

[tc][requirements][horizon] Broken gates due to the new setuptools and pyScss package
by Ivan Kolodyazhny 17 Mar '20

17 Mar '20

Hi team, I'm sorry for being too noisy, but I decided to tag TC to get more attention to the current Horizon situation. We've got a bug reported by Kolla team two days ago [1]. We merged some workaround [2] and [3] yesterday. Thanks a lot to the Requirements team for the really quick merge! I appreciate it. For now, we've got horizon gates broken because of hose patches fix only devstack but not unit tests jobs. The root cause of this situation is pyScss package which is not maintained for the last two years. It's not a surprise to me that it doesn't work with the new setuptools. I'm really surprised that we've found this kind of bugs only now. Since I don't believe we can block new setuptools forever, I decided to fork pyScss [4] and django-pyscss [5] projects. I'm still not sure that I've done everything right with licensing and versioning, but it works now on my environment. Any help on these areas would be much appreciated. I proposed patches to requirements and horizon repos [6] to use new libraries. The reason I've tagged TC in the mail thread is described below. Horizon has a lot of too old and unmaintained libraries. I'm pretty sure that this only one of the first issues with outdated dependencies which blocks horizon and other gates. I do understand why we've got this situation. Unfortunately, we don't have any full-time horizon developers in the community. Horizon is mostly in maintenance phrase but not in active development. I would like to get more attention on this issue because we have to update all dependencies not because they are new, have new features and/or security fixes. We have to take care of our dependencies asap to avoid usage of unmaintained libraries to have the whole OpenStack and Horizon healthy. P.S. I'm sorry if this message is too rude or emotional, I really don't want to make it such one. [1] https://bugs.launchpad.net/kolla/+bug/1866961 [2] https://review.opendev.org/#/c/711930/ [3] https://review.opendev.org/#/c/712777/ [4] https://github.com/e0ne/pyScss/ [5] https://github.com/e0ne/django-pyscss [6] https://review.opendev.org/#/q/status:open+topic:fix-pyscss Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

5 5

[cinder] virtual mid-cycle session 2 summary available
by Brian Rosmaita 17 Mar '20

17 Mar '20

Hello Cinderinos, Thanks for a productive discussion yesterday. I've posted a summary on the wiki so we can remember what happened and for the edification of those who didn't attend: https://wiki.openstack.org/wiki/CinderUssuriMidCycleSummary A link to the recording will be posted on that page when it's available. cheers, brian

1 0

PyOS
by Martin Uhrin 16 Mar '20

16 Mar '20

Dear OpenStack devs, Just a quick question: I came across your project 'pyos' on pypi after using this name for internally one of my projects. I see that you haven't updated the package for some time and was wondering if it was dead and if so if you would consider transfering the name to me for hosting my project? Thanks for your time. All the best, -Martin

2 5

[ironic] proposing Iury Gregory for bifrost-core, ironic-inspector-core, sushy-core
by Julia Kreger 16 Mar '20

16 Mar '20

Iury has been working hard across the ironic community and has been quite active in changing and improving our CI, as well as reviewing code contributions and helpfully pointing out issues or items that need to be fixed. I feel that he is on track to join ironic-core in the next few months, but first I propose we add him to bifrost-core, ironic-inspector-core, and sushy-core. Any objections?

3 2

[ops] how to setup bgp-to-the-host and Neutron Dynamic Routing ?
by Thomas Goirand 16 Mar '20

16 Mar '20

Hi, In my setup, the bgp-to-the-host part is already operational. We're using IPv6 local link to 2 switches on each host, each of them advertising for itself to both routers. Now, I'm trying to add Neutron stuff to it. In my setup, I don't have any IPv4 on my nics, both have ipv6 local link only. So, where do I connect br-ex? I don't have a bond0 interface to connect to anymore... Then, we do have an FRR instance to do the bgp-to-the-host IPv4 routing on each host. How does this work on the hosts where the dr-agent is running? Can it re-use the FRR that I've setup to do the route advertisements too? Or do I need another instance of a routing daemon? Cheers, Thomas Goirand (zigo)

1 0

[Tempest] OpenSack Powered * vs OpeStack Compatible
by prakash RAMCHANDRAN 16 Mar '20

16 Mar '20

Hi all, I am curious to find out if any Distribution or Products based on Openstack Train or Usuri are seeking the latest certifications based on 2019.02. Similarly does any Hardware Driver of Software application seeking OpenStack compatibility Logo? Finally does anyone think that Open Infra Distro like Airship or StarlingX should promote Open Infra Airship or Open Infra StarlingX powered as a new way to promote eco system surrounding them similar to OpenStack compatible drivers and software. Will then Argo, customize, Metal3.io or Ironic be qualified as Open Infra Airship compatible? If so how tempest can help in testing the above comments? Refer to this market place below as how Distos and Products leverage OpenStack logos and branding programs. https://www.openstack.org/marketplace/distros/ Discussions and feedback are welcome. A healthy debate as how k8s modules used in Open Infra can be certified will be a good start. ThanksPrakash Sent from Yahoo Mail on Android

6 11

[tripleo][RDO] Version of Ansible in RDO CentOS8 repository
by Alfredo Moralejo Alonso 16 Mar '20

16 Mar '20

Hi all, During CentOS 8 dependencies preparation we've built ansible 2.9 in RDO dependencies repo which was released on Oct 2019, While testing TripleO with CentOS8 it has been discovered that the latest release of ceph-ansible does not support ansible 2.9 but only 2.8, so I'm opening discussion about the best way to move on in CentOS 8: - Make ceph-ansible 4.0 to work with ansible 2.8 *and* 2.9 so that the same releases can be used in CentOS7 with Stein and Train and CentOS8 Train and Ussuri. - Maintain separated ceph-ansible releases and builds for centos7/ansible 2.8 and centos8/ansible 2.9 able to deploy Nautilus. - Move ansible back to 2.8 in CentOS 8 Ussuri repository. I wonder if TripleO or other projects using ansible from RDO repositories has any requirement or need to move to ansible 2.9 in Ussuri cycle or can stay in 2.8 until next release, any thoughts? Best regards, Alfredo

1 2

[neutron] Bug deputy report (week starting on 2020-03-09)
by Bernard Cafarelli 16 Mar '20

16 Mar '20

Hello neutrinos, last week we started a new bug deputy rotation, opening this round here are the bugs reported in week 11. This was relatively quiet (for new bugs count), and most bugs have active discussion or suggested fix Critical * [security] Add allowed-address-pair 0.0.0.0/0 to one port will open all others' protocol under same security group - https://bugs.launchpad.net/neutron/+bug/1867119 A follow-up to security bug https://bugs.launchpad.net/neutron/+bug/1793029 (which was fixed in documentation) Potential code fix at https://review.opendev.org/712632 - reviews and opinions most welcome Medium * Restart neutron-linuxbridge-agent service led to all ports status changed - https://bugs.launchpad.net/neutron/+bug/1866743 Reported on Pike/Queens, pretty standard configuration, may be l2pop Related gerrit question: https://review.opendev.org/713156 * MTU too large error presented on create but not update - https://bugs.launchpad.net/neutron/+bug/1867214 Suggested fix: https://review.opendev.org/712801 Low * Packets incorrectly marked as martian - https://bugs.launchpad.net/neutron/+bug/1866615 Martian packets logged with some specific setup, VMs are working fine though, switching to ovs firewall workarounds the issue * Deployment has security group with empty tenant id - https://bugs.launchpad.net/neutron/+bug/1867101 Some master devstacks deployments like networking-odl get empty project ID for default security group * Unnecessary network flapping while update floatingip without port or fixed ip changed - https://bugs.launchpad.net/neutron/+bug/1867122 OVN mech driver only, some discussion about relevant use-case for FIP update in LP and patch https://review.opendev.org/712641 Incomplete * router-update for internal networking not correct when restarting ovs-agent - https://bugs.launchpad.net/neutron/+bug/1866635 Missing flows on restart, I asked for more logs - may be missing tunnel during restart Update from previous week * br-int bridge in one compute can't learn MAC addresses of VMs in other compute nodes - https://bugs.launchpad.net/neutron/+bug/1866445 Was closed as duplicate of bug #1732067 but they do not use OVS firewall Patch for iptables_hybrid proposed: https://review.opendev.org/712640 Last bug I triaged is 1867214, handing over the deputy baton to slaweq -- Bernard Cafarelli

1 0

[goals][Drop Python 2.7 Support] Week R-9 Update
by Ghanshyam Mann 15 Mar '20

15 Mar '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" at end of R-9 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * We already passed the deadline but still work is not completed on this. * Few pythonclient and tempest plugins are not merged yet. * I request projects again to merge the passing patches asap. Project wise status and need reviews: ============================ Phase-1 status: All the OpenStack services have dropped the python2.7. Phase-2 status: * Pending Tempest plugins: ** barbican-tempest-plugin: https://review.opendev.org/#/c/704083/ ** cyborg-tempest-plugin: https://review.opendev.org/#/c/704076/ ** kuryr-tempest-plugin: https://review.opendev.org/#/c/704072/ * Pending pythonclient: ** python-barbicanclient: https://review.opendev.org/#/c/699096/2 ** python-zaqarclient: https://review.opendev.org/#/c/692011/4 ** python-tripleoclient: https://review.opendev.org/#/c/703344 * Few more repo patches need to merge: ** masakari-specs: https://review.opendev.org/#/c/698982/ ** cyborg-specs: https://review.opendev.org/#/c/698824/ ** masakari-monitors: https://review.opendev.org/#/c/694552/ ** nova-powervm: https://review.opendev.org/#/c/700683/ ** paunch: https://review.opendev.org/#/c/703344/ ** cloudkitty: https://review.opendev.org/#/c/709585/3 * Started pushing the required updates on deployment projects. ** Completed or no updates required: *** Openstack-Chef - not required *** Packaging-Rpm - Done *** Puppet Openstack- Done ** In progress: *** Openstack Charms - Patches are ready to merge. Need review. *** Openstackansible - In-progress. centos7 jobs are failing on few projects. ** Waiting from projects team to know the status: *** Openstack-Helm (Helm charts for OpenStack services) *** Tripleo (Deployment service) * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open Phase-3 status: This is audit and requirement repo work which is not started yet. I will start this once all the phase-2 work mentioned above is completed. How you can help: ============== - Review the patches. Push the patches if I missed any repo. -gmann

1 0

[requirements][all] migration OFF of mock to the unittest.mock built-in library
by Matthew Thode 13 Mar '20

13 Mar '20

I'd like to suggest, now that we are on modern python, that we stop using the mock library and instead use the built in mock library. unittest.mock has been around since python-3.3 so we should not have a problem with python support. This would allow us to drop a library and also help prevent issues with stuff like https://review.opendev.org/712713 is going to expose (nova/neutron fail tests with the external mock-4 library). -- Matthew Thode

5 6