18:01:12 <jamielennox> #startmeeting keystone
18:01:13 <openstack> Meeting started Tue May 24 18:01:12 2016 UTC and is due to finish in 60 minutes.  The chair is jamielennox. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:16 <openstack> The meeting name has been set to 'keystone'
18:01:24 <jamielennox> :)
18:01:35 <dstanek> ahoy
18:01:45 <jamielennox> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:01:48 <hogepodge> o/
18:02:03 <rderose> o/
18:02:17 <gagehugo> /o/
18:02:21 <jaugustine> \o\
18:02:23 <jaugustine> haha
18:02:34 <jamielennox> ok, as most people are probably aware of by now, stevemar recently had a baby boy and is on leave for the next couple of weeks
18:02:44 <lbragstad> whoop whoop!
18:02:48 <lbragstad> when does he start reviewing code?
18:02:56 <henrynash> rattle rattle
18:02:58 <notmorgan> lbragstad: hehe
18:03:05 <henrynash> who says he isn’t
18:03:20 <jamielennox> in reality this means he'll proabably be around, but in the mean time the cores will generally be able to sort out most things for him
18:03:25 <breton_> o/
18:03:26 <topol> o/
18:03:34 <jamielennox> anything particular come find me or notmorgan
18:03:47 <jamielennox> and of course - congrats stevemar
18:03:58 <dstanek> jamielennox: ++
18:03:59 <amakarov> +1
18:04:02 <topol> +++
18:04:03 <gagehugo> +1
18:04:07 <notmorgan> jamielennox: lets start w/ the etherpad thing
18:04:25 <notmorgan> jamielennox: then we can continue w/ spec freeze etc.
18:04:43 <jamielennox> #topic Meeting Agenda Moving to Etherpad?
18:04:51 <jamielennox> notmorgan: ok then
18:04:52 <notmorgan> Talked with steve and a few others
18:05:01 <notmorgan> people cannot edit the wiki because no new accounts are allowed
18:05:08 <notmorgan> as a trial i created an etherpad
18:05:11 <notmorgan> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:05:30 <raildo> notmorgan: ++ for etherpad
18:05:38 <notmorgan> instead of the wiki we can use the etherpad for meetings. any issues/concerns/love the ideas?
18:05:56 <gyee> all love here
18:05:56 <dstanek> works for me
18:05:57 <lbragstad> i'm indifferent - either works for me
18:05:59 <rodrigods> just put the etherpad URL in the wiki
18:06:04 <notmorgan> rodrigods: that is the plan.
18:06:04 <topol> works
18:06:05 <bknudson> makes sense since editing the wiki is a pain
18:06:05 <lbragstad> yes
18:06:06 <knikolla> ++ for etherpad, with link in wiki
18:06:09 <breton_> i wonder how good it will work in a year
18:06:13 <henrynash> works for me (already edited it!)
18:06:20 <jamielennox> yea, i'm not too worried either way - works if we can't et people accessing the wiki
18:06:34 <notmorgan> ok lets start going from the etherpad then
18:06:41 <notmorgan> i've added the spec freeze bit to it
18:06:54 <notmorgan> and i'l update the wiki to reference more prominently after this meeting
18:07:06 <jamielennox> #action notmorgan fix the wiki keystonemeeting links to point to the new meeting etherpad
18:07:42 <jamielennox> hmm, no meetbot confirmations - hope i didn't screw this up
18:07:50 <notmorgan> you don't get them on #link or action
18:08:00 <jamielennox> ah
18:08:10 <jamielennox> #topic Spec proposal freeze is next week, couple of weeks longer for spec freeze.
18:08:25 <jamielennox> next week is spec proposal freeze
18:08:49 <jamielennox> for anyone unfamiliar this means that any specs you want to land in newton have to be at least proposed by then
18:09:08 <jamielennox> we then have a few weeks before specs have to be actually approved to land in newton
18:09:19 <jamielennox> so if you're thinking of still proposing something get a wriggle on
18:09:20 <breton_> is next week 30-5?
18:09:32 <notmorgan> breton_: yes
18:09:47 * topol wriggle? I need an Australian dictionary
18:09:50 <henrynash> “get a wriggle on”
18:09:51 <jamielennox> notmorgan: i assume it's the end of the week?
18:10:01 <notmorgan> jamielennox: yes by end of the week is usually what we aim for
18:10:04 <breton_> so, will it be unfrozen in 30-5? or frozen on the 30th?
18:10:19 <notmorgan> breton_: after the week
18:10:27 <notmorgan> so after friday
18:10:36 <notmorgan> erm.. wait no.
18:10:40 <lbragstad> it will be frozen after the 5th, right?
18:10:46 <notmorgan> the spec proposal freeze happens after friday
18:10:51 <notmorgan> th... 4th?
18:10:59 <notmorgan> 3rd.
18:11:01 <breton_> 3rd
18:11:14 <jamielennox> after may 3rd is my understanding
18:11:18 <notmorgan> yes
18:11:26 <notmorgan> so a week from this coming friday is your deadline
18:12:10 <jamielennox> #topic Keystone Core Sec Updates
18:12:18 * notmorgan has a lot of topics.
18:12:18 <dstanek> if you're going to be cutting it that close you may want to get moving on it
18:12:33 <notmorgan> #link https://launchpad.net/~keystone-coresec
18:12:39 <notmorgan> the keystone core sec team is too large
18:12:46 <notmorgan> and has a lot of folks not actively participating
18:12:54 <notmorgan> i am going to trim this down.
18:12:54 <breton_> what is coresec?
18:13:01 <breton_> oh, ok.
18:13:04 <notmorgan> breton_: folks who evaluate embargoed bugs
18:13:17 <notmorgan> security vulnerabilities
18:13:19 <lbragstad> I don't think i'm on that list
18:13:30 <dstanek> notmorgan: i'm on there, but only occasionally comment - so you can trim me if you need to
18:13:31 <notmorgan> so, anyone can be on this (does not need to be a core reviewer)
18:13:40 <gyee> notmorgan, I would like to stay on it
18:13:43 <notmorgan> but if you're not interested and are on the list please speak up.
18:13:53 <rodrigods> hmm interesting
18:13:54 <notmorgan> or if you aren't on the list and are interested...
18:13:56 <dstanek> i feel bad taking up someone's spot if i can't contribute back enough
18:13:56 <notmorgan> speak up
18:14:03 <notmorgan> i'll conferr with people after the meeting
18:14:06 <notmorgan> so think about it
18:14:21 <dstanek> it would be nice to somehow still be able to see what's happening though :-(
18:14:24 <lbragstad> is there a limit to how many people we can have?
18:14:31 <notmorgan> ideally we should be ~5 people
18:14:45 <notmorgan> any one can be looped in to view a security bug
18:14:50 <lbragstad> notmorgan because it's security related?
18:14:58 <rderose> notmorgan: I'd be interested
18:14:59 <notmorgan> this is just the front line group who evaluates IF a bug is really a bvlunerability
18:15:13 <notmorgan> think about it, i'll work out who will be on the team after the meeting :)
18:15:43 <notmorgan> i can guarantee that stevemar will be staying on that list [as ptl]
18:15:58 <notmorgan> ok thats all on that topic.
18:16:12 <jamielennox> #topic Reviews!
18:16:25 <notmorgan> ok
18:16:28 <notmorgan> so.
18:16:30 <breton_> lets do them?
18:16:37 <notmorgan> in newton we have been lacking reviews and have a lot of open patches
18:16:43 <notmorgan> some can be abandoned, some need rebasing
18:16:44 <bknudson> http://russellbryant.net/openstack-stats/keystone-reviewers-90.txt
18:16:45 <henrynash> ok, guilty as charged. C- for Henry
18:16:49 <notmorgan> but in short... we have been lacking reviews
18:16:51 <notmorgan> http://stackalytics.com/?module=keystone-group
18:16:56 <notmorgan> #link http://stackalytics.com/?module=keystone-group
18:17:02 <notmorgan> that is specific to newton code
18:17:11 <notmorgan> russ' only covers avg reviews.
18:17:19 <notmorgan> this is a call to action for everyone
18:17:21 <notmorgan> please review.
18:17:27 <notmorgan> cores, non-cores, new folks, etc
18:17:27 <bknudson> I haven't been able to review so much lately due to changes in the job... hoping to get back to it sometime.
18:17:30 <henrynash> will do
18:17:49 <notmorgan> question things in the patch if you don't understand (-1s for things that look wrong, but no score with questions help too)
18:17:52 <notmorgan> in short. review.
18:18:01 <gyee> getting back on the review horse
18:18:04 <knikolla> i’ll start reviewing more, whatever my +1 is worth.
18:18:07 <bknudson> my reviews seem to mostly be ignored lately anyways
18:18:08 * rodrigods have some patches that would love reviews
18:18:20 <notmorgan> we are actively keeping an eye on folks who are reviewing, get the code base, etc for new cores fwiw
18:18:26 <breton_> that's because i am on vacation
18:18:32 <breton_> that's why there are no reviews.
18:18:35 <stevemar> knikolla: it's worth more than you think -- a good review is a good review, regardless who does it
18:18:41 <dstanek> i'm guilty of being low in review count - been tied up with capstone, but that's changing in a day or two
18:18:50 <notmorgan> but everyting does need reviews, a +1 means a lot, a -1 with questions/concerns means a lot
18:18:50 <breton_> i'll be back and we'll be good again, relax.
18:18:56 <notmorgan> a +0 with questions means a lot
18:19:00 <notmorgan> EVEN if a core already +2'd
18:19:00 <raildo> I'll review more on this release :)
18:19:03 <lbragstad> notmorgan ++
18:19:13 <jamielennox> /kick stevemar
18:19:16 <dstanek> knikolla: ideally you find stuff and it gets fixed before a core comes around and -1's it
18:19:21 <notmorgan> please review. we lean on everyones to make the code base good.
18:19:35 <notmorgan> and every review matters.
18:19:40 <bknudson> the comments along with the review are worth more than the vote. Try out the change and say what you did
18:19:49 <knikolla> understood, i’ve been mostly commenting with +0
18:19:52 <bknudson> check the coverage report and say if everything is covered
18:19:52 <notmorgan> if you have a concern you don't want to say publically, you can talk to a core.. or me directly
18:20:03 <jamielennox> the problem with a lot of +0 is they go unnoticed
18:20:06 <notmorgan> i'll happily help guide if you're unsure about how to review.
18:20:10 <notmorgan> jamielennox: we need to fix that.
18:20:12 <topol> I will put more focus on reviewing as well
18:20:21 <topol> message heard!
18:20:23 <jamielennox> i often miss +0 for ages because it doesn't show up as a change in the review list
18:20:31 <gyee> No Review Left Behind Act
18:20:33 <notmorgan> cores - please do not ignore +0s. submitters, be sure to look for the +0
18:20:35 <jamielennox> just as an aside
18:20:36 <amakarov> jamielennox, ++
18:20:37 <notmorgan> with questions.
18:21:13 <jamielennox> notmorgan: ok?
18:21:16 <notmorgan> and if a +0 is being ignored, raise it up to someone :) don't hesitate to point it out if it seems like it is relevant or change the vote to -1 after conferring with a core
18:21:25 <notmorgan> jamielennox: yep :)
18:21:34 <bknudson> submitters should realize that pretty much nothing is going to get merged this release due to lack of reviews.
18:21:43 <rodrigods> i usually +1 when i have doubts
18:21:46 <notmorgan> (or just change it to -1 if you feel it is important enough)
18:21:48 <notmorgan> or a +1
18:21:50 <rodrigods> just for the person be able to see
18:21:57 <dstanek> bknudson: yes. so they should be reviewing too!
18:22:02 <notmorgan> bknudson: exactlyu
18:22:25 * notmorgan has one more short topic.
18:22:25 <jamielennox> #topic Good News Everbody!
18:22:35 <notmorgan> so. i've proxied for steve (and talked with him)
18:22:40 <notmorgan> and conferred with the cores.
18:22:53 <notmorgan> Please welcome rodrigods as the newest member of the core team.
18:23:00 <henrynash> woot woot!
18:23:02 <bknudson> congrats to rodrigods
18:23:03 <lbragstad> rodrigods congrats!
18:23:03 <rodrigods> o/
18:23:06 <raildo> YAY congrats rodrigods!
18:23:07 <gyee> rodrigods, congrats!
18:23:07 <amakarov> rodrigods, congratulations!
18:23:08 <raildo> :D
18:23:09 <knikolla> rodrigods: congrats!
18:23:10 <notmorgan> i will send an email out after the meeting and get you added to the gerrit group.
18:23:14 <jamielennox> well done rodrigods
18:23:14 <rodrigods> will i be able to +A all my code?
18:23:15 <rodrigods> :)
18:23:19 <notmorgan> rodrigods: lol.
18:23:20 <rodrigods> thank you all
18:23:22 <bknudson> thanks for all your work on keystone.
18:23:29 <henrynash> rodigods: instant demotion
18:23:35 <raildo> lol
18:23:40 <rderose> rodrigods: congrats!!!
18:23:40 <jamielennox> shortest core stint award goes to
18:23:51 <notmorgan> i want to reiterate that rodrigods has shown understanding of the code base and quality reviews and code.
18:23:51 <gagehugo> grats!
18:23:57 <gyee> s/demo/demoli/
18:24:17 <notmorgan> we are continuing to look for other reviewers/contributors to include in the core group.
18:24:19 <rodrigods> thanks! and also for the mentoring since i've joined the openstack community
18:24:46 <notmorgan> #action notmorgan to send email and add rodrigods to core group after meeting
18:24:57 <dstanek> rodrigods: congrats
18:24:59 <jamielennox> rodrigods: thanks for sticking in there and everything you've done
18:25:13 <topol> CONGRATULATIONS rodrigods! Very well deserved!
18:25:49 <rodrigods> really glad to be part of the core team, will try to work harder
18:26:00 <dolphm> rodrigods: /salute
18:26:02 <notmorgan> rodrigods: you now have +2/+A rights on the keystone repositories.
18:26:30 <rodrigods> awesome :)
18:26:48 <jamielennox> #topic Creating new versions of keystone component drivers (e.g. V8, V9 etc.)
18:26:57 <henrynash> ok
18:26:58 <jamielennox> go go henrynash!
18:27:38 <bknudson> the suspense...
18:27:39 <henrynash> so todate, every time we create a new version of a driver, we archive off an example driver (e.g. SQL) so that we can test we haev not broken teh old interface
18:27:59 <henrynash> some have suggest this is a poor way of doing it....
18:28:09 <henrynash> …but so far I don’t have any otehr ideas
18:28:18 <bknudson> I guess the old driver is in git already
18:28:22 <bknudson> so maybe check out an old keystone?
18:29:01 <gyee> microversioned keystone drivers :-)
18:29:02 <henrynash> bknudson: so we usual want to substitute an individual driver
18:29:13 <bknudson> y, check out only that driver.
18:29:42 <bknudson> check out keystone to a new directory and pull out the driver.
18:29:42 <knikolla> check out only that specific driver from git
18:29:49 <henrynash> we used to so this for client testing, I think…but we moved away form it
18:29:54 <bknudson> or maybe you can just check out a file.
18:30:04 <bknudson> that was in a different repo
18:30:12 <jamielennox> do we expect people to subclass the driver class directly or duck type it?
18:30:18 <bknudson> you could do git checkout stable/master -- keystone/identity/backend/sql.py
18:30:19 <henrynash> no
18:30:25 <henrynash> (to jamie)
18:30:34 <bknudson> they have to subclass since it's abc.
18:30:44 <bknudson> this is why abc is a bad idea in python
18:30:56 <dstanek> the issue is that we don't want to carry an extra copy of the backend?
18:30:56 <henrynash> we only support the interface, we don’t promise they can subclass our driver and we’ll maintin the code otehyc an continue to subclass
18:31:00 <amakarov> henrynash, is there a problem description somewhere?
18:31:12 <henrynash> just ayiojng objecting in: https://review.openstack.org/#/c/305315/
18:31:28 <bknudson> I don't mind keeping a copy in the tests, so not sure what the complaints are.
18:31:38 <dstanek> bknudson: ++
18:31:45 <dstanek> i dont
18:31:47 <henrynash> this is teh current example: we just need to copy the driver so we can test
18:32:00 <henrynash> ayoung: you about?
18:32:01 <shaleh> so where is ayoung to provide an alternative since he complained?
18:32:01 <bknudson> it's not 400 lines that we have to maintain
18:32:02 <dstanek> like having to rely on checking out individual files
18:32:46 <amakarov> henrynash, can we make subsequent interfaces inherited?
18:32:57 <henrynash> ok, so I’ll follow up with ayoung and ask him to calrify his concern and propose an alternative if he feels striongly about it
18:33:01 <amakarov> this will save a lot of copying
18:33:24 <bknudson> the copy is so that we can test with an old implementation
18:33:39 <bknudson> the interface is already inherited
18:33:50 <henrynash> bknudson: ++
18:33:54 <jamielennox> i think we need to maintain those tests, and we need to maintain the symbols so that anyone who subclassed it doesn't get broken immediately
18:34:11 <dstanek> amakarov: it's the copying of the backend
18:34:37 <amakarov> bknudson, I'm about "class IdentityDriverV9(IdentityDriverV8)"
18:35:04 <bknudson> no, we decided to do an adapter
18:35:27 <amakarov> bknudson, well, then we need all the code
18:35:46 <henrynash> amakarov: we wanted to make sure the new driver & interface was as clean as possible…pushing the ugliness into the adaptor
18:36:02 <henrynash> jamielennox: ok, think we ar done on this one
18:36:28 <jamielennox> #topic Microversioning of the Identity API
18:36:38 <henrynash> damn. me again
18:37:12 <henrynash> ok, so we have at least one hcnage that requires break api
18:37:21 <henrynash> (hierarchial naming)...
18:37:39 <henrynash> …and the push back from several was that we should really do microversioning now for teh Idenityt API
18:37:45 <henrynash> so this is now proposed: https://review.openstack.org/#/c/315180/
18:38:17 <henrynash> this is basically teh same approach nova uses, adapted for keystone
18:38:25 <notmorgan> this is an API breaking change - the options are:
18:38:33 <notmorgan> 1) Microversions (like nova)
18:38:42 <notmorgan> 2) Don't break the API and not change this
18:38:46 <notmorgan> 3) API V4
18:39:05 <notmorgan> in order of my preference [assuming this is something we want]
18:39:07 <henrynash> I re-wrote the origional spec published by ayoung to docuemtn all teh use cases etc and make this a compelte sepc (rather than just refer to the nova spec)
18:39:08 <raildo> API v4, please no :(
18:39:13 <jamielennox> so regards the hierarchical naming (main cause for this) - is that something we can solve with an api version change? it seems like a modelling problem
18:39:21 <bknudson> considering how hard it is to get other projects to even use current features I'd vote for don't break the api.
18:39:33 <gyee> v4 is least disruptive
18:39:55 <notmorgan> henrynash: why do we need this relaxed naming?
18:40:03 <ayoung> I'm here
18:40:17 <notmorgan> is there a real use case we're missing that uniqueness per domain is unacceptable?
18:40:23 <notmorgan> since domains are not hierarchical
18:40:23 <bknudson> can we put the new stuff on a different path (make it a different resource)?
18:40:25 * samueldmq reads up
18:40:36 <amakarov> jamielennox, policy enforcement for ex.
18:40:58 <amakarov> jamielennox, we can do it in keystone for RBAC3
18:40:59 <notmorgan> bknudson: the issue is projects would leak through into the old api...or you'd need a new api to see the project?
18:41:04 <henrynash> notmorgan: so I think there are two things here: we can argue whether we can get away with naming uniquenss or not…..but I think it is better we agree to our approach of hwo we modify the API when we need to….and I’m sure we will need to
18:41:10 <dstanek> bknudson: that's what i would vote for. new/different API resources
18:41:13 <jamielennox> bknudson: also it's really an /auth request
18:41:14 <ayoung> I don't see why relaxing a rule is breaking the contract, but I'm not going to fight this fight.  If microversions buy us things elsewhere, and this is a good place to introduce them,lets do it
18:41:17 <raildo> notmorgan: project name is unique in a domain, we can't have a parent and a subproject with the same name
18:41:25 <bknudson> how can we prevent leaking to the old api in any case?
18:41:36 <notmorgan> raildo: i don't see that as a problem
18:42:02 <jamielennox> it's not just a parent problem
18:42:03 <raildo> notmorgan: we can have something like, coke->dev and pepsi->dev
18:42:19 <notmorgan> raildo: so make coke_domain and pepsi_domain
18:42:23 <jamielennox> an accounting project and a engineering project both want to create ProjectX
18:42:36 <jamielennox> that name is only unique via the path
18:42:42 <henrynash> so on the specific naming issue, I think it is untennable that as hiearchies grow, that all leaves/nodes have to be unique
18:42:54 <notmorgan> jamielennox: and i'm going to argue that accounting should be a domain and engineering should be.
18:42:56 <raildo> notmorgan: yes, but this doesn't work for reseller, since we can create subprojects acting as domains
18:43:14 <raildo> cant*
18:43:33 <notmorgan> raildo: again, i'm back to domains.
18:43:50 <dstanek> henrynash: so what part of the API is being broken? just getting error codes (4xx) where we used to get success (2xx)?
18:43:51 <notmorgan> everything still works with a new domain.
18:44:01 <notmorgan> inc. "reseller" concepts.
18:44:05 <henrynash> notmorgan, jamielennox: I guess I am more interested in whether we think we must be able to break teh API in teh future, and if so, how shoudl we do it....
18:44:07 <notmorgan> add a domain to the account.
18:44:21 <notmorgan> henrynash: microversions or V4
18:44:36 <notmorgan> henrynash: and i'm fine with either
18:44:45 <gyee> auth is part of defcore, so we have to be mindful about interop
18:44:47 <jamielennox> henrynash: given that other projects are adopting microversions, i'd say we would do that - but i would like to be left with absolutely no other choice
18:44:47 <ayoung> lets not V4
18:44:52 <notmorgan> though microversions seems to be the pattern for openstack
18:45:04 <ayoung> micro changes are microversions.  A big version jump is just going to be ignored
18:45:09 <jamielennox> yea, particularly around the auth apis
18:45:25 <henrynash> dtsanek: teh specific problem is that before thsi proposed change, teh proejct scope of “test” would work, but mioght now aftewards, since “test” is not unqiue and /“dev/test” would be requied
18:45:27 <notmorgan> if we did a big api version jump, we'd need to extract auth to /auth
18:45:31 <notmorgan> not /<version>/auth
18:45:43 <jamielennox> notmorgan: ++ to that anyway
18:45:49 <ayoung> I'm not sure we are not just making busywork for ourselves, but if this is the cautious approach, it probably is the better way to go
18:45:51 <notmorgan> that whole tie auth to the CRUD api is what caused us so much headache in api verion adoption
18:46:01 <notmorgan> anyway
18:46:08 <notmorgan> ayoung: it is the conservative approach
18:46:20 <notmorgan> and keystone frankly needs to err to the conservative side
18:46:30 <knikolla> notmorgan: ++
18:46:31 <henrynash> notmorgan: I have to agree with you
18:47:02 <jamielennox> i'm also wondering if we have a real world request for this yet or are looking at upcoming pain points?
18:47:27 <jamielennox> given the adoption of hierarchies so far..
18:47:52 <henrynash> jamielennox: so mine is the only one I knwo of so far….although if we do the work and never incremenent teh microversion number, nothing breaks anywya
18:48:14 <bknudson> nova used microversions for all sorts of fixes
18:48:16 <ayoung> jamielennox, we have requests
18:48:20 <notmorgan> i'll argue that almost everything that is desired with reseller could be done with domains.
18:48:22 <bknudson> useful ones like better validation of user input
18:48:35 <notmorgan> on the topic of hierarchies.
18:48:35 <henrynash> bknudson: agreed, and I plan to copy their approach
18:48:37 <notmorgan> bknudson: ++
18:48:46 <ayoung> HMT is limited by other projects, but we want to keep it that way, and stay ahead of the demand
18:48:59 <dstanek> notmorgan: ++
18:49:09 <ayoung> we had a customer ask about it.  Horizon support needs to come up
18:49:10 <knikolla> also with microchanges we might be able to have better adoption of our newer apis
18:49:30 <jamielennox> 2-3 more minutes so we can leave time for the last topic
18:49:45 <bknudson> we've seen that better adoption only comes when we spend our time in the other projects
18:50:01 <henrynash> ok, so review the spec….and we’ll go from there
18:50:05 <jamielennox> bknudson: ++ no one else does auth work
18:50:28 <jamielennox> henrynash: my view would be microversions is the answer, but only when we're really sure what we want to solve with it
18:50:42 <jamielennox> so i'd prefer to discuss the hierarchical naming problem
18:50:48 <rodrigods> it can be useful for other stuff
18:50:50 <rodrigods> not only HMT
18:50:59 <rodrigods> HMT was the trigger, but...
18:51:05 <knikolla> jamielennox: the use cases will come once it’s there
18:51:09 <dstanek> i think that in a way microversions are an API/architecture smell
18:51:13 <dstanek> maybe a necessary one?
18:51:36 <jamielennox> rodrigods: it can, but we've kept our api stable for a while now
18:51:37 <jamielennox> dstanek: ++
18:51:38 <ayoung> dstanek, part of the issue is that Keystone is not really a micros service
18:51:46 <bknudson> if we could design things perfectly from the beginning we wouldn't need it, but we're not perfect.
18:51:48 <ayoung> its more of just a service, not a macro one.  THat would be nova
18:51:55 <rodrigods> bknudson, ++
18:52:00 <dstanek> even in nova i'd argue that it's not great architecture
18:52:06 <ayoung> nova is a macros service
18:52:09 <ayoung> its like 15 things
18:52:12 <ayoung> Keysteon is about 5
18:52:21 <jamielennox> ok, review spec
18:52:25 <bknudson> I'm surprised every time someone says openstack servers are microservices.
18:52:27 <henrynash> jamielennox: so the spec that is up: (there are two alternatives): https://review.openstack.org/#/c/310048/ and https://review.openstack.org/#/c/315180/
18:52:29 <dstanek> bknudson: or it we understood hypertext
18:52:41 <ayoung> auth, id &  federation, assignment, resource, policy,
18:52:52 <jamielennox> #topic Multiple datacenters
18:52:55 <ayoung> each could and should be separate if we were serious about microservies
18:53:01 <ayoung> Ah
18:53:10 <jamielennox> amakarov: was hoping to give you a bit more time there, sorry
18:53:14 <ayoung> jamielennox, beyond Fernet?
18:53:34 <agrebennikov> are you guys going to wrap up and skip this topic?
18:53:39 <dstanek> ayoung: microservices is really abot team size. so if the same team manages all the microservices then splitting won't matter
18:53:46 <ayoung> we should get a best practice written up about Fernet key rotation
18:53:48 <jamielennox> amakarov: or i can leave it for next week and put you in first instead?
18:54:10 <amakarov> jamielennox, I think 5 min is anough for now
18:54:15 <amakarov> agrebennikov is here
18:54:30 <amakarov> And the case is described in etherpad
18:54:46 <agrebennikov> so I tried to explain in details what I need
18:54:57 <agrebennikov> and this is actually a very common request from the customer
18:55:04 <shaleh> link to pad?
18:55:10 <amakarov> I believe last time we agreed that admin CAN specify project IDs, right?
18:55:18 <jamielennox> so to my mind if you are replicating role ids, project ids and user ids in all regions then you are pretty much replicating the database anyway
18:55:21 <amakarov> https://etherpad.openstack.org/p/keystone-weekly-meeting
18:55:45 <agrebennikov> jamielennox, no, this is not quite correct
18:56:07 <agrebennikov> db replication means if you broke it in one place - it gets broken in all others
18:56:23 <agrebennikov> and we actually had this issue in production cloud
18:56:35 <shaleh> why is DB replication an issue since there will be few writes?
18:56:35 <agrebennikov> that is why the customer decided to get rid of this
18:57:22 <shaleh> without writing UUID there is little to break in Keystone DB now
18:57:22 <agrebennikov> shaleh, because nobody wants to deal with additional instance of db specifically for keystone
18:57:25 <jamielennox> have you tried the read-only database conenctions for this? because if that doesn't work for this case i'm in big trouble :)
18:57:35 <dstanek> agrebennikov: so the alternative is to manually do replication?
18:57:36 <agrebennikov> which has to have different peers than all other dbs
18:58:06 <gyee> agrebennikov, I hear ya, LDAP is already replicated
18:58:26 <agrebennikov> ldap only provides users
18:58:28 <shaleh> dstanek: a push model on the occasional new user / role / project change would not be too bad. But this is still an additional DB instance
18:58:39 <lbragstad> ayoung we have something similar to what you're suggesting in the fenret FAQ
18:58:41 <gyee> and groups
18:58:41 <shaleh> so I do not see the request
18:59:04 <ayoung> agrebennikov, is this essentially "we need to be able to say what the projet Id is" but also for roles and assignments?
18:59:11 <ayoung> lbragstad, cool.  Link?
18:59:15 <lbragstad> ayoung that document seems like the right place for a fernet best practices
18:59:19 <lbragstad> ayoung yeah
18:59:23 <dstanek> shaleh: i would not want keystone to be responsible for that. dbs are built to do this
18:59:23 <shaleh> if every region has their own DB, however you want to sync it is your issue. Otherwise, read only calls back to "home" should work.
18:59:26 <jamielennox> yea, i feel this will grown form project_ids to needing to specify all ids
18:59:32 <jamielennox> also we've one minute
18:59:37 <shaleh> dstanek: I am not saying Keytone would drive it
18:59:41 <lbragstad> ayoung http://docs.openstack.org/admin-guide/keystone_fernet_token_faq.html
18:59:49 <dstanek> shaleh: any code even :-)
18:59:52 <jamielennox> agrebennikov, amakarov: sorry i should have pushed it till next week and given you more time
19:00:11 <jamielennox> please continue the discussion in #openstack-keystone for now
19:00:12 <agrebennikov> ayoung, yes please. roles and projects
19:00:17 <shaleh> amakarov: write more, show the problems.
19:00:25 <amakarov> agrebennikov, till next week then ^^
19:00:33 <jamielennox> #endmeeting