18:00:29 <stevemar> #startmeeting keystone
18:00:30 <openstack> Meeting started Tue Dec 22 18:00:29 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:33 <openstack> The meeting name has been set to 'keystone'
18:00:52 <stevemar> i can't imagine this taking very long... the agenda is empty :)
18:01:00 <stevemar> #topic open discussion
18:01:02 <raildo> o/
18:01:10 <notmorgan> i move that we cancel the rest of the meeting
18:01:15 <notmorgan> and enjoy holidays
18:01:19 <gyee> ++
18:01:21 <breton> > holidays
18:01:36 <breton> in soviet russia it's a usual day
18:01:42 <notmorgan> and the same thing for next week
18:01:45 <notmorgan> in advance
18:02:14 <stevemar> notmorgan: i'll be around to redo this dance :P
18:02:23 <gyee> I don't believe in Santa anymore
18:02:32 <notmorgan> stevemar: call it early
18:02:46 <notmorgan> stevemar: just ML aannounce no meeting until post nye :)
18:02:49 <notmorgan> stevemar: eaaaasy
18:03:08 <stevemar> alright, i actually did want to chat about stable branches, but i can chat with bknudson_ in -keystone
18:03:20 <stevemar> no need for a meeting
18:03:27 <bknudson_> getting rid of stable branches?
18:03:33 <stevemar> bknudson_: fixing them :(
18:03:41 <bknudson_> stable is broken?
18:03:43 <gyee> stevemar, bknudson_, aren't we going to decide on the request-id thingy?
18:03:56 <bknudson_> we could decide on request-id
18:04:13 <notmorgan> man... you all should be vacationing :P
18:04:23 <stevemar> bknudson_: link?
18:04:37 <stevemar> notmorgan: you're more than welcome to vacationize early :D
18:04:50 <bknudson_> #link https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller
18:04:57 <bknudson_> blueprint for keystoneclient
18:05:21 <bknudson_> this is so that applications can get the request ID
18:05:41 <bknudson_> so for example if something goes wrong they can correlate the request with the keystone logs
18:05:51 <breton> > users['request_ids']
18:06:04 <breton> why not users.request_ids?
18:06:05 <bknudson_> it's a cross-project spec
18:06:19 <bknudson_> I don't know why it says users['request_ids']
18:06:24 <stevemar> breton: could use that too
18:06:36 <stevemar> implementation details :P
18:07:02 <stevemar> so i agree it's worth doing
18:07:03 <bknudson_> according to the cross-project spec it's .request_ids
18:07:19 <stevemar> not quite sure how to do it, but that's not my problem
18:07:20 <breton> bknudson_: yep, checked that too
18:07:44 <stevemar> what's the hold up? we need someone to do it?
18:07:47 <bknudson_> I assume there will be a library
18:07:56 <stevemar> there's always a library
18:08:04 <stevemar> any server side changes?
18:08:14 <gyee> client have full access to the headers
18:08:14 <bknudson_> Maho Koshiya assigned himself
18:08:27 <bknudson_> we've already got request ID middleware in the server.
18:09:02 <gyee> bknudson_, but we don't log them right?
18:09:12 <gyee> or in CADF
18:09:15 <bknudson_> gyee: request IDs are logged now by default
18:10:19 <bknudson_> gyee: here's an example: http://logs.openstack.org/86/256986/6/check/gate-tempest-dsvm-full/edf2cb7/logs/apache/keystone.txt.gz#_2015-12-22_17_14_34_990839
18:10:27 <bknudson_> INFO keystone.common.wsgi [req-1e5147fb-d2c6-4dab-b3e7-254db496c25f - - - - -] GET http://127.0.0.1:35357/v3/domains/default
18:11:24 <bknudson_> I made the change to get the request ID in the logs
18:11:28 <gyee> good
18:11:40 <navidp> bknudson_, ++
18:12:16 <bknudson_> so if we make it available to the clients and then eventually print it out when there are errors ...
18:12:23 <bknudson_> deployers might be able to figure out problems
18:12:49 <bknudson_> the question is do we need a spec for the ksc work or not?
18:12:57 <bknudson_> or do we go blueprint-only
18:13:26 <stevemar> blueprint only seems fine to me
18:13:28 <bknudson_> I prefer bp-only since there's already a x-proj spec
18:13:38 <stevemar> is there already a x-proj.... yeah
18:13:49 <stevemar> bp only it is!
18:13:52 <stevemar> i'll mark it as approved
18:14:04 <gyee> do it!
18:14:43 <stevemar> done!
18:15:23 <gyee> wow that's efficiency
18:15:28 <stevemar> i wanted to talk about our stable gate for keystonemiddleware
18:15:45 <stevemar> i saw this happen a week ago: https://review.openstack.org/#/c/256039/
18:15:57 <bknudson_> :)
18:15:59 <bknudson_> :(
18:16:19 <stevemar> seems like the latest release of pycadf messed things up
18:16:52 <bknudson_> payload = req.environ['cadf_event'].as_dict()
18:16:57 <stevemar> yep
18:16:58 <bknudson_> there's no 'cadf_event' anymore?
18:17:17 <stevemar> bknudson_: not just that, it's the use of a deprecated bit, i think
18:17:20 <bknudson_> or is it raising due to the deprecaion?
18:17:29 <stevemar> i proposed to backport this patch: https://review.openstack.org/#/c/258284/
18:17:36 <bknudson_> just change the test to say that deprecation is expected in that test
18:17:43 <stevemar> you can see gordc's comments about it
18:18:08 <stevemar> bknudson_: that would have to be a liberty only change no?
18:18:19 <bknudson_> stevemar: yes, liberty-only
18:18:37 <bknudson_> although the backport makes sense too
18:18:40 <bknudson_> it's fixing a bug, right?
18:19:35 <stevemar> bknudson_: not really, pycadf decided to create valid UUIDs for the event IDs going forward
18:19:44 <stevemar> and that makes it backwards incompatible
18:19:53 <stevemar> we could also cap the library
18:20:39 <breton> what's the problem with capping?
18:20:55 <bknudson_> safest is just to disable the deprecation check for that test
18:21:36 <bknudson_> we've had all sorts of problems with capping. we'd try to cap something and then some other uncapped lib would pull in a newer version anyways.
18:21:57 <stevemar> yeah, just wanted to lay out all our options
18:22:02 <stevemar> none are pretty :)
18:23:07 <stevemar> okay, we'll fix the tests for ksm
18:23:18 <stevemar> now more good news, KSA is also broken for liberty
18:23:22 <stevemar> http://logs.openstack.org/18/258318/1/check/gate-tempest-dsvm-neutron-src-keystoneauth/2d22945/logs/screen-g-api.txt.gz
18:23:35 <stevemar> proposal bot patch: https://review.openstack.org/#/c/258318/
18:23:56 <bknudson_> weird
18:24:41 <stevemar> maybe it's cause it is pulling in an uncapped ksm that is using ksa options?
18:24:58 <stevemar> haven't dug into this one too much
18:27:06 <stevemar> bknudson_: anywho, seems like it's just you and i
18:27:27 <stevemar> calling it early, we can figure out the stable stuff in -keystone later on today
18:27:35 <bknudson_> ok
18:27:39 <stevemar> thanks for coming gyee and breton
18:27:54 <stevemar> notmorgan you are free to leave now :P
18:27:55 <gyee> happy holidays
18:28:01 <stevemar> happy holidays everyone ;0
18:28:01 <stevemar> :)
18:28:07 <navidp> happy holidays
18:28:09 <bknudson_> happy festivus
18:28:22 <stevemar> next week is canceled, i'll send out a note to the ML about it :)
18:28:36 <stevemar> #endmeeting