| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-06-10 | |||
| 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 | |
| 14:10:20 | sean-k-mooney | no | |
| 14:10:24 | sean-k-mooney | "/resource_providers?member_of=in:%s&required=%s" % ( | |
| 14:10:26 | sean-k-mooney | aggs, os_traits.MISC_SHARES_VIA_AGGREGATE) | |
| 14:10:46 | sean-k-mooney | this is only the resouce providers in teh aggrate with the os_traits.MISC_SHARES_VIA_AGGREGATE triat | |
| 14:10:50 | sean-k-mooney | so only the sharing providers | |
| 14:10:55 | gibi | but not for a single host | |
| 14:11:13 | gibi | there is no 'this host' filter | |
| 14:11:16 | gibi | in the queru | |
| 14:11:18 | gibi | in the query | |
| 14:11:21 | sean-k-mooney | there does not need to be | |
| 14:11:38 | sean-k-mooney | we are asking for all the sharing provider in the aggrate our host is a member of | |
| 14:11:47 | sean-k-mooney | that what the in: query is doing | |
| 14:12:16 | sean-k-mooney | the agg_uuids var is the list of aggreates the current host is a member of | |
| 14:13:12 | sean-k-mooney | we tyically expect only one RP in an aggrate to have MISC_SHARES_VIA_AGGREGATE althogh that is not strictly required | |
| 14:13:34 | gibi | ahh I misremembered the meaning of 'in:' the query | |