| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-26 | |||
| 13:03:11 | kholkina | artom, ok, thanks | |
| 13:05:12 | bkero- | Hi there, does anybody know if it's possible to get the nova-cli to output in a different format? Sort of like OSC's -f and -c options | |
| 13:06:05 | artom | bkero-, if there is, nova --help should tell you :) | |
| 13:07:01 | bkero- | I did not see it in there, which is why I came here to ask | |
| 13:08:59 | openstackgerrit | Merged openstack/nova master: tests: Use correct response type in tests https://review.openstack.org/527182 | |
| 13:12:15 | artom | bkero-, then we don't do it :) Were you hoping for some secret options we only tell to the select few? ;) | |
| 13:14:43 | bkero- | pretty much | |
| 13:14:50 | bkero- | some environment variable or undocumented flag | |
| 13:15:39 | bkero- | Or "oh, we use this library for our cli binary, and you'd be setting this env var/flag according to it" | |
| 13:15:59 | artom | bkero-, hehe :) | |
| 13:16:12 | artom | bkero-, I'm not the ultimate expert on this, but I've never come across something like that | |
| 13:21:48 | Spazmotic | Heading out for the day. Will be on at home for a bit, hit me up on SpazZz if you need anything | |
| 13:51:38 | bkero- | Hm, is there any way to clear out 'nova migration-list'? | |
| 14:07:32 | gibi | mriedem: FYI I'm getting lost in zuul job definitions: http://lists.openstack.org/pipermail/openstack-dev/2018-January/126616.html | |
| 14:09:18 | mriedem | crack that nut | |
| 14:13:17 | mriedem | gibi: this is the last versioned notification transformation patch i'm tracking for queens https://review.openstack.org/#/c/465081/ so you could update https://review.openstack.org/#/c/518018/ based on that | |
| 14:14:31 | sean-k-mooney | finucannot: qq i dont have time to read mypy stuff right now (tyring to do the refactor before i the end of the day) but is it related in any way to https://www.python.org/dev/peps/pep-0484/ | |
| 14:14:44 | finucannot | sean-k-mooney: One and the same | |
| 14:15:29 | finucannot | sean-k-mooney: Only I'm using Python 2-compatible comments for now. It could be converted once Python 2 support is dropped, but that's a minimum of two years off | |
| 14:15:31 | sean-k-mooney | finucannot: from what i saw in your pathcs however it looked like mypy did it via comments not fuction changes | |
| 14:15:51 | sean-k-mooney | ah ok so mypy support both | |
| 14:16:06 | finucannot | Correct http://mypy.readthedocs.io/en/latest/python2.html | |
| 14:16:16 | sean-k-mooney | comments for backwards compatiblity and greeting(name: str) -> str: for native python 3 | |
| 14:16:36 | finucannot | sean-k-mooney: Python 3.4+ (I think) | |
| 14:16:47 | finucannot | Thought 3.3 is EOL now so that doesn't matter | |
| 14:16:51 | finucannot | *though | |
| 14:17:30 | sean-k-mooney | ok cool i did like that pep but did i did not know there was a python2 compaible way e.g. i taught we would have to wait for openstack to become python3 only. | |
| 14:17:32 | finucannot | sean-k-mooney: It's pretty neat. I've seen it used in Sphinx and was thinking it would help reviewing ralonsoh's PCI spec object patch, so I tried it out | |
| 14:17:57 | sean-k-mooney | ill add them all to my review list as ya this is somthing i would be in favor of. | |
| 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 | |