| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-30 | |||
| 16:22:25 | fwiesel | That's it from my side. | |
| 16:22:27 | bauzas | no worries | |
| 16:22:42 | bauzas | 9 people don't do babies in 1 month | |
| 16:22:59 | bauzas | ditto indeed | |
| 16:23:22 | fwiesel | All that is left is just wiring it up. It may take just a day, if everything is in place. | |
| 16:23:38 | bauzas | let's then wait | |
| 16:23:44 | bauzas | thanks | |
| 16:23:49 | fwiesel | You're welcome. | |
| 16:23:53 | bauzas | #topic Open discussion | |
| 16:24:02 | bauzas | we have one topic | |
| 16:24:04 | bauzas | (NotTheEvilOne) Support for "Bring your own keys" to `Volume.Create()` | |
| 16:24:11 | bauzas | NotTheEvilOne: around ? | |
| 16:24:14 | NotTheEvilOne | yes | |
| 16:25:37 | NotTheEvilOne | Hi everyone. I would like to basically learn if the idea and intentions are the right way to go and what you may suggest. We (Sovereign Cloud Stack) https://scs.community would like to bring the feature "bring you own keys" for encryption to OpenStack, | |
| 16:26:03 | NotTheEvilOne | #link https://github.com/SovereignCloudStack/issues/issues/519 | |
| 16:26:20 | NotTheEvilOne | For that reason I added a bug to launchpad | |
| 16:26:31 | dansmith | probably best to write up a spec for how you plan to do that, what the workflow and use-cases are so we can review in that format | |
| 16:26:33 | NotTheEvilOne | #link https://bugs.launchpad.net/nova/+bug/2051108 | |
| 16:27:20 | NotTheEvilOne | Should I add that to the ticket? We already had a basic idea. | |
| 16:27:22 | NotTheEvilOne | #link https://input.scs.community/9FbrLgYbT8KFvZGXLzay6Q?view#Go-implementation | |
| 16:27:46 | dansmith | that bug is against nova but says cinder lacks the current API to do it, so it's not clear what nova would need here, and we also need to know if/that cinder has an approved design for their side | |
| 16:28:19 | bauzas | NotTheEvilOne: we'll have a PTG in April | |
| 16:28:23 | dansmith | NotTheEvilOne: that doc of yours also seems to imply only cinder changes | |
| 16:28:29 | bauzas | which is one week after the Caracal release | |
| 16:29:00 | bauzas | given we're currently on new features approval freeze, we can't even accept your request for this cycle | |
| 16:29:07 | NotTheEvilOne | I guess that only some changes are needed to Cinder indeed as most building blocks are already there | |
| 16:29:18 | NotTheEvilOne | I see. | |
| 16:29:20 | bauzas | so I'd strongly suggest you to attend next PTG in April and join the Cinder community at that time | |
| 16:29:24 | dansmith | NotTheEvilOne: okay then you're in the wrong channel/meeting :) | |
| 16:29:58 | bauzas | if something is needed from the nova side when discussing w/ the Cinder folks, then surely we could join that session | |
| 16:30:04 | dansmith | yep | |
| 16:30:16 | NotTheEvilOne | Is it possible to move the bug to the correct category? | |
| 16:30:18 | NotTheEvilOne | ok | |
| 16:30:32 | bauzas | NotTheEvilOne: https://openinfra.dev/ptg/ | |
| 16:30:58 | bauzas | NotTheEvilOne: I can point you to the right Cinder folks to bug | |
| 16:31:06 | bauzas | in order to make sure your topic is discussed at the PTG | |
| 16:31:17 | NotTheEvilOne | Would be great, thanks | |
| 16:32:46 | bauzas | NotTheEvilOne: will give you the nicks after the meeting | |
| 16:32:53 | bauzas | stay online for a sec | |
| 16:33:03 | bauzas | I think we're done by now | |
| 16:33:11 | bauzas | any other topic to discuss ? | |
| 16:34:40 | bauzas | looks not | |
| 16:34:56 | bauzas | let's just call it done | |
| 16:34:59 | bauzas | thanks all | |
| 16:35:05 | bauzas | #endmeeting | |
| 16:35:05 | opendevmeet | Meeting ended Tue Jan 30 16:35:05 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:35:05 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-01-30-16.00.html | |
| 16:35:05 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-01-30-16.00.txt | |
| 16:35:05 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-01-30-16.00.log.html | |
| 16:35:35 | bauzas | NotTheEvilOne: so, | |
| 16:35:43 | bauzas | about your request | |
| 16:35:53 | bauzas | the first thing to do is to reach the Cinder folks | |
| 16:36:20 | bauzas | I don't know their release deadlines, but they're probably like us post-feature approval | |
| 16:36:47 | bauzas | so I suggest you to engage with them and see how you can draft your feature request | |
| 16:37:22 | bauzas | the folks to contact are in the #openstack-cinder IRC chan and the main person to reach for communication is the Cinder PTL : whoami-rajat | |
| 16:37:34 | NotTheEvilOne | Sounds good. There's no separate meeting scheduled for Cinder, right? ok - isee | |
| 16:38:18 | NotTheEvilOne | I'll do that, thanks :) | |
| 16:49:46 | bauzas | dansmith: thanks for your reviews on the live-migration series, I'll softly digest those | |
| 16:50:06 | NotTheEvilOne | cya :) | |
| 16:52:37 | dansmith | bauzas: ack | |
| 16:53:28 | bauzas | dansmith: gerrit ui is providing me some wrong quick glance, I need to click at every single file | |
| 16:53:53 | bauzas | but iiuc, you mostly have three concerns : | |
| 16:54:02 | bauzas | 1/ the object fileds | |
| 16:54:05 | bauzas | fields | |
| 16:54:15 | bauzas | 2/ the virt driver method we provide | |
| 16:54:23 | bauzas | 3/ the persistence we do | |
| 16:54:43 | bauzas | for 1/, I think I can reduce the envelope by removing one unnecessary field | |
| 16:54:58 | bauzas | but we'll still need to provide information about the src support | |
| 16:55:12 | bauzas | err, the dst support | |
| 16:56:21 | bauzas | for 2/, this is due to the ping-pong we do between src and dest | |
| 16:56:38 | bauzas | with RPC calls | |
| 16:57:53 | bauzas | for 3/, I need to correctly look again at your concerns | |
| 17:24:44 | opendevreview | Amit Uniyal proposed openstack/nova master: Allow swap resize from non-zero to zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| #openstack-nova - 2024-01-31 | |||
| 00:55:11 | tonyb | I have access to a cloud that, due to a rabbitmq failure, is in an inconsistent state. `openstack server list` returns a bunch of instances, some [most] return `No server with a name or ID of '$UUID' exists.` when trying to get more information/delete the nodes. | |
| 00:55:49 | tonyb | Any advice on how to reconcile the list with the instances that are still alive? | |
| 06:03:18 | tonyb | Picking one instance as an example, I see it in nova_api.instance_mapping, looking in the nove_cell0.instances it shows as deleted. | |
| 11:30:53 | sean-k-mooney[m] | @tonybso cell0 is only used for instances that fail to boot to any host but pass the intal api checks for is this request valid | |
| 11:31:23 | sean-k-mooney[m] | cell0 should never have any compute nodes in it | |
| 11:38:56 | tonyb | I did more digging and found a number (but not all) of the instances showing up in 'server list' have data in the build_requests table. | |
| 11:39:55 | tonyb | I *suspect* I can delete them from the build_requests table and they | |
| 11:40:12 | tonyb | 'll "go away" | |
| 11:42:06 | tonyb | I also expect that will take care of most of the problems and then I can work out what the next stage is | |
| 11:51:09 | sean-k-mooney[m] | that could happen in older openstack release but i belive we fixed that at some point | |
| 11:52:22 | sean-k-mooney[m] | has anyone worked with the SovereignCloudStack folks on there standards openstack clouds | |
| 11:52:26 | sean-k-mooney[m] | https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0100-v3-flavor-naming.md | |
| 11:53:02 | sean-k-mooney[m] | that is interestign and i agree with most of it but it also impleies some functionality that nova does not supprot nativly | |
| 11:53:13 | sean-k-mooney[m] | at lest not without security risk | |
| 11:54:04 | sean-k-mooney[m] | there disk section https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0100-v3-flavor-naming.md#baseline-2 | |
| 11:54:40 | sean-k-mooney[m] | the mention if the flaovr name does not have a disk capsity that menas the cloud will provide at least image.min_disk space | |
| 11:55:23 | sean-k-mooney[m] | that either need the operator to cofnig root_gb=0 and allow non bfv instance with 0 root disk | |
| 11:55:31 | sean-k-mooney[m] | that was considred a cve in the past | |
| 11:55:49 | sean-k-mooney[m] | or they need to have downstrema changes to supprot that | |
| 11:56:39 | sean-k-mooney[m] | i feel its in approate to propsoe a standard behavior that is not supproted upstream or that depends on a security vulnerability | |
| 11:57:01 | sean-k-mooney[m] | the also have | |
| 11:57:02 | sean-k-mooney[m] | Multi-provisioned Disk | |
| 11:57:02 | sean-k-mooney[m] | The disk size can be prefixed with Mx prefix, where M is an integer specifying that the disk is provisioned M times. Multiple disks provided this way should be independent storage media, so users can expect some level of parallelism and independence. | |
| 11:57:24 | sean-k-mooney[m] | nova only support multipel disks for the same isntance if you use both root_gb adn ephmeral_gb | |
| 11:57:36 | sean-k-mooney[m] | and nova does not supprot puttign them on diffent storage media | |
| 11:57:52 | sean-k-mooney[m] | so again that would require downstream only modifications to nova | |
| 11:57:54 | tonyb | sean-k-mooney[m]: This is victoria | |