Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-06
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?
15:07:59 purplerbot <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 [2017-12-06 14:27:39.279804] [n 3ahR]
15:07:59 cdent sdague: I’ve responded to you twice about that already, last one was [t 3ahR]
15:08:45 openstackgerrit Eric Fried proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
15:09:04 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242
15:09:05 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add regression test for bug 1735407 https://review.openstack.org/526095
15:09:06 openstack bug 1735407 in OpenStack Compute (nova) "[Nova] Evacuation doesn't respect anti-affinity rules" [Medium,In progress] https://launchpad.net/bugs/1735407 - Assigned to Balazs Gibizer (balazs-gibizer)
15:09:13 efried jaypipes cdent ^ Removed some test stuff that got accidentally re-introduced at PS86; and added that Depends-On.
15:09:44 jaypipes efried: tyvm
15:09:44 sdague oh, sorry, apparently I missed that last message
15:10:31 cdent sdague: no worries, that’s pretty much exactly the reason I made that [t stuff
15:16:40 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Object changes to support last-modified headers https://review.openstack.org/521639
15:16:40 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Add cache headers to placement api requests https://review.openstack.org/521640
15:16:41 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Add info about last-modified to contrib docs https://review.openstack.org/526084
15:17:15 cdent mriedem: that ^ tries to address your comments
15:18:53 mriedem sdague: cdent: fwiw i looked at the grenade heat failure too, there is a test timing out as chris mentioned, no failures in the heat logs that i could see, but without a history of runs on that job it's hard to know if it's just always unstable
15:19:10 mriedem since it's non-voting and heat, i'm assuming it's just unstable
15:19:35 mriedem as i recall, we removed heat from tempest full runs because of random timeouts
15:20:26 dansmith I've sent it to its destiny
15:25:53 belmoreira mriedem dansmith Quick question. Ocata requires cells mappings to be defined (it needs at least one cell defined). With cellsV1 are these mappings used in anyway?
15:26:00 mriedem edleafe: comments in https://review.openstack.org/#/c/511358/
15:26:32 dansmith belmoreira: yeah, but they're not the same cells
15:27:14 dansmith belmoreira: meaning, the mappings should just be straight-through to whatever the regular nova db for each cell is
15:28:11 belmoreira the cells DBs endpoints are actually used?
15:28:27 belmoreira I mean, with cellsV1 and no conductor on top cell

Earlier   Later