| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 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 | |
| 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 | |
| 14:47:50 | mriedem | i.e. the IP will change | |
| 14:48:04 | _ix | Fortunately, there are no volumes to be concerned with, and the ports aren't as important with dns. | |
| 14:48:28 | mriedem | if that's not a problem, just snapshot the vms from the old deployment and create new vms from those snapshot images in the new deployment, | |
| 14:48:29 | _ix | Largely intact would really just mean running and reachable. | |
| 14:48:30 | mriedem | if you don't care about downtime | |
| 14:48:37 | efried | jaypipes If https://review.openstack.org/#/c/384807/ was the docs-broken one -- that one passes now :) | |
| 14:48:37 | bauzas | dansmith: jaypipes: question about libvirt VGPU, given we recreate the XML when migrating or hard rebooting an instance, we don't have passed allocations, so the new XML wouldn't know about the existing VGPUs | |
| 14:48:39 | mriedem | if you care about downtime, use live snapshot | |
| 14:48:40 | _ix | Downtime isn't an issue. | |
| 14:48:51 | bauzas | dansmith: jaypipes: so I wonder if we should persist that | |
| 14:49:01 | bauzas | for spawning it's not a problem | |
| 14:49:08 | bauzas | given we pass the allocations | |
| 14:49:21 | dansmith | bauzas: we can look them up easily right? | |
| 14:49:40 | bauzas | dansmith: you mean about the change ? | |
| 14:49:41 | mriedem | _ix: so your old cloud is running juno and you want to move to pike, but aren't doing upgrades, right? | |
| 14:49:42 | _ix | Thanks for the discussion mriedem mdbooth efried. I've got some work to do. | |
| 14:49:52 | efried | enjoy, | |
| 14:49:54 | mriedem | _ix: in that case, easiest thing is just the snapshot move to the new cloud | |
| 14:49:56 | _ix | It's newton to pike. | |
| 14:49:56 | bauzas | dansmith: I can upload it soon yeah | |
| 14:50:16 | bauzas | dansmith: oh, you mean about the allocations ? | |
| 14:50:17 | _ix | I think that's what I'm planning on now. | |
| 14:50:18 | mriedem | hell you could share glance between deployments to make the image move easier | |
| 14:50:34 | _ix | That's a really good idea. | |
| 14:51:35 | dansmith | bauzas: I'm not sure what you mean, but we can now easily look up the _new_ allocations intended for the live migration from placement | |
| 14:52:36 | bauzas | dansmith: mmm, yeah | |
| 14:52:53 | mriedem | edleafe: are you going to handle https://review.openstack.org/#/c/516707/ soonish or would you like me to? i'd like to see a passing run through the stack on the functional tests and then skim the top patch and if nothing major, we can start merging early stuff in the series | |
| 14:53:00 | bauzas | dansmith: anyway, just uploading my change and we'll be discussing | |