- openstack-discuss - lists.openstack.org

Openstack cluster cannot create instances when 1 of 3 rabbitmq cluster node down
by Nguyễn Hữu Khôi 24 Oct '22

24 Oct '22

Description =========== I set up 3 controllers and 3 compute nodes. My system cannot work well when 1 rabbit node in cluster rabbitmq is down, cannot launch instances. It stucked at scheduling. Steps to reproduce =========== Openstack nodes point rabbit://node1:5672,node2:5672,node3:5672// * Reboot 1 of 3 rabbitmq node. * Create instances then it stucked at scheduling. Workaround =========== Point to rabbitmq VIP address. But We cannot share the load with this solution. Please give me some suggestions. Thank you very much. I did google and enabled system log's debug but I still cannot understand why. Nguyen Huu Khoi

5 9

Openstack Cinder and Nova Services cannot work when rabbitmq cluter node down
by Nguyễn Hữu Khôi 24 Oct '22

24 Oct '22

Title: Openstack cluster cannot create when 1 of 3 rabbitmq cluster node down Bug description: Description =========== I set up 3 controllers and 3 compute nodes. My system cannot work when 1 rabbit node in cluster rabbitmq is down, cannot create volume or launch instance. It stucked at creating and scheduling respectively. Steps to reproduce =========== Openstack nodes point rabbit://node1:5672,node2:5672,node3:5672// * Reboot 1 of 3 rabbitmq node. * Create volume or launch instance then it stucked at creating and scheduling respectively. Workaround =========== I need reboot cinder and nova services to create volume and launch instance . More Info: I see in cinder_scheduler, it looks like cinder cannot change to another rabbitmq node. I hope we have ideas for that.. 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task Traceback (most recent call last): 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 441, in get 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task return self._queues[msg_id].get(block=True, timeout=timeout) 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/queue.py", line 322, in get 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task return waiter.wait() 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/queue.py", line 141, in wait 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task return get_hub().switch() 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/hubs/hub.py", line 313, in switch2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task return self.greenlet.switch() 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task _queue.Empty 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task During handling of the above exception, another exception occurred: 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task Traceback (most recent call last): 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_service/periodic_task.py", line 216, in run_periodic_tasks 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task task(self, context) 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/nova/compute/manager.py", line 9716, in _sync_power_states 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task db_instances = objects.InstanceList.get_by_host(context, self.host, 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_versionedobjects/base.py", line 175, in wrapper 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task result = cls.indirection_api.object_class_action_versions( 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/nova/conductor/rpcapi.py", line 240, in object_class_action_versions 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task return cctxt.call(context, 'object_class_action_versions', 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_messaging/rpc/client.py", line 189, in call 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task result = self.transport._send( 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_messaging/transport.py", line 123, in _send 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task return self._driver.send(target, ctxt, message, 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 689, in send 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task return self._send(target, ctxt, message, wait_for_reply, timeout, 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 678, in _send 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task result = self._waiter.wait(msg_id, timeout, 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 567, in wait 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task message = self.waiters.get(msg_id, timeout=timeout) 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 443, in get 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task raise oslo_messaging.MessagingTimeout( 2022-10-24 14:23:01.945 7 ERROR oslo_service.periodic_task oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID c8a676a9709242908dcff97046d7976d Nguyen Huu Khoi

1 0

[large-scale][oslo.messaging] RPC workers and db connection
by Arnaud Morin 24 Oct '22

24 Oct '22

Hey all, TLDR: How can I fine tune the number of DB connection on OpenStack services? Long story, with some inline questions: I am trying to figure out the maximum number of db connection we should allow on our db cluster. For this short speech, I will use neutron RPC as example service, but I think nova is acting similar. So, to do so, I identified few parameters that I can tweak: rpc_workers [1] max_pool_size [2] max_overflow [3] executor_thread_pool_size [4] rpc_worker default is half CPU threads available (result of nproc) max_pool_size default is 5 max_overflow default is 50 executor_thread_pool_size is 64 Now imagine I have a server with 40 cores, So rpc_worker will be 20. Each worker will have a DB pool with 5+50 connections available. Each worker will use up to 64 "green" thread. The theorical max connection that I should set on my database is then: rpc_workers*(max_pool_size+max_overflow) = 20*(5+50) = 1100 Q1: am I right here? I have the feeling that this is huge. Now, let's assume each thread is consuming 1 connection from the DB pool. Under heavy load, I am affraid that the 64 threads could exceed the number of max_pool_size+max_overflow. Also, I noticed that some green threads were consuming more than 1 connection from the pool, so I can reach the max even sooner! Another thing, I notice that I have 21 RPC workers, not 20. Is it normal? [1] https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAUL… [2] https://docs.openstack.org/neutron/latest/configuration/neutron.html#databa… [3] https://docs.openstack.org/neutron/latest/configuration/neutron.html#databa… [4] https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAUL… Cheers, Arnaud.

