April 2022 - openstack-discuss - lists.openstack.org

[neutron][ovn] Need VM accessible on Internet, and able to access DC resources
by Chris DiLorenzo 13 Apr '22

13 Apr '22

To Internet To Data Center Resources (10.x) - -/ - -/ / -/ / -/ / -/ -/ -/ / -/ / Public Provider Network / Private Provider Network / +------------------------+ +-------------------------+ | | | | | | | | | Router #1 |--------------| Router #2 | | SNAT Enabled | .2| SNAT Enabled | | | | | | | | | +------------------------+ +-------------------------+ | 192.168.1.1 | | | | | | | | | 192.168.1.10 (FIP: Public IP) +---------|-------------+ | | | | | | | VM | | | | | +-----------------------+ I am running Openstack Xena with OVN and distributed FIP enabled. We are trying to come up with a way to make a VM accessible from the Internet and still have it able to access internal Data Center services. Our thought is to setup a router between the tenant network and an internet accessible provider network. We'll assign a FIP to the VM. Then, we create an additional router that connects to the same tenant network but routes to a provider network that has access to everything inside the DC. We would then add a static route on Router #1 like 10.0.0.0/8 nexthop 192.168.1.2. I've tried setting this up in our lab, but it's not working. I can't ping to anything inside the DC. Should this work? Any best practice here we should look at? Thanks Chris

1 0

[cinder] Bug deputy report for week of 04-13-2022
by Sofia Enriquez 13 Apr '22

13 Apr '22

This is a bug report from 03-30-2022 to 04-13-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/os-brick/+bug/1967790 " Encryptor connect_volume not changing the symlink." Fix proposed to marter. Medium - https://bugs.launchpad.net/cinder/+bug/1968746 "cinder-manage db sync fails due to row size too large." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1968645 "Concurrent migration of vms with the same multiattach volume fails." Unassigned. Low - https://bugs.launchpad.net/cinder/+bug/1968170 "reimage_volume failure message action does not exist." Unassigned. 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

Error while creating attached to an external interface
by A Monster 13 Apr '22

13 Apr '22

I'm trying to launch an instance attached to an external network, but I get an all host exhausted error message, and the neutron log file show the following error : *ERROR neutron.plugins.ml2.managers [req-6979d5fd-8e6a-4802-a758-e4882b7ac5b6 397fa0267ae340e1b24a3a96ae302f32 05b9f31fca434f7a96b63a1d17e8b14c - default default] Failed to bind port d57ac8f5-7904-495f-a4b9-9b23df681634 on host compute1.localdomain for vnic_type normal using segments [{'id': '475c70c2-6a35-4721-a726-cbf8c0b7e778', 'network_type': 'flat', 'physical_network': 'physnet2', 'segmentation_id': None, 'network_id': 'a1c2cc8f-6a04-48ce-9d87-a351da1d3f3e'}]* But when I try to launch an instance using another external network, it works just fine.

1 0

[neutron] Zed PTG Summary
by Lajos Katona 13 Apr '22

13 Apr '22

Hi, I will try to summarize the Neutron PTG sessions during the last week. The etherpad which we used: https://etherpad.opendev.org/p/neutron-zed-ptg # Day 1 (Monday April 4.) ## Yoga retrospective (I just list here the topics, not every discussion under them): * Good things ** New active people around the team ** Revived project: neutron-fwaas ** video CI meetings every second week are very good IMO ** OVN backend is getting more and more attention and there are less gaps between OVN and OVS backends * Bad / Not so good: ** less and less active people ** to much depends on Red Hat - ~66% of reviews, ~62% of commits (in Neutron official projects) ** lack of maintainers for some stadium projects (neutron-vpnaas) and some backends/drivers (linuxbridge) * As action we previously decided to have a forum session during the Berlin Summit to discuss the lack of activity/maintainers for some backends and stadium projects hopefully with some operators also. ## Short update on bgp related blueprints https://etherpad.opendev.org/p/neutron-zed-ptg#L111 The development of these blueprints are stopped, we will revert the already merged code. # Day 2 (Tuesday April 5.) ## Have nova / os-vif delete the trunk bridges to avoid race conditions The creation of trunk bridges now done by os-vif, and the deletion is done by Neutron, to avoid the race condition we agreed to have both operations done by os-vif. ## skip-level upgrade (tick-tick) We discussed together how this affects Neutron, what is working currently and what is in front of us. We have periodic jobs for ovs and ovn backend. Actions: * Make ovn grenade upgrade jobs green ## When we say something is not supported? * Recently from the Neutron stadium neutron-vpnaas project was that lost all maintainers. Neutron core team keeps an eye on the gate of networking projects, and keep them green, but if there is nobody with specific knowledge for the given area we can't solve the bugs. * We have similar problems with "in-tree" drivers also, a good example is the linuxbridge driver. Agreement was to keep the current approach for stadium project, so send out mail to openstack-discuss, asking for help, and if nobody appears, make the project retired and delete the code but keep git history for it. For in-tree code (drivers, extensions....): * We keep existing jobs for linuxbridge driver for example, but when the tests start to fail we skip them and finally we stop the job also. To make it clear for operators we add warning logs highlighting that the given feature/driver is experimental, and introduce cfg option to enable such features explicitly. We plan to discuss these questions during the Berlin Summit with operators. ## Prefix delegation for Openstack Neutron aka: dibbler tool for dhcpv6 is concluded The original bug: https://bugs.launchpad.net/neutron/+bug/1916428 * The tool behind PD, Dibbler is no more maintained and the suggested tool ISC Kea has no DHCP client actually. * this feature is not tested in upstream CI Due to these we decided to mark prefix delegation as experimental feature. # Day 3 (Wednesday April 6.) ## neutron-dynamic-routing + OVN Redhat works on a BGP solution for OVN, that is ovn-bgp-agent, and currently it doesn't need the existing API in neutron-dynamic-routing. The current approach to make neutron-dynamic-routing work with OVN will be checked. ## Option for OVN to disable DHCP/DNS and use dhcp-agent instead Technically it is possible, a new RFE will be proposed and the drivers team will discuss the usecase behind it. ## CI status / zuul job config errors In the list of zuul cfg errors ( https://zuul.opendev.org/t/openstack/config-errors ) old Neutron stadium branches are listed. * Decision was to EOL these old branches where fixing is not possible. Another topic was from Slawek if we want to have neutron-tempest-plugin-api-ovs job, and the agreement was to merge OVS scenario and API jobs. ## inconsistencies in OVS firewall on an agent restart We will go for a cfg option to select between OVS flow installation in batches and per port, and operators can select which is best for their environment. ## Pain Points TC started a discussion to cover the collected operator pain points, last week we checked again the list for Neutron ( https://etherpad.opendev.org/p/pain-point-elimination#L268) * neutron (via python calls) and OVN (via C calls) can have different ideas about what the hostname is, particulary if a deployer (rightly or wrongly) sets their hostname to be an FQDN ** it was fixed: https://review.opendev.org/q/Iea2533f4c52935b4ecda9ec22fb619c131febfa1 * Useful error msg when network deletion fails due to existing resources on it ** done: https://review.opendev.org/c/openstack/neutron/+/821935 * Open vSwitch Agent excess logging at INFO level ** we check if we can change some to debug, Slawek create a DNM job with only info logs to discuss during one of the coming meetings. * OVN: Spoofing of DNS reponses seems very wrong behavior ** We agreed that for this we need an RFE (see above for disabling OVN DNS/DHCP) ## Edge topics Together with the Designate team we agreed that this is more a documentation problem based on our current understanding. Based on Redhat downstream bugs for edge deployments we try to cover these in this cycle. # Day 4 (Thursday April 7.) We have no sassions. # Day 5 (Friday April 8.) ## Nova - Neutron xproject ### How to require ml2 plugins to implement multiple port bindings The problem is that there are old drivers (hyperv perhaps and others) that do not implement it and this cause a lot of extra code path in Nova. Sean suggested a Forum topic for Berlin to discuss it with operators also. ### Is heal_instance_info_cache_interval still needed? Let's create a job which sets heal_instance_info_cache_interval to 0, and decide the next steps based on the results. The happy moment with the team screenshot: https://photos.app.goo.gl/P6YuYgxzqEiv2gHt8 I hope next time we can meet in person :-) Thanks to everybody for the great discussions. Lajos Katona (lajoskatona)

1 0

[horizon] Cancelling Today's Weekly meeting
by vishal manchanda 12 Apr '22

12 Apr '22

Hello Team, I won't be able to chair today's horizon weekly meeting due to some travel. So if someone from team can host it on my behalf or we can skip this week meeting. Note: I will join office from thrusday so if anything urgent please reach out to horizon core team. Thanks & regards, Vishal Manchanda

1 0

[Trove][Xena] Errors when creating postgresql insances
by wodel youchi 12 Apr '22

12 Apr '22

