January 2022 - openstack-discuss - lists.openstack.org

Logging (Monasca) not in Dashboard
by Karera Tony 08 Jan '22

08 Jan '22

Dear Team, I hope all is well. I have deployed Openstack with kolla-ansible and enabled Monasca among the projects. The deployment was successful but unfortunately I can't see Logging in the Dashn=board. Kindly advise If I could be missing something. Regards Tony Karera

1 0

[release] Release countdown for week R-11, Jan 10-14
by Előd Illés 07 Jan '22

07 Jan '22

Development Focus ----------------- We are now past the Yoga-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (February 17th, 2022). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (February 24th, 2022) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, February 24th, 2022. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (March 10th, 2022) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases beforeMarch 25th, 2022 (Final RC deadline) Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 17th, 2022(R-6 week) Client library freeze: February 24th, 2022(R-5 week) Yoga-3 milestone: February 24th, 2022(R-5 week) Yogafinalrelease: March 30th, 2022 Next PTG: April 4 - 8, 2022 (virtual) Előd Illés irc: elodilles

1 0

[TripleO] Overcloud deployment failing with Network Seggregation
by Anirudh Gupta 07 Jan '22

07 Jan '22

Hi Team, I am trying to deploy an Openstack Train using TripleO having 3 Controllers and 1 Compute. Without Network Isolation, I have deployed it successfully. Now, I am trying to segregate my network traffic using multiple-nics-vlan configuration generated via the below command /tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered -n /home/stack/network_data.yaml -r /home/stack/templates/roles_data.yaml The command used for deploying the overcloud is openstack overcloud deploy --templates \ *-n /home/stack/templates/network_data.yaml \* -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/node-info.yaml \ *...* *-e /home/stack/templates/environments/network-isolation.yaml \-e /home/stack/templates/environments/network-environment.yaml \* *...* It is failing just after the ovs bridge gets created and external nic vlan is attached to the bridge. [image: MicrosoftTeams-image (1).png] MAC Address of br-ex is same as the MAC of the interface specified in file network/config/multiple-nics-vlan/controller.yaml For testing, If I assign an IP address to that interface, it is reachable to GW. But, in case IP is assigned to VLAN 418 and it is added in the br-ex, Gateway remains unreachable. Please suggest

1 0

[neutron] Drivers meeting - Friday 7.1.2022 - cancelled
by Lajos Katona 06 Jan '22

06 Jan '22

Hi Neutron Drivers! Tomorrow we have not enough drivers to vote (see previous mail from mlavalle: [0]), so let's cancel tomorrow's meeting, and meet a week later: January 14th. [0]: http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026549.… See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

[all][Neutron][devstack] Deprecate lib/neutron
by Lajos Katona 06 Jan '22

06 Jan '22

Hi, In devstack we have two more or less overlapping lib for deploying Neutron: lib/neutron and lib/neutron-legacy. lib/neutron-legacy was recently "undeprecated" (see [0]), and Openstack CI mostly (fully?) uses it. To avoid double maintenance, and confusion in settings we would like to deprecate lib/neutron, for recent discussions see [1] and [2]. The plan is to keep lib/neutron for 2 cycles (that will be AA or the release after Z) and delete lib/neutron then, and rename lib/neutron-legacy to lib/neutron. As You can see from the discussions below there are questions like how to name the processes, log-files etc..., as lib/neutron-legacy uses q-* and lib/neutron uses neutron-* names. The best would be to keep both in the long term (we love q-* as historical tradition, but neutron-* looks like so fresh and modern;)) If you have any thoughts suggestions or questions please answer to this mail or comment on the deprecation patch: [3] [0]: https://review.opendev.org/c/openstack/devstack/+/704829 [1]: https://meetings.opendev.org/meetings/networking/2022/networking.2022-01-04… [2]: https://meetings.opendev.org/irclogs/%23openstack-qa/%23openstack-qa.2022-0… [3]: https://review.opendev.org/c/openstack/devstack/+/823653

1 0

