October 2023 - openstack-discuss - lists.openstack.org

[cinder] 2024.1 (Caracal) PTG Summary
by Rajat Dhasmana 31 Oct '23

31 Oct '23

Hello, Please find the summary of 2024.1 (Caracal) PTG in the wiki page[1]. It includes summary and action items for each topic. More details can be found in the PTG etherpad[2]. I would recommend everyone to please look for the action items assigned to you to plan it according to the cycle deadlines. [1] https://wiki.openstack.org/wiki/CinderCaracalPTGSummary [2] https://etherpad.opendev.org/p/caracal-ptg-cinder Thanks Rajat Dhasmana

1 0

Green threads
by Gk Gk 31 Oct '23

31 Oct '23

Hi All, This may be out of place for this question, but I was reading about this bug https://bugs.launchpad.net/oslo.messaging/+bug/2009138, which led to this query. Do green threads in python need GIL ( global interpreter lock) for execution ? Also, can green threads take advantage of multiple processors ? If yes/no, why ?

1 0

[qa] Office hour day and time change
by Martin Kopec 31 Oct '23

31 Oct '23

Hi everyone, as discussed during the PTG [1] we are changing the date and time of our office hours. The office hour will be taking place on *Wednesdays at 17:00 UTC* [2]. The change is effective *from November 8th*. The meeting agenda is available here [3]. I'm cancelling office hours on Tuesday October 31st and November 7th. [1] https://etherpad.opendev.org/p/oct2023-ptg-qa [2] https://review.opendev.org/c/opendev/irc-meetings/+/899457 [3] https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Thanks, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 1

capacity planning question.
by KK CHN 30 Oct '23

30 Oct '23

