Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-06
19:39:10 melwitt oh, hm
19:39:13 mriedem i think there is a default timeout in oslo.cache
19:39:49 mriedem https://docs.openstack.org/oslo.cache/latest/opts.html
19:40:29 melwitt I see. thanks
19:40:50 mriedem i'm only guessing, i do remember going over the patch in nova that converted to use oslo.cache though and had questions like this
19:42:02 melwitt yeah, I think you're right though. the consoleauth stuff just uses nova/cache_utils and in cache_utils I see there's oslo_cache.dict and dogpile.cache.memcached as options. I'm not sure what/how we default to
19:45:27 melwitt default TTL is 600, so 10 minutes. a lot shorter than I thought
19:47:34 mriedem ildikov: i see the live migration change isn't in this series https://review.openstack.org/#/c/330285/
19:47:54 mriedem ildikov: so, i guess to test the new api flow plus live migration, we can just do a DNM nova change that depends on both
19:47:56 mriedem yeah?
19:50:10 ildikov mriedem: I can add it to the chain or just do what you say
19:50:30 mriedem ildikov: let's test it out first, i'll push a patch
19:51:08 ildikov mriedem: sounds good, thanks
19:51:29 melwitt okay, so if they configured oslo.cache themselves we use that, if they didn't, we make it a oslo_cache.dict
19:52:06 mriedem from what i remember, if it's not configured for some other backend, we use an in-memory dogpile cache dict cache yeah
19:52:21 melwitt your memory is excellent
19:53:11 openstackgerrit Moshe Levi proposed openstack/nova master: hardware offload support for openvswitch https://review.openstack.org/398265
19:53:31 mriedem all that clean livin'
19:55:42 melwitt dansmith: so the default TTL is 10 minutes but they could configure it for a lot longer
19:55:56 dansmith melwitt: yeah
19:56:59 dansmith melwitt: I dunno, I think it's fine to say "db is the way forward, memcache is deprecated, if you need, make sure you've configured for db and given enough time for things to expire before rolling
19:57:17 melwitt I dunno how big of a deal it would be. if we don't try to fall back on consoleauth, then at worst they get a InvalidToken and have to re-get a new access url and do again
19:57:34 dansmith right
19:58:01 dansmith there's some config thing now to choose whether we use memcache for that or not, right?
19:58:44 melwitt dansmith: not yet. there was described in the spec, but I think it wasn't added bc instance uuid presence could be used to detect old vs new (that's my speculation, I don't see it documented why they didn't go ahead with the config option)
19:58:53 dansmith oh I see
19:59:06 dansmith but
19:59:16 dansmith and so the code to always do it in the DB is unmerged?
19:59:45 melwitt I think the original design didn't have instance uuid (that was only added bc cells v2 + one proxy at top) and so they had the idea of the config option
19:59:56 melwitt yeah, nothing is happening in the DB yet
20:00:01 dansmith ah, okay I see
20:00:15 dansmith so
20:00:24 dansmith how about:
20:00:28 dansmith 1. Default to only db
20:00:36 dansmith 2. Workaround to check memcache first, fall back to db
20:00:49 dansmith 3. Expect that going forward for Queens it'll be db only
20:01:05 dansmith and a reno to say if you really really care about not resetting consoles, do the workaorund
20:01:15 dansmith I think we discussed forcing the console reset at some point
20:02:11 openstackgerrit Ildiko Vancsa proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987
20:02:45 melwitt dansmith: you mean add the config option for that right? where the choices are "DB only" and "consoleauth + DB"
20:03:00 dansmith melwitt: well, make it a workarounds config
20:03:08 melwitt oh, workarounds config. okay
20:03:11 melwitt I forgot about those
20:03:21 dansmith melwitt: call it [workarounds]/my_users_are_very_delicate_and_need_handholding=True
20:03:33 melwitt :D sure
20:03:52 dansmith I think that messages it as "this is a transitional helper thingy"
20:04:01 melwitt yeah, makes sense
20:04:10 dansmith could default it to true I guess, but I would say default to false and note it in the reno
20:04:19 dansmith because I expect very few people will need it
20:05:10 openstackgerrit Moshe Levi proposed openstack/os-vif master: unplug_vf_passthrough: don't try to delete representor netdev https://review.openstack.org/478820
20:05:34 openstackgerrit Moshe Levi proposed openstack/os-vif master: fix read the representor phys_port_name https://review.openstack.org/480213
20:38:18 dims mriedem : jaypipes : do you remember "why" there was pushback on the ConfKeyManager being in castellan? can't seem to find the email thread mentioned in the spec
20:38:58 mriedem ConfKeyManager?
20:39:26 dims mriedem : https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=ConfKeyManager&type=
20:40:11 dims mriedem : was reading "Move ConfKeyManager elsewhere" section in https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/use-castellan-key-manager.html
20:40:54 mriedem i think the spec was updated here https://review.openstack.org/#/c/338518/
20:41:37 dims yep, reading the updated text
20:41:38 mriedem i don't think it was in the ML
20:41:49 mriedem it was discussion in a patch or irc between kfarr, sdague and myself
20:42:03 dims mriedem : "Might be good to add a link to a ML discussion about the expressed concern?" was a note jay added to the review
20:42:10 mriedem yeah, it wasn't in the ML
20:42:37 dims ok, the only reference i see in ML is an assertion "but it will not live in castellan" http://lists.openstack.org/pipermail/openstack-dev/2016-January/083347.html
20:44:27 mriedem i can't seem to find where this came up in gerrit
20:44:47 dims mriedem : i am looking at line 125 in https://review.openstack.org/#/c/338518/3/specs/newton/implemented/use-castellan-key-manager.rst
20:45:01 dims "The community has expressed concern about ConfKeyManager"
20:45:07 mriedem dims: i understand that you're reading that :)
20:45:15 dims ah :)
20:45:16 mriedem where and how the community expressed concern is not clear
20:45:32 mriedem i'm pretty sure it was an irc discussion or something like that between kfarr, sdague and myself
20:45:33 dims right, just seems kaitlin's email
20:45:39 mriedem and we asked kfarr to update the spec
20:45:41 mriedem which is that change
20:46:06 mriedem that spec update was last july
20:46:11 mriedem the ML thread was from jan 2016
20:46:21 dims y, chasing ghosts
20:47:02 mriedem i think it basically amounted to,
20:47:12 mriedem barbican didn't want a fake key manager b/c it's not secure, obviously,
20:47:25 mriedem but the rest of us don't want fake key managers in nova/cinder/anywhere else that's copied that pattern for testing,
20:47:30 dims right, this is castellan
20:47:32 mriedem and because barbican isn't in base devstack,
20:47:35 mriedem we can't get it from barbican
20:47:48 mriedem *we can't use barbican, or rely on it being in the dsvm env
20:47:53 dims yep
20:48:22 dims that's what i am chasing prompted by a ping from ttx about potentially making barbican a base service in the future
20:48:51 dims there are 2 ConfKeyManager(s) one in cinder and one in nova :)
20:49:25 mriedem yeah and the cinder one is a copy of the nova one
20:53:50 mriedem found it
20:53:56 mriedem you owe me $5
20:53:58 dims looks like setting the api_class is never used in any tests
20:54:07 dims http://codesearch.openstack.org/?q=BarbicanKeyManager&i=nope&files=&repos=
20:54:12 mriedem http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-06-13.log.html#t2016-06-13T18:44:47
20:54:23 mriedem https://review.openstack.org/#/c/273717/
20:54:30 mriedem it was prompted by that devstack change
20:55:01 dims thanks mriedem ! i still have some RMB you can have :)
20:55:16 mriedem me too
20:59:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Pre-load instance.device_metadata in InstanceMetadata https://review.openstack.org/481235
20:59:15 mriedem dansmith: claudiub pointed this out the other day ^
20:59:31 dansmith mriedem: I put a patch up for it,
20:59:35 mriedem oh
20:59:43 mriedem same big

Earlier   Later