Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-26
12:01:40 Spazmotic Yeah I saw that and agree as well unless I duplicated the bdms pull, which was why I say it's wrong
12:01:59 Spazmotic re-pulling bdms in the check call to be able to call the attachments.. which sucks
12:02:04 johnthetubaguy yeah, the bdms just don't have the info in them you think they do, if its done before that call
12:02:16 Spazmotic Ah no? are they modified before then? Didn't think that would change.
12:02:35 Spazmotic Ahhhh i see
12:02:43 Spazmotic I didn't read the loop close enough.. damn
12:03:01 johnthetubaguy they can be modified by this call: https://github.com/openstack/nova/blob/d0d0262379a57230e546cddf233da8012d3fe5b1/nova/compute/manager.py#L5905
12:03:06 johnthetubaguy cool
12:04:02 Spazmotic The other option is to clean up sort out Huan Xie's code.. which just eats the exception and forms the map manually
12:04:10 Spazmotic So.. lots to mush face against on it
12:05:11 Spazmotic nothing really graceful showing up in my mind yet
12:05:52 Spazmotic Could push the bdm attachment setting into its own method to call twice.. but that's just adjusting the code to fit this specific situation.
12:06:47 johnthetubaguy its more we can't call that till the pre-live-migrate stage, else all the error handling is screwed up
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

Earlier   Later