| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-25 | |||
| 13:50:46 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove MIN_LIBVIRT_KVM_AARCH64_VERSION https://review.opendev.org/695901 | |
| 14:08:06 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support live migration with qos ports https://review.opendev.org/695905 | |
| 14:10:32 | mriedem | dansmith: you might want to weigh in on this https://review.opendev.org/#/c/686814/11/nova/network/rpcapi.py | |
| 14:10:52 | mriedem | the client rpc api methods being removed are not called from anywhere, but that add_network_to_project one just looks weird since it never used a version | |
| 14:11:46 | shilpasd | gibi: hi, how i can edit agenda for next nova meeting 'https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting'? | |
| 14:12:55 | gibi | shilpasd: you can edit the wiki and add your item to the agenda. please add your name as well to know who to ping on the meeting | |
| 14:13:24 | gibi | shilpasd: you can add to the Open discussion topic | |
| 14:15:52 | shilpasd | gibi: thanks will check that | |
| 14:16:08 | mriedem | stephenfin: on https://review.opendev.org/#/c/686816/ you remove the nova-network binary but not the actual module code until nova/network/* - is that coming in later changes? | |
| 14:16:17 | mriedem | *under nova/network | |
| 14:16:19 | stephenfin | mriedem: Correct | |
| 14:16:31 | stephenfin | there's a _lot_ of unwinding to be done before I can remove all of that | |
| 14:16:34 | stephenfin | :( | |
| 14:16:55 | mriedem | so basically a lot of small(ish) patches like https://review.opendev.org/#/c/686814/ ? | |
| 14:17:03 | stephenfin | for the most part, yeah | |
| 14:17:09 | stephenfin | currently working on stripping out the firewall feature. That's a beefy one | |
| 14:17:17 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove MIN_QEMU_FILE_BACKED_DISCARD_VERSION https://review.opendev.org/695915 | |
| 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:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-guide: flesh out networking concepts https://review.opendev.org/695777 | |
| 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:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: remove admin/manage-users https://review.opendev.org/695779 | |
| 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 | mriedem | https://bugs.launchpad.net/nova/+bug/1853635 | |
| 14:41:01 | openstack | Launchpad bug 1853635 in OpenStack Compute (nova) "Config_drive file throws Request is too large" [Undecided,New] | |
| 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 | sean-k-mooney | unless you are using boot form cinder volume or confire a different iamge backend like ceph | |
| 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: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 | |