| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-08 | |||
| 15:56:04 | jaypipes | mdbooth: on it. | |
| 15:56:11 | mdbooth | jaypipes: Thanks! | |
| 15:56:14 | jaypipes | np | |
| 15:56:40 | jaypipes | mdbooth: need to have something productive to do while on status calls. | |
| 15:56:47 | mdbooth | jaypipes: Hehe | |
| 15:57:34 | mriedem | mdbooth: ok maybe after calls | |
| 15:58:29 | mdbooth | jaypipes: If you're reviewing it for the first time, I'd split it in 2. First convince yourself that mount and umount in _HostMountState do the right thing. Then entirely separately convince yourself that the locking in mount.py means that we only ever let 1 thing operate on 1 mountpoint, and that we make everything wait during initialisation. | |
| 15:59:03 | jaypipes | mdbooth: will do, thanks for the heads up. | |
| 16:02:57 | openstackgerrit | Gábor Antal proposed openstack/nova master: Enable global hacking checks and removed local checks https://review.openstack.org/431030 | |
| 16:09:04 | macsz | sfinucan: hmm good point :) | |
| 16:09:55 | lyarwood | mriedem: sorry wasn't watching irc, yeah I'll be at the PTG, happy to talk about stable rescue and the LM spec in more detail then | |
| 16:23:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Add neutron.floating_pool https://review.openstack.org/431037 | |
| 16:23:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Deprecate 'default_floating_pool' https://review.openstack.org/431038 | |
| 16:23:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Move 'floating_ips' opts into 'network' https://review.openstack.org/431039 | |
| 16:23:47 | sfinucan | mdbooth: I think I've got it out of my system for now :) | |
| 16:29:28 | cfriesen | Got a compute node question...in commit 2c0a306 we changed things to spawn a helper thread. Doesn't this mean that any errors in the helper thread won't be caught by the function decorators? (@wrap_instance_fault, @wrap_instance_event, etc.) | |
| 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 | |