November 2021 - openstack-discuss

[openstack-ansible] release job failure for ansible-collections-openstack
by Előd Illés 16 Nov '21

16 Nov '21

Hi Openstack-Ansible team! This mail is just to inform you that there was a release job failure [1] yesterday and the job could not be re-run as part of the job was finished successfully in the 1st run (so the 2nd attempt failed [2]). Could you please review if everything is OK with the release? Thanks, Előd (elodilles @ #openstack-release) [1] http://lists.openstack.org/pipermail/release-job-failures/2021-November/001… [2] http://lists.openstack.org/pipermail/release-job-failures/2021-November/001…

5 5

[neutron] CI meeting - agenda for 16.11.2021
by Slawek Kaplonski 16 Nov '21

16 Nov '21

Hi, Just quick reminder for those interested in the Neutron CI. Today at 1500 UTC we will have our weekly meeting. Agenda for the meeting is in the etherpad: [1]. This week's meeting will be also on the meetpad [2]. See You all there :) [1] https://etherpad.opendev.org/p/neutron-ci-meetings [2] https://meetpad.opendev.org/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

error "haproxy[]: proxy horizon has no server available!" when internal tls is activated
by alex souppart 16 Nov '21

16 Nov '21

Hello, I try to deploy an overcloud openstack in victoria version. My configuration to deploy is : openstack overcloud deploy --templates -r /home/stack/templates/roles_data.yaml \ -n /home/stack/network_data.yaml \ -e /home/stack/templates/scheduler_hints_env.yaml \ -e /home/stack/templates/network-isolation.yaml \ -e /home/stack/templates/os-net-config-mapping.yaml \ -e /home/stack/templates/node-info.yaml \ -e /home/stack/containers-prepare-parameter.yaml \ -e /home/stack/templates/host-map.yaml \ -e /home/stack/templates/ips-from-pool-all.yaml \ -e /home/stack/templates/network-environment.yaml \ -e /home/stack/templates/net-multiple-nics-vlans.yaml \ -e /home/stack/templates/ceph-ansible-external.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-internal-tls-certmonger.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-ip.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml \ -e /home/stack/templates/tls-parameters.yaml \ -e /home/stack/templates/inject-trust-anchor.yaml \ The generated configuration of horizon httpd contains SSLVerifyClient. But Haproxy fails to check server available, because haproxy does not send a client certificate when check attempt. the generated configuration of haproxy backend is : server host1 ip_host1:5000 ca-file /etc/ipa/ca.crt check fall 5 inter 2000 rise 2 ssl verify required verifyhost host1 server host2 ip_host2:5000 ca-file /etc/ipa/ca.crt check fall 5 inter 2000 rise 2 ssl verify required verifyhost host2 server host3 ip_host3:5000 ca-file /etc/ipa/ca.crt check fall 5 inter 2000 rise 2 ssl verify required verifyhost host3 if i try adding manualy "crt /etc/pki/tls/certs/haproxy/overcloud-haproxy-internal_api.pem" in server configuration in haproxy.conf, horizon/dashboard works via haproxy. But i'm not sure that's the right way. Did I forget an environment file in deploy configuration ? Thank you in advance for your assistance with this. Best regards Souppart Alexandre

1 0

[openstack-helm] No meeting tomorrow
by Gage Hugo 15 Nov '21

15 Nov '21

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

1 0

Adjutant needs contributors (and a PTL) to survive!
by Adrian Turjak 15 Nov '21

15 Nov '21

Hello fellow OpenStackers! I'm moving on to a different opportunity and my new role will not involve OpenStack, and there sadly isn't anyone at Catalystcloud who will be able to take over project responsibilities for Adjutant any time soon (not that I've been very onto it lately). As such Adjutant needs people to take over, and lead it going forward. I believe the codebase is in a reasonably good position for others to pick up, and I plan to go through and document a few more of my ideas for where it should go in storyboard so some of those plans exist somewhere should people want to pick up from where I left off before going fairly silent upstream. Plus if people want/need to they can reach out to me or add me to code review and chances are I'll comment/review because I do care about the project. Or I may contract some time to it. There are a few clouds running Adjutant, and people who have previously expressed interest in using it, so if you still are, the project isn't in a bad place at all. The code is stable, and the last few major refactors have cleaned up much of my biggest pain points with it. Best of luck! - adriant

5 6

[all][tc] Canceling Technical Committee 18th Nov weekly meeting
by Ghanshyam Mann 15 Nov '21

15 Nov '21

Hello Everyone, Due to OpenInfra Keynotes happening on 17-18 Nov, this week (18th Nov) TC meeting is cancelled. -gmann

1 0

[Openstack][cinder] scheduler filters
by Ignazio Cassano 15 Nov '21

15 Nov '21

Hello All, I read that capacity filters for cinder is the default, so, if I understood well, a volume is placed on the backend where more space is available. Since my two backends are on storage with same features, I wonder if I must specify a default storage backend in cinder.conf or not. Must I create a cinder volume without cinder type and scheduler evaluate where there is more space available? Thanks Ignazio

2 3

[Nova] - OS_TYPE - Setting after the fact.
by Steven Relf 15 Nov '21

15 Nov '21

Hello List, I have the following situation and would be thankful for any help or suggestions. We provide images to our customers, upon which we set the os_type metadata. We use this to help schedule instances to host aggregates, so we can control where certain OS's land. This works great for new instances, that are created from our images. We have the following problems though. 1. Instances created prior to the introduction of the os_type metadata existing on the image, this metadata is not flowed down, and as such these instances have NULL 2. Instances created from a snapshot do not seem to get the os_type flowed down 3. Instances imported using our migration tool do not end up with the os_type being set either. Currently the only way I can see to set os_type on an instance is to manually (yuk) update the database for each and every instance, which is missing it. Does anyone have any ideas how this can be updated without manually modifying the database. My second thought was to maybe make use of the instance metadata that you can set via the CLI or API, but then I run in to the issue that there is not a nova filter that is able to use instance metadata, and in my brief play with the code, it looks like (user) metadata is not passed in as part of the instance spec dict that is used to schedule instances. I was thinking of writing a custom filter, but I'm not sure how compliant it would be to have a function making a call to try and collect the instance metadata. In summary, I need to solve two things. 1. How do I set os_type on instances in a way that doesn't involve editing the database. 2. Or How can I use another piece of metadata that I can set via the api, which also is exposed to the filter scheduler. Rgds Steve. The future has already arrived. It's just not evenly distributed yet - William Gibson

2 3

[nova][placement] Spec review day on Nov 16th
by Sylvain Bauza 15 Nov '21

15 Nov '21

As agreed on our last Nova meeting [1], please sharpen your pen and prepare your specs ahead of time as we'll have a spec review day on Nov 16th Reminder: the idea of a spec review day is to ensure that contributors and reviewers are available on the same day for prioritizing Gerrit comments and IRC discussions about specs in order to facilitate and accelerate the reviewing of open specs. If you care about some fancy new feature, please make sure your spec is ready for review on time and you are somehow joinable so reviewers can ping you, or you are able to quickly reply on their comments and ideally propose a new revision if needed. Nova cores, I appreciate your dedication about specs on this particular day. -Sylvain [1] https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-02-16.00.log.h…

1 1

[all] Openstack CI Log Processing project
by Daniel Pawlik 15 Nov '21

15 Nov '21

Hello Everyone, By moving the Opendev Elasticsearch to Openstack Elasticsearch service (in the future), a new repository was created in the Openstack project: ci-log-processing. The new repository will be used to store configuration related to the Opensearch service and all tools required to process logs from Zuul CI system to Opensearch. By moving to the new Elasticsearch system, we would like to take this opportunity to use a new service to replace the legacy submit-logstash-jobs system [1][2]. I would like to ask for volunteers to review changes in the Openstack ci-log-processing repository? [3] Please reply to this ML or ping me on #openstack-infra IRC channel so that we can plan to expand the core member list of this repo. Dan [1] https://opendev.org/opendev/base-jobs/src/branch/master/roles/submit-logsta… [2] https://docs.opendev.org/opendev/system-config/latest/logstash.html [3] https://review.opendev.org/q/project:openstack%252Fci-log-processing+status…

4 3