- openstack-discuss - lists.openstack.org

[openstack-ansible] : GPU computes on openstack-ansible
by Rambo Rambo 29 Nov '24

29 Nov '24

Hi Team Openstack-Ansible Openstack Victoria Release Ubuntu 20.04 I need to add computes having GPU on them. So I need recommendations on the procedure to add them and also what all configurations through openstack-ansible are required for nova_api, nova_scheduler on control node nova_api containers and compute node nova_compute configurations? Also does anyone has experience using and installing openstack service : cyborg for GPU management. Regards Rambo

3 5

[heat][horizon][octavia][oslo][qa][skyline][takcer][telemetry][zaqar] Need attention for tomorrow (Nov 29th) CI migration to Ubutnu Noble
by Ghanshyam Mann 28 Nov '24

28 Nov '24

Hello Team, As you know, we have been trying very hard to test and fix the project CI for the Ubuntu Noble migration[1] and there are 9 projects that are still failing on Noble. Check the etherpad having testing change for me information on failures: - https://etherpad.opendev.org/p/migrate-to-noble The migration is planned for tomorrow (Nov 29th); request you to check/fix the failure before that; otherwise, it will break your project gate. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… -gmann

1 0

[docs][kayobe] Architecture, terms used
by just.me.on.reddit＠protonmail.com 28 Nov '24

28 Nov '24

Dear Kayoube documentation, If possible please be bit more specific at few points - document Architecture, section Networks refers to bare metal overcloud hosts, however the chapter "Hosts in the System" presents only bare metal compute hosts, nor any other text passage clarifies the term "overcloud". This way it is hard to get full understanding of term "Overcloud out-of-band network". Furthermore, if you talk about an out-of-band stuff it gets hard to see what is out-of-band without term in-band be precisely clear.

1 3

[watcher][tc] watcher-drivers launchpad membership
by Sean Mooney 28 Nov '24

28 Nov '24

Hi folks o/ Following up form the PTG discussion https://etherpad.opendev.org/p/r.79644f8f3cd04686c4f45c10aa35d8ac#L65 and the recently merged governance patch https://github.com/openstack/governance/commit/1e547ae39f9913dc9cfd9c755b24… I wanted to raise the topic of the watcher-drivers team https://launchpad.net/~watcher-drivers membership and ownership. during the TC sessions we discussed that that the <project>-coresec teams should be owned by the https://launchpad.net/~openstack-admins team https://etherpad.opendev.org/p/r.0f25532f564fb786a89cfe1de39b004b#L123 watcher does not currently have a sperate watcher-coresec team in launchpadd only a a watcher-drivers team i also think that the watcher driver team should be owned by the https://launchpad.net/~openstack-adminsteam. https://launchpad.net/~watcher-drivers is currently owned by https://launchpad.net/~david-tardivel and the only other member with admin rights is https://launchpad.net/~li-canwei2 Can i ask that one of the existing admin either grant my membership request and delegate admin rights to me or add the https://launchpad.net/~openstack-admins team as admins and make them the owner of the team? licanwei, david-tardivel, would either of ye be willing and able to make those changes in launchpad? i also think it would be prudent to add other active member (the current liaisons) as admins/moderators of the watcher-driver team but i can do that once i have access or https://launchpad.net/~openstack-adminscan. having all launchpad teams owned by https://launchpad.net/~openstack-adminsteam mitigates the risk of loosing access by the current admins becoming inactive, but it would be nice to not need to escalation to them for simple tasks like moderation of the group. that is why i want to add the other liaisons to the admins of the team. I am asking for this access for 2 reasons: Fist to add https://launchpad.net/~openstack-adminsas admins of the team and the launchpad project, Second so that i can create new launchpad series for current releases to do blueprint and bug tracking. at present because we do not have launchpad series fro 2025.1 we cannot properly track bugs/blueprints for the current cycle. In the future if there are no objections form the existing contributors i would also like to create a separate open bug team with less project wide permission so that anyone can contribute to bug triage without needing access to the drivers team. this is in lien with how other project like nova work for example https://launchpad.net/~nova-bugs i also think we should be creating a separate watcher-coresec team to allow dan as the security liaison and the vulnerability management team to properly manage security reports. once we have access to the watcher-drivers team we should be able to update the launchpad project to make that possible. Regards sean.

3 4

[watcher][tc][tempest] watcher gerrit group membership
by Sean Mooney 28 Nov '24

28 Nov '24

