| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-16 | |||
| 03:40:07 | opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | |
| 03:40:07 | opendevreview | melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180 | |
| 03:40:09 | opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | |
| 03:40:09 | opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | |
| 07:54:11 | lpetrut | Hi, I have a question about keypairs. Nova allows a single keypair to be associated with a vm, yet in some cases we must inject multiple keys. We're using the k8s CAPO provider so we can't really use the userdata directly to inject additional keys. Now, apparently it's possible to bundle multiple ssh keys with the same keypair. Can we rely on this behavior to remain available? Fwiw, when bundling multiple keypairs, apparently each keypair must | |
| 07:54:12 | lpetrut | have a comment, otherwise nova will fail to generate a fingerprint and reject it. | |
| 07:58:16 | bauzas | good morning Nova | |
| 07:58:32 | bauzas | for the first time during this week, I eventually have a bit time for going upstream... | |
| 07:59:19 | gibi | bauzas: o/ could you please check the comments on the prelude | |
| 07:59:48 | bauzas | lpetrut: the API doesn't look it supports more than one public key for a keypair | |
| 07:59:52 | bauzas | lpetrut: https://docs.openstack.org/api-ref/compute/?expanded=create-or-import-keypair-detail | |
| 07:59:55 | bauzas | gibi: sure, will look | |
| 08:00:01 | gibi | thank you | |
| 08:00:09 | bauzas | I also want to work for the vgpu documentation | |
| 08:00:28 | gibi | also would be nice to land this doc https://review.opendev.org/c/openstack/nova/+/809161 and link it to the prelude | |
| 08:00:50 | gibi | sure, if you push vgpu doc ping me and I will prioritize it | |
| 08:01:14 | bauzas | gibi: ack, will look at it today | |
| 08:01:42 | lpetrut | bauzas: we're passing multiple ssh keys separated by newline. apparently other people rely on it as well: https://help.switch.ch/engines/faq/how-to-use-multiple-ssh-keys/ | |
| 08:11:06 | lpetrut | it's an ugly workaround, but it would be nice if we could continue to allow it until nova gets to support associating multiple keypairs | |
| 08:13:02 | bauzas | lpetrut: well, | |
| 08:13:08 | bauzas | if this works, fine | |
| 08:13:27 | bauzas | but we can't say we would continue to support, given our API doesn't say this | |
| 08:13:59 | lpetrut | makes sense | |
| 08:14:00 | bauzas | but we could create a API microversion for supporting multiple public keys per keypair | |
| 08:15:12 | bauzas | that said, I'm not sure what could be stopping to have public keys | |
| 08:15:27 | bauzas | given we ask for a string | |
| 08:15:49 | bauzas | unless we verify this string | |
| 08:16:02 | lpetrut | there's some validation going on when the fingerprint gets generated | |
| 08:16:20 | lpetrut | but if the first key has a comment, the rest of the payload seems to be treated as a comment and ignored | |
| 08:23:13 | bauzas | hah | |
| 08:23:15 | bauzas | I see | |
| 08:23:31 | bauzas | well, unless the input validation changes... | |
| 08:25:21 | bauzas | lpetrut: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/keypairs.py#L47 | |
| 08:27:02 | bauzas | well, this is treated from the API as a full string | |
| 08:27:08 | bauzas | so... | |
| 08:27:17 | bauzas | don't be that afraid | |
| 08:28:08 | lpetrut | great, thanks. just wanted to be sure that others are aware of this situation as well, hopefully we'll be able to improve the API eventually. | |
| 08:28:08 | bauzas | lpetrut: anyway, changing this contract would require a microversion so in case you think you're trampled, you could use an old microversion for importing your multiple-pub keypair | |
| 08:28:43 | bauzas | lpetrut: well, an opensource project can't be "aware" of how people use it | |
| 08:28:55 | lpetrut | about the api change, wondering which should be the best option: multiple keys bundled by a single keypair, or multiple keypairs associated with a single vm | |
| 08:29:25 | bauzas | we try to remember exotic usages, but for best effort, we always say that things that aren't tested in CI are unsupported | |
| 08:29:36 | lpetrut | yep, definitely | |
| 08:29:40 | bauzas | as we could break things | |
| 08:30:06 | bauzas | lpetrut: good question about the draft, I'd say this would be discussed in a spec | |
| 08:30:51 | lpetrut | this might require some cloud-init changes as well | |
| 09:16:33 | bauzas | gibi: i'm tempted to rebase the prelude above lyarwood's doc change, thoughts on it ? | |
| 09:16:49 | gibi | bauzas: works for me | |
| 09:16:59 | bauzas | ok, working on it | |
| 09:17:11 | bauzas | anway, needs to provide a new rev for the prelude | |
| 09:25:38 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add the Xena prelude section https://review.opendev.org/c/openstack/nova/+/807786 | |
| 09:34:22 | opendevreview | Merged openstack/nova master: docs: Add nova-volume volume_attachment refresh admin workflow https://review.opendev.org/c/openstack/nova/+/809161 | |
| 09:43:45 | bauzas | woah, the gate is quiet for a RC1 day | |
| 09:45:21 | bauzas | gibi: working now on sean-k-mooney's doc change https://review.opendev.org/c/openstack/nova/+/806412 | |
| 09:45:30 | bauzas | we could merge it soon | |
| 09:45:49 | bauzas | and before the prelude so we could add it in the prelude | |
| 10:07:37 | sean-k-mooney | am i dont know if we need to mention it in the prelude | |
| 10:07:54 | sean-k-mooney | bauzas: have we not already mentioned the mdevs | |
| 10:08:25 | bauzas | sean-k-mooney: yes we told about them in the prelude | |
| 10:08:37 | bauzas | https://review.opendev.org/c/openstack/nova/+/807786 | |
| 10:10:03 | sean-k-mooney | bauzas: so we can proceed with the docs change but i dont think we need to update the prelude for it | |
| 10:10:43 | bauzas | sean-k-mooney: do you want to work on the doc change or do you let me fixing the nits ? | |
| 10:11:17 | sean-k-mooney | ill leave it to you | |
| 10:20:10 | bauzas | ok, will work on it later after lunch | |
| 10:20:22 | bauzas | our lovely customer leaves us quiet for the moment :) | |
| 10:20:53 | sean-k-mooney | oh dont jinx us like that | |
| 10:25:33 | kashyap | Heh | |
| 10:36:23 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/placement/+/809363 | |
| 10:36:24 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/placement/+/809364 | |
| 10:36:25 | opendevreview | OpenStack Release Bot proposed openstack/placement master: Update master for stable/xena https://review.opendev.org/c/openstack/placement/+/809365 | |
| 10:36:27 | opendevreview | OpenStack Release Bot proposed openstack/placement master: Add Python3 yoga unit tests https://review.opendev.org/c/openstack/placement/+/809366 | |
| 13:52:15 | opendevreview | Artom Lifshitz proposed openstack/nova stable/victoria: Update SRIOV port pci_slot when unshelving https://review.opendev.org/c/openstack/nova/+/796909 | |
| 15:05:38 | melwitt | gibi: apologies if I missed it but I was wondering what are we doing about placement release note prelude and release? I thought about it since we have a couple of new features this time | |
| 15:06:03 | gibi | melwitt: in the last couple of release we had no placemen release prelude written | |
| 15:06:35 | melwitt | ack | |
| 15:06:46 | gibi | interrestingly https://docs.openstack.org/releasenotes/placement/unreleased.html this is open | |
| 15:06:51 | gibi | s/open/empty/ | |
| 15:06:55 | gibi | that feels bad | |
| 15:07:33 | melwitt | hm... that's weird, I thought we had added renos | |
| 15:07:41 | gibi | yeah I do remember we added | |
| 15:07:44 | gibi | running tox locally now | |
| 15:08:57 | melwitt | yeah, just checked and consumer types definitely had a reno | |
| 15:09:32 | gibi | hm, locally I get a proper releasenotes generated | |
| 15:09:46 | gibi | we have renos for 1.37 and 1.38 | |
| 15:10:02 | gibi | that is the two feature we added in Xena | |
| 15:10:54 | melwitt | hm.. ok I'll try to figure out what's wrong with it. I don't remember off the top of my head how the doc publishing works but I think I could find it | |
| 15:11:25 | gibi | thanks | |
| 15:11:47 | sean-k-mooney | that i think is based on tags | |
| 15:12:00 | sean-k-mooney | or something in the comit | |
| 15:12:10 | sean-k-mooney | that marks the start/end of a releas | |
| 15:13:01 | melwitt | well they are supposed to show up in the "unreleased" area soon after merge | |
| 15:13:16 | melwitt | the creation of the release page like "Xena" is a different thing | |
| 15:13:28 | sean-k-mooney | yes but they might be showing up in a xena section | |
| 15:14:17 | melwitt | there is no xena section. the notes are nowhere | |
| 15:14:50 | bauzas | placement should have an unreleased.rst file | |
| 15:14:59 | bauzas | if not, it's something we could do | |
| 15:15:02 | melwitt | I get why we don't have a xena section, we probably didn't do a release yet. but the notes should be in the unreleased area and there's nothing there | |
| 15:15:05 | gibi | maybe we need this patch https://review.opendev.org/c/openstack/placement/+/809365 | |
| 15:15:30 | bauzas | gibi: no this is the xena stable one | |
| 15:15:37 | bauzas | once we branch with RC1 | |
| 15:15:39 | bauzas | oh wait | |