Hi, I defined a postgresql data store with two versions 10 and 12. When creating db instances I am getting different errors : *For Postgresql 10, I am getting : * Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/taskmanager/models.py", line 436, in wait_for_instance time_out=timeout) File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/common/utils.py", line 223, in poll_until return wait_for_task(task) File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/common/utils.py", line 207, in wait_for_task return polling_task.wait() File "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/event.py", line 125, in wait result = hub.switch() File "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 313, in switch return self.greenlet.switch() File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_service/loopingcall.py", line 150, in _run_loop result = func(*self.args, **self.kw) File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/common/utils.py", line 194, in poll_and_check obj = retriever() File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/taskmanager/models.py", line 791, in _service_is_active raise TroveError(_("Service not active, status: %s") % status) trove.common.exception.TroveError: Service not active, status: failed to spawn ==> trove-conductor.log <== 2022-04-13 00:26:52.334 124 ERROR trove.conductor.manager [-] Guest exception on request req-b5bd49e8-e147-41b2-8292-2900bb4022a1: ['Traceback (most recent call last):\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", line 218, in prepare\n ds_version=ds_version)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", line 234, in _prepare\n cluster_config, snapshot, ds_version=ds_version)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/osprofiler/profiler.py", line 160, in wrapper\n result = f(*args, **kwargs)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/manager.py", line 161, in do_prepare\n self.app.start_db(ds_version=ds_version, command=command)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 229, in start_db\n raise exception.TroveError("Failed to start database service")\n', *'trove.common.exception.TroveError: Failed to start database service\n']* *And for Postgresql 12, I am getting :* Server type: guest Traceback (most recent call last): File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", line 845, in create_user self.adm.create_users(users) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 516, in create_users self.create_user(models.PostgreSQLUser.deserialize(user), None) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 549, in create_user [models.PostgreSQLSchema.deserialize(db) for db in user.databases]) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 558, in _grant_access [db.name for db in databases], File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 432, in grant_access database=database, File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 723, in psql return self.connection.execute(statement) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 763, in execute autocommit=True) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 776, in _execute_stmt cursor.execute(cmd, data_values) psycopg2.errors.InvalidCatalogName: database "dbweb01" does not exist And this error from > ==> trove-conductor.log <== > 2022-04-12 23:58:11.689 46 ERROR trove.conductor.manager [-] Guest > exception on request req-7c0e005a-2b02-4acf-bdc5-e9d7a964cd7e: > ['Traceback (most recent call last):\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", > line 808, in create_database\n return > self.adm.create_databases(databases)\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 464, in create_databases\n > self.create_database(models.PostgreSQLSchema.deserialize(database))\n', ' > File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 477, in create_database\n collation=database.collate,\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 723, in psql\n return self.connection.execute(statement)\n', ' > File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 763, in execute\n autocommit=True)\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 776, in _execute_stmt\n cursor.execute(cmd, data_values)\n', > 'psycopg2.errors.ActiveSqlTransaction: *CREATE DATABASE cannot run inside > a transaction block\n\n']* > Regards.

1 0

[openstack-helm] Dropping train support
by Gage Hugo 12 Apr '22

12 Apr '22

Hi all, One of the topics from the latest PTG discussions[0] was looking to drop support of the Train release from our charts due to a lack of interest in maintaining them and several issues with broken images due to dependencies. As a result of those discussions, we'd like to make dropping Train support a goal for this cycle. If anyone is still using Train and has a pressing issue where they cannot upgrade, please reach out and we can discuss a path forward. [0] https://etherpad.opendev.org/p/openstack-helm-zed-ptg Thanks

1 0

[openstack-helm] openstack-helm-addons and docs repository retirement
by Gage Hugo 12 Apr '22

12 Apr '22

Hey everyone, We recently had a PTG session and one of the topics that was discussed was the retirement of the openstack-helm-addons and openstack-helm-docs repositories. This topic has been mentioned now for several PTGs and from our discussion at the latest one, it was determined that due to the lack of updates to the repos as well as the charts themselves receiving no real maintenance, we would look to retire both these repositories this cycle. If anyone is still using the 3 charts that still exist in the repos and would like to maintain them, please let us know. Thanks!

1 0

[nova] final release before Victoria Extended Maintenance transition?
by Előd Illés 12 Apr '22

12 Apr '22

Hi Nova folks! We have released from stable/victoria quite recently, but there are still many open bug fixes on it [1]. If anyone from vendors / operators / developers would like to have any bugfix to be released in Victoria before the Extended Maintenance transition, please feel free to add it / mark them at our nova-stable-victoria-em etherpad [1]. Please consider that the transition deadline is in 2 weeks, so this needs to be ready as soon as possible. Nova stable cores are also welcome to review any patches. If there will be merged patches that we could release before the deadline, then I'll prepare the release patch. [1] https://etherpad.opendev.org/p/nova-stable-victoria-em Thanks, Előd

1 0

Network Node Scaling
by Adivya Singh 12 Apr '22

12 Apr '22

Hi Team, Is there any specified link available which i can go through and do "Network Node Scaling" in my Environment. We are running Openstack Xena in my environment Regards Adivya Singh

3 3

[TripleO] please stop posting patches for tripleo* stable/ussuri (going EOL)
by Marios Andreou 12 Apr '22

12 Apr '22

Hello TripleO As proposed at [1] and also discussed in yesterday's TripleO Z PTG meet [2] we are going to move stable/ussuri for all tripleo repos to EOL. In order to move ahead we need to have no open patches against stable/ussuri. ** please stop posting patches to stable/ussuri tripleo repos ** If you have open patches can you please either get them merged, or abandon them by next Tuesday 12th. After this we will have to abandon any open patches (e.g. folks moved on/not even looking there) and then I can update the EOL proposal at [3] with the latest commit hashes so we can proceed. For reference the repos with open reviews at time of writing are at [4] below. Please speak up if you need more time or with any other comments regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028025.ht… [2] https://etherpad.opendev.org/p/tripleo-zed-ci-load [3] https://review.opendev.org/c/openstack/releases/+/834049 [4] ( list of repos with open reviews for stable/ussuri): * https://review.opendev.org/q/project:openstack%252Fos-net-config+status:ope… * https://review.opendev.org/q/project:openstack%252Fpaunch+status:open+branc… * https://review.opendev.org/q/project:openstack%252Fpuppet-tripleo+status:op… * https://review.opendev.org/q/project:openstack%252Fpython-tripleoclient+sta… * https://review.opendev.org/q/project:openstack%252Ftripleo-ansible+status:o… * https://review.opendev.org/q/project:openstack%252Ftripleo-common+status:op… * https://review.opendev.org/q/project:openstack%252Ftripleo-heat-templates+s… * https://review.opendev.org/q/project:openstack%252Ftripleo-puppet-elements+… * https://review.opendev.org/q/project:openstack%252Ftripleo-validations+stat…

1 1

[Kolla-ansible][Xena] Test Trove module
by wodel youchi 12 Apr '22

12 Apr '22

Hi, I am testing the deployment of Xena, and part of my testing is to test the different modules. I am trying to test the Trove module and for now there is no dev image for Xena here : https://tarballs.opendev.org/openstack/trove/images/ So I decided to build the image, my base system is Rocky Linux, I followed the documentation here : https://docs.openstack.org/trove/latest/admin/building_guest_images.html#bu… But when executing the build command [deployer@rscdeployer scripts]$ ./trovestack build-image ubuntu bionic true ubuntu $HOME/images/trove-guest-ubuntu-bionic-dev.qcow2 ******************************************************************************* Params for cmd_build_image function: ubuntu bionic true ubuntu /home/deployer/images/trove-guest-ubuntu-bionic-dev.qcow2 ******************************************************************************* *Ensuring we have all packages needed to build image.sudo: apt-get: command not found* *I got this : sudo: apt-get: command not found * Do I have to build the image on an ubuntu system? I thought that it is similar to building the octavia image, that it is not tied to the Linux distro you are using. Regards. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 5

(Ansible Galaxy) Assign static ip to build a sever
by borges.ds＠gmail.com 12 Apr '22

12 Apr '22

Hi folks, I am using the server module to build/decomm virtual machines. However I am only able to build VMs using dynamic IP assignment.. Whenever I try to assign a static using float ips, the instruction is ignored. Could you help me to figure this out? The collection documentation is not clear about that... -- Aguardo sua resposta, David Borges de Sousa (3374-9157 / 87846638)

1 0

Resize instance vm Linux error
by Joao Oliveira 12 Apr '22

12 Apr '22

How I can Resize a Instance in the dashboard ?? [cid:image004.png@01D84B6B.A5B5F960] I try this and it is not working. Any sugestions ?? Thanks João de Deus Oliveira Ingeniero de Infraestructura [Descripción: Descripción: Descripción: Logo ITC Servicios] Informática, Tecnología & Comunicaciones Edificio ITC Tower Av. Las Ramblas #100, Torre B Barrio Equipetrol Norte Santa Cruz - Bolivia Tel: +(591) 3 344-4424 Ext. 4368 Fax: +(591) 3-344-4433 Móvil: +(591) 67011038 E-mail: joliveira(a)itcservicios.com<mailto:joliveira@itcservicios.com> Web: www.itc-e.com<http://www.itc-e.com/> AVISO DE CONFIDENCIALIDAD Y PRIVACIDAD: El uso de la información transmitida en este correo electrónico está limitado a la persona a la cual va dirigido. El correo puede contener información privada, privilegiada, confidencial o exenta de revelación bajo las leyes aplicables. Si usted no es el destinatario pretendido o sospecha que el mensaje le hubiera sido enviado sin la debida autorización, queda avisado que está estrictamente prohibido cualquier uso, diseminación o copia de esta información. Si usted ha recibido este mensaje por equivocación le pedimos notificarnos a vuelta de correo y borrar el mensaje. CONFIDENTIALITY AND PRIVACY NOTICE: This email is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us via reply email and delete this message. De: Abhishek Kekane <akekane(a)redhat.com> Enviado el: jueves, 7 de abril de 2022 14:33 Para: Anurag Singh Rajawat <anuragsinghrajawat22(a)gmail.com> CC: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Asunto: Re: [glance] Outreachy 2022 Hi Anurag, Sorry that we were not able to address you on IRC. Currently glance team is busy in PTG which will end tomorrow evening and that is why we might have missed your ping on IRC. I would suggest to share your failures so that we can guide you. I think from Monday onwards everyone will be back to their daily routine so outreachy glance team will help you to resolve your queries. Meanwhile if it is urgent then you can share your doubts and I will try my best to resolve them. Thanks and Regards, Abhishek On Thu, 7 Apr, 2022, 22:30 Anurag Singh Rajawat, <anuragsinghrajawat22(a)gmail.com<mailto:anuragsinghrajawat22@gmail.com>> wrote: Dear glance team, I'd setup glance, glance-store and glance-client on my local setup, but some tests for glance were failing, also is there any good first issues so that I can understand the project more clearly? I also asked about it in IRC but doesn't got response. Thanks Sincerely Anurag

