Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-26
14:24:42 mriedem so people affected by the bug could turn that option on
14:24:48 mriedem and it sets a timer on when we remove the workaround
14:26:46 bauzas mriedem: I thought on that, glad we're on the same page
14:27:00 bauzas mriedem: I'll either way need to use privsep for creating the mdev
14:27:15 bauzas mriedem: because there is nothing in the libvirt API, that's a sysfs call
14:30:40 mriedem stvnoyes: https://review.openstack.org/515426
14:47:04 openstackgerrit Sylvain Bauza proposed openstack/nova master: vgpu: add enabled white list https://review.openstack.org/512580
14:54:22 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Remove 'vendordata_driver' opt https://review.openstack.org/397835
14:55:01 bauzas sahid: I don't understand exactly what you want as a format for https://review.openstack.org/#/c/514763/5/nova/virt/libvirt/config.py@2481
14:55:13 bauzas sahid: you want a dictionary of dictionaries ?
14:55:48 bauzas I'm fully open to ideas for a clear attribute
14:58:29 sahid bauzas: we have an instance of this class for each mdev device, right? no need of dictionary of dictionaries, a dictionary is enough
14:58:53 bauzas sahid: no
14:59:06 bauzas sahid: we have the list of all the supported types for that specific device
14:59:32 bauzas sahid: with each type, we get the deviceAPI, availableInstances and the optional name
14:59:34 sahid oh yes it's the mdev capabilities of the pci device
14:59:49 bauzas yup, that https://libvirt.org/drvnodedev.html#MDEVCap
14:59:49 sahid list of dict, no?
14:59:57 bauzas that's what I wrote :p
15:00:21 sahid :)
15:00:21 bauzas the brackets could have confused you but it's not a list of tuples
15:00:40 bauzas I'll remove them to clarify
15:01:09 sahid no no it's your comment the example which confused me, but it's my mistake I should have read better than that
15:01:56 bauzas I do wonder if I should use a namedtuple
15:02:08 bauzas but let's see what other think
15:02:12 bauzas others*
15:03:24 mriedem edleafe: bauzas: dansmith: jaypipes: a shmorgasbord of comments in the Selection object patch https://review.openstack.org/#/c/499239/
15:03:38 mriedem edleafe: wondering if we should use the existing SchedulerLimits object to contain the limits/numa_limit fields
15:03:41 mriedem like the reqspec
15:04:18 openstackgerrit Merged openstack/nova master: Accept all standard resource classes in flavor extra specs https://review.openstack.org/514942
15:04:25 edleafe mriedem: things have come full circle :)
15:04:34 mriedem you started with that?
15:04:49 edleafe Is the plan that limits would be something that is not going away?
15:05:10 mriedem they aren't going away in the near future
15:05:14 mriedem why does that matter?
15:05:26 bauzas -ETOOMANYTHINGSTODO
15:06:11 edleafe It was Jay's comment that limits are going away that got me to drop limits
15:07:08 dansmith what does that have to do with how we put it in the object, if we know we need them for the short term?
15:07:19 mriedem right - we need to pass limits down either way
15:07:24 mriedem we are still supporting the caching scheduler
15:07:39 mriedem so do we pass them differently from the requestspec when we already have an object that handles the exact same thing?
15:07:45 mriedem i'd rather just re-use SchedulerLimits
15:08:27 edleafe ok, if that's the current feeling
15:08:35 edleafe I'll get started on that soon
15:09:10 mriedem cool. i also tried to document some of the discussion we had in irc with dansmith a week or two ago about how redundant this all is with passing limits to compute in 3 different ways now,
15:09:16 mriedem and that there isn't really a way around that for the time being
15:09:25 mriedem and eventually the legacy filter props *should* go away
15:09:45 dansmith ah
15:10:09 dansmith edleafe: that SchedulerLimits object calls out the few limits we have specifically, which is better than just a dict of ints, yeah
15:10:12 dansmith even more confined
15:10:19 dansmith I didn't realize we had this
15:10:24 edleafe dansmith: gotcha
15:10:33 edleafe dansmith: I didn't know about it either
15:14:14 jaypipes mriedem: so this one of your comments on a previous patchset should be ignored? "Given that, I think it's OK to restrict the limits field value to only things that we know about for in-tree filters and how limits are used in the claim/resource tracker code. Filters are pluggable, but the resource tracker is not."
15:15:14 dansmith no?
15:15:35 dansmith we're still talking about restricting the limits to the ones we know about
15:15:40 dansmith we just can't get rid of them just yet
15:15:43 jaypipes dansmith: ok.
15:16:08 jaypipes dansmith: but we're only keeping them for the caching scheduler users, *not* because of out of tree filters. correct?
15:16:20 edleafe dansmith: question: if SchedulerLimits is already part of the reqspec object, why is it needed in the Seleciton object at all?
15:16:21 dansmith jaypipes: that's what his comment is saying
15:16:26 jaypipes dansmith: ok.
15:16:34 dansmith edleafe: because it differs per host
15:17:06 dansmith edleafe: and because we have to pass at least ten copies of limits to the compute node or we lose our heavyweight championship title
15:18:15 edleafe dansmith: more is better!
15:18:29 dansmith obvi
15:21:13 jaypipes dansmith, mriedem: so I'm confused. if the RequestSpec and legacy filter properties are always passed to the compute service during a build operation, and those things contain the limits cruft, why do we want to pass limits information in the Selection object?
15:21:15 mriedem sorry, was trying to cleanup reqspec madness in compute while it's fresh in my mind - sounds like we're all good?
15:21:28 mriedem jaypipes: different limits per alternate
15:21:33 dansmith that ^
15:21:36 jaypipes mriedem: gah. ok.
15:21:39 jaypipes ack
15:21:46 mriedem plus, the request spec is not passed back to the cell conductor during reschedules,
15:21:51 mriedem so it won't be there for alternates
15:21:54 mriedem i'm just noticing...
15:22:00 jaypipes k, another good point, thanks.
15:22:11 mriedem i'm going to polish some turds this morning
15:23:46 mriedem oh i forgot,
15:23:49 mriedem dansmith: :)
15:24:02 mriedem limits are also passed as a direct kwarg from conductor to compute.build_and_run_instance
15:24:03 dansmith ?
15:24:09 mriedem 1. requestspec.limits
15:24:14 mriedem 2. filterproperties.limits
15:24:16 mriedem 3. direct limits kwarg
15:24:22 mriedem 4. selection.limits
15:24:24 dansmith and once per alternate
15:24:29 dansmith because we rock
15:24:36 mriedem * 4. selection.limits * max_attempts
15:24:51 dansmith actually it's max_attempts +1 I think
15:24:56 dansmith well, maybe not
15:24:57 dansmith whatever
15:24:59 dansmith too fucking many
15:25:01 mriedem i mean seriously, can i just get some limits please
15:25:03 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: proper fix for Quobyte CI https://review.openstack.org/515447
15:25:08 mriedem unlimited ways to get the limits
15:25:09 artom_ kaisers_, still around?
15:25:10 dansmith we should limit our limits
15:25:31 mriedem "nova: blowing up your rpc queue with limits since 2014"
15:27:46 efried mriedem If your req spec turd polishing overlaps with https://review.openstack.org/#/c/515223/2/nova/scheduler/utils.py please let me know.
15:28:15 mriedem right now it doesn't

Earlier   Later