Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-15
15:52:29 mriedem do we have a filter that actually has the driver.capabilities information exposed to it?
15:52:33 bauzas I agree with both of you to try to make #1 prioritary
15:52:38 cdent efried: good, thanks
15:52:57 efried bauzas: IMO we should do any filtering that's possible/practical to do in placement, in placement. Cause that'll be more efficient.
15:52:58 bauzas mriedem: we have one caring about the compute capabilities themselves
15:53:08 mriedem bauzas: but i'm not sure if that filter actually gets that data
15:53:24 bauzas efried: yeah, hence my
15:53:25 bauzas (16:52:33) bauzas: I agree with both of you to try to make #1 prioritary
15:53:38 efried cool
15:53:39 bauzas okay, looks like I'm settling down
15:53:58 mriedem i have a hard time even grokking the code in the compute capabilities filter
15:53:58 bauzas #1 scheduling (placement) shouldn't never be open to operators
15:54:18 bauzas #2 scheduling (filters) would eventually only be custom
15:54:27 bauzas if we could
15:54:48 bauzas looks like a deal then
15:54:49 mriedem the ComputeCapabilitiesFilter works on the HostState.stats right?
15:56:07 mriedem anyway, it would be easy to make one of these pre-placement filters that sees, 'oh you're doing bfv with a multiattach volume, let me add required trait CUSTOM_COMPUTE_SUPPORTS_MULTIATTACH to the request to placement for filtering'
15:56:11 efried bauzas: Not sure I agree that ops don't affect placement-level scheduling. They do so via traits etc.
15:56:37 efried mriedem: ++, assuming the compute got tagged with that trait somehow
15:56:40 jaypipes efried: +2
15:56:47 mriedem efried: that's https://review.openstack.org/#/c/538498/
15:56:56 mriedem http://lists.openstack.org/pipermail/openstack-dev/2018-January/126653.html
15:56:58 mnaser mriedem: left some comments about the change .. to the best of my knowledge
15:57:00 bauzas efried: no, I meant custom code modifying behaviour of placement
15:58:13 bauzas mriedem: IIRC, the ComputeCapabilitiesFilter matches any HostState field
15:58:15 bauzas that's magic
15:58:21 cdent yes, definitely custom code should not happen to placement
15:58:31 dansmith cdent: that's not what he's saying here htough
15:59:12 bauzas dansmith: so, modularity is good, provided we don't open the entry points
15:59:24 dansmith cdent: nobody is talking about touching placement at all, he's talking about in this code that we use to query placement
15:59:26 bauzas dansmith: a big fat comment in the code would be fine for me
15:59:48 dansmith bauzas: we don't comment code that isn't pluggable so I don't see why this would be any different :)
15:59:49 bauzas yeah, what dansmith said
15:59:52 cdent ah, sorry, I misinterpreted "I meant custom code modifying behaviour of placement"
16:00:16 dansmith bauzas: I will have to say, that scheduler filters and these pre-filters would be the _best_ place to introduce custom behavior if I was an operator
16:00:21 bauzas dansmith: you surely imagine the creativity of people using our code :)
16:00:36 cdent presumably the only way to modify placement is by sending different queries and creating various entities. in which case it's not "custom" is it?
16:00:39 dansmith because placement is a solid interface and all this is doing is augmenting how we call it
16:00:42 cdent it's what it's for
16:00:47 dansmith cdent: exactly my point
16:00:50 bauzas the scheduler base filter is an external interface
16:01:01 cdent yay, agreeing with dan is fun
16:01:27 bauzas what would be the base pre-filter isn't an external interface and I'd vote -2 on any change that would open that
16:01:57 dansmith bauzas: why do you think the scheduler filters are an external interface?
16:02:09 bauzas dansmith: because it's pluggable :)
16:02:28 bauzas shit, meeting
16:02:29 dansmith bauzas: we don't load them externally anymore right?
16:02:46 bauzas oh hell, we still do that alot
16:02:54 bauzas unless I missed the bus
16:03:09 bauzas and cutting that flexibility would be a huge thing
16:03:11 dansmith where is the loading code for that?
16:03:37 bauzas sec
16:04:13 dansmith either way, the spec says I'm not even adding a list of pre-filters, but making each one a semantic config toggle
16:04:14 dansmith so it should be pretty clear we're not adding a new external interface here :)
16:04:57 bauzas dansmith: https://docs.openstack.org/nova/latest/user/filter-scheduler.html?#writing-your-own-filter
16:05:39 dansmith ah, I thought we removed the classloading from available_filters
16:05:54 bauzas no, we removed the possibility to hook a custom scheduler *driver*
16:06:02 dansmith yeah I remember that
16:06:19 mriedem no we didn't
16:06:23 mriedem that was reverted
16:06:24 bauzas okay, I thought we never agreed on removing the custom filter
16:06:24 dansmith well, anyway, this is not that :)
16:06:38 bauzas mriedem: orly?
16:06:48 mriedem yes you were on the reno for it
16:06:58 bauzas man, did I slept 100 years like the Sleeping Beauty ?
16:07:31 bauzas mriedem: on reverting the removal of the classloading ?
16:07:44 bauzas if so, I apologize for my memory lack
16:07:49 dansmith bauzas: I think he's talking about the driver pluggability
16:07:59 mriedem you can't classload the driver, but you can add an entry point for the scheduler driver in setup.cfg
16:08:12 bauzas righrt
16:08:50 mriedem https://github.com/openstack/nova/commit/1e5c7b52a403e708dba5a069dd86b628a4cb952c
16:09:19 bauzas seriously, I'm sometimes afraid of my memory lacks :/
16:09:25 bauzas I totally forgot that story
16:09:51 bauzas apologies for that
16:10:10 bauzas it's 6 months ago and I don't recall it
16:10:12 bauzas creepy
16:10:50 dansmith so, um,
16:11:00 dansmith are we okay on this non-pluggable modular pre-filter thing or what?
16:11:04 cdent bauzas: too much chaud-verte (or was it verte-chaud or whatever)?
16:11:17 bauzas cdent: no, Chartreuse
16:11:24 bauzas dansmith: oui
16:11:36 bauzas dansmith: I'm currently re-reviewing your spec
16:19:06 bauzas cdent: edleafe: I mostly see your concerns by having a spec approved in 1 day, and pre-PTG
16:19:17 bauzas cdent: edleafe: please note that I don't feel it's a problem
16:19:35 bauzas we can approve a spec and amend it later based on feedback that can come from the PTG or elsewhere
16:19:54 edleafe bauzas: the concern was that a series of related specs came out all at once
16:20:02 bauzas or we can at the end of the day have a spec that is approved but leading to a dead-end, that's not a problem to me
16:20:10 edleafe At first I thought I missed the discussions about them
16:20:13 dansmith I don't think the concern is over PTG discussion,
16:20:39 dansmith we can't tie spec approvals to ptg discussion globally.. not everyone can or will go, nor will we have enough time for that
16:20:54 edleafe dansmith: agreed.
16:20:57 bauzas edleafe: the relationship between specs is surely a thing to consider, but which shouldn't hold an approval if that's not blocking (heh, tautology)
16:21:11 bauzas dansmith: sure, hence my "or elsewhere"
16:21:48 edleafe bauzas: it was because there were a few unstated assumptions, such as the idea that we would be syncing nova aggs to placement aggs, that were surprising
16:22:12 dansmith edleafe: I dunno why that is surprising, I feel like we've covered that multiple times
16:22:28 dansmith but that said, I'm totally cool with letting the ink dry a bit on things before they go in so all the timezones have a chance to comment
16:22:32 edleafe dansmith: it's possible, but I must have missed those discussions
16:22:46 dansmith I actually thought we already were doing that syncing,
16:22:56 dansmith because of the method for doing so in the scheduler client, which is apparently unused as of yet
16:22:58 edleafe dansmith: I still repeated the mantra "placement aggs are not nova aggs"

Earlier   Later