2 2

[qa][ptg] PTG Summary
by Martin Kopec 12 Apr '22

12 Apr '22

Hello everyone, thank you to all who participated in the PTG discussions and shared their thoughts and opinions. It's very much appreciated! Here is the summary of the discussions [1]: * Yoga Retrospective ** more details in [1] * Secure RBAC ** Devstack - mostly done, it has already options to enable enforce scope ** Tempest - tests will need to be migrated *** will be started after Keystone and Nova are migrated * FIPS current status and next plans ** Tempest will use ecdsa keys by default (instead of rsa) ** QA team will help reviewing related patches *** https://etherpad.opendev.org/p/qa-zed-ptg-fips * Tempest tests in mixed-architecture environments ** there is no support in Zuul for a testing like this ** still in a brainstorming phase looking for a potential solution, if you have any ideas, feel free to reach out * Direction on replacing the scenario manager ** in progress, the plan is to finish it (merge related patches) sooner in the cycle * Retirement of QA projects ** openstack-health ** tempest-lib ** os-testr *** ostestr command was removed from os-testr repo * Future of Centos Stream support ** we'd like to create at least an experimental job on Rocky linux ** during the Zed cycle we would like to deprecated Centos 8 Stream and influence projects to start using Centos 9 Stream jobs The discussed topics are transformed into priority items [2] we will be focusing on this cycle. [1] https://etherpad.opendev.org/p/qa-zed-ptg [2] https://etherpad.opendev.org/p/qa-zed-priority Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 0

[openstack-ansible][PTG] Zed PTG results
by Dmitriy Rabotyagov 12 Apr '22

12 Apr '22

Hi everyone! Thanks everybody for taking time and attending a session. Despite we didn't have much topics in our agenda, I believe it we had great discussion about further steps in project development. We have defined topics that we aim to implement before releasing Yoga: * Move os_octavia role to use PKI role * Implement keystone RBAC support and switch services role to `service`. Be ready for final migration in Zed. * Start implementing support for encrypting connection between haproxy and it's backends * We will also try to get Ubuntu 22.04 support before release, despite in general we add Ubuntu LTS support in autumn. Following plans regarding Zed release were set: * Add unit testing of collections and common roles, with molecule. At same time we should use dependencies from integrated repo for that. * We will support concept of Tick/Tock releases and add testing for jumping through releases. * Implement shared queues for our jobs and see effect from that * Fix repo server to _really_ support multiple distros in the same environment * We should revise in AA PTL if we should keep support for non-SSL deployments, and keep upgrade path in Zed. There was an agreement to EOL Pike and Queens releases in nearest future. We also move Victoria to EM soon. With lack of contributions/interest regarding some of features we are reaching to community and interested parties to help out with support of: * Installation path from distro packages * Support of CentOS distributions If you're interested in continuation of being these part of OSA, please reach us out via ML or IRC to get more information about how you can help out. -- Kind regards, Dmitriy Rabotyagov

1 0

[all] New CFN(Computing Force Network) SIG Proposal
by niujie 12 Apr '22

12 Apr '22

Hi all I'm from China Mobile, China Mobile is recently working on build a new information infrastructure focusing on connectivity, computing power, and capabilities, this new information infrastructure is called Computing Force Network, we think OpenStack community which gathers global wisdom together is a perfect platform to discuss topics like CFN, so we are proposing to create a new SIG for CFN(Computing Force Network). Below is CFN brief introduction and initial SIG scope. With the flourish of new business scenarios such as hybrid cloud, multi-cloud, AI, big data processing, edge computing, building a new information infrastructure based on multiple key technologies that converged cloud and network, will better support global digital transformation. This new infrastructure is not only relates to cloud, it is getting more and more connected with network, and at the same time, we also need to consider how to converge multiple technologies like AI, Blockchain, big data, security to provide this all-in-one service. Computing Force Network(CFN) is a new information infrastructure that based on network, focused on computing, deeply converged Artificial intelligence, Block chain, Cloud, Data, Network, Edge computing, End application, Security(ABCDNETS), providing all-in-one services. Xiaodong Duan, Vice president of China Mobile Research Institute, introduced the vision and architecture of Computing Force Network in 2021 November OpenInfra Live Keynotes by his presentation Connection + Computing + Capability Opens a New Era of Digital Infrastructure, he proposed the new era of CFN. We are expecting to work with OpenStack on how to build this new information infrastructure, and how to promote the development and implementation of next generation infrastructure, achieve ubiquitous computing force, computing & network convergence, intelligence orchestration, all-in-one service. Then computing force will become common utilities like water and electric step by step, computing force will be ready for access upon use and connected by single entry point. The above vision of CFN , from technical perspective, will mainly focus on unified management and orchestration of computing + network integrated system, computing and network deeply converged in architecture, form and protocols aspect, bringing potential changes to OpenStack components. CFN is aiming to achieve seamlessly migration of any application between any heterogeneous platforms, it's a challenge for the industry currently, we feel that in pursuit of CFN could potentially contributes to the development and evolution of OpenStack. In this CFN SIG, we will mainly focus on discussing how to build the new information infrastructure of CFN, related key technologies, and what's the impact on OpenStack brought by the network & could convergence trend , the topics are including but not limited to: 1, A computing basement for unified management of container, VM and Bare Metal 2, Computing infrastructure which eliminated the difference between heterogeneous hardware 3, Measurement criteria and scheduling scheme based on unified computing infrastructure 4, Network solutions for SDN integrating smart NIC for data center 5, Unified orchestration & management for "network + cloud", and "cloud + edge + end" integrated scheduling solution We will have regular meetings to investigate and discuss business scenarios, development trend, technical scheme, release technical documents, technical proposal and requirements for OpenStack Projects, and propose new project when necessary. We will also collaborate with other open source projects like LFN, CNCF, LFE, to have a consistent plan across communities, and align with global standardization organization like ETSI, 3GPP, IETF, to promote CFN related technical scheme become the standard in industry. If you have any thoughts, interests, questions, requirements, we can discuss by this mailing list. Any suggestions are welcomed, and we are really hoping to hear from anyone, and work with you. Jie Niu China Mobile

1 0

[Kolla-ansible][Xena] How to undeploy (remove) a service
by wodel youchi 12 Apr '22

12 Apr '22

Hi, How can I remove a deployed service with kolla-ansible? Regards. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

[nova][placement] Zed PTG summary
by Sylvain Bauza 12 Apr '22

12 Apr '22

Yet again, let me try to provide you a summary about our previous PTG, this time for the Zed release. You can see all the notes thanks to this read-only etherpad : https://etherpad.opendev.org/p/r.75a986ce3ac43bb74b93c5de63d84fe9 ### Cross-project discussions ### # Neutron cross-project discussion with Nova - The nova community asked how to require Neutron backends to support a list of Neutron API extensions (for example multiple port bindings). We discussed whether it was rather a documentation issue or a code issue, but eventually it was rather a supporting concern as we don't test all of the backends for Nova. We then agreed on discussing this during the next OpenInfra Summit in Berlin with operators then, if possible. - We agreed on providing a new job for verifying whether heal_instance_info_cache_interval is no longer needed. # Cinder cross-project discussion with Nova - We discussed how we could remove the os-brick rootwrap config from nova and rather moving the config into directly os-brick. We eventually agreed on trying to rather implement the rootwrap->privsep transition, hopefully, thanks to some Stephen's help ;) # Cyborg cross-project discussion with Nova - We agreed on continuing to accept to provide traits for Resource Providers for owners (OWNER_NOVA at least). Context is https://review.opendev.org/c/openstack/nova-specs/+/836583 and we discussed about some implementation nits. ### Nova specific topics ### # Procedural discussions - We discussed on Yoga retrospective. We were happy to not have a RC2, to have new contributors and to have provided features to Placement for the last two cycles. We agreed to stopping to accept blind rechecks and to use the review priority label. Eventually we agreed on maybe adding new stable cores. - We need to fix Placement tests that verify the number of traits as for the moment it creates some issues. We agreed on relaxing those tests and to add a PTL doc saying we would bump os-traits and os-resource-classes usage in placement before RC1. - We agreed on having the same deadlines that for the last cycle, which are, Spec approval freeze for Zed-2 milestone (July 14th), and FeatureFreeze for Zed-3 (Sep 1st). We will have two spec review days - We agreed on keeping the same release model for os-vif - We agreed on continuing to use the review priority label in Gerrit and encourage contributors to use it (once we land the necessary changes in Gerrit) - Follow-up discussion on the novaclient CLI deprecation we agreed on Yoga. We'll modify the spec template to ask for rather updating OSC instead of the shell, and how to return some warnings if you use the shell. - We agreed on having some bug triage rotation between our contributors. I'll explain it in our next team meeting today :-) - We agreed on saying 'Unsupported' instead of 'Deprecated" for some features that need help if we don't want to remove them :-) - Again, we loudly said ***NO FOR BLIND RECHECKS*** https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-te… # New Release cadence (ie. the tick-tock release balance) - We agreed on writing some guidelines in our Nova documentation explaining the differences between tick and tock releases from a nova perspective and what people could do. We agreed on *not* bumping the compute minimum supported version in a tick release. That would also be super cool if we could have some sphinx directive in reno that contributors would use if they add/modify things in a tock release but want operators to know in the next tick. # Planned API modifications - We agreed on testing new policy defaults in the gate and not yet enforce new scopes until we are sure everything works correctly. Devstack will need modifications for those enablements and proper communication has to be made to deployment projects to make sure they're on the same page before we change anything. - We agreed on deprecating the possibility to generate new keypairs thru the Nova API. Only keypair imports will be accepted in the future. - We agreed on some usecase for adding network domain name in our metadata API. Things have to be further discussed in a spec but the direction sounds reasonable. - We agreed on letting userdata be editables. Details were discussed about the limits of this new mutable field (configdrive et when to apply) but spec will be updated accordingly. - Being able to unshelve an instance by passing a destination seems a valid usecase, spec has to be reviewed besides the implementation. - We'll try to somehow ensure that renaming tenant_id into project_id in our API isn't yet again deferred to the next cycle, even tho the series is large and merge conflicts are important. - Manila shares could be attached or detached to instances thru a new API and notifications would be emitted # Other - Centos9 will be tested on a weekly basis in our gate at first - Nova healthcheck is definitely a thing we want, but we miss hands on deck. - having PCI devices being tracked in Placement is also something we'd love to see arriving on this cycle - we'll continue further testing emulated hardware. Maybe some blueprints would come up but we also said we'll try to give visibility on the periodic gate runs by looking at them in our weekly meeting. - We discussed a very interesting case with the Scaphandre project that needs to use virtio-fs for passing system usage to the guests. We eventually agreed on two possible directions, with one preferred, which is to reuse the Manila shares support we're going to add in Zed. - We can be smarter on placing guest CPUs on physical cores or dies, but this requires a blueprint at least as we agreed on providing some flavor extraspec or image property for letting operators to define the CPU placement. - Windows guests would benefit from new enlightenments in Zed if we merge some small change - Having CPU cores be externally managed by a daemon that would turn them on/off based on consumption seems a valid usecase. We discussed about some details but spec has to be reproposed. That's it. If you reached this line, kudos, you're brave. I tried to be short, but it looks to me I failed. Anyway, the source of truth remains the etherpad, just please avoid to amend it now. -Sylvain

