Earlier  
Posted Nick Remark
#openstack-nova - 2021-09-15
19:54:13 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: Update SRIOV port pci_slot when unshelving https://review.opendev.org/c/openstack/nova/+/796909
19:54:14 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: Fix ImageBackendFixture not to support direct_snapshot https://review.opendev.org/c/openstack/nova/+/809282
19:54:33 artom That was a PITA to hunt down and figure out it was the ImageBackendFixture backport that was needed...
23:52:33 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: Update SRIOV port pci_slot when unshelving https://review.opendev.org/c/openstack/nova/+/796909
#openstack-nova - 2021-09-16
00:21:00 opendevreview Merged openstack/nova stable/victoria: address open redirect with 3 forward slashes https://review.opendev.org/c/openstack/nova/+/806626
03:40:02 opendevreview melanie witt proposed openstack/nova master: Assert quota related API behavior when noop https://review.opendev.org/c/openstack/nova/+/712140
03:40:02 opendevreview melanie witt proposed openstack/nova master: Add stub unified limits driver https://review.opendev.org/c/openstack/nova/+/712137
03:40:03 opendevreview melanie witt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/c/openstack/nova/+/712139
03:40:03 opendevreview melanie witt proposed openstack/nova master: Make unified limits APIs return reserved of 0 https://review.opendev.org/c/openstack/nova/+/712141
03:40:04 opendevreview melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142
03:40:04 opendevreview melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143
03:40:05 opendevreview melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707
03:40:05 opendevreview melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749
03:40:06 opendevreview melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301
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

Earlier   Later