18:01:20 <stevemar> #startmeeting keystone
18:01:21 <openstack> Meeting started Tue Dec 15 18:01:20 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:24 <openstack> The meeting name has been set to 'keystone'
18:01:30 <stevemar> that's for joining everyone!
18:01:46 <stevemar> meeting agenda is in it's usual spot: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:17 <henrynash> squeaks in late
18:02:40 <stevemar> before we go down the agenda, i wanted to say that i intend to have a meeting next week. but i'll see how it goes, if i cancel, i'll send a notification on the mailing list
18:03:00 <bknudson> I'll be around next week
18:03:19 <bknudson> festivus isn't until wed
18:03:23 <stevemar> bknudson: you and i can chat during the meeting!
18:03:52 <stevemar> basically, just keep an eye on the mailing list for meeting cancelations
18:03:56 <stevemar> #topic Move oslo.policy to keystone
18:04:01 <stevemar> bknudson: the floor is yours
18:04:20 <bknudson> so I wonder if oslo.polcy shouldn't be a keystone project
18:04:36 <bknudson> since any time there's a change to it the oslo people are going to ask us to check it out anyways
18:05:05 <bknudson> and I'm not sure that we would want oslo reviewers to approve specs for oslo.policy without us
18:05:28 <stevemar> currently it's in the Oslo umbrella, not keystone http://governance.openstack.org/reference/projects/keystone.html vs http://governance.openstack.org/reference/projects/oslo.html
18:06:04 <gyee> what do you keystone project? like move the code over?
18:06:07 <stevemar> so, keystone core folks - what do you think? will you have the extra bandwidth to review oslo.policy as well?
18:06:14 <davechen> if this should be in keystone, we shouldn't let it go at the begining.
18:06:14 <bknudson> so, if there aren't any objections here I'll post to the -dev mailing list
18:06:36 <gyee> what does it mean a keystone project?
18:06:38 <stevemar> gyee: no, the code wouldn't move, nothing would be renamed
18:06:40 <dstanek> bknudson: no objection from me
18:06:52 <bknudson> it means that when specs are proposed they're proposed to keystone rather than oslo
18:06:53 <stevemar> gyee: it means we're responsible for reviewing code and specs
18:06:55 <samueldmq> what's the purpose of oslo? is it just to be an umbrella to any common code to 2+ openstck proejcts
18:07:16 <gyee> stevemar, k, no objection here
18:07:25 <jamielennox> came late, but i though oslo.policy was already under keystone
18:07:32 <henrynash> bknudson: none here, neither, guv
18:07:32 <stevemar> jamielennox: negatory
18:07:54 <stevemar> samueldmq: correct, but this is about who reviews bugs/specs/patches
18:07:59 <jamielennox> ok, it should be
18:08:04 <stevemar> currently it's a bit of a mix
18:08:25 <samueldmq> stevemar: ah so I am 100% for making it under keystone (for governance purposes, thus reviews, etc)
18:08:30 <stevemar> dolphm: ?
18:08:39 <stevemar> light crowd today
18:09:04 <stevemar> bknudson: seems like there are no objections, please post to ML and create a governance patch
18:09:05 <bknudson> I'll post to the mailing list so they'll have a chance to oppose
18:09:13 <stevemar> ++
18:09:13 <gyee> too many holidays to celebrate around this time
18:09:17 <lhcheng> thought it was already under keystone, makes sense to move it.
18:09:49 <stevemar> alright
18:09:51 <dolphm> (no objections here)
18:09:55 <stevemar> next topic
18:09:58 <stevemar> #topic Deprecate auth plugins and session code in keystoneclient
18:10:14 <bknudson> if there's an alternative that works then let's deprecate
18:10:20 <stevemar> ksa has been out for a while now, what are folks' views?
18:10:39 <dolphm> bknudson++
18:10:40 <stevemar> bknudson: just making sure folks think ksa is fully baked enough
18:10:41 <gyee> do it! eliminate confusion if nothing else
18:10:56 <jamielennox> i think it's baked, lots of things have started to use it
18:10:57 <raildo> gyee: ++
18:11:03 <stevemar> thats some enthusiastic support
18:11:04 <gyee> last I checked the code were insync
18:11:09 <gyee> weren't
18:11:16 <stevemar> any volunteers to do the deprecations?
18:11:19 <jamielennox> i'll start putting up deprecation warnings if everyone is ok and do a transition doc in ksa
18:11:42 <davechen> so jamielennox is the volunteer :)
18:11:44 <stevemar> jamielennox: that would be sauce that is awesome, awesomesauce if you will
18:11:59 <gyee> jamielennox, I don't think the code are insync
18:12:10 <jamielennox> gyee: what's missing?
18:12:31 <gyee> I found there was a patch missing in fixtures a couple of days back
18:12:46 <gyee> there may be more
18:13:12 <jamielennox> gyee: i'd be interested to know what it was, at this point there is defintely stuff available in ksa that is not in ksc
18:13:37 <jamielennox> that should be really easy to port as nothing major changed in that code
18:14:18 <stevemar> on a minor side note - we also stripped middleware out of keystoneclient :)
18:14:22 <gyee> jamielennox, k, unless you want to do a code audit, we'll sync one patch at a time
18:14:33 <stevemar> so next release of keystoneclient won't have middleware in it at all
18:14:40 <bknudson> when's the next release?
18:14:44 <stevemar> bknudson: TBD
18:15:27 <stevemar> i did a search with hound (http://codesearch.openstack.org/) to find projects that are still affected, there were 5 or so, but minor ones that haven't had a successful build in months :(
18:15:39 <jamielennox> gyee: for anyone that's migrating we can also just wait to see them file bugs, we won't remove ksc support that fast the can't just keep using it
18:15:54 <jamielennox> codesearch...
18:15:56 <stevemar> try searching for: "from keystoneclient.middleware import auth_token"
18:16:09 <gyee> jamielennox, ++
18:16:45 <bknudson> when we deprecate things do we need to go through all the other projects and change their code?
18:16:58 <stevemar> bknudson: no, hopefully not
18:17:03 <bknudson> not sure how we're supposed to ever remove stuff if other projects aren't updating based on deprecation warnings
18:17:22 <stevemar> bknudson: i did this because there were only 4 or so
18:17:37 <stevemar> TBH, i'd be surprised if the patches ever merge, these projects seem dead
18:17:43 <dstanek> it would be nice if the gate failed on deprecation warnings after some amount of time after they started appearing
18:17:57 <samueldmq> dstanek: ++
18:18:06 <bknudson> there's also a pendingdeprecation warnings
18:18:18 <stevemar> bknudson: but it's definitely not our responsibility
18:18:59 <gyee> stevemar, yeah, we said the same thing about v3 too
18:19:11 <stevemar> #action jamielennox to deprecate all the things in keystoneclient (auth plugins and session code)
18:19:16 <gyee> it wasn't supposed to be our responsibility :)
18:19:57 <stevemar> gyee: apples and oranges, one is a lot of work
18:20:03 <stevemar> anywho, we're going off the rails
18:20:08 <stevemar> next topic
18:20:15 <stevemar> #topic Stable driver interfaces
18:20:37 <stevemar> the stable ABI stuff has started to come up more often in reviews
18:21:00 <dstanek> i'm working on documentation to address the open questions
18:21:06 <stevemar> thanks dstanek
18:21:31 <stevemar> so background... whenever we change a function of a manager class, we need to create a new version of that driver
18:21:32 <dstanek> for example, i'm updating based on the discussions of https://gist.github.com/dstanek/756337141e5e0066ebce
18:21:53 <bknudson> it's when we change the driver interface
18:21:57 <bknudson> not the manager
18:22:10 <stevemar> bknudson: thanks for the clarification
18:22:14 <dstanek> bknudson: right
18:22:15 <stevemar> here's an example: https://review.openstack.org/#/c/247805/
18:23:08 <dstanek> i'm in the middle of creating new versions of *all* the drivers so that i can document the process
18:23:11 <stevemar> and currently theres a stable driver interface for every backend (resource, assignment, federation, credentual)
18:23:28 <stevemar> dstanek: okay, that was my next question
18:23:41 <bknudson> might as well create the new versions because then we can get the testing in place... then revert if there weren't any changes.
18:23:47 <dstanek> the question that keeps coming up is whether or not to *always* create a new version for a release
18:23:54 <stevemar> if someone wanted to go ahead and create a new version for all drivers, right at the beginning of the release
18:24:02 <stevemar> dstanek: i think we should
18:24:14 <gyee> why?
18:24:20 <dstanek> stevemar: i'm doing that now for mitaka base on what i have been directing henrynash to do
18:24:27 <stevemar> gyee: it would be really weird if we release keystone v9 with role driver at v9 and federation at v8
18:24:40 <stevemar> dstanek: fantastic
18:24:42 <dstanek> gyee: so that it's easy to know that if you run mitaka we support v9 and v8
18:24:58 <jamielennox> stevemar: it's only weird because we started at v9
18:25:01 <jamielennox> v8
18:25:08 <dstanek> gyee: not v9/v8 of assignment, v10/v9 or identity, etc.
18:25:09 <samueldmq> I think it would be consistent to have vX drivers for all backends, rather than vX vY vZ in a single release of keystone
18:25:28 <jamielennox> isn't that anti the point of stable interfaces
18:25:38 <jamielennox> if they haven't changed in a release i don't want them to jump version numbers
18:25:44 <henrynash> the flip side is we will be, by definition, causing custom driver writers to update their driver (at laeast to specify a version) every coupld of releases
18:26:15 <samueldmq> henrynash: hmm, good point
18:26:28 <stevemar> i feel like henrynash and jamielennox share a brain
18:26:36 <henrynash> eek
18:26:41 <jamielennox> scary in here
18:26:42 <dstanek> henrynash: my feeling is that it's only once a year
18:26:46 <henrynash> worse here
18:27:08 <henrynash> dtsanek: which is what it would be if we support teh ABI to N-1
18:27:17 <stevemar> i don't know, mixing up version numbers feels silly
18:27:24 <henrynash> (seperate question…should it be N-1 or N-2)
18:27:30 <dstanek> i'm looking at it more move v9 of the keystone drivers, but i can see the other side
18:27:41 <stevemar> but yeah, mostly cause we started at 8 when keystone was at 8
18:27:51 <bknudson> since we'll know if the interface changed or not in the previous release we can support more versions back for a driver
18:27:54 <gyee> it's the version for the driver interface, not a keystone release
18:27:55 <jamielennox> so why didn't we call it v2? there's no need to tie it to keystone major versions
18:28:05 <dstanek> henrynash: in the draft doc i'm saying that we'll support N, support + deprecate N-1 and delete N-2
18:28:14 <topol> o/ just back from my dept holiday lunch....
18:28:26 <dstanek> bknudson: true
18:28:33 <samueldmq> bknudson: good idea
18:28:35 <henrynash> dstanek: and my question is whether that breaks the standard depreaction rules we are signing up to
18:28:52 <stevemar> topol: welcome!
18:29:12 <dstanek> henrynash: don't we deprecated for one whole release and delete in the next?
18:29:31 * topol thanks for not adding the sarcastic  glad you could join us... :-)
18:29:49 <henrynash> i just don’t see why we need to tie the versions together (across idenityt, resource etc.)….why should they not float free
18:30:00 <dstanek> gyee: so you're more for having a mapping in the docs that says what versions are supported for what subsystems?
18:30:02 <bknudson> topol: that's because we don't want coal in the stockings
18:30:36 <dstanek> henrynash: easier to know what versions are supported
18:30:37 <gyee> dstanek, who's using those interfaces? the 3rd party driver providers
18:30:47 <dstanek> gyee: yes and us
18:30:48 <henrynash> dtsanek: that, I grant you
18:31:07 <dstanek> so Mitaka supports Mitaka drivers and Liberty driver
18:31:09 <gyee> dstanek, yes, and what is the version for?
18:31:26 <gyee> indicating compatibility
18:31:32 <jamielennox> we don't need to bump version numbers to handle deprecations, we can still do the standard 2 releases
18:31:54 <jamielennox> anyone who is doing this is looking at the code, not docs, they'll see what is required
18:32:05 * jamielennox is not advocating for no/less docs
18:32:21 <bknudson> we don't document the interface well enough to develop based on the interface anyways
18:32:25 <dstanek> jamielennox: that's what we are hoping to avoid in the future
18:32:32 <dstanek> bknudson: yet...
18:32:39 <bknudson> woah!
18:32:45 <dstanek> i think that is one of the long term goals here
18:32:45 <samueldmq> if nothing changes, make v10 inherit from v9, and keep v9 as default (without deprecating yet) ? so they might want to update it or not ?
18:32:48 <samueldmq> ^
18:33:34 <dstanek> samueldmq: right, that's what i think bknudson was hinting at earlier
18:33:40 <henrynash> samuedlmq: but then you might have 5 versions live until we actually change something
18:34:22 <dstanek> so like i said i'm fine either way. it just seems easier if it was clear what versions were supported
18:34:23 <bknudson> it might become very difficult to maintain the old test codebase, just due to changes in other libraries.
18:34:24 <samueldmq> henrynash: isn't that okay ? one may want to update it or not, that basically means supporting it for longer if it doesnt change
18:34:40 <samueldmq> like bknudson said early (thanks dstanek for the heads up)
18:34:46 <bknudson> we're not really supporting anything longer, it just happens to continue to work.
18:35:08 <samueldmq> bknudson: agreed
18:36:00 <stevemar> we don't have to agree on something now
18:36:09 <stevemar> we can discuss it in dstanek's eventual doc patch
18:36:18 <gyee> sounds good
18:36:22 <dstanek> stevemar: i'll just keep my stuff the way it is
18:36:22 <stevemar> just wanted to bring it to everyone's attention
18:36:23 <bknudson> I vote for adding the new versions now and putting the testing in place.
18:36:27 <henrynash> i guess….so when it did change, as  customer driver writer, I might update form v8 to v12
18:36:42 <bknudson> that way when someone proposes code that breaks the interface we'll know about it
18:36:42 <henrynash> (say)
18:37:00 <bknudson> henrynash: yes, you might go from V8 to V12.
18:37:05 <stevemar> henrynash: sounds right
18:37:10 <samueldmq> bknudson: without deprecating the "old" driver which haven't been effectively updated, right?
18:37:25 <bknudson> we always deprecate the old driver.
18:37:32 <dstanek> bknudson: ++
18:37:43 <henrynash> So I certianly prefer that than forcing custom driver writers to update tehor code for the sake of a version number change
18:38:00 <davechen> so, the question is if i did some change about the driver interface, what should do about the stable interface?
18:38:24 <dstanek> davechen: you mean the N-1 version?
18:38:31 <henrynash> davechen: so dstanek is documenting this...
18:38:32 <bknudson> davechen: you need to update hthe adapter so the old version still works.
18:38:33 <samueldmq> I think not deprecating what haven't changed would be better, because we will have  new version; but not necessarily forcing them to update their drivers for the sake of a version (as henrynash said)
18:38:34 <davechen> dstanek: yes.
18:38:46 <dstanek> davechen: you provide an adapter class https://gist.github.com/dstanek/756337141e5e0066ebce
18:39:10 <bknudson> samueldmq: you might be right. we can think about it some more
18:39:42 <davechen> sound good, will check out the doc.
18:39:43 <dstanek> samueldmq: deprecations won't force and update (single character change in code), but encourage it
18:39:54 <samueldmq> bknudson: cool, so perhaps we can all discuss in dstanek's patch for the docs, as stevemar said
18:40:05 <dstanek> samueldmq: i was hoping to be able to automate this process at the beginning of each cycle
18:40:11 <samueldmq> dstanek: what if the driver remains 2+ releases without an update?
18:40:11 <stevemar> #action dstanek to toss up a doc patch about stable interfaces
18:40:13 <stevemar> dstanek: ++++++++++++++++++++++
18:40:18 <henrynash> davechecn: and here’s an example: https://review.openstack.org/#/c/242513/
18:40:22 <samueldmq> dstanek: they will need to update for the sake of the ersion number
18:40:30 <stevemar> dstanek: i would love that
18:40:44 <dstanek> samueldmq: yep. a side effect of making understanding the version easier
18:40:51 <samueldmq> dstanek: I'd be glad to see that code generation :)
18:40:54 <stevemar> alright, let's give davechen some time
18:40:56 <davechen> henrynash: thanks, i need this example to update my patch.
18:41:08 <dstanek> samueldmq: if you can't s/V9/V10/ in about a year then you have already lost
18:41:19 <stevemar> lol
18:41:29 <stevemar> alright - topic change
18:41:35 <stevemar> #topic Hornor shema validation everywhere
18:41:38 <bknudson> I'm still on windows 95
18:41:43 <stevemar> davechen: go ahead
18:41:45 <stevemar> bknudson: smart move
18:41:45 <davechen> this is the last chance i join in the meeting in san antonio
18:42:05 <davechen> i just want to do something around schema validation.
18:42:12 <samueldmq> dstanek: that's a good point, let's keep that option in mind too
18:42:24 <davechen> basically, it haven't done for all extensions
18:42:45 <davechen> and there was a patch to enable schema valdiation for v2 api
18:42:49 <stevemar> davechen: so v3 core stuff has schema validation
18:42:58 <davechen> is that necessary to do this for v2 api as well?
18:43:09 <stevemar> but v2 APIs and things that were 'extensions' don't
18:43:14 <bknudson> doing input validation is on the IBM secure coding guidelines, so I'd like to see this done.
18:43:16 <davechen> stevemar: yes, but extension is cores right now.
18:43:29 <stevemar> davechen: it's all wishlist items IMO
18:43:32 <bknudson> I don't think we should bother doing it for v2
18:43:35 <stevemar> davechen: i'd be happy to review it
18:43:56 <davechen> okay, what do you folks thinks about v2?
18:44:03 <davechen> why not bknudson?
18:44:04 <dolphm> finishing it for v3 should be first priority
18:44:06 <samueldmq> bknudson: ++ I'd like to see them for extensions (on core now)
18:44:11 <bknudson> we should deprecate v2 and get rid of it
18:44:12 <dstanek> yes, we need to validate all the things!
18:44:17 <davechen> dolphm: ++
18:44:18 <stevemar> davechen: bknudson: if it's not a lot of work to do it for v2, then you can do it. but finishing it for v3 extensions is higher priority
18:44:36 <dstanek> davechen: i say no to v2 since we have said not sure use it because if it's existing security issues
18:44:49 <davechen> if i have bandwidth, i will also pick up something about v2
18:44:51 <dstanek> s/not sure/not to/
18:45:09 <davechen> dstanek: okay.
18:45:31 <davechen> but what's the security issue?
18:45:34 <dolphm> davechen: focus on v3 first; the value will be much longer lived there
18:45:40 <stevemar> dstanek: i'm OK with v2 only because we have a ton of existing bugs about validation, and routinely get them once a month
18:45:41 <davechen> dstanek: ^
18:45:45 <stevemar> dolphm: ++
18:45:49 <dolphm> stevemar: ++
18:45:54 <stevemar> davechen: definitely v3 first :)
18:46:06 <bknudson> the existing v2 validation bugs we just punt on because we're not enhancing v2.
18:46:07 <dstanek> stevemar: is there a timeline for rewriting v2 to actually use v3 under the hood? that would make it a non-issue
18:46:10 <davechen> i think i have enough champions
18:46:32 <stevemar> dstanek: no timeline yet, but since we deprecated v2.0, it should be added to the timeline
18:47:22 <davechen> bknudson: there was a bug here for V2 API
18:47:26 <stevemar> (deprecate v2.0 patch: https://review.openstack.org/#/c/251530/)
18:47:40 <samueldmq> dstanek: stevemar ++ so that means removing all v2 specific manager/backend logic
18:47:43 <dstanek> davechen: one big issue is tokens in urls
18:47:45 <dolphm> PST /v2.0/tokens (auth) would be top priority within the confines of v2
18:48:06 <dolphm> POST*
18:48:07 <stevemar> samueldmq: yep
18:48:12 <samueldmq> nice
18:48:15 <bknudson> validation on POST /v2.0/tokens I'd be happy with
18:48:20 <stevemar> samueldmq: the controller would just point to something in v3
18:48:46 <samueldmq> stevemar: nice, isn't that something easy to do ?
18:48:55 <dstanek> it would be nice if that could then piggy back in the v3 validation
18:48:59 <stevemar> samueldmq: haven't looked into it yet!
18:49:07 <dstanek> samueldmq: i would doubt it
18:49:23 <gyee> dstanek, how, v2 auth payload is different from v3
18:49:29 <stevemar> dstanek: the requests may be a different format though
18:49:37 <stevemar> what gyee said
18:49:39 <dstanek> samueldmq: if it were then we wouldn't have needed different code for the business logic
18:49:43 <davechen> stevemar: so you decide to deprecate v2 api, and the v2 api will gone within 2 releases?
18:49:46 <bknudson> if you get an error back from v3 validation it's going to be confusing if you're using v2.0
18:49:58 <stevemar> dstanek: v2.0 is special and gets 4 releases
18:50:08 <dstanek> davechen: no, much longer
18:50:26 <stevemar> one more topic on the agenda btw
18:50:39 <davechen> yes, it mine
18:50:40 <samueldmq> dstanek: nice, it might be worth it to give it a try
18:50:42 <stevemar> davechen's again
18:50:47 <stevemar> #topic Fully support attributes filtering
18:50:56 <stevemar> davechen: go ahead sir
18:51:07 <davechen> since it might need update stable inteface as you mentioned
18:51:26 <davechen> we need support more attribute filter in keystone.
18:51:45 <dstanek> davechen: yes it will require interface updates
18:51:52 <davechen> we missed some API, and i wanna to fix all these up.
18:51:54 <bknudson> ok, I guess we can't make any improvements anymore due to stable interface.
18:52:27 <gyee> aren't we passing hints into the drivers?
18:52:28 <bknudson> I'm fine with adding more filter options.
18:52:29 <davechen> bknudson: so, stable interface should change
18:52:30 <dstanek> bknudson: are you declaring keystone to be done?
18:52:48 <gyee> don't think hints are versioned
18:52:54 <dstanek> davechen: the currently developed interface should change
18:52:58 <davechen> gyee: yes, we need support more api
18:53:13 <gyee> davechen, more APIs or more hints?
18:53:22 <davechen> more apis, gyee
18:53:34 <dstanek> gyee: not everything takes hints
18:54:03 <dstanek> davechen: is there a question about this?
18:54:06 <davechen> dstanek: we need do this since osc use some of them but it's currently not supported by server
18:54:10 <gyee> I thought all lookup APIs takes hints
18:54:15 <gyee> need to 2x check
18:54:28 <davechen> is there any need for a backlog spec?
18:54:37 <bknudson> this will need a spec change since it changes the REST api
18:54:46 <davechen> dstanek: this is my question acutally.
18:55:02 <dstanek> davechen: yes, what bknudson said
18:55:04 <davechen> bknudson: sure, i will post one
18:55:26 <stevemar> davechen: cool, target the spec to backlog for now
18:55:36 <gyee> so we are talking two different things
18:55:38 <davechen> so, hope we can move forward
18:55:43 <gyee> 1) api support more filtering
18:55:51 <gyee> 2) drivers understand these new filters
18:55:56 <davechen> stevemar: what's the policy for backlog spec?
18:56:12 <samueldmq> davechen: just submit against /backlog in keystone-specs
18:56:16 <dolphm> api docs are the important bit on the -specs side
18:56:16 <davechen> gyee: yes, thanks sir
18:56:41 <davechen> samueldmq: i know that, but we can target in M or defer to next release?
18:56:49 <stevemar> davechen: propose them to backlog first, if you want to re-target for mitaka send a note to the mailing list asking for an exemption, since we're past feature freeze
18:56:52 <dstanek> gyee: yes, the patch does both
18:56:57 <stevemar> err spec freeze
18:57:00 <samueldmq> dolphm: ++ we don't need a full specifitaion about introducing filters (it's trivial)
18:57:11 <davechen> stevvemar: this is what i am worried.
18:57:13 <gyee> dstanek, sure, will review the spec
18:57:16 <davechen> sound good.
18:57:41 <davechen> who is stevvemar? :)
18:58:10 <stevemar> davechen: if anyone wants something to land in mitaka, that is not already here: http://specs.openstack.org/openstack/keystone-specs/#identity-program-specifications they need to send a note to the mailing list asking for spec exemption and find 2 champions willing to review
18:58:27 <stevemar> anywho
18:58:31 <stevemar> thanks for coming everyone
18:58:36 <henrynash> davechen: stevvemar is the dark side version of our esteemed leader
18:58:44 <davechen> stevemar: got it, thanks sir, I will try anyway.
18:58:53 <stevemar> can we actually end early and not go into infra meeting time?!?
18:58:57 <stevemar> #endmeeting