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