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

[kolla] Ceph transition plan
by Eric K. Miller 18 May '20

18 May '20

Hi, I noticed that in Kolla's master branch that Ceph has been removed, as expected for a deprecated component (I'm sad, though, since it works so well!). In the release notes, it is noted that "Prior to this we will ensure a migration path to another tool such as Ceph Ansible is available." Is this migration path documented since it appears that the latest release will not have the Kolla Ceph container available? Thanks! Eric

2 1

[ops] ops meetups team meeting 2020-5-5
by Chris Morgan 16 May '20

16 May '20

Hey all, The openstack ops meetups team has been fairly dormant recently for obvious reasons. However with the realisation that in-person meetups, conferences, summits etc are simply not coming back any time soon, we've started to regroup to discuss next steps. We are also seeing some requests for virtual meetups from some operators via the OpsMeetup twitter account. Thus we had a quick IRC meeting today, and also a trial run at an open source based video conference meeting using jitsi via an instance running on infra provided by Erik McCormick. This seems to be promising. We'll look into trialling some ops related events leveraging this. We also agreed to try and have an operators session during the upcoming virtual PTG (replacing the Vancouver event now cancelled). More info will be shared as and when we can. I hope you're all doing as well as can be expected. Chris - on behalf of the ops meetups team Meeting minutes: Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2020/ops_meetup_tea… 12:01 PM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2020/ops_meetup_tea… 12:01 PM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2020/ops_meetup_tea… -- Chris Morgan <mihalis68(a)gmail.com>

5 9

[barbican] Nominating Moisés Guimarães for barbican-core
by Douglas Mendizabal 16 May '20

16 May '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I would like to nominate Moisés Guimarães to be added to the barbican-core team. Moisés has been very helpful in helping us review barbican patches, and has done an excellent job of helping maintain the castellan library. If there are no objections, we will officially add Moisés to the team next week. Thanks, Douglas Mendizábal Barbican PTL -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEwcapj5oGTj2zd3XogB6WFOq/OrcFAl6+9XMACgkQgB6WFOq/ OrdzzxAAgxxymvuA+yGDuitEcjqwlggPJBYGb5PlHqqTkXcrS6IEcneG1eEJ/Rp2 JovTMN5sv3PwhtSMxjEmyrBVR9g6MKbQoQvDk1p77fFIL9ofIFV3xKOpZutnb3ig Y2/gSMWNDfuz7DPpNofUsyzvK5eBNWC8aBbpSeN0R4qLAlyOPFe6ftOAI1RvIX4W s6CwOiMQGGGNUK8TZgvG9BOOJorgMZ+maq4tFRN8P6bLA6q7kcsUob/LBIwCpoEF xdl9EO/IaRM4kMP8y/quIzDnBJV9Im4t8WrJ5sYNPnpfS+0yXseuCACAMYWSNp63 Zf9oRyIuv3Z/+z6qjcpkct/xhijdtB+Sc0MpmGv43RSoEHkYAGU6ue2nlZkVIow9 GO5Itq38WbORBIFwlGK+J+u40ikY+EjldzIwsxoBZDvuNMsGltpVclAkyW2VUwL3 HOyKPCm0dLiVz3qYo2dTH2eC2cdSbGxF91gckke1m5o69RDK9vYi6YQxtO0ms7Em yZoVQ6OnA4KCZUEd4sby7jWm/1ueXZq05BQgnB1tXbdMa6hDp6CwVKSAfH0fHS6D 5dCuo1EoDWxCTsh3lH0wogeODcCBReNTNCWEy/ia19aOO4cXrlpLznP6GONENwEo zbaPfwnmdw5Q1ARmLcEpgsbVF+mIymVkqGpNZ8DFA/wR+mQ/fkU= =Syoj -----END PGP SIGNATURE-----

2 1

[all][InteropWG] Request to PTLs for highligting Core Feature add-remove
by prakash RAMCHANDRAN 16 May '20

16 May '20

Hi all, Interop WG needs patches to complete the 2020.06 Ussuri guidelines. PTL or team members of CoreNovaNeutronCinderKeystoneGlanceSwiftadd-onHeat -OrchedtrationDesignate - DNS potential for Victoria add-onsIronicZunSenlinKolla & KuryrPlease suggest others Open Infra (Potential Bare Metal & Container APIs)StarlingXAirshipKata We are reviewing your release notes, but if you can advice us on non-amin APIs for Objects that you can qualify as core for current or future release please send Advisory with your module name. eg.Nova: Advisory - Cell API is potential candidate for core. etc. Alternate visit the TODO plan as on etherpad for interop next week callhttps://etherpad.opendev.org/p/interop Validate your APIs in community sitehttps://refstack.openstack.org/#/community_results Add your items for next week Fri 10 AM PDT call for Fri May 22nd. Plus if you want to attend and Present in PTG interopWG please add your topics and +1 those you like to see on June 1st 6-8 AM PDThttps://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020 Thankson behalf ofChair - InteropWG PrakashVice Chair - Mark T Voelker Sent from Yahoo Mail on Android

