| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-26 | |||
| 12:13:07 | Spazmotic | So we could potentially still generate the map and just have it just not run an assertation if the XS version is high.. but yea it's not a bad idea | |
| 12:13:17 | Spazmotic | worth looking into for usre.. I appreciate the brain dump man | |
| 12:13:23 | Spazmotic | and good luck with the baby :) | |
| 12:13:48 | johnthetubaguy | I may need it :) | |
| 12:14:08 | Spazmotic | Make your baby review my code.. will keep htem busy :p | |
| 12:14:45 | johnthetubaguy | Spazmotic: yeah, that works, generate the map, but skip the check check call based on version (there is some structures in place for version skips already) | |
| 12:15:08 | Spazmotic | Awesome.. maybe i'll look how those are done nad see if i can keep it standard | |
| 12:15:19 | Spazmotic | If you happen to know one feel free to let me know when you get a cahnce so I can take a look | |
| 12:22:48 | Spazmotic | Ah and johnthetubaguy since my irc nme is wierd.. the commit i added you to is https://review.openstack.org/#/c/533168/4.. Ignore zuul.. we fighting right now :P | |
| 12:27:51 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: WIP: VMware: implement update_provider_tree() https://review.openstack.org/536348 | |
| 12:35:59 | rgerganov | efried, is it safe to assume that when update_provider_tree is called, provider_tree.roots[0] points to the root RP of the compute node? | |
| 12:45:11 | Spazmotic | Nice.. host_rec['software_version']['product_version'].. super easy | |
| 12:47:55 | openstackgerrit | Merged openstack/nova master: Add the Nova libvirt StorPool attachment driver. https://review.openstack.org/140733 | |
| 12:48:01 | kholkina | Hi. I use this patch https://review.openstack.org/#/c/530224/ to update user-data. It works fine on 169.254.169.254/2009-04-04/user-data, but doesn't work when I use config drive. What should I do to update it on config-drive too? | |
| 12:48:11 | openstackgerrit | Merged openstack/nova master: Transform instance-evacuate notification https://review.openstack.org/482148 | |
| 12:52:16 | artom | kholkina, the config drive is essentially write-once, at instance creation. | |
| 12:52:40 | artom | kholkina, whatever metadata the instance was created with, that's what's on the config drive, and it can't be updated | |
| 13:01:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: test if tempest-full is triggered or not https://review.openstack.org/537936 | |
| 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 :) | |