Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-02
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
17:21:34 dansmith mriedem: this is exactly the same as the service catalog thing to me
17:21:35 dansmith mriedem: but, like I say, whatever you want
17:25:57 mriedem dansmith: service catalog re: order of steps during deploy?
17:26:02 dansmith yeah
17:27:20 mriedem ok, so maybe i'll just do the devstack change first, hold off on the nova patch and keep it in the pocket
17:28:19 mriedem we could log a warning if there is only 1 cell cached when listing instances, saying hey dummy you started n-api before all of your cells were mapped, you need to create the cells and restart nova-api
17:30:21 dansmith yeah, totes
17:34:39 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow https://review.openstack.org/438729
17:36:05 sileht mriedem: thx, should abandon mine ?
17:36:43 mriedem sileht: it's probably still a good idea to not load extras/plugins until nova is setup
17:40:05 mriedem dansmith: do you remember why for cellsv1 at the end we sync the db? https://github.com/openstack-dev/devstack/blob/master/lib/nova#L978
17:40:11 mriedem after creating cell1 and mapping the hosts to it
17:40:40 dansmith that line is for cellsv2
17:41:21 dansmith mriedem: I think some of this came from just doing cellsv2 stuff where we had bits for cellsv1 which isn't necessarily sensical
17:41:35 mriedem that's cellsv1
17:41:39 mriedem if not n-cell is above
17:41:42 mriedem n-cell is v1
17:41:52 mriedem i'm going to remove it and see what happens
17:46:41 dansmith oh sorry I see I read it wrong
17:47:04 dansmith so .. no I'm not sure
17:52:01 mriedem dansmith: let's find out https://review.openstack.org/440739
17:53:12 mriedem i'm going to lunch
18:02:54 openstackgerrit Anusha Unnam proposed openstack/nova master: POC: add descriptions to server tags https://review.openstack.org/434842
18:04:04 openstackgerrit Jay Pipes proposed openstack/nova master: placement: ironic inventory reporting https://review.openstack.org/437602
18:04:15 jaypipes cdent: ^^ fixed your requests
18:04:27 cdent rad
18:15:04 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Get instance availability_zone without hitting the api db https://review.openstack.org/439754
18:15:05 openstackgerrit Dan Smith proposed openstack/nova master: Target cell in super conductor operations https://review.openstack.org/438022
18:15:05 openstackgerrit Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023
18:15:06 openstackgerrit Dan Smith proposed openstack/nova master: Make scheduler target cells to get compute node instance info https://review.openstack.org/439891
18:15:06 openstackgerrit Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024
18:15:07 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
18:18:44 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add spec to use cinder's new attachment API https://review.openstack.org/373203
18:48:56 dansmith cdent: edleafe since jaypipes isn't around.. do you recall why he wants ironic to be special in the situation where custom resource classes are auto-created?
18:49:12 dansmith I'm not sure I ever knew, so maybe recall is the wrong word
18:50:09 cdent dansmith: my recollection is thin but I think it was because we already promised we would, but that we should not extend that promise to anything else. As you've asked, "why not?" is a fair question on that.
18:50:23 dansmith hmm, okay
18:51:04 dansmith if there is a sunset date on that, then maybe I'm on board, like after ironic creates and maintains these themselves or something
18:51:07 cdent It seems to me that if we're in the context of the compute-node then we may as well auto create because we're in charge there
18:51:19 dansmith right, and virt drivers are in-tree
18:51:23 cdent and if we do it for one, may as well for anything
18:51:35 dansmith yeah
18:51:36 dansmith and you could use the same logic,
18:51:51 dansmith in that until operators are familiar with placement, we auto-create things for them from all virt drivers
18:52:28 cdent the issue with that, of course, is that whole "precedent" thing. If we start auto creating willy nilly now, then everyone will want it later or never adapt to the time when we don't
18:52:29 dansmith also, if your virt driver knows about VFs, PFs, and GPUs, but can't report them until you create a class for them or something.. I dunno, kinda feels too manual to me
18:52:40 dansmith well, I dunno
18:52:53 dansmith but I also don't really know why we wouldn't auto-create anyway, so..
18:53:03 cdent Yeah, that's the crux
18:53:05 dansmith but, sounds like I'm not missing something major, which is good
18:53:39 cdent as far as I recall, you're not, but it often feels like there are major things happening while I blink
18:54:09 dansmith well, it's enough to justify my -1 until we get jay back to discuss at least :)

Earlier   Later