| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-18 | |||
| 13:55:41 | mriedem | gibi: yeah i think log and return from the method is what i'd expect | |
| 13:55:49 | gibi | mriedem: ok | |
| 14:03:28 | shilpasd | dansmith: thanks for ack | |
| 14:06:58 | efried | "There is no script for 398 version" <== I thought this means I need to rebuild my testenv, but that didn't fix it. | |
| 14:08:58 | dansmith | efried: clean your directory of pyc files | |
| 14:09:04 | efried | thanks dansmith | |
| 14:33:01 | dansmith | melwitt: were you going to update this? https://review.opendev.org/#/c/662095 | |
| 14:33:25 | mriedem | alex_xu: is anyone working on renaming "Intel_Zuul" so it shows up as 3rd party CI? | |
| 14:33:38 | mriedem | i.e. comments in patches will be hidden by default | |
| 14:36:28 | sean-k-mooney | https://docs.openstack.org/infra/system-config/third_party.html#creating-a-service-account covers how to configure it but they jsut need to chage teh account full name to have CI in it | |
| 14:38:59 | efried | dtroyer: ^^ Would you be able to (poke someone to) make a PR to make that adjustment? | |
| 14:39:29 | sean-k-mooney | its why everyone ignores my "Sean Mooney CI" account | |
| 14:39:50 | efried | I never know which one to use when adding you to a change. Is your RH email the right one? | |
| 14:40:14 | sean-k-mooney | use the non ci one | |
| 14:40:19 | sean-k-mooney | but yes the redhat one | |
| 14:41:21 | sean-k-mooney | the ci one was for testing ci jobs locally when i was planning to run my own thridparty ci | |
| 14:42:51 | sean-k-mooney | i might someday set that up again but it was burning like 100-200 euro a month in power someing like that anyway | |
| 14:43:06 | mriedem | lyarwood: can we drop these backports? https://review.opendev.org/#/q/I15a7c13edf78884ec223fd531a78a341106b41b8+status:open | |
| 14:43:14 | mriedem | we have no recreate and it's a very latent thing | |
| 14:44:07 | dtroyer | efried: will do | |
| 14:44:13 | efried | thank you dtroyer | |
| 14:45:08 | lyarwood | mriedem: ack sure | |
| 14:46:55 | lyarwood | mriedem: I'll do the same for https://review.opendev.org/#/q/topic:bug/1834048+(status:open+OR+status:merged) - iirc the downstream reporter never got back to us about this. | |
| 14:48:06 | efried | sean-k-mooney, mriedem: merging https://review.opendev.org/#/c/669738/ (config drive fix) | |
| 14:49:19 | mriedem | lyarwood: yup thanks | |
| 14:49:44 | sean-k-mooney | efried: cool, im not sure if mdbooth replied but i dont think the follow up patch is needed so we might want to abandon it? i did not rebase it because i dont know what value it adds. | |
| 14:50:18 | efried | oh, that one's been around for a whiiile. | |
| 14:50:24 | efried | I haven't looked at it recently. | |
| 14:50:43 | mriedem | with the size and breadth of that change the commit message would need a hell of a lot more detail | |
| 15:01:17 | melwitt | dansmith: guh, yeah I had intended to but it keeps getting left on the backburner | |
| 15:01:30 | dansmith | melwitt: okay, seems worth finishing | |
| 15:01:49 | melwitt | yeah, agreed :( | |
| 15:02:01 | melwitt | if anyone else wants to update it, of course feel free too | |
| 15:02:09 | melwitt | I'll try to do it after my calls today | |
| 15:04:24 | gibi | sean-k-mooney: I think I found possible race in the test in https://review.opendev.org/#/c/669738/ | |
| 15:07:11 | sean-k-mooney | i think the state does change but ill check | |
| 15:07:22 | sean-k-mooney | maybe its the task sate | |
| 15:07:47 | gibi | sean-k-mooney: task_state changes but I think the status doesn't | |
| 15:08:27 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Error out interrupted builds https://review.opendev.org/666857 | |
| 15:08:27 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pull up compute node queries to init_host https://review.opendev.org/682680 | |
| 15:08:37 | gibi | sean-k-mooney: even if status changes during the reboot if it start from ACTIVE and ends in ACTIVE then you cannot be sure why the wait returned | |
| 15:08:44 | sean-k-mooney | looking at https://docs.openstack.org/nova/latest/reference/vm-states.html you seam to be correct | |
| 15:09:18 | gibi | mriedem: fixed your comments in https://review.opendev.org/#/c/666857 | |
| 15:10:32 | sean-k-mooney | gibi: efried so we should stop https://review.opendev.org/#/c/669738/7 merging and i should fix that | |
| 15:10:48 | gibi | sean-k-mooney: a rebase would pull it out from the gate | |
| 15:11:10 | sean-k-mooney | i just set workflow -1 will that work? | |
| 15:11:33 | sean-k-mooney | i just removed erric +w | |
| 15:11:35 | gibi | I don't know what is stronger the W+ or the W- | |
| 15:11:46 | gibi | sean-k-mooney: ohh you can do that? | |
| 15:11:53 | sean-k-mooney | if you are the patch owner | |
| 15:11:58 | sean-k-mooney | or a core | |
| 15:12:00 | efried | whoah | |
| 15:12:02 | efried | I didn't know that | |
| 15:12:24 | sean-k-mooney | ya we block remove -* i think | |
| 15:12:28 | efried | anyway, that's not going to pull it out of the check queue, which is where it's sitting right now. But it should prevent it going into the gate. | |
| 15:12:36 | efried | if it was already in the gate you would have to rebase to pull it. | |
| 15:12:42 | bauzas | mriedem: I'm pretty done with my audit command (just needing to work on unittests) but I'd like to provide a functional test about some migration error | |
| 15:12:59 | efried | If you care to save on gate resources you could rebase to pull it out of check | |
| 15:13:05 | bauzas | mriedem: just to make it clear, there are cases where the migration goes into ERROR and then we have orphaned allocations, right? | |
| 15:13:06 | efried | if the patch itself needs changes. | |
| 15:13:22 | sean-k-mooney | efried: taht will kick off new jobs | |
| 15:13:32 | sean-k-mooney | ill just try to fix it before it starts running | |
| 15:13:32 | efried | yes, but at the back of the queue :) | |
| 15:13:33 | bauzas | mriedem: I'd like to mimic some behaviour | |
| 15:13:41 | sean-k-mooney | ok | |
| 15:13:44 | sean-k-mooney | ill do that | |
| 15:13:46 | efried | I think actually you might be able to pull it completely by abandoning and restoring | |
| 15:14:00 | efried | um, restore might start it again | |
| 15:14:11 | efried | so you could abandon until you're ready to push new ps | |
| 15:16:46 | kashyap | sfinucan: Before the GA, this should go in, yeah? The typo-that-matters in driver.py: https://review.opendev.org/#/c/682267/3/nova/virt/libvirt/driver.py | |
| 15:17:08 | mriedem | gibi: sean-k-mooney: commenting on sean's patch | |
| 15:19:08 | mriedem | commented | |
| 15:19:11 | mriedem | seems the only issue is reboot | |
| 15:19:57 | mriedem | sorry i was looking at unshelve | |
| 15:21:33 | openstackgerrit | Shilpa Devharakar proposed openstack/nova-specs master: Update spec: filtering of alloc candidates by forbidden aggregates https://review.opendev.org/675384 | |
| 15:21:35 | mriedem | i think in either case waiting for task_state to be None is sufficient, but waiting on notifications also works | |
| 15:22:28 | gibi | mriedem: replied | |
| 15:26:03 | mriedem | bauzas: for that audit command i would have started with functional tests months ago | |
| 15:26:09 | mriedem | unit tests don't mean much for stuff like this | |
| 15:26:20 | mriedem | in fact, i don't like unit tests really for any of these types of operational commands | |
| 15:26:22 | bauzas | mriedem: I can send you a new revision now, FWIW | |
| 15:26:36 | bauzas | mriedem: but I just wonder what to test from a migration usecase | |
| 15:26:54 | bauzas | but I think I'll just mock a failing migration that leaves an allocation record | |
| 15:26:57 | mriedem | there are notes about migration in the bug report aren't there? | |
| 15:27:18 | bauzas | correct, there are examples where we found orphaned allocations | |
| 15:27:23 | mriedem | i don't think mocking is really good here, i'm pretty sure we have known ways to hit stuff like that, with evacuate | |
| 15:28:02 | mriedem | https://review.opendev.org/#/c/678100/ has a couple of related bugs where we orphan allocations/providers | |
| 15:28:06 | bauzas | what I basically do is to compare whether I can find an active migration against an existing allocation | |
| 15:28:22 | bauzas | will look at the change ^ | |
| 15:28:38 | bauzas | and you know what ? I'll release the change now so people can voice against it | |
| 15:29:07 | mriedem | kashyap: i've tagged the bug with train-rc-potential | |
| 15:29:30 | kashyap | mriedem: Ah, thank you. Didn't think of it | |
| 15:29:53 | kashyap | IIRC, stephenfin wanted to hold off on it until the 'cpu-resources' merges | |
| 15:30:10 | mriedem | so like the day of RC1 | |
| 15:30:12 | mriedem | got it | |
| 15:30:13 | kashyap | (Due to conflicts, etc.) | |
| 15:30:38 | kashyap | mriedem: :D I mentioned it exactly for that -- in case it doesn't merge, that typo shouldn't fall through the cracks | |
| 15:30:49 | kashyap | (And you've helpfully fixed it, by the tag) | |
| 15:30:55 | mriedem | i sure hope everyone rechecking the vpmem and pcpu series is actually looking at every failure to make sure we're not recheck grinding in some regression | |
| 15:31:33 | stephenfin | I am. We're seeing mirror issues, InnoDB issues, and something with devstack_gate and null bytes | |