| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 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: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821 | |
| 17:23:59 | openstackgerrit | Eric Fried proposed openstack/nova master: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 17:24:00 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 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:01 | openstackgerrit | Eric Fried proposed openstack/nova master: Make generation optional in ProviderTree https://review.openstack.org/539324 | |
| 17:24:01 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728 | |
| 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: Move resource provider objects into placement hierarchy https://review.openstack.org/551528 | |
| 17:29:30 | openstackgerrit | Chris Dent proposed openstack/nova master: Reparent placement objects to oslo_versionedobjects https://review.openstack.org/551529 | |
| 17:29:31 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 17:29:31 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 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 ? | |
| 18:26:31 | dansmith | efried: at steady state, nova wouldn't add or remove providers from aggregates | |
| 18:26:32 | sean-k-mooney | efried: in the general case nova cant assume it own RPs or Aggregate in placement | |
| 18:26:41 | dansmith | sean-k-mooney: agree | |
| 18:26:45 | efried | sean-k-mooney: Disagree. Sigh. | |
| 18:27:25 | sean-k-mooney | efried: well the simple case would be that neutron may want to add compute nodes to a aggregate to model there availablity zones which do not have to map direclty to novas | |
| 18:27:33 | dansmith | efried: can you state that disagreement as a full statement? like, you disagree that... | |
| 18:27:38 | sean-k-mooney | same for cinder | |
| 18:27:43 | dansmith | sean-k-mooney: yep | |
| 18:27:56 | dansmith | sean-k-mooney: or the operator may do so for any other reason | |
| 18:28:25 | dansmith | efried: I just wonder which part you disagree with | |
| 18:28:27 | sean-k-mooney | dansmith: yes for failure domains suchs as power or ha failover or other usecse that openstck can discover | |
| 18:28:49 | dansmith | sean-k-mooney: yup | |
| 18:29:54 | sean-k-mooney | s/ can discover/ can't discover/ | |
| 18:29:56 | efried | The virt driver knows of a certain set of aggregates of which its providers (the ones it "owns") are members. What it does not necessarily know about is the set of aggregates of which its providers are *not* members. Today, as designed, u_p_t is supposed to just overwrite aggregate associations. So there's no affordance for outside agents to manipulate them. | |
| 18:30:30 | efried | The question is: do we need such affordance? At least for the host agg mirroring, it sounds like it. | |
| 18:30:49 | dansmith | efried: ah are you talking about an aggregate around a compute node and its children, for example? | |
| 18:30:59 | dansmith | efried: not equal to nova's host aggregates? | |
| 18:31:25 | sean-k-mooney | efried: yes we do for the neutron/cinder case and for failure domains. the virt driver should simple add/remove aggregates it owns but not overrite all aggregates for a RP | |
| 18:31:36 | dansmith | right | |
| 18:31:41 | efried | dansmith: Could be intra-tree; could also be inter-tree (e.g. a shared storage pool). The argument applies to the host agg mirrors as well as whatever else we want to do with aggs. | |
| 18:32:15 | efried | I.e. if the virt driver is not the single SoT for agg associations of the RPs it "owns", we have to have the exact same discussion as we just did with traits. | |
| 18:32:17 | sean-k-mooney | efried: for a shared storage pool nova does not really own that RP cinder likely does | |
| 18:32:40 | efried | sean-k-mooney: Sometimes. PowerVM SSPs will be (co-)owned by the virt driver(s). | |
| 18:32:44 | dansmith | efried: well, I agree the virt driver can draw its own aggregates around things and manage those itself, and maybe tell compute that it should join an aggregate for some shared storage it's connected to, | |
| 18:32:54 | dansmith | but nothing more authoritative than that | |
| 18:34:01 | efried | dansmith: In which case we need to amend the u_p_t charter for aggregates in the same way we just did for traits. Because as currently designed, virt just overwrites the aggregates. | |
| 18:34:29 | dansmith | efried: okay I'm not sure how that was ever considered a reasonable thing to do, but.. yes, agree it needs to not do that :) | |