Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-27
13:35:21 sean-k-mooney finucannot: when i was using "network backend" i was referning to ovs vs linux bridge vs vpp vs sriov ...
13:35:29 leakypipes bauzas: so I've yet to see a single operator respond with a custom scheduler filter being used in the openstack-operators survey on scheduler filters.
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 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:27 superdan the former is what you use for general flavor-to-aggregate mapping right?
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 leakypipes AggregateMultiTenancyIsolation
13:49:13 sean-k-mooney leakypipes: https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_multitenancy_isolation.py
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 :)

Earlier   Later