Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-08
16:29:40 cfriesen I'm wondering if those decorators shouldn't also be on dispatch_live_migration.
16:32:45 cfriesen come to think of it, won't having @wrap_instance_event on live_migration() give odd results because the function will spawn a new helper and immediately return?
16:45:17 openstackgerrit Chris Friesen proposed openstack/nova-specs master: Support Instance Rebuild With Userdata https://review.openstack.org/431052
16:56:46 oomichi alex_xu: thanks for review
16:57:05 oomichi mriedem: could you take a look at https://review.openstack.org/#/c/410006/ ?
16:58:12 mriedem oomichi: i'm trying to sort through https://review.openstack.org/#/c/430497/ first
17:05:07 johnthetubaguy pumaranikar: did you say you had a question for me?
17:11:29 mdbooth lyarwood: Still around?
17:13:14 lyarwood mdbooth: yup
17:13:37 mdbooth lyarwood: Seen jaypipes comments on your swap_volume patch?
17:14:24 lyarwood mdbooth: nope, checking now
17:14:40 mdbooth Nothing onerous, just a clearer comment.
17:17:27 cdent EmilienM: any progress/insights?
17:24:00 pumaranikar johnthetubaguy, sry for delay. I am wondering if someone can approve wrapper patch in placement.
17:24:18 pumaranikar johnthetubaguy, so that I can put follow up patches.
17:25:01 johnthetubaguy pumaranikar: sorry, I am not sure I understand. Why can't you push the other patches right away?
17:26:14 pumaranikar johnthetubaguy, yes I am working on it. I thought I will address any changes in wrapper in the base patch itself, if nay
17:26:20 pumaranikar *if any
17:26:39 pumaranikar johnthetubaguy, just for simplicity
17:28:12 pumaranikar johnthetubaguy, i have already added another patch for resource-class handler
17:28:20 johnthetubaguy pumaranikar: do you mean this one https://review.openstack.org/#/c/395194/, as I thought you said you were planning on doing those formatting fixes?
17:29:58 pumaranikar johnthetubaguy, I think I misunderstood then. I thought we are waiting on inputs for logging in wrapper
17:30:27 johnthetubaguy pumaranikar: I am fine with keeping that there for now, it was just the comment format that I think needs fixing up, ideally at least
17:30:42 pumaranikar johnthetubaguy, ok. I can fix formatting then.
17:31:15 johnthetubaguy pumaranikar: there was a good comment on the git commit message too I think
17:31:37 pumaranikar johnthetubaguy, yeah. I will address those two and let you know.
17:31:48 johnthetubaguy pumaranikar: cool, thank you
17:37:59 EmilienM cdent: we've unpinned nova in rdo and I did recheck on https://review.openstack.org/#/c/430571/ and it pass
17:38:11 EmilienM cdent: which means we might drink gin tonic tonight
17:38:23 EmilienM but i'll confirm when I'll see tripleo Ci promotion jobs
17:38:38 cdent What does this mean about why it was failing before?
17:39:22 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Remove redundant bdm serial mangling and saving during swap_volume https://review.openstack.org/427364
17:40:12 lyarwood jaypipes: ^ thanks for review, I've updated the comment and added a quick check before we stash the serial (as we do elsewhere during attach).
17:40:16 johnthetubaguy cdent: does that sound like a race to you, or is that just me?
17:40:30 jaypipes lyarwood: cool, thanks! will re-review shortly.
17:40:50 EmilienM cdent: tbh, I don't know
17:40:55 cdent johnthetubaguy: it sounds like we have insufficient data to say much of anything :(
17:41:07 johnthetubaguy cdent: thats more accurate
17:41:16 cdent we can't fully articulate what is different from attempt to attempt
17:41:21 dansmith cdent: if it passes some of the time and doesn't other times, I think that's the definition of a race :)
17:41:22 cdent just that things are different
17:41:36 cdent dansmith: "unpinned nova"
17:41:57 dansmith cdent: this was on the run to unpin nova yes? it failed once, and passed on a recheck
17:42:34 cdent Oh, I didn't get that from what EmilienM said. Was it the exact same stuff in each run? I thought not?
17:42:48 dansmith that's my understanding of it
17:43:35 cdent Because if you're right dansmith then I think EmilienM is going to the g&t's early, because we've learned nothing.
17:44:30 dansmith maybe I misunderstood this:
17:44:30 dansmith [07:27:24] <EmilienM>dansmith: ok I'm doing recheck and in 40m if I still see multinode failing, I'll unpin Nova in RDO and see how it goes
17:44:43 dansmith I thought he meant he was rechecking the unpin
17:44:47 EmilienM I did the recheck and it passed
17:44:55 EmilienM which means, I could deploy tripleo with nova from master
17:45:24 EmilienM so we're unpinning now in RDO and i'll check how tripleo work
17:45:33 EmilienM we should know in ~1h
17:45:42 EmilienM cdent: if I see you offline, i'll just email you
17:45:54 cdent EmilienM: when you did the recheck, was that the exact same code (everywhere) as earlier in the day, or some other code?
17:46:21 dansmith I don't even understand how 430571 tests anything different actually
17:46:28 dansmith it depends on the wsgi patch
17:46:36 dansmith but nothing to unpin nova afaict
17:46:42 dansmith even though it says it does
17:48:07 EmilienM cdent: the exact same in theory
17:48:17 cdent "in theory"?
17:48:27 EmilienM yeah, the version of openstack-nova rpm was the same
17:48:36 dansmith it doesn't depend on the wsgi patch actually
17:48:45 dansmith it depends on the nova canary that was depending on the wsgi patch
17:48:47 EmilienM but 'delorean' builds packages from git master so maybe something merged in the meantime?
17:48:57 EmilienM dansmith: yeah it's a canary
17:49:13 dansmith EmilienM: but why depend on the nova patch that does nothing from the tripleo patch?
17:49:32 EmilienM dansmith: to run a job that didn't run in nova gate
17:49:34 EmilienM dansmith: ovb-ha
17:49:54 EmilienM check experimental in nova doesn't run ovb-ha
17:49:56 dansmith EmilienM: how does the depends-on accomplish that?
17:50:26 dansmith EmilienM: I don't think anything is likely to have merged related to this in the last few hours, and even still, if you're not testing the rc1 branch you're not testing ocata anyway
17:50:59 EmilienM dansmith: our Ci tooling read Zuul env and build packages
17:51:15 dansmith EmilienM: if you wanted the nova experimental job to run on the tripleo change the depends-on should go the other way no?
17:51:24 EmilienM dansmith: right, gimme some hours to figure if it works now and if it's not racy & if it's stable
17:51:55 EmilienM I wanted to see ovb-ha so I did https://review.openstack.org/#/c/430571/ which depends-on a nova patch
17:52:43 EmilienM so our ci tooling built the nova patch and ran ovb-ha
17:52:51 EmilienM and it failed. That's the logs we investigated this morning
17:53:03 EmilienM but I did recheck and it pass
17:53:09 EmilienM that's where we are now
17:53:56 dansmith that's not how depends-on works for any other jobs that I know of, but okay
17:54:33 oomichi mriedem: one comment on https://review.openstack.org/#/c/430497
18:02:18 oomichi Kevin_Zheng: gmann puts a question on https://review.openstack.org/#/c/403568/18/nova/compute/manager.py
18:16:45 mriedem oomichi: replied
18:16:56 oomichi sfinucan: can you take a look at https://review.openstack.org/#/c/389338/ again ?
18:17:29 dansmith mriedem: can you re-hit https://review.openstack.org/430354 ?
18:18:34 sfinucan oomichi: Done and done
18:18:43 oomichi sfinucan: thanks :)
18:18:56 cfriesen dansmith: can you check my question earlier about commit 2c0a306? I think that was your commit.
18:18:58 sfinucan any time :)
18:19:22 mriedem dansmith: yeah
18:19:42 mriedem gabor_antal: fyi https://review.openstack.org/#/c/389338/
18:19:46 openstackgerrit John Garbutt proposed openstack/nova master: Default live_migration_progress_timeout to off https://review.openstack.org/429798
18:20:10 gabor_antal mriedem: thanks, I already saw that patchset :)
18:20:29 gabor_antal And built mine on the top of it: https://review.openstack.org/#/c/431030/
18:22:14 dansmith cfriesen: yeah, it probably did drop a little of that, although libvirt was spawn'ing in its driver too, so just adding those to the helper thread might affect more behavior than you expect
18:24:13 cfriesen dansmith: looking at @wrap_instance_event in particular, won't that generate start/finish events potentially before we even do any work?
18:24:42 dansmith cfriesen: yeah, but that didn't wait until it was complete before anyway because libvirt was doing its own spawn'ing
18:25:28 cfriesen dansmith: fair enough, but we used to at least do the pre_live_migration stuff before that spawn in libvirt
18:25:57 dansmith cfriesen: well, we also used to exhaust the rpc worker pool, but.. yeah :)

Earlier   Later