| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-26 | |||
| 14:18:54 | sean-k-mooney | im also wondering is there a way we could integrate mypy with ovo but that for another day | |
| 14:19:20 | finucannot | sean-k-mooney: Cool :) There's a spec there too because I think this would take a while to do (not that we need to check everything - only the most egregious stuff) so that's probably worth a look at | |
| 14:19:23 | efried | rgerganov No | |
| 14:19:59 | efried | rgerganov Also, we really don't want you to be accessing _Provider members directly. | |
| 14:20:21 | sean-k-mooney | ya i was going to start with the spec then read the ptaches you wrote once i had the context for why you were doing it :) | |
| 14:20:32 | finucannot | sean-k-mooney: And o.v.o uses a lot of magic and can definitely wait for a while :) I have started looking at oslo.config though | |
| 14:20:39 | finucannot | Mostly to test out pyannotate, mind | |
| 14:21:13 | efried | rgerganov I think the best way to find the root of the compute node tree is to use the nodename parameter we pass you in update_provider_tree. | |
| 14:21:39 | efried | rgerganov ...as a parm to .exists, .data, .has_*_changed, .update_*, etc. | |
| 14:22:22 | rgerganov | efried, then I think we need a find() method in the provider tree | |
| 14:22:37 | efried | rgerganov You can't have one :) | |
| 14:22:51 | efried | rgerganov We used to have it, but we took it out. Tell me what you are trying to do, what you need it for. | |
| 14:23:22 | rgerganov | efried, how do I find the provider for the compute node? iterate over all roots? | |
| 14:23:59 | efried | rgerganov From update_provider_tree? We pass you a nodename parameter. That ought to do the trick. | |
| 14:24:13 | rgerganov | efried, no it does not | |
| 14:24:13 | efried | rgerganov All the ProviderTree methods accept a name_or_uuid to identify the provider you're looking for. | |
| 14:25:01 | efried | rgerganov Can you tell me a little more about what you're trying to do with the root provider record? | |
| 14:25:09 | rgerganov | efried, first of all I want to remove all existing childs and add them again to avoid complicated synchronizations | |
| 14:25:18 | rgerganov | efried, https://review.openstack.org/#/c/536348/4/nova/virt/vmwareapi/driver.py | |
| 14:25:57 | rgerganov | efried, sorry, this is the latest one https://review.openstack.org/#/c/536348/5/nova/virt/vmwareapi/driver.py | |
| 14:26:34 | efried | rgerganov And this doesn't do the right thing? ==> provider_tree.update_inventory(nodename, root_rp_inv, None) | |
| 14:26:49 | rgerganov | efried, but how do I add a new child? | |
| 14:27:02 | rgerganov | I need the uuid of the parent | |
| 14:27:05 | rgerganov | not the name | |
| 14:27:28 | efried | oic, yeah. Probably wouldn't be a horrible idea for us to change that to name_or_uuid. Let me check if there's any reason we can't do that... | |
| 14:27:45 | efried | rgerganov But in the meantime, you can use provider_tree.data(nodename).uuid | |
| 14:28:19 | rgerganov | efried, ok, what about removing all the childs without using _Provider methods | |
| 14:28:38 | rgerganov | is this OK? root_rp.children.clear() | |
| 14:29:04 | efried | no, you'll have to do something like: | |
| 14:30:20 | efried | descendants = set(provider_tree.get_provider_uuids(nodename)) - set([provider_tree.data(nodename).uuid]); for desc_uuid in reversed(descendants): provider_tree.remove(desc_uuid) | |
| 14:31:11 | rgerganov | why so complicated? | |
| 14:33:10 | izombie | artom: are you around? | |
| 14:33:18 | efried | rgerganov Well, to be perfectly honest, we didn't anticipate that you would want to prune all descendants of the root. I'm still not convinced it's really necessary, but if it is, there's a way to do it. | |
| 14:33:40 | efried | rgerganov As far as why we don't let you have access to the internals, it's for thread safety. | |
| 14:34:06 | rgerganov | efried, but the virt driver get a copy of the tree, right? | |
| 14:35:07 | efried | rgerganov Keep in mind that we've designed this thing with a certain set of use cases vaguely in mind. As real consumers start really consuming it, and we encounter real use cases that run up against awkwardness, we can sure look into adding convenience methods for oft-seen usages. | |
| 14:35:59 | efried | rgerganov In update_provider_tree, yes, you don't have to worry about thread safety on the provider_tree parameter. You own it. But we don't have a separate ProviderTreeWhereThreadSafetyIsNotAnIssue class at the moment. | |
| 14:36:19 | rgerganov | ok | |
| 14:36:38 | artom | izombie, yeah | |
| 14:36:47 | efried | up to the point of that in-flight patch, SchedulerReportClient was the only thing using ProviderTree, and it does need to worry about thread safety (sort of :) | |
| 14:37:02 | izombie | The issue I was speaking of yesterday. | |
| 14:37:26 | izombie | artom: It was with the project-id, it wasn't according to the new regex pattern ;) | |
| 14:37:30 | artom | izombie, err, refresh my memory? | |
| 14:37:49 | izombie | artom: was trying to list nova servers and I was hitting 404.. | |
| 14:38:02 | artom | izombie, oh, right | |
| 14:38:10 | efried | rgerganov Feel like proposing that change for new_child to accept name_or_uuid for the parent? | |
| 14:38:18 | rgerganov | efried, yes | |
| 14:38:42 | rgerganov | efried, I will submit patch for it | |
| 14:38:46 | artom | izombie, err, cool? I'm not sure what you mean by new regex pattern | |
| 14:39:13 | efried | rgerganov You could *almost* cheat and pass in the name as it stands :) But that won't quiiite work all the way. | |
| 14:39:15 | rgerganov | efried, I also think that removing all child providers is pretty valid use case | |
| 14:39:16 | izombie | artom: so project mapper has introduced some change in the way project id's are supposed to be | |
| 14:39:51 | efried | rgerganov I would need to understand more about why that's necessary. And in any case you'll have to get it past Jay :) | |
| 14:39:56 | efried | Which reminds me... | |
| 14:40:02 | fried_rice | It's FRIDAY! | |
| 14:40:08 | artom | izombie, I'll be honest, I'm not following | |
| 14:40:12 | izombie | artom: the regex expects a hex sort of value, but our's was simple characters. hence the project id was never fetched and directly passed to routes to find a match | |
| 14:40:19 | fried_rice | niiice | |
| 14:40:44 | radio_gaga | fried_rice, you familiar with the vmware driver? | |
| 14:40:56 | fried_rice | radio_gaga Not at all, sorry. | |
| 14:41:00 | radio_gaga | fried_rice, basically one nova-compute manges a compute cluster in vcenter server | |
| 14:41:22 | izombie | artom: okay, this code might help you gain context https://github.com/openstack/nova/blob/master/nova/api/openstack/__init__.py#L156-L158 | |
| 14:41:24 | radio_gaga | fried_rice, a compute cluster may be divided into resource pools | |
| 14:41:42 | radio_gaga | fried_rice, now we want to create a nested RP for each resource pool under the compute cluster managed by nova | |
| 14:41:50 | fried_rice | radio_gaga And you don't have n-cpu running on those other ("slave"?) nodes in the cluster? | |
| 14:42:06 | radio_gaga | fried_rice, no | |
| 14:42:10 | fried_rice | k | |
| 14:42:20 | radio_gaga | fried_rice, the thing is that resource pools can be dynamic | |
| 14:42:21 | fried_rice | what's a "resource pool"? | |
| 14:42:24 | artom | izombie, ah, thanks - first time looking at that bit of the API code :) | |
| 14:42:43 | radio_gaga | fried_rice, it's just a group of compute resources | |
| 14:42:59 | radio_gaga | fried_rice, the point is that those resource pools can by dynamic | |
| 14:43:34 | fried_rice | radio_gaga Okay, so the hierarchy is: compute-host-where-service-is-running => resource-pool => slave-compute-node | |
| 14:43:35 | radio_gaga | fried_rice, and it would be a lot easier if we delete all child RP and create them again instead of trying to synchronize what's in the provider_tree and what's in vcenter | |
| 14:44:44 | izombie | artom: :) Necessity! | |
| 14:45:56 | fried_rice | radio_gaga Well, you could always provider_tree.remove(nodename) | |
| 14:46:10 | fried_rice | and then rebuild the whole shebang including the root. | |
| 14:46:29 | fried_rice | .remove(nodename) will implicitly whack everything under him. | |
| 14:46:39 | radio_gaga | fried_rice, hm, actually that will do the job | |
| 14:46:47 | radio_gaga | fried_rice, cool thanks | |
| 14:47:08 | radio_gaga | fried_rice, I will try it just in case :) | |
| 14:47:17 | fried_rice | radio_gaga But have you considered having all your compute nodes as roots, and tagging them with traits to identify their resource pool? | |
| 14:48:34 | radio_gaga | fried_rice, having them under one root is a better model because this is the same model in vCenter; you divide one big compute cluster into resource pools | |
| 14:50:01 | fried_rice | radio_gaga As you wish, just another possibility. Or have the slaves all be children directly under the root, and still tag 'em with resource pool trait name. | |
| 14:50:41 | radio_gaga | fried_rice, yeah, that's what I am trying to accomplish right now | |
| 14:51:12 | fried_rice | radio_gaga Point is, then you don't need to whack all the pools and rebuild them - you can just walk the children and reassign their traits. | |
| 14:51:49 | leakypipes | radio_gaga: awesome Friday nick :) | |
| 14:51:59 | radio_gaga | leakypipes, thanks :) | |
| 14:52:44 | radio_gaga | leakypipes, we were discussing changing provider_tree.new_child to accept name_or_uuid instead of uuid | |
| 14:52:59 | fried_rice | leakypipes IMO an oversight, easily corrected. Agree? | |
| 14:53:19 | fried_rice | leakypipes correction: parent_name_or_uuid instead of parent_uuid | |
| 14:53:30 | radio_gaga | yeah, right | |
| 14:54:29 | leakypipes | fried_rice: how about just "parent" | |
| 14:54:34 | fried_rice | sure | |
| 14:54:36 | leakypipes | fried_rice: and make it accept either. | |
| 14:54:37 | ameeda | can you please review this when you available ? https://review.openstack.org/#/c/528385/ | |
| 14:54:43 | fried_rice | radio_gaga is going to propose it | |
| 15:02:39 | tssurya | superdan, mriedem, melwitt : regarding the solution we discussed for nova list displaying only the uuid when a cell DB is down, there is this issue that we end up displaying all the instance uuids in that cell (including the deleted ones)...since we take it from the mappings, :( | |
| 15:03:05 | tssurya | any ideas on how to differentiate the deleted ones using api info ? | |
| 15:03:16 | melwitt | there isn't a way | |