1 0

[openstack-helm] No meeting this week
by Gage Hugo 11 Apr '22

11 Apr '22

Hey team, Since there is nothing on the agenda the meeting for this week is cancelled. We will meet next week at the usual time.

1 0

Infrastructure and Virtual Resources utilisation tool for openstack cloud
by KK CHN 11 Apr '22

11 Apr '22

List, Can anyone point out the best metering and monitoring tool/tool combination for the complete infrastructure statistics and ( for report generation) as well as virtual resources utilization (including health check of virtual machines / virtual resources ) report generation tools which can be integrated with OpenStack middleware. ? any suggestions most welcome. Thanks in advance, Krish

1 0

[all][tc] Canceling TC this week meetings
by Ghanshyam Mann 11 Apr '22

11 Apr '22

Hello Everyone, TC will not have this week meeting and will continue the weekly meeting from April 21st onwards. -gmann

1 0

[neutron][ops] OVN scale issues and reviving midonet plugin
by Sam Morrison 11 Apr '22

11 Apr '22

Hi, We recently tried to migrate our install from ML2 midonet -> OVN driver on our Victoria Openstack install with ~1000 hypervisors. Victoria was the last release where midonet plugin was supported so was a good motivation to move. Unfortunately when we changed the neutron-server config over to use OVN in our production install everything went very bad. We got lots of things like: ovsdbapp.exceptions.TimeoutException: Commands [<neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.commands.CheckRevisionNumberCommand object at 0x7fa3b84bd8b0>, <neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.commands.SetLSwitchPortCommand object at 0x7fa37b04cf40>, <ovsdbapp.schema.ovn_northbound.commands.PgDelPortCommand object at 0x7fa375ae0fd0>] exceeded timeout 180 seconds, cause: TXN queue is ful ovsdbapp.exceptions.TimeoutException: Commands [<neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.commands.CheckRevisionNumberCommand object at 0x7f0ee5197dc0>, <neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.commands.SetLSwitchPortCommand object at 0x7f0ee50a92e0>, <ovsdbapp.schema.ovn_northbound.commands.PgAddPortCommand object at 0x7f0ee5181760>] exceeded timeout 180 seconds, cause: Result queue is empty ovsdbapp.exceptions.TimeoutException: Commands [<ovsdbapp.backend.ovs_idl.command.DbDestroyCommand object at 0x7fcd99f9ea90>] exceeded timeout 180 seconds, cause: Result queue is empt among other things, which forced us to roll back. Our next approach is to get everything up to yoga and try again, (with some better live testing before we make the switch somehow) In the mean time we have revived the networking-midonet plugin in our own branch but just wanted to check to see if anyone else is in this situation and are or have looked into running midonet on wallaby and beyond? Cheers, Sam

1 0

[manila][ussuri] Manila return 404 resource not found after simple install
by CHANU ROMAIN 11 Apr '22

11 Apr '22

Hello, I tried to install manila on Ubuntu servers and I'm stuck during the first steps. I followed this documentation: https://docs.openstack.org/manila/ussuri/install/install-controller-ubuntu.… When I tried to verify the operation I always get the same message: # manila service-list ERROR: Not Found (HTTP 404) In manila-api.log 2022-04-11 12:12:56.533 125 INFO eventlet.wsgi.server [req-c03111de- 46bb-40e1-9440-2f62a94a61f0 ee3ae5e43b4c6246c4d95264b2978bf05dce57920b6b852d62b450ad6e7fb392 59bc7ad25c364c809a97c1a55caec161 - - -] IP_CLIENT,IP_LB "GET /v2/services HTTP/1.1" status: 404 len: 228 time: 0.1233838 If I use -d #manila -d service-list DEBUG (connectionpool:208) Starting new HTTP connection (1): FQDN DEBUG (connectionpool:396) http://FQDN:8786 "GET /v2/services HTTP/1.1" 404 112 RESP: [404] {'Content-Length': '112', 'Content-Type': 'application/json', 'Date': 'Mon, 11 Apr 2022 12:14:51 GMT'} RESP BODY: {"message": "The resource could not be found.<br /><br />\n\n\n", "code": "404 Not Found", "title": "Not Found"} Services are running, database is populated, rabbitmq has some exchanges... I currently run out of ideas... Did someone already face this issue? Best regards, Romain

2 1

Re: [neutron] exposing ip address of external Network from
by A Monster 11 Apr '22

11 Apr '22

Hi, indeed I have dhcp disabled for this network, and that's because I have an external dhcp server which attributes ip addresses to hosts on this network, so I cannot check the dhcp option when creating subnets for this public network.

1 0

[neutron] Bug Deputy Report January 03 - 10
by Lucas Alvares Gomes 11 Apr '22

11 Apr '22

Hi, This is the Neutron bug report from January 3rd to 10th. Critical: * https://bugs.launchpad.net/neutron/+bug/1956344 - "Functional test test_gateway_chassis_rebalance is failing intermittently" - Assigned to: Rodolfo Alonso High: * https://bugs.launchpad.net/neutron/+bug/1956034 - "ovn load balancer health monitor cause mac address conflict" - Unassigned * https://bugs.launchpad.net/neutron/+bug/1956745 - " [ovn-octavia-provider] Load Balancer remained with ACTIVE state even with PENDING_UPDATE listener" - Assigned to: Luis Tomas Bolivar * https://bugs.launchpad.net/neutron/+bug/1956763 - "[OVN] Overlapping configuration for security group logging is not applied correctly" - Assigned to: Elvira Garcia Ruiz Medium: * https://bugs.launchpad.net/neutron/+bug/1956035 - "ovn load balancer member failover not working when accessed from floating ip" - Unassigned * https://bugs.launchpad.net/neutron/+bug/1956632 - "DNS integration documentation and scenario tests need update after dns_assignment calculation was changed" - Assigned to: Miguel Lavalle * https://bugs.launchpad.net/neutron/+bug/1956785 - "Duplicate validator TypeError for dict values Edit" - Assigned to: Harald Jensås Low: * https://bugs.launchpad.net/neutron/+bug/1956476 - "[OVN] Disallow multiple physnets per bridge" - Assigned to: Rodolfo Alonso * https://bugs.launchpad.net/neutron/+bug/1956770 - " keepalived no_track implemented in >= 2.0.3" - Assigned to: Rodolfo Alonso Needs further triage: * https://bugs.launchpad.net/neutron/+bug/1956435 - "OVS: support multiple segments per host" - Unassigned * https://bugs.launchpad.net/neutron/+bug/1956460 - "The VM can't get metadata from dhcp-agent" - Unassigned * https://bugs.launchpad.net/neutron/+bug/1956846 - "ha router duplicated routes" - Unassigned Cheers, Lucas

4 7

[zuul][neutron][neutron-fwaas][tap-as-a-service] Errors in the jobs definitions and EOL of some old neutron-fwaas and tap-as-a-service branches
by Lajos Katona 11 Apr '22

11 Apr '22

Hi, During the PTG we got questions about projects which cause zuul config errors (see [1]). Slawek started a thread regarding networking-midonet (see [2]), I join to that with neutron-fwaas and tap-as-a-servie. - neutron-fwaas' stable/rocky and stable/queens branches - tap-as-a-service stable/ocata, stable/pike, stable/queens and stable/rocky branches are affected - as tap-as-a-service was under x/ namespace previously I am not sure what can happen to those branches. If there is nobody to fix the config and gate errors on these old branches, then the best would be to EOL and later delete these branches. [1]: https://zuul.opendev.org/t/openstack/config-errors [2]: http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028120.ht…

1 0

[requirements][kolla][infra] Python versions in u-c
by Marcin Juszkiewicz 11 Apr '22

11 Apr '22

OpenStack Zed lists Python 3.8 as minimal version. Debian 'bullseye' (current stable) as Python 3.9, Ubuntu 20.04 'focal' has 3.8. Ubuntu 22.04 'jammy' has 3.10, CentOS Stream 9 (so RHEL 9, Rocky Linux 9) has 3.9 version. We ignore anything RHEL 8 based as they have Python 3.6 only and there is no work on getting OpenStack Zed supported there. So there will be 3.8, 3.9, 3.10 used with Zed. Two question to requirements team: 1. Are there plans to get rid of 3.6 entries from openstack/requirements/upper-constraints.txt in near future? 2. Can we get "python_version=='3.8'" lines be changed to ">=" ones? Or once 3.6 entries drop just assume that we have 3.8+ and drop 'python_version' entries? websocket-client===1.3.1;python_version=='3.6' websocket-client===1.3.2;python_version=='3.8' Asking due to my recent Kolla/infra work on getting CentOS Stream 9 supported in both places. Infra team has CI job which builds Python wheel cache to make sure that other CI jobs do not have to do it. Times are nicely cut due to this stuff. There are 55 entries with "python_version=='3.8'". Probably none of them are time critical anymore as upstream projects provide aarch64 wheels most of times too.

