Tuesday, 2015-04-14

lhchengayoung: do you recall why get_trust is not raising a NotFound exception if no record is found: https://github.com/openstack/keystone/blob/master/keystone/trust/backends/sql.py#L13800:08
*** _cjones_ has quit IRC00:18
*** henrynash has quit IRC00:29
*** gyee has quit IRC00:35
ayounglhcheng, if someone passes in a bogus trust id, what else should it do?00:37
ayounglhcheng, Do you mean that it looks like the code should return None, but instead throws an exception?00:38
lhchengayoung: code is returning None, I wonder why it is *not raising a NotFound exception instead.00:39
ayounglhcheng, ah.00:39
ayounglhcheng, probably an oversight?  I just didn't code it that way?00:39
ayoungMaybe something later on throws the exception instead/00:39
lhchengayoung:  I see is the controller is having all the checks "if not trust: raise exception"00:40
ayounglhcheng, I'd have to look where it was called, and see if there is any advantage to having it return None, but your logic seems correct00:40
ayoungmight have been due to some other backend?  Meh00:40
ayoungno idea, but throwing from the driver would probably be more correct00:41
lhchengmight make sense to move all checks from controller to the backend.00:41
*** alexsyip has quit IRC00:42
ayounglhcheng, Yep. DRY principle.00:42
brownehmm, stable/juno appears broken due to pymongo00:42
browneeven though i know there was a cherry pick to fix it00:43
lhchengayoung: cool, thanks. I'll propose a patch to clean that up.00:43
*** ozialien has joined #openstack-keystone00:44
lhchengbrowne: pymongo, is already pinned in stable/juno: https://github.com/openstack/keystone/blob/stable/juno/test-requirements.txt#L1500:45
lhchengbrowne: weird, that it is still broken..00:45
brownemy bad, it was proposed/kilo00:46
browneok master has the pymongo fix, but not proposed/kilo00:48
lhchengbrowne: I believe rc2 window haven't opened up.00:48
browneprobably my misunderstanding of how proposed/ rc branches work00:49
*** browne has quit IRC00:56
*** tqtran has quit IRC01:04
*** ozialien has quit IRC01:19
*** erkules_ has joined #openstack-keystone01:21
*** erkules has quit IRC01:23
*** browne has joined #openstack-keystone01:45
*** diegows has quit IRC01:54
*** davechen1 has joined #openstack-keystone01:54
*** edmondsw has quit IRC02:00
*** ashleighfarnham has joined #openstack-keystone02:05
*** Raildo__ has quit IRC02:21
*** dims_ has quit IRC02:28
*** richm has quit IRC02:38
*** stevemar has joined #openstack-keystone02:40
*** ChanServ sets mode: +v stevemar02:40
*** rm_work|away is now known as rm_work02:52
*** rhagarty__ has joined #openstack-keystone02:59
*** wolsen_ has joined #openstack-keystone03:01
*** rm_work is now known as rm_work|away03:05
*** stevemar has quit IRC03:06
*** jdennis has quit IRC03:06
*** rhagarty has quit IRC03:06
*** arif-ali has quit IRC03:06
*** wolsen has quit IRC03:06
*** tristanC has quit IRC03:06
*** ashleighfarnham has quit IRC03:09
openstackgerritLin Hua Cheng proposed openstack/keystone: Checking if Trust exists should be DRY  https://review.openstack.org/17315803:13
*** tristanC has joined #openstack-keystone03:13
*** stevemar has joined #openstack-keystone03:13
*** jdennis has joined #openstack-keystone03:13
*** arif-ali has joined #openstack-keystone03:13
*** sendak.freenode.net sets mode: +v stevemar03:13
*** lhcheng has quit IRC03:14
*** ayoung has quit IRC03:14
*** _cjones_ has joined #openstack-keystone03:19
*** _cjones_ has quit IRC03:24
stevemarsigmavirus24_awa, i have so many questions for when you are back03:24
*** dims has joined #openstack-keystone03:28
*** dims has quit IRC03:33
*** lhcheng has joined #openstack-keystone03:36
*** ChanServ sets mode: +v lhcheng03:36
*** ajayaa has joined #openstack-keystone03:44
*** rm_work|away is now known as rm_work03:52
*** sdake has joined #openstack-keystone03:56
*** harlowja is now known as harlowja_away03:58
*** sdake_ has quit IRC03:58
morganfainberglhcheng: I have not been told rc2 is open.03:59
morganfainberglhcheng: I have not heard rc2 windows are open.04:00
morganfainbergbrowne: a bug that is a potential rc blocker just needs the appropriate kilo-rc-potential we will evaluate each bug when rc2 window opens.04:01
*** sdake_ has joined #openstack-keystone04:02
lhchengmorganfainberg: yup, that's what I thought.  we can backport the fix bknudson made when rc2 opens.04:04
brownemorganfainberg: ok sure, but the tests on proposed/kilo are broken until bug 1441393 is cherry picked to it, no?04:04
openstackbug 1441393 in zaqar "Keystone and Ceilometer unit tests fail with pymongo 3.0" [High,New] https://launchpad.net/bugs/1441393 - Assigned to Flavio Percoco (flaper87)04:04
*** sdake has quit IRC04:04
morganfainbergbrowne: doesn't mean we won't absolutely make that a priority ;)04:05
morganfainbergbrowne: it can be proposed against the rc branch but I'll be -2 holding it until we open the window.04:05
morganfainbergbrowne: I expect rc2 to open in the next couple days.04:05
morganfainbergHm. Is stevemar here?04:06
browneok so maybe i did something wrong.  i cherry picked from master to proposed/kilo in https://review.openstack.org/#/c/173115/04:06
browneshould it be -2'd04:06
openstackgerritKun Huang proposed openstack/python-keystoneclient: Use "RegionOne" as default region  https://review.openstack.org/17316504:07
morganfainbergI think the Jenkins -1 is not directly related.04:07
morganfainbergI should -2 it.04:07
morganfainbergYou did nothing wrong.04:08
browneoh ok.  yeah probably best to -2 for now04:08
morganfainbergAnd likewise brant's fix for pymongo just needs rc2 window.04:09
morganfainbergI think we have ~4 rc blocking bugs.04:10
morganfainbergI really need to finish this slide deck up for Thursday :P04:11
morganfainberglhcheng: you coming to the Sunnyvale meetup?04:11
lhchengmorganfainberg: which meetup? I've missed the notice :P04:12
morganfainberglhcheng: http://www.meetup.com/openstack/events/214328842/04:13
morganfainbergThe one I'm supposed to present something besides a slide that says "lolz identity you has it"04:13
lhchengmorganfainberg: I haven04:15
lhchengI haven't attended the meetup for a while04:16
lhchengI attended a couple when it moved to HP campus, but it was mostly introduction track.04:17
lhchengmorganfainberg: great to see that there'll be advanced topics!04:17
morganfainbergThis will mostly be intermediate.04:17
lhchengmorganfainberg: I'll be there!04:18
morganfainbergGoing over the basics of keystone (act 1), multi identity setup (act 2), and federation + non-OpenStack application using Idp initiated saml to access a k2k remote resource04:19
morganfainbergErm s/k2k/saml protected04:19
morganfainbergEg something in swift04:19
morganfainbergBut I'm going to keep that last part light.04:20
stevemarmorganfainberg, yessum04:20
lhchengmorganfainberg: I consider anything that has federation in it as advanced topic :P04:20
* jamielennox just realized how session logging is a bad idea for transferring images :(04:20
morganfainbergstevemar: might ask you to chair the meeting tomorrow.04:21
*** ajayaa has quit IRC04:21
stevemarmorganfainberg, c'est bon04:21
morganfainbergHave an errand to run around noon, but not sure if I will need to be moving earlier or not.04:21
morganfainbergjamielennox: hmm?04:21
jamielennoxmorganfainberg: i couldn't figure out why my test was running slow converting glanceclient to sessions04:22
jamielennoxbecause it look the whole response body, loaded it as a string and dumped it into log output04:22
morganfainbergLol oh god.04:23
morganfainbergYeah let's fix that. ;)04:23
jamielennoxyea, i can turn logging off completely but not just exclude body04:23
morganfainbergjamielennox: I'll have time to finish the session split this week. Once I have rc2 open and this meet up out of the way.04:24
jamielennoxmorganfainberg: no worries, you know i could have done it if you're swamped04:24
morganfainbergjamielennox: eh if you want to sure. But we can't g-r it anyway yet ;)04:25
jamielennoxmorganfainberg: right, i was just looking to strip out some stuff04:25
morganfainbergjamielennox: also we need to identify anything we are back porting to the current tags for ksc/ksm. We aren't doing another release before kilo stable.04:25
jamielennoxit went from something we'll do one day to something we need in a hurry04:25
jamielennoxmorganfainberg: i understand this stable policy but it's going to be annoying for ksm04:26
morganfainbergFor reasons of "God what a mess and I don't want to make people go insane".04:26
jamielennoxhowever i don't think there is anything more that makes much difference for this release04:26
jamielennoxi think i got the g-r bumps i wanted04:27
morganfainbergjamielennox: think of it this way... I'm going to cap the g-r at <X where we can. Meaning if we want to break apis we do it with semver.04:27
morganfainbergjamielennox: I'm wondering if we want to push x releases as the stables04:27
morganfainbergWe can do this04:27
morganfainbergMake 2.x the Liberty release.04:28
morganfainbergThink on it. No decision is needed yet.04:28
jamielennoxoooo, that's interesting04:28
jamielennoxg-r should be using ~= by default04:28
morganfainbergWe won't be able to "break" things in ksc for a few more cycles.04:28
morganfainbergOr ever. But we can start indicating where we can do this.04:28
morganfainbergAssume ksm is locked because the ksm requirements must play nice with the pipeline requirements. (Same interpreter)04:29
morganfainbergUsing ksm in grizzly likely would not work as much as I'd like it to be *that* compatible.04:29
morganfainbergSo maybe we really commit to semver.04:30
jamielennoxi don't think anyone will judge us on auth_token not working with grizzly04:30
morganfainbergAnd if it isn't compatible (even for g-r reasons) we version it.04:30
morganfainbergThey won't. But it makes the breaking the api less bad for our users via semver04:30
morganfainbergNo one will really be able to use ksm 1.5.0 with Juno realistically.04:31
jamielennoxthis progression of g-r is bad for clients04:31
morganfainbergThey will use 1.304:31
morganfainbergClient cli/libs are different.04:31
jamielennoxright, if you don't need a new version of the library please don't force it on us for no reason04:32
morganfainbergSo I'm thinking we really go for it04:32
morganfainbergIf we need to break api... We increment x04:32
morganfainbergIn ksm, and for sure in keystoneauth04:32
jamielennoxso yea, keystoneauth gives us some wiggle room for sure04:33
morganfainbergEven if it is a g-r incompat we use semver to show it.04:33
jamielennoxksc & ksm i had given up on breaking changes04:33
morganfainbergBut I am going to be working to eliminate as many deps as we can04:33
morganfainbergI want keystoneauth to be really lean04:33
morganfainbergNo Oslo deps if we can at all avoid it.04:34
jamielennoxmorganfainberg: lol, mordred and dtroyer_zz  have been onto you as well04:34
morganfainbergFor example.04:34
morganfainbergI totally agree with them.04:34
jamielennoxme too04:34
morganfainbergDidn't take much convincing fwiw ;)04:34
morganfainbergKsm we probably can do a breaking change with a x. Increment. Ksc we have a lot to dig ourselves out of contract wise because of the cli04:35
jamielennoxso where did you get weith keystoneauth?04:35
*** krtaylor has quit IRC04:35
morganfainbergjamielennox: had it all split into a repo ready to push to GitHub04:36
morganfainbergHistory preserved.04:36
morganfainbergWanted to get it passing tests.04:36
morganfainbergThen all the other work I wanted in gerrit.04:36
jamielennoxoh nice, i wasn't sure we'd get history04:36
morganfainbergOh that is why I didn't just forklift. Forklift it would already have been complete.04:36
morganfainbergForklift is *really* easy.04:36
morganfainbergBut I think in this case history is really important too.04:37
jamielennoxi was considering just forking keystoneclient and using gerrit to strip it04:37
*** topol has joined #openstack-keystone04:37
*** ChanServ sets mode: +v topol04:37
morganfainbergThat's effectively what I was going to do just with nifty it tools04:37
lhchengmorganfainberg: you're a celebrity, haven't seen this much people signed up for the openstack meetup :P04:37
jamielennoxbut if you preserved history that's better04:37
morganfainbergjamielennox: both would preserve history but my way only holds history on the files we have in the repo.04:38
morganfainberglhcheng: thanks. I needed the anxiety ;)04:38
jamielennoxright, forking gives us all the CRUD history04:38
morganfainbergjamielennox: and I really would rather rewrite that history out.04:38
*** krtaylor has joined #openstack-keystone04:38
morganfainbergIf it becomes a rush, I don't care.04:38
morganfainbergIt's a days work to have it in a repo on github.04:39
morganfainbergProbably another day to get tests working.04:39
lhchengmorganfainberg: lol we got your back!04:39
jamielennoxmorganfainberg: ok04:40
morganfainbergjamielennox: I figure if ksc can replace its import with "from keystoneauth import" and pass its tests I'm happy04:40
morganfainbergWe can play "shred things out" in gerrit.04:40
morganfainbergThe retrofit stuff back in before making it the ksc dep.04:40
morganfainbergRetrofit in ksc that is.04:41
jamielennoxcan we put a branch on ksc that has keystoneauth from gerrit as a dep or something?04:41
morganfainbergPut it in tox.ini as a dep ;)04:41
morganfainbergThen g-r it when it's ready.04:42
jamielennoxoh g-r won't run on the branch - or we just turn it of04:42
morganfainbergNah have a dodge for that ;)04:42
morganfainbergWe dodge g-r for that test branch04:42
jamielennoxdoes keystoneauth become ka  - doesn't look quite right04:42
morganfainbergKal? Keystoneauth lib04:42
morganfainbergKsa also works.04:43
morganfainbergBtw: you get to write the readme on ksa.04:43
morganfainbergOr I'm copy-pasta your blog post on sessions. :P04:43
jamielennoxyep, that's needed doing for a while, but at least it can start fresh rather than try to figure out how to squeeze it in amonst existing doc04:43
morganfainberglhcheng: tomorrow mind looking through lp bugs for keystone and making sure we have no rc-critical ones?04:44
morganfainbergWe need to do another round of triage.04:45
morganfainbergBut rc ones first.04:45
lhchengmorganfainberg: sure, will do.04:45
stevemarlhcheng, triage them all as non-critical04:45
jamielennoxlhcheng: btw, i've got reviews up adding doa-kerberos to governance and gerrit with horizon ownership - which means i might need to bug you about things needed doing as horizon-core04:47
jamielennoxthis dual core thing is going to turn out very useful :)04:47
lhchengstevemar: wait, I only have to triage those "new" lp bugs right?04:48
lhchengjamielennox: lol I kinda expected that. :) glad to help with that.04:48
* lhcheng still have kerberos on things to-do04:52
*** tobberydberg has joined #openstack-keystone05:03
*** erkules_ is now known as erkules05:07
*** erkules has joined #openstack-keystone05:07
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Make process_header private  https://review.openstack.org/17317105:08
*** tobberydberg has quit IRC05:08
*** ajayaa has joined #openstack-keystone05:08
morganfainbergjamielennox: I'd like to get you core on doa if possible. Let's talk to david about making that its own team. Inherits horizon but allows specialists to jump in and help push things through.05:10
morganfainbergjamielennox: I know we have lhcheng now too, but more the merrier. Unless you don't want it.05:10
morganfainbergBut another passing thought.05:11
jamielennoxmorganfainberg: i know it fairly well now, the real challenge is going to be making horizon use what DOA sets up05:11
jamielennoxbut that's up to horizon for obvious reasons05:11
*** ishant has joined #openstack-keystone05:14
lhchengmorganfainberg: that makes sense.. reviews on doa are usually just between david-lyle and me, any additional reviews would definitely help.05:26
morganfainbergYeah. I think it makes sense.05:27
morganfainbergLet's bug David tomorrow. Silly simple change05:27
morganfainbergBut doa is sufficiently different we might as well get interested parties in on it.05:28
* morganfainberg has no interest in being doa core. Or owning doa05:28
morganfainbergI'd rather it be over in david-lyle 's hands. And people smarter than me at django.05:28
*** rushiagr_away is now known as rushiagr05:33
lhchengdoa is the link between django and KSC, would definitely benefit having KSC expert on it.05:33
lhchengagreed, let's bug David tomorrow.05:34
morganfainbergOh I hope ksc dies in doa. We should be able to move it to keystoneauth this cycle since keystoneauth will be the "new hotness" :)05:35
*** kiran_ has joined #openstack-keystone05:37
*** topol has quit IRC05:38
*** kiran_ is now known as kiran-r05:39
lhchengumm new treats.. :)05:39
lhchengmorganfainberg: that the version-less auth endpoint?05:41
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/17262406:05
*** krtaylor has quit IRC06:11
*** krtaylor has joined #openstack-keystone06:22
*** jdennis1 has joined #openstack-keystone06:30
*** jdennis has quit IRC06:31
*** Nikkau has joined #openstack-keystone06:37
*** tobberydberg has joined #openstack-keystone06:42
*** henrynash has joined #openstack-keystone06:50
*** ChanServ sets mode: +v henrynash06:50
*** trey has quit IRC06:53
*** trey has joined #openstack-keystone06:59
*** jamielennox is now known as jamielennox|away07:02
openstackgerritDave Chen proposed openstack/keystone: Remove project association before removing endpoint group  https://review.openstack.org/17319207:03
*** Nikkau has quit IRC07:06
*** stevemar has quit IRC07:09
*** chlong has quit IRC07:27
*** jistr has joined #openstack-keystone07:29
*** krykowski has joined #openstack-keystone07:33
*** pnavarro has joined #openstack-keystone07:38
*** lhcheng has quit IRC07:47
*** browne has quit IRC07:50
*** fhubik_afk has joined #openstack-keystone07:54
*** dims has joined #openstack-keystone08:07
*** dims has quit IRC08:12
*** davechen1 has quit IRC08:16
*** davechen has joined #openstack-keystone08:16
*** davechen1 has joined #openstack-keystone08:19
*** davechen has quit IRC08:22
*** sdake has joined #openstack-keystone08:22
*** davechen has joined #openstack-keystone08:23
openstackgerritKun Huang proposed openstack/python-keystoneclient: Use "RegionOne" as default region  https://review.openstack.org/17316508:23
*** davechen1 has quit IRC08:25
*** henrynash has quit IRC08:26
*** sdake_ has quit IRC08:26
*** sdake has quit IRC08:30
*** fhubik_afk has quit IRC08:31
*** fhubik has quit IRC08:31
*** fhubik has joined #openstack-keystone08:32
*** lhcheng has joined #openstack-keystone08:47
*** ChanServ sets mode: +v lhcheng08:47
*** lhcheng has quit IRC08:53
*** aix has quit IRC08:53
*** jaosorior has joined #openstack-keystone08:53
*** henrynash has joined #openstack-keystone09:03
*** ChanServ sets mode: +v henrynash09:03
*** henrynash has quit IRC09:08
*** henrynash has joined #openstack-keystone09:10
*** ChanServ sets mode: +v henrynash09:10
*** aix has joined #openstack-keystone09:20
*** amakarov_away is now known as amakarov09:22
openstackgerritDave Chen proposed openstack/keystone: Remove project association before removing endpoint group  https://review.openstack.org/17319209:43
openstackgerritDave Chen proposed openstack/keystone: Remove project association before removing endpoint group  https://review.openstack.org/17319209:46
*** davechen has left #openstack-keystone09:53
*** lifeless1 has joined #openstack-keystone09:54
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300010:00
openstackgerritAlexander Makarov proposed openstack/keystone: Redis token backend  https://review.openstack.org/15084410:02
*** lifeless has quit IRC10:02
*** harlowja_away has quit IRC10:02
*** fhubik is now known as fhubik_afk10:27
openstackgerritEndre Karlson proposed openstack/python-keystoneclient: Allow for other then STABLE api version  https://review.openstack.org/13015910:34
*** lhcheng has joined #openstack-keystone10:37
*** ChanServ sets mode: +v lhcheng10:37
*** davidckennedy has joined #openstack-keystone10:39
*** lhcheng has quit IRC10:41
davidckennedyhenrynash the endpoint enforcement PS Bob Thyne was working on at https://review.openstack.org/#/c/153296/ is now in a fit state for review, I believe.10:42
henrynashok, will take a look thx10:42
davidckennedythank you.10:43
*** ishant has quit IRC10:50
*** dims has joined #openstack-keystone10:54
*** lsmola_ has joined #openstack-keystone10:58
openstackgerritMerged openstack/keystone: Add routing for list_endpoint_groups_for_project  https://review.openstack.org/16793910:58
*** dims has quit IRC10:58
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300011:20
henrynashdavidkennedy: ping11:21
*** Nikkau has joined #openstack-keystone11:25
*** topol has joined #openstack-keystone11:27
*** ChanServ sets mode: +v topol11:27
*** aix has quit IRC11:32
*** aix has joined #openstack-keystone11:33
openstackgerritKamil Rykowski proposed openstack/oslo.policy: Fix invalid indentation in _load_policy_file method  https://review.openstack.org/17327511:40
*** fhubik_afk is now known as fhubik11:42
*** tobberyd_ has joined #openstack-keystone11:42
*** tobberydberg has quit IRC11:46
*** jistr is now known as jistr|class11:47
openstackgerrithenry-nash proposed openstack/keystone: Use correct LOG translation indicator for warnings  https://review.openstack.org/16712411:54
*** Nikkau has quit IRC12:00
*** henrynash has quit IRC12:11
*** jdennis1 has quit IRC12:11
*** fhubik is now known as fhubik_afk12:13
*** fhubik_afk is now known as fhubik12:16
*** davechen1 has joined #openstack-keystone12:16
*** kiran-r has quit IRC12:18
*** jdennis has joined #openstack-keystone12:21
*** pnavarro is now known as pnavarro|off12:22
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300012:24
openstackgerritAlexander Makarov proposed openstack/keystone: Redis token backend  https://review.openstack.org/15084412:30
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300012:30
*** bdossant has joined #openstack-keystone12:32
*** henrynash has joined #openstack-keystone12:35
*** ChanServ sets mode: +v henrynash12:35
*** gordc has joined #openstack-keystone12:36
*** trey has quit IRC12:41
*** lhcheng has joined #openstack-keystone12:43
*** ChanServ sets mode: +v lhcheng12:43
*** ajayaa has quit IRC12:45
*** trey has joined #openstack-keystone12:47
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300712:50
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873012:50
*** dims has joined #openstack-keystone12:51
*** markvoelker has joined #openstack-keystone13:00
*** mitz has quit IRC13:01
*** ozialien has joined #openstack-keystone13:02
*** jistr|class is now known as jistr13:03
openstackgerritLin Hua Cheng proposed openstack/keystone: Checking if Trust exists should be DRY  https://review.openstack.org/17315813:03
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300013:04
*** mitz has joined #openstack-keystone13:04
*** markvoelker_ has joined #openstack-keystone13:06
*** richm has joined #openstack-keystone13:07
*** markvoelker has quit IRC13:09
*** ozialien_ has joined #openstack-keystone13:12
*** ozialien has quit IRC13:12
*** ozialien_ is now known as ozialien13:12
rodrigodshenrynash is on review mode!13:13
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300713:13
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873013:13
henrynashrodigods: :-)13:14
*** topol has quit IRC13:15
raildorodrigods, ++ hah13:16
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300013:20
*** ozialien has quit IRC13:23
rodrigodshenrynash, replied your comments... will wait to send another patch set :)13:24
openstackgerritDave Chen proposed openstack/keystone: Minor change in the docstring  https://review.openstack.org/17232913:26
ccardwhich is the best channel to ask questions about quickstack and keystone?13:30
*** dims has quit IRC13:31
*** dims has joined #openstack-keystone13:32
*** ajayaa has joined #openstack-keystone13:33
*** sdake has joined #openstack-keystone13:35
*** sigmavirus24_awa is now known as sigmavirus2413:37
*** lhcheng has quit IRC13:38
*** nkinder has joined #openstack-keystone13:39
*** sdake has quit IRC13:40
*** rushil has joined #openstack-keystone13:41
*** fhubik is now known as fhubik_afk13:42
*** rushiagr is now known as rushiagr_away13:44
*** fhubik_afk is now known as fhubik13:44
amakarovdstanek, hi! Addressed your comments (sorry, haven't noticed them before) https://review.openstack.org/17300013:45
*** ajayaa has quit IRC13:49
*** joesavak has joined #openstack-keystone13:50
*** Ephur has joined #openstack-keystone13:51
*** r-daneel has joined #openstack-keystone13:52
*** fhubik is now known as fhubik_afk13:52
*** fhubik_afk is now known as fhubik13:52
*** Ephur_ has joined #openstack-keystone13:52
*** ayoung_ has joined #openstack-keystone13:53
rodrigodshenrynash, so you prefer to not delete projects that are domains unless they are leaf, right?13:54
henrynashrodigods: well, I was more reacting to the statement taht we’d never hit a domin with recurxive delete13:55
henrynashrodigods: and with a top level hierachy of projects with is_domain=True set….you clearly could hit a “domain”13:55
henrynashI’m open to what we propose we support, just want us to clear13:55
*** ashleighfarnham has joined #openstack-keystone13:56
rodrigodshenrynash, I was being specific for projects (with is_Domain false) only13:56
*** Ephur has quit IRC13:56
rodrigodsmaybe wasn't clear enough?13:56
*** sdake has joined #openstack-keystone13:57
henrynashrodigods: ah…but I don’t think going forward that’s a clear enough distinction…everything will be a project, just some of them will also be acting as domainds13:57
*** Ephur_ is now known as Ephur13:58
rodrigodshenrynash, we can't have domains that are children of "pure" projects13:58
henrynashrodigods; I think in Liberty, we’ll really be deprecating the “pure” domain concept….13:58
henrynashrodigods: agreed13:58
henrynash(hey, we both used pure at the same time!_13:59
rodrigods(heh noticed too!)13:59
henrynashso are you assuming you can issue the /cascade delete on a project with is_domain=True?13:59
rodrigodshenrynash, no... that if issue the /cascade on a "pure" project it will only have effect to "pure" projects14:00
*** dims has quit IRC14:00
rodrigodshenrynash, that's the idea of that paragraph...14:00
*** dims has joined #openstack-keystone14:00
rodrigodsbecause someone may be concerned about hitting a domain when using /cascade on a project14:00
henrynashi agree with that…but is issuing it on a project acting as domain supported?14:01
rodrigodshenrynash, yes...14:01
*** rushiagr_away is now known as rushiagr14:01
*** browne has joined #openstack-keystone14:02
henrynashok, so in that case…..you *could* hit a domain, since theere could be one immediatly underneath you with is_domain=True as well14:02
*** ajayaa has joined #openstack-keystone14:02
henrynashthat was my only point….when we say “project” now….I don’t think it implicitely means a pure project, it could be either14:03
rodrigodshenrynash, ok... so will make clear that hitting in a pure project can only affect pure projects14:03
rodrigodsand hitting on a domain can affect both14:04
*** ayoung_ has quit IRC14:04
henrynashyes….and probably need to be clear whether what happens if I have N levels of projects acting as domains beneath the point you issue teh command…so we support that and recursively delete all the sub project-domains” as well?  eeek!14:05
henrynashsounds scary to me14:05
henrynashwhich was my point about a leaf project-domain14:05
rodrigodsmy idea was to permit only to "cloud_admins"14:06
rodrigodsthe god of the cloud heh14:06
henrynashwell, that’s a policy descsion, not an API decision14:06
rodrigodsyes... so why we'd limit the API if it is possible to properly prohibit the action in the policy14:06
rodrigodsbut... as first step I'd agree to leave only for "leaf domains"14:07
henrynashunderstand the principle, but in practice we never encode policy rules (or roles) into our code....14:07
henrynashI think that maybe that might be wise :-)14:08
rodrigodswill update the spec14:08
*** topol has joined #openstack-keystone14:13
*** ChanServ sets mode: +v topol14:13
*** davechen1 has left #openstack-keystone14:13
*** mattamizer has joined #openstack-keystone14:18
*** markvoelker has joined #openstack-keystone14:19
*** markvoelker_ has quit IRC14:19
*** ayoung_ has joined #openstack-keystone14:19
*** mattfarina has joined #openstack-keystone14:21
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300714:22
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873014:22
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300714:29
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873014:29
*** stevemar has joined #openstack-keystone14:30
*** ChanServ sets mode: +v stevemar14:30
*** zzzeek has joined #openstack-keystone14:30
sigmavirus24stevemar: I saw you had questions14:30
stevemarsigmavirus24, yep, regarding glanceclient and another for requests. i'll write them out in a few minutes, just doing a few things right now14:31
*** diegows has joined #openstack-keystone14:31
sigmavirus24stevemar: there are fixes in play for glanceclient 0.16.1 if that's breaking nova for you14:31
*** pnavarro|off is now known as pnavarro|mtg14:32
stevemarsigmavirus24, nah, was around how images are listed14:41
stevemarsigmavirus24, looking at the v2.images.list or v1.images.list, both seem to set 'limit' by default14:42
sigmavirus24Also, re requests, #python-requests is a good welcoming place14:42
stevemarbut when i do a list images, glance's CLI seems to go past that limit14:43
*** bknudson has joined #openstack-keystone14:43
*** ChanServ sets mode: +v bknudson14:43
stevemarrgr that, re: requests14:43
sigmavirus24stevemar: hm14:44
mattamizerhello all, is there any plan to support a password reset through the API?14:44
stevemarsigmavirus24, let me link you a bug and review14:44
stevemarmattamizer, keystone does support password updates, but not resets14:45
stevemarmattamizer, there are no plans to make the identity portion of keystone any better. we don't want to be an identity provider14:45
mattamizerstevemar: update isn't really an option for us because we want Member users to be able to update their own passwords but not their domain14:45
stevemarsigmavirus24, review: https://review.openstack.org/#/c/172763/ bug is attached14:46
*** jeffDeville has joined #openstack-keystone14:46
mattamizerso it is not supported, nor are there plans to eventually support it14:46
sigmavirus24stevemar: looking14:47
mattamizerif that's the case, are there any plans to support custom TTL for tokens?14:47
*** stevemar has quit IRC14:49
*** stevemar has joined #openstack-keystone14:49
*** ChanServ sets mode: +v stevemar14:49
morganfainbergmattamizer: users can update their own passwords.14:51
morganfainbergmattamizer: there is an api for that. No plans currently for a "reset"14:51
*** thedodd has joined #openstack-keystone14:52
morganfainbergmattamizer: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#change-user-password14:54
dstanekreset seems more like something horizon would have to handle14:54
*** tobberydberg has joined #openstack-keystone14:55
morganfainbergdstanek: except horizon does not have admin rights. We would need an api and an exchange method (eg email) among other things. We said the sql backend is a toy, therefore it won't be improved. Most real idps have reset functionality (eg AD, freeipa, etc)14:56
morganfainbergAnd we don't track email or other PII in keystone as first order attributes.14:57
morganfainbergAnother issue with "reset"14:57
*** nkinder has quit IRC14:58
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300714:58
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873014:58
*** jeffDeville has quit IRC14:58
*** tobberyd_ has quit IRC14:59
dstanekmorganfainberg: yeah, since email isn't first class you couldn't do a reset because otherwise it would be a security hole14:59
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873015:00
*** fhubik has quit IRC15:00
*** tobberydberg has quit IRC15:00
dstanekreset functionality is really nothing more then a bearer token sent to a know (and hopefully secure) location for single time use15:00
rodrigodsmorganfainberg, is the reseller branch idea going to be put in practice?15:01
*** ozialien has joined #openstack-keystone15:01
openstackgerritTristan Cacqueray proposed openstack/keystonemiddleware: Fix s3_token middleware parsing insecure option  https://review.openstack.org/17336515:01
morganfainbergrodrigods: need to bug jogo.15:01
*** rushil_ has joined #openstack-keystone15:01
morganfainbergNot sure. Everyone is swamped with rc and gate ATM15:02
*** rushil has quit IRC15:02
rodrigodsmorganfainberg, k15:02
*** jeffDeville has joined #openstack-keystone15:03
*** joesavak has quit IRC15:04
mattamizermorganfainberg: the issue is we don't have their original password in all cases15:05
morganfainbergmattamizer: the user should be able to use that api.15:06
morganfainbergIt was designed so the admin would use a user update and the user would use he password change api15:06
morganfainbergBecause the admin shouldn't know the user's password.15:06
mattamizerbut if they don't know or have forgotten their original password we cannot use it, our hope was to provide reset for such a case15:06
morganfainbergWe don't have a secure way to do that.15:07
morganfainbergAnd keystone shouldn't be emailing things out.15:07
*** _cjones_ has joined #openstack-keystone15:07
morganfainbergIt would be really easy to have a reset service that knows the PII for the user (email etc) and their keystone user. If they pass the validate stage it can use super admin powers to update the password.15:08
dstanekpersonally identifiable information15:09
openstackgerritTristan Cacqueray proposed openstack/python-keystoneclient: Fix s3_token middleware parsing insecure option  https://review.openstack.org/17337015:09
mattamizerdstanek: thanks!15:09
morganfainbergUnless we have some real work done on the sql backend and/or identity management crud (which involves things such as supporting encryption of personally identifiable information -[pii]) it's something I'd like to avoid keystone being responsible for.15:09
mattamizerok, so the path forward is some external service that does the magic15:10
mattamizerthanks morganfainberg, that should be enough for us to go on :)15:10
morganfainbergIt really comes down to security. We don't have support to make a "reset" secure in keystone. And it may not be a good idea to put that ability inside keystone.15:10
dstanekis this in regards to a bug/blueprint?15:11
morganfainbergmattamizer: especially if you have a separate customer db, where you know their users/user id/ how to contact them, etc15:11
morganfainbergmattamizer: then you can ensure it is really who they say they are :)15:11
mattamizeryeah, I'm picking up what you're putting down :)15:11
morganfainbergLong term I want to see keystone's identity management crud be separate - and not let any PII leak to the other services consuming authz from keystone.15:12
mattamizermakes sense15:13
morganfainbergIt's hopes, wishes, and dreams. But I'd like to see it.15:13
*** ayoung_ has quit IRC15:13
morganfainbergBut for the most part you need 3 things for authz in openstack: user id, scope id (domain / project), and roles15:14
*** ozialien has quit IRC15:14
morganfainbergAlmost nothing else should be in the token**15:14
morganfainberg** some extra control things live there but they aren't about authz specifically but related to controls on authz15:14
mattamizerwill custom TTL on tokens be supported at some point, then?15:14
morganfainbergCustom ttl as in?15:15
morganfainbergUser requested ttl?15:15
dstanekif we had a good strategy for dealing with the existing APIs then i don't think it would be hard to separate15:15
mattamizeror one we set based on role data coming from wherever15:15
mattamizerso admin role TTL = x, Member = y, etc15:15
morganfainbergmattamizer: ah role based ttl. Not opposed to talking about it.15:16
morganfainbergNo current plans.15:16
morganfainbergI do not want a user to be able to change the ttl.15:16
morganfainbergPer token that is " my first token is ttl x, next time I get ttl y"15:16
morganfainbergCause I want it.15:17
mattamizerso ideally for us we want API tokens that never expire, but web tokens that do15:17
mattamizerso for automated scripts we have a token the we can be certain will work15:17
sigmavirus24so stevemar, looking at https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L88 I think I see your problem15:17
mattamizerbut web based tokens will expire with certainty after X time has elapsed15:17
morganfainbergmattamizer: what if we supported x509 client cert auth instead of endless ttl tokens?15:17
morganfainbergClient cert is used in lieu of a token.15:18
morganfainbergThere is an initiative to do that fwiw.15:18
mattamizerthat'd be fine for sure15:18
morganfainbergNon-expiring tokens are inherently insecure.15:19
morganfainbergSince tokens are bearer tokens.15:19
mattamizerreally we just need support for automation that doesn't require constantly getting new tokens because ours are only good for an hour15:19
mattamizerx509 would work just fine :)15:19
morganfainbergX509 could solve this since it is less likely someone can steal the private key and the cert from15:19
morganfainbergInspecting traffic / logs / etc15:19
mattamizerindeed so15:20
mattamizerany idea on if that initiative will get any traction? and if so what the timeline would look like for getting that into the codebase?15:20
stevemarsigmavirus24, oh, whats thats?15:20
morganfainbergThe other initiative is a session token (unscoped) that you can keep alive for longer than the default ttl (ask for extensions). That token can only work with keystone. You can then just ask for a scoped token anytime you need it (short ttl)15:21
sigmavirus24So previously we didn't send a page_size and now we always send one, (we default to a global DEFAULT)15:21
sigmavirus24And we do it all the time, so you can't even pass page_size=None to prevent that from happening15:21
mattamizermorganfainberg: I think x509 would be preferable to that15:21
morganfainbergmattamizer: the x509 stuff is planned this cycle at least for service users (how nova talks to keystone to validate a token)15:21
sigmavirus24We also, I think, always pass a limit in that method which can be the page_size15:21
morganfainbergmattamizer: the options are not mutually exclusive. The session token works well for real users too.15:22
stevemarsigmavirus24, yeah, it definitely always adds a limit now15:22
sigmavirus24stevemar: there's also https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L12915:22
mattamizerso is Liberty the target for that, then?15:23
morganfainbergmattamizer: using an x509 cert directly with an endpoint is a bit more difficult because auth_token middleware doesn't know x509. But at the very least it is likely you can do x509 to keystone any time you need to this cycle for a new token.15:23
tristanCHi folks, I've submitted fix for bug 1411063 using this changeId: Id674f40532215788675c97a8fdfa91d4420347b315:23
openstackbug 1411063 in keystonemiddleware "S3token incorrect condition expression for ssl_insecure (CVE-2015-1852)" [Critical,In progress] https://launchpad.net/bugs/1411063 - Assigned to Tristan Cacqueray (tristan-cacqueray)15:23
mattamizermorganfainberg: that's great15:23
morganfainbergtristanC: saw it. On the short list to hit - provided we can land code (had issues with stable branches)15:23
sigmavirus24that list method is terrible too stevemar15:24
sigmavirus24so I'm sorry it's so cryptic15:24
morganfainbergtristanC: we will also need to backport to a 1.5.x minor release for stable branches. I'll make sure we look at that today.15:24
morganfainbergAnd I think 1.3.x?15:25
sigmavirus24stevemar: if limit is None, then we make the request with the filters defined (where we set limit to page_size) and always use teh URL https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L10015:25
morganfainbergmattamizer: I know hp wants x509 support. So we have some engineering behind it for Liberty. :)15:25
sigmavirus24stevemar: so yeah, the problem is that we default the limit to the page_size15:26
sigmavirus24(And that's on the v2 side)15:26
mattamizermorganfainberg: excellent :)15:26
stevemarsigmavirus24, it's also defaulted on the v1 side :)15:26
*** ayoung_ has joined #openstack-keystone15:26
sigmavirus24stevemar: yeah I hadn't looked there yet ;)15:26
tristanCmorganfainberg: as far as I know, security fix are only required on master and stable branches... It's still a bit fuzzy to me how to handle 1.3.x15:27
morganfainbergtristanC: 1.3.x is stable/icehouse 1.5.x is Juno I think.15:27
morganfainbergOh wait no15:27
stevemarsigmavirus24, was that change recently added? cause using the installed/latest version from pypi, performing a list returns >30 images15:27
morganfainbergNo icehouse stable. 1.3.x is Juno.15:27
stevemarbut using osc, it returns only 25 images15:28
bknudsonI was wondering about that... we'll have fix in 1.3.1 and 1.6 but not 1.4.1?15:28
morganfainbergtristanC: this happened like Friday.15:28
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300015:28
morganfainbergbknudson: I think we're going to do 2.x for Liberty.15:28
bknudsonpatching every release seems like overkill15:28
tristanCalso by the way, I had trouble to submit this change for those new stable branch as they are not referenced in their .gitreview  I had to specify them manually on "git review" comment15:28
*** diegows has quit IRC15:28
sigmavirus24stevemar: you mean, doing "glance image-list" will return > 30 images?15:28
stevemarsigmavirus24, yep15:28
morganfainbergbknudson: so we semver for the major releases.15:28
sigmavirus24stevemar: it was added in the last ~1-2 months15:29
morganfainbergbknudson: it's .. Not as clean as releas whenever. But at least we know the maintenance cycle.15:29
sigmavirus24stevemar: actually I'm wrong: https://github.com/openstack/python-glanceclient/commit/93c9bc1fe0ae3f5c95395e7a883fdffcc79d7151#diff-de2b001e2b66bb4fe4d42d7ce575567f15:29
morganfainbergbknudson: unless you have a good reason we shouldn't do that.15:30
bknudsonmorganfainberg: why 2.x? are we removing function?15:30
sigmavirus24stevemar: looks like that first went into 0.16.015:30
*** krykowski has quit IRC15:31
morganfainbergNo, because it (due to g-r) likely won't be compat with kilo. And because we then can do backports as needed.15:31
bknudsonWe're incrementing minor for dependency changes.15:31
morganfainberg2.x is Liberty, 1.3.x is Juno (the special case), 1.5.x++ = kilo15:32
bknudsonwhy not call it 2015.1?15:32
morganfainbergBecause this is where I get to be ptl and say I hate that versioning scheme ;)15:32
bknudsonI think dhellmann was going to go with a minor change for L.15:32
bknudsonyou mentioned 1.3 and 1.5, what about 1.4?15:33
morganfainbergHonestly you can't expect anything past the Juno ship to work with Juno services.15:33
morganfainbergKsm might as well just be shipped as the 2015.x "Juno" or whatever.15:33
ayoung_henrynash, you already +2ed this, but he did a minor cleanup.  Wanna do the honors? https://review.openstack.org/#/c/173158/15:33
morganfainbergKeystone client is the weird one.15:34
bknudsonwith the stable branches we can actually remove function and have a ksc 2.015:34
morganfainbergbknudson: we should actually make ksm just follow the release like everyone else.15:34
bknudsonfor example we could get rid of the auth_token middleware.15:34
morganfainbergKsc "stable" branches is for gate I think.15:34
stevemarsigmavirus24, i'm still not seeing a way to tell glance "give me all the images"15:34
morganfainbergbknudson: I really want to do that.15:34
*** ayoung_ is now known as ayoung15:34
sigmavirus24stevemar: me too15:34
morganfainbergbknudson: and drop the cli15:35
henrynashayoung: looking15:35
sigmavirus24stevemar: I think I'm going to ask in #openstack-glance since I'm still half-dead from yesterday15:35
sigmavirus24stevemar: care to join me?15:35
morganfainbergbknudson: and when keystoneauth becomes split out, session etc too15:35
stevemarsigmavirus24, of course15:35
morganfainbergbknudson: but I was told "don't do that" put breaking changes in sdk15:35
morganfainbergSo unless we make Python-keystoneclient2 I think we lose here. :(15:36
bknudsonmorganfainberg: auth_token isn't going to be in sdk.15:36
henrynashayoung: done15:36
bknudsonkeystone CLI isn't going to be in sdk.15:36
morganfainbergbknudson: but keystone client will just die with sdk, right?15:36
morganfainbergActually I'm ok dropping auth_token this cycle from ksc. You can't run modern ksc auth_token in grizzly etc,15:37
bknudsonI guess so... need to start working on sdk like crazy then.15:37
morganfainbergThe requirements conflicts prevent it.15:37
stevemaryeah, it'll be a metric ton of things15:37
morganfainbergWe're safe dropping it15:37
morganfainbergbknudson: for ksm, we should probably move it to standard named release15:39
morganfainbergSince it is really only compatible with the release it shipped with.15:39
morganfainbergMeaning... Dropping semver15:39
bknudson... we've got some work to do to get keystoneclient stable/icehouse working.15:40
morganfainbergSince it uses the same interpreter as the service (aka nova)15:40
bknudsonstrange that python26 worked but not 27?15:40
morganfainbergI need to bring up how much this stable branch thing for clients basically makes semver useless.15:41
morganfainbergIssue with interpreter and differing lib versions.15:42
morganfainbergSince clients are cli, client libs, and inter-service15:42
*** gyee has joined #openstack-keystone15:42
*** ChanServ sets mode: +v gyee15:42
*** ajayaa has quit IRC15:42
morganfainbergWe mixed too many things into one package.15:42
morganfainbergOsc owns cli. Inter-service should be separate from the user-consuming client lib.15:43
morganfainbergWe did it wrong across the board.15:43
*** markvoelker has quit IRC15:44
*** ajayaa has joined #openstack-keystone15:46
*** stevemar has quit IRC15:49
*** stevemar has joined #openstack-keystone15:49
*** ChanServ sets mode: +v stevemar15:49
*** jistr has quit IRC15:51
openstackgerritMerged openstack/oslo.policy: Fix invalid indentation in _load_policy_file method  https://review.openstack.org/17327515:56
*** jeffDeville has quit IRC15:56
*** krtaylor has quit IRC15:57
*** tobberydberg has joined #openstack-keystone15:58
*** edmondsw has joined #openstack-keystone15:58
*** jeffDeville has joined #openstack-keystone16:00
*** erkules_ has joined #openstack-keystone16:02
*** erkules has quit IRC16:02
*** tobberydberg has quit IRC16:04
*** joesavak has joined #openstack-keystone16:04
*** bdossant has quit IRC16:05
morganfainbergRc2 will open tomorrow.16:07
davidckennedyhenrynash thanks for the review on https://review.openstack.org/#/c/153296/ you've higlighted something that needs addressing but maybe not for the reason that you thought.  I'd welcome your thoughts on my return comments.  The spec needs to be mentioned in the commit message, I will do that but for now it's at16:07
*** mattamizer has quit IRC16:08
*** joesavak has quit IRC16:11
*** sdake_ has joined #openstack-keystone16:12
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873016:13
ayoungmorganfainberg, henrynash stevemar can we fast track the tests spec template:  https://review.openstack.org/#/c/163882/ I'd be ok with comitting to major rewrites of it once it is in, but not having it means we can't get people to write test specs16:14
*** markvoelker has joined #openstack-keystone16:14
ayoungand I really want to start beating up my QE team to write test specs16:15
*** rushil_ has quit IRC16:15
ayoungdstanek, you too ^^16:15
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873016:15
morganfainbergayoung: 116:15
morganfainbergMajor comment16:15
ayoungtopol, actually, since it is in specs, if you could look at it, I think you will agree it is important:   https://review.openstack.org/14873016:15
*** sdake has quit IRC16:15
rodrigodsgyee, ^ remember you had some concerns in the recursive deletion spec16:16
morganfainbergDon't put the template in the dir. We want the templates in the repo but not rendered as part of the final docs.16:16
ayoungmorganfainberg, can we do this:16:16
ayoungput it in the repo so it renders , get at least one test spec in, move the template out16:16
ayoungit menas we dpn't need to mess witht the TOC on the first test review16:17
topolHi ayoung, what did you want me to look at?16:17
morganfainbergYeah don't mess with the toc in that case16:17
ayoungtopol, test spec.    https://review.openstack.org/14873016:17
morganfainbergToc should be updated when we have real content in there.16:17
ayoungmorganfainberg, I will take that as a todo once it is in16:17
morganfainbergYou also have erroneous white space in the index.rst16:18
morganfainbergI have not reviewed the template16:18
morganfainbergSo will do before scoring the review.16:18
topolayoung, ok will do16:18
morganfainbergThese were the two things that came to mind at a glance.16:18
ayoungmorganfainberg, topol -1s gladly welcome, just so long as we can move it16:19
*** ajayaa has quit IRC16:20
gyeerodrigods, yes, I am commenting on the recursive spec16:21
gyeegive me a few more mins16:21
*** jeffDeville has quit IRC16:22
rodrigodsgyee, k16:24
rodrigodsbtw... there are two patches waiting so we can have "official" support to GET /projects?parent_id=<>16:26
rodrigodsand https://review.openstack.org/#/c/158314/16:26
*** markvoelker has quit IRC16:26
rodrigodshenrynash, ^16:26
dstanekayoung: so that is something to do in addition to a spec?16:29
gyeerodrigods, see my comments, I have two concerns there16:31
*** lhcheng has joined #openstack-keystone16:32
*** ChanServ sets mode: +v lhcheng16:32
gyeeotherwise, mostly good16:32
dstanekayoung: so i wonder why we don't have tests plans part of the code repository instead of the spec repository. seems like really good developer documentation16:34
openstackgerritMerged openstack/keystone: Checking if Trust exists should be DRY  https://review.openstack.org/17315816:36
rodrigodsgyee, thanks! replied16:38
gyeerodrigods, I am still not seeing the benefits of recursive disable16:40
david-lylegyee, it'll come around to you16:41
gyeesay I have A -> B -> C -> D, disabling B effectively disables B, C and D16:41
* david-lyle see what I did there ;)16:41
rodrigodsgyee, we can't disable A16:42
rodrigodsgyee, allowing this kind of behavior would make us to traverse the hierarchy in every token validation, etc16:42
gyeein that scenario, disabling B does not disable A16:42
*** joesavak has joined #openstack-keystone16:42
gyeerodrigods, no need, its all in a single event16:43
rodrigodsif I disable A, and I want to validate a token for B16:43
gyeethe hierarchy should be in the event16:43
rodrigodsI'd need to go through the hierarchy to check if there are disabled parents16:43
gyeeyes, or have the hierarchy in the event16:43
gyeeread is relatively in expensive compare to write16:44
gyeerevocation event16:44
gyeedisable generates a revocation event16:44
rodrigodsuuid and fernet tokens are validated against revocation events?16:44
gyeerodrigods, think scale, performance, multi datacenters :)16:45
gyeeyou want to avoid write in favor of read if you can16:46
rodrigodsgyee, exactly... but I don't see the advantage of trading a one time write to include lots of data in the event16:46
amakarovrodrigods, hi. Have you considered to introduce materialized path in the hierarchy? It will allow to avoid recursion16:47
gyeeits not a one-time write, its a collections of writes16:47
rodrigodsamakarov, yes... I'd be glad to help you in a spec for such redesign16:47
rodrigodsamakarov, check http://dolphm.com/hierarchical-multitenancy/16:48
amakarovrodrigods, ok, I'll do it. Is there any to modify or I need to create a new one?16:48
rodrigodsamakarov, the recursive deletion one does not depend on implementation, so I'd say a new one16:49
* amakarov reading...16:49
rodrigodsgyee, a collection of one time writes heh16:49
rodrigodsyou do a lot of writes once16:49
rodrigodsthan everything is straightforward to check16:49
rodrigodsgyee, besides that... our current API prohibit to disable a project with enabled children... think that changing this may break the API stability?16:51
gyeebut you can easily avoid write16:51
*** jeffDeville has joined #openstack-keystone16:51
rodrigodsgyee, in every project related call (like get_project, issuing tokens, listing projects for user...), we read up the hierarchy to check if is there a disabled parent16:53
rodrigodswe'd need*16:54
gyeewe currently don't individually disable the users when the domain is disabled16:54
gyeeotherwise, it would be rather expensive16:54
rodrigodsgyee, yeah... I think you are making me to think like you16:55
gyeewith revocation events, we really don't need to walk to tree if we store the hierarchy along with the event16:56
gyeemaybe you can even check the project status by looking at the events16:58
rodrigodsgyee, but we'd return that B is enabled in the get_project?16:58
ayoungdstanek, they need to be in some repository.  If specs get their own repos, test specs belong with them.16:58
ayoungNo reason that the codre repo can't have a reference to it16:58
*** harlowja has joined #openstack-keystone16:59
gyeerodrigods, sure17:00
rodrigodsgyee, ok... so my last concerns are: what is the status of revocation events, remember it had some issues... and, can we allow a call to not return an error after the API returned an error? (see https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#update-project)17:02
gyeerevocation has to work, or we don't have a non-persistent token story :)17:03
gyeerevocation events17:03
rodrigodsgyee, k... and about the API stability17:04
rodrigodswhat* about17:04
gyeehave faith man :)17:04
rodrigodsheh :)17:04
*** joesavak has quit IRC17:05
*** tqtran has joined #openstack-keystone17:05
*** sdake has joined #openstack-keystone17:07
*** sdake_ has quit IRC17:11
tristanCPlease correct me if I'm wrong, for Kilo first release, keystonemiddleware will be 1.6.0 and python-keystoneclient will be 1.4.0 right ?17:11
* tristanC is trying to understand what versions will include fixes for bug 141106317:12
openstackbug 1411063 in keystonemiddleware "S3token incorrect condition expression for ssl_insecure (CVE-2015-1852)" [Critical,In progress] https://launchpad.net/bugs/1411063 - Assigned to Tristan Cacqueray (tristan-cacqueray)17:12
gyeeI thought keystonemiddleware started at 1.0.017:12
rodrigodsgyee, replied in the spec review, cited the concern regarding API stability17:13
*** joesavak has joined #openstack-keystone17:14
*** sdake_ has joined #openstack-keystone17:14
gyeewhat?! we don't allow disabling a project with an enabled child?17:15
openstackgerritMerged openstack/python-keystoneclient: Fix s3_token middleware parsing insecure option  https://review.openstack.org/17337017:16
rodrigodsgyee, yep... the revocation events solution wasn't cited in the time we implemented :)17:16
* gyee cries17:17
*** sdake has quit IRC17:18
*** aix has quit IRC17:18
rodrigodsmorganfainberg, can you give your opinion here ^?17:18
*** alexsyip has joined #openstack-keystone17:18
morganfainbergLet me look once I've gotten food.17:19
morganfainbergAnd coffee.17:19
rodrigodsmorganfainberg, k17:19
morganfainbergTrying to eat pre-meeting for a change.17:19
openstackgerritAlexander Makarov proposed openstack/keystone-specs: Materialized path for project hierarchy  https://review.openstack.org/17342417:20
amakarovrodrigods, ^^17:20
gyeeamakarov, ++, that's what was suggested at the beginning17:21
rodrigodsamakarov, nice!17:21
morganfainbergGyee we have to fix revocation events as the default before we can do disable with enabled children.17:22
morganfainberggyee: still not in ksm17:22
gyeemorganfainberg, yes17:22
amakarovmorganfainberg, hi! btw Horizon folks already started to whine about group revocation again :)17:23
morganfainbergamakarov: they can whine all they want. We can work on fixing it in Liberty.17:23
gyeewhat's issue with group revocation?17:23
morganfainberggyee: groups not in token. We can't issue an event for it.17:24
amakarovgyee, https://review.openstack.org/#/c/141854/17:24
morganfainbergTherefore we revoke all tokens for the user.17:24
amakarovand it is way too heavy17:24
lhchengmorganfainberg: does this sounds like a rc-potential: https://bugs.launchpad.net/keystone/+bug/144049317:25
openstackLaunchpad bug 1440493 in Keystone "Crash with python-memcached==1.5.4" [Undecided,In progress] - Assigned to Alexander Makarov (amakarov)17:25
dolphmdidn't we agree to add the list of groups to the token validation response?17:25
gyeeI am fine with that17:26
amakarovlhcheng, I still owe a test there17:26
openstackgerritAlexander Makarov proposed openstack/keystone-specs: Materialized path for project hierarchy  https://review.openstack.org/17342417:27
lhchengamakarov: yup, just trying to figure out if we should tag for rc-potential17:27
morganfainbergdolphm: I think we did17:29
morganfainbergdolphm: it's just not done yet.17:29
morganfainberglhcheng: that might be a requirements freeze update.17:30
gyeeamakarov, operationally, how often do you think one change the permissions of a group?17:30
*** browne has quit IRC17:30
morganfainbergNeed to bug ttx asap. Sec17:30
openstackgerritayoung proposed openstack/keystone-specs: Template for testing document  https://review.openstack.org/16388217:30
ayoungdstanek, thanks for that review.17:30
*** sigmavirus24 is now known as sigmavirus24_awa17:30
rodrigodsgyee, so we do not need the recursive disabling API, but we need to add ksm support, right?17:30
rodrigodsksm support to revocation events17:31
*** sdake has joined #openstack-keystone17:31
morganfainberglhcheng: so that is a crappy workaround. And will impact ksm as well I think.17:31
*** jeffDeville has quit IRC17:31
morganfainberglhcheng: yes that is rc-potential.17:32
lhchengmorganfainberg: cool, thanks for checking17:32
amakarovgyee, as for me - not often, as for the user - he'll definitely do the worst thing you hoped he'll avoid :)17:33
lhchengmorganfainberg: good call on adding ksm too17:34
*** sdake_ has quit IRC17:35
gyeeyes, ksm definitely need to support revocation events17:35
gyeerodrigods, ^^17:35
gyeedon't think we have much of a choice here17:35
*** jeffDeville has joined #openstack-keystone17:36
*** boris-42 has quit IRC17:38
*** rushil has joined #openstack-keystone17:39
dolphmdoes sqlite do a decent job with indexes?17:39
*** ajayaa has joined #openstack-keystone17:40
*** sdake_ has joined #openstack-keystone17:44
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300717:45
raildotopol, ^ :)17:45
*** sdake has quit IRC17:45
dstanekdolphm: compared to what?17:45
dolphmdstanek: i'm just curious if there are any well known caveats with sqlite indexes vs other databases. wondering how the revocation tree implementation would compare against an in-memory indexed cache of revocation events using sqlite17:47
*** sdake_ has quit IRC17:48
*** sdake has joined #openstack-keystone17:48
*** diegows has joined #openstack-keystone17:49
topolraildo, you left the last change a s a run on sentence :-)17:49
dstanekdolphm: other than having to manually turn on foreign keys, i haven't noticed too much of a difference between it and mysql - but i'm not much of a power user of either17:49
topolraildo, the comma needs to be a period. Or I would have accepted a semi-colon. I wrote it for you. copy paste friend :-)17:50
topolraildo, and then Im a +217:50
raildojust 1 min17:51
*** jeffDeville has quit IRC17:51
topolraildo, I'm being picky because it is the API doc. If it was just a spec I would not have worried about it17:51
*** jaosorior has quit IRC17:52
*** sdake has quit IRC17:52
*** sdake has joined #openstack-keystone17:52
raildotopol, and you're right, this is my fault :)17:52
topolraildo, no worries and an easy fix17:53
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300717:56
*** davechen has joined #openstack-keystone17:57
*** jeffDeville has joined #openstack-keystone18:00
lhchengwhen creating a grant the already exists, the backend silently fails in: https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L130-L13118:01
lhchengis that by design?18:01
lhchengfor v2, we raise an exception when a duplicate role assignment is made.18:01
*** ptoohill has quit IRC18:03
*** ajayaa has quit IRC18:04
lhchengwondering if anyone recalls why creating duplicate grants should fail silently (there might be a good reason behind it that I overlooked)18:04
*** amaurymedeiros has quit IRC18:05
*** jamielennox|away is now known as jamielennox18:05
*** ptoohill has joined #openstack-keystone18:08
*** amaurymedeiros has joined #openstack-keystone18:10
*** amaurymedeiros has quit IRC18:10
*** amaurymedeiros has joined #openstack-keystone18:10
*** nkinder has joined #openstack-keystone18:13
*** sigmavirus24_awa is now known as sigmavirus2418:16
*** amolock has joined #openstack-keystone18:16
openstackgerritAlexander Makarov proposed openstack/keystone: Make memcache client reusable across threads  https://review.openstack.org/17083518:20
*** tellesnobrega has quit IRC18:25
*** markvoelker has joined #openstack-keystone18:25
*** sdake_ has joined #openstack-keystone18:25
*** tellesnobrega has joined #openstack-keystone18:26
*** tellesnobrega_ has joined #openstack-keystone18:27
*** tellesnobrega_ has quit IRC18:27
rodrigodshaneef, replied you in https://review.openstack.org/#/c/153007/18:27
haneefI will have a look at it18:28
*** sdake has quit IRC18:29
*** tobberydberg has joined #openstack-keystone18:29
*** tellesnobrega has quit IRC18:29
*** tellesnobrega has joined #openstack-keystone18:29
haneefrodrigods: Sorry , I added that in different patchset. Fixed it18:31
*** markvoelker has quit IRC18:31
rodrigodshaneef, thanks18:31
openstackgerritAlexander Makarov proposed openstack/keystone: Redis cache backend  https://review.openstack.org/17300018:31
rodrigodshaneef, replied... basically the is_domain field is only if you want to request a project scoped token to a project with the is_Domain flag enabled18:33
*** tqtran has quit IRC18:34
*** jeffDeville has quit IRC18:34
*** rushil has quit IRC18:34
*** jeffDevi_ has joined #openstack-keystone18:36
haneefrodrigods:  May be I missed some stuff. Why do I want to do that? How are going to distinguish between project and domain roles?  e.g a user has a role X on  project which is a domain.  Is it a domain role or project role or it doesn't matter?18:38
rodrigodshaneef, right... i think this API spec doesn't consider merging the assignments types yet18:39
*** sdake has joined #openstack-keystone18:39
haneefrodrigods: so the answer is , it doesn't matter18:40
rodrigodshaneef, no.. it does matter. If we have different assignments types we may have different roles18:41
haneefSo basically ,  with is_domain flag you are going to send  project roles  assignment only. Is that correct?18:42
rodrigodshaneef, correct18:43
*** sdake_ has quit IRC18:43
amakarovrodrigods, I've missed something: where exactly do I have to add my spec? :)18:45
rodrigodsamakarov, https://etherpad.openstack.org/p/keystone-liberty-priority-specs18:45
*** tobberydberg has quit IRC18:45
*** browne has joined #openstack-keystone18:45
amakarovrodrigods, as minor under reseller?18:46
rodrigodsamakarov, I'd say in the performance topic18:46
rodrigodsnot sure, though18:46
amakarovrodrigods, I think greater minds will sort things out :)18:47
rodrigodshaneef, are you ok with the change as it is? (I mean, after addressing henrynash comments)18:47
haneefThe way openstack uses roles, basically I need to add two role assignment with "admin"  role  for a project  which is a domain in order to use it as domain and project .  Unfortunately this is very bad UX. This is very difficult to explain in documentation18:47
rodrigodshaneef, agreed, that's why we are going to submit the dual scoped spec to address this18:48
haneefrodrigods: We are going to get a question, saying I have "admin" role for user on project, still  keystone apis doesn't work.  The answer is, add one more "admin" role for the project using "domain" role assignment18:49
rodrigodshaneef, but this is the current behavior, right?18:50
rodrigodsalthough it is also a project, by the current API domains and projects are treated separately18:50
haneefIn current domain is "different id " and project is "different id". Now we are  going to have same id since project is a domain18:50
*** jeffDevi_ has quit IRC18:51
henrynashrodigods: one concern, if we are going to introduce dual scoped tokens later…how is it that I will know if I get one of not…is it a diferent API….although I have been skeptical of them, I think the obvious place to issue one is when specifing an is_domain=True project18:52
rodrigodshaneef, yes... but they will be different entities, unless you update a project to be a domain18:52
rodrigodshenrynash, I'd say in the domain request...18:52
rodrigodsbut... have no strong preference18:52
henrynashrodigods: interesting….I think the opposite18:52
rodrigodsbtw, our fault to approve reseller without the API18:53
rodrigodsnow I'm inclined to send all API changes in the dual scoped spec review18:53
henrynashrodigods: i think the goal of dual scoped is to allow people who understand project tokens (i.e. everyone) to not have to also do domain toekns18:53
rodrigodshenrynash, good point!18:54
rodrigodshenrynash, but they'd need to update the request anyway18:54
haneefhenrynash: basically in that case, u consider domain role assignment is same as project role assignment.  Is that correct?18:55
rodrigodsto add the is_domain field18:55
henrynashrodigods: not if the specifiy project by ID18:55
rodrigodshenrynash, hmm too many types of requests to keep in mind heh18:55
rodrigodsmakes sense18:55
rodrigodsso I'd say we return dual scoped tokens in both domain and project requests18:56
rodrigodsto is_domain projects18:56
henrynashrodigods: no, I’d say explict domain scoped requests should stay that way18:56
rodrigodshenrynash, why?18:56
henrynashrodigods: i.e. they DON’T contain the project ID…..18:56
rodrigodsto keep domain API "intact" ?18:57
henrynashrodigods: yes, I think we just freeze teh current domain idea18:57
henrynashrodigods: and over time everyone moves to using the project API18:57
rodrigodshenrynash, ok.. agreed18:57
*** dtroyer_zz has quit IRC18:58
*** dtroyer has joined #openstack-keystone18:58
raildohaneef, the main benefit to provide a dual scoped token is use the same token in other services without rescope then.18:58
rodrigodshenrynash, so what do you think about sending the API changes and dual scoped tokens spec all together?18:58
rodrigodsor at least, API changes depending in the dual scoped tokens spec18:59
*** amakarov is now known as amakarov_away18:59
henrynashrodigods: i’m coming round to that idea…in that the example we give in the API of gettinga token to an is_domain project is the obvious example of where you would get a dual scoped token19:00
raildohaneef, today with the actual api, if I request a domain scoped token, and I want to use in Nova, for example, we need to get other project scoped token.19:00
jamielennoxi like that the cleanup/tech debt fixup list is longer than the new features list for this cycle19:00
morganfainbergjamielennox, that is my goal :)19:00
jamielennoxwell not good we have so many, but good they'll get attention19:00
morganfainbergjamielennox, a lot of these are already in flight too19:01
morganfainbergjamielennox, or things that have already been started over a few cycles.19:01
haneefralido:  What is going to happen in dual scoped token for this?  e.g a user has a role X on  project which is a domain.  Is it a domain role or project role or it doesn't matter?19:01
gyeehaneef, so in the case, project_id is the same as domain_id, role assignment shouldn't matter right?19:02
gyeethey are essentially the same19:02
raildohaneef, the our first ideia is provide just one type for role, just for projects.19:02
raildogyee, ++19:02
*** jeffDeville has joined #openstack-keystone19:04
gyeeI agree the API needs to consolidate, but under the hood, the function the same19:04
*** davechen1 has joined #openstack-keystone19:05
morganfainbergi did notice no-downtime upgrades wasn't on the list >.>19:05
* morganfainberg doesn't know if there is a real win to no-downtime upgrades at this point19:05
morganfainberge.g. supporting schema -1 in the backend.19:05
*** davechen has quit IRC19:06
morganfainbergok i need to run an errand.19:06
*** davechen1 has left #openstack-keystone19:06
rodrigodsmorganfainberg, one of the meeting topics was to check if https://review.openstack.org/#/c/172536/ and https://review.openstack.org/#/c/172562/ needs specs19:07
rodrigodsI'm really inclined to opinion that the bugs are enough19:07
*** vilobhmm11 has joined #openstack-keystone19:07
rodrigodshenrynash, context changing ^19:08
morganfainbergthose are typically done out of band of the meeting19:08
morganfainbergwe just keep it in the meeting page for ease to find them19:08
morganfainbergand so everyone sees it at least once a week19:08
rodrigodsmorganfainberg, so how can we proceed?19:09
*** rushiagr is now known as rushiagr_away19:10
morganfainbergrodrigods, get enough cores to agree on needing / not needing the spec19:11
morganfainbergthen update and reference the eavesdrop log19:11
morganfainbergrodrigods, do it here :)19:11
gyeemorganfainberg, no down time is more of networking magic :)19:11
rodrigodsmorganfainberg, cool... so do you think a spec is needed? I don't think so :)19:12
rodrigodsgyee, you too! ^19:12
rodrigodslhcheng was reviewing the first patch of the chain19:12
gyeerodrigods, you mean adding stuff to assertion?19:13
rodrigodsgyee, yes... because right now we can't differentiate users and projects from different domains19:13
gyeethat one needs spec as it affects external interface19:13
gyeenow I need to account for it in mapping19:14
rodrigodsgyee, why it affects?19:14
*** ptoohill has quit IRC19:14
rodrigodsgyee, ok.. but if you had an old mapping19:14
rodrigodsit won't affect19:14
gyeeI'll have to update the mapping to remove ambiguity right?19:15
rodrigodsgyee, yes... if you want to :)19:15
*** jeffDeville has quit IRC19:16
*** diegows has quit IRC19:16
gyeehave to if I can't guarantee all usernames are unique19:16
morganfainbergfor the stevedore to load drivers, i don't think a spec is needed19:16
morganfainbergbknudson, ^19:16
morganfainbergbknudson, confirm with the rest of the team but i'm ok with it as is.19:17
morganfainbergnow i need to run for an errand19:17
rodrigodsgyee, my point is that you were never able to do so... now we are fixing this so you can differentiate if you want...19:17
rodrigodsit won't break anything19:17
bknudsonI might write up a spec anyways after having written the code... will provide useful source for docs.19:18
gyeerodrigods, actually it would be an OSSA/N if we can't guarantee usernames are unique from a given IdP19:19
rodrigodsgyee, OSSA/N? ;)19:19
gyeeopenstack security advisory I think19:20
*** ptoohill has joined #openstack-keystone19:20
rodrigodsit is definitely a security issue19:21
*** jeffDeville has joined #openstack-keystone19:21
rodrigodsgyee, how do I proceed?19:21
gyeerodrigods, put up a spec and articulate what its for and how to utilize it19:22
rodrigodsgyee, :( was really hoping that it could land in Kilo since the code is really simple and implemented19:22
gyeeit should be there for a good reason19:22
*** aix has joined #openstack-keystone19:23
gyeeidentity attributes are part of the auth payload so we should clearly document them19:23
lhchengrodrigods: is this bug still valid? https://bugs.launchpad.net/keystone/+bug/139731819:25
openstackLaunchpad bug 1397318 in Keystone "Wrong return code for inherited project role checking" [Undecided,In progress] - Assigned to Rodrigo Duarte (rodrigodsousa)19:25
rodrigodslhcheng, we had a discussion whether it should be 200 or 204, but I remember the APIs had conflicted returns19:25
rodrigodsAPI docs19:25
*** jeffDeville has quit IRC19:26
rodrigodsgyee, document in the API spec?19:26
lhchengrodrigods: okay, seems like there is still some work needed to cleanup the API docs. I'll leave it open then19:27
*** markvoelker has joined #openstack-keystone19:29
gyeerodrigods, configure_federation.rst?19:31
*** _cjones_ has quit IRC19:33
*** markvoelker has quit IRC19:34
*** sdake_ has joined #openstack-keystone19:37
*** _cjones_ has joined #openstack-keystone19:37
dstaneki just ran across https://review.openstack.org/#/c/173393/ - any reason it's not approved?19:37
*** carlosmarin has quit IRC19:38
*** carlosmarin has joined #openstack-keystone19:39
*** carlosmarin has quit IRC19:40
*** sdake has quit IRC19:41
bknudsondstanek: it's on proposed/kilo...19:41
bknudsonnot sure if we're supposed to be approving there.19:41
dstanekbknudson: ah, i see - we do seem to have the power :-)19:42
bknudsondstanek: morganfainberg -2d https://review.openstack.org/#/c/173115/19:43
*** _cjones_ has quit IRC19:43
*** vilobhmm11 has quit IRC19:47
*** vilobhmm1 has joined #openstack-keystone19:47
*** sdake has joined #openstack-keystone19:51
*** jeffDeville has joined #openstack-keystone19:52
*** ozialien has joined #openstack-keystone19:52
*** carlosmarin has joined #openstack-keystone19:52
*** sdake_ has quit IRC19:54
rodrigodsgyee, ok... so we don't need a spec, but update our documentation, right?20:03
*** ayoung has quit IRC20:05
*** sdake_ has joined #openstack-keystone20:05
*** sdake has quit IRC20:07
openstackgerritLin Hua Cheng proposed openstack/keystone: Make get_trust a protected method  https://review.openstack.org/17262020:12
*** ozialien has quit IRC20:12
*** _cjones_ has joined #openstack-keystone20:16
*** ayoung has joined #openstack-keystone20:17
*** ChanServ sets mode: +v ayoung20:17
*** erkules_ is now known as erkules20:19
*** sdake has joined #openstack-keystone20:23
*** jeffDeville has quit IRC20:24
*** sdake_ has quit IRC20:25
*** topol has quit IRC20:31
*** jeffDeville has joined #openstack-keystone20:32
*** tqtran has joined #openstack-keystone20:33
*** markvoelker has joined #openstack-keystone20:33
morganfainbergbknudson, dstanek, don't approve on proposed/kilo until we open the rc2 window please20:34
*** vilobhmm1 has quit IRC20:35
*** lifeless1 is now known as lifeless20:37
*** markvoelker has quit IRC20:37
*** henrynash has quit IRC20:40
*** samuel has joined #openstack-keystone20:42
dstanekmorganfainberg: ack20:42
*** tqtran has quit IRC20:44
*** jeffDeville has quit IRC20:44
*** ozialien has joined #openstack-keystone20:47
morganfainbergnkinder, ping20:49
nkindermorganfainberg: hey, what's up?20:49
morganfainbergnkinder, if i need to get something to ayoung is it better to hand it off to you and have you ship it to him (before summit) or better to just try and catch him at the summit20:49
morganfainbergnkinder, assuming you'll be around the meetup on thursday20:50
nkindermorganfainberg: I'm not going to see him until the summit20:50
nkindermorganfainberg: I'm happy to be the mule if you want, but it won't get to him any earlier than if you bring it to the summit yourself. :)20:51
morganfainbergi'll prob hand stuff off to you20:51
morganfainbergwill make it easier for me when heading to the summit20:51
morganfainbergless to carry20:51
*** ayoung has quit IRC20:55
morganfainbergsamuel, pong20:58
*** rhagarty__ has quit IRC20:58
*** raildo has quit IRC20:58
samuelmorganfainberg: regarding that bug on inherited role assignments ,,,20:58
samuelmorganfainberg: https://review.openstack.org/#/c/171596/20:58
samuelmorganfainberg: we are going to land this in rc2, right?20:59
morganfainbergsamuel, it is meant to be evaluated for rc220:59
samuelmorganfainberg: when is it ?20:59
morganfainbergRC2 opens tomorrow20:59
samuelmorganfainberg: do you need something else from me to evaluate this ?21:00
morganfainbergno we just need to land it in master21:00
morganfainbergthen make sure bug is tagged for kilo-rc-potential21:00
samuelmorganfainberg: bug #140353921:01
openstackbug 1403539 in Keystone "Can't create both inherited and direct role assignment on same entities" [Medium,In progress] https://launchpad.net/bugs/1403539 - Assigned to Samuel de Medeiros Queiroz (samueldmq)21:01
morganfainbergsamuel, just tagged it21:01
*** ashleighfarnham has quit IRC21:01
samueltagged Keystone liberty-1 "l1"21:01
morganfainbergno "tags"21:01
*** ozialien has left #openstack-keystone21:01
samuelmorganfainberg: yeah I was looking at milestone21:02
*** vilobhmm1 has joined #openstack-keystone21:02
samuelmorganfainberg:thanks for doing so, I will promptly wait for reviews21:02
*** vilobhmm1 has quit IRC21:03
*** vilobhmm1 has joined #openstack-keystone21:03
*** sigmavirus24 is now known as sigmavirus24_awa21:03
bknudsonsamueldmq: https://review.openstack.org/#/c/142472/ isn't going to work anymore since we've got a 068 migration? http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/sql/migrate_repo/versions/068_placeholder.py21:03
*** alexsyip has quit IRC21:06
samuelbknudson: sure, thanks .. I will update it21:07
samuelbknudson: btw, what those placeholder migrations are for ?21:07
bknudsonsamuel: in case we need to add a migration to kilo21:07
*** vilobhmm1 has quit IRC21:07
*** vilobhmm1 has joined #openstack-keystone21:08
openstackgerritMerged openstack/keystone-specs: Add parent_id to GET /projects  https://review.openstack.org/16632621:08
bknudsonI don't think we've ever actually used one of the placeholders?21:08
bknudsonso this might be a first.21:08
samuelbknudson: to backport a migration? sorry but I dont see the advantage of already having a placeholder ..21:09
*** joesavak has quit IRC21:10
*** pnavarro|mtg has quit IRC21:10
bknudsonsamuel: adding the placeholders gets proposed as soon as L opens... I didn't think it would get merged as quickly as it did either.21:10
dstaneksamuel: http://dolphm.com/backporting-openstack-database-migrations-to-stable-branches/21:11
samuelbknudson: yeah, I am going to read this ^21:11
samueldstanek: thanks21:11
*** ayoung has joined #openstack-keystone21:11
*** ChanServ sets mode: +v ayoung21:11
*** amolock has quit IRC21:13
*** henrynash has joined #openstack-keystone21:15
*** ChanServ sets mode: +v henrynash21:15
lhchengnkinder: ayoung: thoughts on priority of this bug report: https://bugs.launchpad.net/keystone/+bug/140963521:15
openstackLaunchpad bug 1409635 in Keystone "keystone fails to authenticate users when LDAP project_id_attribute is not CN" [Undecided,New]21:15
morganfainbergLDAP assignment21:15
rodrigodslhcheng, https://review.openstack.org/#/c/158314/ related to https://review.openstack.org/#/c/166326/21:15
morganfainbergi've really been holding back on wont fix for that21:15
morganfainbergbut we have exactly 1 person saying they use LDAP assignment [long term], and 2 orgs who are moving off it21:16
morganfainbergi'm inclined to say wont fix.21:16
morganfainbergLDAP assignment is dead.21:16
samuelmorganfainberg: btw, I thought we always had managed assignments under keystone umbrella21:16
morganfainbergand because LDAP assignment was a bunch of hacks on hacks on hacks, we can't even provide a sane migration path21:17
morganfainbergthat is a sign somerthing is *very* wrong.21:17
lhchengmorganfainberg: makes sense. I guess if there are critical bugs, it would only go as backport to stable?21:17
ayoungWon't fix21:17
*** sigmavirus24_awa is now known as sigmavirus2421:17
samuelwe already deprecated it ?21:18
lhchengayoung: thought we should still support it for stable but not for master.  (only for critical bugs)21:19
morganfainbergsamuel, yes LDAP assignment is deprecated as of Kilo21:19
morganfainberglhcheng, this afaict is a more of a pony request21:20
ayoungLDAP assignment must die21:20
morganfainberglhcheng, "hey ldap assignment doesn't do this thing, can it?"21:20
samuelayoung: yeah, and we're killing it, starting from deprecating ^21:20
samuelmorganfainberg: nice thx21:20
lhchengmorganfainberg: oh no, I don't mean this request.  More of like the general process if there are critical bug that may came up21:20
morganfainbergif it is a security bug21:20
morganfainbergyes we will fix it21:20
morganfainbergyes we will backport it21:21
lhcheng(from that 1 person :P )21:21
morganfainbergotherwise nope21:21
lhchengsounds good21:21
bknudsonwhen can LDAP assignment be removed?21:23
morganfainbergbknudson, M21:26
morganfainbergbknudson, deprecated in K, removed in M21:26
lhchengrodrigods: cool, thanks for the link, will look at it shortly.  Going through all the un-priotized LP bugs at the moment.21:26
*** mattfarina has quit IRC21:27
samuelbknudson: in this case, 68-72 are placeholders21:31
samuelbknudson: should them be the last ones on K ? in this case my patch should shifht them by 121:31
bknudsonsamuel: the first new on in L is going to be 73 then21:32
bknudsonand the backport will be 6821:32
bknudsonso we'll wind up having 2 of the same migration21:32
samuelbknudson: why backport? this will possible merge into rc221:33
bknudsonrc2 doesn't have the placeholders.21:33
bknudsonsome deployments are using trunk, so they're already at 72.21:33
bknudsonso if you put it into 68 then they won't get it.21:33
samuelif I put on 73, they wont anyway21:34
samuelif I put on 68 or 73, they will need an update anyway21:34
bknudsonif you put 73, then they'll get it since they're at 72.21:35
morganfainbergbknudson, rc2 can't have the placeholders21:36
morganfainbergoh yeah that what you were saying21:36
morganfainbergsamuel, i commented on the way to do the schema migrate + backport21:36
morganfainbergand yes it's meant to be awful21:36
bknudsonmaybe alembic makes it so much easier.21:36
morganfainbergwe should *REALLY* be needing it not "cause i like backporting"21:36
morganfainbergbknudson, it does.21:36
morganfainbergbknudson, but it's still a bit scary to do.21:37
samuelbknudson: sorry but I still didnt get it, if they are on master they need to git pull anyway21:38
samuelbknudson: which would work both ways21:38
bknudsondeployments on master are already on 72, so if you change 68 they're not going to run it.21:38
bknudsonkeystone-manage db_sync will say they're already up to date21:39
*** boris-42 has joined #openstack-keystone21:39
samuelbknudson: even if we change the 068 filename ?21:39
bknudsonsamuel: yes, sqlalchemy-migrate doesn't care about the filename.21:40
samuelbknudson: think I got it ,,, I do pull, and then run migraitons, then db_sync says the db is updated up to version X21:41
samuelbknudson: and then only run migrations starting at X+121:41
morganfainbergsamuel, yep21:41
bknudsonyes, that's how it works... there's a table that has the current version.21:41
samuelah :-)21:41
samuelmorganfainberg, bknudson thanks for sharing the knowledge :)21:42
bknudsonno problem.21:42
samuelbknudson: I will update the version on that migration tomorrow morning, when I get to my pc21:43
samuelneed to go now21:43
samuelthanks for the review21:43
*** samuel has left #openstack-keystone21:49
*** amerine has joined #openstack-keystone21:54
*** nkinder has quit IRC21:57
openstackgerritJamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin  https://review.openstack.org/17355821:59
*** topol has joined #openstack-keystone21:59
*** ChanServ sets mode: +v topol21:59
openstackgerritJamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin  https://review.openstack.org/17355822:06
*** henrynash has quit IRC22:09
*** markvoelker has joined #openstack-keystone22:10
*** markvoelker_ has joined #openstack-keystone22:10
*** markvoelker has quit IRC22:14
openstackgerritMerged openstack/keystone: Exposes bug on role assignments creation  https://review.openstack.org/17159622:18
*** henrynash has joined #openstack-keystone22:22
*** ChanServ sets mode: +v henrynash22:22
openstackgerritMerged openstack/keystone-specs: Adds a spec for fixing Keystone's DI  https://review.openstack.org/13593122:24
*** markvoelker has joined #openstack-keystone22:36
*** thedodd has quit IRC22:36
*** markvoelker_ has quit IRC22:37
*** leonchio_ has joined #openstack-keystone22:37
*** markvoelker_ has joined #openstack-keystone22:41
lhchengmorganfainberg: does this sounds like an rc potential? https://bugs.launchpad.net/keystone/+bug/143632422:43
openstackLaunchpad bug 1436324 in Keystone "Keystone is not HA with memcache as token persistence driver" [Medium,In progress] - Assigned to Boris Bobrov (bbobrov)22:43
lhchengthe patch deprecates memcache as token persistence backend for Kilo22:43
*** markvoelker has quit IRC22:44
lhchengnot a high priority, but something we'd like to deprecate sooner22:44
jlkleonchio_: ping, howdy!22:50
leonchio_@jlk hey jesse how's going?22:52
jlkleonchio_: you know, busy as usual. only 3 or 4 simultaneous things going on this afternoon, so light load :)22:52
*** alexsyip has joined #openstack-keystone22:53
*** edmondsw has quit IRC22:57
*** sigmavirus24 is now known as sigmavirus24_awa22:59
*** nkinder has joined #openstack-keystone23:01
*** henrynash has quit IRC23:06
*** bknudson has quit IRC23:07
*** zzzeek has quit IRC23:10
*** chlong has joined #openstack-keystone23:10
*** gordc has quit IRC23:11
*** topol has quit IRC23:20
morganfainberglhcheng, no not RC candidate23:25
morganfainberglhcheng, that is a fundamental problem with how memcache persistence works and a known long standing issue23:25
openstackgerritMerged openstack/keystonemiddleware: Fix s3_token middleware parsing insecure option  https://review.openstack.org/17336523:25
morganfainberglhcheng, i'd kill memcache persistence but people use it.23:25
lhchengmorganfainberg: if people use it.. yeah, I understand not to push for RC.23:28
dstanekare we interested in fixing https://bugs.launchpad.net/keystone/+bug/1333712 ?23:31
openstackLaunchpad bug 1333712 in Keystone "NotImplemented _for_groups functions on LDAP" [Wishlist,In progress] - Assigned to Marcos Lobo (marcos-fermin-lobo)23:31
morganfainbergdstanek, uhm... sec23:31
morganfainbergok this isn't clear... this looks like another LDAP assignment bug23:32
morganfainbergso my answer is the same as for the other one23:33
morganfainbergdstanek, no.23:33
*** ayoung has quit IRC23:33
morganfainbergiirc CERN is moving off LDAP assignment23:33
dstanekok, i'll make it as won't fix23:34
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Prompt for password on CLI if not provided  https://review.openstack.org/17360523:37
lhchengmorganfainberg: this sounds like a good candidate for rc: https://bugs.launchpad.net/keystone/+bug/140105723:43
openstackLaunchpad bug 1401057 in Keystone "Direct mapping in mapping rules don't work with keywords" [High,In progress] - Assigned to Marek Denis (marek-denis)23:43
*** chlong has quit IRC23:43
*** chlong has joined #openstack-keystone23:45
dstaneklhcheng: why do you think that?23:46
lhchengdstanek: lack of support for remote rules in the mapping engine..23:49
lhchengdstanek: hmm reading the comments on the patch, seems like it has already been decided to move to L23:49
lhchengdstanek: should be fine to leave it as is then23:50
dstaneklhcheng: ah, ok23:51
*** markvoelker_ has quit IRC23:54
lhchengmorganfainberg: finished going through the LP bugs, we got 8 rc potential and 3 are still being worked on in master.23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!