15:59:42 <dims> #startmeeting oslo
15:59:42 <dims> courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, harlowja, haypo,
15:59:42 <openstack> Meeting started Mon Dec 14 15:59:42 2015 UTC and is due to finish in 60 minutes.  The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:43 <dims> courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps
15:59:43 <dims> courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek, gcb
15:59:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:47 <openstack> The meeting name has been set to 'oslo'
15:59:49 <lxsli> ohai
15:59:51 <bknudson> hi
15:59:56 <gcb> o/
15:59:57 <johnsom> o/
16:00:00 <sileht> o/
16:00:01 <rbradfor> o/
16:00:04 <kgiusti> o/
16:00:21 <haypo> hello oslo
16:00:26 <ozamiatin> o/
16:00:32 <dims> good morning/afternoon/evening/night - johnsom lxsli bknudson gcb sileht rbradfor kgiusti haypo ozamiatin
16:00:38 <haypo> maybe we can say hoslo for hello
16:00:47 <dims> haha
16:00:57 <johnsom> ha
16:01:09 <dims> #topic Red flags for/from liaisons
16:01:19 <bknudson> none for keystone
16:01:29 <johnsom> None from LBaaS land
16:01:55 <dims> the grenade job for kilo->liberty should be green now. had to fix oslo.middleware to put back oslo namespace stuff
16:02:02 <dims> thanks bknudson johnsom
16:02:16 <bogdando> hi
16:02:25 <dims> bknudson : did any of the other projects adopt the way keystone does tests for deprecated stuff yet?
16:02:28 <dims> hi bogdando
16:02:43 <bknudson> dims: I haven't seen anything
16:03:00 <haypo> FYI i'm the assigned liaison for nova, but i'm not working on nova anymore
16:03:07 <haypo> maybe nova needs a new liaison?
16:03:15 <dims> haypo : ack, can you please tell Nova PTL?
16:03:25 <haypo> dims: right, will do
16:03:35 <dims> haypo : thanks for the heads up
16:03:37 <dims> #topic Releases for Mitaka
16:03:45 <dims> Does anyone need releases today? please file reviews in openstack/releases repo.
16:04:29 <haypo> dims: i will need a release of oslo.service for liberty
16:04:44 <haypo> dims: is it possible to get it for next week? the required change is not merged yet :-D
16:05:06 <dims> haypo : y just file a review when ready
16:05:13 <dims> #topic New Spec Review
16:05:28 <dims> bogdando : can you please introduce this
16:05:30 <dims> #link https://review.openstack.org/256342 (Add a spec for a work queue messaging pattern)
16:05:48 <dims> sileht : around?
16:05:59 <haypo> dims: a review for the releases repo, right? (FYI the fix is https://review.openstack.org/#/c/256443/ a regression in signal handler, a race condition)
16:06:00 <bogdando> this spec is logical continuation of numerous openstack-dev ML topics
16:06:11 <sileht> dims, yes
16:06:35 <dims> sileht : bogdando : sounds like a new parallel API to me, right?
16:06:59 <bogdando> it is not clear what and how we already have implemented for worq-queue pattern in Oslo messaging
16:07:16 <dims> bogdando : right all we know is that we can't break anyone :)
16:07:26 <bogdando> yes, this is supposed to became so. But alternatives assume to figure out and rework the current state
16:07:53 <dims> sileht : prefer a fresh start here, right?
16:08:09 <dims> given the troubles we had enforcing the current API
16:08:19 <dims> (sequence of calls)
16:08:42 <bogdando> main points are clearly defined claims and failure modes
16:08:59 <bogdando> and hopefully new API docs...
16:09:01 <sileht> It's still unclear for me what we will add to oslo.messaging (I haven't yet read the latest patchset of this afternoon)
16:09:26 <bogdando> WorkQueue API
16:10:05 <bogdando> and I added new alt, "use celery and touch nothing please"
16:10:13 <sileht> lol
16:10:22 <dims> haha
16:10:41 * dims googles for "work queue api"
16:11:06 <dims> ok let's continue discussion on the spec itself. thanks bogdando
16:11:11 <dims> #link https://review.openstack.org/#/c/256431/  (Support RBAC with LDAP in oslo.policy)
16:11:26 <dims> is anyone here for this spec?
16:11:50 <dims> bknudson, stevemar : wanted to catch your eye ^^
16:12:03 <dims> not sure how it lines up with the dynamic policy work
16:12:15 <bknudson> there is no dynamic policy work.
16:12:33 <bknudson> what do you think about putting this in keystone-specs ?
16:12:45 <dims> bknudson : deep sixed
16:13:15 <dims> bknudson : what happened to the work?
16:13:25 <dims> "dynamic policy work"?
16:13:35 <bknudson> dims: dynamic policy was abandoned
16:13:51 <bknudson> we don't have any bps in m for dynamic policy.
16:14:01 <dims> bknudson : interesting thanks. please leave a note on that review to move to keystone-specs
16:14:08 <haypo> bknudson: what are the "operations" managed in LDAP?
16:14:27 <bknudson> haypo: I don't know what operations means?
16:14:32 <haypo> bknudson: who is responsible to handle these permissions on these operations? oslo.policy or keystone?
16:14:37 <stevemar> dims: bknudson is it really related to dynamic policy?
16:14:49 <bknudson> the work is in oslo.policy.
16:14:55 <haypo> bknudson: https://review.openstack.org/#/c/256431/7/specs/mitaka/ldap-rbac.rst : "Permission is which ROLE can do OPERATION with OBJECT"
16:14:58 <bknudson> I don't think oslo.policy should be an oslo project and belongs in keystone
16:15:15 <bknudson> the operation is like "list users" "boot instance"
16:15:23 <dims> stevemar : bknudson the source of the information in policy.json picked up "dynamically" from another source?
16:15:28 <dims> not policy.json
16:15:36 <stevemar> dims: gotcha
16:15:52 <haypo> bknudson: i'm replying to "what do you think about putting this in keystone-specs ?"
16:16:05 <dims> bknudson : +2A to move it
16:16:35 <stevemar> dims: but like bknudson said, we abandoned it. not enough of a need from operators to have the work done
16:17:05 <haypo> bknudson: you want to move the spec, or the whole oslo.policy, inside keystone? i don't understand :-/
16:17:07 <dims> stevemar : so this seems like a light-weight alternative
16:17:26 <dims> haypo : let's stick to the spec for now :)
16:17:26 <bknudson> haypo: I want to move the whole oslo.policy to keystone
16:17:54 <haypo> bknudson: oh ok. so yes, it makes sense to move the spec
16:17:56 <dims> bknudson : do you envision a rename?
16:18:10 <stevemar> dims: i hope not :P
16:18:12 <bknudson> I don't think renaming the library is worth it
16:18:13 <haypo> maybe we need another to move oslo.policy inside keystone? :)
16:18:26 <haypo> another spec*
16:19:07 <dims> bknudson : +1 to get the ball rolling on a ML thread
16:19:20 <dims> then we can do a governance patch
16:19:37 <dims> haypo : don't think we need another spec :)
16:20:05 <bknudson> #action bknudson to send note to -dev list to request move oslo.policy to keystone
16:20:15 <dims> k. now that spec is off the table for us :)
16:20:24 <dims> #topic OpenStack Spec Review
16:20:24 <dims> #link https://review.openstack.org/#/c/226157/ (Backwards compat for libraries and clients.)
16:20:39 <dims> need some +1's on ^^ per request from TC
16:21:02 <bknudson> +1 from me
16:21:08 <dims> net, net. we can't break any active release...all active releases may use newest oslo libs
16:21:16 <dims> s/release/releases/
16:21:37 <bknudson> we already broke that since we dropped 2.6 support
16:21:40 <dims> we have to figure out the test matrices to help us figure out
16:21:50 <dims> bknudson : that spec is not in effect yet :)
16:22:09 <bknudson> we should make sure to drop support for stuff before the spec gets merged
16:22:22 <dims> bknudson : LOL as long you don't break CI jobs
16:22:38 <dims> then folks would spot it :)
16:23:08 <dims> #topic Open discussion
16:23:41 <lxsli> I'd like to discuss https://review.openstack.org/#/c/253125
16:23:42 <johnsom> I will not be at these meetings until the 4th
16:23:59 <dims> johnsom ack thanks for the heads up
16:24:01 <amrith> ./
16:24:09 <lxsli> harlowja left a comment, I've requested a couple of times in channel to discuss it but not been able to raise anyone
16:24:17 <amrith> I'd asked a questions some days agon on the channel, I'd like to ask here
16:24:24 <amrith> dims was out when I asked ...
16:24:32 <amrith> about strutils.mask_password()
16:24:43 <amrith> dims, ok to ask now?
16:25:04 <dims> harlowja : TZ issues i think, will review it
16:25:16 <lxsli> dims: thanks!
16:25:19 <dims> amrith : shoot
16:25:22 <amrith> thx
16:25:29 <amrith> the issue is with mask_password()
16:25:36 <amrith> currently it is setup to mask a string
16:25:43 <amrith> I'd like to extend the same capability to a dictionary
16:25:54 <amrith> where the keys are in the 'list' that mask_password() uses
16:26:03 <amrith> the list of keys is the same.
16:26:13 <amrith> and I'm wondering whether I can add it to mask_password()
16:26:29 <haypo> amrith: accept dict as input type? why not using a dict comprehension for example?
16:26:34 <amrith> or whether it is not a 'strutils' thing.
16:26:45 <amrith> yes, I want to mask passwords in a dictionary
16:26:59 <haypo> amrith: i don't think that it's worth to make the function more complex
16:27:03 <amrith> such as { "password": "u812hhx", ... }
16:27:09 <haypo> amrith: you should write your own helper in your application
16:27:11 <amrith> I would like to add mask_dict_password()
16:27:18 <amrith> and put it in strutils
16:27:24 <haypo> i prefer to keep oslo.utils simple
16:27:53 <amrith> one second,  I have a request for a plan (b)
16:28:20 <dims> amrith : if we see more projects doing that then may be we can consider it. haypo's point seems valid to me
16:28:28 <dims> ack
16:28:50 <amrith> may I change _SANITIZE_KEYS to SANITIZE_KEYS
16:29:00 <amrith> making it explicit that other modules may use it
16:29:05 <amrith> and add a comment there.
16:29:08 <haypo> amrith: dhellmann was opposed to that
16:29:12 <amrith> then I'll write my helper routine.
16:29:22 <amrith> haypo, sorry didn't see dhellmann's reply
16:29:24 <amrith> apologies
16:29:33 <amrith> then what do y'all suggest?
16:29:34 <haypo> amrith: dict((mask_password(key), value) for key, value in dict.iteritems()) doesn't fit your use case?
16:29:40 <haypo> amrith: it's just one line, no?
16:30:11 <haypo> "then what do y'all suggest?" again, develop such helper in your application
16:30:37 <amrith> haypo, I'm trying to understand how this would work
16:30:54 <amrith> I'll think about your suggestion (1 line) and get back to you
16:31:03 <amrith> thx
16:31:05 <dims> haypo : guessing you need to mask the value and not the key
16:31:06 <amrith> dims, good for now
16:31:08 <haypo> amrith: i'm not sure that i understood your use case
16:31:15 <haypo> dims: ah
16:31:19 <amrith> dims, yes
16:31:31 <haypo> in this case, you cannot use mask_password() in its current shape
16:31:34 <amrith> if the dictionary is as I said earlier  { "password": "u812hhx", ... }
16:31:40 <haypo> amrith: open a review for that and explain your use case
16:31:43 <amrith> I want to mask the "u812hhx",
16:31:52 <amrith> with "****"
16:32:01 <amrith> I don't think the 1 line proposed would work
16:32:22 <amrith> haypo, that's the use-case
16:32:24 <amrith> 1 line above
16:32:33 <amrith> given a dict like { "password": "u812hhx", ... }
16:32:45 <amrith> mask the "u812hhx" and replace with "***"
16:32:50 <haypo> amrith: dhellmann was opposed to allow applications to pass new keys to hide to mask_password()
16:32:55 <amrith> where "password" is any one of the values in _SANITIZE_KEYS
16:32:59 <haypo> amrith: it's different from getting the list of keys
16:33:07 <amrith> I don't want to pass new keys to mask_password()
16:33:15 <amrith> I want to write a helper function that uses _SANITIZE_KEYS
16:33:17 <haypo> amrith: but maybe it's worth to add a new function
16:33:23 <amrith> and the leading "_" implies private
16:33:33 <amrith> I would be fine changing _SANITIZE_KEYS to SANITIZE_KEYS
16:33:38 <amrith> and importing it in my helper
16:33:44 <amrith> and implementing the logic for dictionaries
16:33:53 <amrith> all I want is the change to the variable name
16:33:55 <amrith> in strutils.py
16:33:57 <haypo> don't use _SANITIZE_KEYS outside strutils.py
16:34:01 <amrith> from _SANITIZE_KEYS to SANITIZE_KEYS
16:34:04 <amrith> haypo, you don't
16:34:10 <amrith> my helper function would.
16:34:17 <dims> amrith : which review #?
16:34:22 <haypo> amrith: i changed my mind. propose a change to add a new function to strutils
16:34:24 <amrith> dims, don't have one yet.
16:34:33 <amrith> haypo, I will do that and submit a review
16:34:39 <amrith> that may make it more concrete
16:34:46 <amrith> as an example of the intended use-case.
16:34:48 <haypo> amrith: ok. add me (victor stinner) in the reviewers
16:34:50 <dims> k lets start with a new function for dict with a concrete test
16:34:59 <amrith> haypo, dims understood.
16:35:00 <amrith> thanks
16:35:02 <amrith> I will do that
16:35:17 <dims> thanks
16:35:21 <dims> johnsom lxsli bknudson gcb sileht rbradfor kgiusti haypo ozamiatin - anything else?
16:35:22 <haypo> lxsli: sorry i'm not a big fan of oslo.config, so i'm not really excited by extended it (so i didn't review your change)
16:35:31 <haypo> dims: nope
16:35:33 <kgiusti> nope
16:35:35 <gcb> In last meeting , we talked  how to  clean up  bugs with wrong status, I created an etherpad: https://etherpad.openstack.org/p/oslo_bug_track
16:35:35 <bknudson> nothing for me
16:35:57 <stpierre> i'd like comments on the approach in https://review.openstack.org/#/c/256584/, if anyone can give me some direction. if it looks like the right way to tackle the issue, i've got some paperwork to do before it can be merged
16:36:25 <lxsli> haypo: that's OK, it's harlowja torpedoing it and running away I mind :)
16:36:36 <dims> stpierre : ack will add it to review queue
16:36:38 <bknudson> what's wrong with the current timestamps?
16:36:40 <stpierre> tyvm
16:37:04 <dims> lxsli : LOL, poor guy, does so much and you are accusing him :)
16:37:44 <johnsom> Nothing here
16:37:52 <lxsli> dims: haha not sharpening my daggers just yet :)
16:37:52 <dims> thanks everyone
16:38:26 <dims> special bye from Kharkiv, talk to you all from Boston next week
16:38:42 <dims> #endmeeting