April 2023 - openstack-discuss - lists.openstack.org

Cinder Bug Report 2023-04-26
by Sofia Enriquez 26 Apr '23

26 Apr '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> *High* - Users with a Reader role can create/delete/update a snapshot <https://bugs.launchpad.net/cinder/+bug/2017108>. - *Status:* Unassigned. These issues were found while adding snapshot tests for srbac <https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/872986> . *Incomplete* - wrong hostname passed to os_brick <https://bugs.launchpad.net/cinder/+bug/2017575> - *Status:* Waiting on reports updates. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[Image Encryption] No meeting on May 1st
by Josephine Seifert 26 Apr '23

26 Apr '23

Hi, due to a national holiday there will be no meeting on May the 1st. regards, Jospehine (Luzi)

1 0

[nova][ci] Hold your rechecks
by Sylvain Bauza 25 Apr '23

25 Apr '23

Due to tooz changing their python support to no longer support py3.8 by the 4.0 version, the Nova functional jobs are now blocked until we either block tooz>=4 in upper-constraints or we completely remove py3.8 support for the CI jobs we run. A proposal already exists : https://review.opendev.org/c/openstack/nova/+/881339 Anyway, hold your rechecks. -Sylvain

1 2

[publiccloud-sig] Bi-weekly meeting reminder
by Tobias Rydberg 25 Apr '23

25 Apr '23

Hi everyone, Tomorrow it's time again for our bi-weekly meeting, 0800 UTC in #openstack-operators. Etherpad can be found here [0]. Hope to chat with you tomorrow! [0] https://etherpad.opendev.org/p/publiccloud-sig-meeting BR, Tobias Rydberg -- *Tobias Rydberg* Solution Architect Email: tobias.rydberg(a)cleura.com cleura.com <https://cleura.com/> – The European cloud! Read our press release – City Network becomes Cleura <https://cleura.com/press-releases/city-network-becomes-cleura/>

1 0

[neutron] Deprecated support for Windows OS
by Rodolfo Alonso Hernandez 25 Apr '23

25 Apr '23

Hello Neutrinos: During this release, Neutron is dropping the support for Windows OS [1] and will be removed in 2024.2. This decision [2] was taken after the announcement of the current Winstacker mantainers to step down from this project. Regards. [1]https://review.opendev.org/c/openstack/neutron/+/880980 [2] https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-18… [3] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03104…

1 0

[neutron] Broken CI "neutron-tempest-plugin-*" jobs
by Rodolfo Alonso Hernandez 25 Apr '23

25 Apr '23

Hello all: Please hold your rechecks for the "neutron-tempest-plugin-*" jobs. We need to bump the python version from 3.8 to 3.9. However, due to an issue in Ubuntu Jammy [1], we are still working with Ubuntu Focal nodes. The problem in Focal is that uWSGI provided in this version doesn't support python3.9. We are pushing new patches for Nova and neutron-tempest-plugin to test possible solutions. If we can't solve this issue, we'll skip these jobs temporarily. I'll send an update as soon as possible. Regards. [1]https://bugs.launchpad.net/neutron/+bug/1999249 [2]https://review.opendev.org/c/openstack/nova/+/868419 [3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879036

2 3

[tc] Next Technical Committee weekly meeting to be held on April 25, 2023
by Nikolla, Kristi 24 Apr '23

24 Apr '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday (April 25) at 1800 UTC on #openstack-tc on OFTC IRC Items can be proposed by editing the wiki page at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Unless there are last minute additions (for which I will send a follow-up email) the agenda will be: * Roll call * Follow up on past action items * Gate health check * 2023.2 cycle Leaderless projects ** https://etherpad.opendev.org/p/2023.2-leaderless * Broken docs due to inconsistent release naming * Following new release naming convention by packagers (UCA/RDO) * Schedule of removing support for Python versions by libraries - how it should align with coordinated releases (tooz case) * Recurring tasks check ** Bare 'recheck' state *** https://etherpad.opendev.org/p/recheck-weekly-summary * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open Thank you, Kristi Nikolla

1 0

Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down
by Matt Crees 24 Apr '23

24 Apr '23

