December 2024 - openstack-discuss

Re: [nova][security-sig] Communicating SSH host keys on
by Jeremy Stanley 12 Dec '24

12 Dec '24

first boot (was: Removing md5 in password injection) Reply-To: In-Reply-To: <8a163fa2-f071-4744-aae3-2182c048351c(a)redhat.com> On 2024-12-11 16:30:40 +0000 (+0000), Sean Mooney wrote: [...] > > Tangential, sorry, but could this sort of mechanism also be used to > > provide an out-of-band verification of SSH hostkeys generated on > > first boot for *nix type guests? We used to splat them to the > > primary terminal and then try to scrape them from the console log,… [View More] > > but having a structured API response would be a lot cleaner (or did > > something similar already get added and I missed it?). [...] > i see the merrit in supprot some kind of reporting for limited > trusted boot type use cases such as providing the ssh host key > fingerprint so you can validate that the vm is the one you expect > it to be. > > im not sure how i would feel about allowing arbiarty metadata to > be store this way. > > is there something beyond the host key that would be useful for > you to record on boot? Nothing else comes to mind. Basically it's the desire to avoid ToFU style finger-crossing that the SSH host key you get on initially connecting to a newly booted server instance is really coming from that instance and not a MitM or honeypot. It's possible in most providers to create an authenticated backchannel by abusing the console log, as I described, but that has its own challenges. I suppose there might be alternative management protocols similar to SSH which rely on asymmetric key algorithms to authenticate hosts, but I'm not personally familiar with any (none with the near ubiquity of SSH at any rate). > perhaps we can try and capture this is a spec or separate thread > and work out what an mvp would look like. there would basically be > two part, one extednign the metadata api to support recording the > host key fingerprint somewhere, and then making that discoverable > via the main api perhaps in server show. That would make sense, and it would probably also be a good idea to try to involve e.g. a cloud-init maintainer in any such design discussion, as this would need client-side integration eventually anyway in whatever's going to communicate the key back to nova. > is we allowed read write access to all instance metadata we would > would not actually need to modify the main api as you can already > list metadata on an instance but im worried that could be abused > so i don't know if that is a good idea. Yes, that sounds like a security nightmare. > the nova metadata api is not intended a a high performance key > value store so i dont necessarily think it would be a good idea to > extned this to a generic crud api but we certainly could provide > limited support for targeted uscease liek the one you raise. Agreed, I suppose the field could be given a more generic name in case certain kinds of guests wanted to store functionally similar things in it, but as I said I don't know what else that would end up being anyway. -- Jeremy Stanley [View Less]

1 1

Some questions about ironic
by Johnny Hao 11 Dec '24

11 Dec '24

Hi Buddies, I am new to ironic, after some study, I have several questions about it, could anyone help to answer? Thanks a lot. 1. According to the workflow chart below, what's the communication method between nova-compute and Ironic API? HTTP API call or RPC call through mq like rabbitmq? So are the communications between Ironic Conductor and other components of Neutron, Glance and Cinder/Swift etc? 2. Where do Ironic services run (Ironic API/Conductor/Drivers and DB)? In the controller … [View More]

2 1

[nova] riscv64 emulation support
by James Page 11 Dec '24

11 Dec '24

Hi Nova Team We've had some initial support for enabling RISCV64 support in Nova in a review for sometime which I refreshed this week: https://review.opendev.org/c/openstack/nova/+/889137 Sean suggested that this really needs a blueprint and discussion at the next Nova meeting (which I can't make) so proposing discussion via ML instead: https://blueprints.launchpad.net/nova/+spec/riscv64-emulation-support I'm also going to look at the nova-emulation job to see if that can be extended … [View More]

2 1

OpenStack metrics and logs
by Timothé Bauge 11 Dec '24

11 Dec '24

Hello Stackers, I would like to know what are you all using to monitor and supervise your Openstack clusters ? We are in the process of setting up our own private cloud based on RedHat OpenStack Platform 17.1, we choose not to go with the RedHat Service Telemetry Platform, and were strongly advise against Ceilometer and aodh. At the moment, we built our own stack based on Prometheus (with the plenty of exporters) for the metrics, Graylog + OpenSearch for the logs, and Grafana for the … [View More]

3 3

Re: [openstack-helm] [Cinder] Cinder-Scheduler oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start
by daniel890723＠gmail.com 11 Dec '24

11 Dec '24

Hello Daniel here I have been test and trying to solve the oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start Error on openstack-helm deployed Cinder After the test with kolla-ansible i can confirm the problem is from kubernetes So i perform the test with all Cinder Service with Priviliged true setting in Value.yaml: pod: security_context: volume_usage_audit: pod: runAsUser: 42424 container: cinder_volume_usage_audit: … [View More]

3 3

[nova] Specs review day is TODAY and Spec soft freeze is TOMORROW
by Sylvain Bauza 11 Dec '24

11 Dec '24

Hi folks, As we discussed on yesterday's nova meeting, today is our second specs review day and tomorrow (Dec 12th) will be the last day for providing a new spec to be reviewed. Please see our schedule here: https://releases.openstack.org/epoxy/schedule.html Thanks, -Sylvain

1 0

Open Stack APIs
by foram.thakkar＠crestdata.ai 10 Dec '24

10 Dec '24

Hello, We want to fetch all the servers present in all the projects a user has access to. Currently we have to provide any one project name in the body of the authentication call. Is there a way we can fetch all the projects without providing any project name?

