May 2022 - openstack-discuss - lists.openstack.org

[ironic] [requirements] broken libvirt-python on yoga on stream 9
by Dmitry Tantsur 19 May '22

19 May '22

Hi all, It is happening again, the Bifrost CI is broken because libvirt-python cannot be built from source, this time on Stream 9. Missing type converters: int *:1 ERROR: failed virDomainQemuMonitorCommandWithFiles I created a gist with a reproducer: https://gist.github.com/dtantsur/835303c6a68ed77157016f5955183115. I cannot count how many times we had to deal with similar errors. I assume, libvirt-python has to be newer than the installed Python (8.2.0 in CS9, 8.0.0 in constraints). Should we stop constraining libvirt-python? Any other ideas? Dmitry -- Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 14, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

5 7

[TripleO] Gate blocker on Master - standalone-on-multinode-ipa failing
by Sandeep Yadav 19 May '22

19 May '22

Hello All, We have a check/gate blocker on Master branch - standalone-on-multinode-ipa[0] job is failing with bug[1]. Please hold rechecks on master till [1] resolves. [0] https://zuul.openstack.org/builds?job_name=tripleo-ci-centos-9-standalone-o… [1] https://bugs.launchpad.net/bugs/1973863 Thank you Sandeep(on behalf of tripleo-ci)

1 1

[keystone][nova][placement] audit logs
by Sharath Ck 19 May '22

19 May '22

Hi, Placement does not have an api-paste.ini configuration file. Also Placement does not have a placeholder to mention or add middleware. Hence keystone audit middleware is not supported in Placement ? Need to collect the audit events from Nova itself. Can anyone please confirm this. Regards, Sharath

2 2

[magnum] [xena] [IPv6]
by Namrata Sitlani 19 May '22

19 May '22

Hello All, We run release Xena, and we have deployed Kubernetes version 1.21.10 on Magnum with Fedora CoreOS version 34 and we are trying to have IPv6 support for that Kubernetes cluster, as Kubernetes 1.21 and later versions have dual-stack(IPv4/IPv6) support enabled by default. To achieve the same, we used a network with both IPv4 and IPv6 subnets and we got a successful creation of the cluster. The compute instances of the cluster get both IPv4 and IPv6 addresses, but the master and minion nodes get IPv4 as external IP, and also the container does not get an IPv6 address. Can someone please help us with the information, what changes are required to be made at the magnum client-side to have an IPv6 supported Kubernetes Cluster? Thanks, Namrata

1 0

[all][tc] Technical Committee next weekly meeting on May 19, 2022 at 1500 UTC
by Ghanshyam Mann 19 May '22

19 May '22

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

1 1

[infra][stable] reopened old, EOL'd branches
by Előd Illés 18 May '22

18 May '22

Hi Infra team, I need some help / advice from you. Some time ago I realized that there are multiple open stable/newton (and some older) branches as well for some projects. I see there multiple kind of open EOL'd branches: 1. where there were no *-eol tag at all and thus branch is still open 2. where there exist *-eol tag, but the branch was not deleted 3. where there exist *-eol tag, the branch was probably deleted but then reopened and some generated patch created a new branch from the same branching point where the original stable/* branch was branched from. (some example generated patches: * OpenDev Migration Patch * Replace openstack.org git:// URLs with https:// see specific example [1]) To clean up this I think we need some decision and manual tagging and branch deletion, because our tooling (openstack/releases) does not allow to tag on a branch that has an EOL state. For this I would - push release patches where that is missing from openstack/release (this will not do the work, as mentioned above, but needs some manual tagging / branch deletion afterwards) - this is only to have a better view of the tags and branches from openstack/releases repository - tag branches with *-eol where that is missing - delete branches that have already *-eol tag, even if that means we lose some patches (like the above mentioned generated patches) Is this acceptable? What do you think? (Or should the two latter be done by Infra team via a list that I could collect?) [1] https://paste.opendev.org/show/bCnJaKgdTrlZwDzcP3VM/ Thanks in advance, Előd (irc: elodilles)

2 2

Can external API endpoints be registered in Openstack Keystone service catalogue/registry?
by Milan Paul 18 May '22

18 May '22

Hi All, We are developing few wrapper APIs (in SpringBoot and Python) on top of Openstack components like Nova, Neutron and glance. As Keystone works as a service registry for internal Openstack APIs, is it possible to register our custom wrapper APIs in keystone registry? Basically, we want to use keystone as an API registry without having another API gateway. Any help would be highly appreciated. Regards.

2 1

octavia_rsyslog service fails/keeps restarting | Openstack Wallaby | Tripleo
by Swogat Pradhan 18 May '22

18 May '22

Hi, I am currently trying to deploy octavia in openstack wallaby, but the octavia_rsyslog service is malfunctioning it seems. And I am checking the logs but am not sure how to fix the issue. Attached log for reference. With regards, Swogat Pradhan

3 2

[ Triple0 - NETWORKS ] Openstack Network getting created from wrong network segment range
by Lokendra Rathour 18 May '22

18 May '22

Hi Team, We have deployed tripl0 Train using two tenant networks by configuring the parameters for additional networks. environments.yaml: *NeutronBridgeMappings: datacentre:br-tenant,datacentre2:br-extratenant* in environments/network-environment.yaml * NeutronNetworkVLANRanges: 'datacentre:1:500,datacentre2:501:1000'* and have also isolated and separated the physical nic configuration for ovs in network/config/bond-with-vlans/compute.yaml with this setting, overcloud is deployed and the network is getting created, Checking further, in Controller configs(/etc/neutron/plugins/ml2/) we see the changes as below, which looks fine: *[ml2_type_vlan]* *network_vlan_ranges=datacentre:1:500,datacentre2:501:1000* *but it is also allowing* the network to be created from the wrong network segment range. For example, while creating a network: - openstack network create --share --provider-network-type vlan --provider-physical-network datacentre2 --provider-segment 420 datacenter_2_420 -provider-physical-network- *"datacentre2"* is having VLAN range from 501-1000 and if I am passing the provider segment as 420(which is out of range) then *also a network is getting created.* This does not look fine. please help share any inputs on the same. -- ~ Lokendra skype: lokendrarathour

2 1

[horizon] Cancelling Today's Weekly meeting
by vishal manchanda 18 May '22

18 May '22

Hello team, Since there is no topic added for discussion in the agenda etherpad[1] for today's meeting. So let's cancel it. If anyone like to discuss anything, ping me on IRC channel(#openstack-horizon). See you next week! Thanks & regards, Vishal Manchanda(irc:vishalmanchanda) [1] https://etherpad.opendev.org/p/horizon-release-priorities#L38

1 0