Hi list, I am in need of an infrastructure set up for data analytics / live video stream analytics application using big data and analytics technology.. The data is basically right now stored as structured data(no video streaming) in PostgresDatabase. ( Its an emergency call handling solution, In database which stores, caller info (address, mobile number, locations co-ordinates, emergency category metadata and dispatch information regarding rescue vehicles., Rescue vehicle location update (lat, long)every 30 seconds all are stored in the Postgres Database .. Input1 : I have to do an analytics on these data( say 600 GB for the last 2 years its the size grown from initial setup).To perform an analytical application development( using python and data analytics libraries, and displaying the results and analytical predication through a dashboard application.) Query 1. How much resource in terms of compute(GPU?(CPU) cores required for this analytical application? and memory ? And any specific type of storage(in memory like redis required ? ) etc, which I have to provision for these kind of application processing. ?? any hints most welcome.. Any more input required let me know I can provide if available. Input 2 In addition to the above I have to do video analytics from bodyworn cameras by police personnel, drone surveillance Videos from any emergency sites, patrol vehicle (from a mobile tablet device over 5G )live streaming of indent locations for few minutes ( say 3 to 5 minutes live streaming for each incident. ) There are 50 drones, 500 Emergency rescue service vehicles, 300 body worn camera personnels.. and roughly 5000 incidents / emergency incidents per day happening, which needs video streaming for at least 1000 incidents for a time duration of 4 to 5 minutes live streaming. Query2. What/(how many) kind of computing resources GPUs(CPUs)? RAM, Storage solutions I have to deploy in numbers( or cores of GPUs/how many/(CPUs)? RAM ? In Memory (Redis or similar ) or any other specific data storage mechanisms ? Any hints much appreciated.. Thank in advance, Krishane

1 0

[tacker][ptg] Caracal vPTG Summary
by Yasufumi Ogawa 30 Oct '23

30 Oct '23

Hi all, We had two days session for discussing new proposals for Caracal and reamined items couldn't fixed in the previous release [1]. Here is a summary of the discussion in Tacker team. # Revise FTs Gate tests, especially for functional tests, have been getting mess because of increasing amount of codes without active maintenance. For the issue, we have focused on reducing useless logs. And also re-design directory structure and testcase scenarios. We're going to continue the tasks and will fix it in this release. # Legacy API deprecating/obsoleting It was proposed to drop Tacker's legacy implementation in antelope, and will be completed in this release as planed. # Introducing Cilium CNI for high-performance network connectivity for VNF/CNF This proposal is for a new example app using Cilium CNI as a vRAN usecase in which VNF/CNF requires performance for network connectivity between VMs or containers. The first target is to confirm it's available to deploy with Tacker in a manner of VNF package. # Update requirements for monitoring We have introduced Prometheus for implementing FM/PM interfaces defined in ETSI-NFV standards from Yoga. This proposal is for more advanced feature than monitoring, called as observability, by using OpenTelemetry for considering future requirements. We agreed to implement an additional plugin dedicating to interwork between Otel collector and Tacker. # NFV Orchestration API v2.0 in Tacker Horizon Although many of v2 APIs in ETSI specifications have been implemented, tacker-horizon is not ready for the features. We'll update NFVO interfaces in Horizon to provide v2 features. Current legacy features are going to be dropped instead. # Improving Tacker Document As legacy implementations have been deprecated, documents are also removed. In addition, there are some other sections should be updated such as incorrect usecase guides don'twork, unmaintained operator's guides or so. # Tacker Tempest Plugin Tacker doesn't support tempest, but it's not good for considering if it leads to OpenStack vendors not including Tacker in their products, and also makes Tacker look unhealthy project. So, implement Tacker's tempest plugin and update our zuul jobs to use the plugin for. # Fix vimConnectionID in ResouceHandle In the current implementation, vimConnectionID differs from ETSI specs mistakenly. So, it's should be fixed soon and expected to be small changes. # Secure RBAC This item has been led by NEC team and development of UTs and FTs are under implemention as noted on the vPTG etherpad. However, we need to update ownership of the item for manpreetk moved to another organization. Confirm if NTT or NEC team own the item in caracal and share the result in IRC meeting. # Fix issues which were encounter in compliance test execution In next release of tacker (2024.1), NEC team proposing to make 'tacker-compliance-devstack-multinode-sol' job testing mandatory and voting after some issues occured in the test are fixed. # Maintain tosca-parser and heat-translator Assign team leaders for each projs temporarily for governance, Toshiaki Takahashi for tosca-parser and Ayumu Ueha heat-translator. Ask TC memebers anything requried to change the ownership. [1] https://etherpad.opendev.org/p/oct2023-ptg-tacker Thanks, Yasufumi

1 0

[tc] Weekly Meeting Tomorrow, Oct 31 1800 UTC in OFTC
by Jay Faulkner 30 Oct '23

30 Oct '23

Hi all, The OpenStackTechnical Committee will have our weekly meeting tomorrow, October 31, at 1800 UTC in #openstack-tc on OFTC. All are welcome to attend. The proposed agenda is below. Agenda Suggestions - Roll call - Follow up on tracked action items: https://meetings.opendev.org/meetings/tc/2023/tc.2023-10-17-18.00.html - JayF: Before next video meeting, write up a short document on pros/cons of moving TC video meetings to jitsi-meet. - Gate health check - Leaderless projects (gmann) - PTG follow-ups? - https://etherpad.opendev.org/p/tc-ptg-october-2023 - https://etherpad.opendev.org/p/tc-leaders-interaction-2024-1 - https://etherpad.opendev.org/p/oct2023-ptg-os-dbperf-crossproject - Open Discussion and Reviews Thank you, Jay Faulkner OpenStack TC Chair

1 0

[barbican] Weekly Meeting 31-10-2023 Canceled
by Grzegorz Grasza 30 Oct '23

30 Oct '23

Hi all, I'm canceling the meeting this Tuesday. I'm on a business trip this week. Thanks! / Greg

1 0

Re: Regarding Nova's inability to delete the Cinder volume for creating virtual machines (version Y)
by 无数的星球 30 Oct '23

30 Oct '23

Thank you for Gorka's reply! I have seen this document multiple times and it has not been taken seriously. Next, I will try.

1 0

Regarding Nova's inability to delete the Cinder volume for creating virtual machines (version Y)
by 无数的星球 30 Oct '23

30 Oct '23

When creating a virtual machine in the dashboard, create a volume and choose to delete the virtual machine while also deleting the volume. When deleting the virtual machine, there is no normal uninstallation of the volume and the volume is not deleted. The relevant error logs are shown in the image, but the openstack CLI can delete its volume. The specific commands are as follows. CLI： source /etc/keystone/admin-openrc.sh (Verify password file) openstack volume set --detached　191e555c-3947-4928-be46-9f09e2190877（volumeID） openstack volume delete 191e555c-3947-4928-be46-9f09e2190877（volumeID） It seems that Nova is unable to interact with the Cinder API to delete(or detached) commands, but I am not very professional. I don't know if it's a bug? Note that I have seen similar bug patch files, but they are invalid. URL:   BUG page   https://bugs.launchpad.net/nova/+bug/2016173   Page for patching files   https://review.opendev.org/c/openstack/nova/+/880399 Is not working!!!

2 1

[openstack-ansible][ptg] OpenStack-Ansible 2024.1 (Caracal) vPTG Summary
by Dmitriy Rabotyagov 30 Oct '23

30 Oct '23

Hey everyone, We had quite a productive discussion on the PTG and I will provide a summary of them below. It was divided into multiple sections, like things we need to finish for 2023.2 (Bobcat) - since OpenStack-Ansible has trailing release model we have some time to wrap things up; plans for 2024.1 (Caracal) and some things that moved out of scope until better times. You can also find original PTG with discussions here [1] Finalizing 2023.1 (Bobcat): * Documentation on using pretty endpoint names (ie identity.cloud.org instead of cloud.org:5000). For 2024.1 we will try to simplify the way of using such naming to make it more convenient for end-users. * Finalize support of RabbitMQ Quorum queues for all services [2]. With that they will be disabled by default at least for 2023.2 release and we will revise the defaults for 2024.1 * Implement openstack_resources common rolem that will handle different resources creation, like OpenStack users, projects, networks, images, aggregates, etc. It will be also used in roles like Tempest, Octavia, Trove and Magnum to create such resources, instead of each role implementing its own flow of doing that. We agreed to add a separate playbook that will allow deployers to leverage the role and run it after setup-openstack. * Debian 12 support. Most patches have landed, but we also need to reflect it's support in documentation * Review and release Skyline role. Tough discussion was about defaults and how Skyline should co-exist with Horizon. As a result we decided to deploy both options, when both are defined in the inventory (as usual), but the playbook that is run last will basically configure HAProxy backends to itself, fully neglecting other available services. So if you want to have both Skyline and Horizon running and functional - you will need to apply some overrides for that. There are also no guarantees that we will be able to merge and release the role in time, so we may end up with making it as part of OSA only for 2024.1. Scoped improvements for 2024.1 (Caracal): * Adoption of PKI role to be used with PIPE modules, that will allow the role to be pointed to any file (like encrypted with ansible-vault) or external storage that supports lookup, instead of plain text files on a deploy host. With that we will also take a look at using Hishcorp Vault as a PKI source and adding it as another driver in addition to the "standalone" one. * Natively supporting multi-AZ deployments for Neutron. At the moment for OVS/LXB you need to define some overrides to make that working, while for OVN you would need to manually execute a bunch of commands. POC patch has been already proposed [3], but it still needs some love. * Finalize support of OVN driver for Octavia. Initial patch has been proposed, but it also needs some love, despite it works in general [4] * Resume work on ProxySQL implementation as a replacement for HAProxy balancing for MariaDB deployment. That should improve load distribution between MariaDB backends. * Allow to select OS for LXC containers. At the moment we're forcing to use the host OS, while in some cases it might be preferred to use a different one, like during OS upgrades or switching the OpenStack deployment from one distro to another. * With that we are excited about incus (LXD fork) having the first release and it being packaged with traditional packages (only .deb at the moment). This opens the door for implementation of incus as a manager for LXC containers, that may simplify our flows and day2 operations significantly. * Invest some time into decreasing the runtime, both for CI/CD and for end-user deployments. * In case improvements for Quorum Queues will land to the oslo.messaging [5] - add a set of variables to roles for nicely controlling the behaviour. [1] https://etherpad.opendev.org/p/osa-caracal-ptg [2] https://review.opendev.org/q/topic:osa%252Fquorum_queues [3] https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/858271 [4] https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/868462 [5] https://review.opendev.org/q/topic:bug-2031497

1 0