3 3

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-16)
by Goutham Pacha Ravi 10 Dec '24

10 Dec '24

Hello Stackers, We're 16 weeks away from the 2025.1 ("Epoxy") release date (2024-04-02) [1]. OpenStack project teams are planning bug squashes and review jams in the next couple of weeks before contribution activity slows due to end-of-the-year holidays around the world. The OpenStack Technical Committee did not merge any new governance changes this week; however, a few proposals are iterating with community and TC review. === Weekly Meeting === The OpenStack Technical Committee held its … [View More]monthly video conference last week, which was simultaneously recorded via text on IRC [2][3]. The discussion tracked several TC initiatives for this release cycle [4]. Most notably, the recent migration of base integration jobs to Ubuntu 24.04 LTS and Python 3.12 has caused CI jobs to break for several code repos [5]. I’d like to reiterate that project teams must resolve these issues or temporarily pin the nodeset of their test jobs to "ubuntu-jammy" to buy some time for fixes. We then checked on the status of "unmaintained" branches. The release team wanted the TC to solidify processes for two specific issues: nominating "unmaintained" liaisons and establishing guidelines for retiring these branches. The lack of such processes has resulted in the proliferation of "unmaintained" code branches across the community and failure to implement the TC resolution that created these branches [6]. The oldest unmaintained branch is "unmaintained/victoria", and it’s unclear if anyone benefits from keeping it around. Discussion on cleanup has been delayed due to uncertainty about what to do [7]. Meanwhile, branches like Yoga may still have high usage and active contributors, emphasizing the need for a clear process to decide their fate. The technical committee may consider advising the release team to eliminate branches with low usage, but this doesn’t solve the problem of finding volunteers to maintain high-usage branches. The idea is that projects can opt to maintain more branches if there is sufficient user interest and support, but there is currently no process for this, nor is it clear how to recruit volunteers. We agreed to continue this discussion at the next meeting. However, in the meantime, there were no objections to EOL-ing the Victoria, Wallaby, and Xena branches. Clark Boylan (clarkb) noted an issue with building CentOS Stream 10 images using Disk Image Builder, as they cannot boot on several clouds due to the x86_64 v3 CPU instruction set requirement. Only a few provider clouds, including OpenMetal and Rackspace Flex, meet the CPU requirements to boot CentOS 10. This limitation may affect options for regular test nodes, and project teams are advised to take notice. Until all Zuul/Nodepool cloud providers meet the CPU requirements, teams may need to adjust their testing strategies. Jeremy Stanley (fungi) reminded us that nominations for individual member representatives for the OpenInfra Foundation Board of Directors are still open [8]. Ten nominations from members are required to make it onto the ballot. The OpenStack TC's next weekly meeting is today, 2024-12-10. This will be an IRC meeting hosted on #openstack-tc at 1800 UTC. Please find the agenda on the meeting wiki [9]. I look forward to seeing you there. === Governance Proposals === ==== Open for Review ==== Add ansible-role-httpd repo to OSA-owned projects | https://review.opendev.org/c/openstack/governance/+/935694 Retire Murano/Senlin/Sahara OpenStack-Ansible roles | https://review.opendev.org/c/openstack/governance/+/935677 Rework the initial goal proposal as suggested by people | https://review.opendev.org/c/openstack/governance/+/931254 Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/934936 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] TC Meeting Video Recording, 2024-12-03: https://youtu.be/KlYbFxjhACs [3] TC Meeting IRC Log 2024-12-03: https://meetings.opendev.org/meetings/tc/2024/tc.2024-12-03-18.00.log.html [4] TC Tracker for 2025.1: https://etherpad.opendev.org/p/tc-2025.1-tracker [5] Runtime update to Ubuntu 24.04/Python3.12: https://etherpad.opendev.org/p/migrate-to-noble [6] TC Resolution to create "unmaintained" code branches: https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [7] Transition "victoria" code branch to EOL: https://review.opendev.org/c/openstack/releases/+/935373 [8] Nominations for OpenInfra Individual Board Member Elections: https://lists.openinfra.dev/archives/list/foundation@lists.openinfra.dev/th… [9] TC Meeting Agenda, 2024-12-10: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee [View Less]

1 0

Kolla-Ansible: Why is handling kolla_*_fqdn in /etc/hosts out of scope?
by Matthias Tinnemeier 09 Dec '24

09 Dec '24

Dear Community, According to the documentation (https://docs.openstack.org/kolla-ansible/2024.2/admin/advanced-configuratio…) the provisioning of kolla_*_fqdn Name Resolution via /etc/hosts must be managed outside of the scope of Kolla. The question, therefore, is why :-) Given the existence of "customize_etc_hosts", there should be at least some logic to implement this behaviour in an automatic way. Is there a particular reason why this is not being implemented via Kolla? … [View More]

1 0

a suggestion: use LDAP to manage all openstack components configuration
by Shi Wei 09 Dec '24

09 Dec '24

Hi, everyone, I have a suggestion. we can use LDAP service to mange all openstak components and nodes(including physical nodes and vm nodes).  Because ldap is easy to read and ldap can support DNS and DHCP service. if a node get ip address by DHCP server with ldap. You and get the Mac address information from the LDAP server. and if all components are communicated by domain name. all records are on the LDAP server. if the one node will change IP address, you can just modify on the ldap … [View More]

2 1