| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 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 | bauzas | dansmith: I can upload it soon yeah | |
| 14:49:56 | _ix | It's newton to pike. | |
| 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 | cdent | sdague: I’ve responded to you twice about that already, last one was [t 3ahR] | |
| 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: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 | sdague | oh, sorry, apparently I missed that last message | |
| 15:09:44 | jaypipes | efried: tyvm | |
| 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] Add cache headers to placement api requests https://review.openstack.org/521640 | |
| 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: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 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242 | |
| 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: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 | |
| 15:45:36 | edleafe | efried: what mriedem said. Empty list is correct. | |
| 15:46:02 | efried | thanks | |
| 15:46:14 | belmoreira | dansmith: I completely forgot to do that mapping. And in my early tests I haven't seen any problem | |