| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 14:01:17 | mriedem | jangutter: stephenfin: to be clear, we don't have to add feature parity or support for any new features for nova-net at this point | |
| 14:01:19 | mriedem | if that's a question | |
| 14:01:54 | stephenfin | mriedem: Not quite. The question is can we remove nova-net stuff if it doesn't break the cells v1 jobs | |
| 14:02:04 | bauzas | mriedem: so, in that case, should we just accept strings and asking to operators to modify setup.cfg ? | |
| 14:02:15 | stephenfin | untested nova-net stuff, I might add | |
| 14:02:28 | mriedem | stephenfin: can't make that assumption - the cellsv1 job is just one config | |
| 14:02:49 | mriedem | bauzas: that's the way it worked prior to the choices restriction | |
| 14:02:56 | stephenfin | drat | |
| 14:03:02 | stephenfin | looks like it's to stay, jangutter | |
| 14:03:06 | stephenfin | *got to | |
| 14:03:11 | mriedem | bauzas: i'm not advocating supporting out of tree scheduler drivers | |
| 14:03:26 | jangutter | stephenfin: here's to 6 more years! | |
| 14:03:35 | mriedem | bauzas: so what i'm proposing is we enable that ability, along with immediately deprecating it, and backport that to ocata | |
| 14:03:37 | mriedem | and remove in queens | |
| 14:03:38 | bauzas | mriedem: not really | |
| 14:03:47 | mriedem | jangutter: stephenfin: tbc, i'm also not sure what the context is here | |
| 14:03:48 | bauzas | mriedem: previously, we were not using strings | |
| 14:03:59 | bauzas | mriedem: rather, we asked for the package | |
| 14:04:03 | mriedem | bauzas: the scheduler driver config option could be an entry point | |
| 14:04:07 | mriedem | in setup.cfg | |
| 14:04:11 | mriedem | and we'd load it with stevedore | |
| 14:04:12 | mriedem | i know | |
| 14:04:15 | bauzas | mriedem: correct | |
| 14:04:25 | mriedem | i'm saying i think we have to go back to supporting that, | |
| 14:04:28 | mriedem | and backport that to ocata | |
| 14:04:29 | mriedem | as a bug fix | |
| 14:04:35 | mriedem | and deprecate it at the same time | |
| 14:04:44 | mriedem | since the deprecation was never done properly before that was broken | |
| 14:04:48 | bauzas | mriedem: that's why I'd say that if we accept custom drivers, instead of passing a path, you should just pass the name of the entrypoint | |
| 14:05:10 | mriedem | i'm not advocating going back to loading from classpath | |
| 14:05:12 | mriedem | separate issues | |
| 14:05:15 | bauzas | mriedem: and just changing the type of the option to not be a choice | |
| 14:05:31 | mriedem | yes the choices kwarg would have to be removed | |
| 14:05:44 | bauzas | sec, verifying oslo.config | |
| 14:06:22 | stephenfin | mriedem: There's a number of interface drivers for nova-net. We're wondering if some of them can be removed because they're untested, possibly unused, and are the sole consumers of large chunks of code https://review.openstack.org/#/c/483030/2/nova/network/linux_net.py | |
| 14:06:30 | sean-k-mooney | mriedem: out of tree scheduler dirver already work today though correct | |
| 14:06:54 | stephenfin | mriedem: But we've no way of telling if someone is using them, so I guess they've just got to stay til cells v2 is ready | |
| 14:07:06 | bauzas | mriedem: okay, I'll write the patch | |
| 14:07:09 | mriedem | sean-k-mooney: no | |
| 14:07:16 | bauzas | mriedem: and I'll add a relnote | |
| 14:07:19 | openstack | Launchpad bug 1704788 in OpenStack Compute (nova) "Hardcoded choices for nova scheduler driver" [Undecided,Confirmed] | |
| 14:07:19 | mriedem | sean-k-mooney: https://bugs.launchpad.net/nova/+bug/1704788 | |
| 14:07:28 | sean-k-mooney | mriedem: i taught we just had to register a nova.scheduler.driver stevador entry point | |
| 14:07:37 | mriedem | that was broken in ocata | |
| 14:07:46 | mriedem | by restricting the scheduler driver config option to use the choices kwarg | |
| 14:07:54 | mriedem | where your only choices are the known in-tree drivers | |
| 14:08:04 | mriedem | https://review.openstack.org/#/c/349666/ | |
| 14:08:22 | mriedem | sean-k-mooney: https://review.openstack.org/#/c/349666/16/nova/conf/scheduler.py@63 | |
| 14:08:55 | sean-k-mooney | mriedem: ah well honestly i think we need to keep this plug point unless we move the scheduler selection into placement which i dont think is the right approch | |
| 14:09:36 | mriedem | sean-k-mooney: why do we need to support out of tree scheduler drivers? | |
| 14:09:45 | mriedem | we want to make filter scheduler driver use placement | |
| 14:09:50 | mriedem | we want to deprecate caching scheduler driver | |
| 14:09:57 | mriedem | the other 2 in tree drivers are basically fakes for testing | |
| 14:10:13 | mriedem | note that the scheduler driver plugin != the scheduler filter plugin | |
| 14:10:39 | mriedem | unless the argument is the same as why we allow out of tree virt drivers | |
| 14:10:43 | sean-k-mooney | mriedem: several operators use costom scheduler and if we want to get to a point where we have a unifed scheduler that means introducing more filters or create a new scheduler | |
| 14:11:07 | mriedem | sean-k-mooney: we don't want to get to a point of a unified scheduler | |
| 14:11:10 | mriedem | gantt is dead | |
| 14:11:21 | mriedem | the nova scheduler is going to be biased toward compute things for nova | |
| 14:11:28 | mriedem | placement is the place to put generic things | |
| 14:11:33 | sean-k-mooney | nova does not most compay i talk to in the mano space do | |
| 14:11:34 | mriedem | consumable by all other services | |
| 14:12:12 | bauzas | mriedem: that's why I asked for questions about why people want custom drivers | |
| 14:12:17 | bauzas | mriedem: not filters | |
| 14:12:54 | bauzas | mriedem: my main point would be that nova would only pass to the scheduler driver hosts that are supported by placement | |
| 14:12:55 | mriedem | i can see it's going to take me awhile to get all of this shit off my shoe that i stepped into yesterday | |
| 14:13:12 | sean-k-mooney | mriedem: i agree with jay that placement should not make scheduling decision but instead return a list of candiates that a scheduler then claims from. the filter schedueler is a good default but it may not be smart enough to cover all usecases | |
| 14:13:26 | bauzas | mriedem: how then the scheduler driver would return a destination between all those supported hosts is possibly something custom | |
| 14:13:38 | mriedem | sean-k-mooney: what does a custom driver buy you that custom filters can't? | |
| 14:14:53 | sean-k-mooney | mriedem: the abblity to intergrate with external inventory systems in addtion to placement to make a desission. i may not like the design of ONAP but in there model they own all inventory resources which is a conclift with how nova works today | |
| 14:15:12 | bauzas | mriedem: I thought about something | |
| 14:15:28 | bauzas | mriedem: what if we would pass a new choice named 'custom' | |
| 14:15:55 | bauzas | mriedem: that would mean that if you choose 'custom', then you need to modify setup.cfg to add a 'custom' entrypoint | |
| 14:15:59 | mriedem | sean-k-mooney: still, you can't do that in a filter? | |
| 14:16:00 | sean-k-mooney | bauzas: i like the idea of tighing the contract for scheduler drivers for queens on to requried them to support placement. | |
| 14:16:17 | openstackgerrit | Sean Dague proposed openstack/nova master: Ironic: Support boot from Cinder volume https://review.openstack.org/215385 | |
| 14:16:29 | bauzas | sean-k-mooney: you can call external inventory systems within a filter | |
| 14:16:53 | bauzas | sean-k-mooney: that said, it will call N times the 3rd party system, N being the number of hosts | |
| 14:17:05 | edleafe | mriedem: sean-k-mooney: like the way that TrustedFilter can call out? | |
| 14:17:10 | bauzas | that's the only limitation of that within a filter | |
| 14:17:18 | bauzas | edleafe: shhhhhttttt | |
| 14:17:25 | mriedem | edleafe: yes that or the attestation filter | |
| 14:17:28 | mriedem | or did i just make that up | |
| 14:17:32 | bauzas | edleafe: I *really* *hate* TrustedFilter | |
| 14:17:39 | bauzas | because it's in tree | |
| 14:17:45 | edleafe | bauzas: me too, but it's "in-tree" :) | |
| 14:17:47 | sean-k-mooney | edleafe: yes that is one example where it needs to talk to an atestation server. | |
| 14:17:58 | bauzas | mriedem: attestation server = silly TrustedFilter | |
| 14:18:13 | mriedem | oh yes | |
| 14:18:23 | mriedem | trusted filter is gone in queens | |
| 14:18:26 | mriedem | so don't complain too much | |
| 14:18:29 | sean-k-mooney | mriedem: bauzas i could do most of this with a costom filter + costum weigher to update the external inventory system with the final choice | |
| 14:18:54 | mriedem | i'd argue the custom external inventory system should be pumping custom resource class information into placement | |
| 14:18:58 | mriedem | which the filter scheduler can then use | |
| 14:19:15 | edleafe | mriedem: that would be best | |
| 14:19:25 | bauzas | hangout time ? | |
| 14:19:32 | edleafe | mriedem: but not always feasible | |
| 14:19:40 | sean-k-mooney | bauzas: the trusted filter today dose not vaildate that the plathfrom trust is still present just that you labled it as such. with the atestation server it dose a mesuared boot and attest the trust is still valid | |
| 14:19:42 | bauzas | I really wanted to explain my thoughts but my brain translates too slow | |
| 14:20:02 | bauzas | so I hope my thoughts could be clearer if I would voice | |