May 2020 - openstack-discuss - lists.openstack.org

[oslo][nova][vmware] Replacement for suds library
by Stephen Finucane 14 May '20

14 May '20

The suds-jurko library used by oslo.vmware is emitting the following warnings in nova tests. /nova/.tox/py36/lib/python3.6/site-packages/suds/resolver.py:89: DeprecationWarning: invalid escape sequence \% self.splitp = re.compile('({.+})*[^\%s]+' % ps[0]) /nova/.tox/py36/lib/python3.6/site-packages/suds/wsdl.py:619: DeprecationWarning: invalid escape sequence \s body.parts = re.split('[\s,]', parts) These warnings are going to be errors in Python 3.10 [1]. We have over 18 months before we need to worry about this [2], but I'd like to see some movement on this well before then. It seems the suds-jurko fork is dead [3] and movement on yet another fork, suds-community, is slow [4]. How difficult would it be to switch over to something that does seem maintained like zeep [5] and, assuming it's doable, is anyone from VMWare/SAP able to do this work? Stephen [1] https://docs.python.org/3.9/whatsnew/3.9.html#you-should-check-for-deprecat… [2] https://www.python.org/dev/peps/pep-0596/ [3] https://bitbucket.org/jurko/suds/src/default/ [4] https://github.com/suds-community/suds/pull/32 [5] https://python-zeep.readthedocs.io/en/master/

5 6

[ironic] [release] Proposal for a new release model for ironic projects
by Dmitry Tantsur 14 May '20

14 May '20

Hi folks, I would like to formally present this proposal: https://review.opendev.org/#/c/725547/ It is largely driven by a desire to produce frequent supported and tested intermediate releases for standalone consumers, as well as address a few minor issues we've found over time. I would like to try applying it to Victoria already. Please read and comment. Thanks, Dmitry

1 0

[RDO][OpenStack] Removal of Pike and Ocata Trunk repos
by Yatin Karel 13 May '20

13 May '20

Hi, The topic was discussed in yesterday's RDO meeting[1] and to reach a wider audience it's being raised here. Ocata and Pike are in the Extended maintenance phase[2] for more than a year now, The promotion jobs which used to test these repos were dropped long ago[3][4]. Now we are planning to drop these trunk repos[5][6] in the first week of June, 2020. We already stopped building new commits for pike/ocata[7]. So if anyone still using these repos consider moving to upgrade to queens or any later releases. If something is blocking you to stop relying on ocata/pike repos raise your voice here so we can consider it before dropping the repos. [1] https://lists.rdoproject.org/pipermail/dev/2020-May/009379.html [2] https://releases.openstack.org/ [3] https://review.rdoproject.org/r/#/q/topic:remove_pike [4] https://review.rdoproject.org/r/#/c/16485/ [5] http://trunk.rdoproject.org/centos7-ocata/ [6] http://trunk.rdoproject.org/centos7-pike/ [7] https://softwarefactory-project.io/r/#/c/18347/ On Behalf of RDO Team Thanks and Regards Yatin Karel

1 0

[all] OpenStack Ussuri Community Meeting in 30 Minutes
by Allison Price 13 May '20

13 May '20

Hi everyone, I just wanted to remind you that there is a community meeting in 30 minutes to cover OpenStack Ussuri highlights. The meeting will be moderated by Mohammed Naser from the OpenStack Technical Committee and include project updates from: - Slawek Kaplonski, Neutron - Michael Johnson, Octavia - Goutham Pacha Ravi, Manila - Mark Goddard, Kolla - Balazs Gibizer, Nova - Brian Rosmaita, Cinder You can find dial-in information in this etherpad [1]. The recording and slides will be shared on the mailing list after the meeting. There will also be another meeting tomorrow, Thursday May 14 at 0200 UTC, moderated by Rico Lin from the OpenStack TC, and you can see who will be presenting here [1]. [1] https://etherpad.opendev.org/p/CommunityMeeting_Ussuri <https://etherpad.opendev.org/p/CommunityMeeting_Ussuri> Allison Price OpenStack Foundation allison(a)openstack.org

3 2

[all] OpenStack Ussuri Community Meeting Recording and time for Meeting 2
by Allison Price 13 May '20

13 May '20

