Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-26
12:07:41 Spazmotic mmhmm.. I can see that
12:07:47 Spazmotic Just needs more thought then I think
12:09:04 openstackgerrit Ameed Ashour proposed openstack/nova master: detaching volumes when deleted VM is in error state https://review.openstack.org/528069
12:09:04 openstackgerrit Ameed Ashour proposed openstack/nova master: detach instance volumes when VM creation fails https://review.openstack.org/528385
12:09:07 openstackgerrit Ameed Ashour proposed openstack/nova master: change instance_system_metadata column type https://review.openstack.org/526900
12:09:40 mdbooth stephenfin: You can't spit-shine a turd ;)
12:09:55 mdbooth stephenfin: Thanks for trying, though.
12:09:58 johnthetubaguy Spazmotic: so the quickest fix is to skip the check_can_live-migrate for XS 7+
12:10:17 Spazmotic I was wondering if we could do that but I could not think of a way
12:10:24 johnthetubaguy Spazmotic: that might not be as bad as it first sounds, given how the API has changed
12:10:28 Spazmotic We still do need the data from the source check, but if we could skip the assertation that would be ideal.
12:11:08 Spazmotic I guess I could use the XenAPI host calls to make a switch
12:11:15 johnthetubaguy Spazmotic: so you can call it right before where we call live_migrate, if the data is missing in migrate data?
12:11:49 johnthetubaguy Spazmotic: downside is failed live-migrations will take much longer to fail, and involve more work to rollback (disconnect the volumes)
12:12:09 johnthetubaguy but given you need to connect the volume first now anyway, its maybe not a big deal
12:12:37 ameeda gmann: gibi: is this ready for merge ? https://review.openstack.org/#/c/526900/
12:12:53 johnthetubaguy Spazmotic: so I think I am on watch the baby duties in a few mins, over lunch, so maybe catch you later on
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.

Earlier   Later