| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 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 | jaypipes | hahahaha | |
| 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: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 | panda | nice to know more nice uses of my nick :) | |
| 16:23:46 | aspiers | jaypipes: I guess I need to update my slides https://youtu.be/uMCMDF9VkYk?t=483 | |
| 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 | [quote] | |
| 16:49:03 | kashyap | virt-ssbd | |
| 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? | |
| 16:50:14 | kashyap | sean-k-mooney: What do you mean? | |
| 16:50:28 | sean-k-mooney | there does not need to be a 1:1 mapping between tratis adn cpus flags | |
| 16:50:39 | sean-k-mooney | the traits dont impact the xml generation | |
| 16:50:56 | sean-k-mooney | so for the tratis we need to think about whgat we schdule on | |
| 16:50:56 | kashyap | Please comment in the review; I need to leave the library. It's closing | |
| 16:51:07 | sean-k-mooney | sure will do | |
| 16:51:09 | kashyap | Much appreciated | |
| 16:51:23 | artom | What's the ? at the beginning of https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/devstack/tempest-dsvm-lvm-rc#L33 ? | |
| 16:51:38 | artom | 'r="^(?!.*"' | |
| 16:51:48 | artom | I thought I groked regex, but this confuses me. | |
| 16:52:04 | artom | ? would mean 0 or 1, right? So... "maybe a (" ? | |
| 16:52:08 | artom | But... why? | |
| 16:52:11 | aspiers | that's a negative look-ahead assertion | |
| 16:53:01 | aspiers | (?!foo.*bar) means "foo.*bar can't come next" | |
| 16:53:26 | efried | ..."but don't capture it" | |
| 16:53:30 | aspiers | right | |
| 16:53:42 | aspiers | it's one of the more obscure features of pcre, been around since Perl 5 days though | |
| 16:53:51 | artom | Ah, I was reading it as a quantifier | |
| 16:53:54 | artom | Thanks aspiers | |
| 16:53:59 | aspiers | https://xkcd.com/208/ is the obvious reference here | |
| 16:54:16 | artom | *snerk* | |
| 16:54:40 | artom | More like https://xkcd.com/1171/ | |
| 16:54:53 | aspiers | hahahaha | |