Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-06
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
15:46:59 dansmith belmoreira: cellsv1 will probably side-step some things that would make things continue to work without that mapping, but not all
15:47:15 dansmith belmoreira: just because it overrides certain code paths that we're not updating for cellsv2
15:47:36 belmoreira dansmith: fair enough. Must be that
15:47:37 dansmith belmoreira: I wouldn't think it would override enough to make it seem like things are really working, but I'd have to test, as you say
15:48:00 mriedem in ocata,
15:48:15 mriedem it looks like the only things that use cell mappings are the api when listing instances, and conductor when burying an instance that fails to shedule in cell0
15:48:23 mriedem for cellsv1, are those things that only happen in the child api?
15:48:31 dansmith no, that's the thing,
15:48:36 openstackgerrit Huan Xie proposed openstack/nova master: XenAPI: Don't use nicira-iface-id for XenServer VIF https://review.openstack.org/451641
15:48:42 dansmith listing instances should be mostly the same,
15:48:47 dansmith althouuuuugh...
15:49:00 dansmith we do have some "if cellsv1: then do_old_thing()" escapes in that listing logic
15:49:01 dansmith so maybe that's it
15:49:07 mriedem oh wait,
15:49:08 mriedem yup
15:49:15 dansmith yeah, okay
15:49:16 mriedem when listing instances, if cellsv1 we do the old thing
15:49:26 mriedem we do look in cell0 though
15:49:30 dansmith yeah
15:49:31 mriedem so you'll need the cell0 mapping at the top yes?
15:49:32 mriedem ok
15:49:34 dansmith yes
15:49:38 mriedem belmoreira: ^
15:49:46 dansmith belmoreira: you will want the record there anyway, at some point
15:49:47 mriedem scheduler and api don't use cell mappings until pike
15:50:02 dansmith belmoreira: also, while you're here.. this fix is tanking the cellsv1 job: https://review.openstack.org/#/c/523187/
15:50:06 dansmith which is, like, not a good sign,
15:50:11 belmoreira yeah, cell0 I defined
15:50:13 dansmith but I'm not sure why, especially since you said it works
15:50:36 dansmith like, 100% fail on anything that hits nova
15:50:40 dansmith which seems hard to believe
15:55:22 belmoreira dansmith: I'm running this patch already. Haven't detected any issue yet. However, the functionality that we expose is very limited. Maybe that's why.
15:55:24 huanxie Hi jaypipes, I have updated the reno to make it precise and please help review it again https://review.openstack.org/#/c/451641/ Thanks a lot :)
15:55:45 mriedem belmoreira: can't even build an instance it looks like
15:55:47 jaypipes huanxie: already +2d.
15:55:48 dansmith belmoreira: I dunno, this seems to fail everything all the time, but I can't really see any errors in the logs
15:55:49 mriedem times out waiting to go to ACTIVE
15:56:17 huanxie Many thanks jaypipes :)
15:56:21 belmoreira dansmith: but, as you said, not a good sign :) Will keep eyes open on this
15:56:58 dansmith well, anyway, I don't want to spend too much time on it, but unless we figure that out, we can't merge it
15:57:09 belmoreira dansmith: definitely create/delete instances is working for us with this patch
15:57:44 dansmith although that's ocata I guess
15:57:45 belmoreira but I'm running newton
15:57:49 dansmith oh, newton
15:58:07 dansmith well, still, I'd expect to see an error somewhere if this was actually blowing something up
15:58:19 belmoreira in pike I will not need this patch
15:59:12 openstackgerrit Merged openstack/nova master: Add a new check to volume attach https://review.openstack.org/525622
15:59:43 mriedem dansmith: looking at the instance create flow, if cellsv1 the api will create the instance before casting to build_instances in conductor,
15:59:49 mriedem build_instances in conductor creates the instance mapping
16:00:13 mriedem well, api creates the instance mapping
16:00:38 mriedem conductor gets the host mapping for the chosen host and pulls the cell mapping from that host mapping to set on the instance mapping
16:00:41 mriedem then deletes the build request
16:00:53 mriedem ah,
16:01:03 mriedem and if the build request is already destroyed when conductor tries to do it,
16:01:07 mriedem conductor deletes the instance mapping
16:01:11 mriedem which the api relies on i think
16:01:40 mriedem https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L599-L605
16:01:43 dansmith oh you think we're deleting the build request early enough that it just nukes the instance when it tries because it assumes the user did it?
16:02:34 mriedem maybe
16:02:46 mriedem and when getting the instance from the api, we'll pull it from the top cell https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2221

Earlier   Later