| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-06-10 | |||
| 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 | |
| 13:42:37 | sean-k-mooney | we have a custoemr with a similar probelem for a diffent reason | |
| 13:42:45 | sean-k-mooney | they had ~600 aggrates per host | |
| 13:42:57 | sean-k-mooney | before they hit the limit in our installer | |
| 13:43:19 | sean-k-mooney | so add ign a hardcoded check like this would 1 break them and 2 break the workaround they want to use | |
| 13:43:30 | sean-k-mooney | which is to increase the query string limit | |
| 13:43:40 | sean-k-mooney | which they tested and works for them | |
| 13:44:02 | sahid | not sure to understand | |
| 13:44:18 | sahid | the fix split the number of uuid passed to the uri | |
| 13:44:27 | sahid | if it is more than 200 | |
| 13:44:57 | sean-k-mooney | which intoduces multipel quereis | |
| 13:45:32 | sahid | only for env with more than 200 | |
| 13:45:41 | sean-k-mooney | gibi: you were looking into this on our side | |
| 13:46:03 | sean-k-mooney | gibi: didnt you mention we doen seem to need to call _get_sharing_providers in teh comptue manager today ? | |
| 13:46:10 | sahid | so for most of the deployment we don't change the behavior | |
| 13:46:19 | sahid | and for the other, we fix their issue | |
| 13:46:50 | sean-k-mooney | sahid: we cant use a constant fo 200 | |
| 13:47:03 | sean-k-mooney | if we were to do this we need to have it be configurable | |
| 13:47:47 | sean-k-mooney | but the reason im pinign gibi into the conversation is i think they determined this was not curestly used in compute manager where its called | |
| 13:48:38 | sean-k-mooney | sahid: https://bugzilla.redhat.com/show_bug.cgi?id=2283075 | |
| 13:48:52 | sean-k-mooney | sahid: we were considering if we coudl remove this funciton entirely | |
| 13:49:28 | sean-k-mooney | the pagingation fo this query is perhaps somethign we coudl do but i think we would need to make the size configurabel if we did | |
| 13:50:02 | sahid | hum... interesting yes | |
| 13:50:51 | gibi | sean-k-mooney: what I remember it is used in the resource tracker to cache the sharing realtionship into the internal provider_tree. | |
| 13:51:29 | sean-k-mooney | right and today im not sure that cache is actully used in the resouce tracker for anything | |
| 13:52:27 | sean-k-mooney | sahid: if the bug you reported is just with the compute manager/resouce tracker and not the sechduler | |
| 13:52:53 | sean-k-mooney | i guess your propsoed patch is not a behaivor chage when scheduling | |
| 13:53:13 | sean-k-mooney | so the bug you reported is proably valid | |
| 13:53:45 | sean-k-mooney | what im not sure would be valid is making muliple request ot the allcoation candiate api in a similar way | |
| 13:54:01 | sean-k-mooney | that is what i tought you were suggesting but looking at your patch its not | |
| 14:00:48 | gibi | I belive what is proposed is heavy behavior change. Today the returned RP needs to be in all the aggregates passed, in the new code it only needs to be in a subset of those aggregates. | |
| 14:01:20 | gibi | potentially in the last loop the RP only need to be in the last aggregate | |
| 14:01:47 | gibi | we cannot paginat the query itself | |
| 14:02:16 | sean-k-mooney | what is proposed is not affecting the allocation candiate query | |
| 14:02:41 | sean-k-mooney | at least that is what i understood sahid was asserting | |
| 14:03:10 | gibi | it affects the meaning of _get_sharing_providers | |
| 14:03:24 | gibi | we cannot just do that bindly | |
| 14:03:33 | sean-k-mooney | yes i know | |
| 14:03:59 | sean-k-mooney | but but what im saying is we shoudl not be calling that when generating the allcoation candiate request | |
| 14:04:55 | sean-k-mooney | but your right that we have to be carful which is why i was orginally pushing back on shaids approch. but if it only affecting the resouce-tracker cache that less fo a concern | |
| 14:06:33 | gibi | even if it is only used in the tracker we cannot allow to have wrong data in the tracker, maybe tomorrow a new feature will start using that data. | |
| 14:06:47 | sean-k-mooney | sure | |
| 14:07:01 | sean-k-mooney | but i never said we shoudl | |
| 14:07:03 | gibi | so I'm hard -1 in the current version of the patch | |
| 14:08:00 | gibi | I guess I'm not arguing against you but against the patch itself :) | |
| 14:08:02 | sean-k-mooney | so the current verison of the patch should not chagne the behaivor | |
| 14:08:19 | sean-k-mooney | either we would loop over all the aggreates and return the comined set | |
| 14:08:39 | sean-k-mooney | or raise the same excption we raised previosusly | |
| 14:09:11 | sean-k-mooney | the main issues is that there coudl be a chagne in the assocation during the iterations | |
| 14:09:15 | gibi | no, that is my point, we cannot just combine the results | |
| 14:09:41 | sean-k-mooney | this is the set of sharing resouce providers that share with this host | |
| 14:09:48 | sean-k-mooney | why can we not just combine? | |
| 14:09:57 | gibi | no this is all the RPs that in an aggregate | |
| 14:10:10 | gibi | this is not just a single RP | |