April 2020 - openstack-discuss - lists.openstack.org

[tripleo] ptg meetings and time zones
by Wesley Hayutin 16 Apr '20

16 Apr '20

Greetings, Looking to see if there are strong preferences for our time slots for the PTG. I would suggest we try to shoot for 13-17 UTC slot [1] as much as possible. Any strong preference in not utilizing that time slot? Reminder.. topics topics topics Thanks all 0/ [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.opendev.org/p/tripleo-victoria-topics <https://etherpad.opendev.org/p/tripleo-victoria-topics>

3 2

[TripleO][Ironic] pxe boot remote host
by Ruslanas Gžibovskis 16 Apr '20

16 Apr '20

Hi all, Could someone help me, I do not get, I try to boot remote host (behind Firewall). I have dhcp-relay configured. And finally, I see the DHCP request, but nothing else happens... except me crying ;'( "D DHCP request captured on undercloud vnet5 where dhcp is listening also on eth1, But I am not able to load a remote host. I had a thought, maybe DHCP is generally not working, but one node which is local, I am able to introspect and provide it. completely nothing in /var/log/containers/ironic-inspector/dnsmasq.log Any suggestions? My network, which I used and have configured on undercloud host is: 10.120.191.80/28 and IP for DHCP which is configured as dhcp relay is 94. output from tcpdump: 21:19:00.058565 40:a6:77:4b:07:cb > 52:54:00:20:c1:dc, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 58, id 60458, offset 0, flags [none], proto UDP (17), length 576) 10.41.94.241.67 > 10.120.191.94.67: [udp sum ok] BOOTP/DHCP, Request from 24:6e:96:14:a1:a4, length 548, hops 1, xid 0x9614a1a4, secs 12, Flags [Broadcast] (0x8000) Gateway-IP 10.41.94.241 Client-Ethernet-Address 24:6e:96:14:a1:a4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 36: Subnet-Mask, Time-Zone, Default-Gateway, Time-Server IEN-Name-Server, Domain-Name-Server, RL, Hostname BS, Domain-Name, SS, RP EP, RSZ, TTL, BR YD, YS, NTP, Vendor-Option Requested-IP, Lease-Time, Server-ID, RN RB, Vendor-Class, TFTP, BF Option 128, Option 129, Option 130, Option 131 Option 132, Option 133, Option 134, Option 135 MSZ Option 57, length 2: 1260 GUID Option 97, length 17: 0.68.69.76.76.57.0.16.56.128.80.200.192.79.56.68.50 ARCH Option 93, length 2: 0 NDI Option 94, length 3: 1.2.1 Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001" -- Ruslanas Gžibovskis +370 6030 7030

2 4

[kolla][ptg] virtual PTG
by Mark Goddard 16 Apr '20

16 Apr '20

Hi, For Victoria we will again be having a virtual PTG, however this time due to "you know what" we will be holding it at the same time as the other teams. The PTG will take place from 1st - 5th June, with various slots [1] available throughout the day from which we can select. Looking at previous events [2][3], we had two four hour slots. For Train this was 12:00 - 16:00 UTC, and for Ussuri 14:00 - 18:00 UTC. Note that Train was during daylight savings, Ussuri was not. We also held a mid-Train planning session for Kayobe [4], which took two hours. Based on the above, I suggest we go with the same as Ussuri: Monday 1st: 14:00 - 18:00 UTC (kolla) Tuesday 2nd: 14:00 - 18:00 UTC (kolla) Wednesday 3rd: 14:00 - 16:00 UTC (kayobe) This is just a proposal - if you would like to attend these sessions and the above time slots do not work for you, please get in touch. In particular, please speak up if these slots are significantly out of your working day - with sufficient interest we could split sessions across timezones. [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.openstack.org/p/kolla-ussuri-ptg [3] https://etherpad.openstack.org/p/kolla-train-ptg [4] https://etherpad.opendev.org/p/kayobe-train-planning Cheers, Mark

2 4

[tc] [ironic] Promoting ironic to a top-level opendev project?
by Dmitry Tantsur 16 Apr '20

16 Apr '20

Hi everyone! This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion. TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated. (And no, it’s not an April 1st joke) Background ========= Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it. And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team. Okay, so why? =========== The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it? Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here. Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above). What we will do ============ This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule. In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication). What we will NOT do ================ At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely. What do you think? =============== Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome. Cheers, Dmitry

