March 2021 - openstack-discuss - lists.openstack.org

[charms] Charms libraries freeze on Friday
by Alex Kavanagh 30 Mar '21

30 Mar '21

Hi All Just a reminder that this week is the last opportunity to get features into the libraries for the release. The libraries affected by this freeze are: - charm-helpers - charms.openstack - charms.ceph - zaza - zaza-openstack-tests We will be taking a stable cut (stable/21.04) of these libraries on Friday and doing a batch review of the charms to point to these cuts during the testing period with a final charm-helpers sync at this point. The reactive charms will have a build.lock file introduced to lock their versions of the layers, interfaces and python modules (the above libraries will be tracked by stable branch). Only bug fixes and features-by-exception will be accepted into the stable cuts of these libraries after that point. For the avoidance of doubt, we will be testing and releasing against the current latest stable of: - juju 2.8.10 - python-libjuju 2.8.6 - charm-tools 2.8.3 Many thanks Alex. -- Alex Kavanagh - Software Engineer OpenStack Engineering - Data Centre Development - Canonical Ltd

1 0

[ops][victoria] Windows Server 2012 R2 - Can't install - unbootable
by DHilsbos＠performair.com 30 Mar '21

30 Mar '21

All; We have a recently built Victoria cluster with storage provided by a Ceph Nautilus cluster. I'm working through the following tutorial: https://medium.com/@yooniks9/openstack-install-windows-server-2016-2019-wit… When I get to step 4 under "Windows Server Installation," it says "Windows can't be installed on this drive." Details are: " Windows cannot be installed to this disk. This computer's hardware may not support booting to this disk. Ensure the disk's controller is enabled in the computer's BIOS menu. Any recommendations on what I'm missing here would be appreciated. Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

3 2

[cinder] this week's meeting in video+IRC
by Brian Rosmaita 30 Mar '21

30 Mar '21

Quick reminder that this week's Cinder team meeting on Wednesday 31 March, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. Here's a quick reminder of the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. connection info: https://bluejeans.com/3228528973 cheers, brian

1 0

[neutron][db] Train: neutron-db-manage can't locate revision
by Eugen Block 30 Mar '21

30 Mar '21

Hi *, I have a new issue with our Train cloud (upgraded through the years). Currently I'm preparing the next upgrade step to Ussuri and stumbled upon this neutron db issue: ---snip--- controller01:~ # neutron-db-manage current Running current for neutron ... INFO [alembic.runtime.migration] Context impl MySQLImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. ERROR [alembic.util.messaging] Can't locate revision identified by 'e4e236b0e1ff' FAILED: Can't locate revision identified by 'e4e236b0e1ff' controller01:~ # neutron-db-manage revision --contract Running revision for neutron ... Generating /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/contract/b5344a66e818_.py ... done OK controller01:~ # neutron-db-manage revision --expand Running revision for neutron ... Generating /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py ... done OK controller01:~ # neutron-db-manage heads Running heads for neutron ... 6c9eb0469914 (expand) (head) c43a0ddb6a03 (contract) (head) OK ---snip--- I've been searching how that revision got into the database but I can't find any hint where that e4e236b0e1ff belongs to. To test the upgrade process I have a VM that was initially setup with Ocata, I'm able to investigate a snapshot from before the Pike upgrade, and I can't find a clue either, except for the neutron database. Although our current setup works just fine I'm not sure if this will be a show stopper for the Ussuri upgrade, although it wasn't for the previous upgrades. Anyway, how would I resolve this? I see these versions in the neutron.alembic_version table: +--------------+ | version_num | +--------------+ | 5c85685d616d | | e4e236b0e1ff | +--------------+ And 5c85685d616d seems to be a valid version from Newton, it seems. Could anyone provide some guidance on how to fix this before the next uprade? If possible I would like to avoid making manual changes in the database myself. Thanks and best regards, Eugen

2 3

[octavia] Xena PTG planning
by Gregory Thiemonge 30 Mar '21

30 Mar '21

Hi Octavia community! We have booked 2 sessions for Octavia during the Xena PTG: Tuesday April 20 - 13:00 - 17:00 UTC Wednesday April 21 - 13:00 - 17:00 UTC There's an etherpad for the PTG planning, please add your topics to the list: https://etherpad.opendev.org/p/xena-ptg-octavia Thanks, Greg

1 0

[tc][release] Networking-midonet current status and Wallaby release
by Slawek Kaplonski 30 Mar '21

30 Mar '21

Hi, We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there). In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running? [1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797 -- Slawek Kaplonski Principal Software Engineer Red Hat

6 19

Use of BladeCenter as a compute node(s)
by open infra 29 Mar '21

29 Mar '21

Hi, Done anyone deployed OpenStack compute nodes on BladeCenter? Do we need to attach each blade as a compute node? If we do so, aren't we restrict the maximum capacity of the VM to capacity of each blade? Regards, Danishka

1 0

[designate][ptg] Designate will have a PTG time for Xena
by Michael Johnson 29 Mar '21

29 Mar '21

Hi Designate community! I have reserved a timeslot to discuss Designate at the PTG. As discussed in the IRC channel, we will meet during the same time slot as we did for the last PTG. April 22th, 13:00-15:00 UTC I have created an etherpad to start collecting topics: https://etherpad.opendev.org/p/xena-ptg-designate I hope to see you there, Michael

1 0

[openstack-helm] Meeting cancelled March 31st
by Gage Hugo 29 Mar '21

29 Mar '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, March 31st, the meeting is cancelled. Our next IRC meeting will be April 6th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

[puppet] Artificially inflated dependencies in metadata.json of all modules
by Thomas Goirand 29 Mar '21

29 Mar '21

Hi, Each time there's a new release, all of the modules are getting a new set of lower bounds for: - openstack/keystone - openstack/openstacklib - openstack/oslo I just did a quick check and this really doesn't make sense. For example, for going from 18.2.0 to 18.3.0, there's no breakage of the API that would require a bump of version in all modules. So, could we please stop this non-sense and restore some kind of sanity in our dependency management ? FYI, I'm expressing these in the packaged version of the puppet modules, and it increase complexity for no reasons. A lower bound of a dependency should be increased *only* when really mandatory (ie: a backward compatibility breakage, a change in the API, etc.). Your thoughts? Cheers, Thomas Goirand (zigo)

3 6