| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 13:05:44 | efried | grisly. | |
| 13:05:49 | sean-k-mooney2 | bauzas: johnthetubaguy ye are both on the nova satable matainance team correct? can ye take a look at this trival change in os-vif https://review.openstack.org/#/c/488670/ we dont have a seperate release team so we use nova's | |
| 13:06:13 | cdent | efried: I think that because placement went wsgi before everything else, some later learnings didn’t get incorporated into its devstack handkling | |
| 13:06:34 | cdent | and because placement is managed in grenade as part of nova, despite being its own thing in devstack, caused some packet drops | |
| 13:17:56 | bauzas | sean-k-mooney2: lemme look | |
| 13:19:28 | mdbooth | Folks, has anybody else encountered MySQL-python FTB on Fedora 27? | |
| 13:19:47 | sean-k-mooney2 | bauzas: its just an update to the .gitreview but its been open for a few months now so would be good to merge | |
| 13:20:12 | mdbooth | This django bug shows the issue I hit: https://github.com/OWASP/django-DefectDojo/issues/407 | |
| 13:20:23 | bauzas | sean-k-mooney2: +2 | |
| 13:20:50 | sean-k-mooney2 | bauzas: thanks | |
| 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/ | |