| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 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 | bauzas | #1 scheduling (placement) shouldn't never be open to operators | |
| 15:53:58 | mriedem | i have a hard time even grokking the code in the compute capabilities filter | |
| 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 | dansmith | well, anyway, this is not that :) | |
| 16:06:24 | bauzas | okay, I thought we never agreed on removing the custom filter | |
| 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" | |
| 16:23:14 | dansmith | ...which is still true :) | |
| 16:24:33 | edleafe | now it's "placement aggs *are* nova aggs, and then some" | |
| 16:24:35 | edleafe | :) | |
| 16:24:44 | mriedem | fwiw i never thought we were syncing nova aggs to placement aggs, or intended to do so, before yesterday | |