3 4

RE: RE: [yoga][cinder] Cinder NFS backend: Compute service cannot access volume file (UID/GID problem)
by Felix Hüttner 24 Oct '22

24 Oct '22

Sorry, no idea about that, for us the group also has write permissions -- Felix Huettner From: 박경원 <park0kyung0won(a)dgist.ac.kr> Sent: Monday, October 24, 2022 9:24 AM To: Felix Hüttner <felix.huettner(a)mail.schwarz>; openstack-discuss(a)lists.openstack.org Subject: RE: RE: [yoga][cinder] Cinder NFS backend: Compute service cannot access volume file (UID/GID problem) Hello Felix Thank you very much for kind reply Do I also need to change permission setting of volume file in /var/lib/nova/mnt/... ? By default its: drwxr-x--- 2 64061 64061 11 Oct 24 04:19 99c4f7e8b15983b65e20cb7d37db899f group has only read and execute permission, no write permission ---------- 원본 메일 ---------- 보낸사람: "Felix Hüttner" <felix.huettner(a)mail.schwarz<mailto:felix.huettner@mail.schwarz>> 받는사람: "park0kyung0won(a)dgist.ac.kr<mailto:park0kyung0won@dgist.ac.kr>" <park0kyung0won(a)dgist.ac.kr<mailto:park0kyung0won@dgist.ac.kr>>, "openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org>" <openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org>> 날짜: 2022-10-24 (월) 16:12:48 제목: RE: [yoga][cinder] Cinder NFS backend: Compute service cannot access volume file (UID/GID problem) Hi, we are solving this issue for us by creating a “cinder” group on all hypervisors with the same gid (64061 in your case). Then we add the nova user to the cinder group and we are fine afterwards. You might need set “dynamic_ownership = 0" In your libvirt qemu.conf -- Felix Huettner From: 박경원 <park0kyung0won(a)dgist.ac.kr<mailto:park0kyung0won@dgist.ac.kr>> Sent: Monday, October 24, 2022 7:21 AM To: openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org> Subject: [yoga][cinder] Cinder NFS backend: Compute service cannot access volume file (UID/GID problem) Hi I'm trying to setup cinder-volume service with NFS backend When I create a new VM instance with a volume from web UI, cinder-volume service on storage node creates volume file just fine But I get the following error on compute node and instance fails to spawn. 2022-10-24 02:14:25.347 402789 ERROR nova.compute.manager [req-47ec9fb1-9daa-4c24-8673-538797a217cc 8769cfaf608349bd9fbb36f92b188fe3 e1e8e8397cde49899b00d09dec76b29e - default default] [instance: 5acb1dc3-0685-4980-977b-b6dfff6dfb45] Instance failed to spawn: libvirt.libvirtError: internal error: process exited while connecting to monitor: 2022-10-24T02:14:24.819644Z qemu-system-x86_64: -blockdev {"driver":"file","filename":"/var/lib/nova/mnt/99c4f7e8b15983b65e20cb7d37db899f/volume-8f478992-dde3-4c20-9005-61cd34eacf30","aio":"native","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}: Could not open '/var/lib/nova/mnt/99c4f7e8b15983b65e20cb7d37db899f/volume-8f478992-dde3-4c20-9005-61cd34eacf30': Permission denied I've added appropriate configs to apparmor profile. (Using Ubuntu 22.04) Apparmor isn't blocking this access. While the instance is spawning, I've checked ownership of the volume file on compute node: root@compute-node:/var/lib/nova/mnt$ ls -al total 17 drwxr-xr-x 3 nova nova 4096 Oct 24 04:19 . drwxr-xr-x 12 nova nova 4096 Oct 24 02:14 .. drwxr-x--- 2 64061 64061 11 Oct 24 04:19 99c4f7e8b15983b65e20cb7d37db899f It seems like cinder user on storage node creates volume file with UID/GID of 64061 (cinder user's UID/GID) But nova user on compute node has UID/GID of 64060, therefore cannot open volume file(/var/lib/nova/mnt/99c4f7e8b15983b65e20cb7d37db899f/volume-8f478992-dde3-4c20-9005-61cd34eacf30) Should I manually set the UID/GID of nova user on compute node to 64061, so both nova user on compute node and cinder user on storage node would have the same UID/GID? Feels like this duct taping isn't a proper solution. Did I miss something? Thank you Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.daten…>. Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.

