Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-23
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 dasp I'm here
16:43:18 dansmith default to the same behavior it looks like, so no change unless you want change
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
16:56:07 sean-k-mooney dasp: for rebuild we do allow new user data to be pass in a later microverion i belive
16:56:18 bauzas yeah that rings me a bell
16:56:19 sean-k-mooney dasp: you are correct that orginally we did not
16:56:19 bauzas sec
16:56:21 dasp oh, sorry my org is running a bit "behind" on versions
16:57:12 bauzas sean-k-mooney: 2.3
16:57:18 bauzas so... Kilo
16:57:20 sean-k-mooney 2.54 allows the key to be changed on rebuild https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id50 and 2.57 allows user data to be updated
16:57:48 bauzas oh, that one
16:57:52 sean-k-mooney bauzas: its no 2.3
16:57:59 bauzas yeah my bad
16:58:06 bauzas this is Queens
16:58:06 sean-k-mooney but ya since queens
16:58:32 bauzas we only have 2 mins left
16:58:41 bauzas (as a timekeeper)
16:59:07 sean-k-mooney jhartkopf: we could proably make it mutable if there is a use facing usecase but we would need to support config dirve and note that the change may not fully be ableable untill after a hard reboot
16:59:23 bauzas I'll have to call it a wrap
16:59:25 bauzas for this week
16:59:30 bauzas we can revisite this in the spec
17:00:21 bauzas #info https://review.opendev.org/c/openstack/nova-specs/+/816542 requires propre description of enduser cases for mutable user data
17:00:31 bauzas that's it, we're over time

Earlier   Later