17:59:40 <stevemar> #startmeeting keystone
17:59:41 <openstack> Meeting started Tue Nov 24 17:59:40 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:44 <openstack> The meeting name has been set to 'keystone'
17:59:49 <lbragstad> stevemar o/
17:59:53 <stevemar> ping ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC
17:59:54 <davechen> o/
18:00:00 <raildo> olá o/
18:00:07 <amakarov> hey!
18:00:09 <breton> o/
18:00:12 <marekd> hi
18:00:19 <navid_> o/
18:00:24 <henrynash> ’tis the season to be merry....
18:00:30 <henrynash> oh, no, that’s later
18:00:34 <ajayaa> o/
18:00:43 <dstanek> henrynash: this season makes me grumpy
18:01:03 <samueldmq> oi :)
18:01:05 <henrynash> dstanek: you be grumpy, I’ll be sneezy
18:01:06 <stevemar> #topic Mid-cycle survey
18:01:11 <xek_> o/
18:01:19 <david8hu> \o
18:01:29 <stevemar> check the mailing list http://lists.openstack.org/pipermail/openstack-dev/2015-November/080299.html
18:01:35 <stevemar> theres a survey please fill it ou!t!
18:02:02 <stevemar> any questions about mid cycle?
18:02:09 <bknudson> sorry to tell you this, but Winterfell has been destroyed
18:02:20 <stevemar> bknudson: shhh spoilers!
18:02:23 <lbragstad> spoiler alert!
18:02:24 <dstanek> i should have written in Cleveland for location
18:02:59 <stevemar> so no questions :)
18:03:03 <davechen> has filled.
18:03:10 <henrynash> stevemar: filed
18:03:17 <stevemar> ty davechen and henrynash
18:03:29 <stevemar> gonna skip the next topic
18:03:34 <stevemar> #topic Backend driver versioning
18:03:36 <stevemar> henrynash: its all you
18:03:40 <henrynash> ok
18:03:59 <henrynash> so i happen to have to be the person to write the first new driver version
18:04:10 <henrynash> https://review.openstack.org/#/c/242853/
18:04:39 <henrynash> but dtsanek and I have been debating exaclty how this should work…and more importantly what the goals
18:04:40 <henrynash> are
18:04:52 <henrynash> see his thoughts here: https://gist.github.com/dstanek/756337141e5e0066ebce
18:05:31 <henrynash> question 1: Is the main goal of driver versioning to ensure we can update to a release and someones customer driver still works?
18:05:54 <dstanek> some of this we knowingly deferred because of time constraint to get versioning into the L release and we didn't know all the issues that would come up
18:05:55 <bknudson> that's the goal
18:06:12 <bknudson> why was there a time constraint to get versioning into L?
18:06:30 <bknudson> we'd rather get some code in rather than get the right code in?
18:07:20 <henrynash> bknudson: I don’t the code was necessarily wrong, just that I don’t think anyone fully thought out eactly HOW we would create a new version!
18:07:23 <dstanek> bknudson: no, it's not about right code. these are things that need to be decided when creating the first updated version
18:08:00 <henrynash> I’ll lay out the two extremes
18:08:02 <dstanek> bknudson: we talked about some of the things i listed in my gist, but decided we could defer since they don't change the overall stragegy
18:08:05 <dstanek> or strategy
18:08:15 <henrynash> extreme support says:
18:08:35 <henrynash> 1) We keep the current driver and the n-1 driver in tree, all the code etc.
18:09:00 <bknudson> we're going to need the n-1 driver for testing
18:09:14 <henrynash> 2) We support different SQL models between the drivers, if teh new one has changed
18:09:35 <bknudson> SQL model assumes the driver is SQL... not sure what that has to do with it
18:09:49 <henrynash> 3) we (somehow) allow db_sync to be directed to upgrade to the right model based on driver version choice
18:10:11 <dstanek> bknudson: the current review copies the old SQL driver (including model) so that someone can use it if they wanted
18:10:12 <bknudson> how did SQL get mixed in with this?
18:11:03 <henrynash> bknudson: so I am assuming (maybe incorrectly) that custom drivers are not necessarily just differnet backend technologies, but could be a modified version of our own SQL driver, say
18:11:11 <dstanek> bknudson: essentially all of our V8 assignment drivers are being supported for one more release; i would rather not do this and just support the V8 interface
18:11:24 <bknudson> the database schema is for the keystone sql driver. If someone wants a custom driver that uses their own database schema then they need to write their own migrations and models
18:11:47 <bknudson> y, it's just the interface that we say is supported
18:11:57 <lbragstad> but what if we change the shema and the new version wants to use the new schema?
18:12:02 <bknudson> that implies the old drivers will still work.
18:12:15 <bknudson> (in the SQL case, the old drivers with our old schema)
18:12:16 <dstanek> lbragstad: i address that in the gist
18:12:26 <dstanek> adapt the old driver
18:12:34 * stevemar is back
18:12:35 <lbragstad> dstanek ah, gotcha
18:12:46 <notmorgan> the versioned drivers was really about the interface itself that keystone communicates to.
18:13:07 <notmorgan> if the backend datastore has to change, you need to adapt t it. but the driver interface keystone expects would remain consistent
18:13:16 <henrynash> bknudson, notmorgan: Ok, so that’s a useful clarification….and I think this get’s much simpler in thatcase
18:13:29 <notmorgan> if somoene is subclassing the SQL driver and we change the schema... thye kindof are on their own there - there be dragons
18:13:58 <ayoung> henrynash, its to keep people from me doing things like breaking Dreamhost's custom in house Identity driver
18:14:06 <ayoung> again
18:14:11 <notmorgan> but in reality, i expect someone to write their own (mongo?) data store for this, and therefore wouldn't hit the "the schema changed" issue
18:14:27 <notmorgan> or the like
18:15:05 <dstanek> sounds like most agree with the concepts from my gist then.... if that's the case i'll put the content into our documentation to clarify this
18:15:22 <henrynash> notmorgan: and I agree with that….and if we are all agreed that we are NOT trying to ensure someons sub-classed n-1 SQL driver will magically work, then I think we have a clearer way forward
18:15:32 <henrynash> dtsanek: agreed
18:15:33 <ayoung> notmorgan, henrynash so, to make explicit;  we will start a new version of a driver at the start of a cycle (or when required) and that version will stay open for changes for the durecation of that release, to be closed to modification upon RC1?
18:15:41 <bknudson> so the manager is going to have to check if the driver is V8 and if so insert the adapter
18:15:56 <notmorgan> henrynash: aboslutely on point - never try and be magical with the datastore. if they subclass they take on the risks of subclassing
18:16:19 <henrynash> bknudson: yes
18:16:28 <dstanek> bknudson: i think that's the best approach. otherwise you'd sprinkle in versioned code all over the manager
18:16:38 <shaleh> notmorgan: we should be clear about that in comments and documentation
18:16:38 <topol> o/
18:16:43 <notmorgan> shaleh: yes
18:16:44 <dstanek> when V8 isn't supported then delete the V8 adapter
18:16:51 <notmorgan> dstanek: ++
18:17:12 <dstanek> shaleh: yes, post meeting i'll work on that
18:17:13 <henrynash> ok, I think we have agreement on direction…dstanek and I can take it from here
18:17:43 <dstanek> #action dstanek to update the documentation
18:17:48 <samueldmq> so all we need to have is a v(X-1) -> vX adapter (where X is the current version)
18:18:09 <samueldmq> but we also need to keep a copy of the old drivers (as you're doing) so tht we can test the adapter, right ?
18:18:12 <samueldmq> henrynash:  ^
18:18:33 <henrynash> samueldmq: yes, that is probably true…..
18:18:37 <stevemar> henrynash and dstanek thanks for championing this effort
18:18:46 <samueldmq> henrynash: nice
18:18:48 <samueldmq> stevemar: ++
18:18:57 <dstanek> samueldmq: keeping the copy is a case by case, i think. we need enough to guanarantee the adapter works to fulfill the contract
18:19:27 <stevemar> next topic time
18:19:31 <dstanek> i'd rather not over constrain because that may stop good ideas from appearing
18:19:37 <ayoung> notmorgan, henrynash so, to make explicit;  we will start a new version of a driver at the start of a cycle (or when required) and that version will stay open for changes for the durecation of that release, to be closed to modification upon RC1?
18:19:47 <ayoung> I'd like a yay/nay on tyhat
18:19:48 <ayoung> that
18:19:50 <samueldmq> dstanek: I agree... if we are just removing some methods (this case) perhaps we don't need a copy, but I'd take that as the general rule for simplicity
18:19:59 <henrynash> ayoung: yes (although RC1 or M3 might be debatable)
18:20:05 <ayoung> agreed
18:20:07 <dstanek> ayoung: yes
18:20:14 <ayoung> thanks
18:20:14 <stevemar> ayoung: i think that is agreeable
18:20:50 <stevemar> #topic Call for keystone-spec reviews
18:20:53 <ayoung> HMT time?
18:20:59 <ayoung> Ah...
18:20:59 <stevemar> ayoung: this will be quick
18:21:08 <dstanek> hyper multi threading?
18:21:19 <stevemar> please review specs! if you do, i will buy you beer and puppies
18:21:29 <notmorgan> dstanek: hypercube magical time?
18:21:34 <dstanek> sold!
18:21:36 <stevemar> Mitaka-1 ends around Dec 1-3
18:21:37 <lbragstad> stevemar i'll hold you to that!
18:21:43 * notmorgan throws peanuts at stevemar
18:21:45 <henrynash> stevemar: action: stevemar to buy beer and puppies
18:22:07 <stevemar> notmorgan: i think we usually have a spec freeze after m1?
18:22:07 <xek_> lbragstad, I think I addressed your comments in the online schema migration spec
18:22:09 <dstanek> stevemar: is that 1 beer per review (or 2)?
18:22:11 <lbragstad> I'll take a chocolate lab and a IPA, please
18:22:27 <notmorgan> stevemar: i always drove for that freeze
18:22:28 <marekd> dstanek: depending if you voted abs(1) or abs(2)
18:22:30 <lbragstad> xek_ awesome, I'll be sure to take another look today
18:22:33 <stevemar> *amounts of beer and puppies are up for debate later
18:22:35 <notmorgan> stevemar: but you're the PTL you get to make policy here :)
18:22:35 <stevemar> notmorgan: cool
18:22:41 <stevemar> so we'll keep it the same :)
18:22:45 <dstanek> stevemar: there are lots of old specs
18:22:46 <stevemar> m1 is spec freeze
18:22:52 <stevemar> dstanek: there are
18:22:59 <ayoung> M1 Will work for me, but then, I've pushed my specs through already, so that would be selfish of me
18:23:05 <stevemar> i've tried to highlight ones here: https://gist.github.com/stevemart/46d664e486e2edce4972
18:23:12 * notmorgan is not submitting specs...sooo
18:23:13 <topol> stevemar when is m1 again?
18:23:18 * notmorgan has no horse in this race
18:23:18 <marekd> dec 3
18:23:19 <stevemar> topol: dec 1-3
18:23:20 <dstanek> should we abandon without prejudice?
18:23:33 <notmorgan> dstanek: i like abandoning with predjudice
18:23:41 <stevemar> dstanek: if you feel the need, go ahead
18:23:51 <topol> well now I know how I am spemding my thanksgiving... reviewing!
18:23:54 <ayoung> dstanek, all specs should be proposed against backlog.  We can always approve backlogged specs, just they don't get commitmnet for Mitaka
18:23:56 <stevemar> i would like it if we concentrated on ones we spoke about at the summit
18:23:57 <dstanek> stevemar: great. i'll go ahead to walk you gist and get reviewing
18:24:03 <notmorgan> topol: you know you'd do it anyway (and you like it)
18:24:22 <topol> notmorgan :-)
18:24:29 <stevemar> prioritize specs that are targeting mitaka and not backlog
18:24:51 <ayoung> BTW. Can I get a vote on https://review.openstack.org/#/c/244694/  and, if the team agrees to it, I willremove the -2
18:24:53 <dstanek> ayoung: yeah, we just have to decide if it's something that we'd want to support
18:25:04 <breton> stevemar: that's a freeze for mitaka/, not for backlog, right?
18:25:16 <stevemar> breton: yep
18:25:23 <breton> great
18:25:28 <dstanek> topol: i have family stuff. so yeah, reviewing will keep me sane
18:25:45 <stevemar> thank you for your reviews in advance :)
18:26:07 <lbragstad> ayoung dstanek I had a bunch of questions on that one
18:26:10 <davechen> is the spec from backlog approved , still can get the code in?
18:26:11 <topol> buckeyes lost, yellow jackets stink.   football season is over anyway
18:26:36 <stevemar> okay, HMT time, i'll give you guys a heads up when it's wrap up time, there is a lot on the list
18:26:42 <ayoung> ok
18:26:48 <ayoung> short bit on HMT:
18:26:53 <stevemar> #topic Hierarchical Naming
18:26:56 <ayoung> We make it possible to make URLS out of the names
18:27:01 <stevemar> davechen: depends on the impact
18:27:12 <davechen> gotcha.
18:27:15 <ayoung> to do that, a domain (and  possibley prject) name is URL safe
18:27:16 <marekd> ayoung: ++
18:27:29 <stevemar> davechen: functional testing, np. huge function, mehh, we'll have to discuss :)
18:27:35 <henrynash> See proposal:  https://review.openstack.org/#/c/248083/
18:27:36 <ayoung> no / no @ no characters that mess up a URL scheme
18:27:45 <ayoung> we make it a config option to go strict
18:28:01 <ayoung> if you go strict, then all non-complying domains get disabled
18:28:04 <ayoung> its an opt in
18:28:05 <shaleh> ayoung: why not support &entity; style escaping?
18:28:19 <ayoung> but you need to opt in in order to get HTM naming
18:28:29 <samueldmq> henrynash: ayoung: what's the advantage of making names URL-safe ?
18:28:34 <bknudson> URLs use %xx
18:28:39 <samueldmq> is that we can easily pick a separator for representing the hierarhcy ?
18:28:49 <ayoung> shaleh, we can make that a potential porting technique, but the short is we don'
18:28:57 <shaleh> bknudson: right, thanks
18:28:58 <henrynash> samueldmq: so we can, eventually, say: auth on domain/projectA/projectB
18:29:03 <henrynash> or something liek that
18:29:16 <ayoung> t want to chage OS_DOMAIN_NAME, OS_PROJECT_DOMAIN_NAME env vras and the like, so the integration with everything else still works
18:29:19 <samueldmq> henrynash: so yes, we can easily pick / as the separator for representing the hierarchy
18:29:22 <marekd> henrynash: so a separator would be  hardcoded, say '/'
18:29:25 <ayoung> so if I have a domain named customers
18:29:31 <samueldmq> henrynash: that was my only remaining question  on that
18:29:39 <ayoung> I can make a domain named customers/pepsi and customers/coke
18:29:49 <shaleh> in general I like this proposal. But, there are sure to be people out there that it impacts. Which is why some form of escaping for existing coupled with checks on new would be a good idea.
18:29:50 <ayoung> and use that full name in the env vars etc
18:29:56 <dstanek> having a / as a separator feels like it would make routes hard to write
18:30:03 <henrynash> marekd: the current proposal does not specifiy what separator we use, just that we enbale that support in the future
18:30:28 <marekd> henrynash: i am talking long term - we would eventually choose something, probably '/'
18:30:38 <henrynash> marekd: sure
18:30:41 <raildo> I'd rather choose the separator as a config option
18:30:43 <ayoung> shaleh, since it would be a top level name...we might be able to work out some escaping, but the user would have to only use the escaped version
18:30:50 <notmorgan> i like using the ASCII Bell character as the delimiter...
18:30:51 <notmorgan> >.>
18:30:53 <shaleh> ayoung: agreed
18:30:54 <henrynash> raildo: thats fine, but not part of this spec
18:31:01 <ayoung> so  if they had red/hat  it would become red%whateverhat
18:31:22 <marekd> a dot is acceptable?
18:31:24 <shaleh> ayoung: we could provide library assistance for that easily enough
18:31:24 <raildo> henrynash: yeap, I know but I'm just saying :P
18:31:28 <ayoung> marekd, I think it is
18:31:30 <henrynash> the only thing this spec does is provide a path to get domains and projects to NOT use anu url reserved charcacters
18:31:44 <ayoung> you can do http://hostname/this.is.my.url
18:31:48 <samueldmq> henrynash: +1 from me
18:32:00 <topol> raildo would making the separator a config option make interoperability more problematic?
18:32:01 <ayoung> and a relatvie url with this.is.my.url/test.html
18:32:13 <marekd> ayoung: ++ i like dot as it more reflects dns
18:32:17 <ayoung> topol, its not the separateo that is up for discussion
18:32:26 <marekd> ayoung: ++
18:32:26 <ayoung> the domain nesting will be URL based
18:32:37 <henrynash> I would suggest, in the interests of time, we defere debate on teh separator itself…it is not part of the spec up for review here
18:32:42 <topol> ayoung  agreed but a question to ponder over turkey
18:32:50 <topol> agreed
18:32:55 <samueldmq> henrynash: ++
18:33:08 <dstanek> henrynash: ++
18:33:12 <raildo> topol: we can discuss later about it :)
18:33:19 <stevemar> so why was this not included in the initial HMT stuff?
18:33:21 <marekd> henrynash: ayoung ok, so i think it was not super clear from the spec that enabling this naming convention (names url safe) automatically disable non compliant domains/projects
18:33:22 <ayoung> henrynash, so, it sounds like you and I are in sync?  Let me know if  htere are any other goblins hiding that you've spirited out, ok?
18:33:22 <shaleh> as voice for the end-user, I like this spec we just need to make it easy on ops and users to comply
18:33:38 <ayoung> marekd, if not, we need to put it in bold and underline it
18:33:40 <stevemar> why are we just bringing it up now?
18:34:03 <ayoung> stevemar, we tried back then
18:34:05 <dstanek> henrynash: so are you wanting to encode names or force the name to be urlsafe?
18:34:08 <marekd> ayoung: that's my observation
18:34:14 <henrynash> marekd: it states that you can’t issue any tokens scoped by name to url-unsafe named projects/domains if you opt in
18:34:23 <ayoung> but I think we were thinking about it backwards...the realization was that it woudl be opt in, not that all current domains would work
18:34:25 <raildo> stevemar: he have discussed about it a lot of times here... and right now, we have a patch to handle with clash names,
18:34:30 <marekd> henrynash: maybe i missed it then.
18:34:32 <marekd> thanks
18:34:34 <henrynash> dtsanek: we make them only use url-safe names
18:34:57 <stevemar> so the point of this is so i can specify a nested project?
18:35:03 <marekd> hierarchy
18:35:10 <ayoung> marekd, I think we also need to make it explicit that domain nesting only works with url-safe names enabled
18:35:17 <marekd> ayoung: sure
18:35:17 <ayoung> stevemar, a nested domain
18:35:22 <topol> ayoung +++
18:35:22 <henrynash> stevemar: yes (or maybe even a nested domain, if we ever do that)
18:35:22 <samueldmq> stevemar: because we hadn't thought about it ? maybe the same case as we hand't tought about the inherited assignments and hierarchical projects properly
18:35:31 <dstanek> so basically something like: [a-zA-Z0-9\-_] and a few other chars?
18:35:32 <ayoung> stevemar, it might be extensible to nesting projcts, too, but that is a longer reach
18:35:32 <samueldmq> stevemar: maybe just a lack of eyes on that at the time :/
18:35:38 <ayoung> dstanek, I think so
18:35:48 <ayoung> we can start cautious, and then open it up
18:35:58 <ayoung> easier than being to permissive, as we've found
18:36:12 <topol> ayoung +++
18:36:13 <dstanek> iirc there are a lot of urlsafe chars
18:36:18 <stevemar> i'm just concerned about all these changes to our base API
18:36:20 <davechen> dstanek: ++
18:36:20 <dstanek> ayoung: totally agree
18:36:34 <ayoung> stevemar, no API changes here by default
18:36:34 <henrynash> dtsanek: yes, we exclude those specifed as reserved chars in the URL spec
18:36:44 <dstanek> stevemar: are there api changes or just new constraints for the data?
18:36:44 <ayoung> its opt in
18:36:59 <topol> hopefully just new constraints
18:37:12 <stevemar> ayoung: OK, not new API changes, but additional logic in the controller that handles those APIs
18:37:28 <henrynash> stevemar: not with the spec, no
18:37:31 <ayoung> sounds like we have a plan.  We can work the rest out in the review process. please prioritize.
18:37:50 <ayoung> I'm going to ask for a spec review exception for this right now.
18:38:01 <dstanek> FYI rfc3986 says: unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
18:38:05 <henrynash> stevemar: if we chose to extent auth to accept a hierarchy name, then yes, but only in trh processing of teh name field
18:38:07 <ayoung> I think we can parallelize the implementation with the spec, but don't want to rush it
18:38:18 <henrynash> dstanek: yep
18:38:19 <raildo> dstanek: nice
18:38:28 <ayoung> dstanek, I'm ok with starting with just those characters.
18:38:46 <shaleh> that brings us back to '/' as a separator. Is that an issue with routes?
18:39:04 <stevemar> shaleh: probably
18:39:11 <shaleh> '.' is an allowed character so we cannot use that
18:39:24 <ayoung> shaleh, yes, but we can make it work.
18:39:35 <dstanek> we could use ,
18:39:38 <topol> ayoung how?
18:39:51 <shaleh> dstanek: eeewww, visually hard to make out
18:40:06 <topol> shaleh, I agree eeeww
18:40:10 <ayoung> topol, its python code.  Its only going to be one API.  I don't know *how* but I know we *can*
18:40:11 <dstanek> shaleh: then ..,.?
18:40:23 <shaleh> '|' is always popular
18:40:26 <ayoung> but we can make the mapper code deal with a/b/c/d
18:40:40 <dstanek> shaleh: we'd have to encode that
18:40:53 <stevemar> defer the conversation about the delimiter
18:40:57 <stevemar> we've got a full list
18:41:01 <shaleh> fair
18:41:02 <henrynash> again, let’s not debate the separator….we get to chose any url reserverd cahr
18:41:07 * notmorgan votes ಠ_ಠ as the delimiter
18:41:08 <dstanek> we should debate this with the spec that proposes the delimiter!
18:41:08 <topol> agreed
18:41:20 <notmorgan> (that was commentary on the convo needs to move on btw)
18:41:20 <ayoung> what do you guys mean delimeter?
18:41:33 <stevemar> #topic filtering service providers with endpoint filter
18:41:33 <ayoung> (continue after meeting in #Keystone)
18:41:36 <bknudson> we don't have nested domains really so no need for delimiter
18:41:37 <stevemar> marekd: ^
18:42:02 <stevemar> is there something that needed to be hashed out here instead of the spec?
18:42:02 <notmorgan> bknudson: ++ no nested domains.
18:42:33 <marekd> ok
18:42:33 <stevemar> is marekd online?
18:42:33 <henrynash> bknudson: there are plentt of reasons to do this, ignoring the domain issue
18:42:38 <marekd> i am
18:42:48 <marekd> https://review.openstack.org/#/c/188534/8/specs/backlog/service-providers-filters.rst so for this spec
18:42:56 <stevemar> marekd: the podium is yours
18:43:22 <dstanek> with HMT don't we get nested domains?
18:43:54 <marekd> some reviewers inclined endpoint filtering might be not "ready to use" as service_providers are not in the service catalog. Just wanted to hear your opinions - maybe we should just add another api and make it work as we would like to from the beginning?
18:44:04 <dstanek> oh, wait no.. nm me
18:44:43 <stevemar> hmm, they aren't in the service catalog are they
18:44:49 <marekd> they arent
18:44:53 <notmorgan> didn't we add them to the top level?
18:45:00 <marekd> notmorgan: we did
18:45:00 * notmorgan might be misremembering
18:45:26 <stevemar> they are in the token body, at the same level as the service catalog, i think
18:45:27 <shaleh> marekd: I like the idea of a filter for them. I am just not sold that endpoint filtering is the way to go.
18:45:59 <marekd> shaleh: cool, so this is the perfect timing for a discussion :)
18:46:19 <shaleh> marekd: agreed :-)
18:46:39 <bknudson> unscoped tokens don't include the service providers?
18:46:42 <marekd> i personally thin an admin should be able to tie a service provider with a project, domain (for domain scoped token) but also "all projects in a domain"
18:46:59 <dstanek> seems like a new service provider filtering concept
18:47:06 <marekd> bknudson: notremembering now, but today we simply fetch all service providers and return them in the token response.
18:47:19 <marekd> so this might also be athe case for unscoped token
18:47:32 <bknudson> so for unscoped tokens there's nothing to filter on.
18:47:34 <ayoung> marekd, only list SPs for Unscoped?
18:47:41 <bknudson> maybe the projects that the user has roles on
18:47:54 <marekd> ayoung: you don't want to list all sps to everyone
18:48:09 <marekd> you don't want your pepsi clients expose that coke is your client too
18:48:14 <ayoung> correct.  So unscoped seems like the wrong abstraction
18:48:15 <lbragstad> ++
18:48:21 <marekd> you dont want them think they may burst there...
18:48:29 <ayoung> its public vs private Idps, just for K2K
18:48:35 <shaleh> ayoung: ++
18:48:40 <stevemar> ayoung: seems like it
18:48:51 <marekd> ayoung: more or less....(less)
18:49:00 <ayoung> so...they should be associated with proejcts
18:49:04 <marekd> yes
18:49:09 <ayoung> which is what endpoint filtering is doing
18:49:18 <marekd> but also domains and "all projects in a domain"
18:49:32 <ayoung> so...lets expand that API to handle SPs seems like the most sane approach?
18:49:37 <shaleh> but how are you associating a SP's endpoint with an IdP's project?
18:49:40 <bknudson> did endpoint filtering ever get expanded to domains?
18:49:45 <stevemar> marekd: i'm okay with abusing endpoint filtering for service providers
18:50:00 <ayoung> lets not expand anything to domains that we don't have to
18:50:08 <marekd> stevemar: so extending it, right?
18:50:14 <stevemar> marekd: yeah
18:50:18 <bknudson> it might happen automatically when we change domains to projects
18:50:23 <marekd> stevemar: cool
18:50:46 <marekd> ah, pity samuel is not here
18:50:47 <lbragstad> ~ 10 minutes left
18:50:47 <stevemar> marekd: are the API changes and spec changes in the same patch?
18:50:53 <marekd> stevemar: not yet
18:50:53 <stevemar> thanks lbragstad
18:51:04 <ayoung> bknudson, ++
18:51:05 <marekd> stevemar: i can add
18:51:12 <marekd> ok, dont want to use more tim.e
18:51:23 <stevemar> marekd: start writing them out, i'd be curious to see what happens as you go
18:51:27 <marekd> stevemar: OK
18:51:33 <stevemar> i think we might be mis-remembering something
18:51:34 <stevemar> anywho
18:51:42 <marekd> like?
18:51:48 <stevemar> marekd: not sure!
18:51:53 <stevemar> #topic Dropping python 2.6 support
18:51:56 <stevemar> bknudson
18:51:58 <dstanek> marekd: i'd love to see the documentation changes earlier than the code if possible...
18:52:04 <notmorgan> yes! drop it!
18:52:06 <bknudson> in case you missed the mailing list discussion
18:52:08 <notmorgan> make it go away
18:52:10 <notmorgan> >.>
18:52:11 <shaleh> die die die py26
18:52:16 <bknudson> infra stopped testing with py26
18:52:27 <stevemar> this seems like an easy one
18:52:30 <bknudson> and oslo libs already stopped advertising support for it
18:52:46 <bknudson> so there's some work to do in the repos to stop advertising support for 2.6
18:52:51 <stevemar> 1) get rid of the job, 2) clean tox.ini 3) clean up any py26 specific code we have (we probably have a lot)
18:52:58 <bknudson> if anybody wants to sign up to do it ...
18:53:02 <ayoung> DIE PYTHON2.6 DIE
18:53:04 <bknudson> otherwise I'll add it to my list
18:53:07 <davechen> is there anything left in keystone?
18:53:14 <notmorgan> stevemar: open a tracking bug for cleanup of this stuff i think
18:53:18 <stevemar> any takers? give bknudson a break to eat some turkey
18:53:20 <notmorgan> and then anyone can do it
18:53:23 <stevemar> notmorgan: that would be great
18:53:28 <dstanek> bknudson: i'll do some
18:53:29 <lbragstad> notmorgan ++
18:53:29 <davechen> iirc, py26 has been removed from dependency list.
18:53:29 <shaleh> bknudson: I can help out
18:53:35 <lbragstad> i can give a hand too
18:53:36 <breton> davechen: nope, keystone is py26-free
18:53:38 <notmorgan> and it can just have bits done at a time. i'll open the bug shortly
18:53:46 <lbragstad> navid_ around?
18:53:53 <navid_> yea
18:53:56 <bknudson> ok, I'll assume people are going to work on it. Add me to the reviews
18:54:03 <lbragstad> navid_ would that be something you're interested in, too?
18:54:04 <stevemar> just remember to use Partial-Bug: blah
18:54:09 <dstanek> bknudson: consider yourself added
18:54:18 <shaleh> stevemar: do we have a bug yet?
18:54:20 <stevemar> tjcocozz might be interested too :P
18:54:33 <stevemar> shaleh: not yet, notmorgan is opening one as we speak... err type
18:54:36 <navid_> @lbragtad: sure, we can discuss afterwards
18:54:38 <bknudson> there's plenty of examples in oslo repos
18:54:49 <stevemar> next!
18:54:53 <stevemar> #topic Reno for other repos
18:54:56 <stevemar> i don't want this
18:55:06 <stevemar> this is overkill for libraries
18:55:21 <stevemar> is oslo doing this? dhellmann dims_ ?
18:55:30 <bknudson> yes, oslo is doing this as far as I know
18:55:35 <stevemar> ughhhhhhh
18:55:39 <dims_> stevemar : we were talking about it. haven't decided yet
18:55:43 <stevemar> but i dont wannnaaaaa
18:55:43 <ayoung> If you kill a man in Reno, they don't send yo to Folsom St. Penn...yougo to jail in Nevada
18:55:46 <bknudson> e.g., https://review.openstack.org/#/c/249329/
18:56:00 <notmorgan> stevemar: https://bugs.launchpad.net/keystone/+bug/1519449
18:56:00 <openstack> Launchpad bug 1519449 in OpenStack Identity (keystone) "Remove Python 2.6 Support" [Low,In progress] - Assigned to Keystone Drivers (keystone-drivers)
18:56:00 <lbragstad> stevemar we only want to use reno for keystone server?
18:56:03 <bknudson> oh, the discussion is ongoing
18:56:07 <dims_> bknudson : see the -W
18:56:09 <dims_> y
18:56:15 <stevemar> thanks notmorgan
18:56:33 <ayoung> link to "why reno?" please.
18:56:45 <stevemar> bknudson: let's wait and see what comes out from the oslo discussion
18:56:54 <stevemar> i'd really prefer to not have to do reno for libraries
18:56:58 <notmorgan> lbragstad: reno doesn't make sense (i think) for the libs.
18:56:59 <bknudson> reno is to generate release notes, so that users will know what changed
18:57:05 <stevemar> but we'll go with the flow
18:57:09 <bknudson> e.g., what new features have been added
18:57:12 <topol> so um who was pushing reno?
18:57:24 <stevemar> topol: release mgnt ream
18:57:26 <stevemar> team*
18:57:27 <dstanek> notmorgan: use that bug for all of the libs?
18:57:37 <dims_> topol : release team is trying to evaluate
18:57:45 <notmorgan> dstanek: yeah will add the libs now
18:57:47 <stevemar> topol: it's great for the server stuff, instead of a wiki
18:57:50 <topol> anyone else actually really using it
18:57:57 <stevemar> topol: it just started
18:58:04 <dstanek> notmorgan: cool. thx
18:58:07 <dims_> topol Nova has
18:58:13 <stevemar> topol: we get pretty release notes like: http://docs.openstack.org/releasenotes/keystone/unreleased.html
18:58:25 <stevemar> bknudson:  we can chat about libraries in -keystone
18:58:34 <stevemar> bknudson: sorry we didn't get to that last topic
18:58:36 <bknudson> ok, we'll see where the rest of openstack goes
18:58:42 <ayoung> please lock the python-keystoneclient repo, but leave it a round since old versions of the code will point to it
18:58:47 <notmorgan> dstanek: did I miss any?
18:58:53 <ayoung> same with SAML
18:59:01 <ayoung> don;t delete the repos.
18:59:13 <stevemar> ayoung: we won't, they'll go in the attic
18:59:20 <notmorgan> dstanek: ok added pycadf too
18:59:24 <ayoung> so long as the links still work, I'm OK
18:59:26 <dstanek> notmorgan: do pycadf, ks-auth policy have 2.6?
18:59:27 <ayoung> with it
18:59:42 <stevemar> ayoung: links may not work...
18:59:44 <davechen> stevemar: the release note is a little confusion, you put a bug link there but say it's a feature.
19:00:00 <stevemar> davechen: new options are available
19:00:03 <davechen> and properly, we will has lot of features in the releasenote after the end of the cyle.
19:00:07 <stevemar> #endmeeting