| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 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: Use improved instance_list module in compute API https://review.openstack.org/505418 | |
| 21:19:05 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix CellDatabases fixture swallowing exceptions https://review.openstack.org/506312 | |
| 21:19:06 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix minor input items from previous patches https://review.openstack.org/506416 | |
| 21:19:06 | openstackgerrit | Dan Smith proposed openstack/nova master: Move cell marker tests to Cellsv1DeprecatedTestMixIn https://review.openstack.org/508314 | |
| 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 | |
| 21:44:06 | cdent | the early assumptions were it would be on the compute node instance (the ultimate parent of any tree returned in allocation_candidates) | |
| 21:44:24 | cdent | so there would always be inventory consumed at the top | |
| 21:45:05 | cdent | but even if inventory is not consume at the top we must have the resource provider uuid of the compute node so we know what the destination is | |
| 21:45:37 | edleafe | we are always returning root RPs, right? | |
| 21:45:47 | cdent | so even if the allocation part of the allocation candiate doesn’t consumer, there will be a record in the other half of the tuple which has the roots | |
| 21:45:59 | edleafe | IOW, we'd never return a NIC by itself | |
| 21:46:04 | cdent | edleafe: i think so, yes, at least in the resource providers half of the tuple | |
| 21:46:06 | efried | More recently we've talked about modeling NUMA by making the NUMA nodes child RPs and having them provide the CPU/MEM(/possibly-other-things-like-PFs) resources. | |
| 21:46:17 | cdent | efried: right, but they are still a child | |
| 21:46:32 | efried | Well, okay, but if the tree is three deep, the root RP may still not have the traits the leaf is inheriting. | |
| 21:46:32 | cdent | so you could alloc against them, but still _place_ on the parent | |
| 21:46:52 | cdent | I think inheritance is a very bad way of thinking of this | |
| 21:46:59 | cdent | and that’s what my comment was inspired by | |
| 21:47:04 | cdent | (on the review) | |
| 21:48:07 | cdent | which spec has allocation candidates? | |
| 21:48:38 | edleafe | cdent: yeah, this is more like composition than inheritance | |
| 21:49:00 | cdent | ah, it’s got the wrong name: http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/placement-allocation-requests.html | |
| 21:49:25 | dansmith | gah | |
| 21:49:31 | dansmith | does anyone else get stopped in devstack doing this? | |
| 21:49:31 | dansmith | 403 Forbidden: You are not authorized to complete publicize_image action. (HTTP 403) | |
| 21:49:50 | dansmith | must be residue leftover from my previous install, but I don't know what it is | |
| 21:50:35 | cdent | efried: in there, provider_summaries is the second half of the tuple, contains the rp info. in there will be represented the info to construct a nested provider hierarchy, I don’t know if that’s defined yet | |
| 21:50:56 | cdent | efried: but in that a trait will be on the thing to which the trait was associated, not its children | |
| 21:51:30 | efried | cdent You could totally return *just* the RPs that are being claimed against, and the scheduler would have to use the root RP UUID to pull the whole tree from placement at that point. | |
| 21:52:10 | efried | Or you could return the whole tree, and the scheduler would not have to do that, but there would be empty "allocations". | |
| 21:52:11 | cdent | you could, yes, but I don’t think that was the plan. I suggested at one point we should just return uuids and require the client to go back for more info if it wanted | |
| 21:52:26 | efried | Or you could return just the claimed RPs in the allocations, but return the whole RP trees in the provider summaries. | |
| 21:52:26 | cdent | why would there be empty allocations? | |
| 21:52:51 | cdent | the structure in provider_summaries is not directly mapped to what is in allocations | |
| 21:52:54 | mriedem | dansmith: making an image public? | |
| 21:53:06 | mriedem | but devstack uploads the image... | |
| 21:53:07 | dansmith | mriedem: that's just during stack | |
| 21:53:43 | efried | dansmith Could be perms in your configured temp dir, which glance uses to store a copy of the image while it's uploading it. | |
| 21:54:02 | dansmith | efried: I dunno what would have changed from one stack run to another | |