| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 23:11:08 | mriedem | technically efried did that for me | |
| 23:11:21 | sean-k-mooney | cool | |
| #openstack-nova - 2019-07-03 | |||
| 00:40:10 | melwitt | alex_xu: hey, would appreciate to have your thoughts on the unified limits spec around the proxy API/deprecation and migration parts https://review.opendev.org/602201 | |
| 00:40:36 | melwitt | *especially the proxy API/deprecation and migration parts | |
| 00:45:24 | openstackgerrit | Merged openstack/nova stable/rocky: Init HostState.failed_builds https://review.opendev.org/668520 | |
| 00:45:31 | openstackgerrit | Merged openstack/nova master: Stabilize unshelve notification sample tests https://review.opendev.org/668675 | |
| 01:21:45 | openstackgerrit | Merged openstack/nova stable/queens: Fail to live migration if instance has a NUMA topology https://review.opendev.org/629597 | |
| 02:06:59 | openstackgerrit | Merged openstack/nova stable/queens: libvirt: Avoid using os-brick encryptors when device_path isn't provided https://review.opendev.org/656464 | |
| 06:17:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] Introduce live_migration_claim() https://review.opendev.org/635669 | |
| 06:17:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827 | |
| 06:17:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.opendev.org/634828 | |
| 06:17:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.opendev.org/635229 | |
| 06:17:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605 | |
| 06:17:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 06:17:05 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: CONF.enable_numa_live_migration is not needed >= Train https://review.opendev.org/640021 | |
| 07:02:59 | openstackgerrit | Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.opendev.org/621476 | |
| 07:25:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/stein: Stabilize unshelve notification sample tests https://review.opendev.org/668806 | |
| 07:34:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Get rid of args to RBDDriver.__init__() https://review.opendev.org/668564 | |
| 07:52:02 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove unreachable native QEMU iSCSI initiator config code https://review.opendev.org/668750 | |
| 08:37:32 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.opendev.org/649963 | |
| 08:47:40 | kashyap | johnthetubaguy: You about by any chance? If so, the Secure Boot spec requires the final +2 (& a +W), assuming you're satisfied with all the things I've addressed: https://review.opendev.org/#/c/506720/ | |
| 09:57:28 | kashyap | alex_xu: Hi, maybe you can give the final ACK (if you don't spot anything else): https://review.opendev.org/649963 | |
| 11:23:34 | openstackgerrit | Josephine Seifert proposed openstack/nova-specs master: Spec for the Nova part of Image Encryption https://review.opendev.org/608696 | |
| 11:26:32 | Luzi | sean-k-mooney, I added a few sentences concerning the lifecycle | |
| 11:56:30 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 11:56:31 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: CONF.enable_numa_live_migration is not needed >= Train https://review.opendev.org/640021 | |
| 12:37:45 | sean-k-mooney | Luzi: thanks ill re review but overall i liked the spec | |
| 12:41:55 | sean-k-mooney | Luzi: so all server operations like shelve,rescure, mirgrations will all work | |
| 12:42:04 | Luzi | yes | |
| 12:43:01 | sean-k-mooney | and for shelve if the instance is create form an encypted image teh snapshot that is created automaticly by shelve will be encrypted | |
| 12:46:34 | Luzi | I will have a deeper look into this, but we only wanted to create encrypted images when a user triggers the encryption | |
| 12:47:43 | sean-k-mooney | without a change to the shelve api the user would not be able to say use encyption since for shvele and cross cell resize a snapshot is created automatically | |
| 12:48:05 | sean-k-mooney | rather then the user calling the snapshot api directly | |
| 12:48:50 | sean-k-mooney | so we would really want the encyption to be sticky. e.g. if the instacne was created form an encypeted image defult to encyption | |
| 12:52:47 | Luzi | well it seems there are three options here: | |
| 12:53:26 | Luzi | 1. leaving this alone, so there would not be any encryption during shelve | |
| 12:53:46 | Luzi | 2. automaticly encryption - which is a huge problem for glance, btw... | |
| 12:54:52 | Luzi | or 3. let the user trigger the encryption (and maybe deny the operation, when the original image was encrypted) | |
| 12:55:43 | Luzi | the last one would need a metadata change, so we can check, whether the snapshot could be taken without encryption | |
| 12:55:57 | Luzi | but it seems to be the most reasonable way | |
| 12:56:56 | sean-k-mooney | well if we do 1 if i wanted to steal you sensitive data all i have to do is shelve you instnace grap a copy of the snapshot which is in the clear and unshelve it | |
| 12:57:09 | Luzi | there was a misunderstanding here with the word snapshot, so thank you for the hint | |
| 12:57:20 | Luzi | yeah, thats not nice from a security perspective :D | |
| 12:57:37 | sean-k-mooney | 2 and 3 are the most secure | |
| 12:58:10 | sean-k-mooney | the issue with 3 woudl be that its would be fine for shelve to be exteded with a "encypte this please" option | |
| 12:58:22 | sean-k-mooney | resize im less sure about | |
| 12:58:52 | Luzi | 2 would not be practically as automatically creating secrets for a ressource of another project is horrible | |
| 12:58:56 | sean-k-mooney | for resize we only create a snapshot if its a cross cell resize | |
| 12:59:20 | sean-k-mooney | a normal resize wont create a snapshot | |
| 12:59:29 | Luzi | so i will add number three in the spec and will have a look into resize too | |
| 12:59:38 | sean-k-mooney | and as an unprivaldaged user i cant tell if its cross cell or not | |
| 13:00:10 | Luzi | thank you, that was reasonable the best review I got so far :D | |
| 13:01:10 | sean-k-mooney | :) well hopefully we can get this landed soon. as i said the rest of the spec looks good to me | |
| 13:02:13 | sean-k-mooney | just to undersdand the problem with option 2, what is the issue with createing keys automatically | |
| 13:02:52 | sean-k-mooney | i had assumed we would use the same key we are currently using | |
| 13:03:23 | sean-k-mooney | rather then create a new one but i also have not considered it much | |
| 13:03:37 | Luzi | who will delete a newly created key bound to an image? | |
| 13:04:17 | Luzi | well if its not exactly the same image anymore, would you encrypt it with the same key? | |
| 13:04:47 | sean-k-mooney | well for shelve we delete the image we created when unshelving | |
| 13:05:20 | Luzi | so there would be a point for nova to create and delete a key, that would be okay | |
| 13:05:25 | sean-k-mooney | and for cross cell resize we auto delete teh image snapthot when we create the instnace on the dest node | |
| 13:05:26 | sean-k-mooney | so nova | |
| 13:06:01 | sean-k-mooney | yes in both cases nova could create a temperoy key and it could delete it at the correct time | |
| 13:06:02 | Luzi | i know that discussion from cinder and glance, there cinder creates a key which glance has to delete - that is not a good practise | |
| 13:06:51 | sean-k-mooney | right that is messy | |
| 13:07:36 | Luzi | sean-k-mooney, that seems good from my perspective, so automatic key creation for shelve and cross-cellresize, given a metadata parameter indicating a formerly encrypted image | |
| 13:08:06 | sean-k-mooney | yep and if that metadata paramter is not set just do what we do today | |
| 13:08:17 | Luzi | yes | |
| 13:08:25 | sean-k-mooney | so you can make it complete transparent to the end user and no api changes needed | |
| 13:09:37 | Luzi | that sounds good, I will add this to the spec :) | |
| 13:16:16 | lyarwood | mdbooth: https://review.opendev.org/#/c/668750/ - thoughts on this? Came across it last night while looking at upstream bugs and suddenly noticed this codepath is dead. We could just keep it but it hasn't been tested in ~3 years so it might be easier to start over with a clean volume driver. | |
| 13:18:18 | mdbooth | lyarwood: Hmm. It doesn't sound like we're going to implement native iscsi any time soon, tbh, due to lacking multipath and no upstream motivation to implement it. | |
| 13:18:35 | mdbooth | Making this just dead code which isn't like to be used any time soon. | |
| 13:18:42 | mdbooth | And which probably doesn't work anyway. | |
| 13:19:51 | mdbooth | lyarwood: Is os-brick based iscsi problematic? | |
| 13:20:42 | lyarwood | mdbooth: it has some rough edges wrt to multipath etc but the basic single path stuff also covered by this native support is QEMU is pretty solid | |
| 13:20:53 | lyarwood | s/is/in/g | |
| 13:21:23 | lyarwood | so yeah I'm fine nuking this for now and if anyone cares enough we can reintroduce it later in a broken out volume driver | |
| 13:21:30 | lyarwood | and have it actually tested in the gate etc | |
| 13:21:41 | mdbooth | lyarwood: +1 from me for nuking unusable code | |
| 13:22:21 | lyarwood | ack thanks | |
| 13:25:54 | shilpasd | efried: Hi, need discussion on https://review.opendev.org/#/c/667952/1/nova/conf/scheduler.py@188 | |
| 13:26:07 | efried | Sure shilpasd | |
| 13:26:29 | efried | I'm sure we must have discussed this during the spec review | |
| 13:26:30 | shilpasd | here saying 'enable_forbidden_aggregates_filter' conf option bydefault enabled | |
| 13:26:46 | efried | It must be about the performance penalty. | |
| 13:26:54 | shilpasd | efried: but what we observed for other request filters, its not so | |
| 13:27:33 | efried | Well, this one is doing a pretty expensive db lookup every time. The other filters are (I think) exclusively local processing. | |
| 13:27:48 | efried | Have you done any kind of performance analysis of this filter? | |
| 13:27:54 | efried | especially on a large database with lots of aggregates | |
| 13:28:39 | shilpasd | efried: not on that large scale | |
| 13:29:13 | efried | dansmith: you were also concerned about the performance of this filter. | |
| 13:30:14 | efried | Having thought about it some, we're better off being conservative unless we can demonstrate that the db lookup is super cheap. | |
| 13:30:25 | efried | So - leave the conf option as is shilpasd :) | |
| 13:30:30 | efried | I'll update the review. | |
| 13:31:07 | sean-k-mooney | efried: i think all the prefilters default to false so for consitency i would keep it as false too | |
| 13:31:21 | shilpasd | efried: great, thank you, we are keeping it as False | |
| 13:31:24 | sean-k-mooney | at least until we have info from deploymetns that its cheap and works well | |
| 13:31:56 | efried | sean-k-mooney: In this case I was suggesting that we remove the toggle entirely. You have to do enough other stuff to opt in, the only benefit you get by having it switched off is that you don't run the code. | |
| 13:32:05 | shilpasd | sean-k-mooney: thank you for opinion | |