| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-06 | |||
| 13:35:50 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.volume_detach notification https://review.openstack.org/408676 | |
| 13:36:25 | mriedem | njohnston: https://developer.openstack.org/api-ref/compute/#quota-sets-os-quota-sets | |
| 13:36:55 | johnthetubaguy | mriedem: njohnston: I wonder if you have to turn on the extension in the API, if you go back that far, or rather your config might have turned it off | |
| 13:38:11 | mriedem | johnthetubaguy: wanted to ask you about this given you're familiarity with all things caching scheduler https://review.openstack.org/#/c/453916/ | |
| 13:38:32 | mriedem | johnthetubaguy: i assume rax is setting CONF.filter_scheduler.track_instance_changes = False? | |
| 13:38:39 | njohnston | johnthetubaguy mriedem: I assumed that call was how Horizon was displaying it's array of quota pie charts, since the data returned is pretty much perfect for it. So since I see the pie charts in my Horizon I was hopeful it would work. | |
| 13:38:40 | mriedem | so the computes don't send instance updates to the caching scheduler, which doesn't use them | |
| 13:39:08 | mriedem | njohnston: to debug your curl request, you could use nova client with the --debug option | |
| 13:39:40 | openstackgerrit | Dinesh Bhor proposed openstack/nova master: Refactor: Move post method to APIValidationTestCase base class https://review.openstack.org/364687 | |
| 13:39:41 | mriedem | njohnston: nova --debug quota-show tenant_id | |
| 13:39:53 | johnthetubaguy | mriedem: not sure we are running a new enough nova | |
| 13:39:55 | mriedem | * nova --debug quota-show --tenant <tenant_id> --detail | |
| 13:40:07 | mriedem | johnthetubaguy: i think those are pretty old options | |
| 13:40:11 | mriedem | for the instance update stuff | |
| 13:41:06 | mriedem | johnthetubaguy: i just noticed yesterday the config docs saying track_instance_updates is only used for the filter scheduler, but it defaults to true and so nova compute is always sending those, unless you change it when you change the scheduler.driver | |
| 13:41:22 | mriedem | seems we could be smarter and just not look at that option at all if you're not using the filter scheduler | |
| 13:41:37 | mriedem | way back before we had a hard list of scheduler drivers and it was just loaded from classpath, we couldn't really do this | |
| 13:41:40 | mriedem | but i think it's safe now | |
| 13:42:05 | johnthetubaguy | maybe, added a comment on that patch, we don't actually configure the scheduler settings on any node other than the scheduler | |
| 13:42:39 | johnthetubaguy | but I like your approach, it makes more sense overall, we just need to train folks about configuration more | |
| 13:44:39 | johnthetubaguy | mriedem: actually, I think we proabably just turned that off because we didn't use filters that need that info | |
| 13:44:48 | johnthetubaguy | mriedem: but anyways, seems worth a peak | |
| 13:45:06 | mriedem | so i was worried about that, | |
| 13:45:14 | mriedem | because if you don't configure the scheduler things on the compute node, | |
| 13:45:29 | mriedem | that means you get the default, so nova compute is doing all of this extra rpc traffic to send something your scheduler doesn't care about | |
| 13:45:49 | johnthetubaguy | yeah, that does suck | |
| 13:46:33 | johnthetubaguy | we had this debate a few times, we should really look at being more specific on the idea of what configurations should be set where | |
| 13:47:14 | mriedem | i didn't realize until yesterday that this was scheduler config used on the comptues | |
| 13:47:18 | mriedem | but yeah it's pretty nasty | |
| 13:47:28 | mriedem | i guess the silver lining is, | |
| 13:47:32 | mriedem | when caching scheduler is gone, | |
| 13:47:37 | mriedem | so is this config option | |
| 13:47:57 | mriedem | because the only options you'd have then are filter, chance and fake, and the latter two are test-only | |
| 13:48:34 | bauzas | mriedem: remember we have 3 drivers in tree | |
| 13:48:37 | bauzas | not only 2 | |
| 13:48:47 | mriedem | we have 4 drivers in tree | |
| 13:48:54 | mriedem | caching, filter, chance and fake | |
| 13:49:01 | mriedem | the scheduler.driver option uses the choices kwarg | |
| 13:49:11 | mriedem | so unless you fork that, it's a ValueError to specify something else | |
| 13:49:25 | johnthetubaguy | remembers macsz saying something about stevedoor^ | |
| 13:50:25 | mriedem | https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L58 | |
| 13:50:42 | mriedem | https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L79 | |
| 13:50:50 | mriedem | i don't see how ^ is right since we use choices | |
| 13:50:56 | mriedem | "A custom scheduler driver. In this case, you will be responsible for creating and maintaining the entry point in your 'setup.cfg' file" | |
| 13:51:05 | mriedem | choices=("filter_scheduler", "caching_scheduler", "chance_scheduler", "fake_scheduler"), | |
| 13:51:11 | bauzas | mriedem: FWIW, the FakeScheduler is not existing in tree | |
| 13:51:30 | bauzas | afaik, it's only in the tests tree | |
| 13:51:45 | bauzas | you can't deploy it | |
| 13:51:47 | johnthetubaguy | yeah, its meant to be stevedoor I think | |
| 13:52:10 | dansmith | mriedem: yeah that scheduler config is nasty, and it's an upcall :( | |
| 13:52:11 | bauzas | johnthetubaguy: we already load with stevedore :) | |
| 13:52:19 | dansmith | mriedem: that was part of the source of my frustration with this crap last week | |
| 13:52:24 | johnthetubaguy | oh, maybe choices was a step too far then | |
| 13:52:47 | bauzas | dansmith: oh, you weren't knowing that computes fanout the scheduler ? | |
| 13:52:50 | mriedem | the choices definitely breaks any stevedore loading of custom drivers | |
| 13:53:11 | dansmith | bauzas: I knew we had this but it's not something I think about much | |
| 13:53:39 | bauzas | dansmith: maybe we could use placement rather, because it's for providing aggregate and instance values | |
| 13:54:07 | mriedem | https://github.com/openstack/nova/commit/fe3d6dba3d1db8f97dab4baffcc11dda56368096 | |
| 13:54:07 | dansmith | bauzas: we can't use placement for the affinity bits yet, which is what this is for, AFAIK | |
| 13:54:09 | bauzas | dansmith: I created those RPCAPI methods because I wasn't accepting the scheduler filters calling DB | |
| 13:54:40 | bauzas | mriedem: anyway, operators can run custom filters that call their own scheduler :) | |
| 13:54:42 | mriedem | anyway i'm pretty sure https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L79 doesn't work | |
| 13:54:50 | mriedem | bauzas: that's fine | |
| 13:55:00 | mriedem | but if you can't load up your own scheduler "driver" we should remove this line https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L79 | |
| 13:55:20 | bauzas | mriedem: I'm fine with stopping to have a custom driver | |
| 13:55:22 | mriedem | https://github.com/openstack/nova/commit/6832a417c93046750ec7eff51eb59be802fd70dc | |
| 13:55:41 | openstack | Launchpad bug 1516703 in OpenStack Compute (nova) "crypto.py generates certs with SHA-1 digest" [Medium,New] | |
| 13:55:41 | dane-fichter | mriedem: peter mentioned that you wanted us to look into https://bugs.launchpad.net/nova/+bug/1516703 ? | |
| 13:55:43 | johnthetubaguy | mriedem: yeah, leaving the custom bit in there is misleading/inconsistent | |
| 13:55:43 | bauzas | rather, in case operators want to use their own scheduler, they just need to use a filter | |
| 13:56:12 | mriedem | dane-fichter: yeah it's just an old bug, if it doesn't make sense we should invalidate or mark as won't fix | |
| 13:56:29 | bauzas | mriedem: like I also said, https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L61 is wrong, because fake_scheduler doesn't exist in tree | |
| 13:56:48 | johnthetubaguy | mriedem: that might actually be a hyper-v thing from claudiub and team? | |
| 13:56:51 | mriedem | it has to be in choices to workaround oslo | |
| 13:57:05 | mriedem | johnthetubaguy: not sure what that means | |
| 13:57:09 | dane-fichter | mriedem: nova cert is being removed this cycle right? Seems like this functionality should be removed as well | |
| 13:57:14 | johnthetubaguy | mriedem: we added that for hyper-v I think | |
| 13:57:18 | mriedem | dane-fichter: there is a spec for that | |
| 13:57:25 | mriedem | johnthetubaguy: added what for hyperv? | |
| 13:57:26 | mriedem | fake_scheduler? | |
| 13:57:33 | johnthetubaguy | x.509 cert generation | |
| 13:57:39 | johnthetubaguy | to replace the ssh keypair type | |
| 13:57:41 | bauzas | dansmith: anyway, I tried to think about reschedules | |
| 13:57:48 | bauzas | dansmith: I still think we need them | |
| 13:57:57 | bauzas | because of X or Y | |
| 13:58:37 | dansmith | X or Y? | |
| 13:58:52 | mriedem | nova meeting in 2 minutes | |
| 14:00:23 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: WIP: implement API version 1.0 https://review.openstack.org/451877 | |
| 14:02:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove a fallacy in scheduler.driver config option help text https://review.openstack.org/454196 | |
| 14:04:17 | claudiub | mriedem: johnthetubaguy you mean the x509 certificates? | |
| 14:04:29 | johnthetubaguy | yeah, for windows auth | |
| 14:04:30 | claudiub | those would the windows equivalent of ssh keys | |
| 14:04:43 | claudiub | so, not hyper-v specific, windows guests specific | |
| 14:05:19 | dane-fichter | johnthetubaguy: So what I'm hearing is that generate_winrm_x509_cert() is still needed? | |
| 14:05:30 | johnthetubaguy | dane-fichter: I think so, yeah | |
| 14:05:38 | johnthetubaguy | dane-fichter: even after we kill nova-cert | |
| 14:05:51 | openstackgerrit | Dan Smith proposed openstack/nova master: Add functional test for two-cell scheduler behaviors https://review.openstack.org/452006 | |
| 14:05:54 | dane-fichter | johnthetubaguy: ok. good to know. | |
| 14:06:29 | johnthetubaguy | dane-fichter: although I am willing to believe its something we should deprecate in the API, us generating certs is probably the wrong thing to do for winRM, but I am not sure | |
| 14:06:47 | johnthetubaguy | dane-fichter: needs a look, I guess | |