2 1

[Zuul] [neutron] Errors in the jobs definitions and EOL of some old networking-midonet branches
by Slawek Kaplonski 11 Apr '22

11 Apr '22

Hi, Today I got back to checking my old patches which are going to fix some zuul jobs' definitions. And I found that CI for networking-midonet in some stable branches is totally broken: * stable/ussuri: https://review.opendev.org/c/openstack/networking-midonet/+/823273[1] - everything is red here * stable/train: https://review.opendev.org/c/openstack/networking-midonet/+/823275[2] - most of the jobs are red * stable/stein: https://review.opendev.org/c/openstack/networking-midonet/+/823276[3] - here there were errors in the definition of the jobs, I changed it now, maybe it will run, So my question is if we want, and have resources, to fix it somehow or should we maybe set those branches as EOL now? Also, another question to the Zuul team - will it be ok if such branch will be EOL to get rid of the Zuul configuration errors warnings? Or should we somehow force to merge those patches first to get rid of the errors in https://zuul.opendev.org/t/openstack/config-errors[4] ? -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/openstack/networking-midonet/+/823273 [2] https://review.opendev.org/c/openstack/networking-midonet/+/823275 [3] https://review.opendev.org/c/openstack/networking-midonet/+/823276 [4] https://zuul.opendev.org/t/openstack/config-errors

2 2

[all][neutron] Pike - End of Life
by Lajos Katona 11 Apr '22

11 Apr '22

Hi, As time and cycles are passing it's time to bring up the topic of EOLing an old branch again. In Neutron (and its satellite projects, aka stadium) stable/pike has had low activity in the last cycle and recently even the jobs for it started to fail, and we cause some zuul config errors which are hard to fix as the gate is broken. Based on the Ocata EOL mail (see [1]), Neutron team decided to EOL Pike, see the discussions during the Zed PTG (see [2]) [1]: http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021949.ht… [2]: https://etherpad.opendev.org/p/neutron-zed-ptg#L254 Lajos Katona (lajoskatona)

1 0

[vmware-nsx] EOL old branches
by Slawek Kaplonski 11 Apr '22

11 Apr '22

Hi Salvatore, According to Your comments in my patches to x/vmware-nsx project: * stable/stein: https://review.opendev.org/c/x/vmware-nsx/+/823277[1] * stable/rocky: https://review.opendev.org/c/x/vmware-nsx/+/823291[2] Can You maybe make them EOL finally? -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/x/vmware-nsx/+/823277 [2] https://review.opendev.org/c/x/vmware-nsx/+/823291

1 0

[neutron] Bug Deputy Report April 04 - 11
by Lucas Alvares Gomes 11 Apr '22

11 Apr '22

Hi, This is the Neutron bug report from April 4th to 11th. Critical: * https://bugs.launchpad.net/neutron/+bug/1967893 - " [stable/yoga] tempest.scenario.test_network_qos_placement.MinBwAllocationPlacementTest fails in neutron-ovs-tempest-multinode-full job Edit" - Assigned to: Lajos Katona High: * https://bugs.launchpad.net/neutron/+bug/1967839 - " [L3] NDP extension not handing "ha_state_change" correctly" - Assigned to: Rodolfo Alonso * https://bugs.launchpad.net/neutron/+bug/1967996 - "[OVN] External subscribers to feed generated in Openstack fails if no internal VM is subscribed to that feed first" - Unassigned Medium: * https://bugs.launchpad.net/neutron/+bug/1967742 - "ML2 - Network Context, not possible to see original/current segments" - Unassigned * https://bugs.launchpad.net/neutron/+bug/1968343 - "Security Group Rule create with forged integer security_group_id causes exceptions" - Assigned to: Andrew Karpow Needs further triage: * https://bugs.launchpad.net/neutron/+bug/1968057 - "Doc needed for configuring neutron AZs for edge" - Unassigned * https://bugs.launchpad.net/neutron/+bug/1968269 - " [router qos] qos binding is not clear after remove gateway" - Unassigned Cheers, Lucas

1 0

[Senlin][Zuul] Errors in the jobs definitions in stable branches
by Slawek Kaplonski 11 Apr '22

11 Apr '22

Hi, Some time ago I pushed patches to fix definitions of the Zaqar's jobs in stable branches: * stable/stein: https://review.opendev.org/c/openstack/senlin/+/823287[1] * stable/rocky: https://review.opendev.org/c/openstack/senlin/+/823293[2] * stable/queens: https://review.opendev.org/c/openstack/senlin/+/823294[3] It seems that CI for all those branches is broken. Do You still have plans to fix it so I can rebase my patches and we can get rid of those zuul's configuration errors? Or should those branches be maybe EOL? -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/openstack/senlin/+/823287 [2] https://review.opendev.org/c/openstack/senlin/+/823293 [3] https://review.opendev.org/c/openstack/senlin/+/823294

1 0

[Zaqar][Zuul][TC] Errors in the jobs definitions in stable branches
by Slawek Kaplonski 11 Apr '22

11 Apr '22

Hi, Some time ago I pushed patches to fix definitions of the Zaqar's jobs in stable branches: * stable/stein: https://review.opendev.org/c/openstack/zaqar/+/823289[1] * stable/rocky: https://review.opendev.org/c/openstack/zaqar/+/823295[2] * stable/queens: https://review.opendev.org/c/openstack/zaqar/+/823296[3] * stable/pike: https://review.opendev.org/c/openstack/zaqar/+/823297[4] It seems that CI for all those branches is broken. Do You still have plans to fix it so I can rebase my patches and we can get rid of those zuul's configuration errors? Or should those branches be maybe EOL? I'm tagging TC in the topic of that email too as there is still no PTL of the Zaqar project appointed. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/openstack/zaqar/+/823289 [2] https://review.opendev.org/c/openstack/zaqar/+/823295 [3] https://review.opendev.org/c/openstack/zaqar/+/823296 [4] https://review.opendev.org/c/openstack/zaqar/+/823297

1 0

error
by Reza Bojnordi 11 Apr '22

11 Apr '22

Hi, sorry I have problem on Openstack tcd3gw': No module named 'etcd3gw': ModuleNotFoundError: No module named 'etcd3gw' Apr 09 20:09:34 infra1-nova-api-container-483c43d7 nova-metadata-wsgi[2912]: 2022-04-09 20:09:34.836 2912 ERROR stevedore.extension [req-089ca62f-02ee-49f9-a305-75f426102ebc - - - - -] Could not load 'oslo_cache.e tcd3gw': No module named 'etcd3gw': ModuleNotFoundError: No module named 'etcd3gw' -- <https://about.me/rbojnordi?promo=email_sig&utm_source=product&utm_medium=em…> reza bojnordi about.me/rbojnordi <https://about.me/rbojnordi?promo=email_sig&utm_source=product&utm_medium=em…>

4 4

[baremetal-sig][ironic] Tue Apr 12, 2022, 2pm UTC: "Using OpenStack Ironic for HPC at Berlin Institute of Health"
by Arne Wiebalck 11 Apr '22

11 Apr '22

Dear all, The Bare Metal SIG will meet tomorrow Tue Apr 12, 2022, 2pm UTC featuring a topic of the day presentation by Dr. Manuel Holtgrewe: "Bare Metal for Health - Using OpenStack Ironic for HPC at Berlin Institute of Health" Everyone is welcome, all details on how to join can be found on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Hope to see you there! Arne -- Arne Wiebalck CERN IT

1 0

[Glance] Zed PTG Summary
by Abhishek Kekane 10 Apr '22

10 Apr '22

