| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 15:51:58 | mriedem | adrianc: if you agree, i'm willing to make that change and then still +2 | |
| 15:52:03 | mriedem | it's just docs and variable naming | |
| 15:58:52 | efried | dansmith, mriedem, gibi: Did we ever settle on the accepted way to add resource/trait/aggregate things via a request_filter so they end up in the GET /a_c request? | |
| 16:00:21 | mriedem | not that i know of, i know gibi posted a patch, | |
| 16:00:30 | mriedem | and my eyes glazed over at the discussion within my multiattach capability trait patch | |
| 16:00:51 | mriedem | for now i'm just shoving a trait in the flavor extra spec on the request spec before it hits the scheduler and making sure the change isn't persisted | |
| 16:00:58 | mriedem | i.e. hitching a ride to scheduler town | |
| 16:01:09 | mriedem | cash, grass, or ... | |
| 16:01:17 | mriedem | no traits ride for free | |
| 16:02:44 | efried | making sure the change isn't persisted? | |
| 16:03:00 | mriedem | RequestSpec.flavor gets persisted | |
| 16:03:17 | efried | so you're adding it to the flavor extra spec until the GET /a_c and then removing it? | |
| 16:03:18 | mriedem | i want to make sure that twiddling RequestSpec.flavor.extra_specs for a one-time scheduler run doesn't get persisted | |
| 16:03:35 | mriedem | nothing is explicitly removing it, | |
| 16:03:45 | mriedem | you reset changes on the object so that when it's saved those changes aren't persisted | |
| 16:03:45 | efried | ...you just aren't saving it | |
| 16:03:49 | efried | okay | |
| 16:05:14 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Delete approved template in move_implemented_specs https://review.opendev.org/592755 | |
| 16:08:49 | jaypipes | mdbooth: what is the primary use case for the volume-update operation? (as opposed to just doing a detach-volume, start-new-instance-elsewhere, attach-volume flow? | |
| 16:10:44 | mriedem | volume live migration and retypes | |
| 16:11:22 | mriedem | for a retype it's a new volume, else it's the same volume on a different backend with the same type (i think) | |
| 16:11:41 | mriedem | https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_swap_volume | |
| 16:13:17 | jaypipes | mriedem: what's the use case though? | |
| 16:13:41 | aspiers | jaypipes wins the Review Of The Week award for a perfect use of a Big Lebowski quote | |
| 16:13:48 | jaypipes | aspiers: yw | |
| 16:14:02 | mriedem | jaypipes: this feels like a trap | |
| 16:14:09 | mriedem | what's the use case for live migration? | |
| 16:14:17 | jaypipes | mriedem: no, I'm honestly curious. | |
| 16:14:30 | jaypipes | mriedem: is volume live migration different from live migration? | |
| 16:14:40 | mriedem | yes | |
| 16:14:45 | mriedem | it's initiated through cinder | |
| 16:14:50 | mriedem | smcginnis: maybe you want to elaborate here ^ | |
| 16:15:15 | jaypipes | mriedem: so this is not an operation a user would ever issue, right? | |
| 16:15:19 | mriedem | https://docs.openstack.org/cinder/latest/admin/blockstorage-volume-migration.html | |
| 16:15:30 | jaypipes | (like instance live migration is not an operation any normal user even knows about) | |
| 16:15:42 | mriedem | for volume migration i think that is correct, it's admin-only by default, | |
| 16:15:48 | mriedem | but retype is admin or owner of the volume aka the user | |
| 16:15:59 | mriedem | https://developer.openstack.org/api-ref/block-storage/v3/?expanded=migrate-a-volume-detail,retype-a-volume-detail#retype-a-volume | |
| 16:16:15 | mriedem | "Change the volume type of existing volume, Cinder may migrate the volume to proper volume host according to the new volume type." | |
| 16:16:27 | mriedem | i think of volume retype like server resize | |
| 16:16:52 | mriedem | by default retyping should not migrate the volume, but the user can override that | |
| 16:17:08 | mriedem | "If the volume is attached to a server instance and will be migrated, then by default policy only users with the administrative role should attempt the retype operation." | |
| 16:17:22 | mriedem | ^ is because the nova swap volume api is admin-only by default | |
| 16:17:25 | mriedem | it's f'ing great | |
| 16:17:31 | jaypipes | hrmph | |
| 16:18:03 | mriedem | so i as a non-admin user could try to retype my attached volume and migrate it which could then blow up b/c nova rejects my non-admin user token passed by proxy from cinder | |
| 16:18:14 | aspiers | efried: when you have a moment, if you can give me some newb pointers about how encrypted_memory=true would be implemented, I can submit a new patch set proposing that | |
| 16:18:24 | mriedem | not sure if cinder has added anything to escalate that token to admin/service user in the last 3 years | |
| 16:19:19 | mriedem | the more sane thing to do would probably be stop the instance, detach the volume, retype it, re-attach and then restart the server | |
| 16:20:14 | jaypipes | or design your application to write to multiple volumes in a replica set instead of one giant panda volume. | |
| 16:20:21 | jaypipes | but I digress. | |
| 16:20:28 | mriedem | my enterprise panda volume is very important and can never go down | |
| 16:20:38 | mriedem | it runs my website visit counter | |
| 16:20:44 | jaypipes | :) | |
| 16:20:58 | jaypipes | new band name: Enterprise Panda Volume. | |
| 16:21:06 | jaypipes | or EPV for the cool kids. | |
| 16:21:08 | mriedem | EPV if you're talking to execs | |
| 16:21:11 | mriedem | yeah :) | |
| 16:21:12 | panda | uh ? | |
| 16:21:13 | jaypipes | :) | |
| 16:21:16 | mnaser | LOL | |
| 16:21:22 | aspiers | there is actually a panda on this channel who is gonna be wondering why they suddenly got a bunch of notifications :-D | |
| 16:21:22 | jaypipes | hahahaha | |
| 16:21:24 | jaypipes | panda: :) | |
| 16:21:36 | aspiers | oh, I was too late | |
| 16:21:38 | panda | can I get back to sleep ? | |
| 16:21:43 | panda | :) | |
| 16:21:47 | aspiers | :) | |
| 16:21:50 | jaypipes | panda: sorry, a "Panda" is a pet virtual machine that can not be killed otherwise it's an international incident :) | |
| 16:22:01 | jaypipes | sorry for waking you! | |
| 16:22:05 | panda | oh my. | |
| 16:23:11 | mriedem | oh it also looks like swap volume will work on root volumes, whereas detach / attach does not (yet) | |
| 16:23:37 | jaypipes | mriedem: yuck. | |
| 16:23:39 | jaypipes | :P | |
| 16:23:46 | aspiers | jaypipes: I guess I need to update my slides https://youtu.be/uMCMDF9VkYk?t=483 | |
| 16:23:46 | panda | nice to know more nice uses of my nick :) | |
| 16:24:29 | jaypipes | aspiers: yes. yes you do. | |
| 16:24:45 | jaypipes | aspiers: and add a Big Lebowski reference while you're at it. | |
| 16:24:52 | aspiers | good plan | |
| 16:40:20 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Add HW_CPU_X86_* traits for Meltdown/Spectre mitigation https://review.opendev.org/655191 | |
| 16:42:12 | openstackgerrit | Merged openstack/nova-specs master: Delete approved template in move_implemented_specs https://review.opendev.org/592755 | |
| 16:45:40 | openstackgerrit | Kashyap Chamarthy proposed openstack/os-traits master: Add CPU traits for Meltdown/Spectre mitigation https://review.opendev.org/655193 | |
| 16:46:41 | kashyap | Any "Traits People", please let me know if I got the above even partly right... | |
| 16:47:34 | efried | aspiers: I was just doing that in the review when I received an interrupt, getting back to it now. | |
| 16:47:51 | aspiers | efried: if it's easier you can just educate me here | |
| 16:48:05 | sean-k-mooney | kashyap: do we need seperate VIRT-SSDB and AMD-SSDB traits | |
| 16:48:13 | aspiers | efried: since I'll probably have questions which the extra round trip latency from Gerrit won't help | |
| 16:48:26 | efried | aspiers: okay, sure. One minute... | |
| 16:48:27 | kashyap | sean-k-mooney: Yes, we do. | |
| 16:48:40 | sean-k-mooney | why? | |
| 16:49:01 | kashyap | sean-k-mooney: Let me quote the upstream QEMU documentation: | |
| 16:49:03 | kashyap | virt-ssbd | |
| 16:49:03 | kashyap | [quote] | |
| 16:49:04 | kashyap | Required to enable the CVE-2018-3639 fix. Not included by default in any AMD CPU model. Must be explicitly turned on for all AMD CPU models. This should be provided to guests, even if amd-ssbd is also provided, for maximum guest compatibility. Note for some QEMU / libvirt versions, this must be force enabled when when using “Host model”, because this is a virtual feature that doesn’t exist | |
| 16:49:10 | kashyap | in the physical host CPUs. | |
| 16:49:13 | kashyap | [/quote] | |
| 16:49:20 | kashyap | Note the: *even if amd-ssbd- is also provided* part. | |
| 16:49:42 | kashyap | sean-k-mooney: They are separate CPU flags, so of course we need separate traits. | |
| 16:49:57 | sean-k-mooney | well we dont that is basically my point | |
| 16:50:04 | kashyap | Oh? | |