| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 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 | mriedem | i know it's not an issue for libvirt | |
| 21:15:51 | dansmith | otherwise we're just lazy-loading nothing | |
| 21:16:16 | dansmith | we can do both I guess just to make sure we don't get the 'splosion | |
| 21:16:40 | mriedem | yeah see that's the other thing, the comment in the change to pre-load those said it was doing ec2_ids and keypairs because those are known to be used in there, | |
| 21:16:46 | mriedem | device_metadata clearly is also | |
| 21:17:02 | dansmith | yeah, fair enough | |
| 21:17:59 | mriedem | i'll just move my test over to your patch and +W it | |
| 21:18:33 | dansmith | already abandoned and +2d yours | |
| 21:18:37 | mriedem | guh | |
| 21:18:54 | dansmith | you had nothing but mean things to say about mine | |
| 21:19:03 | mriedem | i'm sorry | |
| 21:19:07 | mriedem | a little | |
| 21:19:11 | dansmith | yours was a little bigger | |
| 21:20:15 | mriedem | "I think you mean "touch"" - i try to avoid getting sued | |
| 21:20:29 | dansmith | since when? | |