1 0

RE: RE: [yoga][cinder] Cinder NFS backend: Compute service cannot access volume file (UID/GID problem)
by 박경원 24 Oct '22

24 Oct '22

1 0

[yoga][cinder] Cinder NFS backend: Compute service cannot access volume file (UID/GID problem)
by 박경원 24 Oct '22

24 Oct '22

2 1

[largescale-sig] No meeting this week
by Thierry Carrez 23 Oct '22

23 Oct '22

Hi everyone, With the PTG just over, the Large Scale SIG will not be meeting this week. Our next regular IRC meeting will be November 9, at 1500utc on #openstack-operators on OFTC. Feel free to add topics to the agenda: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 0

single Network interface
by Parsa Aminian 23 Oct '22

23 Oct '22

Hello I use kolla ansible wallaby version . my compute node has only one port . is it possible to use this server ? as I know openstack compute need 2 port one for management and other for external user network . Im using provider_networks and it seems neutron_external_interface could not be the same as network_interface because openvswitch need to create br-ex bridge on separate port is there any solution that i can config my compute with 1 port ?

7 9

[tc][all][policy][rbac] RBAC 2023.1 Antelope cycle Virtual PTG discussions summary
by Ghanshyam Mann 22 Oct '22

22 Oct '22

Hello Everyone, Last week, I tried to attend all the RBAC-related sessions on various projects. We mainly discussed the next steps on RBAC and implementing the project personas if not yet done. I captured the summary and outcome of the discussions of those projects in the below etherpad: Look for the section: "RBAC/Policy 2023.1 Antelope PTG summary". If I have missed any project discussion, please add it to the etherpad. - https://etherpad.opendev.org/p/rbac-goal-tracking One of the big outcomes, we agreed on all the projects (implemented phase-1) to enable the scope checks and new defaults by default. But before doing that, we need to test the new defaults and scope in Tempest (tempest plugin) integrated gate. I have started working on the job enabling the scope and new defaults[1]. [1] https://review.opendev.org/c/openstack/tempest/+/614484 -gmann

1 0