Hi everyone o/ As many will be aware, over the last month or two, I and some others have been looking to help maintain and extend the Watcher project. At the ptg, I proposed several topics to cover the administrivia of reviving the project. To bring it to a healthy state where features, bugs and general maintenance could be performed on an ongoing basis and avoid its retirement at the end of the 2025.1 cycle. One of the follow-up items to enable that was the extension of the watcher Gerrit groups to allow others to supplement the largely inactive core groups. https://etherpad.opendev.org/p/r.79644f8f3cd04686c4f45c10aa35d8ac#L47 <https://etherpad.opendev.org/p/r.79644f8f3cd04686c4f45c10aa35d8ac#L47> To that end, I would like to ask the existing watcher core team and TC (or other community members :) ) to provide input on the following proposal. 0.) I want to state upfront that I do not want to take away review rights or diminish the experience and efforts of any of the past or present members of the watcher team. I am sending this proposal to enable the watcher project to function effectively and I am welcome to feedback or objections. 1.) To facilitate the changes in the rest of the proposal I would like to formally ask to be added to all of the existing watcher Gerrit groups * watcher-core https://review.opendev.org/admin/groups/77cd139bd57514e98e5e694a82f7e261b47… <https://review.opendev.org/admin/groups/77cd139bd57514e98e5e694a82f7e261b47…> * watcher-release https://review.opendev.org/admin/groups/b265e6b6457de71c7ecfc2a3c70f0c52cde… <https://review.opendev.org/admin/groups/b265e6b6457de71c7ecfc2a3c70f0c52cde…> * watcher-dashboard-core https://review.opendev.org/admin/groups/77cd139bd57514e98e5e694a82f7e261b47… <https://review.opendev.org/admin/groups/77cd139bd57514e98e5e694a82f7e261b47…> * watcher-dashboard-release https://review.opendev.org/admin/groups/904be58ec9fa0e811166ce6144d6314cc7b… <https://review.opendev.org/admin/groups/904be58ec9fa0e811166ce6144d6314cc7b…> * watcher-specs-core https://review.opendev.org/admin/groups/747af616eb8748aee5b17d9493f9ebbc49e… <https://review.opendev.org/admin/groups/747af616eb8748aee5b17d9493f9ebbc49e…> * watcher-tempest-core https://review.opendev.org/admin/groups/09a91d8e24af9ce44b80062c4851a1d2fa3… <https://review.opendev.org/admin/groups/09a91d8e24af9ce44b80062c4851a1d2fa3…> 2.) watcher-release and watcher-dashboard-release Historically, there has been a benefit to having separate core teams for the master and the stable branches. As the velocity of projects has decreased and projects have become more mature the delineation between the maintainers of the master branch and the stable branches has lessened. I believe there is still merit in having the flexibility to add people directly to the release team independently from the core team so I am not proposing replacing the *-release teams with *-core. To that end, I would like to make the following changes to the membership of watcher-release and watcher-dashboard-release - add stable-maint to both release groups - add watcher-core to watcher-release, as we have done in other projects the ask to the watcher-core team is, if you do not have time to review stable branches, or do not feel comfortable with applying stable policy, then there is no expectation to review on the stable branches. - add watcher-dashboard-core to watcher-dashboard-release - me (sean-k-mooney as release-liaison) to facilitate backports and release activities and Gerrit membership admin. 3.) watcher-core and watcher-dashboard-core As it currently stands the core groups are relatively inactive https://tinyurl.com/bdz9k47n full url: https://openstack.biterg.io/app/dashboards?security_tenant=openstack#/view/…:'Gerrit%20Approvals%20panel%20by%20Bitergia',filters:!(('$state':(store:appState),meta:(alias:Bots,disabled:!f,index:gerrit,key:author_bot,negate:!t,params:(query:!t),type:phrase),query:(match:(author_bot:(query:!t,type:phrase)))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:gerrit,key:project,negate:!f,params:(query:watcher),type:phrase),query:(match_phrase:(project:watcher)))),fullScreenMode:!f,options:(darkTheme:!f,hidePanelTitles:!f,useMargins:!t),query:(language:lucene,query:''),timeRestore:!f,title:'Gerrit%20Approvals',viewMode:view <https://openstack.biterg.io/app/dashboards?security_tenant=openstack#/view/…:'Gerrit%20Approvals%20panel%20by%20Bitergia',filters:!(('$state':(store:appState),meta:(alias:Bots,disabled:!f,index:gerrit,key:author_bot,negate:!t,params:(query:!t),type:phrase),query:(match:(author_bot:(query:!t,type:phrase)))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:gerrit,key:project,negate:!f,params:(query:watcher),type:phrase),query:(match_phrase:(project:watcher)))),fullScreenMode:!f,options:(darkTheme:!f,hidePanelTitles:!f,useMargins:!t),query:(language:lucene,query:''),timeRestore:!f,title:'Gerrit%20Approvals',viewMode:view>) Dan Smith and Slawek Kaplonski were added to help with the retirement/gate issues on behalf of the TC While Dan has offered to help bootstrap the core team we need to be cognizant that both Dan and Slawek have other commitments. Chenker has previously expressed that they intend to review when time allows but they have limited time to do so. To that end, I would like to propose that I be added to both core teams, To have a health core team we will eventually need to have at least 3 active reviewers. Watcher will still be 1-2 reviews short of that, but I hope that can be addressed over the coming months. As others become active over the 2025.1 cycles I would like to revisit the membership and extend the core team after milestone 2 or more realistically after milestone 3 if others demonstrate interest and capacity to review. 4.) watcher-tempest-core This is a newly created group added by https://review.opendev.org/c/openstack/project-config/+/934357 <https://review.opendev.org/c/openstack/project-config/+/934357> This group intends to allow the review team for the tempest plugin to diverge from the main watcher core group. To enable effective review and maintenance of the tempest plugin I would like to propose the following membership changes. - tempest-core should be added as a fallback, to guide best practices, and review if they have time. - gmann has volunteered to help with this too so I propose they be added as a direct member - I would like to be added to have a second active reviewer available. Note, while I can provide some review input I have less knowledge of tempest in general as such I will rely on Gmann's guidance in this area. 5.) watcher-specs Several years ago Nova expanded the nova-specs core group to include nova-core there were a number of motivating factors but one of them was the large overlap between the two groups. another factor was the role of a spec core (focusing on the design constraints, upgrade impact, API impact ectra) is different from the implementation considerations(testing, code quality, performance) often the line between the two is subtle and blurred. To that end, I would like to propose the following changes. - first, I would like to be directly added to the specs core group - second, I would like to add the watcher-core group to watcher-specs. If this proposal is accepted I would like to try and move forward with this in the next week or so to unblock the pending review backlog. Regards sean PS many of the open reviews are cleanup i have submitted so this does not directly address review bandwidth for my personal patches but i think it still has value in general.

