| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-23 | |||
| 16:29:23 | bauzas | then* | |
| 16:29:41 | gibi | bauzas: the waiting for plug fix needed on victora / pike for my downstream counterpart | |
| 16:29:43 | elodilles | (i don't see much merged content) | |
| 16:29:54 | opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | |
| 16:30:23 | bauzas | gibi: well, for us, wallaby and train, but whatever | |
| 16:30:44 | gibi | yeah probably train too | |
| 16:30:49 | bauzas | I guess we're done with this topic, we can rediscuss about the opportunity to release a bit later in the cycle | |
| 16:31:44 | elodilles | yes, let's discuss later | |
| 16:32:00 | bauzas | ++ | |
| 16:32:08 | bauzas | #topic Sub/related team Highlights | |
| 16:32:14 | bauzas | Libvirt (lyarwood) | |
| 16:32:19 | lyarwood | wait on a fix in QEMU. | |
| 16:32:19 | lyarwood | We are tracking a QEMU 6.1.0 regression downstream with [libvirt]num_pcie_ports >= 15 when using the q35 machine type, we aren't hitting it yet upstream in Nova itself as we only use q35 in nova-next but TripleO is seeing it with centos 8 and 9 stream after a QEMU rebase. The workaround is to lower the port count to <=14. Just a heads up for now, I've got a TODO to create a known issue release note in Nova for the time being while we | |
| 16:32:57 | bauzas | ouch. | |
| 16:33:00 | lyarwood | and that's all I have this week | |
| 16:33:27 | sean-k-mooney | ack so noting to do in nova other then the known issue | |
| 16:33:35 | bauzas | ack, I also saw some bad libvirt modification that creates problems for our vgpu support | |
| 16:33:39 | sean-k-mooney | and perhaps change job config if needd | |
| 16:33:50 | lyarwood | sean-k-mooney: ack pretty much | |
| 16:33:55 | bauzas | https://bugs.launchpad.net/nova/+bug/1951656 | |
| 16:34:27 | bauzas | the fix is easy but that makes me worried about the fact that the namings we have are not a public API | |
| 16:35:06 | sean-k-mooney | its not the first time we have been broken by such name changes | |
| 16:35:45 | bauzas | can't imagine what would happen if the drivers can also change their mdev type names | |
| 16:36:04 | bauzas | we're a bit fragile | |
| 16:36:08 | bauzas | anyway | |
| 16:36:12 | bauzas | let's not overdiscuss this | |
| 16:36:26 | bauzas | we have a few specless bps requests again this week | |
| 16:38:10 | bauzas | #info QEMU 6.1.0 regression downstream with [libvirt]num_pcie_ports >= 15 requires for the moment to work around by lowering the port count to <=14. lyarwood will provide a relnote for it until the QEMU regression is fixed | |
| 16:38:27 | bauzas | moving on | |
| 16:38:31 | bauzas | #topic Open discussion | |
| 16:38:35 | bauzas | #topic Open discussion | |
| 16:38:44 | bauzas | (dasp) Blueprint for review: "Make no_compression_image_types configurable" -- https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types | |
| 16:38:49 | bauzas | dasp: around ? | |
| 16:38:57 | bauzas | Rationale: hardcoded behavior slows down cold migrations with local RAW disk images to 8 mbps and maxes CPU. It might be a good idea to change the default value as well or disable compression for all types. | |
| 16:39:58 | dansmith | this is compression of just the stream? | |
| 16:41:24 | dansmith | I assume the original thought is that raw disks *might* be mostly zeroes which compress to nothing during transfer, | |
| 16:41:38 | dansmith | but that probably falls apart over time and makes it compression for no reason | |
| 16:41:41 | bauzas | that's my general assumption | |
| 16:42:06 | sean-k-mooney | for ssh | |
| 16:42:09 | dansmith | ideally libvirt would just do hole detection and not transfer the holes, I think, but... | |
| 16:42:10 | sean-k-mooney | it just adds -C | |
| 16:42:19 | sean-k-mooney | for rsync it enable rsync compression | |
| 16:42:20 | dansmith | sean-k-mooney: ah, right | |
| 16:42:35 | dansmith | well, I see no reason to prevent people from choosing this, so seems okay to me | |
| 16:42:40 | bauzas | oh the ssh transfer itself ? | |
| 16:42:47 | sean-k-mooney | yes | |
| 16:42:56 | bauzas | I guess the proposal is to make it configurable ? | |
| 16:43:01 | dansmith | yeah | |
| 16:43:10 | bauzas | but that would be for all images of the same type | |
| 16:43:18 | dansmith | default to the same behavior it looks like, so no change unless you want change | |
| 16:43:18 | dasp | I'm here | |
| 16:43:21 | bauzas | (I guess) | |
| 16:43:37 | sean-k-mooney | its this https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/volume/remotefs.py#L192-L193 | |
| 16:43:50 | bauzas | dansmith: if this is opt-in for uncompress, that's OK | |
| 16:43:55 | dansmith | bauzas: right | |
| 16:44:07 | bauzas | dansmith: if that's changing the default to *not* compress raw images, I'm -1 | |
| 16:44:14 | sean-k-mooney | so the current patch if they have not reviesed it maintianed the exsting behavior | |
| 16:44:19 | dansmith | bauzas: no, it's keeping the same default, just allowing people to control it | |
| 16:44:34 | sean-k-mooney | and i was suggesting we would not change the default without more dicussion | |
| 16:44:47 | bauzas | then it looks to me a simple configurable ask, which doesn't require a spec provided they don't break existing behaviour | |
| 16:44:49 | sean-k-mooney | although both rsync and ssh recommend it only for slow connections | |
| 16:45:09 | dasp | yes, changing default is not in scope right now as it comes from me. However, based on my tests, the default behavior is very bad unless I'm doing something unusually wrong. | |
| 16:45:37 | dasp | So I'm likely going to propose another future spec to change the default separately. | |
| 16:45:44 | sean-k-mooney | dasp: right so for now i think we shoudl add the option and consider changing the default after we get some operator input | |
| 16:45:53 | bauzas | what sean-k-mooney said | |
| 16:45:56 | dansmith | I dunno if discard will cause qemu to zero sections of a raw disk, but if not, over time your raw disk of zeroes becomes not that, so compression becomes useless after a point | |
| 16:45:57 | bauzas | expose the new knob | |
| 16:46:02 | bauzas | let operators play with it | |
| 16:46:17 | bauzas | and give us figures about why this is helpful to change the default | |
| 16:47:54 | bauzas | anyone having concerns about https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types NOT being a specless BP ? | |
| 16:48:36 | bauzas | no API modifications, no upgrade concerns, no DB modifications, just a configurable add | |
| 16:48:53 | sean-k-mooney | this is ok to me so no objections | |
| 16:48:59 | dansmith | yup | |
| 16:49:00 | bauzas | looks like nobody is freaking out | |
| 16:49:21 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types is approved as a specless BP, provided no change in default behaviour | |
| 16:49:30 | bauzas | next one | |
| 16:49:38 | bauzas | (jhartkopf) Update user data spec (https://review.opendev.org/c/openstack/nova-specs/+/816542) | |
| 16:49:43 | bauzas | jhartkopf: around ? | |
| 16:49:51 | bauzas | are you just asking for spec review ? | |
| 16:50:07 | jhartkopf | around | |
| 16:50:35 | bauzas | oh, I remember this one | |
| 16:50:51 | bauzas | that's an interesting case | |
| 16:50:52 | sean-k-mooney | i think jhartkopf wanted to expand on there usecase | |
| 16:51:01 | bauzas | right | |
| 16:51:11 | jhartkopf | We have already discussed this spec extensively, but I’d like to focus on a specific use case now. | |
| 16:51:38 | jhartkopf | We think the change would make sense when using Cloudbase-init plugins, which can run at every boot and configures guest settings based on user data | |
| 16:51:56 | jhartkopf | We already brought that up, but still think this would be a valid use case | |
| 16:52:21 | sean-k-mooney | cloud-init support that too by the way its just not how its typically used | |
| 16:52:32 | bauzas | jhartkopf: IIRC, your usecase was for ssh key management, right? | |
| 16:52:50 | sean-k-mooney | i thikn that was someone else usecase | |
| 16:52:56 | jhartkopf | bauzas: no, that was the other person who wanted the same feature some years ago | |
| 16:53:05 | bauzas | hah, apologies then | |
| 16:53:06 | sean-k-mooney | for ssh key manament i do think there is vaule in support multiple keys and updating them | |
| 16:53:39 | bauzas | jhartkopf: my concern is, which specific cases are useful that require the userdata to be mutable ? | |
| 16:53:56 | bauzas | besides the fact that other big Fives do this | |
| 16:54:28 | sean-k-mooney | speificly is there a usecase you are trying to enable that is a usecase for the end user/tenant not the operator | |
| 16:54:30 | jhartkopf | sean-k-mooney: Cloud-init supports this as well, yes. But why would you want to restrict API functionality and potentially restrict other's workflows? | |
| 16:55:09 | bauzas | sean-k-mooney: indeed, cases about end user | |
| 16:55:16 | sean-k-mooney | the user-data is "owned" by the enduser so if the reason to make it mutable is so operators can chagne it it would not be consitnet with the usage of that api | |
| 16:55:39 | dasp | when rebuilding an instance, you can't redeclare userdata (AFAIK) but you effectively make cloud-init re-run, that's a trap my users run into | |