Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-02
16:23:45 mriedem jaypipes: yeah you need to update the hacking version here https://github.com/jaypipes/os-traits/blob/master/test-requirements.txt#L5
16:23:58 mriedem http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n424
16:24:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: handle uninited fields in notification payload https://review.openstack.org/415857
16:24:22 openstackgerrit Arnaud Morin proposed openstack/nova master: Set default value to HTTP_X_FORWARDED_PROTO https://review.openstack.org/423375
16:28:12 jaypipes mriedem: thx for the heads up, will fix up now.
16:29:15 mriedem dansmith: before i write tests, how much do you hate this? https://review.openstack.org/#/c/440652/
16:29:35 mriedem trying to think of ways to auto-invalidate or update that CELLS cache when a new cell mapping is created
16:30:09 dansmith mriedem: one cell is not valid regardless of why so I think you need only check the length
16:30:31 dansmith I still assert this is a silly workaround, but if you want it that's fine
16:31:31 mriedem i don't know that i want it
16:31:40 mriedem the devstack change would also unblock gnocchi
16:31:41 mriedem i think
16:35:44 dansmith mriedem: what was the change in the last day or so that caused this?
16:35:57 mriedem dansmith: https://review.openstack.org/#/c/427392/
16:36:16 dansmith ah
16:36:30 dansmith that caused me trouble too
16:38:20 jaypipes edleafe, alex_xu, bauzas, mriedem, dansmith: fixed up pep8/hacking thing. https://review.openstack.org/440678 now new root of series.
16:38:31 mriedem it does follow https://docs.openstack.org/developer/nova/cells.html#fresh-install more closely now, but simple_cell_setup and when it's called is kind of our issue now i think
16:38:54 mriedem dansmith: if we created cell1 around the same time as cell0, before starting nova-api, then we wouldn't have the cache issue
16:39:17 mriedem we'd just have to run discover_hosts after starting n-cpu
16:39:34 dansmith I still don't understand why we have the problem at all, since devstack is sequential
16:39:37 bauzas jaypipes: I thought you were hit by the fact we were pulling pbr-2.0.0
16:40:41 mriedem dansmith: devstack is mapping cell0, starting n-api, then loading extras (ceilometer plugin) which starts querying n-api, then devstack eventually does create_cell which calls simple_cell_setup
16:40:46 mriedem which creates the cell1 mapping
16:40:57 mriedem for the 'normal' setup there are no extras so we don't see it
16:41:52 dansmith mriedem: ah so we really are starting it in the wrong order we just don't hit the cache?
16:42:24 mriedem dansmith: yeah
16:42:34 dansmith mriedem: okay yeah then we should change that
16:42:36 mriedem ceilometer hit the cache and stored only cell0
16:42:44 dansmith mriedem: you're going to break my fleetify patch, but..
16:43:10 markus_z mriedem: I don't find a clue to solve the novnc issue. Tomorrow I have no time left, I'll give it another try on Monday.
16:43:22 mriedem markus_z: ok thanks for looking
16:43:35 mriedem dansmith: sileht has this https://review.openstack.org/#/c/440651/
16:43:39 mriedem but it is a workaround yeah
16:43:58 mriedem so the proper fix is probably what i described above, with creating cell1 at the same time as cell0
16:44:08 dansmith mriedem: yeah
16:44:10 mriedem and then change simple_cell_setup in the post-setup to just discover_hosts
16:44:17 mriedem or map_cell_and_hosts or whatever
16:44:51 dansmith not map_cell_and_hosts
16:44:52 mriedem i don't know if/how that messes up upgrade because we'd already have cell1
16:44:53 dansmith that creates a cell
16:44:56 dansmith just discover at the end
16:46:05 mriedem we need to not create cell1 if it already exists, which we could maybe figure out with the list_cells command
16:46:40 mriedem jaypipes: +2 on https://review.openstack.org/#/c/440678/
16:47:54 dansmith mriedem: that point where we create cell0 we're on an empty db regardless of upgrade because we're on the old side right?
16:49:13 mdbooth Is this going to be a problem in general when adding a cell? If you can add a cell and have instances scheduled to it instantly, but those instances won't be visible, isn't this something you're always going to hit when adding a cell?
16:49:14 jaypipes mriedem: cheers. the end goal here is to release os-traits lib with a git tag today so we can begin working on tests for that "sync os-traits" thing in placement-manage per bauzas and alex_xu's discussion on the traits spec.
16:50:01 mdbooth iow is it worth fixing this with something a bit more general purpose than a workaround for cell1?
16:50:32 mriedem dansmith: i think https://github.com/openstack-dev/devstack/blob/master/lib/nova#L700 is the dirty secret
16:50:40 mriedem we drop and recreate the nova_api db
16:50:51 mriedem dansmith: same for cell0
16:50:58 dansmith mriedem: eh?
16:51:03 mriedem i think from newton->ocata that wasn't a problem for cell0 because in newton we didn't put anything into cell0
16:51:15 mriedem but ocata cell0 could have stuff in it
16:51:22 dansmith init_nova only runs on the old side right?
16:51:31 mriedem idk
16:51:57 mriedem i thought it ran on both but i don't have grenade memorized
16:52:02 dansmith we blow away all the dbs there.. nothing would work if we ran it in both places
16:53:34 mriedem ok. i was thinking of this https://review.openstack.org/#/c/393441/2/projects/60_nova/from-newton/upgrade-nova@8
16:53:42 mriedem unrelated and confusing myself i suppose
16:54:15 mriedem anyway, i can work a change to do create_cell cell1 after map_cell0 and change simple_cell_setup to be discover_hosts in devstack
16:54:24 mriedem and if grenade hates it i guess we'll find out
16:55:46 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP compute: Move detach logic from manager into driver BDM https://review.openstack.org/439520
16:55:47 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Only destroy BDMs after successful detach call https://review.openstack.org/440693
16:58:31 aunnam johnthetubaguy, Will you be updating the poc patch https://review.openstack.org/#/c/434842/ by removing scope and access as they are not needed right now?
16:59:12 johnthetubaguy aunnam: I was hoping you or sneti might fancy doing that :)
16:59:18 aunnam johnthetubaguy, Or you want us to update the patch?
16:59:35 aunnam johnthetubaguy, sure will do that, thanks
17:00:32 mriedem sileht: looks like my nova workaround patch fixed the gnocchi issue
17:02:20 mdbooth mriedem: re the CELLs cache, would it be feasible to manage that with memcached via oslo_cache? Could a newly created cell poke itself into the cache before allowing anything to be scheduled there?
17:02:55 mdbooth Should mean you'd have no weirdness period after creating a new cell.
17:03:13 mriedem mdbooth: at a minimum yes on oslo.cache to add a timer to it
17:03:19 mriedem mdbooth: feel free to start that
17:03:36 mriedem as for how to auto-register a new cell to invalidate the cache or put itself into it, i'm not sure how we do that right now
17:03:57 mdbooth mriedem: Well I was explicitly thinking of a distributed cache, like memcached
17:04:17 mriedem with oslo.cache the backing cache store is abstracted
17:04:20 mriedem i thought anyway
17:04:28 mdbooth I think we have the infrastructure in place for that already, but I don't know what the deployment concerns would be
17:04:40 mdbooth Yes, looks like it is
17:05:11 mriedem we already use oslo.cache in several places so it should be a common pattern
17:05:44 mriedem even with a timeout on the cache, we still have a timing issue between when a new cell is added and when the cache invalidates and gets updated
17:06:02 mriedem having said that, we don't expect new cells to be added all the time
17:06:10 mdbooth Right. Unless you've got a distributed cache, you're always going to have a broken period there.
17:06:55 mdbooth Could you put it on the deployer? Before enabling scheduling to a new cell, all n-api need to be restarted?
17:07:48 mdbooth Ugly, but deterministic.
17:08:46 mriedem i believe that's what we've said if you update db or transport url connection info in a cell mapping
17:10:49 mriedem yeah https://docs.openstack.org/developer/nova/man/nova-manage.html#nova-cells-v2
17:10:54 mriedem "NOTE: Updating the transport_url or database_connection fields on a running system will NOT result in all nodes immediately using the new values. Use caution when changing these values."
17:12:52 mdbooth mriedem: Is it possible to add a cell without allowing instances to be scheduled there, btw?
17:13:11 dansmith we are really a long way from needing to overthink this cache thing
17:13:14 mriedem mdbooth: if the cell doesn't have hostmappings
17:13:30 mriedem if it doesn't have host mappings nothing goes into it
17:13:34 dansmith you can't even have multiple cells today
17:13:36 dansmith so a static list is *fine*
17:13:40 mdbooth dansmith: Yeah, with the restarting things I was backing away from distributed caches :)
17:17:42 mriedem dansmith: so you want me to just change this to check for len 1 and just always re-query until we have more than 1? https://review.openstack.org/#/c/440652/1/nova/compute/api.py
17:18:00 dansmith mriedem: it's not what I want, but I will accept it :)
17:18:09 dansmith we need to fix devstack anyway right?
17:18:30 mriedem i think so
17:18:46 mriedem i only worry about fixing devstack and others in the wild falling into the same trap

Earlier   Later