18:00:34 <stevemar> #startmeeting keystone
18:00:35 <openstack> Meeting started Tue Jun 14 18:00:34 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:39 <openstack> The meeting name has been set to 'keystone'
18:00:41 <dstanek> o/
18:00:50 <MeganR> o/
18:00:57 <shaleh> \o
18:01:04 <stevemar> let's jump right into it
18:01:07 <stevemar> rmizuno_: you here?
18:01:14 <notmorgan> link the agenda?
18:01:27 <stevemar> notmorgan: thanks, is my rust showing :)
18:01:29 <stevemar> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:01:40 <ayoung> \m/   d(-v-)b  \m/
18:01:46 <lbragstad> o/
18:02:06 <rmizuno_> stevemar: yes
18:02:12 <stevemar> rmizuno_: doesn't seem to be here, so i'll skip to the next topic, if he... oh there you are
18:02:22 <stevemar> #topic Add resource name to the notification event
18:02:27 <stevemar> rmizuno_: the floor is yours
18:02:33 <gyee> just do it!
18:02:48 <stevemar> gyee: but names are mutable and domain scoped o_O
18:02:58 <ayoung> we only do IDs now, and that is hard to match, I take it?
18:03:05 <henrynash_> (hi)
18:03:05 <stevemar> ayoung: yep
18:03:08 <rmizuno_> #link: https://review.openstack.org/#/c/320299/
18:03:18 <ayoung> audit events are going to get big
18:03:20 <rmizuno_> this patch was intended to add a name to the audit notification when the project deleted.
18:03:22 <gyee> stevemar, notification and audits is a snapshot in time
18:03:25 <gyee> nothing more
18:03:29 <dolphm> ayoung: ++
18:03:34 <rmizuno_> but, it seems odd to do it just for deleting project.
18:03:39 * lbragstad we had a similar request here - https://bugs.launchpad.net/keystone/+bug/1552795
18:03:39 <openstack> Launchpad bug 1552795 in OpenStack Identity (keystone) "enhance notification for user events with user name" [Wishlist,In progress] - Assigned to Lance Bragstad (lbragstad)
18:03:46 <ayoung> rmizuno_, is this a case of the cure being worse than the disease?
18:03:46 <rmizuno_> so, I want to gain approval about adding the resource name to all audit notification.
18:03:52 <dstanek> #link https://bugs.launchpad.net/keystone/+bug/1552795 similar bug
18:03:53 <lbragstad> and there were some good points made in that report
18:04:00 <stevemar> rmizuno_: so, i understand the need for doing this for projects
18:04:04 <gyee> we have to understand what notifications and events are for
18:04:17 <gyee> to facilitate monitoring, auditing, and forensics
18:04:33 <stevemar> rmizuno_: but i'd like the code to be done in a way that it's extensible, so users, roles, etc... can also add names to the event
18:04:36 <dolphm> ID's certainly fulfill that requirement
18:04:58 <notmorgan> dolphm: ++ if not being super friendly, but are guaranteed immutable and unique within a deployment
18:05:09 <notmorgan> so are *safe* for such actions
18:05:12 <stevemar> rmizuno_: also, we need to include domain name
18:05:16 <dstanek> gyee: you're missing your implied requirement to tie things back to your source system
18:05:16 <dolphm> the use case in the bug report, and the one we've discussed before, is primarily around the ** user experience ** of receiving an audit notification
18:05:23 <jamielennox> but particularly for a delete action you can't resolve an ID into a name later
18:05:28 <dolphm> not the functionality of audit notifications
18:05:39 <stevemar> dolphm: right, this is totally a UX thing
18:05:42 <gyee> dstanek, its a snapshot of the resource at that time, whatever it was/is
18:05:49 <ayoung> What if we had a utility to populate it ex-post-facto instead?
18:05:58 <stevemar> if you're using the name as the canonical source, tis your own fault :P
18:06:01 <dstanek> gyee: not saying you're wrong, just that you need to clarify the requirements
18:06:08 <ayoung> lkeep the audit events small, but have a "expand audit log ids" CLI
18:06:14 <bknudson> unless you're keeping essentially a duplicate of the keystone database there's no way you could get the name on a delete event.
18:06:27 <dolphm> ayoung: then we have to keep deleted entities around to make that work
18:06:42 <lbragstad> bknudson which is something that can be done today
18:06:47 <stevemar> bknudson: fetch the resource from the backend before deleting? i think we do that now today?
18:06:49 <notmorgan> dolphm: we may want to do that for many reasons [change the course from today]
18:06:50 <dolphm> bknudson: which is not a bad or strange idea at all if you care about your data that deeply
18:06:53 <ayoung> dolphm, seems like that would be a shrotcoming of the current system, wouldn'tit
18:07:04 <ayoung> so...better to have the names in there at least for deletes
18:07:11 <gyee> I would hate to have my monitoring system to do a resource looking in order to display meaningful/reading stuff
18:07:15 <lbragstad> bknudson i highlighted that in a summary of this discussion from the summit - http://lbragstad.com/improving-auditing-in-keystone/
18:07:16 <ayoung> and for anything that is deleted, we would have no way of mapping...
18:07:27 <shaleh> even the ID is useless post delete right? Sure it was unique but what was it.....
18:07:32 <gyee> not to mention having to configure a credential in my monitoring in order to lookup stuff
18:07:44 <stevemar> shaleh: that was mfisch's point too
18:07:44 <notmorgan> i'm more inclined to make delete not be a "remove the row from the DB"
18:07:49 <notmorgan> fwiw
18:07:54 * ayoung too
18:07:57 <ayoung> soft delets
18:07:59 <ayoung> deletes
18:08:05 <dolphm> gyee: the current audit records *are* meaningful - don't confuse this for a lack of functionality
18:08:08 <notmorgan> ayoung: lets not call it that please...
18:08:11 <dstanek> a side effect is dealing with uniqueness in code
18:08:17 <raildo> notmorgan: ++ for soft deletes
18:08:18 <notmorgan> ayoung: just change what the delete means.
18:08:22 <bknudson> if I've kept a copy of the data (ID -> name) from before the delete I could use the ID to look up the name
18:08:35 <raildo> (or whatever other name for this)
18:08:39 <gyee> dolphm, just display the resource ID in the screen?
18:08:40 <dolphm> verbose cadf vs soft deletes vs shadow tables: http://lbragstad.com/improving-auditing-in-keystone/
18:08:53 <dolphm> gyee: ?
18:08:54 <notmorgan> please no shadow tables
18:09:07 <notmorgan> i'll take verbose cadf easily before that
18:09:07 <dolphm> notmorgan: that'd be an operator solution, not upstream
18:09:09 <rderose> notmorgan: ++
18:09:13 <dolphm> notmorgan: operators can do that today
18:09:20 <ayoung> notmorgan, it was the term he used on the blog post
18:09:25 <notmorgan> dolphm: true.. but nova did that in their tree
18:09:32 <notmorgan> i don't want to see that replicated ;)
18:09:34 <stevemar> dolphm: from an implementation point of view, adding the names is the easiest of those 3
18:09:40 <dolphm> notmorgan: or maybe it's something we can document upstream as our recommended solution if you want those behaviors
18:09:43 <dstanek> notmorgan: what did they do?
18:09:59 <notmorgan> dstanek: they have all sorts of internal shadow tables for book keeping on deletes
18:10:00 <bknudson> who would have a problem with adding name to the audit payload?
18:10:14 <notmorgan> dstanek: accross services etc.
18:10:14 <stevemar> bknudson: presumably only keystone devs :P
18:10:21 <dolphm> notmorgan: didn't know that, that sounds awful. are they using mongo?
18:10:21 <gyee> dolphm, when monitor system receiving an event which containing only resource ID, it has to make a call to Keystone to lookup the resource (if it still there) in order to display something that is *readable*
18:10:35 <lbragstad> well what if an operator doesn't want a particular attribute in the payload
18:10:36 <samueldmq> verbose notifications would be something configured in the config file right?
18:10:37 <notmorgan> easiest solution: verbose cadf, best solution don't delete the rows, worst of both worlds shadow tables
18:10:39 <lbragstad> and we put it in there
18:10:42 <samueldmq> somehting like configuring the log level
18:10:45 <samueldmq> notificaiton levle ?
18:10:45 <notmorgan> samueldmq: no. lets not do that
18:10:54 <dstanek> dolphm: doubt it, because they could use just a single 'audit' collection
18:10:55 <ayoung> you know what...I'm not really engaged in this.  Any of the options would suffice by me
18:10:56 <notmorgan> samueldmq: please lets not add knobs to what is in notifications.
18:10:57 <shaleh> notmorgan: ++
18:10:59 <dolphm> gyee: again, the use case your describing is user experience, not system auditing
18:11:00 * stevemar thinks we should make cadf the default notification format
18:11:10 <shaleh> I like soft deletes. It is kind of the norm really.
18:11:20 <shaleh> easier to ensure uniqueness too.
18:11:44 <stevemar> it's been ten minutes, doesn't seem like there's consensus here
18:11:44 <dstanek> if we just always put ids and names in the audit records would that satisfy 90% of the needs for more data?
18:11:48 <gyee> user experience matters
18:11:52 <stevemar> dstanek: i think so
18:11:54 <dolphm> notmorgan: ++
18:11:55 <samueldmq> what is a notification ? is it supposed to only contain operation/entity_id ?
18:11:58 <shaleh> dstanek: I think so
18:12:00 <notmorgan> in fact i recommend adding name to cadf AND not deleteing rows
18:12:09 <notmorgan> for different reasons
18:12:12 <shaleh> notmorgan: agreed on not deleting.
18:12:16 <notmorgan> but it would be the most complete solution
18:12:32 <stevemar> notmorgan: ++
18:12:36 <notmorgan> so lets do that
18:12:40 <stevemar> *why not both*
18:12:42 <notmorgan> name first, not delete rows second
18:12:48 <stevemar> yep
18:12:51 <shaleh> ++
18:12:56 <stevemar> rmizuno_: consider it approved
18:12:59 <samueldmq> so adding names for ALL entities right?
18:13:00 <bknudson> we'll just run lbragstad's performance tests with the change and see what the effect is.
18:13:02 <samueldmq> not just projects
18:13:03 <dolphm> why not full objects? because that's the next request
18:13:12 <gyee> for the second part, we need a more comprehensive resource lifecycle management framework
18:13:12 <dolphm> #slipperyslope
18:13:15 <stevemar> rmizuno_: please try to make the code so other resources can use it
18:13:19 <samueldmq> dolphm: ++ and their memory refs
18:13:19 <notmorgan> dolphm: because we wont delete the objects
18:13:28 <notmorgan> dolphm: to avoid that
18:13:31 <lbragstad> stevemar i would be in favor of having a single notification format... having configurable notification stuff is confusing
18:13:31 <stevemar> dolphm: we won't include the description too :P
18:13:36 <dolphm> bknudson: i don't think there is any messaging support in the benchmark
18:13:36 <notmorgan> dolphm: provide real lifecycle management on the resorces
18:13:38 <rmizuno_> stevemar: ok
18:13:51 <rmizuno_> thanks! all!
18:13:55 <dstanek> if we stop deleting rows we'll have to start enforcing rules in python that the db currently handles
18:13:56 <stevemar> lbragstad: i agree, as it stands now the 'audit' format is not default
18:14:07 <lbragstad> right
18:14:08 <shaleh> lbragstad: if we can come up with a minimal, sufficient format I am +1 to that
18:14:13 <samueldmq> if we're going to not delete rows, why not start with that
18:14:28 <samueldmq> instead of adding names -> stop dleeting rows ?
18:14:28 <stevemar> samueldmq: adding names is much easier to do
18:14:36 <samueldmq> let's do it right from the start :)
18:14:56 <raildo> it is not wrong adding names, it just simpler for now
18:15:03 <dolphm> dstanek: ++ :(
18:15:07 <samueldmq> stevemar: and after when we don't delete roles anymore, we won't be able to remove names from the events anymore
18:15:10 <notmorgan> dstanek: not really, the db can still handle it, it is just changing how we handle unique constraints
18:15:22 <notmorgan> dstanek: i can show you the migrations for it. it isn't too terrible
18:15:22 <dstanek> notmorgan: how would you do that?
18:15:49 <notmorgan> dstanek: unique(deleted(notNull, Bool), delete_time(notNull, default=0)
18:16:07 <stevemar> we still have a lot on the agenda, can we discuss this in -keystone or in the patch?
18:16:07 <notmorgan> dstanek: add in name etc constraints
18:16:16 <samueldmq> stevemar: ++
18:16:24 <notmorgan> it basically means you unique on "not-deleted, and delete time 0, and <other thing>"
18:16:32 <notmorgan> and ids still remain unique
18:16:37 <notmorgan> dstanek: i'll go over it more with you post meeting
18:16:39 <notmorgan> (s)
18:16:43 <notmorgan> it's not that hard to do.
18:16:56 <stevemar> #topic Drop support for Driver Versioning
18:17:04 <stevemar> rderose: ^
18:17:05 <notmorgan> stevemar: just rubber stamp this.
18:17:07 <rderose> So the spec proposes dropping support for driver versioning.
18:17:14 <rderose> There is a maintenance/development burden, however small you think it is.
18:17:21 <rderose> I don't like our approach and question whether operators are actually benefiting from it.
18:17:26 <stevemar> i saw the ML post, but no one replied to it :(
18:17:27 <notmorgan> stevemar: no one seems to care [though i dislike not having a clear contract, i'm willing to go with the general community consensus]
18:17:29 <rderose> And to me it's not unreasonable to say, if you want to upgrade Openstack, you'll need to upgrade and test your custom drivers.  That's it.
18:17:38 <dolphm> stevemar: i'd rather have some decisions than try to rush through a rediculously long agenda
18:17:38 <notmorgan> and i'm the reason for the original proposal.
18:17:50 <dstanek> notmorgan: we can have a clear contract without supporting old versions of it
18:18:06 <gyee> oh I love the terms "technical debt"
18:18:21 <notmorgan> dstanek: either not really a contract [or unchanging?] or need versioning
18:18:27 <lbragstad> i imagine we would have to provide better documentation when interfaces change?
18:18:28 <ayoung> we did "delete means disable" for tokens for a long time
18:18:28 <bknudson> what's wrong the approach?
18:18:32 <stevemar> dolphm: fair enough, we can circle back to it. i'll drop my item
18:18:34 <henrynash_> so my question is why do we think the answer is different today than we did 3 releases ago?
18:18:48 <bknudson> maybe we can fix the approach
18:18:56 <notmorgan> henrynash_: because fewer deployments run custom drivers now. iirc
18:19:05 <dstanek> henrynash_: i didn't actually like it then either
18:19:16 <notmorgan> i haven't heard of folks doing it in the last year
18:19:23 <henrynash_> dstanek: I think we all felt it was a necessary evil
18:19:27 <notmorgan> it was much more prevalent when i proposed this
18:19:34 <ayoung> lets kill driver versioning and if people are doing customer drivers break them willy and nilly.
18:19:36 <bknudson> we'll likely wind up running a custom driver here.
18:19:54 <amakarov> rderose, is this support is dropped immediately after spec merge or we still have to support versions and adapters in between for 2 releases?
18:19:57 <stevemar> bknudson: would keeping the versioned drivers make things easier for you?
18:20:01 <dolphm> henrynash_: the maintenance cost of the current approach is astronomical compared to the supposed benefit
18:20:03 <samueldmq> we should listen to deployers and take our decision to keep or not supporting it
18:20:15 <stevemar> amakarov: it would be 2 releases i think
18:20:19 <dolphm> samueldmq: deployers have not expressed any support on the mailing list either way
18:20:21 <notmorgan> samueldmq: i hear no deployers asking for it at this point
18:20:27 <notmorgan> previously there were a number
18:20:28 <bknudson> stevemar: I don't think the versioned drivers actually would help us much.
18:20:38 <notmorgan> dreamhost, hp, etc
18:20:44 <ayoung> the only way to find out who is using it is to remove it.  For any value of *it*
18:20:45 <samueldmq> dolphm: notmorgan: so I fully support dropping support for custom drivers
18:20:46 <bknudson> we'll have to change our driver eventually so will likely just do it when we upgrade.
18:20:53 <samueldmq> maintanance costs are high
18:20:54 <notmorgan> samueldmq: no.
18:20:55 <bknudson> and write our own translation code.
18:20:56 <rderose> bknudson: for complicated drivers, "faking out" methods is difficult
18:21:00 <notmorgan> samueldmq: verioned drivers.
18:21:09 <amakarov> stevemar, so delegation driver adapters I'm working should still introduce new assignement and trust driver versions instead of just changing them?
18:21:10 <notmorgan> samueldmq: someone can still write a custom driver.
18:21:11 <stevemar> notmorgan: so why did hp & dreamhost change?
18:21:20 <notmorgan> stevemar: hp doesn't run a public cloud now.
18:21:24 <ayoung> dreamhost changed because I broken them
18:21:28 <notmorgan> stevemar: dreamhost moved to pure upstream.
18:21:32 <samueldmq> notmorgan: ok, so we keep supporting withouth the headache of versioning them
18:21:32 <notmorgan> stevemar: afaik
18:21:34 <ayoung> when we split ID into id and assignment.
18:21:36 <gyee> stevemar, I can't get us to contribute the mongodb driver, so I won't cry if we drop it
18:21:36 <samueldmq> notmorgan: yes that's what I MEANT
18:21:37 <ayoung> poort thingy
18:21:38 <notmorgan> samueldmq: basically
18:21:39 <jamielennox> the thing i like about the custom drivers is the backwards support from version to version. If we think we can do upgrade notes etc on drviers and deprecation periods etc then they're not needed - but historically we didn't
18:21:46 <samueldmq> notmorgan: ++ I support that
18:22:01 <ayoung> better to push for code going in upstream
18:22:07 <gyee> iSuck
18:22:17 <notmorgan> we could also just 2-cycle support the backend driver contract - no versions
18:22:24 <shaleh> jamielennox: good points
18:22:36 <samueldmq> let's create better docs about driver contract changes; and to be honet they're pretty good right now since we do release notes
18:22:53 <notmorgan> but as the original champion of this - i'm fine with it being dropped. i hear very few people [zero] asking for this now.
18:22:56 <bknudson> we don't really have a driver contract anyways.
18:22:59 <dolphm> samueldmq: we can't avoid driver contract changes...
18:23:12 <notmorgan> we aren't ironic, we aren't cinder with 3rd party drivers
18:23:13 <amakarov> ayoung, the problem I see, is we're saying: "You can write your own drivers with this interface which is subject to change anytime we please"
18:23:21 <bknudson> even the backends we supply now work differently in many cases
18:23:22 <stevemar> i'm OK with not creating any new drivers and removing the current versioned drivers when they have been deprecated
18:23:24 <samueldmq> dolphm: exactly, so let's just document the changes better (with release notes). and drop support for versioning
18:23:32 <notmorgan> amakarov: well not once release happens for a given cycle
18:23:32 <rderose> amakarov: basically notify in newton and remove in O
18:23:46 <notmorgan> amakarov: but if you're chasing master, do it at your own risk
18:23:49 <jamielennox> samueldmq: we lack the notes saying to upgrade you need to implement these functions and drop these others, with the versioning it's easy to see what you need to implement rather than scattered deprecation notices
18:23:54 <dolphm> samueldmq: oh, sure ++
18:23:55 <gyee> samueldmq, the code is the document :-)
18:24:01 <notmorgan> we wont change [barring security issues etc] the backend interfaces on a given release.
18:24:19 <raildo> gyee: the better way, always :D
18:24:23 <notmorgan> gyee: don't even joke about that :P
18:24:30 <dolphm> stable releases are stable, and that's never changed
18:24:34 <samueldmq> jamielennox: that info is available in the release notes, at least the ones I've seen from henrynash_ iirc
18:24:35 <bknudson> at this point the code is the document
18:24:36 <notmorgan> dolphm: ++
18:24:38 <notmorgan> anyway.
18:24:41 <bknudson> since we don't document the interface.
18:24:45 <stevemar> i think we're all in agreement (except maybe henrynash_) ?
18:24:47 <jamielennox> but i've advocated before we should create a keystone/lib dir and treat it like a real library and put in there anything that is supposed to be consumed from others
18:24:47 <samueldmq> knikolla: we can do that with release notes pretty easily
18:24:49 <notmorgan> genral consensus - drop it?
18:24:53 <samueldmq> vote ?
18:24:55 <notmorgan> and document better?
18:25:07 <dstanek> notmorgan: drop & doc!
18:25:19 <henrynash_> stevemar: I’m just leary of removing something we thought was important with zero input from deployers
18:25:21 <dolphm> dstanek: ++
18:25:24 <shaleh> do what jamielennox is proposing
18:25:26 <gyee> I don't always agree with dstanek, but not this time
18:25:29 <stevemar> samueldmq: i think henrynash_ is the only one on the fence
18:25:29 <samueldmq> stevemar: notmorgan: should we vote? shoud be quick
18:25:33 <ayoung> amakarov, I've never said that.  I always saw driver as internal code
18:25:42 <raildo> and who will do this? rderose? :D
18:25:51 <dolphm> henrynash_: we asked for input, we heard crickets
18:25:56 <notmorgan> dolphm: ++
18:25:58 <rderose> raildo: dstanek: volunteered
18:26:00 <henrynash_> I’ll certainly support the consenus
18:26:02 <ayoung> lets hold off on removing versioned drivers until after the next summit, and get it before the operators
18:26:07 <samueldmq> henrynash_: let's senf an email notifying the decision
18:26:11 <amakarov> ayoung, and we expose 'driver' parameter to config for people to override it
18:26:11 <raildo> rderose: dstanek awesome :)
18:26:11 <ayoung> its probably just busy work, but we have committed to it
18:26:15 <samueldmq> they will say something if they disagree
18:26:18 <notmorgan> and everyone who has complained to me previously have stopped doing custom drivers as i know
18:26:20 <samueldmq> at least this time :)
18:26:21 <dstanek> the question is whether we just drop all support of honor the existing contracts for a release
18:26:30 <henrynash_> dolphm: which meant they weren;t listeneing, didn’t get the question or don’t care…but we don;t know which
18:26:34 <ayoung> amakarov, I just saw that as a way to switch between existing ones in tree
18:26:36 <shaleh> dstanek: honor for at least a release
18:26:42 <dolphm> #info gyee doesn't always agree with dstanek, but not this time
18:26:48 <gyee> hahah
18:26:51 <shaleh> as ayoung says, we do not really know what is out there
18:27:00 <amakarov> ayoung, anyway, whoever customizes driver get a maintainance problem, and it's his problem :)
18:27:04 <stevemar> #startvote drop version driver support? Yes, No
18:27:05 <openstack> Begin voting on: drop version driver support? Valid vote options are Yes, No.
18:27:07 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:27:07 <notmorgan> announce the versions go away in O
18:27:11 <samueldmq> #vote Yest
18:27:12 <openstack> samueldmq: Yest is not a valid option. Valid options are Yes, No.
18:27:13 <samueldmq> #vote Yes
18:27:15 <bknudson> #vote Yes
18:27:16 <rderose> Yes
18:27:16 <samueldmq> oops
18:27:18 <notmorgan> #vote idontcare
18:27:19 <openstack> notmorgan: idontcare is not a valid option. Valid options are Yes, No.
18:27:21 <amakarov> #vote yes
18:27:21 <stevemar> #vote yes
18:27:22 <ayoung> wait...when?
18:27:22 <rderose> #vote yes
18:27:25 <dolphm> #vote Yes
18:27:26 <shaleh> #vote later
18:27:27 <openstack> shaleh: later is not a valid option. Valid options are Yes, No.
18:27:28 <henrynash_> #vote no
18:27:30 <ayoung> I want to do so eventually
18:27:34 <lbragstad> #vote yes
18:27:36 <jamielennox> #vote yes
18:27:36 <ayoung> is a yes vot for dropping immediately?
18:27:39 <raildo> #vote yes
18:27:40 <rodrigods> #vote yes
18:27:40 <dstanek> #vote more_yes_than_yes
18:27:40 <openstack> dstanek: more_yes_than_yes is not a valid option. Valid options are Yes, No.
18:27:43 <dolphm> #viteinfo
18:27:46 <samueldmq> dstanek: heh
18:27:47 <dstanek> #vote yes
18:27:47 <dolphm> #voteinfo
18:27:52 <notmorgan> dolphm: VITEINFO!
18:27:53 <stevemar> ayoung: yes means we just don't create new ones, and let the exisitng ones deprecate
18:27:55 <browne> #vote yes
18:27:59 <ayoung> #vote yes
18:28:00 <knikolla> #vote yes
18:28:00 <nisha_> #vote yes
18:28:00 <jamielennox> but i want to say there's really no rush to this
18:28:06 <dolphm> #showvote
18:28:07 <openstack> Yes (15): rodrigods, nisha_, lbragstad, ayoung, rderose, bknudson, browne, dstanek, samueldmq, jamielennox, knikolla, amakarov, dolphm, raildo, stevemar
18:28:08 <openstack> No (1): henrynash_
18:28:10 <stevemar> #endvote
18:28:10 <openstack> Voted on "drop version driver support?" Results are
18:28:11 <openstack> Yes (15): rodrigods, nisha_, lbragstad, ayoung, rderose, bknudson, browne, dstanek, samueldmq, jamielennox, knikolla, amakarov, dolphm, raildo, stevemar
18:28:12 <openstack> No (1): henrynash_
18:28:20 <henrynash_> (someone’s gotta stand out from the crowd)
18:28:27 <rderose> :)
18:28:27 <shaleh> henrynash_: ++
18:28:28 <bknudson> he's a wild duck.
18:28:28 <dstanek> if people end up not liking this then we can always start creating new versions
18:28:35 <stevemar> rderose: interpret what you may from the results :)
18:28:42 <samueldmq> nice, I think we can discuss about how we do it in -keystone
18:28:43 <stevemar> dstanek: lol
18:28:46 <henrynash_> ok, done…next topic!
18:28:55 <rderose> stevemar: ++ what, you mean henry hates me now
18:28:58 <shaleh> I just feel like wearing Monty's hat and saying operators might be bitten if we act too quickly
18:29:06 <stevemar> henrynash_: actually... i'm going to circle back to the previous one
18:29:08 <rderose> henry: beer is on me at mid
18:29:18 <stevemar> #topic Add resource name to the notification event
18:29:20 <notmorgan> shaleh: you should invoke mordred when putting on his hat
18:29:23 <gyee> rderose, do pay attention to who's walking behind you on the next summit
18:29:28 <henrynash_> redose: as the person who ended writing nealy all teh bl**dy wrappers, no I’m happy (in a perverse way!)
18:29:29 <stevemar> let's get a concrete action item out of this
18:29:32 <dolphm> rderose: follow up on your mailing list post with the outcome of this meeting
18:29:42 <stevemar> dolphm: good call
18:29:47 <rderose> dolphm: will do
18:30:04 <stevemar> so back to the whole names in audit events thing
18:30:05 <notmorgan> shaleh: (though i think he's in meetings all day)
18:30:13 <shaleh> notmorgan: yeah...
18:30:14 <samueldmq> dolphm: ++
18:30:21 <rderose> gyee: ++
18:30:37 <stevemar> i'm ok with adding the resource name and domain name
18:30:38 <rderose> henrynash: ++
18:30:40 <shaleh> stevemar: a) add names now b) move towards soft deletes
18:30:47 <notmorgan> shaleh: ++
18:30:51 <samueldmq> shaleh: ++
18:30:53 <gyee> ++
18:30:54 <stevemar> dolphm, you seem concerned
18:30:59 <samueldmq> maybe we should vote again ? :-)
18:31:01 <notmorgan> shaleh: but can we never call them "soft deletes" again ;)
18:31:12 <notmorgan> shaleh: just call them "deletes" ;)
18:31:16 <dolphm> stevemar: i'm in favor of A, with the caveat that names are not unique across domains, and we're not including domain references
18:31:17 <samueldmq> I think we should go to b) from now, that shouldn't be a hurry to add the name
18:31:33 <dolphm> stevemar: so i'm inclined to suggest we should just dump the full object into the cadf payload
18:31:41 <gyee> samueldmq, b) is quite a bit of work
18:31:41 <lbragstad> dolphm so keeping the notification payload reasonably sized, right?
18:31:58 <dolphm> lbragstad: not necessarily lol
18:31:59 <samueldmq> gyee: can't be done in this release or next ?
18:32:08 <jamielennox> i'm ok with adding names, with all the regular caveats that names can change and you should be storing ids
18:32:11 <notmorgan> gyee: it really isn't that much work. - also it buys us the "restore a deleted resource" option w/o needing magic "inject data into the db" commands
18:32:18 <samueldmq> gyee: in worst case it will get in next cycle (1 release after the name  can be added)
18:32:22 <notmorgan> for free.
18:32:26 <shaleh> jamielennox: if we log BOTH it is better than just ids
18:32:28 <gyee> samueldmq, not this release I don't think, but miracle do happen
18:32:36 <jamielennox> notmorgan: it's always the API that bugs me about that, how do you request a deleted project?
18:32:46 <raildo> we will still with name + id right? so this will be a unique combination across domains
18:32:50 <stevemar> dolphm: by "not including domain references" you mean the entire domain ref, we still need the domain name
18:32:50 <notmorgan> jamielennox: same way as with nova ?deleted=true
18:32:54 <jamielennox> shaleh: yes, logging both is fine
18:32:56 <shaleh> notmorgan: ++
18:33:13 <bknudson> the project was deleted, not the domain, so we only need the domain ID
18:33:14 <gyee> normorgan, that's not lifecycle managment, just a delete hack
18:33:22 <samueldmq> /v3/projects/<id>?RESSURRECT
18:33:29 <notmorgan> gyee: no it allows us to do lifecycle management
18:33:36 <notmorgan> gyee: right now... we don't really have that option
18:33:37 <shaleh> IFF IDS <-> mapping live forever we can just log IDs
18:33:38 <dstanek> jamielennox: not only that what if a project already exists with the deleted name...
18:33:41 <notmorgan> short of a custom driver.
18:33:41 <rderose> samueldmq: ++
18:33:44 <shaleh> until then we need both
18:33:50 <dolphm> stevemar: i do just mean the flat ref
18:33:56 <notmorgan> dolphm: i'm actually ok with just shoving all relevant data in cadf.
18:34:00 <ayoung> we have a lot more to discuss and we are half done
18:34:05 <notmorgan> dolphm: if we don't blow out a maximum size
18:34:08 <dolphm> stevemar: if the domain hasn't changed, you can cache your GET /domains/{domain_id} call
18:34:11 <stevemar> dolphm: the flat ref will have the domain_id in there, that's good enough for me
18:34:17 <ayoung> Perf, use requests, name constraints
18:34:23 <ayoung> Swift ACLs
18:34:38 <jamielennox> dstanek: notmorgan has explained his uniqueness theory before, it's a bit twisty but it would work
18:34:38 <notmorgan> ayoung: swift ACLs should just be a "go read the ML thread and comment"
18:34:46 <samueldmq> should we vote ? or is it just me wanting to do the delete thing now ?
18:34:49 <notmorgan> samueldmq: no
18:34:59 <jamielennox> no soft delete now
18:34:59 <shaleh> soft delete is step 2
18:35:02 <notmorgan> just do the name thing.
18:35:06 <stevemar> i think we're OK now, dolph -- you good?
18:35:08 <gyee> our resource objects arn't that big
18:35:10 <ayoung> step 3 is profit?
18:35:14 <shaleh> ayoung: always
18:35:25 <stevemar> flat ref in the notification?
18:35:26 <dolphm> stevemar: are we saying no to soft deletes in the application layer, then?
18:35:26 <notmorgan> the change on how deletes are handled (don't call it "soft deletes") should be a proposed spec for O release ( shaleh you should write this)
18:35:40 <stevemar> dolphm: ^
18:35:46 <notmorgan> dolphm: today. i want a spec for O on this
18:35:48 <notmorgan> not in newton
18:35:50 <notmorgan> not worth it
18:35:53 <stevemar> right
18:35:54 <notmorgan> too short of time
18:36:02 <jamielennox> notmorgan: you can fight this all you like and implement it how you like - but the concept is what people refer to as soft deletes
18:36:09 <notmorgan> jamielennox: shhhhhhh
18:36:22 <dolphm> i'm okay with saying no to soft deletes later then :P
18:36:23 <samueldmq> notmorgan: my concern is that we add name/domain-name now and that won't be removed we support those deletes
18:36:26 <samueldmq> next cycle
18:36:29 <stevemar> dolphm: lol
18:36:44 <samueldmq> notmorgan: s/we/when
18:36:46 <notmorgan> dolphm: i think we should do it for the main resources that "own" things, but that is a case to be made in the spec.
18:36:46 <stevemar> dolphm: alright, next topic? is this horse dead enough?
18:36:55 <dolphm> (i'm not entirely opposed to soft deletes, i'm just used to letting the db handle them)
18:36:59 <notmorgan> dolphm: not *all* resources.
18:37:01 <ayoung> Horse has been turned int dogfood and glue
18:37:12 <notmorgan> dolphm: and also i want the DB to handle most all of it still. ftr.
18:37:13 <dolphm> or *something* else besides the app
18:37:23 <stevemar> #topic Performance testing is available
18:37:28 <stevemar> lbragstad: you've got 3 minutes :P
18:37:29 <notmorgan> i'll work with shaleh to make the spec clear on that.
18:37:31 <ayoung> Perf testing of what?
18:37:32 <stevemar> i'm kidding
18:37:35 <lbragstad> well this is going to be short
18:37:39 <lbragstad> it's there, you can use it
18:37:45 <lbragstad> but im interested in feedback
18:37:50 <shaleh> lbragstad: this is a great start
18:37:50 <lbragstad> https://github.com/lbragstad/keystone-performance
18:37:52 <bknudson> we could use updates to the developer docs to say how to use this
18:37:56 <notmorgan> lbragstad: does it make sense to move into gerrit?
18:37:58 <notmorgan> my only question
18:38:03 <notmorgan> but awesome work
18:38:08 <lbragstad> notmorgan good question, maybe at some point
18:38:22 <gyee> lbragstad, nice handwriting!
18:38:29 <lbragstad> but right now I for sure what to improve things and make the whole system a bit better before moving it into gerrit
18:38:46 <raildo> lbragstad: thanks to be working on it! awesome work :)
18:38:48 <rderose> lbragstad: awesome
18:38:51 <lbragstad> so - feel free to use it, but it is only running on a single node
18:38:59 <lbragstad> so don't add 'check performance' to every patch in review
18:39:06 <stevemar> lbragstad: so it's the same machine every time?
18:39:09 <lbragstad> yes
18:39:10 * notmorgan makes a bot for that
18:39:14 <lbragstad> using containers as the app node
18:39:17 <notmorgan> lbragstad: did you get a proper 3rd party ci account?
18:39:20 <lbragstad> yes
18:39:24 <notmorgan> ok cool
18:39:29 <lbragstad> it's call the 'OSIC Performance Bot'
18:39:31 <samueldmq> how's that different from rally ?
18:39:38 <lbragstad> because I can't name things for crap
18:39:58 <lbragstad> it's running on dedicated hardware
18:40:01 <notmorgan> samueldmq: a lot of history, lets not cover that here
18:40:02 <jamielennox> samueldmq: much more focused on the hot path we care about
18:40:18 * samueldmq nods
18:40:26 <lbragstad> if you have specific questions, please ask
18:40:42 <lbragstad> but I'd like to try and get this improved and exposed to a bunch of feedback this release
18:40:47 <stevemar> lbragstad: so how do i invoke the perf tests on a given patch?
18:40:56 <shaleh> read the docs stevemar
18:41:02 <lbragstad> leave a comment with 'check performance'
18:41:06 <ayoung> cool
18:41:06 <lbragstad> in the message
18:41:19 <henrynash_> nice
18:41:20 <stevemar> shaleh: i did, i was just trying to force lbragstad to write it out in the meeting for everyone's convenience
18:41:28 <shaleh> stevemar: :-)
18:41:31 <stevemar> ;)
18:41:35 <stevemar> lbragstad: awesome stuff
18:41:35 <samueldmq> stevemar: shaleh :-)
18:41:38 <henrynash_> hey siri…check...
18:41:40 <bknudson> write a bitcoin miner and recheck performance.
18:41:44 <gyee> lbragstad, so benchmark spit out a html/pdf report?
18:41:45 <lbragstad> i've also tried to add a bunch of docs about the infra.
18:42:08 <stevemar> so, let's use it !
18:42:10 <lbragstad> so - open issues if you find anything is missing
18:42:15 <stevemar> thanks lbragstad
18:42:19 <lbragstad> or want to see enhancements,
18:42:21 <bknudson> this is great
18:42:21 <lbragstad> no problem.
18:42:27 <knikolla> awesome work!
18:42:29 <lbragstad> PRs welcome
18:42:31 <lbragstad> :_
18:42:32 <stevemar> next topic jamielennox
18:42:33 <bknudson> I've been looking at performance problems for a couple weeks now.
18:42:34 <lbragstad> :)
18:42:43 <stevemar> #topic Use a request object in keystone
18:42:51 <jamielennox> ok, i'll keep this quick
18:42:54 <jamielennox> #link https://review.openstack.org/#/c/318658/
18:42:57 <ayoung> what is the difference between a request and a context
18:42:58 <bknudson> what's the performance impact of using a request object in keystone?
18:43:11 <stevemar> bknudson: leave a comment on the patch and see :O
18:43:11 <ayoung> bknudson, premature optimization...
18:43:28 <shaleh> stevemar: ++
18:43:33 <jamielennox> so we've passed around this weird dict of context forever now and it results in all this checking whether things are in the dict or not and making guesses
18:43:35 * notmorgan checks performance on all the patches!
18:43:45 <jamielennox> particularly given we end up passing the environment around everywhere in that dict anyway
18:44:00 <notmorgan> jamielennox: i like using the real request objects
18:44:00 <jamielennox> we need to integrate better with oslo.context and the objects passed down out of auth_token middleware
18:44:00 <ayoung> its better organization, I'll admit.  Do we need to structure things more than just "request has a context dict" over time?
18:44:03 <bknudson> doesn't every openstack app pass around a dict of context?
18:44:08 <ayoung> and if so, what doe the end state look like?
18:44:21 <jamielennox> so instead of just adding more crap to the dict i want to use real objects - with properties and stuff for attributes we care about
18:44:24 <notmorgan> bknudson: somewhat, but a lot of it is now centralized in oslo_context (thread local things)
18:44:34 <dstanek> jamielennox: as long as request objects don't bleed lower than the controllers, then i'm on board
18:44:54 <ayoung> https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequest.html
18:44:55 <samueldmq> notmorgan: couldn't we just use oslo.context then ?
18:44:57 <bknudson> we've got a oslo_context.RequestContext (was added for request ID)
18:45:08 <notmorgan> bknudson: and we use it for the request_local caching too
18:45:09 <jamielennox> so this patch is kind of big because it has to do a lot of router/controller level stuff in one go, but things beyond that should be normal review size again
18:45:27 <ayoung> the general pattern in Servlet programming was that you only read from the request, and write new data tothe response
18:45:31 <notmorgan> bknudson: so we could just use oslo_context
18:45:37 <jamielennox> dstanek: i see no reason for them to go futher than context does now
18:45:37 <amakarov> samueldmq, it will add even more spagetti code
18:45:48 <ayoung> and state was saved ewither in the session (which we have none) and the database
18:45:55 <dstanek> jamielennox: +2 from me then
18:46:13 <ayoung> so...why only a request object, and not a response?
18:46:13 <stevemar> i'm OK with it, i always found the way we pass the context around a bit weird
18:46:19 <samueldmq> amakarov: so other openstack projects adoption oslo.context are making spaghetti code ?
18:46:28 <dstanek> samueldmq: yes
18:46:31 <amakarov> samueldmq, I think so
18:46:34 <ayoung> yeah....jamie this is long overdue
18:46:40 <jamielennox> anyway, i want to make it so that everyone knew about this and there are a number of conflicting reviews so i would like to get this merged if we all agree
18:46:43 <dolphm> ayoung: next step?
18:47:02 <samueldmq> jamielennox: ++
18:47:08 <stevemar> henrynash_: you'll have the rest of the time for your topic
18:47:19 <jamielennox> ayoung: because ATM i need more access to the inputs and haven't had to worry about the writing
18:47:24 <stevemar> jamielennox: sounds good
18:47:35 <henrynash_> stevemar: thx
18:47:37 <stevemar> jamielennox: sounds like everyone is okay with it
18:47:42 <jamielennox> ayoung: but i'm silently keen to change up all the routers as well one day
18:47:43 <ayoung> its a start
18:47:53 <dolphm> jamielennox: flask?
18:48:04 <ayoung> I want a proper token/auth-data pipeline
18:48:06 <notmorgan> dolphm: ++
18:48:06 <stevemar> next topic coming up
18:48:12 <notmorgan> dolphm: yes flask!
18:48:14 <dolphm> brace yourselves
18:48:16 <stevemar> #topic Project name constraints & project hierarchical naming
18:48:19 <jamielennox> dolphm: i looked and it's just a massive change that requires rewriting all the protected stuff
18:48:21 <henrynash_> ok
18:48:21 <stevemar> brace yourselves is right
18:48:31 <jamielennox> dolphm: this at least gets us to request objects which is a step in the direction
18:48:33 * stevemar sits back and grabs popcorn
18:48:38 <dolphm> jamielennox: ++
18:48:42 <raildo> stevemar: lol
18:48:45 <henrynash_> so we;ve been hashing this one around a while
18:48:45 <dolphm> stevemar: scoot over
18:48:57 <dstanek> jamielennox: take a look at my flask patch - it wasn't terrible to do
18:48:59 * notmorgan has nothing else to add that isn't on the ML/talked with henrynash_ directly
18:49:09 <henrynash_> (more accurately morgan has been knockig holes in various suggestions!)
18:49:17 * gyee is comfortable numb
18:49:21 <stevemar> https://media.giphy.com/media/qR6UR8K1Ia2BO/giphy.gif
18:49:23 <henrynash_> latest incarnation is https://review.openstack.org/#/c/318605/
18:49:51 <henrynash_> which goes for the “make project name the path” approach
18:49:52 <shaleh> are we gonna -2 this or not? Is there anything left to say?
18:50:03 <amakarov> dstanek, for me flask is better than the pylons legacy we call routers now :)
18:50:14 <stevemar> i'll admit i haven't read the latest ML posts
18:50:29 <henrynash_> as described, I think this does not allow us to maintain compatibility with v3.6 clients and before
18:50:51 <ayoung> henrynash_, we can't config value our way out of this hole?
18:51:06 <notmorgan> ayoung: not really
18:51:07 <dstanek> amakarov: i'm going to bring back that patch
18:51:11 <stevemar> henrynash_: did someone poke a hole in clint's suggestion? name and basename?
18:51:25 <notmorgan> stevemar: doesn
18:51:31 <stevemar> it seemed the least breaky to me
18:51:40 <gyee> what's stopping V4?
18:51:41 <notmorgan> solve the unique name constraing in 3.6
18:52:08 <dolphm> stevemar: isn't that eventually backwards incompatible?
18:52:16 <notmorgan> stevemar: unless you never expect post 3.7 projects to 3.6
18:52:22 <henrynash_> stevemar: so I articulated the compatibilit requiremenets in a reponse on the mailing list, I don’t see how we maintain 3.6 cleints
18:52:23 <notmorgan> expose*
18:52:25 <notmorgan> dolphm: yes.
18:52:35 <dolphm> well, then, hole poked.
18:52:41 <henrynash_> with that approacj
18:52:45 <stevemar> dolphm: very much so
18:52:49 <notmorgan> dolphm: it was the same hole i poked in removing 3.6 at all
18:52:49 <amakarov> gyee, we haven't dragged OpenStack from v3 to v3 yet, and now you want to announce v4? People will linch us!
18:53:00 <stevemar> amakarov: also true
18:53:00 <amakarov> s/v3/v2/
18:53:01 <henrynash_> no v4 required
18:53:15 <rderose> amakarov: ++
18:53:19 <henrynash_> so two questions for y’all to ponder:
18:53:40 <notmorgan> henrynash_: "full name" also might be a good attr instead of "path" ?
18:53:44 <notmorgan> henrynash_: side thought.
18:53:45 <samueldmq> that's all because we hadn't the full roadmap when we first implemneted hierarchical projects :(
18:53:49 <notmorgan> henrynash_: but that is bike-shedding
18:53:57 <samueldmq> :(
18:54:05 <henrynash_> 1) Since this is the only cure we could come up with (that maintains compatility), is the cure still worse than the disease?
18:54:06 <notmorgan> samueldmq: even if we had, we'd have broken a TON of people
18:54:14 <notmorgan> samueldmq: and it would still be a no-go
18:54:37 <ayoung> I can't keep track of the objections and the counter solutions
18:54:38 <notmorgan> i strongly believe that the reseller case is better with domains
18:54:56 <henrynash_> 2) (much more minor) severel questions on consistency in the current proposal (e.g. should you be abel to use name including a path on create project)
18:54:56 <notmorgan> and de-uniquing the names in a given domain doesn't provide a lot on that front
18:55:00 <samueldmq> notmorgan: maybe it wouldn't break that much if we made hierarchical project experimental and come with this in the next cycle
18:55:09 <samueldmq> notmorgan: but nevermind, let's solve what we have today
18:55:09 <notmorgan> samueldmq: it breaks auth
18:55:13 <notmorgan> samueldmq: that is the issue.
18:55:22 <ayoung> we could go with ldap style naming  "domain=pepsi,project_name=top,project_name=middle"
18:55:27 <dolphm> (let's not break auth)
18:55:38 <samueldmq> notmorgan: because root projects now have a parent (is_domain ?)
18:55:38 <amakarov> henrynash_, closure table can be used to identify projects without unique naming and storing full path in the name
18:55:39 <notmorgan> ayoung: thats basically what i've proposed, just with / instead
18:55:40 <ayoung> sorry, we need to make that longer
18:55:44 <ayoung> we could go with ldap style naming  "domain_name=pepsi,project_name=top,project_name=middle"
18:55:50 <notmorgan> samueldmq: i'll go over that outside of here
18:56:04 <ayoung> so  "domain_name=pepsi/project_name=top/project_name=middle"
18:56:13 <gyee> ayoung, UX people will look for ya
18:56:15 <jamielennox> ayoung: no, never
18:56:25 <stevemar> yeesh
18:56:25 <henrynash_> OK, back to the question
18:56:27 <notmorgan> ayoung: that is effectively my proposal fwow, but was domain/px/py/pz
18:56:30 <amakarov> ayoung, let's writhe our own LDAP!
18:56:31 <ayoung> jamielennox, scared at how quick people take me seriously
18:56:35 <shaleh> ayoung: that is too convenient. Make it more cumbersom please
18:56:38 <bknudson> what if my name was domain_name=pepsi/project_name=top ?
18:56:41 <notmorgan> ayoung: since domains are always the root.
18:56:42 <amakarov> write
18:56:43 <ayoung> shaleh, XML?
18:56:44 <jamielennox> ayoung: this was erring on the side of caution
18:56:51 <ayoung> heh
18:56:52 <shaleh> ayoung: good start
18:57:05 <henrynash_> Assuming you agree that we CAN solve this, without breaking compatibility (as per the current poposal https://review.openstack.org/#/c/318605/), is this worth doing
18:57:26 <ayoung> so  OS_PROJECT_NAME="domain/pepsi/top/middle" would work for scoping a token
18:57:37 <ayoung> henrynash_, oh yes it is
18:57:44 <amakarov> henrynash_, we don't need it: https://review.openstack.org/#/c/285521/
18:57:54 <henrynash_> ayoung: yes (although with a leading /)
18:58:02 <gyee> yes we can, lets make it great again, a future we believe in
18:58:05 <ayoung> OS_PROJECT_NAME="/domain/pepsi/top/middle" would work for scoping a token
18:58:09 <amakarov> henrynash_, do you want materialized path with names?
18:58:12 <henrynash_> ayoungL yes
18:58:23 <henrynash_> amakaraov: implmentation detail
18:58:25 <notmorgan> ayoung: that would be the idea. it would match "name" or "path"
18:58:30 <ayoung> henrynash_, and what hoops do we need to jump throughto get there
18:58:32 <notmorgan> ayoung: in the case of old projects.
18:58:47 <notmorgan> ayoung: since some projects might be "ProjectName" only
18:58:49 <stevemar> this is getting nasty
18:59:05 <stevemar> voice opinions on the ML or https://review.openstack.org/#/c/318605/ (or both)
18:59:13 <ayoung> notmorgan, /domain becomes a reserved project name?
18:59:18 <notmorgan> stevemar: i don't think we need this, but i offered an alternative when i poked holes in it
18:59:18 <jamielennox> so, i don't know how to say this better - but it's just not nice
18:59:27 <ayoung> not allowed as either project or domain, or as the start of either?
18:59:37 <notmorgan> ayoung: no /<domainname>/<projextName>/<otherProject>
18:59:38 <stevemar> notmorgan: that's my next question, do we need this?
18:59:44 <amakarov> colleagues, closure table will allow to address project by path, index hierarchies, and leave project name be
18:59:50 <stevemar> but we're at time...
18:59:53 <notmorgan> stevemar: i don't think we need it. but there is a ux concern
18:59:55 <stevemar> to -keystone
19:00:06 <notmorgan> some orgs want /domain/acc/dev
19:00:09 <ayoung> notmorgan, so first link is alwyas domain?
19:00:09 <stevemar> thanks to everyone for joining
19:00:10 <notmorgan> and /domain/ops/dev
19:00:15 <stevemar> #endmeeting