| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-06-10 | |||
| 03:45:21 | opendevreview | melanie witt proposed openstack/nova master: Support create with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870932 | |
| 03:45:22 | opendevreview | melanie witt proposed openstack/nova master: Clean up unused ephemeral encryption libvirt secrets https://review.opendev.org/c/openstack/nova/+/919990 | |
| 03:45:22 | opendevreview | melanie witt proposed openstack/nova master: Validate key manager create access in API https://review.opendev.org/c/openstack/nova/+/919989 | |
| 03:45:23 | opendevreview | melanie witt proposed openstack/nova master: Support (resize|cold migration) with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870933 | |
| 03:45:23 | opendevreview | melanie witt proposed openstack/nova master: libvirt: "Auto heal" ephemeral encryption secrets on guest launch https://review.opendev.org/c/openstack/nova/+/919991 | |
| 03:45:24 | opendevreview | melanie witt proposed openstack/nova master: Support live migration with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/905512 | |
| 03:45:25 | opendevreview | melanie witt proposed openstack/nova master: Add Glance standardized encryption image properties https://review.opendev.org/c/openstack/nova/+/921345 | |
| 03:45:25 | opendevreview | melanie witt proposed openstack/nova master: Support rebuild with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870939 | |
| 03:45:26 | opendevreview | melanie witt proposed openstack/nova master: Add encryption support to qemu-img rebase https://review.opendev.org/c/openstack/nova/+/870936 | |
| 03:45:26 | opendevreview | melanie witt proposed openstack/nova master: Support encrypted source images for qcow2 https://review.opendev.org/c/openstack/nova/+/919992 | |
| 03:45:28 | opendevreview | melanie witt proposed openstack/nova master: Support encrypted backing files for qcow2 https://review.opendev.org/c/openstack/nova/+/907961 | |
| 03:45:28 | opendevreview | melanie witt proposed openstack/nova master: Add backing_encryption_secret_uuid to BlockDeviceMapping https://review.opendev.org/c/openstack/nova/+/907960 | |
| 03:45:30 | opendevreview | melanie witt proposed openstack/nova master: Support snapshot with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870937 | |
| 03:45:30 | opendevreview | melanie witt proposed openstack/nova master: Support rescue with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/873675 | |
| 03:45:32 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for raw with LUKS https://review.opendev.org/c/openstack/nova/+/884313 | |
| 03:45:32 | opendevreview | melanie witt proposed openstack/nova master: Support cross cell resize with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/909595 | |
| 11:11:51 | sahid | 13:09 < sahid> o/ | |
| 11:11:54 | sahid | 13:10 < sahid> regarding placement, is there a way to make the in_tree query using POST instead of GET? | |
| 11:11:57 | sahid | 13:10 < sahid> we are using routed provider network, which create many aggregates per hosts | |
| 11:12:00 | sahid | 13:11 < sahid> we are in that situation where the URI is too long when calling an placement API with request that use in_tree | |
| 11:12:05 | sahid | bauzas: perhaps you have some idea | |
| 11:50:33 | sahid | hum in same time using POST does not look right in an API's point of view | |
| 11:50:56 | sahid | we can perhaps improve nova to batch requests | |
| 12:49:41 | sean-k-mooney | sahid: in general no | |
| 12:50:28 | sean-k-mooney | we had discussed moving the query form the uri to a post boday a long time ago but there was resitance to doing that | |
| 13:00:15 | bauzas | sahid: sorry, have a flapping network for now | |
| 13:01:04 | sean-k-mooney | sahid: unless your hitting the RFC spec limit on a uri, which i think is 64k you are likely hitting a limit in your loadbalancer or webserver | |
| 13:01:13 | sean-k-mooney | so that is what i woudl try adjusting first | |
| 13:01:39 | sean-k-mooney | sahid: api changes are not backporatbale and allowing an alternitive way to query palcyement would be an api change | |
| 13:02:18 | sean-k-mooney | so for your current deployment that is really the only option aviable (adjust the limit in your loadbalabcer/webserver) or reduce the number of network segments | |
| 13:08:43 | sahid | sean-k-mooney: yes thank you it's basically on what we are currently working | |
| 13:09:10 | sahid | in same time i'm going to impl fix for our current release, I'm not sure that is going to change the API | |
| 13:09:44 | sean-k-mooney | what kind of fix | |
| 13:10:19 | sean-k-mooney | modifying the qurey size limit is valid but modifing the call to placement would be ill advised | |
| 13:11:14 | sahid | yes rights, give me a moment I'm going to share it with you | |
| 13:11:37 | sean-k-mooney | batching request is also proably hnot someting we woudl do in nova | |
| 13:11:56 | sean-k-mooney | that has performance and correctness issues | |
| 13:12:50 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: scheduler: fix _get_sharing_providers to support unlimited aggr https://review.opendev.org/c/openstack/nova/+/921665 | |
| 13:13:25 | sahid | sean-k-mooney: i guess but you also want to handle enviroment that scale | |
| 13:15:48 | sean-k-mooney | sure but in general we would not expec there to be more hten a hand ful of network segments per neutorn providree network and more then a hand full of ports per vm | |
| 13:16:20 | sean-k-mooney | i.e. 5 segments per network and 5 port per vm for 25 ish uuids max for a large vm/deployment | |
| 13:16:37 | sean-k-mooney | you can have more but i would think that is very atypical | |
| 13:17:48 | sahid | sean-k-mooney: with rpn you can't have more than one physnet attached to a segment for a given network, that means if you want to have small broadcast domain you have to have lot of networks | |
| 13:18:09 | sahid | I have fixed that missing in neutron, but it's only available start to zed | |
| 13:19:00 | sean-k-mooney | yes having lots of network is intened apprch | |
| 13:19:07 | sahid | for each host, you have an agregate related that is created by neutron | |
| 13:19:10 | sean-k-mooney | not one large network with lots of segments | |
| 13:19:24 | sahid | to ensure the vm is schedule on a host that handle the requested physnet | |
| 13:19:26 | sean-k-mooney | you do not have 1 aggreate per host | |
| 13:20:04 | sean-k-mooney | you have one aggrate per network segment and all hosts on the relevent phsynet related to the segment are added to that aggreate | |
| 13:20:05 | sahid | you have a aggregate for each segments, (sorry) | |
| 13:20:36 | sean-k-mooney | this is a know design limiattion with segment by the way | |
| 13:20:37 | sahid | if you have 100 networks and two physnet per networks, you hqve 200 aggregates | |
| 13:20:49 | sean-k-mooney | i orgially tried to have neutron not sue physnest for that mapping | |
| 13:20:54 | sahid | sean-k-mooney: yes fixed for zed | |
| 13:21:11 | sean-k-mooney | so in zed you can create segments and map the to specific hosts? | |
| 13:21:14 | sean-k-mooney | without using phsynets | |
| 13:21:51 | sean-k-mooney | adding multiple phsynets to a network is not reallly the correct way to model this | |
| 13:21:55 | sahid | https://github.com/openstack/neutron-specs/blob/master/specs/zed/multiple-routed-provider-network-per-compute.rst | |
| 13:22:07 | sean-k-mooney | you should have muliptle phsynets but you should not have network span physnets | |
| 13:23:01 | sahid | sean-k-mooney: you want ability to extend you using subnet to take advantage of the scheduling, basically the user request a network, if one subnet is out of ips, then the process switch to the next subnet | |
| 13:23:23 | sahid | if we don't have this mech, the vm is in error | |
| 13:23:31 | sahid | which is not really "cloud" | |
| 13:23:47 | sean-k-mooney | sure but you can have multipel subnets mapped to the same segment | |
| 13:24:07 | sean-k-mooney | segmetns were ment to model l2 broadcast domains | |
| 13:24:17 | sean-k-mooney | and be mappable to indeivgual hosts | |
| 13:24:26 | sean-k-mooney | there was an api for that in the orginal propaosl | |
| 13:24:43 | sean-k-mooney | and along the way it got replaced with using the phsynet for segment affintiy | |
| 13:24:49 | sahid | you that means you remove the 1:1 mapping between l2 and l3 | |
| 13:24:52 | sean-k-mooney | which was the architureal mistake that should have been fixed | |
| 13:25:15 | sean-k-mooney | i mena neutron should have an api to allow you to mapp computes hots to network segments | |
| 13:25:44 | sean-k-mooney | and allow you to have multiple subnets per segment | |
| 13:25:59 | sahid | sean-k-mooney: I think we can do that in neutron | |
| 13:27:54 | sahid | currently there is a real desir of having a 1:1 mapping between a vlan and a subnet | |
| 13:28:08 | sahid | you don't want to have two subnet sharing the same vlan | |
| 13:28:24 | sean-k-mooney | how this was ment to scale orgianly is 1 segment per broadcast doamin (TOR switch), each segment should have multipel l3 routed subnets, and each segment was intended to mapped to the specific host that are attach to that broadcast domain | |
| 13:29:03 | sahid | i see | |
| 13:29:12 | sean-k-mooney | if you want a 1:1 mapping between vlan and subnet that requireds 1 network per subnet | |
| 13:29:33 | sahid | no anymore :-) | |
| 13:29:42 | sahid | but yes previously it was like that | |
| 13:30:06 | sean-k-mooney | right but im saying i dont think the feature added in zed is good for scaling | |
| 13:30:42 | sean-k-mooney | or at least it not implemted how i would do that | |
| 13:30:47 | sahid | it is good from an user point of view | |
| 13:31:11 | sean-k-mooney | not if it causes schduign issue by an expoltion of aggreates meaning they cant use it | |
| 13:32:30 | sahid | interesting point :-) perhaps the design used by placement is not so ideal ... ;D | |
| 13:33:01 | sean-k-mooney | or neutron is not useing it properly | |
| 13:33:17 | sean-k-mooney | sahid: im really not inclidned to extend nova ot supprot this neutron feature | |
| 13:33:36 | sean-k-mooney | to me its breakign the desing of how l3 routed networks was intended to work | |
| 13:38:37 | sahid | sean-k-mooney: not really sure, the datastructure in neutron was originaly exposed to handle multiple-segments | |
| 13:39:39 | sahid | but anyway, back in the fix proposed, it is not going to change nova behavior for small deployments and helps large deployments | |
| 13:39:40 | sean-k-mooney | neutorn often add extentsion without addign the nova support. | |
| 13:39:58 | sean-k-mooney | for example noava still does nto supprot the multi physnet extention i belive | |
| 13:40:30 | sahid | sean-k-mooney: yes in some situation it always take the first subnet | |
| 13:40:52 | sahid | I this the issue is when you specify a fixed ip when creating the vm | |
| 13:40:56 | sean-k-mooney | sahid: it is a change in behavior as today we only make 1 palcmenet query per schduilng request (ignoriang a deprected config option) | |
| 13:41:18 | sahid | sean-k-mooney: it will alqys be the same one request | |
| 13:42:01 | sahid | the limit of 200 is basically the limit we have observed | |
| 13:42:08 | sahid | (about 220) | |
| 13:42:09 | sean-k-mooney | the fix is raisign an exaction based on a hard coded max query size | |
| 13:42:25 | sean-k-mooney | that is deployment sepciric | |