Earlier  
Posted Nick Remark
#openstack-nova - 2017-12-06
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
15:29:04 dansmith belmoreira: they are, yeah, but for you, each api db will have one cell mapping pointing at the corresponding cell db
15:29:31 dansmith belmoreira: remember, cellsv2 is fully woven into the main code.. there is no way to separate it.. no mode where the cell mappings aren't used
15:31:32 belmoreira dansmith: but I continue to have a global api_db
15:31:52 dansmith belmoreira: I thought you were doing separate api dbs?
15:32:54 dansmith I thought the question was over separate/global placement
15:33:03 belmoreira dansmith yes, but I still need to have a global (top cell in cellsV1). local nova_apis (in each child cell) are basically for placement
15:33:05 dansmith I think we've always assumed that api_db would be replicated in each cellsv1 cell
15:34:07 dansmith belmoreira: well, the api db at the top isn't global though, right? it just has all instances in it because of the fact that the top-level cell does too...
15:34:25 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add regression test for bug 1735407 https://review.openstack.org/526095
15:34:26 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:34:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242
15:36:18 belmoreira I didn't test everything yet, but was expecting to have instances, build_request, request_spec, aggregates, flavors... everything defined there. Without need to define it again in the locals nova_api DBs
15:36:54 dansmith well, the bit of compute/api that gets re-run in the child cells will need to talk to an api database,
15:37:01 dansmith but perhaps that will be okay for it to be global
15:37:27 efried jaypipes If I ask for ?tree=<uuid that doesn't exist>, should I get an empty list or a 404?
15:37:35 dansmith belmoreira: regardless, in that top-level nova_api db, I think you just want the one cell mapping to the api cell's nova db
15:37:39 jaypipes efried: empty list
15:37:49 efried jaypipes is that The Right Thing?
15:37:53 jaypipes efried: ask cdent.
15:37:55 edleafe mriedem: ok; still cleaning up the functional tests in https://review.openstack.org/#/c/516707
15:40:11 belmoreira dansmith: hummm... I was not thinking about that cell mapping (top level nova DB).
15:41:21 mriedem efried: jaypipes: i think empty list is the right thing
15:41:31 mriedem 404 is for a specific resource not being found
15:41:42 mriedem e.g. GET /resource_providers/{id} where the RP for {id} isn't found
15:42:08 mriedem something not found in a body is a 400, but this is a filter parameter
15:42:20 mriedem filtering on something which doesn't exist gets you nothing back
15:42:43 mriedem i seem to remember this same quandary in another spec, maybe for the traits stuff
15:42:47 belmoreira dansmith: I need to test it. But still not sure why it's required.
15:43:00 dansmith belmoreira: not sure why the cell mapping is required?
15:43:31 efried mriedem jaypipes okay, that makes sense, thanks.
15:44:11 belmoreira dansmith: I understood that you said that in nova_api global I need to have a mapping to the nova DB (father cell)
15:44:36 dansmith right

Earlier   Later