3 3

Re: [kolla][oslo] RabbitMQ issue Adding/Removing a Controller Node in an OpenStack Cluster
by Ishan Shanware (ishanwar) 28 Nov '24

28 Nov '24

For everyone’s reference From: Ishan Shanware (ishanwar) <ishanwar(a)cisco.com> Date: Wednesday, 27 November 2024 at 10:01 PM To: Sven Kieske <kieske(a)osism.tech> Subject: Re: [kolla][oslo] RabbitMQ issue Adding/Removing a Controller Node in an OpenStack Cluster Hi Sven, Thanks for getting back to me. We have configured kolla to use 3 controllers in each cluster. Each controller has one rabbitmq container created by kolla. The process we follow move a controller out of rotation is as follows: 1. We first failover all the l3 and dhcp agents running on the controller to the 2 other controllers. 2. We then turn of the server and then delete any neutron agents on it. Currently the rabbitmq cluster only consists of only 2 containers. The problem specifically occurs during the reinstall of the rabbitmq container in the kolla deploy stage. Specifically, after it executes the checking rabbitmq containers role. It triggers a restart for the contains on all the blades. After this stage completed we observe that the masakari-engine disables all the nova-computes. Let me know if you need any other information for discussion Thanks Ishan From: Sven Kieske <kieske(a)osism.tech> Date: Tuesday, 26 November 2024 at 11:36 PM To: Ishan Shanware (ishanwar) <ishanwar(a)cisco.com>, openstack-discuss(a)lists.openstack.org <openstack-discuss(a)lists.openstack.org> Subject: Re: [kolla][oslo] RabbitMQ issue Adding/Removing a Controller Node in an OpenStack Cluster Hi Ishan, my first question would be, how many controller nodes and specifically, rabbitmq nodes you are running inside your Openstack cluster? You should be following the general guidelines for running any raft consensus based distributed system and only run an odd number of systems, e.g. 3 or 5 control nodes. Can you confirm that this is the case in your setup? If you e.g. run a two node setup such errors are indeed expected. See also our production architecture guide: https://docs.openstack.org/kolla-ansible/latest/admin/production-architectu… > Control - Cloud controller nodes which host control services like APIs and databases. This group should have odd number of nodes for quorum. If you are running an odd number of control nodes and you're still facing this issue, I would be curious to know the rabbitmq cluster state before you add or remove a node, because this should theoretically just work. But maybe there is another issue with your cluster. HTH -- Sven Kieske Senior Cloud Engineer Mail: kieske(a)osism.tech Web: https://osism.tech OSISM GmbH / Talweg 8 / 75417 Mühlacker / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Mühlacker Amtsgericht: Stuttgart, HRB 756139