Hi All, We had our fifth virtual PTG between 4th April to 8th April 2022. Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app we had lots of discussion around different topics for glance, glance + cinder, fips and Secure RBAC. I have created etherpad [1] with Notes from the session and which also includes the recordings of each discussion. Here is a short summary of the discussions. Tuesday, April 5th 2022 # Yoga Retrospective On the positive note, we managed to complete all the work we targeted for the yoga cycle. In addition to that we have organized a first ever glance review party where we managed to perform group reviews which helped us to cover our review load in the final milestone. On the other side we need to reorganize our bi-weekly bugs meeting and also improve our documentation and API references. Recording: https://bluejeans.com/s/kVeDPbu6kX2 - Chapter 1 # Cache API - New API to trigger periodic job In Yoga we have managed to put together new endpoints for cache, this cycle we should add a new API to trigger the periodic job to cache the images. Here we have decided to get rid of periodic job and add a new API to cache(pre-cache) the specified image(s) instantly rather than waiting for the next periodic run to pre-cache those images. Recordings: https://bluejeans.com/s/kVeDPbu6kX2 - Chapter 2 # Glance Cache improvements, restrict duplicate downloads How we can avoid multiple downloading of the same image in cache on first download. Final design - https://review.opendev.org/c/openstack/glance-specs/+/734683 Recordings: https://bluejeans.com/s/kVeDPbu6kX2 - Chapter 3 # Distributed responsibilities among cores/team >From this cycle we have decided to follow a distributed leadership model internally which will help us to train internal members to take the PTL responsibilities in the upcoming cycle. We have decided to distribute the below responsibilities among ourselves in this cycle. Release management: pranali/abhishek Bug management: cyril/abhishek Meetings:pranali Stable branch management: jokke Cross project communication:abhishekk Mailing lists:pranali/abhishekk PTG/summit preparation:pranali/abhishekk Vulnerability management: jokke Infra management: abhishekk Recordings: https://bluejeans.com/s/kVeDPbu6kX2 - Chapter 4 # Secure RBAC - System Scope Unfortunately due to time crunch we were not able to find answers to a few of our queries in this PTG, so we have decided to attend the Open office hours and Policy popup meetings to get them sorted. As per community goal we should be enforcing the new RBAC policies from this cycle and support system-admin. Once we get our doubts sorted then we will share more information about the same. Recordings: https://bluejeans.com/s/kVeDPbu6kX2 - Chapter 5 # Policy refactoring - Part 2 In Xena we have managed to move all policy checks to the API layer. This cycle we need to work on removing dead code of policy and authorization layer. So we are going to ensure that the policy and authorization layer are not used anywhere before removing it from the code base. Recordings: https://bluejeans.com/s/kVeDPbu6kX2 - Chapter 6 Wednesday, April 06th 2022 # Proposal for moving away from onion architecture This is a long term goal and from this cycle we should start doing homework on how we can squash two or more layers together and move away from the onion architecture and obtain a popular and simple MVC architecture in upcoming cycles. This cycle we will be mostly working on finalizing the detail spec about this work. Recordings: https://bluejeans.com/s/ZmURX2kOeJy - Chapter 1 # Import image from another region When dealing with a multi-region cloud it often appears that operators or customers need to copy images from a region to another (it can be public images or even remote backup of instance snapshot). It is currently complicated to implement as customers need to save the image locally, then upload it to the new region. We propose to rely mostly on the web-download code of glance to directly download an image from a remote glance, calling this method « glance-download ». Note that this first version will require a federated Keystone between all the glance in order to avoid all authentication problems (we will rely on the context token of the target glance to authenticate to the remote glance). Recordings: https://bluejeans.com/s/ZmURX2kOeJy - Chapter 2 # Expanding stores-info detail for other stores In Yoga we added a new API ``stores-detail`` to expose the properties of stores but currently it is only exposing details of rbd store, we are planning to extend its support to expose properties of other stores as well. Recordings: https://bluejeans.com/s/ZmURX2kOeJy - Chapter 3 # Discussion of property injection coherency between image import and possible implementation in upload Glance does support injecting certain properties for images created by non-admin users by using inject metadata import plugin, but same is not possible when we do not use import workflow and use traditional way to create the image. This cycle we will be working on supporting injecting the metadata while creating images using upload workflow. https://bluejeans.com/s/ZmURX2kOeJy - Chapter 4 Thursday, April 07th 2022 # Refactor glance cinder store Currently we have one file for cinder store where the logic for handling all cinder backend types (on basis of protocol) exists. It makes the code less readable and prone to mistakes and even the unit testing for code coverage is difficult due to a lot of nested code. The idea of this proposal is to divide the one big file into backend specific files on the basis of operations sharing the same interface. Eg: connect_volume call for most of the backends is the same except for remotefs type drivers where it is handled in a custom way. https://bluejeans.com/s/oiS49m8Pj_o - Chapter 1 # Native Image Encryption Barbican updates: - Microversion is done - Secret consumer will be implemented by milestone 1 - Luzi is interested to work on image encryption - Glance will keep watch and review the work if posted this cycle # Default Glance to configure multiple stores Glance has deprecated single stores configuration since Stein cycle and now will start putting efforts to deploy glance using multistore by-default and then remove single store support from glance. This might be going to take a couple of cycles, so in yoga we are going to migrate internal unit and functional tests to use multistore config and also going to modify devstack to deploy glance using multistore configuration for swift and Ceph (for file and cinder it's already supported). We need to notify respected deployment teams (ansible/tripleo/ceph-admin) about our work and we are moving from single store configuration. Recordings: https://bluejeans.com/s/oiS49m8Pj_o - Chapter 2 # Fips overview Path forward: - add experimental/periodic fips job on centos 8 (it will run on master) - centos 9 dependency fixes (tempest and swift changes) - Once dependency merges, experimental/periodic job will be run for centos 9 (enough time to verify that it is stable now) - Once it is stable, move it to check/gate queue - Then backport swift/tempest dependencies to stable branches - Run centos 9 fips job as periodic on stable branches - Once stable move those to gate/check queue for stable branches Recordings: https://bluejeans.com/s/oiS49m8Pj_o - Chapter 3 # Cross project meet with Cinder Discussion 1: New API to expose location information We have OSSN-0065 describing the security risk of enabling ``show_multiple_locations`` option but this is required for cinder to perform certain optimizations when creating a volume from image (in case of cinder and RBD store). The proposal is to create a new admin only API to provide the location of the image and avoid dependency on the config options. Decided to write a spec describing the current API design for the new locations API (alternative: nova's approach of using alternative endpoint and service role/token as well) Discussion 2: Clone v2: RBD deferred deletion Recently cinder has utilized Ceph clone v2 support for its RBD backend, since then if you attempt to delete an image from glance that has a dependent volume, all future uses of that image will fail in error state. Despite the fact that the image itself is still inside of Ceph/Glance. This issue is reproducible if you are using ceph client version greater than 'luminous'. Decided to fix things on cinder side and see how we can fix glance using the same techniques (also document it since customers face these issues all the time) Recordings: https://bluejeans.com/s/efAqf0e5RDQ - Chapter 2 Friday, April 08th 2022 # Image Export with metadata Especially if we implement the glance-download discussed on Wednesday it might be worth exploring my old idea of image export, which would bundle the image metadata together with the image payload itself for easier import into the glance environment. This will need bits of work on both sides of the process. The source will need to be able embed the metadata into the end of the datastream sent to the client and the receiving end will need to understand how to pick up and parse that data. To make easier transfer of the image (especially RAW images from all of our Ceph deployments) the original image payload should be compressed on the fly when sent to the client and the metadata can be added after the compression is closed. This way the image can be brought in older glance deployments too that supports the uncompression and if it doesn't know to look at the metadata that part will be just simply ignored. Recordings: https://bluejeans.com/s/C7F5pDPR_v4 - Chapter 1 You will find the detailed information about the same in the PTG etherpad [1] along with the recordings of the sessions and milestone wise priorities at the bottom of the etherpad. Kindly let me know if you have any questions about the same. [1] https://etherpad.opendev.org/p/zed-glance-ptg Thank you, Abhishek

1 0

Xena and CEPH RBD backend (show_image_direct_url status )
by west, andrew 09 Apr '22

09 Apr '22

Hello experts Currently using openstack Xena and Ceph backend (Pacific 16.2.7) It seems there is a bug (since Wallaby?) where the efficient use of a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is not working . Show_image_direct_url needs to be False to create volumes (or ephemeral volumes for nova) This can of course be tremendously slow (Nova , ephemeral root disk) without copy-on-write cloning feature of Ceph. As Ceph RBD is THE most favourite backend for block storage in openstack I am wondering how others are coping (or workarounds found ?) Which combinations of Openstack and Ceph are known to work well with copy-on-write-cloning? How is the noted GRAVE Security RISK of enabling Show_image_direct_url mitigated ? (i.e I think , for CEPH RBD, it needs to be True to get cloning to work efficiently) See another report of this issue here: Re: Ceph Pacifif and Openstack Wallaby - ERROR cinder.scheduler.flows.create_volume - CEPH Filesystem Users (spinics.net)<https://www.spinics.net/lists/ceph-users/msg66016.html> Thanks for any help or pointers, Andrew West Openstack consulting CGG France ________________________________ "This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of the email by others is strictly prohibited. If you are not the intended recipient, you must not review, disclose, copy, distribute or use this e-mail; please delete it from your system and notify the sender immediately."

7 9

Magnum not working / kube minions not spawning
by Oliver Weinmann 09 Apr '22

09 Apr '22

