Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-26
08:34:07 Spazmotic You making IBM hate me again hehe
09:26:31 Spazmotic man the tempest zuul and IBM failures plaguing me with snapshots failing to create is driving me into insanity
09:41:57 gmann alex_xu: gibi stephenfin : any other optimized way to get system metadata ?- https://review.openstack.org/#/c/526900/22/nova/tests/functional/regressions/test_bug_1117923.py@124
09:45:21 gmann ameade: ^^ let's see if other folk can tell better way
09:50:06 gibi gmann: as far as I see there is no way to directly get the instace system_metadata via the nova REST_API
09:53:33 openstackgerrit Merged openstack/nova master: Use neutron port_list when filtering instance by ip https://review.openstack.org/525505
09:53:44 openstackgerrit Merged openstack/nova master: Modify the test case of get_disk_mapping_rescue_with_config https://review.openstack.org/494156
09:55:35 Spazmotic nova hides that junk pretty well unfortunately from what i've tested in the past
10:01:00 Spazmotic Any UK cores here today? :)
10:02:02 Spazmotic Would love if one had some free cycles for a review. https://review.openstack.org/#/c/533168/4 . Zuul freaking out over some volume stuff but should go back to +1 here soon. Heading on vacation in about 9 days and don't want it to sit idle for 2 weeks
10:03:27 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'move-nova-cmds-to-cliff' spec https://review.openstack.org/433603
10:06:43 openstackgerrit lei zhang proposed openstack/nova master: Fix the incorrect RST convention https://review.openstack.org/538208
10:12:59 openstackgerrit Zengzhi Wang proposed openstack/nova stable/pike: Make eventlet hub use a monotonic clock https://review.openstack.org/537811
10:13:33 jianghuaw Spazmotic, I guess the zvkm rechecks were done automatically as there was an error in upstream package which caused some CI job failed.
10:14:18 Spazmotic Maybe maybe.. now I Just gotta fight zuul hehe
10:15:28 jianghuaw hehe. Good luck.
10:26:46 Roamer` Spazmotic, if you're seeing Zuul failures in volume backup tests, there's little point in rechecking until https://review.openstack.org/#/c/538027/ merges
10:27:05 Spazmotic ahh something regress? Alrighty roamer, thanks
10:28:10 Roamer` Spazmotic, yep, sporadic, not always, but quite annoying the last couple of days
10:34:49 Roamer` of course, once it merges, you'd wish you had rechecked early enough so that your patch is close to the head of the queue :P
11:17:41 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Integrate Mypy Type Checking https://review.openstack.org/538217
11:21:15 stephenfin cdent, mdbooth, sean-k-mooney: Would be interested in your thoughts on this. PoC changes to follow shortly https://review.openstack.org/538217
11:41:51 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Add mypy target https://review.openstack.org/538221
11:41:52 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Store list of converted files https://review.openstack.org/538222
11:41:52 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Move __init__ function https://review.openstack.org/538223
11:41:53 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add 'types' module https://review.openstack.org/538225
11:41:53 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.openstack.org/538224
11:42:26 stephenfin cdent, mdbooth, sean-k-mooney: Ta-da! ^ That was my evening's work 🙈
11:43:29 Spazmotic You did all that and i'm just over here smashing my face into xenapi live migrate
11:50:09 johnthetubaguy Spazmotic: xenapi live-migrate... whats up there?
11:50:38 Spazmotic man john i've been crying your name for days :p
11:50:53 johnthetubaguy Spazmotic: your welcome
11:50:55 Spazmotic hehehehe
11:51:20 Spazmotic Looks like it's not working in XS7+ due to the SR not existing during the assert_can_live_migrate for src -> destand XS7 being more insistent that it does.
11:51:41 johnthetubaguy oh, they "fixed" that check
11:52:02 Spazmotic Yep, so it would seem. It actually insists now and throws MAP errors
11:52:34 johnthetubaguy yeah, we don't pass the SR map to the first check call, as it never used to do anything with it
11:52:37 Spazmotic johnthetubaguy: by the by I manually added you to a review with Xenapi the other week, I hope you don't mind.
11:53:10 johnthetubaguy that is no problem, although you might have to ping me to get to that, hoping to ramp my reviewing back up now things are more settled over here
11:53:15 Spazmotic Well in this case it's for our iSCSI volumes only causing an issue since they don't exist yet on the dest during its first pass call through that method
11:53:33 Spazmotic yeah I understand, I mentioned you a few times but figured yo uwere just busy
11:53:36 johnthetubaguy yeah, but I think you will need to send the map for it to find them
11:53:41 Spazmotic IT's pretty simple code but it directly involves things I know yo uworked on, so wanted your advice
11:54:09 Spazmotic I agree, my only real thought here is how to handle it. My best thought now is to generate the SR a little earlier in the code line
11:54:16 johnthetubaguy its a nasty one honestly, as the work isn't done until much later to create the volumes on the dest, as I am sure you saw
11:54:51 johnthetubaguy the problem is Cinder really, that extra connection has tracking info that doesn't get updated till after the check phase
11:55:29 johnthetubaguy the other (very unfortunate but quick) approach is to move the check later, before you call the live-migration
11:55:40 Spazmotic Without a major overhaul, the only thing I was able to think of that wasn't too gross was to use connect_to_volume provider at the destination check. IT would require that code pulling BDMS though.. which doesn't feel right.
11:55:58 Spazmotic at least that way the SR exists, but doesn't need to attach the volume yet..and it generates the map without error.
11:55:59 johnthetubaguy yeah, those BDMs are wrong at that point
11:56:26 johnthetubaguy you need the specific connection params for the destination hypervisor, which could be different credentails, in the general case
11:56:28 Spazmotic It would literally just be a throw away of the variable afterwards, which is a waste
11:57:16 Spazmotic That's true that data is stored in the SR isn't it.
11:58:05 Spazmotic I guess it's still workable since bdms pulls conn_data anyway
11:58:17 Spazmotic But still not right
11:58:22 johnthetubaguy hmm, not sure I understand what you mean, I thought each SR would have different passwords in conn_data, potentially, not sure we ever tested that mind
12:00:16 johnthetubaguy Spazmotic: basically, you need this code to run *before* you attach the SR from the bdm: https://github.com/openstack/nova/blob/d0d0262379a57230e546cddf233da8012d3fe5b1/nova/compute/manager.py#L5889
12:01:06 johnthetubaguy That means due to the common code the earliest you can attach the SRs on the destination is this path: https://github.com/openstack/nova/blob/d0d0262379a57230e546cddf233da8012d3fe5b1/nova/compute/manager.py#L5944
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

Earlier   Later