18:01:19 <dolphm> #startmeeting keystone
18:01:20 <openstack> Meeting started Tue May 14 18:01:19 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:21 <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:24 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:01:34 <dolphm> the agenda is giant today
18:01:53 <bknudson> let's just talk about ldap.
18:01:57 <dolphm> and sort of a mess
18:01:59 <ayoung> dolphm, yeah, that is my doing.  I girue I would make people aware of those isues, not expecting them to be resolved
18:02:09 <ayoung> no, we can't just talk about LDAP
18:02:17 <dolphm> sure we can ;)
18:02:18 <dolphm> but first
18:02:20 <rkanade> Can we get some feedback on https://review.openstack.org/#/c/25517
18:02:22 <gyee> wow, dolphm, I forgot to add the pluggable token management to the agenda
18:02:26 <ayoung> there is a lot going on, and we need core to be engaged across the board
18:02:29 <dolphm> #topic Havana milestone 1
18:02:30 <gyee> I posted the code yesterday
18:02:32 <dolphm> #link https://launchpad.net/keystone/+milestone/havana-1
18:02:38 <dolphm> #link https://wiki.openstack.org/wiki/Havana_Release_Schedule
18:03:12 <dolphm> just an announcement/reminder- havana-m1 is about two weeks out, if you don't think a bp will make it, or are working on a bp should be targeted to m1, let me know
18:03:15 <ayoung> dolphm, so the anony binding is the riks issue there, since it isn't started
18:03:44 <bknudson> and I think topolino is on vacation?
18:03:44 <dolphm> i believe the milestone will be forked on may 28th
18:03:56 <stevemar> bknudson: yep, he is
18:03:58 <dolphm> #topic High priority issues?
18:04:06 <dolphm> anything not on the agenda already?
18:04:08 <ayoung> bknudson, the actual impl is pretty small, can someone else from IBM pick it up?
18:04:15 <dolphm> ayoung: noted
18:04:33 <bknudson> topol is the one with the minions. cat's away kind of thing.
18:04:41 <dolphm> and no topol present
18:04:48 <ayoung> and sahdev is gone, too
18:04:49 <dolphm> i also remember it being a very simple bp
18:04:53 <dolphm> thereotically
18:04:59 <bknudson> it should be like 10 lines of code.
18:05:13 <ayoung> dolphm, for anonymous,  yeah, the one thing I asked is that instead of deducing anonymous, he make it an explicit enumeration value...I can take that one
18:05:18 <bknudson> I hate to promise to do something and then find I'm too busy, but I think I could pick it up.
18:05:26 <ayoung> bknudson, do you have LDAP exp?
18:05:38 <bknudson> ayoung: I've got some LDAP exp. Worked on IBM's server for a few years.
18:05:43 <ayoung> if you take it, I can help you.
18:05:45 <dolphm> bknudson: ayoung: first one to code review wins
18:05:55 <bknudson> ok, I'll put it on my list.
18:05:59 <gyee> which one?
18:06:03 <bknudson> I seem to be better about creating work than finishing it.
18:06:15 <dolphm> bp keystone-ldap-anonymous-binding
18:06:19 <dolphm> https://blueprints.launchpad.net/keystone/+spec/keystone-ldap-anonymous-binding
18:06:46 <gyee> yeah, should be easy
18:07:08 <ayoung> token flush is under review.  the one thing that might mitigate is if we get some agreement on the revoked token table
18:07:22 <dolphm> bknudson: it'd be tough to beat ayoung's stream of consciousness blueprinting ;)
18:07:31 <ayoung> #link https://review.openstack.org/#/c/28859/
18:07:36 <bknudson> I tend to report bugs.
18:07:45 <dolphm> #topic High priority code reviews
18:07:59 <dolphm> bknudson: nothing wrong with that!
18:07:59 <gyee> dolphm, pluggable token management
18:08:08 <rkanade> https://review.openstack.org/#/c/25517
18:08:14 <dolphm> #link https://review.openstack.org/#/c/29021/
18:08:22 <dolphm> gyee: ^
18:08:32 <gyee> yeah, 1 KLOC worth of shit
18:08:59 <ayoung> rkanade, I'll look after the meeting, promise
18:09:11 <ayoung> #action ayoung to review  https://review.openstack.org/#/c/29021/ right after meeting
18:09:13 <rkanade> thanks adam :)
18:09:15 <henrynash> gyee: excellent progress on this…I'll go through it in detail
18:09:17 <ayoung> there it is in the notes!
18:09:21 <dolphm> obviously code reviews for/blocking bp's have highest priority, so besides gyee's that also includes:
18:09:23 <dolphm> #link https://review.openstack.org/#/c/28133/
18:09:28 <bknudson> we've got competing fixes for the atomic problem... jay pipes had one too, I think.
18:09:28 <dolphm> #link https://review.openstack.org/#/c/27881/
18:09:42 <dolphm> bknudson: have links to those?
18:09:48 <rkanade> Jay pipes review for atomic issue doesnt work
18:10:01 <dolphm> rkanade: link to review?
18:10:20 <rkanade> https://review.openstack.org/#/c/27507/1
18:10:25 <bknudson> #link https://review.openstack.org/#/c/27507/
18:10:28 <rkanade> mentioned the issue on that review
18:10:29 <bknudson> jay pipes is abandoned.
18:10:41 <gyee> code review Tuesday, keep'em coming :)
18:10:44 <ayoung> rkanade, aside from "user create needs to be atomic"  what bug is this really fixing?
18:10:55 <dolphm> bknudson: not intentionally though
18:11:19 <ayoung> don't have to answer here, but update the bug report with an actualy "this is causing problem blah..."
18:11:37 <rkanade> it is fixing other 4 apis too 1. update_user_project 2. delete_domain 3. delete_project 4. delete_user
18:12:08 <dolphm> what is update_user_project?
18:12:10 <ayoung> because, while I am sympathetic, LDAP is not going to play well.  And I don't think it is smart to treat sql as a more equal backend
18:12:20 <rkanade> it is an api call, it needs to be atomic
18:12:23 <dolphm> ayoung: +1
18:12:34 <rkanade> all these are api calls which need to be atomic
18:12:49 <ayoung> rkanade, understand, I am propsing that we split identity into 3 parts
18:13:02 <ayoung> and so domains, users, and projects/roles might all be in 3 separate backends
18:13:16 <ayoung> so, kiss your integrity constriants goodbye
18:13:26 <henrynash> ayoung: +1
18:13:31 <gyee> nice
18:13:43 <rkanade> 3 sql backend instances ?
18:13:47 <ayoung> gyee, if you quote me, I want full attribution
18:13:51 <ayoung> rkanade, nope
18:14:05 <ayoung> rkanade, I would see domains in a flat file, idenitity in LDAP, and projects in SQL
18:14:15 <ayoung> being them most common impl  down the road
18:14:23 <rkanade> So no sql backend for identity ?
18:14:58 <asgreene> why split up into multiple stores before the single store models work?
18:14:59 <henrynash> ayoung: that's essentially what the bp: https://blueprints.launchpad.net/keystone/+spec/auth-domain-architecture
18:15:02 <ayoung> rkanade, it will be there, but don't expect the calls to be atomic across domains, idenityt, and projects
18:15:18 <henrynash> ayoung: except that I don't necessarily agree that domains will be a flat file
18:15:39 <rkanade> ok, but that wont fix the atomicity issue right ?
18:15:41 <ayoung> henrynash, sure
18:16:09 <ayoung> rkanade, so long as it is atomic within a single backend, I am OK with it...but I roles assignments are going to be separate from users
18:16:18 <ayoung> update_user_project can't be atomic
18:16:26 <rkanade> i see
18:16:29 <ayoung> delete_user  probabny not either
18:16:43 <ayoung> delete_domain  will span 3 backends
18:16:45 <ayoung> maybe
18:16:45 <henrynash> asgreene: it's an issue of whether identity needs to be defined and tested…ie. where authentication and authorisation needs to take place….and it may well be in non-openstack systems
18:16:51 <bknudson> atomicity will still be problem, but the fix won't be "put it in a single db transaction"
18:17:04 <rkanade> ok, i can fix issue for single backend for now , is the session code in the review alright?
18:17:10 <ayoung> henrynash, to your point, domains will have multiple backends.  I just like the flat file cuz I'm a control freak
18:17:25 <ayoung> and not a "flat" file, but kindof textured and bumpy and json like
18:17:26 <henrynash> bknudson: agreed…we need to make a s/w resilient and expectant to find integrity issues
18:17:31 <rkanade> @bknudson : can you provide some alternative ?
18:17:38 <dolphm> bknudson: +1
18:17:43 <henrynash> ayoung: :-)
18:18:22 <dolphm> ayoung: sounds like yaml
18:18:31 <bknudson> rkanade: I don't think there's an obvious fix for it.
18:18:35 <dolphm> bknudson: +1
18:18:36 <ayoung> dolphm, btw, I'll communicate with jamielennox tonight, and we should have an updated token flush for tomorrow
18:18:48 <dolphm> ayoung: awesome, thanks
18:18:52 <dolphm> ayoung: i'm looking forward to that
18:18:56 <rkanade> any specific reason why db transactions arent ok?
18:18:58 <ayoung> dolphm, maybe. Guess it is time to learn "yet another..."
18:19:01 <gyee> yay, token flush!
18:19:10 <ayoung> rkanade, they are fine, just they can't span multiple backends
18:19:25 <ayoung> rkanade, lets talk after this, and I can help you scope in the patch, ok?
18:19:33 <rkanade> ok sure
18:19:55 <ayoung> dolphm, I'd like to target "split crednetials" for H1
18:20:09 <ayoung> #link https://review.openstack.org/#/c/28372/
18:20:27 <dolphm> is there a bp?
18:20:28 <gyee> speaking of credentials, when are we migrating ec2_credential table over to credential?
18:20:32 <ayoung> should be fairly close.
18:20:39 <gyee> no reason to keep both
18:20:52 <ayoung> dolphm, it is linked to a larger BP, but not one that would be completed for H1, so nevermind
18:20:58 <dolphm> gyee: +1
18:21:09 <ayoung> gyee, +1
18:21:27 <ayoung> gyee, that might also help out with some of the issues we have with the ec2 middleware
18:21:36 <dolphm> ayoung: like what?
18:21:46 <gyee> dolphm, ayoung, should I file a bp and get it done?
18:22:22 <dolphm> #link https://review.openstack.org/#/c/27563/
18:22:30 <henrynash> dolphm: how about: https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles
18:22:30 <dolphm> gyee: that'd be great
18:22:38 <henrynash> dolphm: I could get that done for H1
18:22:47 <ayoung> dolphm, thanks
18:22:57 <ayoung> yeah waht are we doing about domains?
18:23:01 <ayoung> er, regions
18:23:02 <henrynash> dolphm: although we haven't actually approved it
18:23:07 <dolphm> henrynash: let me know when you have an implementation, and if it looks like we can merge in h1, we'll bump it up?
18:23:23 <henrynash> dolphm: ok
18:23:36 <gyee> dolphm, what's the deal with this? https://review.openstack.org/#/c/27563/
18:23:38 <ayoung> aside from termie are we all agreed that jaypipes bp is correct?
18:23:42 <dolphm> henrynash: direction is approved, just no spec or anything to approve the bp design
18:23:51 <ayoung> https://blueprints.launchpad.net/keystone/+spec/first-class-regions
18:23:54 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/first-class-regions
18:24:00 <jaypipes> lol.
18:24:01 <gyee> I hate to agree with termie, but I think he's onto something
18:24:03 <dolphm> henrynash: spec == code review*
18:24:04 <gyee> :)
18:24:09 * jaypipes had pretty much just given up on it all.
18:24:12 <ayoung> he did write up a doc spec
18:24:15 <henrynash> dolphm: ;-)
18:24:21 <gyee> I like a general approach for endpoint lookups
18:24:52 <gyee> an endpoint is just a url and a bunch a attributes
18:24:52 <ayoung> is the "regions" abstraction general enough to cover all of the use cases we have?
18:25:06 <ayoung> namely:  what endpoints to link to a project, and so on?
18:25:07 <gyee> we should be able to construct any kind of filters
18:25:20 <dolphm> ayoung: it sounded like it was general enough for the discussions we had in the regions session
18:25:21 <gyee> just like LDAP filters
18:25:50 <dolphm> jaypipes: since there's no impact on existing api's, i'm wondering if this should be an OS-REGION extension on top of v3
18:25:51 <ayoung> dolphm, yep, that was my take.
18:26:23 <ayoung> dolphm, the one issue that has come up (and I think it covers) is for things that are not necessarily keystone concepts, like cells.
18:26:26 <dolphm> jaypipes: and limit the implementation impact to it's own middleware
18:26:52 <jaypipes> dolphm: I don't see why it would be an extension... the concept is already in the existing API -- it's just not a first-class citizen.
18:26:54 <dolphm> ayoung: i don't think it's intended to overlap with cells, afaik
18:27:13 <dolphm> ayoung: just everyone's various interpretations of "regions" and availability zones
18:27:19 <ayoung> dolphm, so, it was not intended to, but *could* it was the question
18:27:29 <jaypipes> ayoung: cells are private to an implementation -- i.e. they are not discoverable,.
18:27:48 <dolphm> jaypipes: termie will certainly be much more agreeable if it's a discrete extension
18:27:51 <jaypipes> ayoung: in other words, a user can't ask that a resource be spun up in a cell.
18:27:58 <ayoung> if we say that Regions is the abstraction for grouping resources, and ,if you ever need to expose something new, such as cells (in the future) I think there is a clear mapping
18:28:09 <ayoung> jaypipes, not today. But what about tomorrow?
18:28:11 <jaypipes> dolphm: extension of the service catalog or extension of the API in general?
18:28:13 <dolphm> ayoung: tenants/projects are the abstraction for grouping resources
18:28:22 <ayoung> dolphm, but not by locale
18:28:25 <dolphm> jaypipes: of the api in general
18:28:31 <jaypipes> ayoung: I'll pay you for that hamburger then.
18:28:35 <ayoung> dolphm, I hear you, this is nova stuff, and not our abstractions
18:28:39 <ayoung> jaypipes, you misunderstand
18:28:50 <ayoung> I am saying that "yes, this abstraction is powerful enough"
18:29:06 <jaypipes> dolphm: I'm fine putting it in an extension if that's what folks want, sure.
18:29:08 <ayoung> so we *should* go with regions as designed.  I don't think that was clear.
18:29:17 <ayoung> jaypipes, it can't be an extension
18:29:22 <jaypipes> ayoung: ah, gotcha
18:29:24 <ayoung> it needs to be part of the service catalog
18:29:28 <dolphm> ayoung: ?
18:29:42 <jaypipes> lol, when you guys figure that out, lemme know and I will code it up. ;)
18:29:44 <ayoung> dolphm, regions are going to be how we group things in the service catalog
18:30:06 <ayoung> jaypipes, this is when I go to bat for you and say "lets cook this"
18:30:07 <dolphm> ayoung: sure, but that doesn't mean it needs to be in the catalog controller/driver
18:30:31 <ayoung> dolphm, OK,  I can see it as a separate back end...maybe, if I squint
18:30:51 <dolphm> ayoung: then it should be just as easy to see it as an extension with it's own backend (please continue squinting)
18:31:00 <fabio> Maybe there should be a Group concept like the one for users
18:31:06 <gyee> ayoung, with the pluggable token management backend, you can have you own catalog if you want
18:31:09 <gyee> just saying
18:31:14 <dolphm> ayoung: there's a bunch of other reviews on the meeting agenda, any others your want to mention?
18:31:21 <ayoung> dolphm, ok, so a related issue is: splitting migration back ends
18:31:29 <ayoung> keeping it in the scoped o jaypipes work
18:31:39 <ayoung> say he needs a DB backend
18:31:56 <ayoung> we shouldn't be oputting that in with the rest of the common sql code
18:32:20 <dolphm> currently db_sync will stand up tables for any/all extensions, i don't see an immediate reason to change that, although it'd be ncie
18:32:21 <ayoung> so we need to make it the first backend that has its own revision repo...
18:32:23 <dolphm> it's not a blocker
18:32:43 <ayoung> dolphm, extensions should not be in core, otherwise, "extensions" means nothing
18:32:48 <ayoung> but we already have the mech
18:33:18 <gyee> ayoung, I think "extensions" is more significant to the API then impl
18:33:22 <ayoung> dolphm, I think we need to be able to enumerate through the "active extensions" from the config file, and call db_syn on each one
18:33:33 <ayoung> gyee, I'll link, one sec
18:33:44 <bknudson> #link https://wiki.openstack.org/wiki/Keystone/sql-migrate-extensions
18:34:07 <ayoung> #link https://github.com/openstack/keystone/blob/master/keystone/cli.py#L51
18:34:22 <ayoung> so we call db_sync for each backend, even though they are all common code
18:34:36 <ayoung> but we have no way for doing it for an 3rd party extension
18:34:42 <bknudson> ayoung: so we'd need some way for extension to register db_sync.
18:34:52 <ayoung> bknudson, right...so how about
18:35:09 <ayoung> extensions = regions, oauth....
18:35:20 <ayoung> and then we pull that out of the config file and enumerate?
18:35:54 <bknudson> extensions is a config option? it's not just they add middleware?
18:36:06 <ayoung> [pipeline:public_api]
18:36:17 <bknudson> ok
18:36:17 <ayoung> bknudson, it is done like that for now^^
18:36:37 <dolphm> ayoung: i'm just saying that's massive scope creep for this, considering we're way past that
18:36:42 <ayoung> but not everything that is registered that way would end up getting a db_sync
18:36:45 <dolphm> ayoung: nice to have yes, but not a blocker for this
18:36:49 <ayoung> dolphm, no, this is fixing something we've messed up
18:36:57 <ayoung> dolphm, oauth is going to have the same thing
18:37:07 <dolphm> ayoung: right, but it's already broken
18:37:13 <ayoung> it also would have been cleaner for trusts...I'm truying to learn from mistakes of the past
18:37:19 <ayoung> so for all extensions, we need this
18:37:32 <ayoung> we are making the rule "do it in an extension first"
18:37:37 <ayoung> so this is out side of the bargain
18:37:42 <ayoung> out->our
18:37:59 <ayoung> dolphm, I can code it up...I'll take this, and jaypipes can consume it
18:38:09 <gyee> it going to be messy, if I remove an extension from the pipeline, do I run db_sync to downgrade?
18:38:21 <dolphm> ayoung: sure, but it's not fair to block his implementation if he gets there first
18:38:22 <ayoung> gyee, you don't have to, but you can
18:38:27 <dolphm> gyee: +1
18:38:38 <gyee> I think this is going to be extremely messy
18:38:44 <dolphm> db_sync <backend-name> ?
18:38:49 <dolphm> gyee: +1
18:38:59 <ayoung> gyee, there is actually already a mechanism in place for it, we just don't use it
18:39:06 <ayoung> see the BP
18:39:15 <gyee> how the deployers need to have knowledge of the backend
18:39:16 <ayoung> just needs a unique repo patch
18:39:25 <bknudson> is the repository path in the extension?
18:39:39 <ayoung> gyee, no, they need to register it as an extension.  we can have the rgions extension enabled by default if we decided
18:39:46 <ayoung> bknudson, sort of
18:39:50 <ayoung> bknudson, it is in the DB table
18:40:01 <ayoung> and the migrations themselves are then in the extension
18:40:07 <dolphm> we don't even support multiple sql backends, much less this
18:40:16 <bknudson> ayoung: yes, that's what I was asking.
18:40:28 <ayoung> dolphm, we do  support this already, for the most part
18:40:36 <ayoung> we just have only one migrtation scheme, in common
18:40:39 <ayoung> but in the db:
18:40:53 <ayoung> select * from migrate_version;
18:40:58 <ayoung> keystone      | /opt/stack/keystone/keystone/common/sql/migrate_repo |      22
18:41:07 <dolphm> ayoung: post a demo of two backends using separate sql connection strings, and an API call that consumes both
18:41:39 <ayoung> dolphm, this would be in a single backend.  smaller use case
18:41:52 <dolphm> (since this was on the agenda)
18:41:52 <dolphm> #topic splitting migration back ends
18:42:02 <ayoung> thanks
18:42:33 <ayoung> dolphm, anyway, enough people have the context, I'll work with the people writing extensions to make it happen
18:42:51 <dolphm> ayoung: alright
18:42:53 <dolphm> #topic IPv6 and eventlet
18:42:55 <dolphm> bknudson: ?
18:43:01 <rkanade> It is very late here in India,  please give your comments on the review itself https://review.openstack.org/#/c/25517 . Thanks :) , cya all .
18:43:06 <dolphm> rkanade: o/
18:43:07 <ayoung> gnighht rkanade
18:43:10 <bknudson> dolphm: I added this just to mention the bug report...
18:43:11 <rkanade> gn
18:43:18 <bknudson> #link https://bugs.launchpad.net/keystone/+bug/1178732
18:43:19 <uvirtbot`> Launchpad bug 1178732 in keystone "Eventlet dnspython monkey-patching problems" [Undecided,New]
18:43:29 <ayoung> so we are back on an even keel with IPv6 and eventlet for gating, right?
18:43:35 <dolphm> there's also:
18:43:37 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1176204
18:43:38 <uvirtbot`> Launchpad bug 1176204 in keystone "keystone ipv6 tests fail" [Undecided,Fix committed]
18:43:48 <bknudson> I think what I'll go with is moving the wsgi.Server code to its own part
18:43:54 <dolphm> bknudson: ayoung: what's the current status of all this?
18:44:05 <ayoung> so jamielennox is working on something that might help, too
18:44:14 <bknudson> Where we are now is that the tox.ini sets the env var for eventlet
18:44:28 <bknudson> This is another change that we should be able to get rid of.
18:44:43 <ayoung> jamielennox had posted code for reveiw, but it was too huge...
18:44:54 <ayoung> it is now abandoned and he is reworking into smaller patches
18:45:07 <ayoung> one goal, the main one, is to remove eventlet from the server test code, and use webtest
18:45:14 <ayoung> let me find the link
18:45:37 <ayoung> #link https://review.openstack.org/#/c/28387/
18:46:02 <ayoung> he has split the v2 and v3 tests out, but the main thing, the webtest one, is still being reworked
18:46:11 <bknudson> the major problem was the tests, so changing to webtest would make it easier
18:46:29 <bknudson> but I assume the keystone-all server still uses eventlet?
18:46:32 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/extract-eventlet
18:46:44 <ayoung> #link https://review.openstack.org/#/c/29049/
18:46:53 <dolphm> interesting approach
18:47:23 <bknudson> do we use eventlet when run under apache?
18:47:25 <dolphm> bknudson: i would assume so based on this patch
18:47:29 <dolphm> bknudson: no
18:47:41 <ayoung> bknudson, as much as possible, no
18:47:55 <ayoung> most of the eventlet patching was moved into the startup code, and apache start up bypasses that
18:48:08 <dolphm> nginx as well
18:48:10 <bknudson> then I'm not sure what the blueprint is talking about with apache/nginx?
18:48:25 <ayoung> https://github.com/openstack/keystone/blob/master/bin/keystone-all#L109
18:48:41 <ayoung> bknudson, trying to make sure we are testing what would actually be run in them, for one thing
18:49:26 <bknudson> so is the blueprint about changing keystone-all to not use eventlet, too?
18:49:47 <ayoung> bknudson, no, the blueprint is to make the final changes to make the tests and client and middleware don't require it
18:49:56 <dolphm> targetted bp to m2
18:50:02 <dolphm> targeted*
18:50:09 <ayoung> dolphm, thanks
18:50:12 <bknudson> ok, well, maybe I'll get my change in before that.
18:50:25 <bknudson> I don't think it conflicts.
18:51:06 <ayoung> dolphm, so the test re-org is a *nice to have* not a need-to-have
18:51:42 <ayoung> but it comes from jamielennox trying to separate out the eventlet code in the testing, and getting frustrated with the organic nature of the code
18:51:57 <ayoung> I think the v3 one looks good, suspect that the v2 one is probably right, as well
18:52:34 <ayoung> anyway, instead of it coming by fiat, everyone should look and provide feed back, with an eye to keeping the tests as maintainable as possible
18:52:52 <ayoung> dolphm, can we talk Token table revocations list now?
18:53:16 <dolphm> ayoung: is that on the agenda somewhere?
18:53:25 <ayoung> dolphm, yep
18:53:39 <ayoung> dolphm, right under "Atomic API "
18:53:49 <dolphm> was hoping to get to notifications (but bknudson also disappeared)
18:53:57 <bknudson> diasppeared?
18:53:57 <dolphm> bknudson: er, maybe not
18:54:15 <dolphm> bknudson: maybe my client was acting weird
18:54:28 <dolphm> ayoung: i thought we talked about atomic stuff
18:54:41 <dolphm> ayoung: pm me
18:54:41 <ayoung> dolphm, so Token revocation is a real bug, and is stonewalled
18:54:42 <dolphm> #topic Notifications
18:54:44 <dwaite> is there a BP for revocations?
18:55:05 <ayoung> dwaite, see the agenda, links to the reviews, and bps off of them
18:55:29 <bknudson> we were wondering if you dolphm could use some help on the notifications, to speed it up
18:55:31 <ayoung> dolphm, just need people to keep that process moving. termie objects, but I think we can't meet his ideals on this one\
18:55:40 <bknudson> I've got a guy on my team here ( lbragstad ) who could help out
18:55:41 <dolphm> bknudson: what kind of help?
18:55:51 <bknudson> dolphm: implement it.
18:56:03 <dolphm> i'd love to, but not sure if i can hit m1
18:56:26 <dolphm> bknudson: oh wait, i misread that
18:56:26 <bknudson> dolphm: I think it's scheduled for m3, with his help could probably move up to m2.
18:56:33 <dolphm> bknudson: you want him to implement it?
18:56:43 <bknudson> dolphm: yes, have him implement it.
18:56:52 <dolphm> bknudson: i don't have any issue with that
18:56:57 <bknudson> dolphm: great!
18:57:03 <dolphm> bknudson: i've only put a little thought into how i would implement, but haven't written any code
18:57:07 <lbragstad> dolphm: awesome thanks!
18:57:34 <bknudson> that was it for notifications.
18:57:52 <ayoung> notifications are an argument to split project fro identity, too.
18:57:53 <dolphm> bknudson: why i had notifications targetted to m3- it's not api-impacting, so that's just the latest it could possibly merge; i'd like it to depend on oslo.notify, which is still in progress
18:58:15 <dolphm> lbragstad: get caught up on oslo.notify!
18:58:37 <dolphm> i haven't seen any blockers in those discussions for us
18:58:41 <lbragstad> dolphm: yep, I was working with a core from oslo on that for a while yesterday
18:58:44 <dolphm> awesome
18:58:50 <dolphm> lbragstad: keep me posted
18:59:01 <ayoung> dolphm, last thing I'd like to hit is: gate support for MySQL and Postgres Unit tests
18:59:11 <lbragstad> I guess the only question I had was if notify doesn't have a maintainer, does that effect us
18:59:11 <dolphm> #topic gate support for MySQL and Postgres Unit tests
18:59:17 <dolphm> err eff
18:59:19 <dolphm> 1 minute
18:59:19 <ayoung> we can run the unit tests against the real DBS, we should be running that in the gate.  Agreed?
18:59:41 <ayoung> #link https://review.openstack.org/#/c/27878/
18:59:44 <ayoung> henrynash, gyee ?
18:59:50 <dolphm> "unit" tests, no lol
18:59:55 <gyee> ayoung, on it
19:00:15 <dolphm> #endmeeting