- openstack-discuss - lists.openstack.org

[docs][arch] Architecture Guide, ch. Control Plane Design
by just.me.on.reddit＠protonmail.com 29 Nov '24

29 Nov '24

I am sorry for proprietary tag - I hope it helps to narrow down the scope of this mail. Tags in order generic to more specific. Hello, If I only understand the term "cloud controller" properly these are those OpenStack services which collectively control whole cloud, inclusively those services exposed to cloud user. Cloud control can run on single hosting node, or can be distributed to a group of nodes. Please correct me if I am wrong. My role is on cloud operative side (a learner to become OS user). Architecture Guide, chapter as in this mail subject states following "It’s also possible to use virtual machines for all or some of the services that the cloud controller manages, such as the message queuing. In this guide, we assume that all services are running directly on the cloud controller." It is hard to continue the lecture of this Guide due to unclear description at following points. 1. reg. "all services are running directly on the cloud controller" Can't actually understand this statement. The "on" suggests cloud controller be hosting services in mind. Furthermore, cloud controller includes only those services acting under the goal of cloud control. Service whose major purpose is to provide functionality to cloud user won't, I suppose, be part of cloud controller. Hence, this statement might be more generic as it should be. 2. reg. "use virtual machines for all or some of the services that the cloud controller manages, such as the message queuing" Will cloud controller really mange message queuing instead of include comprise it? Which use of virtual machine exactly is meant here * placing services to virtual machine during O.S. deployment to hosting IT * the IT hosting OpenStack-based cloud? Should the former bullet apply, wasn't is said in some other Guide, abstraction level rather high, that use of virtual machines as cloud host is recommended only for test and evaluation purposes?

1 0

[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 29 Nov '24

29 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 29 Nov '24

29 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 28 Nov '24

28 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