[tc][all][ Technical Committee 2023.1 Antelope cycle Virtual PTG discussions summary
by Ghanshyam Mann 22 Oct '22

22 Oct '22

Hello Everyone, I am summarizing the Technical Committee discussion that happened in the 2023.1 Antelope cycle PTG last week. Also, in case anyone wanted to search for all the projects etherpad later after ptgbot cleans them, I have added those to this wiki[1] Attendance: ========= * ~30 on Monday, ~25 on Thursday, ~20 on Friday Improvement in project governance: =========================== We continued the discussion from Monday and discussed a few high-level criteria which can be the potential criteria to monitor inactive projects. Along with contributors, event, and meeting occurrence is one of them but not all. JayF will be working on this to list the exact criteria/things TC can monitor to find and work on help inactive projects. User Survey: ========== * 2021 user Survey result analysis: We started with the pending review of the 2021 survey analysis[2]. There wasn't 2020 analysis so, the comparison was done using 2019. Overall, the trends in the survey were positive. We discussed adding the question about UI participants especially if users need new features to be implemented in UI then what prevents them to help and contribute? * 2022 User Survey result: knikolla and I will be working on the analysis of this survey result. jungleboyj will help on documenting the process and tips to analyze the survey xls which is not an easy task. Thanks to jungleboyj for doing the survey analysis and helping with the 2022 survey too. * 2023 User Survey question review: While doing the 2021 survey analysis, we discussed the below changes in 2023 survey. ** Remove "Other ways users participate:" ** Add: 1. how users are consuming OS. From pypi packages? From RHOSP? etc. 2. How are users interacting with OpenStack? Through Horizon? CLI? Skyline? An internally developed tool? etc. 3. Adding a sub-question about UI development help in "To which projects does your organization contribute maintenance resources such as patches for bugs and reviews on master or stable branches?" 4. Asking about what all OSS/software/services are used in your OpenStack provisioned cloud/resource. * Action: As the next step, we will work on the exact wording for the above questions and send it to Allison before the end of Oct month. Next step for OSC work ================== We started the discussion on sdk/osc should continue supporting the old interfaces even if we are not able to test them properly. Anyone running a very old cloud should be able to use the sdk/osc latest. We agree and Artem mentioned being more careful about removing the things. Next, we discussed where we stand on OSC work and direction from the project side and good progress from nova, neutron, and manila (might be a few more) but at the same time, many other projects need work on fixing the feature gaps. Glance is also in agreement to work towards OSC. There was a question on when and how we should work towards deprecating/removing the project's python client. The best way is to start implementing the new features in OSC and try their best to fill the old feature gap. Based on the current state, we agree to start this work as one of the community-wide and Artem volunteers to help here. * Action: ** Propose this as a community-wide goal "focus on fixing the feature gaps in osc not to remove the pythonclient which can be another goal" ** Look at devstack's use of OSC to see if we can enable token caching and perhaps use a smaller venv for performance Consistent and Secure Default RBAC ============================ As a good amount of the services are ready with the project personas, We will be testing them in the integrated gate (tempest and tempest plugins jobs), and based on the results we will enable the scope to enforce and new defaults enforce by default in this cycle. Also, services can start implementing phase 2 of the goal which is the service-to-service role. On Horizon question of moving to new defaults. because of the explicit policy files (with defaults) on the horizon side, the operator will not be able to just switch the flag until they change the policy file. For a better migration path and getting one more cycle to test the new defaults by default on the service side, it is better for Horizon to move to new defaults in the next cycle. FIPs goal ======= Ade lee provided the current status[3] of the goal which is good progress. There is work going on having the ubuntu based FIPs enabled job[4] and that will be to achieve the goal of having of voting job in the check/gate pipeline. Migrate CI/CD jobs to Ubuntu 22.04 (Jammy Jellyfish) ========================================= Projects are testing the jobs on Jammy but not all[5], we encourage the projects to start testing your project jobs before the deadline which is m-1 (Nov 18), and fix the issues if there are any. One known issue is Ceph job failing on Jammy as there aren't jammy upstream packages. There are packages in UCA and Ubuntu proper that could be used instead. The community-wide goal process in a world with few contributors =================================================== This topic is on how we can improve the community-wide goal progress and productivity but at the same time reduce the overhead on projects. Also, to highlight that the Champion of a goal is not required to do all the work and it is up to the champion. knikolla will work on the goal documentation to try goal overhead minimum. We will be more careful with goal selection to make sure if any work can be done without a community-wide goal then we should proceed that way. * Action: knikolla: see opportunities for rewording the community goal document. mention: striving to keep goals to a minimum to reduce overhead on teams and try to build consensus first. Pop-Up Team checks ================ We have two active popup teams, 1. Image Encryption 2. Policy(RBAC). Both have pending work to finish so will continue in this cycle also. Support policy for 32-bit platforms support ================================= Zigo is testing the OpenStack on 32-bit and filed bugs[6]. As we do not test it in the upstream CI/CD, we will not be committing to its support. But it is completely ok to fix the bug or add a skip in tests. Thanks to zigo for testing and reporting the bugs. Fixing docs build issues with recent Sphinx ================================ Sphinx is capped at 4.5.0 in upper constraints for a long time and whether we should move our doc to 6.0 or not is the question. Moving to 6.0 needs more work in openstackdocstheme. Until we have someone fixing things, it is ok to continue on Sphinx 4.5.0. Election retrospective: ================= We had a good amount of discussion on elections and many ideas to improve them in the future. Also by discussing the k8s election process with k8s steering committee members. We also discussed TC Chair election process to record the nomination in a better way. This is still not concluded and we continue the discussion in TC. Overall it was a productive discussion and we came up with below action items: *Action: 1. Extend the nomination and voting period to two weeks and also communicate the election well in advance. 2. Along with existing projects/SIG repos, add a few more related repos (governance, etc) in election tooling to count the electorate. 3. Add in the election process: call for AC on openstack-discuss or any other ML before the deadline. 4. Appoint a TC liaison as a point of contact to track the election dates more carefully and ICAL for election tasks will be a good idea to send/add. 5. Update the TC charter to mention the election period, and deadline explicitly. Cross-community sessions with k8s steering committee team: =============================================== We invited Kubernetes Steering Committee members to TC sessions. Tim and Christoph joined the sessions. This is a great way to collaborate between two communities. Following the introduction from both sides, we discussed various topics and share the process, challenges, and feedback from both sides. The election process, contributor recruiting, and how to engage them as long-term contributors. Also having part-time or non-corporate contributors is still a challenge for both communities. We also discussed the operator engagement challenges OpenStack is facing. Kubernetes operator thing is a bit complicated and they have app dev, cluster, app, and infra operator. Similar to OpenInfra foundation to the OpenStack community, CNCF foundation plays an important role for them to connect the operator with the community as much as possible. Discuss and clarify the supported upgrade-path testing in PTI: =============================================== To provide a better upgrade path, we decided to test the old distro version also whenever we will bump the distro version in our CI/CD. Below are details of the upgrade testing we will be following: Agree: * Supporting two distro versions when we bump the new distro version in any release: (this is only for the release bump of the distro and after that, we can go back to a single distro version testing) ** Run single tempest job in project gate on old distro version, not all jobs ** Add the previous python version unit test job in the new release testing template. * For non-SLURP releases, we will try not to change the testing runtime unless it is very much required due to the EOL of versions, we are using in testing. * In case the project has to add some feature that needs a new version of deps which is not supported in the old distro version then they need to be explicit about it and communicate in a better way. * Action: I will document the above in PTI. Guidelines for using the OpenStack release version/name and project version in 1. releasenotes 2. Documentation ===================================================================================== In Zed cycle, TC passed a resolution[7] and also prepared the guidelines[8] on using the release number as a primary identifier. During nova PTG, there was a question on what is the recommendation for using OpenStack version and package version (say Nova 27.0.0) in project documentation, releasenotes etc. After discussing the multiple options listed in etherpad we agree to go for the below: * OpenStack <release version> (<project> <project vesion>) Example: OpenStack 2023.1 (Nova 27.0.0) I will add this to the release identifier page[8] so that all projects can use it consistently. Discussion on projects (like neutron, ceilometer ) in Upper Constraints: ===================================================== Having projects in u-c makes it difficult for users to have a consistent deployment of those services. But we do not recommend using the u-c in production and it can be explicitly mentioned in the requirement and project-team-guide document. * Action: tonyb to document the upper constraints usage expectation (especially for production usage) in the requirement document as well as in project-team-guide[9]. Zed Retrospective: ============== In the end, we discussed the Zed cycle retrospective. * What went well? ** Good amount of work in the zed cycle[10] ** New TC members ** Good participation in meetings especially video call ** TC & Community Engagement (leaders interaction) improving *** i18 SIG team having there helped to proceed with i18 SIG work One thing to improve next time is to explicitly call out the team/members with a courtesy ping for future PTG if any related discussion. We do send the agenda on ML in advance but no harm in ping also. Meeting time check: =============== TC weekly Video calls are more productive compared to text meetings and we will do two video calls in a month. We will also start a poll to select the meeting time. 2023.1 cycle TC Tracker ================== I prepared the TC tracker for 2023.1 and listed all the actionable working items that came up during the PTG discussion. This is helpful for tracking the working items. - https://etherpad.opendev.org/p/tc-2023.1-tracker Thank you for reading the summary or I will say detailed summary :), have a nice weekend everyone. [1] https://wiki.openstack.org/wiki/PTG/2023.1/Etherpads [2] https://review.opendev.org/c/openstack/governance/+/836888 [3] https://etherpad.opendev.org/p/fips_goal_status [4] https://review.opendev.org/c/openstack/project-config/+/861457/ [5] https://etherpad.opendev.org/p/migrate-to-jammy [6] https://bugs.launchpad.net/glance-store/+bug/1991406 [7] https://governance.openstack.org/tc/resolutions/20220524-release-identifica… [8] https://governance.openstack.org/tc/reference/release-naming.html [9] https://docs.openstack.org/project-team-guide/dependency-management.html [10] https://etherpad.opendev.org/p/tc-zed-tracker -gmann

1 0