- openstack-discuss - lists.openstack.org

Zun connector for persistent shared files system Manila
by Vaibhav 14 Nov '22

14 Nov '22

Hi, I am using zun for running containers and managing them. I deployed cinder also persistent storage. and it is working fine. I want to mount my Manila shares to be mounted on containers managed by Zun. I can see a Fuxi project and driver for this but it is discontinued now. With Cinder only one container can use the storage volume at a time. If I want to have a shared file system to be mounted on multiple containers simultaneously, it is not possible with cinder. Is there any alternative to Fuxi. is there any other mechanism to use docker Volume support for NFS as shown in the link below? https://docs.docker.com/storage/volumes/ Please advise and give a suggestion. Regards, Vaibhav

2 4

[all][tc] What's happening in Technical Committee: summary 2022 Nov 11: Reading: 5 min
by Ghanshyam Mann 12 Nov '22

12 Nov '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * * We had this week's meeting on Nov 09. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2022/tc.2022-11-09-16.00.log.html * Next TC weekly meeting will be on Nov 16 Wed at 16:00 UTC, please make note of the new day/time for TC meetings. Feel free to add the topic to the agenda[1] by Nov 15. 2. What we completed this week: ========================= * None for this week. 3. Activities In progress: ================== TC Tracker for 2023.1 cycle --------------------------------- * Current cycle working items and their progress are present in 2023.1 tracker etherpad[2]. Open Reviews ----------------- * Ten open reviews for ongoing activities[3]. 2023.1 cycle testing runtime changes (additional testing) ------------------------------------------------------------------- We discussed it in PTG and mainly for smooth upgrade what best we can do/test in testing runtime when we bump the distro version. You might have read my PTG summary email about the agreement on this. Accordingly, I have updated the patch[4] which includes the change in the 2023.1 cycle testing runtime: 1. Keep supporting Ubuntu 20.04: at least one integrated job running at the project gate. 2. Minimum python version will be py3.8 (default in Ubuntu 20.04) This is early heads-up on this and you can review it if any feedback otherwise once it is merged, I will send these updates in a separate email also. TC to stop using storyboard? ---------------------------------- TC has a governance project in the storyboard and it was confusing for many of us. It was used to track the tasks mainly the community-wide goals. But we have not used it for a couple of years and etherpad for TC tracker works very well since Xena cycle[5]. Most TC members are ok to remove the TC storyboard project (after cleaning all story/tasks which I already started) but as we did not have all the TC members in this week's meeting, we will do a formal vote on this in the next TC meeting. Renovate translation SIG i18 ---------------------------------- * rosmaita is coordinating with Weblate and updated that hosting OpenStack translation on Weblate is not free (they can give a 50% discount though). This is a difficult situation now and rosmaita will continue his research and user survey if we can get help from users using the translation. TC Weekly meeting new day and time -------------------------------------------- I am mentioning this again in case anyone missed it. The TC weekly meeting new time is every Wed at 16:00 UTC. TC Video meeting discussion ---------------------------------- JayF resolution patch to move TC all weekly meetings format to IRC is under review[6]. TC chair nomination & election process ----------------------------------------------- I have updated the patch to have the dir structure in the chair nomination. The current two options are up for the review[7][8]. Project updates ------------------- * Add zookeeper role under OpenStack-Ansible governance[9] * Add Skyline repository for OpenStack-Ansible[10] * Add the cinder-infinidat charm to Openstack charms[11] * Add the infinidat-tools subordinate charm to OpenStack charms[12] * Add the manila-infinidat charm to Openstack charms[13] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [15] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. See you all next week in PTG! [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://etherpad.opendev.org/p/tc-zed-tracker [3] https://review.opendev.org/q/projects:openstack/governance+status:open [4] https://review.opendev.org/c/openstack/governance/+/860599 [5] https://wiki.openstack.org/wiki/Technical_Committee_Tracker [6] https://review.opendev.org/c/openstack/governance/+/863685 [7] https://review.opendev.org/c/openstack/governance/+/862772 [8] https://review.opendev.org/c/openstack/governance/+/862774 [9] https://review.opendev.org/c/openstack/governance/+/863161 [10] https://review.opendev.org/c/openstack/governance/+/863166 [11] https://review.opendev.org/c/openstack/governance/+/863958 [12] https://review.opendev.org/c/openstack/governance/+/864067 [13] https://review.opendev.org/c/openstack/governance/+/864068 [14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[release] Release countdown for week R-18, Nov 14 - 18
by Elõd Illés 11 Nov '22

11 Nov '22

Development Focus ----------------- The Antelope-1 milestone is next week, on November 17th, 2022! Project team plans for the 2023.1 Antelope cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Zed release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Antelope-1 milestone: November 17th, 2022 Final 2023.1 Antelope release: March 22nd, 2023 Előd Illés irc: elodilles

