| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 13:28:50 | jaypipes | efried: welcome back | |
| 13:29:11 | jaypipes | cdent: any prog on that bug? | |
| 13:30:03 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: archive_deleted_instances is not atomic for insert/delete https://review.openstack.org/526065 | |
| 13:30:08 | cdent | jaypipes: yeah, it has fixes that need be merged, the tests underneath this are passing: https://review.openstack.org/#/c/525605/ there’s a dependent devstack change and a backport of that devstack change | |
| 13:30:19 | cdent | sdague, dansmith ^ | |
| 13:30:54 | cdent | jaypipes: it was a bit of an onion | |
| 13:31:03 | jaypipes | cdent: sounds like it indeed :( | |
| 13:34:06 | sdague | cdent: I approved the 2 devstack changes, I guess we are waiting on grenade results to come in? | |
| 13:34:29 | efried | jaypipes Howdy, thanks. I'm poring over emails to see where you got to with those patches. | |
| 13:34:30 | cdent | sdague: Yeah, I’ve been watrching zuul and the two main grenade changes have passed | |
| 13:34:50 | efried | jaypipes I didn't intend for you to have to do that stuff - I realized it had gotten pretty ugly at this point with all the stuff that changed underneath it. | |
| 13:34:50 | cdent | heat (non-voting) has vailed and ironic is being slow | |
| 13:35:19 | jaypipes | efried: well, I had to give up after f**king up the series in a failed rebase. | |
| 13:35:44 | cdent | vailed is a word I will use to mean something like “veiled in failure” | |
| 13:36:06 | jaypipes | efried: heh | |
| 13:36:18 | efried | cdent Or a verb related to an overpriced ski resort. | |
| 13:36:18 | jaypipes | efried: https://review.openstack.org/#/c/385693/ is where I stopped after a revert of the rebase attempt. | |
| 13:36:28 | cdent | that fails to satisfy | |
| 13:37:06 | jaypipes | I'm also at my wit's end w.r.t the REST API patch for nested resource providers. | |
| 13:37:25 | jaypipes | so much for trying to merge things quickly and tweak afterwards. | |
| 13:37:43 | sdague | cdent: is the heat one normally passing? | |
| 13:37:47 | jaypipes | let's bikeshed on shit some more, just for fun. | |
| 13:37:51 | efried | jaypipes What's the rub there? Are we just bikeshedding tree vs in_tree? | |
| 13:38:27 | jaypipes | efried: that, yes, and placement-api-ref weirdness. | |
| 13:39:02 | jaypipes | efried: I'm tired of the placement api ref docs crap, frankly. | |
| 13:39:09 | cdent | sdague: it’s hard to tell, there haven’t been many changes to grenade since zuul | |
| 13:39:15 | jaypipes | efried: in particular, these comments: https://review.openstack.org/#/c/384807/85/placement-api-ref/source/resource_provider.inc | |
| 13:39:29 | jaypipes | efried: the parameters are not required. they are optional. | |
| 13:39:31 | cdent | sdague: but this recent change passes: https://review.openstack.org/#/c/525720/ | |
| 13:39:58 | jaypipes | efried: but takashi wants to indicate that the *response* attributes will always be there, so insists I put required: true in the parameters file. | |
| 13:40:01 | efried | So I agree that in_tree would be clearer; else we're sorta giving the impression that a tree is an entity in its own right with a UUID. But super-meh. This is an API, and people are going to have to read the docs to figure out what it means regardless of whether it's called `tree` or `in_tree`. | |
| 13:40:29 | efried | WRT the docs, my *strong* preference at this point would be to merge what we have so we can get *code* going, and then follow up with docs tweaks. | |
| 13:41:05 | jaypipes | efried: that was my preference as well, but I've now attempted to comply with the review requests on the docs stuff and broken the api-ref build. | |
| 13:42:01 | efried | jaypipes Let me catch up on the review comments. I can take over fixing up the api-ref build if you're getting burned out. | |
| 13:42:16 | jaypipes | efried: I'm way burned out on this, yes. | |
| 13:42:43 | jaypipes | efried: and other than not wanting to go with "tree_member", I don't care about tree vs. in_tree. | |
| 13:43:05 | efried | jaypipes What's it at right now in the patch? | |
| 13:43:32 | jaypipes | tree | |
| 13:44:33 | jaypipes | efried: I'll fix it. gimme 10 mins | |
| 13:44:51 | efried | jaypipes cdent edleafe bauzas can we take a quick vote? Sounds like jaypipes is +1 on tree/in_tree and -1 on tree_member; I'm the same. | |
| 13:44:58 | jaypipes | efried: but you can do the rebase for your WIP patches above it. | |
| 13:45:05 | efried | jaypipes ight. | |
| 13:45:16 | jaypipes | efried: I'm +1 on just get this friggin done. | |
| 13:45:25 | efried | ++ | |
| 13:45:46 | efried | You have to respin the patch anyway; but renaming that query param is slightly nontrivial compared to fixing the doc build. | |
| 13:45:49 | cdent | -1 on tree_member, slight preference for in_tree over tree, but not enough to be upset if tree is the result | |
| 13:47:09 | cdent | brb | |
| 13:50:55 | bauzas | jaypipes: I agree with you on the fact it's just a verbiage problem, so a nit, but honestly, given it would be an API parameter, I prefer to make sure we discuss that | |
| 13:52:30 | jaypipes | bauzas: this patch is >1 year old. let's make a decision and do this. | |
| 13:52:35 | bauzas | exactly | |
| 13:52:38 | bauzas | so | |
| 13:52:42 | bauzas | tree, -1 for me | |
| 13:52:48 | bauzas | in_tree : +0 | |
| 13:53:04 | maciejjozefczyk | Hello Guys, im trying to debug why I've faced a problem with scheduling. My instances stucks in 'scheduling' state. After enabling debug on nova-scheduler I've found that a host was selected. On nova-compute side there were 0 info about building an instance. It could be possible that the failure point is nova-conductor? | |
| 13:53:11 | bauzas | tree_member : +1 | |
| 13:53:26 | bauzas | or tree_node | |
| 13:53:40 | jaypipes | alex_xu: around? your vote on tree, in_tree or tree_member please. | |
| 13:57:04 | efried | in_tree has it by a whisker. | |
| 13:57:11 | efried | You know, assuming it's a democracy in the first place | |
| 13:57:31 | efried | and the need to delta what's there isn't being factored in. | |
| 13:58:50 | sean-k-mooney2 | :) in_tree would be my choice out of those too | |
| 14:00:49 | sean-k-mooney2 | tree_member almost seams like a boolean to me. e.g. is that resouce a tree member or standalone | |
| 14:02:33 | sean-k-mooney2 | but as cdent said between tree and in_tree i dont have a stong enough preference to mind which was used | |
| 14:07:33 | efried | jaypipes How far up the stack are you rebasing currently? | |
| 14:08:20 | jaypipes | efried: only to the update client to set parent provider patch (third from the bottom) | |
| 14:08:41 | jaypipes | efried: since when I tried to rebase all the way up to your WIP patches, I failed miserably | |
| 14:09:14 | efried | jaypipes k. I just started looking, but in particular I think this delta is wrong, please confirm: https://review.openstack.org/#/c/520643/8..9/nova/scheduler/client/report.py | |
| 14:09:21 | efried | That reverts the exception handling bugfix. | |
| 14:09:40 | efried | It's like an un-rebase | |
| 14:09:41 | jaypipes | efried: yeah, I messed it up. totally. :( | |
| 14:10:18 | efried | but I need to wait until you've published the bottom three to start rebasing on top. | |
| 14:10:18 | jaypipes | efried: I ended up having to "revert" the rebase for the three patches at the bottom using clarkb's trick of git review -d XXXXX,N-1 && git commit --amend | |
| 14:10:23 | jaypipes | efried: yes | |
| 14:10:32 | jaypipes | efried: I'm just running tests now. | |
| 14:10:38 | efried | k, I shall stop distracting you :) | |
| 14:10:42 | jaypipes | efried: gimme another ten minutes to complete. | |
| 14:10:48 | efried | rgr | |
| 14:14:39 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Check if interface belongs to a Linux Bridge before removing https://review.openstack.org/526079 | |
| 14:15:26 | kashyap | mdbooth: Have you resolved your MySQL-Python on F27 thing? I'm on F27 | |
| 14:15:45 | mdbooth | kashyap: I think so... by not building it :) | |
| 14:16:30 | kashyap | Ah, then something somewhere still has stale deps file | |
| 14:18:24 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add abstract OVSDB API https://review.openstack.org/476612 | |
| 14:20:01 | efried | cdent Would it be feasible/appropriate/relevant for jaypipes to put Depends-On to https://review.openstack.org/#/c/525605/ (grenade fix) from https://review.openstack.org/#/c/385693/ in his current spin? | |
| 14:21:10 | cdent | efried: Maybe, I’m never quite sure well depends-on _to_ a grenade change works. It might be just fine. mriedem ? | |
| 14:21:36 | efried | I know certain projects don't pick up Depends-Ons to certain other projects. | |
| 14:21:52 | efried | I'm also pretty sure some of those rules changed (for the better IIRC) when we went to zuulv3 | |
| 14:22:05 | efried | So - no idea at this point. | |
| 14:22:53 | efried | Guess it couldn't hurt. If it winds up being a no-op, we haven't lost anything; but if it winds up going green, we know it works. | |
| 14:23:54 | mriedem | it's valid for nova to depend on a grenade fix yes | |
| 14:24:23 | mriedem | cdent: questions in https://review.openstack.org/#/c/521639/ | |
| 14:25:02 | cdent | mriedem: roger, working on the contributor doc stuff now | |
| 14:25:40 | mriedem | melwitt: lyarwood: i went over https://review.openstack.org/#/c/400384/ - only thing of note is that power_on (start API) is now going to do this full hard reboot, and i'm not sure if that's an intended side effect or not | |
| 14:26:15 | mriedem | definitely feels like one of those changes that will break something else we aren't aware of, so i'll definitely want to avoid backporting that too far too fast until it has some time to sink in | |
| 14:26:23 | sdague | cdent: can you let me know if you feel the heat fail on https://review.openstack.org/#/c/525605/ is valid or not | |
| 14:26:31 | sdague | if not, I'm happy to get it merged | |
| 14:27:39 | cdent | sdague: I was unable to trace the failure to anything related to placement, it looked like a timeout, but it’s hard to tell: the (single) test that failed doesn’t make what it’s doing all that obvious | |
| 14:27:44 | cdent | so I’d say go for it | |
| 14:29:20 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 14:29:21 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 14:29:21 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |