| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-25 | |||
| 14:19:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-guide: flesh out networking concepts https://review.opendev.org/695777 | |
| 14:19:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-guide: flesh out flavor extra specs and image properties https://review.opendev.org/695776 | |
| 14:19:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: remove admin/manage-users https://review.opendev.org/695779 | |
| 14:19:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-guide: flesh out todos in user doc https://review.opendev.org/695778 | |
| 14:19:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-guide: remove empty sections about inter-service interactions https://review.opendev.org/695774 | |
| 14:38:59 | mriedem | anyone remember where the hard 64kib limit on injected_file_content_bytes is enforced? | |
| 14:39:38 | dansmith | mriedem: isn't it on the implied size of the text field in the db? | |
| 14:39:45 | mriedem | i guess i was thinking user_data | |
| 14:39:50 | mriedem | https://docs.openstack.org/nova/latest/user/metadata.html#metadata-userdata | |
| 14:39:56 | dansmith | oh right right | |
| 14:41:01 | openstack | Launchpad bug 1853635 in OpenStack Compute (nova) "Config_drive file throws Request is too large" [Undecided,New] | |
| 14:41:01 | mriedem | https://bugs.launchpad.net/nova/+bug/1853635 | |
| 14:41:04 | mriedem | was trying to triage that | |
| 14:44:32 | sean-k-mooney | we have a downstream bug for that i think that got reported like 2 weeks ago | |
| 14:44:42 | sean-k-mooney | ill see if i can find it | |
| 14:46:34 | sean-k-mooney | artom: you were looking at ^ with dvd or dhill 2 weeks ago right | |
| 14:48:37 | artom | sean-k-mooney, it rings a bell | |
| 14:48:52 | artom | With dhill, though I don't know how that ended | |
| 14:48:57 | artom | The logging made no sense | |
| 14:49:08 | artom | It was a 413, but no other details in the API logs | |
| 14:49:12 | artom | Which were in debug | |
| 14:49:23 | artom | So it made me think maybe a middleware somewhere was doing it | |
| 14:49:42 | artom | And I think efried as kind enough to offer to help since he had played with paste | |
| 14:49:48 | artom | ... and then we all forgot about it | |
| 14:49:56 | sean-k-mooney | i think we found a place where there awas a hardcoded limit | |
| 14:50:32 | efried | still happy to help there, lmk what you need | |
| 14:50:41 | artom | efried, ack, appreciated :) | |
| 14:50:55 | artom | Though at this point we're still speculatively rambling, methinks | |
| 14:53:12 | sean-k-mooney | i cant find it in my history or via BZ so i dont know if i still have the data on it | |
| 14:53:41 | artom | sean-k-mooney, did he ever actually file a bz though? | |
| 14:53:44 | artom | I'll ask | |
| 14:54:02 | sean-k-mooney | maybe not that could be why i cant find it | |
| 14:55:51 | fungi | quick question, mhen mentioned in the image encryption pop-up team meeting an hour ago that during the ptg some nova folks were discussing the spec reproposal with luzi and suggested that they wanted someone to fix ephemeral disk encryption to use luks before adding image encryption support. this is all third-hand so i'm sure i'm missing a bunch of details, but curious if anyone can fill in the gaps | |
| 14:55:53 | fungi | there (the two features don't, at face value, seem to be directly related to one another) | |
| 14:55:56 | fungi | http://eavesdrop.openstack.org/meetings/image_encryption/2019/image_encryption.2019-11-25-13.00.log.html | |
| 14:56:29 | sean-k-mooney | fungi: you want to speak to mdbooth | |
| 14:57:05 | fungi | ahh, so he's working on overhauling ephemeral disk encryption in nova? | |
| 14:57:13 | sean-k-mooney | fungi: mdbooth wanted epmeral disk encryption to be a prequisite for image encryption | |
| 14:57:33 | sean-k-mooney | im not sure if he is working on it or not | |
| 14:57:43 | fungi | got it. does nova use the ephemeral disk subsystem for caching images? | |
| 14:57:51 | fungi | i'm just trying to understand the interrelationship | |
| 14:58:12 | sean-k-mooney | but he felt strongly that have enycpeted image in galce that were stored in non encyped form on the hypervior was not very useful | |
| 14:58:55 | fungi | so you're saying the images when they get stored on the hypervisor use the ephemeral disk mechanism? | |
| 14:59:32 | sean-k-mooney | in the libvirt case the root disk is storead as a qcow or raw file on the host by defualt | |
| 14:59:56 | sean-k-mooney | with both a cache of the iamge and a backing file in the qcow case | |
| 15:00:03 | fungi | so what does that have to do with the ephemeral disk feature? | |
| 15:00:04 | mriedem | stephenfin: on https://review.opendev.org/#/c/686814/ i tend to think you should just leave the server-side manager stuff alone and leave that for some change at the end of that series where you delete it in a single change | |
| 15:00:12 | mriedem | stephenfin: everything else is just deleting client-side code | |
| 15:00:21 | mriedem | not sure how dansmith feels about that strategy or if it's worthwhiel | |
| 15:00:23 | mriedem | *worthwhile | |
| 15:00:41 | sean-k-mooney | fungi: well qemu cannot execute from a gpg encryped imagae as far as i am aware | |
| 15:00:44 | dansmith | mriedem: ++ | |
| 15:00:57 | sean-k-mooney | fungi: so you would have to decrypt it on the host to be able to boot the vm | |
| 15:01:17 | fungi | sean-k-mooney: got it, so the idea was to decrypt into an encrypted ephemeral disk and then boot that? | |
| 15:01:40 | stephenfin | mriedem, dansmith: what about other changes where there's call to things like virt driver methods? | |
| 15:01:43 | sean-k-mooney | fungi: yes using qemus nataive luks support | |
| 15:02:02 | dansmith | stephenfin: those would be from server methods, so during/after those are removed? | |
| 15:02:30 | sean-k-mooney | fungi: so that you dont have to us dmcrype or something lease hat would mount the disk and decypte it via the kernel | |
| 15:02:48 | stephenfin | um, can you say that again but differently? | |
| 15:02:51 | fungi | sean-k-mooney: so just to make sure i understand the interrelationship, nova boots images from ephemeral disks? or the plan would be to add booting from ephemeral disk? | |
| 15:03:44 | mriedem | fungi: if luks is involved i'd ask lyarwood | |
| 15:03:50 | sean-k-mooney | fungi: by defualt with libvirt nova boots all image from epheral root disk in qcow or raw format | |
| 15:04:17 | fungi | mriedem: well, sounds like luks isn't involved today with ephemeral disks, and that's apparently the objection/prerequisite which was raised | |
| 15:04:17 | sean-k-mooney | unless you are using boot form cinder volume or confire a different iamge backend like ceph | |
| 15:04:56 | sean-k-mooney | fungi: right today we dont support booting with encryped root disk excpu vai that lvm driver i belvie | |
| 15:05:01 | sean-k-mooney | and that has other issues | |
| 15:06:12 | fungi | sean-k-mooney: got it, thanks, so the idea is that for non-boot-from-volume scenarios, to make sure we don't store the retrieved image unencrypted, the ephemeral disk mechanism needs to support an encryption container format which qemu can boot directly | |
| 15:06:31 | sean-k-mooney | fungi: yep | |
| 15:06:43 | fungi | perfect, that was the missing connection for me. thanks!!! | |
| 15:06:51 | sean-k-mooney | the current encyped image support declared that out of scope | |
| 15:07:19 | sean-k-mooney | but mdbooth and lyarwood wanted to make it a prerequsite even though its another feature | |
| 15:07:32 | fungi | right, unfortunately i think due to their limited bandwidth they're going to focus on boot-from-volume for now and revisit support in nova later | |
| 15:07:43 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Improve metadata server performance with large security groups https://review.opendev.org/695925 | |
| 15:08:09 | sean-k-mooney | fungi: my understading is cidner does not currently support booting form an encyped volume either | |
| 15:08:34 | fungi | right, but they're up for moving forward on the spec to add that | |
| 15:08:36 | sean-k-mooney | fungi: mdbooth mentioned somting about that being inded for cinder backups but nova vms | |
| 15:08:58 | sean-k-mooney | *intended | |
| 15:09:15 | fungi | ahh, i'll take a closer look at the cinder spec to confirm | |
| 15:09:16 | sean-k-mooney | *not for nova vms | |
| 15:09:26 | fungi | thanks again | |
| 15:09:35 | lyarwood | sean-k-mooney: we can boot from an encrypted volume | |
| 15:10:21 | sean-k-mooney | lyarwood: ok but is that only with ceph | |
| 15:10:34 | lyarwood | and yeah, we need to kill off the existing ephemeral disk encryption support in the Libvirt driver before we reintroduce a sane version tbh | |
| 15:10:36 | sean-k-mooney | with isci the volume wouls be mounted on the host | |
| 15:10:40 | lyarwood | sean-k-mooney: nope, that's pretty much any backend | |
| 15:10:47 | lyarwood | sean-k-mooney: nope, that's native | |
| 15:11:02 | lyarwood | sean-k-mooney: native allowed us to support rbd encrypted volumes for the first time | |
| 15:11:19 | lyarwood | sean-k-mooney: everything else was already supported and just switched to being native within QEMU in Queens | |
| 15:11:32 | sean-k-mooney | lyarwood: ok | |
| 15:12:07 | aarents | mriedem: hi, can you confirm that commit message is ok like tht https://review.opendev.org/#/c/670000/ it was the last blocking point. | |
| 15:12:20 | sean-k-mooney | but we do still mont the voluems on the host via the kernel right they are just but encypeted? | |
| 15:12:29 | sean-k-mooney | lyarwood: im asking because fo the local caching spec | |
| 15:13:31 | sean-k-mooney | that was implying that iscsi based volumes are mounted on the host and passed to qemu as a block deice wo they could add a caching layer | |
| 15:13:55 | lyarwood | sean-k-mooney: yeah so for iSCSI/LVM etc we still end up with host devices but these are never decrypted on the host now | |
| 15:14:04 | sean-k-mooney | i assume we use qemus native encryption support to use the encyped volumes form teh host | |
| 15:14:13 | sean-k-mooney | cool | |
| 15:14:46 | sean-k-mooney | fungi: so basicly we would like to get to the same state for non boot form volume guests | |
| 15:18:38 | mriedem | lyarwood: do we even have *any* in-tree docs about encryption features in nova today? | |
| 15:18:56 | mriedem | would probably be good to level set from there | |
| 15:19:23 | lyarwood | mriedem: do releasenotes count /s | |