[neutron] Dadfailed of ipv6 metadata IP in qdhcp namespace and disappearing dhcp namespaces
by Kamil Madáč 06 Jan '22

06 Jan '22

Hello, In our small cloud environment, we started to see weird behavior during last 2 months. Dhcp namespaces started to disappear randomly, which caused that VMs losed connectivity once dhcp lease expired. After the investigation I found out following issue/bug: 1. ipv6 metadata address of tap interface in some qdhcp-xxxx namespaces are stucked in "dadfailed tentative" state (i do not know why yet) 2. 3. root@cloud01:~# ip netns exec qdhcp-3094b264-829b-4381-9ca2-59b3a3fc1ea1 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2585: tap1797d9b1-e1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:77:64:0d brd ff:ff:ff:ff:ff:ff inet 169.254.169.254/32 brd 169.254.169.254 scope global tap1797d9b1-e1 valid_lft forever preferred_lft forever inet 192.168.0.2/24 brd 192.168.0.255 scope global tap1797d9b1-e1 valid_lft forever preferred_lft forever inet6 fe80::a9fe:a9fe/64 scope link dadfailed tentative valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe77:640d/64 scope link valid_lft forever preferred_lft forever 4. 5. This blocked dhcp agent to finish sync_state function, and NetworkCache was not updated with subnets of such neutron network 6. During creation of VM assigned to such network, agent does not detect any subnets (see point 2), so he thinks (reload_allocations()) there is no dhcp needed and deletes qdhcp-xxxx namespace, so no DHCP and no Metadata are working on such network since that moment, and after 24h we see connectivity issues. 7. Restart of DHCP agent recreates missing qdhcp-xxxx namespaces, but NetworkCache in dhcp agent is again empty, so creation of VM deletes the qdhcp-xxxx namespace again 🙁 Workaround is to remove dhcp agent from that network and add it again. Interestingly, sometimes I need to do it multiple times, because in few cases tap interface in new qdhcp finishes again in dadfailed tentative state. After year in production we have 20 networks out of 60 in such state. We are using kolla-ansible deployment on Ubuntu 20.04, kernel 5.4.0-65-generic. Openstack version Victoria and neutron is in version 17.2.2.dev70. Is that bug in neutron, or is it misconfiguration of OS on our side? I'm locally testing patch which disables ipv6 dad in qdhcp-xxxx namespace (net.ipv6.conf.default.accept_dad = 1), but I'm not sure it is good solution when it comes to other neutron features? Kamil Madáč Slovensko IT a.s.

3 3

[horizon] Bump XStatic-Angular-FileUpload to 12.2.13
by Thomas Goirand 06 Jan '22

06 Jan '22

Hi, After someone unrelated to OpenStack maintenance uploaded libjs-angular-file-upload 12.2.13, I tested it, and it didn't break Horizon (at least, when I manually uploaded a file, it worked...). So IMO, it would be fine to just bump to that version. Cheers, Thomas Goirand (zigo)

1 0

[keystone][requirements] keystone holding back pysaml2-7.1.x update
by Matthew Thode 06 Jan '22

06 Jan '22

Hi again, pysaml2===7.1.0 has been breaking updates for a while now. https://review.opendev.org/818612 -- Matthew Thode

1 0

[horizon][requirements] falling behind on requirements updates
by Matthew Thode 06 Jan '22

06 Jan '22

Hi, The following requirements updates have been stalled. XStatic-Angular===1.8.2.1 Has been held back for at least 7 months, but I think closer to a year now. Some review history is here: https://review.opendev.org/794258 django-compressor===2.4.1 rcssmin===1.1.0 rjsmin===1.1.0 These come as a group and have been holding things back for about a month. I'm not sure what's holding things back here on the horizon side. Review bundled with XStatic-Angular here: https://review.opendev.org/823449 -- Matthew Thode

1 0

[all][tc] Technical Committee next weekly meeting on Jan 6th at 1500 UTC
by Ghanshyam Mann 06 Jan '22

06 Jan '22

Hello Everyone, Technical Committee's next weekly meeting is scheduled for Jan 6th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Jan 5th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1