| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-27 | |||
| 13:35:50 | finucannot | sean-k-mooney: So neutron agents? | |
| 13:36:08 | sean-k-mooney | finucannot: so neutron can only have one tunnel enpoint ip for the ovs agent but if you also ran linux bridge on the host it could have a different one | |
| 13:36:13 | sean-k-mooney | finucannot: ya basically | |
| 13:36:22 | bauzas | leakypipes: maybe they're shy ? :p | |
| 13:38:41 | finucannot | sean-k-mooney: Yeah, I think we need to settle on terminology here. So to start, we've got neutron agents. Theoretically you can run many of these on one host but we're going to consider that out of scope here, I guess | |
| 13:39:13 | sean-k-mooney | finucannot: normally you will have sriov + one other maxium per host | |
| 13:40:20 | sean-k-mooney | finucannot: you can have more but gernally running more then two agent does not by you anything usefull and is a pain to mainatin | |
| 13:43:20 | sean-k-mooney | leakypipes: there were a few responces on the openstack-dev thread but ya i guess either operators dont want to share or have not seen it | |
| 13:44:57 | sean-k-mooney | leakypipes: looking at the responces only the AggregateInstanceExtraSpecsFilter and AggregateImagePropertiesIsolation need complex metadata stored on the host aggreates which cant be offloaded to placement | |
| 13:45:27 | leakypipes | sean-k-mooney: and ComputeCapabilitiesFilter. | |
| 13:46:04 | leakypipes | sean-k-mooney: the AggregateInstanceExtraSpecsFilter and AggregateImagePropertiesIsolation stuff will be handled fully by superdan's placement-request-filter work. | |
| 13:46:19 | superdan | um | |
| 13:46:21 | superdan | fully? | |
| 13:46:26 | leakypipes | FULLY! | |
| 13:46:31 | leakypipes | because... superdan. | |
| 13:46:46 | sean-k-mooney | leakypipes: hum i assumed that we would be able to modle the compute capablities could be handeled by traits on the compute node RP but i admit i have not looked at what that does in a while | |
| 13:47:27 | superdan | the former is what you use for general flavor-to-aggregate mapping right? | |
| 13:47:27 | leakypipes | sean-k-mooney: it is this ludicrousness that is problematic to "port" to placement: https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L49-L56 | |
| 13:47:46 | leakypipes | superdan: yes. and the latter is tenant to aggregate mapping | |
| 13:48:05 | superdan | leakypipes: no, the latter is for image-based mapping | |
| 13:48:15 | superdan | leakypipes: there is a dedicated tenant filter for tenant-to-aggregate | |
| 13:48:28 | leakypipes | superdan: ack, apologies, yep. | |
| 13:48:48 | leakypipes | superdan: IsolatedHostsFilter? | |
| 13:49:02 | leakypipes | nope, that's the image one too | |
| 13:49:13 | sean-k-mooney | leakypipes: https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_multitenancy_isolation.py | |
| 13:49:13 | leakypipes | AggregateMultiTenancyIsolation | |
| 13:49:15 | leakypipes | :0 | |
| 13:49:24 | superdan | right, that's the tenant one | |
| 13:49:25 | leakypipes | sean-k-mooney: just beat ya. :) | |
| 13:49:59 | leakypipes | sean-k-mooney: also, see this craziness here: https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L76-L107 | |
| 13:50:10 | leakypipes | sean-k-mooney: there's not a chance that will be ported as a placement filter. | |
| 13:51:29 | sean-k-mooney | leakypipes: perhaps port is the wrong word. i think many of the usecase that this was used for can be supported with placement with out all the extra spec hardcodeing that was dont in that filter | |
| 13:52:59 | sean-k-mooney | however bad the compute_capablities_filter looks however the json filter is 10 times worse https://github.com/openstack/nova/blob/master/nova/scheduler/filters/json_filter.py | |
| 13:53:08 | leakypipes | sean-k-mooney: yep. | |
| 13:53:19 | leakypipes | sean-k-mooney: luckily I have yet to see anyone say they are using it. | |
| 13:54:11 | sean-k-mooney | out of interest is there a policy on deprecating filters over time | |
| 13:55:58 | leakypipes | sean-k-mooney: well, as soon as the filter becomes redundant, we want to deprecate it. | |
| 13:58:21 | bauzas | leakypipes: just keep in mind that till' we prevent other scheduler drivers but FilterScheduler, we can't remove the filters that are feature-parity with superdan's placement-request-filter work | |
| 13:58:38 | superdan | um | |
| 13:58:48 | bauzas | leakypipes: other good news, we still allow to run custom scheduler driver, AFAIK | |
| 13:58:50 | superdan | you mean cachingscheduler only right? | |
| 13:59:08 | bauzas | superdan: I need to look at code, but I think we can run any scheduler driver code | |
| 13:59:13 | superdan | because I don't think we're promising to keep filters around for our own scheduler for other drivers | |
| 13:59:16 | superdan | sure, but, | |
| 13:59:20 | superdan | that's your problem if you do | |
| 13:59:30 | bauzas | that's one way to see it :) | |
| 13:59:40 | superdan | if you swap out the whole driver, but import our filters to use them... | |
| 13:59:55 | bauzas | but yeah, at least in-tree, we still have CachingScheduler and ChanceScheduler | |
| 14:00:02 | bauzas | both aren't calling placement | |
| 14:00:36 | superdan | heh, chancescheduler :) | |
| 14:00:44 | bauzas | tbc, while the former is production-targeted, I think we can safely drop chancescheduler | |
| 14:00:54 | bauzas | ... except we use it at lot in our functional tests | |
| 14:01:06 | bauzas | AFAIR | |
| 14:01:23 | bauzas | chancescheduler is just random(host) | |
| 14:01:31 | bauzas | it's not about chance | |
| 14:01:44 | sean-k-mooney | bauzas: we do stil allow out of tree scheduler driver but we dont gurarntee not to break them | |
| 14:02:01 | bauzas | I agree | |
| 14:02:16 | bauzas | I'm just saying we allow that, so communication is the key | |
| 14:03:13 | sean-k-mooney | in future we will likely want to narrow that to say if you run a out of tree driver it must call placement but there is not much add benifit to that vs the filter driver with just one custom filter | |
| 14:05:21 | sean-k-mooney | bauzas: the chance schduler could likely be ported to just a random weigher and a pass all filter for functional tests | |
| 14:09:56 | openstackgerrit | Merged openstack/nova master: placement: resource requests for nested providers https://review.openstack.org/554529 | |
| 14:10:11 | openstackgerrit | Merged openstack/nova master: Fix tox -e docs https://review.openstack.org/564631 | |
| 14:11:16 | openstackgerrit | Takahito Hirose proposed openstack/python-novaclient master: api_version decorator becomes an error in Python 3.5.0. https://review.openstack.org/564774 | |
| 14:21:38 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Make sure microversion < 2.62 does not show host(Id) for instance actions https://review.openstack.org/564782 | |
| 14:30:13 | sahid | mriedem, superdan, when you have a moment i commented on a patch we have worked on | |
| 14:30:16 | sahid | https://review.openstack.org/#/c/497457/30/nova/virt/libvirt/driver.py@7384 | |
| 14:30:38 | sahid | i think we will have to find a solution to address a specific case | |
| 14:43:18 | sean-k-mooney | mriedem: im going to be offlie for a while soon but ill try and respin https://review.openstack.org/#/c/553072/5 today. | |
| 14:45:12 | sahid | sean-k-mooney: don't set workflow -1, if you can't address the comments I will try next week | |
| 14:45:59 | sean-k-mooney | mriedem: ill also try and and set up a mixed lb and ovs devstack at the weekend/this evening to test https://review.openstack.org/#/c/551370/ and ill post the local.conf. i should be able to convert that into a ci job once i know what the local.conf need to look like. | |
| 14:46:23 | sean-k-mooney | sahid: well i set -1 since i plan to fix it myself later today once i get home. | |
| 14:46:43 | mriedem | sean-k-mooney: cool, thanks | |
| 14:49:57 | kashyap | mriedem: Fixed another typo in the config file: s/the you need to/then you need to/ in that change | |
| 14:50:03 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Lift the restriction of choices for `cpu_model_extra_flags` https://review.openstack.org/563926 | |
| 14:50:47 | mriedem | kashyap: did you see the comment from danpb? | |
| 14:50:50 | mriedem | on PS6 | |
| 14:50:54 | kashyap | mriedem: Oh, let me see | |
| 14:51:47 | kashyap | mriedem: Darn | |
| 14:51:58 | kashyap | In the original series, I _did_ canonicalize | |
| 14:52:11 | kashyap | (s/series/patch/) | |
| 14:52:36 | sean-k-mooney | kashyap: ya i was about to check if it was done in the previous patch | |
| 14:52:58 | kashyap | sean-k-mooney: In the original backported version we ignore the case | |
| 14:53:01 | kashyap | Hmm | |
| 14:53:47 | sean-k-mooney | kashyap: in that case you proably want a patch to just lowercase the flags then rebase https://review.openstack.org/#/c/563926/ on top | |
| 14:54:04 | sean-k-mooney | then we can backport the lowercsing seperatly | |
| 14:54:35 | kashyap | sean-k-mooney: Hmm, I'm a bit torn | |
| 14:54:46 | kashyap | Whether to just do the canonicalization to lowercase in this patch | |
| 14:54:52 | kashyap | (Which seems cleaner) | |
| 14:54:54 | sahid | sean-k-mooney: ok thanks | |
| 14:55:09 | kashyap | But there's the "What about backports" thing | |
| 14:55:12 | sean-k-mooney | kashyap: actully we have a choices element in the backport right? | |
| 14:55:40 | sean-k-mooney | kashyap: e.g. the backported verion only allows pcid | |
| 14:55:41 | kashyap | sean-k-mooney: We do, and also have: 'ignore_case=True' | |
| 14:55:54 | kashyap | sean-k-mooney: Yes, only 'pcid' was allowed | |
| 14:56:27 | sean-k-mooney | so for the backport if we always emit lowercase pcid then its fine to jsut canonicalise the names in https://review.openstack.org/#/c/563926 | |
| 14:56:55 | kashyap | sean-k-mooney: No, in the backport too we ignore casing. | |
| 14:57:00 | leakypipes | TheJulia: FYI, I'm reviewing the ironic instance_uuid prep_for_spawn() patch. Might take a little while. | |
| 14:57:46 | TheJulia | leakypipes: thanks, no worries :) I just don't want it to fall off radars :) | |
| 14:57:56 | leakypipes | yup, no worries. | |
| 15:01:56 | sean-k-mooney | kashyap: https://github.com/openstack/oslo.config/blob/master/oslo_config/types.py#L160-L164 this should lowercase it for you | |