| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 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. | |
| 14:40:40 | mdbooth | efried: How would you create db entries without creating the guest? | |
| 14:40:54 | mdbooth | Ah, ok | |
| 14:41:15 | efried | mdbooth Yeah, we don't create 'em in nova. Just let you manage 'em whether they were created in nova or not. | |
| 14:41:30 | _ix | Are there any other concepts of having an existing kvm vm and giving OS control over it? | |
| 14:41:41 | _ix | Maybe by creating an image? | |
| 14:42:10 | mdbooth | _ix: In the general case, Nova is very opinionated not only about having various metadata (mostly in the db) about an instance, but also exactly how that instance exists on the hypervisor. | |
| 14:42:46 | efried | _ix It sounds like something that's possible. I don't know of an example of any turnkey tools to do it, but that doesn't mean they don't exist. | |
| 14:42:59 | mdbooth | Importing a guest which was created by something else is an open-ended problem with countless edge cases | |
| 14:43:16 | _ix | I can appreciate that, and I don't mind doing the work. | |
| 14:43:24 | efried | You could certainly create a disk image from a non-Nova VM and stuff it in Glance and use it to create Nova VMs. That's how you bootstrap Nova VMs in the first place, nah? | |
| 14:43:34 | mdbooth | The guest would have to already be something which nova can describe exactly | |
| 14:44:00 | mdbooth | And then you'd have to create its metadata | |
| 14:44:02 | efried | yeah, you'd have to specify the metadata... | |
| 14:44:25 | efried | jaypipes FYI, built the placement-api-ref locally for that patch and it passes. | |
| 14:44:29 | mdbooth | It would be a pretty hard problem, anyway. | |
| 14:44:34 | jaypipes | efried: cool. | |
| 14:44:38 | mdbooth | _ix: Incredibly useful, though. | |
| 14:45:27 | efried | jaypipes Oh, maybe I built it for the wrong patch. Pretend I didn't say that, but stay tuned. | |
| 14:45:47 | _ix | Maybe this isn't as edgey of an edge case as I had thought. The requirement was to create a new openstack deployment while leaving the previous one largely intact. | |
| 14:45:59 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Add info about last-modified to contrib docs https://review.openstack.org/526084 | |
| 14:46:45 | _ix | Now that the new deployment is starting to outpace the old deployment in maturity, I'd like to cut over to the new one. But cutting over isn't that simple with existing VMs. | |
| 14:46:46 | sdague | mriedem: it might be, I haven't tried to use it lately | |
| 14:47:20 | mriedem | _ix: does "largely intact" include keep the ports and volumes connected to the old VMs? | |
| 14:47:43 | mriedem | if the new thing should look like the old thing, then you have a problem with ports and volumes too | |