Hi all, It seems worth noting here that there is a fix ongoing in oslo.messaging which will resolve the issues with HA failing when one node is down. See here: https://review.opendev.org/c/openstack/oslo.messaging/+/866617 In the meantime, we have also found that setting kombu_reconnect_delay = 0.5 does resolve this issue. As for why om_enable_rabbitmq_high_availability is currently defaulting to false, as Michal said enabling it in stable releases will impact users. This is because it enables durable queues, and the migration from transient to durable queues is not a seamless procedure. It requires that the state of RabbitMQ is reset and that the OpenStack services which use RabbitMQ are restarted to recreate the queues. I think that there is some merit in changing this default value. But if we did this, we should either add additional support to automate the migration from transient to durable queues, or at the very least provide some decent docs on the manual procedure. However, as classic queue mirroring is deprecated in RabbitMQ (to be removed in RabbitMQ 4.0) we should maybe consider switching to quorum queues soon. Then it may be beneficial to leave the classic queue mirroring + durable queues setup as False by default. This is because the migration between queue types (durable or quorum) can take several hours on larger deployments. So it might be worth making sure the default values only require one migration to quorum queues in the future, rather than two (durable queues now and then quorum queues in the future). We will need to make this switch eventually, but right now RabbitMQ 4.0 does not even have a set release date, so it's not the most urgent change. Cheers, Matt >Hi Michal, > >Feel free to propose change of default in master branch, but I don?t think we can change the default in stable branches without impacting users. > >Best regards, >Michal > >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet(a)ultimum.io> wrote: >> >> Hi, >> >> Btw, why we have such option set to false ? >> Michal Arbet >> Openstack Engineer >> >> Ultimum Technologies a.s. >> Na Po???? 1047/26, 11000 Praha 1 >> Czech Republic >> >> +420 604 228 897 <> >> michal.arbet(a)ultimum.io <mailto:michal.arbet@ultimum.io> >> https://ultimum.io <https://ultimum.io/> >> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline> >> >> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka(a)gmail.com <mailto:mnasiadka@gmail.com>> napsal: >>> Hello, >>> >>> RabbitMQ HA has been backported into stable releases, and it?s documented here: >>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabb… >>> >>> Best regards, >>> Michal >>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com <mailto:nguyenhuukhoinw@gmail.com>> napisa?(a): >>>> Yes. >>>> But cluster cannot work properly without it. :( >>>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb(a)thehutgroup.com <mailto:Danny.Webb@thehutgroup.com>> wrote: >>>>> This commit explains why they largely removed HA queue durability: >>>>> >>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90… >>>>> From: Satish Patel <satish.txt(a)gmail.com <mailto:satish.txt@gmail.com>> >>>>> Sent: 09 April 2023 04:16 >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com <mailto:nguyenhuukhoinw@gmail.com>> >>>>> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org <mailto:openstack-discuss@lists.openstack.org>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down >>>>> >>>>> >>>>> CAUTION: This email originates from outside THG >>>>> >>>>> Are you proposing a solution or just raising an issue? >>>>> >>>>> I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem. >>>>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com <mailto:nguyenhuukhoinw@gmail.com>> wrote: >>>>> Hello everyone. >>>>> >>>>> I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible >>>>> >>>>> Scenario: 1 of 3 controller is down >>>>> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow >>>>> >>>>> fix by: >>>>> >>>>> nano: >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2 >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2 >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2 >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2 >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2 >>>>> >>>>> or which service need caches >>>>> >>>>> add as below >>>>> >>>>> [cache] >>>>> backend = oslo_cache.memcache_pool >>>>> enabled = True >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }} >>>>> memcache_dead_retry = 0.25 >>>>> memcache_socket_timeout = 900 >>>>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487 >>>>> >>>>> but it is not the end >>>>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this step) >>>>> >>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2 >>>>> >>>>> "policies":[ >>>>> {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %}, >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0} >>>>> {% endif %} >>>>> ] >>>>> >>>>> nano /etc/kollla/global.conf >>>>> >>>>> [oslo_messaging_rabbit] >>>>> kombu_reconnect_delay=0.5 >>>>> >>>>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149 >>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html >>>>> >>>>> I used Xena 13.4 and Yoga 14.8.1. >>>>> >>>>> Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack >>>>> >>>>> >>>>> Nguyen Huu Khoi >>> -- >>> Micha? Nasiadka >>> mnasiadka(a)gmail.com <mailto:mnasiadka@gmail.com>

6 18

Query about RBAC for subnets
by Aditya Sathish 24 Apr '23

24 Apr '23

Hello, We currently have an external network that is being interfaced from the physical interface of the compute server to an L3 switch with different subnets to different services. These services (and, by extension, the subnets) must be accessed and controlled by the operator to allow a project only a subset of these services. RBAC can only set rules for the network as a whole. Can this network be made external but only share a few subnets with each project? If not the RBAC way, is there another alternative to achieve the same? Regards, Aditya

2 1

[openstack-helm] Manila chart merged
by Vladimir Kozhukalov 24 Apr '23

24 Apr '23

Hi, everyone I would like to announce that last week we eventually merged the PR that adds the Manila chart. Thanks everyone for their contribution. -- Best regards, Kozhukalov Vladimir

1 0