24 93

OpenStack should be buildable with sphinx 2.4: FTBFS in many packages
by Thomas Goirand 16 Apr '20

16 Apr '20

Hi, Sphinx 2.4 has been uploaded to Experimental. I just received bug reports against the OpenStack packages because some of them cannot be built with Sphinx 2.4. Here's the list: - ironic - os-api-ref - aodh - cloudkitty - kombu - panko - ceilometerclient - ceilometermiddleware - doc8 - dracclient - glareclient - murano-pkg-check - os-xenapi - scciclient - sahara - sphinxcontrib-programoutput - tempest-horizon It'd be nice if those affected could be fixed for Ussuri. IMO, it's just the doc, so fixing it wouldn't hurt code quality. In other words: help would be more than welcome writing patch or reviewing them, and testing Sphinx 2.4 compatibility. Cheers, Thomas Goirand (zigo)

7 13

[neutron] port binding issues after upgrade attempt
by Jean-Philippe Méthot 15 Apr '20

15 Apr '20

Hi, We’ve been running a somewhat old version of openstack-queens for a while (I don’t know the exact release number, you will understand why shortly). Our setup has dedicated network nodes which we set up to use l3ha not too long ago. The package version was more recent on the second network node than on the first one because of that, however, high availability worked fine. We then tried to upgrade to rocky and since then, we get binding failed errors for pretty much all our ports whenever a router change network node. The only way we’ve found to fix this is to shutdown our neutron services and then reimport our pre-upgrade openstack database backup. This way, every port gets created properly, as it was at the time. Since then we have: -Moved everything back to queens. -Reinstalled our controller and network nodes from scratch (which is why I don’t know which queens version we were using before). However, this issue still happens as soon as the router change network node. Most ports get binding failed errors and restoring the database backup is the only way we managed to get out of this issue each time. We use neutron-openvswitch for networking and tunneling is done with GRE. Our OS is centos 7. Is it possible that code pertaining to HA may have changed in the later versions of queens and rocky which could explain that we’re running into a bug of some sort? Is there a way I could get neutron to tell me exactly why port binding is failing? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

1 0

[all][elections][tc] Technical Committee Election Results
by Kendall Nelson 15 Apr '20

15 Apr '20

Hello Everyone! Please join me in congratulating the 5 newly elected members of the Technical Committee (TC). Graham Hayes (mugsie) Kristi Nikolla (knikolla) Mohammed Naser (mnaser) Belmiro Moreira (belmoreira) Rico Lin (ricolin) Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_95cb11614fb23566 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round! -Kendall Nelson (diablo_rojo) & the Election Officials

9 8

[tripleo] undercloud installation failed at "waiting for container to start"
by Giuseppe Sannino 15 Apr '20

15 Apr '20

Hi all, need a (hopefully) small help from you. I'm trying to deploy Openstack on RHLE8 using TripleO. The "openstack undercloud install" fails at this stage: 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 5 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 623.63s 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 4 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 304.39s Images are fetched from the RedHat registry and pushed on the local registry: *>> containers-prepare-parameter.yaml* ContainerImageRegistryCredentials: registry.redhat.io: xxx:yyy ContainerImagePrepare: - push_destination: rhosp-under.ctlplane.localdomain:8787 *>> From "/var/log/tripleo-container-image-prepare.log"* I can see images are properly pushed into local registry: 2020-04-10 17:17:22,339 587093 INFO tripleo_common.image.image_uploader [ ] [registry.redhat.io/rhosp-rhel8/openstack-nova-compute-ironic:16.0-91] Completed upload for image 2020-04-10 17:17:22,341 586855 INFO tripleo_common.image.image_uploader [ ] result [] 2020-04-10 17:17:22,370 586855 INFO root [ ] ContainerClustercheckConfigImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 ContainerClustercheckImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 : : : ContainerZaqarImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 DockerInsecureRegistryAddress: - rhosp-under.ctlplane.localdomain:8787 >> From "install-undercloud.log" I can see a smooth procedure till it gets to the "TASK [Debug output for task: Start containers for step XX ]" phase. Specifically, at step 5 it ends unsuccesfully. *>> podman image list* Empty *>> podman ps* Empty >> openstack tripleo container image list [stack@rhosp-under ~]$ openstack tripleo container image list +--------------------------------------------------------------------------------------------------------+ | Image Name | +--------------------------------------------------------------------------------------------------------+ | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-heat-engine:16.0-91 | : : : | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-cron:16.0-96 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-keystone:16.0-93 | +--------------------------------------------------------------------------------------------------------+ Any suggestion would be more than welcome Many thanks in advance /Giuseppe

