| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 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 | 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:18 | efried | but I need to wait until you've published the bottom three to start rebasing on top. | |
| 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: update client to set parent provider https://review.openstack.org/385693 | |
| 14:29:21 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 14:29:25 | jaypipes | efried: et voila. ^ | |
| 14:29:38 | efried | jaypipes Merci bien. | |
| 14:29:57 | jaypipes | efried: changed to in_tree and also added that additional func test you wanted for the in_tree=CHILD_RP_UUID and returned grandchild RP with resources query | |
| 14:30:06 | efried | jaypipes beaut. | |
| 14:30:21 | jaypipes | efried: and fixed (hopefully?) the placement-api-ref shit. | |
| 14:30:28 | mriedem | sdague: failopotamus might be busted on something with the zuulv3 move | |
| 14:30:33 | mriedem | can't get any data on the grenade-heat job | |
| 14:32:21 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: archive_deleted_instances is not atomic for insert/delete https://review.openstack.org/526065 | |
| 14:35:32 | mdbooth | mriedem: That's not a bug, that's a feature! https://review.openstack.org/#/c/400384/20 | |
| 14:36:30 | _ix | Good morning folks. I was curious if it were possible to take an existing hypervisor from one Openstack implementation and join it to a different one. | |
| 14:36:57 | mriedem | define "join" | |
| 14:37:19 | _ix | Basically, repoint the hypervisor to start using a different controller and attendant services. | |
| 14:37:30 | _ix | But have that controller aware of the VMs running on it. | |
| 14:38:01 | mriedem | no | |
| 14:38:16 | mriedem | you can probably make a different controller aware of and manage the compute node, | |
| 14:38:19 | mriedem | but not the existing VMs | |
| 14:38:28 | mriedem | that would be like creating VMs in virsh directly and expecting nova to start managing them | |
| 14:38:33 | mriedem | which won't happen | |
| 14:38:49 | _ix | A man can dream, can't he? | |
| 14:39:05 | mdbooth | _ix: Only approved dreams. | |
| 14:39:12 | efried | _ix There are orchestrators (that live on top of nova) that can do "discovery" like that. | |
| 14:39:35 | mdbooth | efried: orly? | |
| 14:39:48 | _ix | Yes, do tell, efried. | |
| 14:40:27 | efried | mdbooth _ix I'm not necessarily talking about OpenStack projects. I just happen to know PowerVC does that. | |