Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-06
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
20:59:44 mriedem *bug?
20:59:49 dansmith mriedem: but I think the right approach is different, and he put one up for it
21:00:11 dansmith https://review.openstack.org/#/c/479335/
21:00:13 dansmith yeah
21:01:14 melwitt are we doing a nova meeting today?
21:01:17 mriedem yes
21:01:18 mriedem crap
21:02:24 mriedem dansmith: this is his i guess? https://review.openstack.org/#/c/479335/
21:02:39 dansmith mriedem: I just pasted that bove :)
21:03:00 mriedem oh i was looking at yours
21:13:49 dansmith mriedem: oh I bet you were
21:13:59 mriedem i was less than impressed
21:14:51 dansmith daaaum..
21:15:12 mriedem not sure i care for claudiub's change since it's specific to the virt driver, and xenapi just added this same support
21:15:25 mriedem but i think xenapi will be ok because they also blindly set instance.device_metadata
21:15:35 dansmith mriedem: well, the deal is, we needn't load this because libvirt always has this set once it has resolved the devices
21:15:50 dansmith so I think the better thing is to make sure that's the assumed behavior,
21:15:51 dansmith otherwise we're just lazy-loading nothing
21:15:51 mriedem i know it's not an issue for libvirt
21:16:16 dansmith we can do both I guess just to make sure we don't get the 'splosion

Earlier   Later