| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 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 | |
| 14:54:48 | edleafe | mriedem: I'm currently mired in fixing all the broken unit tests for the resize changes | |
| 14:55:00 | edleafe | But I can get to that in a little while | |
| 14:55:20 | mriedem | ok, i'll start skimming the top patch in the series then | |
| 14:57:04 | ildikov | mriedem: morning :) | |
| 14:57:52 | ildikov | mriedem: checked the comments and answered to a couple | |
| 14:58:38 | ildikov | mriedem: do you plan to touch that chain or should I start updating the virt/block_device changes? | |
| 14:59:31 | huanxie | Hi jaypipes, I have a patch https://review.openstack.org/#/c/451641/ to remove using of nicira-iface-id for XenServer VIF, could you please review it when you are available? This is a follow up patch as my previous patch in Pike has deprecated the using of nicira-iface-id. | |
| 15:00:12 | mriedem | ildikov: i'll handle the block_device.py changes in a bit - i think we definitely want to rollback if attachment_complete fails, just like in the old flow | |
| 15:00:33 | mriedem | i just needed some time away from the series to think about that | |
| 15:00:41 | ildikov | mriedem: yeah, we did when the call was first added | |
| 15:01:03 | ildikov | it got uncovered when I moved, forgot to add another try-except block... :/ | |
| 15:01:05 | ildikov | my bad | |
| 15:01:12 | mriedem | i'm less sure about when we call save() before doing the driver attach, but i think we want to do similar to what we did before - only save() the connection_info after we've attached on the driver | |
| 15:01:34 | mriedem | otherwise we're not actually connected | |
| 15:02:16 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: vSCSI https://review.openstack.org/526094 | |
| 15:02:32 | ildikov | mriedem: the save() calls were put there a while ago and I removed the second one when johnthetubaguy pointed it out | |
| 15:02:51 | ildikov | I'm a bit confused all the time when I get those parts that what gets saved to where and when... | |
| 15:03:47 | ildikov | I think we ended up with two calls to be extra sure we have everything as at least on the Cinder side we got into trouble due to missing save() calls | |
| 15:04:11 | ildikov | and my brain is definitely too small for keeping both code bases in it :) | |
| 15:05:04 | dansmith | cdent: that patch to grenade makes sense to me, but I haven't gone digging to see if it actually makes sense | |
| 15:05:15 | dansmith | cdent: but sdague will know, so let him +2 it first and then I'll hit it | |
| 15:05:48 | cdent | many are the layers to sense | |
| 15:07:05 | sdague | dansmith / cdent the change looks good to me conceptually, I just want to make sure that the heat fail seems unrelated. cdent: you able to take a look and give an assessment? | |
| 15:07:46 | dansmith | I thought he said he did, and couldn't | |
| 15:07:52 | dansmith | maybe a recheck to see? | |