1 0

[neutron][release] Proposing to EOL Queens, Rocky and Stein (all Neutron related projects)
by Rodolfo Alonso Hernandez 11 Nov '22

11 Nov '22

Hello: In the last PTG, the Neutron team has decided [1] to move the stable branches Queens, Rocky and Stein to EOL (end-of-life) status. According to the steps to achieve this [2], we need first to announce it. That will affect all Neutron related projects. The patch to mark these branches as EOL will be pushed in one week. If you have any inconvenience, please let me know in this mail chain or in IRC (ralonsoh, #openstack-neutron channel). You can also contact any Neutron core reviewer in the IRC channel. Regards. [1]https://etherpad.opendev.org/p/neutron-antelope-ptg#L131 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

1 1

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 11 Nov '22

11 Nov '22

Hello Neutrinos: Due to the lack of agenda, today's meeting is cancelled. Have a nice weekend!

1 0

[kolla-ansible]Network Problem after server reboot
by Franck VEDEL 11 Nov '22

11 Nov '22

Hello, after a restart of my cluster (and some problems...), I have one last problem with the VMs already present (before the restart). They all work fine….They all work, console access OK, network topology ok… But they can no longer communicate on the network, they do not obtain IP addresses by dhcp. Yet everything seems to be working. If I detach the interface, I create a new interface, it doesn't work. I cannot reach the routers. I cannot communicate with an instance on the same network. On the other hand, if I create a new instance, no problem, it works and can join the other instances and its router. Is there a way to fix this? The problem is where? in the database? Thank you in advance for your help. Franck VEDEL

2 2

Fwd: Need assistance
by Gk Gk 11 Nov '22

11 Nov '22

---------- Forwarded message --------- From: Gk Gk <ygk.kmr(a)gmail.com> Date: Thu, Nov 10, 2022 at 7:01 PM Subject: Re: Need assistance To: <neil(a)shrug.pw> The file which is being picked by uwsgi is '../../nova-20.2.1/lib/python3.6/site-packages/nova/api/openstack/compute/wsgi.py' . But I dont see how this file is being called. Which program loads this file ? Can someone help me here ? Disregard the abive message. This is the file I believe is being called "/openstack/venvs//nova-20.2.1/lib/python3.6/site-packages/nova/api/openstack/wsgi.py" . So how is it being called or which program is calling it ? I want to know the first file which uwsgi loads after being launched. On Wed, Nov 9, 2022 at 5:28 PM Neil Hanlon <neil(a)shrug.pw> wrote: > > > On Wed, Nov 9, 2022, 05:51 Gk Gk <ygk.kmr(a)gmail.com> wrote: > >> Thanks Melanie for the reply. I am able to use pdb successfully for the >> trace. But I am observing a strange behaviour with the python source files. >> Whenever I make any changes to the source files >> , for example, insert a pdb statement in servers.py, it is taking a >> minute or more for the changes to take effect. For example, after the >> change, if I run the uwsgi command at the terminal manually with >> --honour-stdin option, then immediately if I fire the nova list command, >> it is not taking effect. Only after a minute or so of making the change, it >> is taking effect. Somewhat strange. >> >> My next question is, inside the nova-api container, I am trying to trace >> how nova-api service starts. The systemd file has this content: >> --- >> ExecStart = /openstack/venvs/uwsgi-20.2.1-python3/bin/uwsgi --autoload >> --ini /etc/uwsgi/nova-api-os-compute.ini >> ---- >> So I have checked the file /etc/uwsgi/nova-api-os-compute.ini , which has >> the below content: >> --- >> wsgi-file = /openstack/venvs/nova-20.2.1/bin/nova-api-wsgi >> -- >> >> Is the above file '/openstack/venvs/nova-20.2.1/bin/nova-api-wsgi' the >> one from which the nova-api service starts at all ? >> > > That is correct. The nova-api-wsgi and nova-metadata-wsgi entry points > read nova.conf and api-paste.ini to generate the required WSGI application. > > Those scripts are just python entry points so you should be able to follow > along there, barring some setuptools magic invoked. > >> >> >> Thanks >> Kumar >> >> On Wed, Nov 9, 2022 at 5:39 AM melanie witt <melwittt(a)gmail.com> wrote: >> >>> On Tue Nov 08 2022 03:03:18 GMT-0800 (Pacific Standard Time), Gk Gk >>> <ygk.kmr(a)gmail.com> wrote: >>> > Hi All, >>> > >>> > I have a OSA setup. I am trying to trace the control flow of nova-api >>> > using pdb in the file >>> > >>> "/openstack/venvs/nova-20.2.1/lib/python3.6/site-packages/nova/objects/instance.py". >>> > >>> > My goal is to trace the flow for "nova list --all" command. I am >>> > launching the nova-api service manually from the command line as >>> follows: >>> > >>> > #/openstack/venvs/uwsgi-20.2.1-python3/bin/uwsgi --ini >>> > /etc/uwsgi/nova-api-os-compute.ini --workers 1 >>> > >>> > I am executing "nova list --all" command in another terminal. I have >>> > inserted pdb in instance.py as follows: >>> > >>> > ---- >>> > @base.remotable_classmethod >>> > def get_all(cls, context, expected_attrs=None): >>> > import pdb; pdb.set_trace() >>> > """Returns all instances on all nodes.""" >>> > db_instances = db.instance_get_all( >>> > context, >>> columns_to_join=_expected_cols(expected_attrs)) >>> > return _make_instance_list(context, cls(), db_instances, >>> > expected_attrs) >>> > --- >>> > >>> > But when I fire the nova list --all command, I see no pdb prompt being >>> > shown in the nova-api window. Can anyone help me how to use the pdb to >>> > trace the flow of control for "nova list --all" command ? >>> >>> It looks like running nova-api that way is still running as a background >>> process: >>> >>> >>> https://stackoverflow.com/questions/34914704/bdbquit-raised-when-debugging-… >>> >>> I got that result ^ when I tried it locally. >>> >>> I was however able to get success with remote pdb: >>> >>> https://docs.openstack.org/devstack/latest/systemd.html#using-remote-pdb >>> >>> so maybe give that a try. Note that the code where you set the trace in >>> nova/objects/instance.py is not actually hit when doing a server list. >>> You may have instead meant: >>> >>> >>> https://github.com/openstack/nova/blob/c97507dfcd57cce9d76670d3b0d48538900c… >>> >>> Also note that as a community we're trying to get away from using the >>> legacy 'nova' command and recommend using the openstackclient instead: >>> >>> >>> https://docs.openstack.org/python-openstackclient/latest/cli/command-object… >>> >>> The 'nova' CLI is no longer being maintained and we're adding to the >>> novaclient python bindings only when necessary. >>> >>> HTH, >>> -melwitt >>> >>> >>> >>>

2 1

[Openstack][FOSDEM][CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski 11 Nov '22

11 Nov '22

We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2023, to be hosted on February 4th 2023. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 10th, 2022. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 10th December 2022 Acceptance notifications: 15th December 2022 Final schedule announcement: 20th December 2022 Devroom: First half of 4th February 2023 Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Submission Guidelines Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. How to Apply In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact devroom mailing list [2] for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM17> https://penta.fosdem.org/submission/FOSDEM23 [2] iaas-virt-devroom at lists.fosdem.org

1 0

[ansible-openstack-modules] 2023.1 Antelope PTG summary
by Rafael Castillo 10 Nov '22

10 Nov '22

We held our ansible-collections-openstack PTG a few weeks ago. Thanks to everyone who participated! Here's a belated summary of the discussions that took place. Etherpad: https://etherpad.opendev.org/p/oct2022-ptg-os-ansible-modules The plan for the Antelope cycle is to continue our current course of porting all remaining modules to support the new SDK. Our tentative release date for 2.0.0 is January 1st 2023. While porting modules will be the priority first and foremost, we discussed some proposals for enhancement during our session. These will remain on the backburner and will be addressed on a best effort basis. # Proposals for improvement ## Consistent module naming In order to make the modules more self-describing, avoid prefixes like federation_idp and keep names obvious. Change module names to be consistent with openstack-client. Change return values to match module names where possible. ## Documentation updates Highlight in docs that module results can differ depending on the cloud they use. Our module docs are currently based on devstack. Keep different documentation pages on galaxy between stable and master, as the two differ quite a bit. Update README and docs folder with more current information. ## Migrate current tests to use ansible-test The ansible-test integration test runner has some nice features. There's examples of the OTC modules using this we can take a look at. ## Write sdk logs to module results instead of writing to file Can be more convenient to have logs available right in ansible output. Counter-point is that these logs grow to be huge sometimes. ## Drop pbr based installation? We should focus on supporting ansible-galaxy as the preferred method of installing ansible collections. Again, thanks for participating in the collections process. Have a good weekend.

1 0

[nova][placement] Happy Specs review day next Tuesday (Nov 15) !
by Sylvain Bauza 10 Nov '22

10 Nov '22

Hey, as said above, like every 6-month cycle, we'll have a specs review day to make sure we can jab the open specs. You are a reviewer (even not a core) ? Make sure you can review the specs on Nov 15th. You are a contributor and you have an open spec ? Make sure you can look at Gerrit during this day because you could see new comments and you could then rebase your spec for providing a new revision :) -Sylvain

1 0