3 5

[neutron] Bug deputy report for week of April 6th
by Lajos Katona 15 Apr '20

15 Apr '20

Hi, I was Neutron bug deputy last week, please read a short summary of last week's reported Neutron bugs. What I would like to highlight: 1871032 <https://bugs.launchpad.net/neutron/+bug/1871032> and 1871239 <https://bugs.launchpad.net/neutron/+bug/1871239> are unassigned and 1871608 <https://bugs.launchpad.net/neutron/+bug/1871608> needs more investigation (at least from my side to what happens there). - Critical bugs - Rally job on stable branches is failing ( https://bugs.launchpad.net/neutron/+bug/1871596) In Progress - High priority bugs - Not Assigned: - OVN migration scripts doesn't work with SSL-only deployment ( https://bugs.launchpad.net/neutron/+bug/1871032) - ovn-octavia-provider is not using load balancing algorithm source-ip-port (https://bugs.launchpad.net/neutron/+bug/1871239) - In Progress - neutron.tests.functional.agent.ovn.metadata.test_metadata_agent.TestMetadataAgent.test_agent_registration_at_chassis_create_event fails randomly (https://bugs.launchpad.net/neutron/+bug/1871340) - OVN octavia provider driver should spawn long-living process in driver agent (https://bugs.launchpad.net/neutron/+bug/1871355) - fix Released - [VPNaaS]: DeprecationWarning: invalid escape sequence ( https://bugs.launchpad.net/neutron/+bug/1871621) - More investigation is necessary - OVN] Cannot create metadata port for segmented network ( https://bugs.launchpad.net/neutron/+bug/1871608) - Low priority bugs - [OVN] local conf devstack for a ovn-northd (DB only) node does not work (https://bugs.launchpad.net/neutron/+bug/1871730) - Whishlist - neutron ovn db clients need more logs if they fail to connect to db (https://bugs.launchpad.net/neutron/+bug/1871427) - Incomplete or solved in other projects - vm cannot be created after a large number of vms are removed from the same node (https://bugs.launchpad.net/neutron/+bug/1870723) - stable/stein tempest-full job fails with "tempest requires Python '>=3.6' but the running Python is 2.7.17" was solved in devstack ( https://bugs.launchpad.net/neutron/+bug/1871327) It was solved in devstack Best wishes Lajos (lajoskatona) ,-.,-. ( ( ( \ ) ) _..-.._ __)/ ,',' `. ," `. ,--. `. ," @ .' ` \ (Y ( ;''. `--.____, \ , ; ((_ ,----' ,---' _,'_,' (((_,- (((______,-' ------------------------------------------------ Thank you for visiting https://asciiart.website/ This ASCII pic can be found at https://asciiart.website/index.php?art=holiday/easter

2 4

[manila] Driver interface changes
by Carlos Silva 14 Apr '20

14 Apr '20

Greetings, zorillas! During the previous week we have merged a change in manila which improves the create share from snapshot functionality [1] to allow a multi-stage share creation. This means that a share creation request at the share manager can be acknowledged by the share driver to be pending; and the share manager will call a different driver interface to gather the status of this share, periodically until it is created. The primary benefit of this change is for drivers that cannot clone their snapshots instantaneously into new shares, and for drivers that would like to implement snapshot cloning across different storage pools or back ends. To make these changes, we needed to change the driver interface. All in-tree drivers were already modified and are up to date with the changes in the interface. The out-of-tree drivers will need to be updated as well according to the changes in the interface, then they will be able to work properly. [1] https://review.opendev.org/#/c/709697/ Regards, Carlos Eduardo da Silva.

1 0