| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 17:10:13 | bauzas | no need to change the virt driver interface | |
| 17:10:14 | efried | dansmith: Yes. And virt drivers have to use it. Which is okay with me. | |
| 17:10:19 | dansmith | efried: where provider would be any element in the tree | |
| 17:10:20 | jaypipes | doh, jinx | |
| 17:10:24 | dansmith | efried: yeah, I think that's fine | |
| 17:10:42 | bauzas | the merge_traits() thing is a compute manager method, right? | |
| 17:10:45 | efried | dansmith: But to clarify, it still means the virt driver is responsible for merging traits. | |
| 17:10:48 | dansmith | bauzas: no | |
| 17:10:50 | jaypipes | bauzas: no. ProviderTree | |
| 17:10:54 | efried | ^ | |
| 17:11:00 | bauzas | meh to that | |
| 17:11:04 | dansmith | efried: understood, and I don't like that as much, but I'm willing to defer that argument until later :) | |
| 17:11:18 | bauzas | I mean, the caller would be the compute manager ? | |
| 17:11:19 | dansmith | efried: so I still don't think this is a major disruption, just a change in protocol a little bit | |
| 17:11:25 | dansmith | bauzas: in some cases | |
| 17:11:30 | dansmith | bauzas: but not the ones we're talking about here | |
| 17:11:39 | bauzas | I'm missing some cases then | |
| 17:11:42 | efried | dansmith: Not really even that. The only thing we would need to change about what's proposed is the u_p_t docstring. | |
| 17:11:48 | bauzas | but I don't want to rathole | |
| 17:12:05 | efried | Adding the ProviderTree.merge_traits method is a nice-to-have, but until then, u_p_t could still do that manually. | |
| 17:12:17 | bauzas | oh, unrelated, I'll take a couple of days off | |
| 17:12:19 | dansmith | efried: um, not sure about that | |
| 17:12:22 | jaypipes | bauzas: technically, the resource tracker is the caller of update_provider_tree() on a virt driver, but the goal is to have update_provider_tree() API be what other agents (including Neutron) use for managing their hierarchy of providers, inventories, and traits. | |
| 17:12:36 | dansmith | efried: but get some code up so we can argue over that, which will be more clear right? | |
| 17:12:39 | bauzas | jaypipes: dansmith: cdent: mriedem: others: I'll be on PTO thursday to monday included | |
| 17:12:41 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: Fix N358 hacking check https://review.openstack.org/547670 | |
| 17:12:47 | jaypipes | bauzas: ack | |
| 17:12:56 | bauzas | disneyland... | |
| 17:13:11 | bauzas | not for the dog this time | |
| 17:13:23 | efried | dansmith: I'm rebasing the u_p_t series now. I'll throw a comment in the appropriate spot. And then at some point I guess I can propose the ProviderTree.merge_traits method. | |
| 17:13:33 | dansmith | okay | |
| 17:13:49 | bauzas | jaypipes: ack, yeah, makes sense | |
| 17:14:17 | bauzas | it's 6:13pm here, my stomatch starts to tell me it's time to hang off | |
| 17:14:30 | bauzas | but I'll be back tonight | |
| 17:14:31 | bauzas | \o | |
| 17:14:33 | jaypipes | ciao | |
| 17:23:58 | openstackgerrit | Eric Fried proposed openstack/nova master: New-style _set_inventory_for_provider https://review.openstack.org/537648 | |
| 17:23:59 | openstackgerrit | Eric Fried proposed openstack/nova master: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 17:23:59 | openstackgerrit | Eric Fried proposed openstack/nova master: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821 | |
| 17:24:00 | openstackgerrit | Eric Fried proposed openstack/nova master: Move refresh time from report client to prov tree https://review.openstack.org/535517 | |
| 17:24:00 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 17:24:01 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728 | |
| 17:24:01 | openstackgerrit | Eric Fried proposed openstack/nova master: Make generation optional in ProviderTree https://review.openstack.org/539324 | |
| 17:26:52 | efried | ^ rebase. The first patch should still be good to go regardless. The next one still needs some work. | |
| 17:28:13 | mriedem | is someone going to summarize all of the 'merge traits' discussion/decisions/etc from today into the ML per the retrospective at the ptg? | |
| 17:29:29 | openstackgerrit | Chris Dent proposed openstack/nova master: Move resource class fields https://review.openstack.org/540049 | |
| 17:29:30 | openstackgerrit | Chris Dent proposed openstack/nova master: Reparent placement objects to oslo_versionedobjects https://review.openstack.org/551529 | |
| 17:29:30 | openstackgerrit | Chris Dent proposed openstack/nova master: Move resource provider objects into placement hierarchy https://review.openstack.org/551528 | |
| 17:29:31 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 17:29:31 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 17:29:32 | openstackgerrit | Chris Dent proposed openstack/nova master: Move placement exceptions into the placement package https://review.openstack.org/549862 | |
| 17:30:53 | efried | mriedem: Well, I was planning to propose an update to the update-provider-tree spec. | |
| 17:31:14 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add 'member_of' param to GET /allocation_candidates https://review.openstack.org/552098 | |
| 17:31:20 | edleafe | dansmith: ^^ | |
| 17:31:42 | edleafe | dansmith: Still have to do tests, but I wanted jaypipes to review the SQL join code | |
| 17:31:49 | efried | mriedem: Once I've put that up, I can write something up for the ML. | |
| 17:47:18 | efried | dansmith: Are we going to have this same issue for aggregates? | |
| 17:47:28 | efried | Rephrase: We're going to have this same issue for aggregates. | |
| 17:47:42 | efried | I hesitate to wonder if we've got the same issue for inventories. | |
| 17:47:52 | efried | Golly, yes, allocation_ratio... | |
| 17:48:49 | sean-k-mooney | efried: same issue? | |
| 17:49:43 | efried | sean-k-mooney: Yeah; does the operator get to make changes to a provider's aggregates? | |
| 17:50:16 | efried | Since we're mirroring host aggregates, the answer is clearly yes; though those are going to be funneled through the compute service somehow. | |
| 17:50:17 | sean-k-mooney | efried: they get to create new ones. not sure they are allowed to modify existing ones | |
| 17:50:38 | efried | sean-k-mooney: Then we have exactly the same problem - how does the virt driver know it gets to remove an aggregate association? | |
| 17:51:07 | sean-k-mooney | it cant unless it created it | |
| 17:51:34 | sean-k-mooney | other service can create aggregates also not just the operator | |
| 17:52:54 | arvindn05 | mriedem: https://review.openstack.org/#/c/541507/ - can you take a look at the latest patchset? I think it should address your concerns | |
| 18:04:48 | openstackgerrit | Hongbin Lu proposed openstack/nova master: Skip placement on rebuild in same host https://review.openstack.org/546357 | |
| 18:06:44 | efried | I don't suppose there's a way to permalink an etherpad line | |
| 18:07:42 | sean-k-mooney | efried: i dont think the lines have css id so no | |
| 18:08:02 | efried | sean-k-mooney: Or even permalink the etherpad as a whole at a point-in-time. | |
| 18:08:30 | edmondsw | efried I wouldn't think so | |
| 18:08:34 | sean-k-mooney | efried: you could use http://archive.org/web/ | |
| 18:08:53 | efried | mmm, nice | |
| 18:09:11 | sean-k-mooney | efried: make a snap shot of the doc then link to the snap shot and give the line number | |
| 18:09:47 | efried | sean-k-mooney: Yeah, I'll pastebin just the relevant section. | |
| 18:09:51 | efried | I guess. | |
| 18:11:39 | sean-k-mooney | efried: you can create readonly share links in etherpad like this one https://etherpad.openstack.org/p/r.2bb9e3053658b6ddf5e73d31045dcfba | |
| 18:13:07 | efried | sean-k-mooney: That doesn't actually freeze it. Just makes it so you can't edit. | |
| 18:13:16 | efried | sean-k-mooney: Changes still show up. | |
| 18:14:06 | sean-k-mooney | efried: ah ok ya maybe with the version specified https://etherpad.openstack.org/p/r.2bb9e3053658b6ddf5e73d31045dcfba/timeslider#43302 | |
| 18:14:15 | sean-k-mooney | still pastbin might be cleaner | |
| 18:14:24 | efried | aha, #timeslider is probably what I want. | |
| 18:14:55 | efried | 'cept no line numbers! | |
| 18:14:59 | efried | gaaahhh! | |
| 18:16:28 | sean-k-mooney | efried: ya all the etherpads are version controled but yes the etherpad line number are added with javascipt renderer and are not part of the document | |
| 18:18:30 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Support default allocation ratios https://review.openstack.org/552105 | |
| 18:18:35 | jaypipes | dansmith: ^ | |
| 18:20:49 | dansmith | efried: I don't see the same problem with aggregates | |
| 18:20:59 | dansmith | efried: and aggregate changes wouldn't go through the compute service | |
| 18:21:08 | dansmith | efried: adds or removes would get mirrored to placement,m | |
| 18:21:26 | dansmith | but if the operator changed them in placement, we wouldn't necessarily un-do that with a sync based on what jaypipes has proposed as I understand it | |
| 18:23:29 | efried | dansmith: I think, as with the "driver capabilities" traits, the mirrored host aggregates will be a special case controlled by compute manager (!virt). But I mean in general. If an admin adds/removes an aggregate in placement directly, how does virt know not to remove/restore that aggregate association? | |
| 18:23:36 | sean-k-mooney | dansmith: i thikn efried main concern was how does nova know if it is allowed to remove a RP it created from an aggregate. my answer would be unless it created the aggregate it should not add or remove RPs from it | |
| 18:24:49 | dansmith | efried: the compute manager can't know what aggregate it's in | |
| 18:25:11 | dansmith | efried: it can't even access the database that has those details, nor talk to conductors that can | |
| 18:25:49 | efried | okay, sorry, "...special case controlled by conductor". But the point about the general case remains. | |
| 18:26:14 | dansmith | efried: I'm missing something | |
| 18:26:23 | efried | dansmith: I.e. do we need to implement ProviderTree.merge_aggregates ? | |