| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-06 | |||
| 20:08:14 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Deprecate certs commands and APIs https://review.openstack.org/454326 | |
| 20:08:17 | mriedem | macsz: ^ | |
| 20:09:01 | macsz | mriedem: should i draft a spec for it? | |
| 20:12:11 | mriedem | macsz: for what? | |
| 20:12:17 | mriedem | cloudpipe/ | |
| 20:12:18 | mriedem | sure | |
| 20:12:35 | macsz | or can we smuggle it under the cert deprecation banner? | |
| 20:12:47 | sdague | macsz: I'm pro smuggle | |
| 20:13:06 | mriedem | if we smuggle, we should probably amend the spec | |
| 20:13:11 | sdague | mriedem: yeh | |
| 20:13:14 | macsz | the spec was merged, but i can also do a follow-up patch that modifies the current spec | |
| 20:13:26 | sdague | macsz: ++ an ammend would be great | |
| 20:13:27 | macsz | yeah, shorter way to say what i meant | |
| 20:20:47 | openstackgerrit | Sihan Wang proposed openstack/nova master: Update checking vm state in vmware driver https://review.openstack.org/454328 | |
| 20:22:01 | macsz | mriedem: it seems that os-cloudpipe is already deprecated | |
| 20:22:02 | macsz | https://github.com/openstack/nova/blob/master/api-ref/source/os-cloudpipe.inc | |
| 20:23:13 | mriedem | just in the docs | |
| 20:23:31 | mriedem | it doesn't return an error though on any microversion like 2.36 would for listing networks | |
| 20:24:14 | mriedem | i don't know if we're proposing to just remove it, like os-certificates, or deprecating it with a microversion, but if we remove nova-network and nova-cert, then it seems kind of pointless to do the microversoin | |
| 20:24:16 | mriedem | sdague: ^ thoughts? | |
| 20:26:20 | macsz | doc mentions that os-cloudpipe works only with nova-net, so there is really no point in having it around, with or without nova-cert, it seems | |
| 20:27:16 | mriedem | we still have nova-net | |
| 20:27:20 | mriedem | although | |
| 20:27:24 | mriedem | nova-net is cells v1 only now | |
| 20:27:33 | mriedem | and i assume os-cloudpipe doesn't work with cells v1 | |
| 20:29:06 | mriedem | it might, it's a weird orchestration api that creates an instance for you | |
| 20:29:10 | mriedem | with a configured vpn image | |
| 20:30:04 | mriedem | so the cloudpipe api should have been deprecated with 2.36 when we did the other nova-net stuff, like multinic | |
| 20:30:24 | mriedem | alex_xu: is deprecating the multinic api https://review.openstack.org/#/c/384261/ | |
| 20:30:32 | mriedem | since it's nova-net really | |
| 20:30:41 | mriedem | maybe we should do cloudpipe and multinic in the same spec? | |
| 20:30:42 | openstackgerrit | Sihan Wang proposed openstack/nova master: Update checking vm state in vmware driver https://review.openstack.org/454328 | |
| 20:31:16 | mriedem | but if you need os-certificates to use os-cloudpipe and we remove os-certificates, then... | |
| 20:31:45 | sdague | mriedem: yeh, I feel like we should just couple it to the os-certificates delete | |
| 20:31:50 | mriedem | that's fine | |
| 20:33:31 | macsz | is there a spec for os-certificates? | |
| 20:33:41 | mriedem | dansmith: so i'm trying to think about impacts with your workaround config, and what if any other config options we should note are related to that one, like track_instance_changes | |
| 20:33:46 | mriedem | since i think track_instance_changes is tied to affinity | |
| 20:33:57 | mriedem | macsz: your one for removing nova-cert :) | |
| 20:34:00 | mriedem | remember?! | |
| 20:34:11 | macsz | xD | |
| 20:34:22 | macsz | yeah, i do... :D | |
| 20:34:38 | mriedem | dansmith: i'm trying to sort out where the instance info stuff that the computes send up to the scheduler is used | |
| 20:34:45 | macsz | did not connect the dots between nova-cert and os-certificates ;) | |
| 20:37:26 | openstackgerrit | Maciej Szankin proposed openstack/nova-specs master: Add os-cloudpipe to remove-nova-cert spec https://review.openstack.org/454332 | |
| 20:43:44 | dansmith | mriedem: yeah, so track changes will also not work, so maybe I should mention that in there for the connection | |
| 20:43:55 | mriedem | dansmith: i left a comment about that in the review | |
| 20:43:58 | dansmith | okay | |
| 20:44:01 | mriedem | i'm just looking at how all of this crap gets used | |
| 20:44:13 | dansmith | it's fairly terribad | |
| 20:44:13 | mriedem | and all of it is just for the affinity/anti-affinity filters/weighers it looks like | |
| 20:44:19 | dansmith | right | |
| 20:44:21 | dansmith | it's nuts | |
| 20:44:22 | mriedem | so a ton of code just for those | |
| 20:44:26 | dansmith | right | |
| 20:44:51 | mriedem | ok i also need to update https://review.openstack.org/#/c/453916/ since i didn't realize the compute manager and host manager were doing the exact same thing in the init | |
| 20:44:55 | dansmith | claims in the scheduler will let us do affinity without all that stuff | |
| 20:45:17 | cdent | mriedem: I haven't caught up on backlog, but are you looking at the stuff that does affinity based on live host/instance info? | |
| 20:45:28 | mriedem | so if you're using caching scheduler or not using these filters/weighers, and not paying attention to default options, you could have all of this extra rpc traffic and db lookups for nothing | |
| 20:45:47 | mriedem | cdent: it's the instance info stuff in the host manager and scheduler filter yeah | |
| 20:46:13 | dansmith | this mess is the source of my tweet from last week :) | |
| 20:46:17 | mriedem | dansmith: like https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L731 | |
| 20:46:31 | mriedem | if we knew you weren't using those filters/weighers, that could just be a noop | |
| 20:46:37 | mriedem | but, those are defaults so i guess... | |
| 20:46:47 | cdent | those are the things that make me say that we'll never have a fully single transaction placement engine | |
| 20:46:48 | dansmith | mriedem: well, also, | |
| 20:46:55 | dansmith | mriedem: compute sends instance info when an instance boots, | |
| 20:47:03 | dansmith | mriedem: but host manager just uses that as a trigger to re-query the db | |
| 20:47:05 | dansmith | it's madness | |
| 20:47:20 | mriedem | to refresh it's cache right? | |
| 20:47:36 | dansmith | yeah | |
| 20:47:37 | dansmith | but it sends the whole instance, | |
| 20:47:40 | dansmith | and we just ignore it and re-query | |
| 20:47:43 | dansmith | unless it sends all of them, | |
| 20:47:45 | dansmith | and then we assume it's right | |
| 20:48:07 | mriedem | cripes | |
| 20:48:09 | dansmith | it's very complicated and wasteful | |
| 20:49:26 | mriedem | "ServerGroupAntiAffinityFilter", | |
| 20:49:27 | mriedem | "ServerGroupAffinityFilter", are default filters | |
| 20:49:35 | mriedem | and filter scheduler is default | |
| 20:49:39 | mriedem | and track_instance_changes is on by default | |
| 20:50:34 | mriedem | oh, and | |
| 20:50:51 | mriedem | all computes have a periodic task that run every 2 minutes by default to pull all instances from that host and send them to the scheduler | |
| 20:51:07 | cdent | huzzah | |
| 20:51:18 | dansmith | which nobody can have enabled at that frequency with a reasonable number of computes I'm sure | |
| 20:51:18 | mriedem | i wonder if that filters out deleted instances... | |
| 20:51:56 | mriedem | oh plus that does the big default joins | |
| 20:52:48 | dansmith | of course | |
| 20:52:52 | dansmith | go big or go home | |
| 20:52:56 | mriedem | well maybe we don't | |
| 20:53:00 | mriedem | we pass expected_attrs=[] | |
| 20:53:04 | mriedem | to try and trick that i think | |
| 20:53:14 | dansmith | okay yeah that won't do the joins then | |
| 20:53:16 | dansmith | BUT | |
| 20:53:18 | dansmith | still stupid :) | |
| 20:53:20 | mriedem | but i wouldn't be surprised if there is an "if not expected_attrs: expected_attrs = DEFAULT_BIG_ASS_LIST" | |
| 20:53:35 | dansmith | no it checks =None | |
| 20:53:37 | dansmith | =None means default =[] means nothing | |
| 20:53:55 | mriedem | i was thinking the db api | |
| 20:54:05 | mriedem | so, | |