| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-06 | |||
| 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, | |
| 20:54:07 | mriedem | instance_get_all_by_host in the db api, | |
| 20:54:11 | mriedem | does not filter out deleted instances | |
| 20:54:17 | dansmith | WAT | |
| 20:54:30 | mriedem | oh wait | |
| 20:54:36 | mriedem | model_query filters deleted right? | |
| 20:54:40 | dansmith | depends on context | |
| 20:54:59 | openstackgerrit | Sihan Wang proposed openstack/nova master: Update checking vm state in vmware driver https://review.openstack.org/454328 | |
| 20:56:10 | mriedem | def _instance_get_all_query(context, project_only=False, joins=None): | |
| 20:56:10 | mriedem | if joins is None: | |
| 20:56:10 | mriedem | joins = ['info_cache', 'security_groups'] | |
| 20:56:20 | mriedem | so we are at least joining on those mofos | |
| 20:56:34 | dansmith | but should be not =None there if we're passing =[] | |
| 20:56:39 | mriedem | not there | |
| 20:57:00 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2530 | |
| 20:57:09 | mriedem | we don't pass columns_to_join to _instance_get_all_query | |
| 20:57:10 | dansmith | you said we were passing expected_attrs=[] right? | |
| 20:57:11 | mriedem | so it's None | |
| 20:57:22 | mriedem | we pass [] to _instances_fill_metadata | |
| 20:57:28 | mriedem | but not _instance_get_all_query | |
| 20:57:35 | dansmith | ah | |
| 20:57:39 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2513 | |
| 20:57:39 | dansmith | so the funny thing is, | |
| 20:57:53 | dansmith | if we just sent an empty call to that update method on the scheduler, | |
| 20:58:02 | dansmith | it would do it itself, direct from the db, no big rpc involved | |
| 20:58:11 | dansmith | because remember this goes compute->conductor->compute->scheduler over rpc | |
| 20:58:25 | dansmith | but if you just call that method with an empty list, | |
| 20:58:33 | dansmith | scheduler will just pull it itself without any rpc | |
| 20:58:39 | cdent | ha! | |
| 20:58:40 | mriedem | that's _update_scheduler_instance_info ? | |
| 20:58:40 | dansmith | or maybe something else to fool it | |
| 20:58:47 | dansmith | whatever that scheduler rpc call is | |
| 20:58:48 | cdent | that's awesome | |
| 20:59:06 | dansmith | cdent: we should figure out more places to route that through | |
| 20:59:20 | dansmith | compute->conductor->compute->twitter->facebook->compute->conductor->super-conductor->scheduler | |
| 20:59:38 | cdent | i think you left out the pigeon | |
| 20:59:53 | dansmith | heh | |
| 21:00:27 | mriedem | dansmith: you're talking about this right? https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L767 | |
| 21:00:30 | mriedem | where it does the full pull | |
| 21:00:43 | dansmith | mriedem: yeah | |
| 21:00:51 | mriedem | but that's only if it doesn't already have a list for the host | |
| 21:01:02 | mriedem | https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L752 | |
| 21:01:09 | mriedem | that gets created when the compute starts up | |
| 21:01:19 | mriedem | which is what we were talking about yesterday | |
| 21:01:35 | dansmith | sure, but we're still sending it | |
| 21:01:36 | dansmith | for no reason | |
| 21:01:42 | mriedem | yes that's dumb too | |
| 21:01:43 | dansmith | we'd have to tweak the logic there just a bit, agreed | |
| 21:01:54 | mriedem | i'm just thinking https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L767 is a complete fallback | |
| 21:02:05 | mriedem | if the compute host didn't send the instances on startup | |
| 21:02:09 | mriedem | to register itself with the scheduler | |
| 21:02:15 | mriedem | err host manager | |
| 21:02:32 | mriedem | https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L761 is the compute start case | |
| 21:02:41 | mriedem | well, unless it's a new compute with no hosts | |
| 21:02:42 | dansmith | we only get here in the rpc call right? | |
| 21:02:46 | mriedem | yeah | |
| 21:02:58 | dansmith | otherwise if we need host info before it has called in, we just generate it ourself anyway | |
| 21:03:04 | mriedem | _update_scheduler_instance_info in the compute manager is called on (1) startup and (2) when a new instance is created | |
| 21:03:13 | mriedem | yeah | |
| 21:03:16 | dansmith | and in a periodic right? | |
| 21:03:23 | mriedem | no | |
| 21:03:31 | mriedem | that's _sync_scheduler_instance_info | |
| 21:03:44 | mriedem | that sends the uuids | |
| 21:04:18 | chatter29 | hey guys | |
| 21:04:24 | mriedem | dansmith: and in instance_uuids | |
| 21:04:38 | mriedem | if the set that the host manager knew about doesn't match what was passed in, it pulls them all from the db again | |
| 21:04:40 | mriedem | for that compute | |
| 21:04:47 | chatter29 | allah is doing | |
| 21:04:53 | chatter29 | sun is not doing allah is doing | |
| 21:04:55 | chatter29 | to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger | |
| 21:05:06 | dansmith | mriedem: okay yeah, I see | |
| 21:05:16 | dansmith | mriedem: I was conflating those two I guess | |
| 21:06:27 | dansmith | mriedem: why do we have to send the whole instance? | |
| 21:06:42 | mriedem | because the host manager caches the list by host | |
| 21:06:47 | dansmith | mriedem: we only really care about the uuids for affinity, AFAIK, but we're sending the instance a bunch of places from computemaanger | |
| 21:06:51 | mriedem | and then the affinity filter/weigher uses those | |
| 21:06:55 | dansmith | sure, but we neednly send the whole object for that | |
| 21:07:02 | mriedem | let me see how they use them | |
| 21:07:02 | dansmith | needn't | |
| 21:07:15 | mriedem | back when these were simple single-level dicts it was maybe not as big a deal | |
| 21:07:21 | mriedem | now it's a behemoth of nested goodness | |
| 21:07:35 | mriedem | maybe this is why we fucking kill ram usage in a single node devstack run :) | |
| 21:07:50 | dansmith | same number of instances regardless :) | |
| 21:08:19 | clarkb | mriedem: "remember when devstack needed 1GB of ram to run?" :) | |
| 21:08:35 | mriedem | instance group members are just instance uuids right? | |
| 21:08:59 | mriedem | yeah, so this whole big ass cache of hosts -> instances for the affinity filter/weigher JUST NEEDS UUIDS | |
| 21:09:30 | mriedem | 'members': fields.ListOfStringsField(nullable=True), | |
| 21:09:36 | mriedem | Yeah InstanceGroup.members is just instance uuids | |