| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 20:17:57 | mriedem | that seems ok | |
| 20:18:37 | dansmith | we really need to be removing the honoring of the limits provided by those filters from compute anyway I think | |
| 20:18:50 | dansmith | we've not really done any culling of stuff that is now handled by placement from compute/rt | |
| 20:20:20 | mriedem | speaking of culling | |
| 20:20:22 | mriedem | _get_all_instance_metadata | |
| 20:20:24 | mriedem | in compute api | |
| 20:20:31 | mriedem | apparently the only things that use that, aren't used by anything else | |
| 20:22:20 | mriedem | i'm going through https://review.openstack.org/#/c/505418/ btw | |
| 20:22:25 | mriedem | hence asking random questions | |
| 20:23:19 | dansmith | thank you | |
| 20:23:53 | dansmith | my devstack setup came back so I'll poke at sysmeta | |
| 20:27:09 | mriedem | ok comments inline | |
| 20:27:23 | dansmith | mriedem: is that one of the tests I pulled out to the cells class in an earlier patch? | |
| 20:27:27 | mriedem | nope | |
| 20:27:28 | mriedem | just looked | |
| 20:27:40 | dansmith | okay | |
| 20:27:59 | mriedem | checking to see if anything else covers that | |
| 20:28:05 | mriedem | we tend to duplicate a lot of our unit tests | |
| 20:30:16 | mriedem | _get_all_instance_metadata is only used by methods that were for the ec2 api | |
| 20:31:03 | mriedem | ec2api repo doesn't call them though | |
| 20:34:07 | dansmith | hmm, got worried for a sec | |
| 20:34:24 | dansmith | baseline was taking 10s instead of 6s from yesterday | |
| 20:34:47 | dansmith | but after the reboot the devstack@dstat.service was consuming two cores for some reason | |
| 20:34:50 | dansmith | hopefully that's why | |
| 20:39:05 | mriedem | ok we return metadata during GET /servers/{server_id} which makes sense, so still need to join on that | |
| 20:39:11 | mriedem | and flavor for flavor, and info_cache for IPs, | |
| 20:39:19 | mriedem | but system_metadata should be able to be nuked from the join in the API | |
| 20:41:07 | mriedem | oh | |
| 20:41:09 | mriedem | geez | |
| 20:41:14 | mriedem | we join on security_groups... | |
| 20:41:25 | mriedem | for no good reason | |
| 20:41:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove unused get_all_instance_*metadata methods https://review.openstack.org/508299 | |
| 20:42:43 | mriedem | gmann: Kevin_Zheng: shouldn't JOINED_TABLE_QUERY_PARAMS_SERVERS include 'tags'? | |
| 20:43:32 | dansmith | hrm, still running slow | |
| 20:44:01 | mriedem | if we removed system_metadata from the default join list in the API, if it was used somewhere, we'd see the "lazy-loading ..." message in the API logs though right? | |
| 20:44:58 | dansmith | yes | |
| 20:50:16 | mriedem | gmann: Kevin_Zheng: oh nvm it can't because "tags" is an actual query parameter | |
| 20:50:33 | dansmith | for a single list operation via curl I really shouldn't be hitting keystone more than once right? | |
| 20:50:53 | mriedem | hmmm | |
| 20:51:05 | mriedem | going to neutron? | |
| 20:51:22 | mriedem | we pass the token to neutron and it has to auth? | |
| 20:51:23 | dansmith | for a list? | |
| 20:51:42 | mriedem | we proxy the security group information during list to neutron | |
| 20:51:53 | dansmith | I'm just trying to figure out why this is taking double what it was yesterday | |
| 20:51:56 | mriedem | i think anyway, this has come up before b/c we don't cache security groups | |
| 20:57:36 | mriedem | nova meeting in 3 minutes | |
| 20:58:49 | mriedem | jaypipes: even if the instance_security_groups table is empty, i'm assuming that listing 1000 instances and joining on that table is not insignificant? | |
| 20:59:38 | mriedem | sorry the security_group_instance_association table | |
| 20:59:57 | jaypipes | mriedem: well, if i_s_g is empty, it's an insignificant thing. | |
| 21:00:28 | jaypipes | mriedem: if there's no records, the join is optimized out by the DB. that said, as soon as it starts to get many records in it, boom. | |
| 21:00:41 | mriedem | if using neutron it shouldn't ever have records in it | |
| 21:00:46 | mriedem | system_metadata totally will though | |
| 21:01:05 | mriedem | anyway, meeting time | |
| 21:01:32 | dansmith | mriedem: I'm restacking to make sure I'm clean and measuring what I expect, because things are taking twice what they should be | |
| 21:02:09 | mriedem | ok | |
| 21:12:37 | jaypipes | efried: care to update https://review.openstack.org/#/c/497713/ to say required= and let's ship it? | |
| 21:12:50 | tonyb | dansmith: I should've added a comment but I'd only just +wd the pike version so I was waiting for that to merge | |
| 21:13:08 | dansmith | tonyb: okay, well I hit it anyway | |
| 21:13:12 | efried | jaypipes Sure, I can do that. | |
| 21:13:26 | jaypipes | efried: ty | |
| 21:16:16 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Add trait support in the allocation candidates API https://review.openstack.org/497713 | |
| 21:16:22 | efried | jaypipes hecho ^ | |
| 21:16:42 | jaypipes | efried: danke | |
| 21:18:42 | cdent | i guess I better actually read that one | |
| 21:19:05 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix CellDatabases fixture swallowing exceptions https://review.openstack.org/506312 | |
| 21:19:05 | openstackgerrit | Dan Smith proposed openstack/nova master: Use improved instance_list module in compute API https://review.openstack.org/505418 | |
| 21:19:06 | openstackgerrit | Dan Smith proposed openstack/nova master: Move cell marker tests to Cellsv1DeprecatedTestMixIn https://review.openstack.org/508314 | |
| 21:19:06 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix minor input items from previous patches https://review.openstack.org/506416 | |
| 21:25:13 | efried | jaypipes Oh, did you mean https://review.openstack.org/#/c/468797/ ? I can update that one too... | |
| 21:25:30 | jaypipes | efried: that would be great, too. | |
| 21:25:37 | jaypipes | efried: that's the flavor changes, right? | |
| 21:25:51 | efried | They're different, mind you: one's in flavor and the other's in API. But with the current proposals I don't see any reason they shouldn't both be required= | |
| 21:26:10 | jaypipes | efried: agreed completely. they should match. | |
| 21:27:27 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Request traits in Nova https://review.openstack.org/468797 | |
| 21:27:34 | efried | jaypipes ^ | |
| 21:27:41 | jaypipes | efried: danke | |
| 21:27:46 | efried | bitte | |
| 21:30:12 | efried | jaypipes of Nederland als je wil | |
| 21:30:58 | jaypipes | efried: no. I speak only English. and badly at that. | |
| 21:32:39 | cdent | efried: I’m sensing a good deal of polylingualism in your direction | |
| 21:33:01 | efried | jaypipes Oh, I thought you had some Dutch, or Afrikaans. | |
| 21:33:07 | efried | cdent You could say I'm a cunning linguist. | |
| 21:33:40 | efried | If only I could learn python | |
| 21:34:57 | takashin | oomichi: Are you around? | |
| 21:37:43 | efried | cdent "The traits don't belong to the children do they, they just happen to be present because the parent is present. You can't have the trait without the parent, right?" <== talk to me | |
| 21:38:21 | efried | Any RP can have traits. The paragraph in question is talking about how traits inherit in a NRP tree and (not) in aggregates. | |
| 21:39:03 | efried | The paragraph is saying that a parent RP's traits implicitly also belong to its descendants, but not the other way around. | |
| 21:39:06 | cdent | a) how traits behave in rps is not relevant to that spec is it. That spec is merely saying “I require this trait”, so the paragraph is not required and merely confuses (it did me) | |
| 21:39:53 | efried | cdent Mm, I think it's relevant to understanding what you're expecting to get back when you specify those required traits. | |
| 21:40:20 | efried | And also how the implementor of the RPs should model them in order for that to be effective. | |
| 21:40:26 | cdent | it means you’ll get back some resource providers, one of which will have that trait, that’s all | |
| 21:40:32 | cdent | s/one/at least one/ | |
| 21:40:46 | efried | I believe that paragraph indicates that that is not completely true. | |
| 21:40:58 | cdent | explain? | |
| 21:41:11 | efried | Because I could get back a leaf RP that doesn't actually have the trait explicitly itself, but got returned because its parent/ancestor had that trait. | |
| 21:41:42 | cdent | and that’s my question: you’ll only see that leaf in the results if you are _also_ seeing the ancestor in the results | |
| 21:41:44 | efried | It's unclear (but needs to be clarified) whether the API is gonna populate the leaf RP's traits with all the ancestors' traits as it returns it. | |
| 21:42:19 | efried | Yeah, that's another good question: are you going to get back the parent RP in the response? If so, it's likely not to have any inventory allocated out of it. | |
| 21:42:26 | efried | is that kosher? | |
| 21:43:35 | cdent | that’s indeed a tricky question, because we’ve where a VCPU lives in a NUMA world ambiguous in our questions | |