Thank you to everyone who joined the community meeting earlier today to learn more about OpenStack Ussuri as well as the contributors who presented the release highlights! If you were unable to attend, you can check out the recording [1] which includes a link to the slides or check out the attached deck. There is also going to be another community meeting in 7.5 hours at 0200 UTC on Thursday, May 14. You can find the list of presenters as well as the dial-in information here [2]. [1] https://www.youtube.com/watch?v=T5-Dr1lxPB0&feature=youtu.be <https://www.youtube.com/watch?v=T5-Dr1lxPB0&feature=youtu.be> [2] https://etherpad.opendev.org/p/CommunityMeeting_Ussuri <https://etherpad.opendev.org/p/CommunityMeeting_Ussuri> Thanks! Allison Allison Price OpenStack Foundation allison(a)openstack.org

1 1

OpenStack Ussuri is officially released!
by Sean McGinnis 13 May '20

13 May '20

The official OpenStack Ussuri release announcement has been sent out: http://lists.openstack.org/pipermail/openstack-announce/2020-May/002035.html Thanks to all who were part of making the Train series a success! This marks the official opening of the releases repo for Victoria, and freezes are now lifted. Ussuri is now a full stable branch. Thanks! Sean

5 6

[kolla] Kolla klub meeting 21st May
by Mark Goddard 13 May '20

13 May '20

Hi, In today's Kolla IRC meeting we agreed to host a project onboarding session for the next Kolla Klub meeting on the 21st May. We'll cover a variety of topics on the many different ways you can contribute to the project. Gaël Therond will also fill us in on some of the questions put to him since the last meeting about his case studies. https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Thanks, Mark

1 0

[TripleO][Rdo][Train] Deploy OpenStack using only provisioning network
by Ruslanas Gžibovskis 13 May '20

13 May '20

Hi all, I am doing some testing and will do some deployment on some remote hosts. Remote hosts will use provider network only specific for each compute. I was thinking, do I really need all the External, InternalAPI, Storage, StorageManagemnt, Tenant networks provided to all of the nodes? Maybe I could use a Provision network for all of that, and make swift/glance copy on all computes to provide local images. I understand, if I do not have tenant network, all VM's in same project but in different sites, will not see each other, but it is ok at the moment. Thank you for your help -- Ruslanas Gžibovskis +370 6030 7030

3 6

[horizon][qa][infra] horizon master gate failure
by Akihiro Motoki 12 May '20

12 May '20

Hi, horizon master branch is now failing due to permission defined during installing tempest-horizon into the tempest venv [1]. It happens since May 9. The source tempest-horizon repo is located in /home/zuul/src/opendev.org/openstack/tempest-horizon/. I digged into the detail for a while but haven't figured out the root cause yet. I have the following questions on this: (1) Did we have any changes on the job configuration recently? stable/ussuri and master branches are similar but it only happens in the master branch. (2) When I changed the location of the tempest-horizon directory specified as tempest-plugins, the failure has gone [2]. Is there any recommendation from the tempest team? Thanks, -amotoki [1] https://zuul.opendev.org/t/openstack/build/9389be57c39d4971867abfa831bd3793 [2] https://review.opendev.org/#/c/726698/1/.zuul.yaml

3 2

Tox basepython and Python3
by Clark Boylan 12 May '20

12 May '20

Hello everyone, This has come up a few times on IRC so we are probably well overdue for a email about it. Long story short, if your tox.ini config sets basepython [0] to `python3` and you also use py35, py36, py37, or py38 test targets there is a good chance you are not testing what you intend to be testing. You also need to set ignore_basepython_conflict to true [1]. The reason for this is basepython acts as an override for the python executable to be used when creating tox virtualenvs. `python3` on most platforms indicates a specific python3 version: Ubuntu Xenial 3.5, Ubuntu Bionic and CentOS 8 3.6, and so on. This means that even though you are asking for python 3.7 via py37 you'll get whatever version `python3` is on the running platform. To address this we can set ignore_basepython_conflict and tox will use the version specified as part of the target and not the basepython override. You might wonder why using basepython is useful at all given this situation. The reason for it is the default python used by tox for virtualenvs is the version of python tox was installed under. This means that if tox is running under python2 it will use python2 for virtualenvs when no other version is set. Since many software projects are now trying to drop python2 support they want to explicitly force python3 in the default case. basepython gets us halfway there, ignore_basepython_conflict the rest of the way. [0] https://tox.readthedocs.io/en/latest/config.html#conf-basepython [1] https://tox.readthedocs.io/en/latest/config.html#conf-ignore_basepython_con… Hopefully this helps explain some of tox's odd behavior in a beneficial way. Now go and check your tox.ini files :) Clark

7 9