18:02:38 <dolphm> #startmeeting keystone 18:02:38 <openstack> Meeting started Tue Aug 12 18:02:38 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:41 <openstack> The meeting name has been set to 'keystone' 18:02:46 <dolphm> real quick... 18:02:53 <dolphm> #topic Feature Proposal Freeze: August 21st 18:02:56 <dolphm> that's next week 18:03:23 <dolphm> and it means your blueprints need to be feature complete, stable and in review by that day, else be bumped to kilo 18:03:38 <dolphm> if you don't think something is going to make it, give me a heads up ASAP 18:03:59 <dolphm> we're definitely talking about the blocked ones later on the agenda 18:04:15 <dolphm> so that is all, ping me later if you have questions :) 18:04:17 <gyee> dolphm, both spec and impl needs to be up there by 8/21? 18:04:30 <gyee> or just bp and spec 18:04:48 <dolphm> gyee: according to the rest of the community, your spec should have landed weeks ago to be considered for juno 18:05:18 <dolphm> gyee: i did a poor job of communicating that here, so i'm not considering that to be a strict rule 18:05:23 <dolphm> if something looks stable, let's consider it 18:05:26 <dolphm> #topic Cleanup / Abandonment of WIP and Lingering reviews in Keystone repositories 18:05:28 <ayoung> ++ 18:05:38 <lbragstad> will we be following that for Kilo? 18:05:44 <dolphm> we have a lot of old reviews that need to be pruned 18:05:49 <dolphm> lbragstad: likely, yes 18:05:56 <dolphm> lbragstad: the earlier specs land the better 18:06:04 <lbragstad> ok, cool 18:06:24 <dolphm> on stale reviews: cores, feel free to abandon things that look like they aren't going to land. be sure to include an explanation 18:06:38 <dolphm> abandoned reviews can be re-opened by the author, so it's not like a permament -2 or anything 18:07:34 <dolphm> at the very least, if something is miserably failing gate jobs and needs some love, leave it as WIP until someone can tackle it 18:07:47 <dolphm> morganfainberg: anything else to add or are you afk? 18:07:54 <ayoung> I'll probably do that with most of mine, and get people to focus only on the ones that are high priority 18:08:05 * ayoung the worst offender for malingering reviews 18:08:13 <dstanek> ayoung: i was thinking the same thing 18:08:17 <dstanek> for mine i mean 18:08:27 <ayoung> You meant for both. 18:08:33 <dstanek> sure, ok 18:08:43 <dolphm> ayoung: i'm far worse on allowing my reviews to stagnate! 18:08:49 <gyee> ya'll get paid on number of reviews? :) 18:09:18 <dstanek> gyee: are you offereing? 18:09:19 * gyee hides 18:09:23 <dolphm> dstanek: ++ 18:09:33 <dstanek> i just fix stuff as i see it in other people's reviews 18:09:39 <dolphm> dstanek: ++ 18:09:41 <dstanek> or when poking around 18:09:57 <dolphm> renaming this on the agenda... 18:10:00 <dolphm> #topic Last specs for Juno 18:10:10 <dolphm> auth data https://review.openstack.org/#/c/107325/ 18:10:21 <dolphm> unscoped catalog https://review.openstack.org/#/c/107333/ 18:10:39 <jamielennox> yep, so hopefully everyone has seen this, we talked about it a few weeks ago 18:10:45 <dolphm> gyee: did you have one for consideration? (that's nearly implemented?:) 18:11:03 <gyee> dolphm, the x.509 auth depends on generic mapping 18:11:09 <jamielennox> need to get some actual votes on it though if its going to go through 18:11:13 <gyee> I am working with Kristy on this to get the generic mapping working first 18:11:15 <morganfainberg> dolphm, o/ here now 18:11:32 <marekd> gyee: ++ cool 18:11:53 <dolphm> gyee: ? https://blueprints.launchpad.net/keystone/+spec/generic-mapping-federation 18:11:54 <morganfainberg> dolphm, but don't have anything to add to your comments 18:12:03 <dolphm> gyee: whats your bp name, i'll link them 18:12:43 <gyee> dolphm, https://review.openstack.org/#/c/105913/5/specs/juno/x509-ssl-client-cert-authn.rst 18:12:47 <dolphm> #link https://review.openstack.org/#/c/107325/ auth data spec 18:12:55 <dolphm> #link https://review.openstack.org/#/c/107333/ unscoped catalog spec 18:12:58 <gyee> https://blueprints.launchpad.net/keystone/+spec/x509-ssl-client-cert 18:12:58 <gyee> -authn 18:13:11 <gyee> ++ for auth data spec 18:13:11 <bknudson> is https://review.openstack.org/#/c/107325/6/specs/juno/auth-specific-data.rst proposing get rid of /v3/catalog? 18:13:24 <gyee> no sure about the unscoped catalog one though 18:13:41 <dolphm> gyee: is there an implementation for the x509 spec somewhere? 18:14:23 <gyee> dolphm, no, there's an implemented based on auth plugin which I abandon https://review.openstack.org/#/c/103736/ 18:14:41 <gyee> but I don't have one based on generic map yet 18:14:50 <dolphm> gyee: are we likely to see one before next week? 18:15:14 <grantbow> interesting 18:15:16 <dolphm> gyee: if not, we should plan this for kilo now 18:15:30 <gyee> dolphm, lets do it for Kilo to be safe 18:15:38 <gyee> I need to get the generic map working 18:15:45 <gyee> right now its not truly "generic" 18:15:50 <dolphm> gyee: awesome, i'd like some more focus there :) 18:16:25 <gyee> mapping is only capable of mapping to user_id and group_id right now from what I can tell 18:16:27 <dolphm> stevemar's not here, but open id connect support is in the same boat. blocked by generic mapping 18:16:38 <dolphm> gyee: that's true (a list of groups) 18:16:39 <gyee> I need to get it to a point where we can map one set to another set of attributes 18:17:03 <marekd> gyee: i think generic mapping/reeingeneered federation patch will also be posponed for K ? 18:17:09 <marekd> dolphm: ^^ 18:17:22 <dolphm> marekd: should it be postponed? 18:17:28 <gyee> marekd, we need it to be truly generic 18:17:41 <marekd> dolphm: it's still marked as WIP. 18:17:52 <dolphm> marekd: correct; do you think it needs more time? 18:18:10 <dolphm> i don't know how far the implementation is behind the spec 18:18:59 <marekd> dolphm: i posted my comments a long time ago, and since then I haven't heard anything. gyee says he works with Kristy on that so he can answer whether it's far beyond the spec but AFAIR it needs more time. 18:19:17 <dolphm> i'm going to bump all 3 to 'next' (kilo) for now, and if something changes this week, we can re-evaluate 18:19:27 <marekd> dolphm: great! 18:19:53 <gyee> dolphm, ++ 18:20:02 <dolphm> jamielennox: my impression of auth data and the unscoped catalog is that they can be ready for code review this week if the specs are approved - is that true? 18:20:04 <gyee> since they are all related 18:20:11 <marekd> yeah 18:20:29 <jamielennox> dolphm: i have a WIP for unscoped catalog 18:20:41 <jamielennox> dolphm: auth data should be fairly trivial but i haven't done it 18:20:59 <jamielennox> you had a patch to move /catalog to /auth/catalog from memory 18:21:07 <dolphm> that's still up, somewhere 18:21:40 <stevemar> o/ 18:22:00 <jamielennox> dolphm: so yes, if we approve them i can have code ready in a day or two 18:22:00 <dolphm> stevemar: fyi, bumping openid connect to kilo unless mapping gets some traction this week 18:22:07 <dolphm> generic-mapping 18:22:19 <dolphm> jamielennox: ack 18:22:25 <stevemar> dolphm, ok, did Henry give his opinion on the matter? 18:22:31 <topol> dolphm, what is the Aug 21 deadline again? blueprints or code must be under review? 18:22:35 <dolphm> stevemar: unavailable 18:22:41 <marekd> topol: code 18:22:46 <stevemar> topol, the latter 18:22:52 <gyee> topol, the whole shebang 18:22:53 <dolphm> topol: stable code in review 18:22:55 <jamielennox> bnemec: sorry just saw comment from further back - it's proposing to move it to /auth/catalog not get rid of it 18:22:57 <ayoung> there are 3 reasons to have the unscoped catalog, BTW: list projcts, list domains, exchage the unscoped token for a token 18:23:07 <jamielennox> oops bknudson ^ was for you 18:23:20 <bknudson> jamielennox: ok. 18:24:00 <bknudson> was just hoping that /v3/catalog could be made consistent with this 18:24:19 <dolphm> bknudson: it would be 18:24:28 <gyee> catalog is optional anyway so I can the base auth plugin can handle that logic 18:24:43 <gyee> if catalog is absent, try to fetch it via the catalog api 18:25:02 <bknudson> gyee: that's going to be /v3/auth/catalog and not /v3/catalog 18:25:20 <dolphm> assuming jamielennox's auth-data spec is approved 18:25:35 <bknudson> just write your code to use JSON Home to find the resource and you won't have to worry about it 18:25:57 <dolphm> bknudson: =) 18:26:18 <gyee> I am fine either way, just a matter of consistency 18:26:42 <gyee> if everybody is going with JSON home, why not 18:27:04 <bknudson> In K somebody can work on client support. 18:27:04 <dolphm> #topic Keystone Weekly Bug Report 18:27:05 <dolphm> lbragstad: o/ 18:27:07 <dolphm> this is new :) 18:27:19 <lbragstad> http://pasteraw.com/b0r3xfk41debm0tdjwcewtmf9k2lf0f 18:27:36 <lbragstad> so, just wanting to do a weekly bug round up 18:28:01 <lbragstad> just a quick 30 second "here are all the bugs that were opened against us in the last 7 days and their status" 18:28:22 <stevemar> lbragstad, neat, thanks for this, helps for folks like me who don't look at launchpad often enough 18:28:29 <bknudson> "ldap binary fields fail when code try to convert to utf8" is interesting... I thought we fixed it 18:28:44 <lbragstad> I can do this for keystone, keystonemiddleware, and python-keystoneclient 18:28:52 <bknudson> but then it also shows that we're using LDAP inefficiently and fetching more attrs than we need to 18:28:52 <morganfainberg> lbragstad, that would be awesome 18:28:55 <dolphm> lbragstad: for future reference, you could use the wonderful launchpad api to query this stuff 18:29:06 <lbragstad> dolphm 18:29:10 <lbragstad> it's built on the api 18:29:18 <marekd> :D 18:29:19 <dolphm> lbragstad: win 18:29:25 <lbragstad> https://github.com/lbragstad/openstack-infra-scripts 18:29:42 <morganfainberg> dolphm, lbragstad, there is also the untriaged bot that triple-o is using, we might be able to use that and report in the channel at X interval what bugs are not looked at 18:29:48 <lbragstad> some minor modifications I did to jogo's bug roundup infra scripts 18:30:29 <lbragstad> hopeing this will help up triage bugs a little faster, not saying it's not fast enough :) 18:30:33 <lbragstad> hoping* 18:30:45 <dolphm> lbragstad: well now you just need a more recent run - everything in the paste is out of date :P 18:31:11 <lbragstad> dolphm: sounds good, I'll run this for keystone, keystonemiddleware, and python-keystoneclient before every meeting and paste the results 18:31:43 <dolphm> lbragstad: and if possible: openstack-api-site for bugs with the identity-api tag 18:31:56 <lbragstad> dolphm: good point, I can built that in 18:31:58 <dolphm> i haven't worked with tags in the api, so i don't know how well that will go 18:32:02 <ayoung> Gotta drop. Back on line in an hour-ish 18:32:09 <dolphm> ayoung: ack 18:32:34 <dolphm> bug love appreciated :) 18:32:50 <dolphm> #topic What is a sane default cache timeout? 18:32:52 <dolphm> dstanek: o/ 18:32:56 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1355919 18:32:57 <uvirtbot> Launchpad bug 1355919 in keystone "By default when caching is enabled, objects will be cached forever" [Medium,In progress] 18:33:10 <dstanek> so i want to get opinions from the group 18:33:15 <dstanek> what would be a sane setting? 18:33:17 <morganfainberg> dolphm, dstanek, that is the case for assignment, tokens have a default already 18:33:19 <bknudson> forever is an unreasonable default 18:33:31 <morganfainberg> dstanek, dolphm, i think catalog is also affected by that bug (now) 18:33:57 <dolphm> there were a few cache_time options with no default 18:33:58 <dstanek> i chose 10 minutes in my patch, but i would be open to discussion 18:34:18 <dstanek> assignment, catalog and token IIRC 18:34:20 <gyee> dstanek, really? we cache the stuff *forever*?!! 18:34:29 <dolphm> gyee: by default 18:34:36 <gyee> oh my 18:34:37 <dstanek> gyee: there is code that will remove cached entries for some things 18:34:42 <bknudson> I thought we didn't cache anything by default 18:34:42 <morganfainberg> dstanek, fairly certain token has a default 18:34:47 <dstanek> but as far as i can tell it's not everything 18:34:49 <dolphm> dstanek: i was just going to suggest "minutes", so 10 fits my answer :) 18:35:07 <morganfainberg> or it used to 18:35:09 <morganfainberg> vlah 18:35:11 <morganfainberg> blah* 18:35:25 <dstanek> morganfainberg: :-) 18:35:25 <morganfainberg> bknudson, you have to turn on caching, the config is very deployment specific 18:35:54 <morganfainberg> bknudson, but if you do turn it on, it caches forever (well barring an invalidation because of update, keystone is *good* about invalidating when things change) 18:36:00 <dolphm> morganfainberg: typo-correcting your frustration is either coincidental or ironic, i can't remember which 18:36:13 <bknudson> 10 minutes seems reasonable to me. 18:36:14 <morganfainberg> dolphm, both! 18:36:35 <Haneef> morgon: I believe both global cache and token cache is disabled by default 18:36:47 <bknudson> keystone doesn't know about users when you have them in ldap 18:36:59 <dstanek> the review itself it trivial if we agree on 10 minutes - https://review.openstack.org/#/c/113586 18:37:07 <bknudson> so if you enable caching for users then it won't notice a change for the cache time? 18:37:16 <bknudson> (read-only ldap) 18:37:19 <gyee> bknudson, its a feature to cache LDAP lookups 18:37:20 <dolphm> and it's dependent on an even more trivial review: https://review.openstack.org/#/c/113585/ 18:37:22 <gyee> performance gain 18:37:30 <morganfainberg> bknudson, 10 mins works for me, may i suggest we do the same thing we do for the "enable" have a global default that can be overridded by the individual subsystem 18:37:44 <topol> 10 mins sounds good 18:37:48 <gyee> right now we do 3 LDAP roundtrips with every auth 18:37:54 <dstanek> morganfainberg: that would be easy enough 18:38:05 <dolphm> gyee: for extra security 18:38:14 <gyee> huh? 18:38:16 <bknudson> 3-factor authentication 18:38:20 <jamielennox> dolphm: ++ 18:38:20 <morganfainberg> dstanek, yah, and it means as we add more caching, people don't need to remember adding the default 18:38:27 <gyee> heh, I get the joke now 18:38:31 <dolphm> we need to have the openstack code proposal bot give us sample config updates daily <-- someone #action themselves thx 18:38:34 <morganfainberg> dstanek, it would just be changing the lambdas 18:38:43 <morganfainberg> dolphm, infra nixed that 18:38:55 <morganfainberg> dolphm, when i proposed it -- or is that a joke 18:39:18 <dolphm> morganfainberg: i'm serious - why was it nixed? 18:39:41 <morganfainberg> dolphm, because it "wasn't what they wanted" they want sample configs to be generated on release. - it was a lot of back and forth. 18:39:56 <morganfainberg> dolphm, i'll revisit it, but it was pretty resounding "no, not the right answer" 18:40:04 <bknudson> we never used the lockutils stuff... it was just pulled in via oslo-incubator. 18:40:28 <gyee> can't we automate the sample conf generation stuff in Jenkins? 18:40:34 <gyee> like some sort of hook? 18:40:43 <bknudson> nova doesn't have a sample config in git repo 18:40:45 <dolphm> generated on release is dumb for the sake of docs 18:40:47 <morganfainberg> gyee, no, automation is not allowed to commit to a repo. 18:40:55 <dstanek> i have a test i can commit that will break if the config isn't up to date - that may help a little 18:41:07 <gyee> morganfainberg, seem dump to having to manually generate it every time 18:41:12 <gyee> dumb 18:41:16 <morganfainberg> dstanek, i can add a simple non-voting job that tells us if it is out of date 18:41:22 <bknudson> dstanek: we tried the test breaking on sample config and it was a disaster 18:41:24 <morganfainberg> dstanek, infra wasn't opposed to that really 18:41:44 <morganfainberg> but we cant *gate* on it being up-to-date 18:41:49 <stevemar> dolphm, fyi updated meeting agenda 18:42:02 <dolphm> morganfainberg: that would be better than where we're at 18:42:05 <bknudson> http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/README-nova.conf.txt 18:42:06 <dstanek> bknudson: i didn't realize we had a test. i remember the issues generating the config 18:42:10 <morganfainberg> i'll revisit proposal bot with them first. 18:42:30 <dolphm> ack 18:42:36 <bknudson> we could just go with Nova's approach and not have a sample config in git 18:42:47 <dstanek> anyway...i'll create a patch to have a global default cache_time 18:42:50 <morganfainberg> bknudson, that is likely what we'll be told to do. 18:42:59 <dolphm> bknudson: i think that's a terrible approach from the perspective of docs and new user experience. it's an unnecessary hurdle 18:43:08 <topol> dolphm +++ 18:43:08 <dolphm> morganfainberg: and i'm happy to argue against it 18:43:14 <bknudson> I find the sample config in git handy 18:43:23 <morganfainberg> dolphm, ++ i'll poke ya when we get there (later today) 18:43:26 <dolphm> bknudson: i link people to it every couple days, for sure 18:43:31 <dolphm> morganfainberg: thanks 18:43:35 <dolphm> #topic Attempt to assign a role to a non existent user should fail 18:43:37 <morganfainberg> dolphm, if we go non-voting job, it'll be a check-only job 18:43:45 <morganfainberg> (not run at gate time) 18:43:46 <dstanek> bknudson: ++ i point people to it quite a bit 18:43:50 <dolphm> i just wanted to bring this up again, because i'm the sole voice on this, along with everyone filing bugs 18:43:55 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1355655 18:43:56 <uvirtbot> Launchpad bug 1355655 in keystone "Attempt to assign a role to a non existent user should fail" [Undecided,Opinion] 18:44:14 <morganfainberg> i think the reason for that was federated users. 18:44:15 <dolphm> i left it as opinion, but i really think we should 404 for invalid data. users will forever be confused 18:44:27 <dolphm> morganfainberg: correct 18:44:39 <bknudson> there have been arguments that we shouldn't 404 for this. 18:45:00 <bknudson> for the case where you're using LDAP and for some reason the user hasn't been added yet 18:45:23 <bknudson> We should get a use case that says why this must fail 18:45:36 <morganfainberg> bknudson, i'm not sure that is really a valid case. esp. with the user_id mapping stuff 18:45:39 <bknudson> the complaint here is just that tempest fails. 18:46:00 <dstanek> how do you give roles to users in federation anyway? i thought they were always mapped to a group 18:46:05 <bknudson> what's the real issue? 18:46:07 <morganfainberg> dstanek, they are. 18:46:16 <dolphm> bknudson: user experience is the use case 18:46:30 <dolphm> the one that i see, anyway 18:46:31 <bknudson> ok, but this bug report isn't about UX 18:46:40 <dolphm> bknudson: agree/understood 18:47:03 <dolphm> i'm just going to put it on the agenda everytime someone complains :) 18:47:15 <dolphm> #topic notifications for role assignments 18:47:17 <dolphm> stevemar: o/ 18:47:21 <dstanek> the behaviour, i think, is not intutitive and will keep confusing people 18:47:23 <dolphm> #link https://review.openstack.org/#/c/112204/ 18:47:24 <stevemar> dolphm, hey 18:47:27 <morganfainberg> i'm fine with 404ing in this case now since the user_id mapping happened 18:47:29 <stevemar> thx 18:47:29 <dolphm> dstanek: ++ 18:47:35 <dolphm> morganfainberg: ++ 18:47:37 <bknudson> dstanek: test writers? 18:47:40 <morganfainberg> dolphm, it changes the landscape some. 18:47:52 <stevemar> so, i tossed up some code for emitting notifications for role_assignments 18:47:56 <stevemar> https://review.openstack.org/#/c/112204/ 18:48:01 <stevemar> i'd appreciate some reviews :) 18:48:13 <stevemar> and for dolphm - do you want a spec/bp/bug for this? 18:48:29 <dolphm> stevemar: no spec for weird public api notification format? :P 18:48:58 <stevemar> dolphm, it's not all that different 18:49:01 <dolphm> i think notifications are a public api that is severely undocumented in openstack, i just want to make sure we're not contributing to that mess 18:49:09 <gyee> stevemar, I thought you should get a purple heart for modifying the notification payload :) 18:49:18 <stevemar> gyee, hooray 18:49:23 <dolphm> stevemar: weird = arbitrary and clients needs to understand it and for it to be stable 18:49:28 <stevemar> yeah it was a mess earlier 18:49:47 <stevemar> dolphm, i agree the docs suck atm 18:49:57 <stevemar> dolphm, i was just going to add a small bit of info 18:50:07 <stevemar> dolphm, but if you want me to overhaul them, i cans 18:50:28 <dolphm> stevemar: as long as we're documenting what we're doing and holding ourselves to it? 18:50:34 <gyee> stevemar, but why stop at role assignment? it should be for any sort of updates 18:50:56 <lbragstad> we'll need a new notifications wrapper class for each kind of update? 18:50:59 <jamielennox> stevemar: i know there was compaints from jogo and nova that these notifications conform to a stable api 18:51:03 <dolphm> gyee: role assigment is just an odd one, because there's not a resource entity in the picture 18:51:06 <stevemar> gyee, role assignments in particular were weird, cause it has multiple entities being affected 18:51:11 <gyee> lbragstad, yes, right now we can't tell what's being updated 18:51:14 <stevemar> yeah ^ 18:51:26 <gyee> only the resource ID is not good enough 18:51:42 <stevemar> gyee, yeah, cause you don't know what the role is being assigned to, and on what project 18:51:49 <dolphm> you could almost emit 3 notifications :-/ 18:51:51 <stevemar> (or domain) 18:51:58 <stevemar> dolphm, nope! 18:52:06 <dolphm> but i'd rather bring it back to the use case - who's going to consume the notifications and what do they care about? 18:52:25 <gyee> say PATCH /users/user_id, how can we tell which fields are being updated? 18:52:47 <dolphm> gyee: why do you need to know which fields were updated? 18:53:00 <Haneef> Which openstack service care about role assigments? Are we concerned about delete role_assignment 18:53:00 <dolphm> gyee: don't you just care about what the new entity looks like? 18:53:04 <stevemar> dolphm, for auditing i would think. it's one of those things an admin should be able to watch with ceilometer 18:53:21 <dolphm> Haneef: delete assignment is sort of handled by token revocation events 18:53:36 <dolphm> Haneef: but for auditing, crud all the assignments 18:54:27 <gyee> dolphm, yes, even as simply as changing email cause a bunch of changes behind the scene 18:54:53 <dolphm> stevemar: so let's write a short spec on the perspective that an auditor cares about? 18:55:07 <stevemar> dolphm, alright 18:55:37 <stevemar> dolphm et all, i'd still appreciate code reviews! :) 18:56:01 <dolphm> #topic open discussion 18:56:06 <dolphm> YAY 5 MINUTES LEFT 18:57:01 <bknudson> I proposed a minor change to JSON Home spec based on Anne Gentle's feedback: https://review.openstack.org/#/c/113413/ 18:57:32 <bknudson> this is the location she suggested for the relationship link so that we could potentially publish something there 18:57:55 <dolphm> bknudson: ++ 18:58:03 <ajayaa> dolphm, What do I need to pay if I changed status of a bug by mistake? 18:58:06 <bknudson> it's not required by json home to have the links lead anywhere, but it's something we could do eventually 18:58:15 <dolphm> ' 18:58:27 <topol> bknudson thats a cool option to have 18:58:43 * dolphm liquid-keyboard interaction incident 18:58:56 <topol> dolphm any sparks??? 18:59:05 <bknudson> so now I'm also working on refactoring the JSON Home code so that it's easy to change the relationship link 18:59:10 <bknudson> removing duplication 18:59:19 <dolphm> topol: this isn't a thinkpad 18:59:43 <stevemar> dolphm, thinkpads are bullet and water proof 19:00:27 <dstanek> stevemar: that's because it's a brick 19:00:39 <bknudson> I'm guessing there won't be further oslo libs published in J 19:00:48 <bknudson> so the oslo.utils one is probably the last 19:01:10 <dolphm> oop, time 19:01:11 <dolphm> #endmeeting