Hi, I recently deployed Openstack wallaby using kolla-ansible and also deployed magnum. I know it was working fine a while ago and I was able to spin up K8s clusters without a problem. But I think This was on Ussuri back then. I went through the magnum troubleshooting guide but couldn’t solve my problem. Magnum spins up the master node and I can log in via SSH using its floating IP. I checked the logs and saw this after waiting for a few minutes: role.kubernetes.io/master="" + echo 'Trying to label master node with node-role.kubernetes.io/master=""' + sleep 5s ++ kubectl get --raw=/healthz Error from server (InternalError): an error on the server ("[+]ping ok\n[+]log ok\n[+]etcd ok\n[+]poststarthook/start-kube-apiserver-admission-initializer ok\n[+]poststarthook/generic-apiserver-start-informers ok\n[+]poststarthook/start-apiextensions-informers ok\n[+]poststarthook/start-apiextensions-controllers ok\n[-]poststarthook/crd-informer-synced failed: reason withheld\n[-]poststarthook/bootstrap-controller failed: reason withheld\n[-]poststarthook/rbac/bootstrap-roles failed: reason withheld\n[-]poststarthook/scheduling/bootstrap-system-priority-classes failed: reason withheld\n[+]poststarthook/apiserver/bootstrap-system-flowcontrol-configuration ok\n[+]poststarthook/start-cluster-authentication-info-controller ok\n[+]poststarthook/start-kube-aggregator-informers ok\n[+]poststarthook/apiservice-registration-controller ok\n[+]poststarthook/apiservice-status-available-controller ok\n[+]poststarthook/kube-apiserver-autoregistration ok\n[-]autoregister-completion failed: reason withheld\n[+]poststarthook/apiservice-openapi-controller ok\nhealthz check failed") has prevented the request from succeeding + '[' ok = '' ']' + echo 'Trying to label master node with node-role.kubernetes.io/master=""' + sleep 5s Trying to label master node with node-role.kubernetes.io/master="" ++ kubectl get --raw=/healthz + '[' ok = ok ']' + kubectl patch node k8s-test-small-cal-zwe5xmigugwj-master-0 --patch '{"metadata": {"labels": {"node-role.kubernetes.io/master": ""}}}' Error from server (NotFound): nodes "k8s-test-small-cal-zwe5xmigugwj-master-0" not found + echo 'Trying to label master node with node-role.kubernetes.io/master=""' Running kubectl get nodes is just empty even when appending all-namespaces. I pretty much used the documentation that I created when I was using Ussuri. I wonder what has changed since then that would make this fail. I googled for hours but was not able to find similar issues and if then it was about having different version of k8s server and client. Which is definitely not the case. I also tried this on Xena but it also fails. I do have the feeling that the issue is network related but I do not see any issues at all spinning up instances and also the communication between instances works fine. Here are my current configs: Globals.yml [vagrant@seed ~]$ grep ^[^#] /etc/kolla/globals.yml --- kolla_base_distro: "centos" kolla_install_type: "source" openstack_release: "wallaby" kolla_internal_vip_address: "192.168.45.222" kolla_external_vip_address: "192.168.2.222" network_interface: "eth2" neutron_external_interface: "eth1" keepalived_virtual_router_id: "222" enable_haproxy: "yes" enable_magnum: “yes” multinode hosts file control[01:03] ansible_user=vagrant ansible_password=vagrant ansible_become=true api_interface=eth3 compute[01:02] ansible_user=vagrant ansible_password=vagrant ansible_become=true api_interface=eth3 [control] # These hostname must be resolvable from your deployment host control[01:03] # The above can also be specified as follows: #control[01:03] ansible_user=vagrant ansible_password=vagrant ansible_become=true #compute[01:02] ansible_user=vagrant ansible_password=vagrant ansible_become=true # The network nodes are where your l3-agent and loadbalancers will run # This can be the same as a host in the control group [network] control[01:03] #network01 #network02 [compute] compute[01:02] [monitoring] control[01:03] #monitoring01 # When compute nodes and control nodes use different interfaces, # you need to comment out "api_interface" and other interfaces from the globals.yml # and specify like below: #compute01 neutron_external_interface=eth0 api_interface=em1 storage_interface=em1 tunnel_interface=em1 [storage] control[01:03] #storage01 [deployment] localhost ansible_connection=local cat /etc/kolla/config/magnum.conf [trust] cluster_user_trust = True Sorry for the formatting. Sending this on a smartphone with plenty of copy and paste. Best Regards, Oliver

1 1

[tc][all][ Technical Committee Zed Virtual PTG discussions details
by Ghanshyam Mann 08 Apr '22

08 Apr '22

Hello Everyone, I am writing the Technical Committee discussion details from the Zed cycle PTG this week. We had a lot of discussions and that is why it is a long email but I tried to categorize the details per topic so that you can easily spot the discussion you are interested in. TC + Community leader's interaction ============================ We continue the interaction session in this PTG also. The main idea here is to interact with community leaders and ask for their feedback on TC. I am happy to see more attendance this time. Below are the topics we discussed in this feedback session. * Updates from TC: ** Status on previous PTG interaction sessions' Action items/feedback: *** TC to do more technical guides for the project: DONE We have a unified limit as the first technical guide to start in this[1]. *** TC to define a concrete checklist to check goal readiness before we select a goal: DONE We decoupled the community-wide goal from the release cycle[2] and also added the goal readiness checklist[3]. *** Spread the word: DONE We have updated a new page in project-team-guide where projects can spread the word/story[4] ** Do not do ignorant Recheck: Recheck without seeing the failure even those are not related to the proposed change is very costly and end up consuming a lot of infra resources. Checking the failure and adding comments in why you are doing a recheck will give related projects a chance to know the frequent failures happening in upstream CI and so does we can spend more time fixing them. Dan Smith has added detailed documentation on "How to Handle Test Failures"[5], this can be used to educate the contributors on recheck and how to debug the failure reason. *** Action Item: **** PTL to start spreading the word and monitor ignorant recheck in their weekly meeting etc. **** On ignorant recheck, Zuul to add a comment with the link to recheck practice documentation. ** Spread the word/project outreach: This was brought up again in this PTG but I forget to update that we did work on this in the Yoga cycle and updated the project-team-guide to list the places where the project can spread the word/story[4]. It is ready for projects to refer it and know where they can post their stories/updates. * Recognition to the new contributors and encourage/help them to continue contributing to OpenStack: When there is a new contributor who contributes a significant amount of work to any project then we should have some way to appreciate them. It can be an appreciation certificate/badge from the foundation or TC, appreciation on social media, especially on linked-in. In TC, we will check what is the best possible and less costly way to do so. We checked in cross-community session with k8s and they seem to have coupon/badge distribution from CNCF foundation. 2021 user survey analysis =================== Jay has prepared the summary of the 2021 TC survey[6] and we covered it at a high level, especially the big changes from the previous survey. As the next step, we will review the proposed summary and merge it. Also, we talked about updating the upgrade question when we start the tick/tock release. Prepare to migrate for SQLAlchemy 2.0 ============================== sqlalchemy 2.0 is under development and might have many incompatible changes. To prepare OpenStack in advance, Stephen sent the mail on what are changes and project needs to do[7], also gave the project status. oslo.db is all good to use the sqlalchemy 2.0 and the required neutron change is also merged. Thanks to Stephen for driving it and taking care of various project work. Elections Analysis: ============== Project elections are not going well and we end up with a lot of missing nominations. This cycle, we had 17 projects on the leaderless list and out of it, 16 missed the nomination. There are various factors that lead to missing nomination, short notice from the election (1-2 weeks), PTLs are not active on ML, Language, Time Zone etc. By seeing the number of leaderless projects end up having the new PTLs (this cycle it was just 1 project) and having such projects repeating the nomination miss, we thought election in those projects are not actually required. TC agrees to change the leader assignment for such a project and instead of finding PTL, we will propose to move these projects to the DPL model. WIth the DPL model, we do not need to repeat the PTL assignment in every cycle. Please note, moving them to DPL model will not be automatically done instead that will be done when there are required liaisons to take care of DPL responsibility. Community-wide goals Check In & discussion: =================================== * FIPS goal ade_lee gave the current status of this FIPS work progress in various projects[8]. Current FIPS jobs are based on the centos9 stream which is not so stable but we will keep monitoring it. Canonical has suggested a way to set up FIPS jobs on ubuntu and will give the foundation keys to do FIPS testing and periodically rotate them. One challenge is the horizon which has the dependencies on Django fix and that will be present in Django higher version (4.0 or later) and it is difficult for the horizon to upgrade to that, especially the current bandwidth team has. He also proposed the different milestones to finish the FIPS work[9]. The Technical Committee agreed to have this as a 'selected goal' and as the next step ade_lee will propose it in governance with defined milestone and we will review it. Thanks, ade_lee for all your work and energy in this. * RBAC goal I have summarised it in a separate email, please refer to it - http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028103.ht… Release Cadence Adjustment: ======================= In TC and leaders' interaction sessions, Dan presented an overview of the new release cadence and explain the things which will be changed. After that project followed the discussion in their project PTG sessions and then brought the question in the Thursday TC session. There was a question if we can remove the things (which are deprecated in tick release) in tock release and the answer is yes. We discussed the automation of deprecation/upgrade release notes from tock release to tick release and it is fine but we need to make sure we do not make tick release notes so big that people start ignoring those. We will see how it goes in a few of the initial tick release notes. Below are the various other things which need changes: * ACTION: ** Deprecation document in project-team-guide[10]: *** Add the master deployment case as a recommendation *** Intermediate release upgrade case *** Update 4-a paragraph to clarify the 12 months case and things deprecated in tick can be removed in the next tock release. ** Testing runtime *** In tock release, it is ok to add/test the new python version but do not upgrade the distro version. *** In tick release: no change and keep doing the same what we do currently ** Stable branch *** Update release and stable team with what is proposed in https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad… ** tick-tock name: ***gmann to check foundation about trademark check on "tick", "tock" name Remove release naming instead just use the number ======================================= In yoga cycle, we changed the release naming convention to add the number also in <year>.<release count in that year> format[11]. But the release name is less fun nowadays and more of a conflict or objection from the community. Starting from Ussuri, I have seen objections on many release names and the most recent is 'Zed'. Being one of the release name process coordinators for the last couple of releases, I feel that I am doing a good job and have to accept the blame/objection. Also, the process of selecting the release name has its own cost in terms of TC, community time as well as the cost of the legal check by the foundation. Having only the release number will help to understand how old that release is and also in understanding the tick-tock releases. The Drawback of removing the release name is that it requires changes in release tooling and will be less helpful in marketing. The former one is a one-time change and later once can be adjusted with having some tag lines. For example, "'OpenStack 2022.2': The integration of your effort" Considering all the facts, TC agreed to start the release name drop process in Gerrit and the community can add their feedback on that. Gate Health and Checks =================== This is something TC started monitoring and helping on gate health and it is going in a good direction. TC will continue doing it in every weekly meeting. We encourage every project to keep monitoring their rechecks and TC also will keep eye on those when we notice a large number of rechecks without comment. * Infra resource checks: The next thing we checked was if there are enough infra resources we have to have the smooth development of OpenStack in the Zed cycle. Clark and fungi gave updates on those and we are all in a good position at least not in a panic situation. But to monitor the required infra resources correctly, TC will work on listing the required and good-to-have services we need for OpenStack development. That way we will be able to judge the infra resource situation in a better way. * ELK service: The new dashboard for ELK service is ready to use, you can find the dashboard and credential information in this review[12]. We encourage community members to start using it and provide feedback. Accordingly, Clark will plan to stop the older ELK servers in a month or so. Thanks dpawlik for working on it. * nested-virt capable instances for testing We discussed it and they are available and can be requested from the job definition but there is always a risk of a slow job and timing failure and it is preferred to use those in the project gate only and not in the integrated/cross-project gate, Testing strategy: ============= * Direction on the lower constraints As lower constraints are not well tested and always causing issues in upstream CI, we are discussing it again to find some permanent solution. We discussed both cases 1. keeping lower bound in requirements.txt files and 2. lower-constraints.txt file and its testing. We agree to keep the 1st one but drop the 2nd one completely. Below is the agreement and action items: ** AGREE/ACTION ITEM: *** Write up how downstream distro can test their constraint file with OpenStack upstream. *** Keep the lower bound in requirements.txt but add a line saying that they are the best effort but not tested. If they are wrong then file a bug or fix it. *** Drop the lower-constraints.txt file, l-c tox env and its testing on master as well as on all stable branches. TC will add the resolution and communicate that on ML too. * Release specific job template for testing runtime: As brought up in ML[13], release-specific template does not actually work for independent releases model repo where the OpenStack bot does not update the template. Stephen added a new generic template to use in such repo. But if we see these release-specific templates are adding an extra step to update in every repo on a new release. Having a generic template and handling the python version jobs with branch variant[14] will work fine. But the generic template will move all the projects to new testing runtime at the same time from a central place. We agree to do it but with proper communication to all the projects and give some window to test/fix them before we switch to new testing versions. * Performance testing/monitoring Performance testing is good to do but as per our current CI resources, it is very difficult. We discussed few ideas where we can keep eyes on the performance aspect: ** At the start, we can monitor the memory footprint via performance stats in CI jobs ** Before and after DB query counting (how does this patch affect the number of DB queries) ** For API performance, we can monitor all the API requests via a single behind tls proxy gateway and collect the stats. * When to remove the deprecated devstack-gate? We agree to remove it once stable/wallaby is EM and will update the same in README file also with the expected date of stable/wallaby to be EM (2022-10-14). Improvement in project governance (continue from Yoga PTG....) ================================================ This is regarding how we can better keep eyes on the less or no active projects and detect them earlier in the cycle to same the release, infra resources. In the Yoga release, we faced the issue of a few projects being broken during the last date of the final release. We discussed it in the last PTG and agreed to start the 'tech-preview' idea. To define what can be entry and exit criteria for any project to be in 'tech-preview', we need input from the release team on stopping the auto release of projects or so. The release team was busy in their PTG at the same time we had this discussion so I will continue the discussion in TC weekly meetings. Current state of translations in OpenStack ================================ Ianychoi and Seongsoocho attended this session and gave us a detailed picture of the translation work, what is the current state and what all work is required to do including migration from Zanata to weblate. The main issue here is we need more people helping in this work. We also asked who uses those translations and they should come up to help. As the next step, we agreed to add a new question to the user survey ("Do you use i18n translations in your deployments? If yes please tell us which languages you use") and get some stats about translation usage. Meanwhile, Ian and seongsoocho team will continue maintaining. Thanks to Ian and Seongsoocho for their best effort to maintain it. Cross community sessions with the k8s steering committee team: ================================================= k8s steering committee members (Paris, Dims, Bob, and Tim) joined the OpenStack Technical Committee in PTG. We discussed the various topics about Legal support/coverage for contributors, especially in the security disclosure process and export control. We asked if k8s also have the same level of language translation support in code/doc as that we have in OpenStack and they have only for the documentation which is also if anyone proposes to do. Then we discussed the long-term sustainability efforts, especially for the experience contributors who can take higher responsibility as well as train the new contributors. This is an issue in both communities and none of us have any solution to this. In the last, we discussed how k8s recognize the contributor's good work. In k8s along with appreciating on slack, ML, they issue the coupon and badges from the CNCF foundation. TC Zed Activities checks and planning ============================= This is the last hour of the PTG and we started with the yoga cycle retrospective. * Yoga Retrospective We are doing good in gate health monitoring as well doing more technical work. On the improvement side, we need to be faster at making the decision on things that are in discussion for long period instead of keeping them open. * Pop Up Team Check In After checking with the status and need of both active popup teams, we decided to continue with both in Zed cycle. * TC weekly Meeting time check We will keep the current time until daylight saving time changes again. Also, we will continue the video call once a month. * TC liaison continue or drop? As we have improved the interaction with the project with the weekly meetings as well as in PTG sessions (TC+Leaders interaction session), we agreed to drop the TC liaisons completely. * I will prepare the Zed cycle TC Tracker (activities we will do in Zed cycle) * Next week's TC meeting is cancelled and we will resume meeting from 21st April onwards. That is all from PTG, thanks for reading it and stay safe! [1] https://docs.openstack.org/project-team-guide/technical-guides/unified-limi… [2] https://review.opendev.org/c/openstack/governance/+/816387 [3] https://review.opendev.org/c/openstack/governance/+/835102 [4] https://docs.openstack.org/project-team-guide/spread-the-word.html [5] https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-te… [6] https://review.opendev.org/c/openstack/governance/+/836888 [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.h… [8] https://etherpad.opendev.org/p/qa-zed-ptg-fips [9] https://etherpad.opendev.org/p/zed-ptg-fips-goal [10] https://docs.openstack.org/project-team-guide/deprecation.html [11] https://review.opendev.org/c/openstack/governance/+/829563 [12] https://review.opendev.org/c/openstack/governance-sigs/+/835838 [13] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027676.ht… [14] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833892

1 0

[release] Release countdown for week R-25, Apr 11 - 15
by Előd Illés 08 Apr '22

08 Apr '22

Hi, Welcome back to the release countdown emails! These will be sent at major points in the Zeddevelopment cycle, which should conclude with a final release on October 5th, 2022. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the Zeddevelopment cycle, assessing Zedcommunity goals and approving Zedspecs. General Information ------------------- Zed is a 27 weeks long development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/ <https://releases.openstack.org/zed/schedule.html>zed <https://releases.openstack.org/zed/schedule.html>/schedule.html <https://releases.openstack.org/zed/schedule.html> By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Yogarelease are continued in Zedwith a similar release model. Upcoming Deadlines & Dates -------------------------- Zed-1 milestone: May 19th, 2022 OpenInfra Summit: June 7-9, 2022 (Berlin) Előd Illés irc: elodilles

1 0

I sent e-mail to this mailing list but got reply from support@paribet.ru! Why!?!???
by 박경원 08 Apr '22

08 Apr '22

2 1

[Openstack][nova] server groups
by Ignazio Cassano 08 Apr '22

08 Apr '22

Hello, we noted that instances can be inserted in server groups only at instance creation step but we need to insert in a server group some old instances. We tried to modify database nova_api server group tables but we noted that we must modify spec in request_specs table . For us is not clear how to modify the spec value. We tried to investigate looking at instances inserted in a server group at creation step and we got issues in instance live migration. Please, anyone could provide any utility to do it or any template ? Thanks Ignazio

2 8

[Question] Do I must separate management network and overlay network?
by 박경원 08 Apr '22

08 Apr '22

3 2

[stable][horizon] add vishalmanchanda and tmazur to horizon-stable-core
by Akihiro Motoki 07 Apr '22

07 Apr '22

Hi, To horizon team, During the horizon PTG, we visit our stable branch reviewers. We (all existing core reviewers) agree to add vishalmanchanda and tmazur to the horizon stable core team. We believe they are familiar with the stable policy. Welcome! We also agreed to drop David Lyle from the horizon stable core as he is no longer active in horizon for long. Thanks David for your contributions so far! To stable-maint-core team, Could you apply the following changes to horizon-stable-main group in the Gerrit? Additions: manchandavishal143(a)gmail.com, t.v.ovtchinnikova(a)gmail.com Removal: dklyle0(a)gmail.com Thanks, Akihiro Motoki (irc: amotoki)

4 3

Re: [neutron] exposing ip address of external Network from
by A Monster 07 Apr '22

07 Apr '22

When I attach an interface to an external network, openstack gives an ip address of 192.168.10.13 to the instance, Inside the instance, I can see a new network interface, but it doesn't get an ip address automatically, and when I configure it to have 192.169.10.13 manually, I still cannot ping the other ips on this network, and I cannot ping 192.168.10.13 from the outside I think it's not feasible to attach instances to external networks.

2 1

[tacker] Cancel PTG Day4 on 8th Apr.
by TAKAHASHI TOSHIAKI(高橋　敏明) 07 Apr '22

07 Apr '22

Hi, We will cancel Tacker PTG Day4 on 8th April because all topics have been discussed and completed. Regards, Toshiaki

2 1

[glance] Outreachy 2022
by Anurag Singh Rajawat 07 Apr '22

07 Apr '22

Dear glance team, I'd setup glance, glance-store and glance-client on my local setup, but some tests for glance were failing, also is there any good first issues so that I can understand the project more clearly? I also asked about it in IRC but doesn't got response. Thanks Sincerely Anurag

2 1

[glance] Zed PTG schedule
by Abhishek Kekane 07 Apr '22

07 Apr '22

Hello All, Greetings!!! Zed PTG is going to start next week and if you haven't already registered, please do so as soon as possible [1]. I have created an etherpad [2] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots. We also have one slot open on Wednesday and Friday is kept reserved for any unplanned discussions. So please feel free to add your topics if you still haven't added yet. As a reminder, these are the time slots for our discussion. Tuesday 5 April 2022 1400 UTC to 1700 UTC Wednesday 6 April 2022 1400 UTC to 1700 UTC Thursday 7 April 2022 1400 UTC to 1700 UTC Friday 8 April 2022 1400 UTC to 1700 UTC NOTE: At the moment we don't have any sessions scheduled on Friday, if there are any last moment request(s)/topic(s) we will discuss them on Friday else we will conclude our PTG on Thursday 7th April. We will be using bluejeans for our discussion, kindly try to use it once before the actual discussion. The meeting URL is mentioned in etherpad [2] and will be the same throughout the PTG. [1] https://openinfra-ptg.eventbrite.com/ [2] https://etherpad.opendev.org/p/zed-glance-ptg Thank you, Abhishek

2 2

OPS Meetup Call for Topics
by Amy Marrich 07 Apr '22

07 Apr '22

During our PTG session, we started the process of gathering potential topics for the OPS Meetup to be held in Berlin on June 10. If you are interested in attending the event ,please add any topics you wish to discuss to the etherpad[0]. Deadline for adding new topics is April 30, so we can open for session voting in early May. Registration will be available shortly. Thanks, Amy 0 - https://etherpad.opendev.org/p/april2022-ptg-openstack-ops

1 0