1 0

[neutron] 15-05-2020 drivers meeting agenda
by Slawek Kaplonski 15 May '20

15 May '20

Hi, For tomorrow's drivers meeting we have only one RFE to discuss: * https://bugs.launchpad.net/neutron/+bug/1877301 - L3 Router support ndp proxy It was initially triaged by Brian (Thank You) and discussed already on L3 subteam meeting. See You all tomorrow and have a nice day :) -- Slawek Kaplonski Senior software engineer Red Hat

2 1

[swift] Adding disks - one by one or all lightly weighted?
by Mark Kirkwood 15 May '20

15 May '20

Hi, We are wanting to increase the number of disks in each of our storage nodes - from 4 to 12. I'm wondering whether it is better to: 1/ Add 1st new disk (with a reduced weight)...increase the weight until full, then repeat for next disk etc 2/ Add 'em all with a (much i.e 1/8 of that in 1/ ) reduced weight...increase the weights until done Thoughts? regards Mark

2 2

[all] pep8 job failing due to flake8 3.8.0
by Ghanshyam Mann 15 May '20

15 May '20

Hello Everyone. You might have noticed that few or most of the projects pep8 job started failing. That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*. The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it. To fix your pep8 job you can, - Either fix the pep8 error in code if easy and fast to fix. - Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:mer… If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine. -gmann

4 12

OpenStack Ussuri Community Meeting Recordings & Presentation Decks
by Allison Price 15 May '20

15 May '20

Hi everyone, Thanks to all who joined or created content and presented at the community meetings yesterday! There were quite a few project updates presented for the Ussuri release. If you missed the meetings, you can find the recordings in this playlist [1] and links to the presentations are also included in the video abstracts. We have also posted both meeting recordings on Tencent Cloud, so you can watch the first community meeting [2] or the second community meeting [3] there as well. If you have any trouble accessing these resources, please let me know. Cheers, Allison [1] https://www.youtube.com/playlist?list=PLKqaoAnDyfgpYADSiOfIVwgKb5zbL0GJE <https://www.youtube.com/playlist?list=PLKqaoAnDyfgpYADSiOfIVwgKb5zbL0GJE>[2] https://v.qq.com/x/page/q0966o61rz9.html <https://v.qq.com/x/page/q0966o61rz9.html> [3] https://v.qq.com/x/page/d09667otaf1.html <https://v.qq.com/x/page/d09667otaf1.html> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[nova][gate] openstack-tox-docs job failure
by melanie witt 15 May '20

15 May '20

Howdy all, There's a upper-constraints bump to openstackdocstheme 2.1.0 which has recently merged [1] which is going to break the openstack-tox-docs job for nova. I've proposed a patch to fix it here: https://review.opendev.org/727898 if people could please take a look. Cheers, -melanie [1] https://review.opendev.org/727850

2 2

[neutron] parent ports for trunks being claimed by instances
by Nate Johnston 14 May '20

14 May '20

Neutron developers, I am currently working on an issue with trunk ports that has come up a few times in my direct experience, and I hope that we can create a long term solution. I am hoping that developers with experience in trunk ports can validate my approach here, especially regarding fixing current behavior without introducing an API regression. By way of introduction to the specifics of the issue, let me blockquote from the LP bug I raised for this [1]: ---- When you create a trunk in Neutron you create a parent port for the trunk and attach the trunk to the parent. Then subports can be created on the trunk. When instances are created on the trunk, first a port is created and then an instance is associated with a free port. It looks to me that's this is the oversight in the logic. From the perspective of the code, the parent port looks like any other port attached to the trunk bridge. It doesn't have an instance attached to it so it looks like it's not being used for anything (which is technically correct). So it becomes an eligible port for an instance to bind to. That is all fine and dandy until you go to delete the instance and you get the "Port [port-id] is currently a parent port for trunk [trunk-id]" exception just as happened here. Anecdotally, it's seems rare that an instance will actually bind to it, but that is what happened for the user in this case and I have had several pings over the past year about people in a similar state. I propose that when a port is made parent port for a trunk, that the trunk be established as the owner of the port. That way it will be ineligible for instances seeking to bind to the port. ---- Clearly the above behavior indicates buggy issue that should be rectified in master and stable branches. Nobody wants a VM that can't be fully deleted because the port can't ever be deleted. This is especially egregious when it causes heat stack deletion failures. I am mostly concerned that by adding the trunk as an owner of the parent port, then the trunk will need to be deleted before the parent port can be deleted, otherwise a PortInUse error will occur when the port is deleted (i.e. on tempest test teardown). That to me seems indicative of an inadvertent API change. Do you think it's all right to say that if you delete a port that is a parent port of a trunk, and that trunk has no other subports, that the trunk deletion is implicit? Is that the lowest impact to the API that we can incur to resolve this issue? Your wisdom is appreciated, Nate [1] https://bugs.launchpad.net/neutron/+bug/1878031

5 6