Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-27
13:00:13 sean-k-mooney kashyap: out of interest does cpu model Haswell-noTSX-IBRS have meltdown/specter fixed
13:01:26 sean-k-mooney the fact that its IBRS and not noIBRS implies it doing speclitive execution
13:11:50 mdbooth jgriffith: https://bugs.launchpad.net/nova/+bug/1767363
13:11:50 openstack Launchpad bug 1767363 in OpenStack Compute (nova) "Deleting 2 instances with a common multi-attached volume can leave the volume attached" [Undecided,New]
13:12:20 kashyap sean-k-mooney: Was AFK briefly
13:12:35 kashyap sean-k-mooney: Yes, and no
13:13:19 sean-k-mooney kashyap: yes to meltdown and not to specter because qemu/kvm/kernel is patch to prevent that?
13:13:35 kashyap Exactly
13:14:05 sean-k-mooney kashyap: cool then IBRS makes sense
13:14:07 kashyap sean-k-mooney: And more over: those -noIBRS models _doesn't_ include 'PCID' (some got confused)
13:16:01 sean-k-mooney kashyap: right well i guess it you dont do speculatve branch execution then you dont need pcid to create seperate user/kernel adress contextes in the guest to mitigate the security risk
13:16:43 kashyap sean-k-mooney: Hmm, didn't think that way; that's a good point.
13:23:26 stephenfin sean-k-mooney: Sure is. I tested on an AIO DevStack deployment with OVS and things get shunted to the correct NUMA node
13:23:43 sean-k-mooney stephenfin: cool
13:25:30 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: Lift the restriction of choices for `cpu_model_extra_flags` https://review.openstack.org/563926
13:30:34 sean-k-mooney finucannot: did you see my comment on https://review.openstack.org/#/c/564439/1
13:31:16 kashyap mriedem: Nice of you to fix the nits yourself
13:31:21 sean-k-mooney finucannot: also cool i might see if i can test it with ovs-dpdk but it will be next week at the earliest before i do
13:33:07 finucannot sean-k-mooney: That would be great. I was planning to do that myself. I also want to do some multi-host testing (to properly validate the scheduler aspects of things) though live migration is off the cards, seeing as this requires CPU pinning
13:33:49 finucannot sean-k-mooney: Question though: both you and jaypipes keep using the term "network backend". What do mean?
13:33:57 finucannot e.g. https://review.openstack.org/#/c/564439/1/nova/objects/numa.py@164
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 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

Earlier   Later