| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-23 | |||
| 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 | |
| 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 | bauzas | sec | |
| 16:56:19 | sean-k-mooney | dasp: you are correct that orginally we did not | |
| 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 | sean-k-mooney | but ya since queens | |
| 16:58:06 | bauzas | this is 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 | |
| 17:00:34 | bauzas | thanks all | |
| 17:00:36 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.log.html | |
| 17:00:36 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.txt | |
| 17:00:36 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.html | |
| 17:00:36 | opendevmeet | Meeting ended Tue Nov 23 17:00:36 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:36 | bauzas | #endmeeting | |
| 17:01:15 | sean-k-mooney | jhartkopf: so i dont think bauzas or myself are entirly aginst this but the reasons for doing it present sofare in the spec dont fully seam valid | |
| 17:01:27 | bauzas | correct | |
| 17:01:29 | jhartkopf | Well, I understand your concerns. | |
| 17:01:41 | bauzas | copying others isn't enough for me | |
| 17:02:50 | jhartkopf | This was definitely not a copy, as you can see in the implementation. We had a use case internally, which may seem not valid to others. | |
| 17:03:42 | jhartkopf | I don't know if we will put further work into it. | |
| 17:03:50 | sean-k-mooney | jhartkopf: i think you orginally mention NTP servers chanign which i woudl have expected to be pushed out via either vendor data or neutron via dhcp | |
| 17:03:55 | opendevreview | Artom Lifshitz proposed openstack/nova master: DNM: Explode libvirt builds to trigger tempest error code https://review.opendev.org/c/openstack/nova/+/818932 | |
| 17:04:33 | sean-k-mooney | jhartkopf: i do liek the multiple key pairs or updating keypairs usecase | |
| 17:05:15 | sean-k-mooney | so perhaps if we support that it also makes sense to allow updatign the user-datat to allow bootstraping that | |
| 17:05:36 | bauzas | jhartkopf: sorry, didn't wanted to nack, I need to revisite your spec | |
| 17:06:29 | bauzas | jhartkopf: probably understanding which specific instance action you'd like the userdata to be updated, and why, would help | |
| 17:06:57 | sean-k-mooney | bauzas: well without config driver i think its just a server update | |
| 17:06:58 | bauzas | and what would be the benefit for the end user | |
| 17:07:24 | bauzas | sean-k-mooney: that's why I don't want to discuss about the solution yet | |
| 17:07:28 | sean-k-mooney | then its updated in the metadata api so the instance can retirve the new version | |
| 17:07:47 | bauzas | I need to understand the problem that a immutable userdata creaters | |
| 17:07:51 | bauzas | creates* | |
| 17:08:19 | jhartkopf | sean-k-mooney: Maybe, I have to think about that multiple SSH keys use case more. | |
| 17:09:07 | sean-k-mooney | jhartkopf: with your proposal this would also be a replace of the user data right | |