1 1

[watcher] Canceling Dec 5th weekly meeting
by Douglas Viroel 28 Nov '24

28 Nov '24

Hi all o/ Since most of our audience will be out next week, we agreed[1] on canceling watcher's weekly meeting[2], on Dec 5th. We will meet again in two weeks, on Dec 12th. [1] https://meetings.opendev.org/meetings/watcher/2024/watcher.2024-11-28-12.00… [2] https://meetings.opendev.org/#Watcher_Team_Meeting BR, -- Douglas Viroel - dviroel

1 0

[kolla-ansible] nova-cell can't not find nova.keyring file when deploy
by daniel890723＠gmail.com 27 Nov '24

27 Nov '24

hello Daniel here Previously i was testing openstack-helm but it doesn't work so i switch to kolla-ansible with all-in-one mode i was following the official guide and put the keyring file i generate to the config folder: (venv) root:~# nano /etc/kolla/config/nova/ ceph.client.nova.keyring ceph.conf localhost/ nova-compute.conf But when i try to deploy it show the error below TASK [nova-cell : Check nova keyring file] ***************************************************************************************************************** fatal: [localhost]: FAILED! => {"msg": "No file was found when using first_found."} Just in case i also put the keyring file in /config/localhost/nova Still shows the same error But when i put the cinder keyring file in nova folder like this: (venv) root@:~# nano /etc/kolla/config/nova/ ceph.client.cinder.keyring ceph.client.nova.keyring ceph.conf localhost/ nova-compute.conf It can find the cinder keyring file but this time the nova-compute container show error below: unable to find a keyring on /etc/ceph/ceph.client.nova.keyring,/etc/ceph/ceph.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin: (2) No such file or directory Did i do anything wrong or something makes it not able to detect the nova.keyring file P.S. Cinder and Glance works fine and Ceph can be used normally

2 5

[manila] Cancelling Nov 28th upstream weekly meeting
by Carlos Silva 27 Nov '24

27 Nov '24

Hello Zorillas, At least half of our audience tomorrow will not be online tomorrow, as it is thanksgiving in the US, so let's cancel the meeting. We'll resume the weekly meetings on Dec 5th. Regards, carloss

1 0

[ops][kolla-ansible][openstack-ansible] Deploying OpenStack using Ansible to LXC while project is used to grab for Kolla-Ansible
by just.me.on.reddit＠protonmail.com 27 Nov '24

27 Nov '24

Hi, I am learning OS because my imminent mission uses a cloud-based solution (cloud-app) which runs in OpenStack cloud. How do you estimate the probability for a cloud-app to feature built-in Docker dependency (runtime) in situation where the project of mentioned app appears to be used to apply Kolla Ansible in order to deploy OpenStack cloud? It means the cloud-app to depend at runtime on Docker-specific artefacts. 3rd-party cloud-app going to be in use will play a major role in my project. It is in responsibility of cloud-app operator to do provisioning of OpenStack cloud before mentioned app can be deployed to cloud. Recommendations found in cloud-app's documentation read to use Kolla Ansible in order to conduct mentioned provision. Myself learned that Kolla uses Docker. Docker use is that component which triggers me to ask this question. My own preference would be rather to deploy OpenStack services to LXC-containers. One can find in OpenStack web the project Ansible-based deployment to LXC containers. I wonder following if cloud-app developers could had placed in it any built-in Docker (eco-system) runtime dependency and they achieved it by the use of Ansible Kolla for OpenStack deployment. Considering my very flat knowledge of Docker (only familiarized with its purpose and very few exercises made in far past) there exists just hypothetical risk for cloud project in my focus to feature built-in docker eco-system dependency. Should such dependency be a fact (not just a risk) my aim to use OpenStack services in LXC-containers has good chance to fail. It is hard to contact 3rd-party cloud project developer regarding my questions. Question 2 Any common conclusions had been drawn so far if one of the two approaches be of remarkably higher suitableness to host OpenStack-based cloud services? * placing OpenStack-based cloud services to Docker-based containers * placing services of OpenStack-based cloud to Linux containers (LXC/LXD/...)

1 0