| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 21:37:01 | efried | right, but "using encrypted storage backends" is not part of this spec | |
| 21:37:06 | efried | that's already supported | |
| 21:38:29 | sean-k-mooney | right but that means on the host the iamge is still encrypted as its streamed into an encpted file | |
| 21:39:12 | sean-k-mooney | so when you do a nova rescue and you boot form a different image you still need to pass the encyption key to qemu so it can open that encypted file a use it | |
| 21:39:26 | efried | Not "still encrypted". decrypted to clear, then re-encrypted with a different key (and possibly a different algorithm, etc) | |
| 21:40:09 | efried | so yes, *if* your storage backend is encrypted, regardless of whether you're using *image* encryption (this feature), then you'll need to manage slinging keys around. | |
| 21:40:15 | sean-k-mooney | the decypted to clear happens in memory. but when i was referign to still encrypted i ment after it was re encrypted | |
| 21:40:31 | efried | I'm saying they're separate and unrelated. | |
| 21:40:33 | sean-k-mooney | ok so long as that all works that is cool | |
| 21:40:39 | efried | I think | |
| 21:40:50 | sean-k-mooney | i just was suprised that it was never mention in the spec | |
| 21:43:44 | sean-k-mooney | i could cahcne my +1 to a -1 i guess until josephine seifert replies to confirm but i whould have expect this to at least be mentioned in the spec if all it was is "it jsut works" | |
| 22:12:27 | mriedem | dansmith: you know how this set_host_enabled is a blocking rpc call? if this is an ironic compute service managing 1000 compute nodes (1000 resource providers) and we have to sync the trait on all of them, i'm not sure if that would take more than 60 seconds but it might - thinking this change should use the long_rpc_timeout for that call now - agree? | |
| 22:21:27 | mriedem | weee looks like the gate is crapping itself too atm | |
| 22:23:00 | openstackgerrit | Merged openstack/nova-specs master: Policy Default Refresh spec https://review.opendev.org/547850 | |
| 22:26:24 | dansmith | mriedem: yeah makes sense to make it a long rpc call | |
| 22:26:55 | dansmith | mriedem: even for the single compute case, if placement is bogged or something, we could still take a while to set the trait | |
| 22:31:13 | openstackgerrit | Merged openstack/nova stable/queens: Restore connection_info after live migration rollback https://review.opendev.org/662471 | |
| 22:35:54 | mriedem | melwitt: can you hit this remaining queens backport? https://review.opendev.org/#/c/629597/ | |
| 22:47:51 | openstackgerrit | Merged openstack/nova-specs master: Spec: Use OpenStack SDK in Nova https://review.opendev.org/662881 | |
| 22:50:06 | sean-k-mooney | heh if only the rest of the repo had a 10 minute merge trun around time | |
| 23:06:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Sync COMPUTE_STATUS_DISABLED from API https://review.opendev.org/654596 | |
| 23:07:15 | mriedem | it is done https://review.opendev.org/#/q/topic:bp/pre-filter-disabled-computes+(status:open+OR+status:merged) | |
| 23:08:23 | openstackgerrit | Merged openstack/nova-specs master: Libvirt: add vPMU spec for train https://review.opendev.org/651269 | |
| 23:09:25 | sean-k-mooney | mriedem: as in you have split it out int different patches and its now ready for review? | |
| 23:09:33 | mriedem | hells yeah | |
| 23:09:37 | mriedem | it's glorious | |
| 23:10:16 | sean-k-mooney | cool im poking at similar code for my own prefilter stuff so ill see if ther are any trick i shoudl "borrow" form my onw stuff | |
| 23:10:58 | sean-k-mooney | mriedem: did you drop the custom trait stuff since os-tratis 1.15 is released | |
| 23:11:03 | mriedem | yes | |
| 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 :) | |