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

[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 17 Mar '20

17 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 16 Mar '20

16 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 14 Mar '20

14 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