| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-03 | |||
| 13:33:22 | efried | yw | |
| 13:44:01 | gibi | stephenfin, efried: I'm +2 on the extra_spec validation spec https://review.opendev.org/#/c/638734 . alex_xu and bauzas had comments earlier. do we want to wait for them to chime in? | |
| 13:44:31 | stephenfin | gibi: alex_xu, sure, but I think bauzas is MIA now since it's summer and he's French | |
| 13:44:58 | gibi | stephenfin: OK, cool with me | |
| 13:46:04 | efried | probably want to get sean-k-mooney to re-ack as well | |
| 13:46:24 | sean-k-mooney | which reivew? | |
| 13:46:30 | efried | he has the medal for most comments in a single review on that one. | |
| 13:46:33 | efried | sean-k-mooney: https://review.opendev.org/#/c/638734 | |
| 13:46:37 | efried | extra spec validation | |
| 13:46:54 | sean-k-mooney | ah ok | |
| 13:47:10 | sean-k-mooney | am ya that is a medal i get a little too often | |
| 13:47:48 | sean-k-mooney | ill quickly re review it now | |
| 13:49:32 | efried | stephenfin: any merit in changing the topic of that spec and its patch (https://review.opendev.org/640733) to ...-extended to match the new bp? | |
| 13:49:48 | efried | I could understand if you want to keep them grouped with the old ones, as currently. | |
| 13:49:51 | efried | either way | |
| 13:49:57 | stephenfin | I'm happy with either too | |
| 13:50:14 | stephenfin | so I'll leave it but won't object if you want to change it :) | |
| 13:50:21 | efried | I only glanced at the number of results https://review.opendev.org/#/q/topic:bp/flavor-extra-spec-image-property-validation+(status:open+OR+status:merged) -- no idea how related/unrelated they actually are. | |
| 13:50:38 | efried | is your work really a continuation of that? | |
| 13:50:55 | stephenfin | To be honest, not really now. It's the same idea but on a broader scale | |
| 13:51:14 | stephenfin | Perhaps I should have a totally different name. Open to suggestions | |
| 13:51:39 | stephenfin | Given that I'm not doing image metadata validation now, a new name would definitely be a good idea | |
| 13:51:40 | efried | Oh, let's not go through the paperwork of changing the blueprint and stuff. | |
| 13:51:54 | efried | but yeah, that's a point | |
| 13:55:02 | sean-k-mooney | cool your going with my stevador suggestion for cyborge extra spec valdaditon or other services. | |
| 13:55:05 | sean-k-mooney | almsot done | |
| 13:55:19 | stephenfin | yeah, it was a good one | |
| 13:57:12 | efried | sean-k-mooney: I saw (but did not read) you discussing image encryption with Luzi. Where are you on that spec? | |
| 13:57:34 | efried | I noticed she added a sentence on (no) impact on lifecycle operations; is that sufficient to address your concern from the previous PS? | |
| 13:58:14 | efried | also lyarwood: are you +1 on that? Your words imply so, but there's no vote. | |
| 13:58:37 | efried | talking about https://review.opendev.org/#/c/608696/ btw | |
| 13:58:47 | sean-k-mooney | efried: nova should create a tempory key on shelve and encypte the snapshot if the instance image was encypted and delete the key when unshelving. same for cross cell resize | |
| 13:58:49 | Luzi | efried, i have to reconsider shelve and cross-cell resize | |
| 13:59:00 | lyarwood | efried: yeah sorry the comments were against an older PS so I couldn't vote | |
| 13:59:15 | efried | okay, cool, thanks all. I'll hold off and wait for a new PS | |
| 13:59:27 | sean-k-mooney | either that or we need to expsoe it on the shelve/resize api endpoint for the end user to decide | |
| 14:00:39 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497 | |
| 14:00:53 | efried | sean-k-mooney, Luzi: But that changes everything. | |
| 14:01:28 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Init HostState.failed_builds https://review.opendev.org/668911 | |
| 14:01:30 | sean-k-mooney | efried: what changes everything? auto encypte or api endpoint or both | |
| 14:01:49 | efried | Auto encrypt: As previously written, you didn't keep track of whether a server was originated from an encrypted image. Now you would have to. | |
| 14:01:49 | efried | API endpoint: now you need a microversion (right?) | |
| 14:02:06 | sean-k-mooney | yes | |
| 14:02:26 | sean-k-mooney | too ^ we would need a microversion | |
| 14:02:44 | sean-k-mooney | not sure about keeping track of if it was encypted | |
| 14:03:01 | sean-k-mooney | i think Luzi said there was a metadta key on the image/instance | |
| 14:03:22 | efried | I thought the spec said we forget about that. | |
| 14:03:27 | sean-k-mooney | i assume it would be in the embeded copy of hte image meta we store in the request spec | |
| 14:04:20 | efried | "...the encryption-related | |
| 14:04:20 | efried | additional metadata properties become irrelevant and thus may be discarded | |
| 14:04:20 | efried | instead of being carried over into the server's metadata." | |
| 14:04:24 | Luzi | efried, i thought so until sean-k-mooney asked me, we misinterpreted the word snapshot | |
| 14:06:05 | efried | I'm on the fence about whether it's better to encrypt automatically or on-demand when doing things involving snapshot. | |
| 14:06:36 | efried | but it seemed reasonable as written (on-demand) | |
| 14:06:45 | efried | and simpler | |
| 14:06:50 | sean-k-mooney | either would be ok. what i dont think is ok would be that shelve and cross cell resize alway result in unencypted snap shots with no way to encyrpte them | |
| 14:07:20 | efried | (cross-cell resize creates a snapshot?) | |
| 14:07:23 | sean-k-mooney | so if we do the microversion bump or auto encypt i think both are fine | |
| 14:07:25 | sean-k-mooney | efried: yes | |
| 14:07:50 | efried | okay | |
| 14:07:52 | sean-k-mooney | efried: for corss cell resize we can rely on direct connectivity to the host | |
| 14:08:22 | efried | if we auto-encrypt, then we should do the same for the already-considered snapshot case (createImage) | |
| 14:08:33 | efried | i.e. it should be symmetrical. | |
| 14:08:41 | Luzi | efried, and that cannot happen | |
| 14:08:46 | efried | but that would require a key... | |
| 14:09:38 | Luzi | because the new key would be generated in nova and is then used in glance, which doesn't delete the key in the case a user deletes the image | |
| 14:09:56 | openstackgerrit | Lee Yarwood proposed openstack/nova master: block_device: Optionally recreate attachments when refreshing connection_info https://review.opendev.org/579004 | |
| 14:10:18 | efried | Luzi: I assume saving the *original* key with the server metadata is a nonstarter. | |
| 14:10:43 | efried | like taping your car keys to the fender | |
| 14:11:17 | Luzi | well the key could have been deleted at the point | |
| 14:11:26 | sean-k-mooney | Luzi: how? | |
| 14:11:34 | Luzi | because it was just tied to the original image | |
| 14:11:52 | stephenfin | Newb question: when I'm told to delay string interpolation by doing "LOG.warning('foo %s', 'bar')" instead of "LOG.warning('foo %s' % 'bar')", what actually resolves that? | |
| 14:11:53 | sean-k-mooney | dose the instance not have a key associated to it | |
| 14:12:05 | stephenfin | Is it a feature of the logging library | |
| 14:12:11 | Luzi | if the original image is deleted, the key can be deleted too | |
| 14:12:14 | sean-k-mooney | fo use in its encyped ephmeral disk | |
| 14:12:22 | stephenfin | or the translation framework? | |
| 14:12:57 | Luzi | but that would only be the case if we use a backend which supports ephemeral storage encryption | |
| 14:13:10 | sean-k-mooney | ah right | |
| 14:13:30 | Luzi | ceph right now doesn't - maybe a nice thing to look for in the future :D | |
| 14:13:32 | stephenfin | I ask because we appear to be delaying interpolation here but I didn't that was supported for exceptions https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5842-L5847 | |
| 14:13:38 | stephenfin | So I'm guessing it's a minor bug | |
| 14:14:04 | sean-k-mooney | yes native encyption fo ceph rbds would be nice at somepoint | |
| 14:14:06 | efried | stephenfin: yes that looks like a bug | |
| 14:14:17 | stephenfin | okay, phew. I'll fix | |
| 14:16:13 | sean-k-mooney | Luzi: efried so if we cant make auto encyption symetric for normal snapshoting those that make it a non starter in your minds | |
| 14:17:10 | sean-k-mooney | i would personlally prefer teh asymatry to give a better user experince and be secure by defualt | |
| 14:17:17 | efried | stephenfin: http://paste.openstack.org/show/753821/ | |
| 14:17:56 | efried | your exception message winds up being a %s-ification of a tuple of a string and a dict. | |
| 14:18:01 | stephenfin | efried: I did the exact same thing :) However, I wasn't sure if the i18n marker changed things | |
| 14:18:21 | efried | oh, definitely not, it returns a string | |
| 14:18:27 | efried | The marker can't see the stuff after the comma. | |
| 14:18:54 | stephenfin | Sweet, so it is logging that does the delayed interpolation. Good to know I hadn't been mistaken all these years, heh | |
| 14:19:36 | efried | yes, logging does delayed, because it's conditional. The exception is always happening (if you get to that point), so there's no reason to delay anything. | |
| 14:35:31 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove MIN_{QEMU,LIBVIRT}_LUKS_VERSION https://review.opendev.org/668924 | |
| 14:36:05 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497 | |
| 14:39:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Translatable output strings in heal allocation https://review.opendev.org/668925 | |
| 14:51:20 | adrianc | stephenfin, efried, thanks for taking the time to review | |
| 14:51:20 | adrianc | [FUP] Follow-up patch for SR-IOV live migration | |