| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 16:27:53 | sean-k-mooney | stephenfin: lennyb spotted it and pingged rodlfo and i on the neutron irc this morning | |
| 16:28:23 | sean-k-mooney | i was thinking about fixing the name spaceing of those module too but i think there is already enough in one patch | |
| 16:28:32 | sean-k-mooney | i might submit a followup later | |
| 16:28:35 | stephenfin | sean-k-mooney: I'm going to see if we can do the same thing claudiub did here to avoid that happening again https://review.openstack.org/#/c/470775/ | |
| 16:29:30 | sean-k-mooney | stephenfin: im not sure that would have help in this case but i might not under stand awhat that dose enough either | |
| 16:30:28 | stephenfin | sean-k-mooney: Yeah, it wouldn't actually. I thought https://review.openstack.org/#/c/609414/1/os_vif/tests/unit/internal/command/ip/windows/test_impl_netifaces.py was mocking the wrong stuff but it's not | |
| 16:31:02 | sean-k-mooney | this is the improtant test https://review.openstack.org/#/c/609414/1/os_vif/tests/unit/internal/command/ip/test_api.py | |
| 16:31:26 | sean-k-mooney | before we were returing an instance of the ip lib for windows and the module for linux | |
| 16:31:43 | stephenfin | sean-k-mooney: Just left a nit comment on that, actually | |
| 16:32:33 | mriedem | dansmith: on that initial allocation ratios spec, there is one place we still use the compute node fields, and that's in the scheduler https://github.com/openstack/nova/blob/6bf11e1dc14afad78b11d980c2544a3dc41579ff/nova/scheduler/host_manager.py#L256 | |
| 16:32:46 | sean-k-mooney | ya i realsied i coudl have used that too. im going to be adding more unit tests wehn ir change the module layout so ill change that then if your ok with that | |
| 16:32:51 | mriedem | so we set the values on the compute (in the RT) and then read in the scheduler | |
| 16:33:00 | dansmith | mriedem: but aren't those just for the filters? | |
| 16:33:04 | dansmith | what else cares about those? | |
| 16:33:28 | mriedem | weighers use it too i guess | |
| 16:33:46 | dansmith | to pick things that aren't set for oversubscription? | |
| 16:33:49 | dansmith | that seems weird | |
| 16:34:11 | mriedem | the numa topology filter is also using it | |
| 16:34:12 | dansmith | oh, numa filter uses it | |
| 16:34:18 | dansmith | hah | |
| 16:34:24 | dansmith | christ | |
| 16:34:37 | dansmith | so | |
| 16:34:43 | dansmith | (a) we should try to get someone to fix that | |
| 16:35:02 | dansmith | (b) we can just update the compute node record with the same policy as we update placement | |
| 16:35:02 | stephenfin | sean-k-mooney: Yup, it's just a nit | |
| 16:35:28 | mriedem | which is use config if set | |
| 16:35:35 | mriedem | that's what the spec proposed yeah | |
| 16:35:39 | dansmith | yep | |
| 16:35:44 | dansmith | okay I see the use in the weigher | |
| 16:35:48 | mriedem | the question was about upgrading from compute nodes that have 0.0 values in the db | |
| 16:36:01 | mriedem | and i said we could online data migrate those by reading config if the values are 0.0 | |
| 16:36:13 | dansmith | the 0.0 means that scheduler uses its own config, right? | |
| 16:36:26 | sean-k-mooney | regarding the numa topology filter im not sure it actully need the allocation ratiors | |
| 16:36:27 | mriedem | no | |
| 16:36:43 | dansmith | allocation_ratio of zero makes no sense otherwise right? | |
| 16:36:47 | mriedem | nothing in the scheduler reads config for allocation ratios | |
| 16:36:58 | dansmith | mriedem: it used to though yeah? | |
| 16:37:04 | mriedem | in the long long ago i guess, | |
| 16:37:07 | mriedem | oh well, | |
| 16:37:12 | mriedem | the facade would i guess yeah... | |
| 16:37:30 | mriedem | the ComputeNode._from_db_object would read from config if 0.0 in the db | |
| 16:37:30 | dansmith | point being, 0.0 is nonsense | |
| 16:37:38 | jaypipes | dansmith: ++ | |
| 16:37:55 | dansmith | so we could leave that, and only set it if they override per compute.. same logic as placement | |
| 16:38:05 | dansmith | and anything existing with 0.0 gets the same treatment as usual I guess | |
| 16:38:26 | mriedem | leave the facade in ComputeNode._from_db_object? | |
| 16:38:49 | dansmith | i imagine it won't affect compute's use if it is ignoring what is set on the object, so .. sure? | |
| 16:38:58 | sean-k-mooney | stephenfin: for https://github.com/openstack/nova/blob/0163b9bfb54aaa89b0574c86e7fd36321eebccfe/nova/scheduler/filters/numa_topology_filter.py#L91-L102 can you think of a use case wehre we actully need the allcoation ratiios here | |
| 16:39:33 | sean-k-mooney | stephenfin: we are not allowed to over subsibe against our selves wehn fitting to a host so setting them to 1.0 i think would be valid | |
| 16:42:05 | sean-k-mooney | stephenfin: i would have to go through the code to check but i think we could make the numa topolgy filter work without them. | |
| 16:42:50 | sean-k-mooney | dansmith: although it sound like we dont need to remove them if we go wtih the facade right | |
| 16:43:14 | dansmith | sean-k-mooney: it won't be right if you do | |
| 16:43:32 | dansmith | sean-k-mooney: because if people set the ratio in placement per-compute, which is what we're trying to enable with all of this work, | |
| 16:43:38 | dansmith | the filter will consider a value other than what is in placement | |
| 16:44:04 | dansmith | I'm guessing we don't get back ratios in /a_c, but if we did, we could update our host states before we call the filters | |
| 16:44:12 | sean-k-mooney | dansmith: yes but this is not using the placement value anyway | |
| 16:44:18 | jaypipes | mriedem: why would we keep the facade stuff in ComputeNode._from_db_object()? | |
| 16:44:38 | dansmith | sean-k-mooney: right but right now they have to be the same | |
| 16:44:39 | dansmith | sean-k-mooney: in the future they will not be | |
| 16:44:52 | dansmith | jaypipes: see the discussion just now on the filters that use it, and existing computes in the db with 0.0 set | |
| 16:45:21 | sean-k-mooney | dansmith: placement woudl have already filtered out any host that did not pass its allocation right. so we should not have to check twice and sicne we can oversubsibe againat ourselve an allocation ration of 1 i think would still be correct | |
| 16:45:21 | mriedem | jaypipes: we either need to leave that or online data migrate the 0.0 entries from existing records in the db on read | |
| 16:45:46 | sean-k-mooney | dansmith: anywway its not important right now i guess | |
| 16:45:49 | mriedem | jaypipes: because the compute won't deal with those fields on the object, and if not set, the scheduler reads them from config via the facade | |
| 16:45:55 | dansmith | sean-k-mooney: I didn't look to see what that code in the filter was doing, so maybe? | |
| 16:46:00 | dansmith | sean-k-mooney: if so, we just remove it right? | |
| 16:46:43 | sean-k-mooney | dansmith: ya i think soo but i would have to double check the hardware.numa_fit_instance_to_host fucntion first | |
| 16:47:28 | dansmith | we get back the resource summaries from the providers in /a_c, so including the allocation_ratios in there might be useful for things like this and for the weigher case | |
| 16:48:30 | sean-k-mooney | dansmith: ya. the filters dont currently have access to the allocation candiates today is that correct | |
| 16:48:39 | sean-k-mooney | unless there in the spec_objec? | |
| 16:48:42 | dansmith | sean-k-mooney: that isn't what I'm saying | |
| 16:49:01 | dansmith | I'm saying the scheduler, when it gets back candidates, gets a summary of all covered providers, with inventory information | |
| 16:49:11 | dansmith | if that included the ratios, it could update host_states before calling the filter loop | |
| 16:49:46 | jaypipes | sean-k-mooney: pls see my comment on https://review.openstack.org/#/c/609414/ | |
| 16:49:59 | sean-k-mooney | oh ok that would work too ya i was assuming you were suggsting passing in the candiates but your way we do that update once and dont have to update any code in the filters | |
| 16:50:52 | sean-k-mooney | jaypipes: there isnt a bug number because i just got pingged on irc this morning but i can open one | |
| 16:51:11 | dansmith | mriedem: melwitt tssurya: cells meeting today? | |
| 16:51:17 | mriedem | nack | |
| 16:51:24 | mriedem | we might want to just cancel that meeting | |
| 16:51:39 | dansmith | I'd also be fine with that | |
| 16:51:50 | dansmith | I think I suggested that last year even | |
| 16:53:39 | jaypipes | sean-k-mooney: yes pls. if this is truly a "currently broken for hardware offloaded ovs" scenario, it definitely should be a bug. | |
| 16:54:50 | tssurya | dansmith: no problems in cancelling | |
| 16:55:03 | sean-k-mooney | its broke for all ovs backends that use ip command because api _get_impl on linux retrun a module instead of the insatnce of the pyroute2 class | |
| 16:56:12 | mriedem | dansmith: you want to propose the change to cancel the meeting or want me to? | |
| 16:56:13 | sean-k-mooney | jaypipes: os that is ovs + iptables or ovs + hardware offloads. i have added some extra test to catch this case | |
| 16:56:22 | dansmith | melwitt: what do you think about canceling the cells meeting altogether and making it ad-hoc as needed? | |
| 16:56:35 | dansmith | mriedem: I figure we don't need to make a federal case out of it | |
| 16:56:42 | dansmith | if everyone agrees, we just take it off the schedule | |
| 16:56:45 | mriedem | dansmith: it's literally in a schedule though | |
| 16:56:56 | mriedem | http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meetings/nova-cells-v2-meeting.yaml | |
| 16:56:56 | dansmith | I know | |
| 16:57:02 | dansmith | oh, | |
| 16:57:04 | dansmith | that schedule | |
| 16:57:16 | mriedem | yeah, free up the time slot in that channel if we're not going to use it | |
| 16:57:18 | dansmith | I thought it was just on the old wiki list | |
| 16:57:28 | mriedem | no this is very official and federale | |
| 16:57:34 | dansmith | I'll propose.. I need to do something useful today | |
| 17:01:44 | melwitt | dansmith: yup sounds ok to me | |
| 17:01:57 | dansmith | https://review.openstack.org/#/c/609496/ | |