| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 13:57:33 | mriedem | so now, we might pass api and get to conductor and fail, and then you've got 20 ERROR instances to cleanup | |
| 13:57:36 | mriedem | if you're bursting | |
| 13:57:46 | bauzas | mriedem: FWIW, I left a comment for https://bugs.launchpad.net/nova/+bug/1704788 | |
| 13:57:47 | openstack | Launchpad bug 1704788 in OpenStack Compute (nova) "Hardcoded choices for nova scheduler driver" [Undecided,Confirmed] | |
| 13:58:02 | dansmith | mriedem: because sometimes the instance and build request exist together for a second, you would end up racing to consume your last instance if you're doing a lot of builds, but maybe that's better I dunno | |
| 13:58:38 | mriedem | bauzas: where was "because that would mean we would go against the consensus we had in Ocata." documented? | |
| 13:58:39 | dansmith | mriedem: my head is in something else atm, so let us chat with melwitt when she's around | |
| 13:58:53 | bhagyashris | jaypipes, gibi: yeah now it's 7:30 pm here | |
| 13:58:59 | jangutter | stephenfin: somewhere, someone still has linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver set in a production config, and they are planning to use it in Queens. | |
| 13:58:59 | mriedem | dansmith: sure, and i'm not liking the idea of adding more complexity to this pile | |
| 13:59:05 | mriedem | just got thinking about it though | |
| 13:59:16 | bauzas | mriedem: I don't remember exactly when we discussed that, but AFAIR we said that having custom drivers was not something good | |
| 13:59:26 | jaypipes | gibi: in your script, after line 157, can you call GET /allocation_candidates?resources=CUSTOM_MAGIC:512 and tell me what is returned please? | |
| 14:00:19 | mriedem | bauzas: regardless i think we scrooged the pooch, as the french would say, when it came to that choices restriction being put in since we didn't have a deprecation period on non-standard drivers | |
| 14:00:21 | dansmith | mriedem: yeah, kindof a big thing to change at this point | |
| 14:00:27 | mriedem | *screwed the pooch | |
| 14:00:28 | mriedem | wow | |
| 14:00:44 | stephenfin | jangutter: Possibly, but if they do then they're using nova-net and we won't/can't support them anymore because it's deprecated | |
| 14:00:55 | bauzas | mriedem: possibly | |
| 14:01:14 | openstackgerrit | Alex Szarka proposed openstack/nova master: Refactor create_delete_server_with_instance_update https://review.openstack.org/466296 | |
| 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 | mriedem | sean-k-mooney: https://bugs.launchpad.net/nova/+bug/1704788 | |
| 14:07:19 | openstack | Launchpad bug 1704788 in OpenStack Compute (nova) "Hardcoded choices for nova scheduler driver" [Undecided,Confirmed] | |
| 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 | |