Monday, 2015-08-10

openstackgerritJamie Lennox proposed openstack/keystoneauth: Replace endpoint_type with interface in catalog  https://review.openstack.org/21026900:08
openstackgerritJamie Lennox proposed openstack/keystoneauth: Remove service_type requirement from catalog searching  https://review.openstack.org/21026800:08
openstackgerritJamie Lennox proposed openstack/keystoneauth: Allow searching a catalog on service or endpoint id  https://review.openstack.org/21026700:08
openstackgerritJamie Lennox proposed openstack/keystoneauth: Import service catalog tests from keystoneclient  https://review.openstack.org/21026600:08
*** piyanai has quit IRC00:13
*** shoutm has quit IRC00:17
*** shoutm has joined #openstack-keystone00:20
*** mylu has joined #openstack-keystone00:21
openstackgerritJamie Lennox proposed openstack/keystoneauth: Replace endpoint_type with interface in catalog  https://review.openstack.org/21026900:22
openstackgerritJamie Lennox proposed openstack/keystoneauth: Remove service_type requirement from catalog searching  https://review.openstack.org/21026800:22
openstackgerritJamie Lennox proposed openstack/keystoneauth: Allow searching a catalog on service or endpoint id  https://review.openstack.org/21026700:22
openstackgerritJamie Lennox proposed openstack/keystoneauth: Import service catalog tests from keystoneclient  https://review.openstack.org/21026600:22
*** shadower has quit IRC00:23
*** shadower has joined #openstack-keystone00:23
*** tellesnobrega has quit IRC00:27
*** ericksonsantos has quit IRC00:27
*** hrou has joined #openstack-keystone00:28
*** ericksonsantos has joined #openstack-keystone00:31
*** mylu has quit IRC00:31
*** tellesnobrega has joined #openstack-keystone00:31
*** lhcheng has quit IRC00:32
*** thedodd has quit IRC00:32
*** mylu has joined #openstack-keystone00:33
*** mylu has quit IRC00:38
*** mylu has joined #openstack-keystone00:39
*** shoutm has quit IRC00:44
*** shoutm has joined #openstack-keystone01:02
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/21089201:06
openstackgerritOpenStack Proposal Bot proposed openstack/keystoneauth-saml2: Updated from global requirements  https://review.openstack.org/21089301:06
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/21089401:06
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/21092301:10
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements  https://review.openstack.org/19231901:10
*** topol has joined #openstack-keystone01:10
*** ChanServ sets mode: +v topol01:10
*** shoutm has quit IRC01:16
*** shoutm has joined #openstack-keystone01:19
*** shoutm has quit IRC01:28
*** shoutm has joined #openstack-keystone01:30
*** topol has quit IRC01:32
*** mylu has quit IRC01:39
*** markvoelker has joined #openstack-keystone01:39
*** markvoelker has quit IRC01:44
*** davechen has joined #openstack-keystone01:52
*** alex_xu has quit IRC01:55
*** alex_xu has joined #openstack-keystone01:56
*** alejandrito has joined #openstack-keystone02:08
*** ankita_wagh has quit IRC02:14
*** ankita_wagh has joined #openstack-keystone02:14
*** lhcheng has joined #openstack-keystone02:21
*** ChanServ sets mode: +v lhcheng02:21
*** lhcheng has quit IRC02:22
*** lhcheng has joined #openstack-keystone02:22
*** ChanServ sets mode: +v lhcheng02:22
*** mylu has joined #openstack-keystone02:26
*** alejandrito has quit IRC02:37
*** ankita_wagh has quit IRC02:38
*** hakimo has joined #openstack-keystone02:52
*** hakimo_ has quit IRC02:55
*** mylu has quit IRC02:55
*** hrou has quit IRC03:05
*** markvoelker has joined #openstack-keystone03:40
*** topol has joined #openstack-keystone03:44
*** ChanServ sets mode: +v topol03:44
*** markvoelker has quit IRC03:45
*** topol has quit IRC03:48
*** stevemar has joined #openstack-keystone03:48
*** ChanServ sets mode: +v stevemar03:48
*** ayoung has quit IRC03:50
openstackgerritMerged openstack/keystone: Updated from global requirements  https://review.openstack.org/21089204:45
*** btully has joined #openstack-keystone04:47
*** ankita_wagh has joined #openstack-keystone04:53
*** ankita_wagh has quit IRC04:56
*** stevemar has quit IRC04:56
*** ankita_wagh has joined #openstack-keystone04:56
*** stevemar has joined #openstack-keystone04:57
*** ChanServ sets mode: +v stevemar04:57
openstackgerritMerged openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/21089405:00
openstackgerritMerged openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/21092305:01
*** jasondotstar has joined #openstack-keystone05:21
*** stevemar has quit IRC05:24
*** stevemar has joined #openstack-keystone05:25
*** ChanServ sets mode: +v stevemar05:25
*** jasondotstar has quit IRC05:26
*** stevemar has quit IRC05:28
*** markvoelker has joined #openstack-keystone05:41
*** Nirupama has joined #openstack-keystone05:46
*** markvoelker has quit IRC05:46
*** lhcheng has quit IRC05:52
*** yottatsa has joined #openstack-keystone05:53
*** Nirupama has quit IRC06:00
*** josecastroleon has joined #openstack-keystone06:07
*** marekd has quit IRC06:09
*** marekd has joined #openstack-keystone06:12
*** ChanServ sets mode: +v marekd06:12
marekdmorning06:15
bretonmorning!06:16
*** henrynash has joined #openstack-keystone06:17
*** ChanServ sets mode: +v henrynash06:17
*** henrynash has quit IRC06:20
*** afazekas_ has joined #openstack-keystone06:24
*** yottatsa has quit IRC06:25
*** yottatsa has joined #openstack-keystone06:28
*** Nirupama has joined #openstack-keystone06:28
*** topol has joined #openstack-keystone06:44
*** ChanServ sets mode: +v topol06:44
*** Nirupama has quit IRC06:45
*** topol has quit IRC06:48
*** odyssey4me has quit IRC06:50
*** odyssey4me has joined #openstack-keystone06:50
*** ankita_wagh has quit IRC06:54
openstackgerritMarek Denis proposed openstack/keystone: Refactor: Provider._rebuild_federated_info()  https://review.openstack.org/20887207:01
*** hakimo has quit IRC07:02
*** belmoreira has joined #openstack-keystone07:02
*** hakimo has joined #openstack-keystone07:03
*** kiran-r has joined #openstack-keystone07:03
*** shoutm has quit IRC07:27
*** Nirupama has joined #openstack-keystone07:29
*** Nirupama has quit IRC07:29
*** shoutm has joined #openstack-keystone07:30
*** Nirupama has joined #openstack-keystone07:32
*** markvoelker has joined #openstack-keystone07:42
*** yottatsa has quit IRC07:43
*** fhubik has joined #openstack-keystone07:45
*** ankita_wagh has joined #openstack-keystone07:45
*** fhubik is now known as fhubik_brb07:46
*** markvoelker has quit IRC07:46
*** yottatsa has joined #openstack-keystone07:47
*** btully has quit IRC07:47
*** fhubik_brb is now known as fhubik07:47
*** jasondotstar has joined #openstack-keystone07:48
*** yottatsa has quit IRC07:51
*** jasondotstar has quit IRC07:52
*** jagter has left #openstack-keystone07:54
openstackgerritDave Chen proposed openstack/keystone: Improve a few random docstrings  https://review.openstack.org/21102307:58
*** e0ne has joined #openstack-keystone08:10
*** jistr has joined #openstack-keystone08:12
*** e0ne has quit IRC08:16
*** fhubik is now known as fhubik_brb08:19
*** fhubik_brb is now known as fhubik08:25
*** odyssey4me has quit IRC08:26
*** odyssey4me has joined #openstack-keystone08:27
*** davechen has quit IRC08:31
*** davechen has joined #openstack-keystone08:31
*** e0ne has joined #openstack-keystone08:32
*** shoutm has quit IRC08:34
*** henrynash has joined #openstack-keystone08:34
*** ChanServ sets mode: +v henrynash08:34
*** ankita_wagh has quit IRC08:43
*** e0ne has quit IRC08:53
*** katkapilatova has joined #openstack-keystone08:55
*** afazekas_ is now known as afazekas09:04
*** shoutm has joined #openstack-keystone09:09
*** mkoderer has quit IRC09:14
*** marzif_ has quit IRC09:16
*** mkoderer has joined #openstack-keystone09:17
*** belmoreira has quit IRC09:18
*** belmoreira has joined #openstack-keystone09:19
*** yottatsa has joined #openstack-keystone09:26
*** _kiran_ has joined #openstack-keystone09:28
*** kiran-r has quit IRC09:31
*** marzif_ has joined #openstack-keystone09:36
*** rajesht has joined #openstack-keystone09:42
*** odyssey4me has quit IRC09:43
rajeshthi dolph09:43
rajeshtyou around ?09:43
*** markvoelker has joined #openstack-keystone09:43
*** odyssey4me has joined #openstack-keystone09:43
rajeshtdolphm: you around ?09:43
*** fhubik is now known as fhubik_brb09:49
*** markvoelker has quit IRC09:49
*** davechen has left #openstack-keystone09:55
*** shoutm has quit IRC09:58
*** odyssey4me has quit IRC10:04
*** odyssey4me has joined #openstack-keystone10:04
openstackgerritBoris Bobrov proposed openstack/keystone: Prevent exception due to missing id of LDAP entity  https://review.openstack.org/20796010:21
openstackgerritBoris Bobrov proposed openstack/keystone: Expose exception due to missing id of LDAP entity  https://review.openstack.org/21108810:21
*** Nirupama has quit IRC10:22
*** jasondotstar has joined #openstack-keystone10:29
*** stevemar has joined #openstack-keystone10:34
*** ChanServ sets mode: +v stevemar10:34
*** stevemar has quit IRC10:37
*** josecastroleon has quit IRC10:41
openstackgerritMarek Denis proposed openstack/keystone: Respect federated user name in UUID tokens.  https://review.openstack.org/21109310:41
openstackgerritMarek Denis proposed openstack/keystone: Respect federated user name in UUID tokens.  https://review.openstack.org/21109310:42
*** mylu has joined #openstack-keystone10:43
openstackgerritMarek Denis proposed openstack/keystone: Respect federated user name in UUID tokens.  https://review.openstack.org/21109310:44
openstackgerritMarek Denis proposed openstack/keystone: Respect federated user name in tokens.  https://review.openstack.org/21109310:50
openstackgerritBoris Bobrov proposed openstack/keystone: Allow to provide an expected exception to `wip` decorator  https://review.openstack.org/21109810:50
*** kiran-r has joined #openstack-keystone10:51
*** _kiran_ has quit IRC10:55
*** mylu has quit IRC10:58
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Fix nits from Project Tree Deletion spec  https://review.openstack.org/20905711:03
*** yottatsa has quit IRC11:05
*** fhubik_brb is now known as fhubik11:09
samueldmqmorning11:11
*** josecastroleon has joined #openstack-keystone11:11
*** jasondotstar has quit IRC11:18
*** henrynash has quit IRC11:28
*** markvoelker has joined #openstack-keystone11:29
*** shoutm has joined #openstack-keystone11:30
*** kiran-r has quit IRC11:32
*** markvoelker has quit IRC11:34
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Fix nits from Project Tree Deletion spec  https://review.openstack.org/20905711:36
*** marzif_ has quit IRC11:45
*** marzif_ has joined #openstack-keystone11:45
*** fhubik is now known as fhubik_brb12:03
*** htruta has joined #openstack-keystone12:04
*** markvoelker has joined #openstack-keystone12:08
*** fhubik_brb is now known as fhubik12:08
*** raildo has joined #openstack-keystone12:11
*** gordc has joined #openstack-keystone12:13
*** pawel_ has quit IRC12:13
*** yottatsa has joined #openstack-keystone12:24
*** yottatsa has quit IRC12:25
*** hrou has joined #openstack-keystone12:26
*** iurygregory has joined #openstack-keystone12:34
*** stevemar has joined #openstack-keystone12:35
*** ChanServ sets mode: +v stevemar12:35
*** bapalm has joined #openstack-keystone12:36
*** stevemar has quit IRC12:38
*** edmondsw has joined #openstack-keystone12:38
*** eandersson has joined #openstack-keystone12:40
*** tjcocozz has joined #openstack-keystone12:41
*** piyanai has joined #openstack-keystone12:47
bretonwhere do we get self.identity_api in tests from?12:50
bretoncan't find its initialization12:50
*** hrou has quit IRC12:52
*** jamie_h has joined #openstack-keystone12:52
*** bapalm_ has joined #openstack-keystone12:58
*** bapalm has quit IRC13:02
*** Kennan has quit IRC13:03
*** elmiko has joined #openstack-keystone13:03
*** diazjf has joined #openstack-keystone13:07
*** yottatsa has joined #openstack-keystone13:08
*** petertr7_away is now known as petertr713:09
bretonin load_backends of core.py.13:10
*** nkinder has joined #openstack-keystone13:16
marekddolphm: re:  https://bugs.launchpad.net/keystone/+bug/1482701 there is a fix for that here: https://review.openstack.org/#/c/211093/ however this doesn't work for scoped federated tokens.13:19
openstackLaunchpad bug 1482701 in Keystone "Federation: user's name in rules not respected" [Medium,In progress] - Assigned to Marek Denis (marek-denis)13:19
*** Kennan has joined #openstack-keystone13:20
marekddolphm: I am curious what's your opinoin on that matter - adding another field to fernet payload or  let's change the policy on user name/id and say that for ephemeral users name will  always be url_Decoded version of id ?13:20
*** jecarey has quit IRC13:20
marekdoterwise we will be growing with fernet size.13:20
marekdlbragstad: Fernet is also your baby, give it some love ^^ :)13:21
lbragstadmarekd: let me check out the bug report quick to get a little more context.13:22
marekdlbragstad: of course13:22
*** dsirrine has joined #openstack-keystone13:24
lbragstadmarekd: interesting, so this is something that happens with uuid, too13:24
marekdlbragstad: yes13:24
lbragstadI thought you meant it was fernet-specific13:24
marekdbut a proposed fix (read up) fixes uuid13:24
marekdit' wont fix scoped fernet13:24
marekdlbragstad: well, i come up with the idea while playing with fernet, then found it'd be for all tokens, but when it comes to scoped fernet federated token fernet is not easily fixable.13:25
lbragstadmarekd: because the token format has to change in order to "persist" the user name13:25
lbragstadright?13:25
marekdlbragstad:13:26
marekdyes13:26
lbragstadso, this means that we can't get scoped federated fernet tokens until we include this13:26
marekdwe can13:26
lbragstadif we pass it as a header?13:26
marekdbut name will be equal to id13:26
marekdwill be set to is13:26
lbragstadoh...13:26
marekdid13:26
lbragstadsure13:26
lbragstadthat makes sense13:26
lbragstadwill that break anything else?13:27
lbragstadrequiring that username and user id are equal?13:27
marekddont thnk so13:27
marekdunless we will break ourselves13:27
marekdsaying it could have been different.13:27
*** tjcocozz has quit IRC13:28
*** zzzeek has joined #openstack-keystone13:29
*** jasondotstar has joined #openstack-keystone13:29
*** tjcocozz has joined #openstack-keystone13:30
lbragstadmarekd: so, this prevents us from being able to do scoped federated tokens.13:32
lbragstadbut only if the user name and the user ids are different?13:32
marekdno13:32
lbragstad(how didn't we stumble across this before with UUID tokens?)13:32
marekdyou can get the tokens13:33
marekdbut the name will not be persisted13:33
marekdit will be set to id.13:33
marekdthat's all13:33
*** opilotte has joined #openstack-keystone13:33
odyssey4memarekd so I noticed this before, but thought that it was working as designed.13:33
lbragstadinteresting13:34
*** jasondotstar has quit IRC13:34
odyssey4meif you map the remote user name to either id or name it'll use whatever's provided as both the name and id13:34
marekdodyssey4me: yeah.13:34
odyssey4meit's not pretty, but it works, so I wasn't too fussed about it13:34
marekdodyssey4me: well, yes it works13:35
marekdbut somehow we allow id and name for users13:35
marekdand maybe somebody is using it.13:35
marekdi don't know.13:35
odyssey4meit's a little horrible if you want to use, say, the SID from ADFS as the id to try to guarantee uniqueness13:35
marekdno, id should be unique13:35
marekdname is more like "human readable name"13:36
odyssey4meI originally had my maps using the upn as the name and the SID as the id13:36
odyssey4methat was nice and readable13:36
*** marzif_ has quit IRC13:36
marekdwhat's SID ?13:36
*** ayoung has joined #openstack-keystone13:36
*** ChanServ sets mode: +v ayoung13:36
odyssey4meSID is an Active Directory unique ID13:36
*** marzif_ has joined #openstack-keystone13:36
lbragstadhttps://technet.microsoft.com/en-us/library/Cc961625.aspx13:36
marekdodyssey4me: yeah, so id should be your source of user identification13:37
*** yottatsa has quit IRC13:37
marekdbut since we allow names we should probably keep them as well13:37
marekdor say aloud something's changes.13:37
odyssey4melbragstad so yeah GUID would be a better unique ID - but it'd be nicer to have the name = the upn instead of the GUID13:38
odyssey4mewe should only copy the id to the name if the name is not provided13:38
lbragstadGUIDs would be unique globally13:38
marekdodyssey4me: we do13:38
marekdwe have a function that handles name/id filling if either is missing.13:39
odyssey4meoh, except that it's clearly overwriting the name at this point :p13:39
marekdodyssey4me: it isn't13:39
marekduser name is not stored in the fernet token payload13:39
marekdso when the json response is being built there is no name there.13:40
marekdthat's why my superfunction fills name with id.13:40
marekdand it works as designed.13:40
marekdproblem is the fernet :P13:40
odyssey4meah13:43
*** yottatsa has joined #openstack-keystone13:44
lbragstadso, we should either persist the username in the fernet payload, or make id and names the same13:44
*** shoutm has quit IRC13:44
*** tjcocozz_ has joined #openstack-keystone13:48
marekdlbragstad: yes13:48
marekdlbragstad: i answered your comment13:48
openstackgerritOlivier Pilotte proposed openstack/keystone: Keystone accepts Group IDs from the IdP without any Domain reference  https://review.openstack.org/21058113:48
*** ayoung has quit IRC13:49
*** jasondotstar has joined #openstack-keystone13:49
*** tjcocozz has quit IRC13:51
*** arif-ali has quit IRC13:53
marekdlbragstad: i don't know when dolphm's gonna be around so can you bug him for his opinion? Comment on a bug should be sufficient.13:53
marekdlbragstad: i might need to disappear relatively soon.13:54
lbragstadmarekd: yeah, I'll be sure to follow up with him today13:55
marekdlbragstad: thanks.13:55
lbragstadmarekd: worst case we'll add it to the agenda for tomorrow13:55
openstackgerritHenrique Truta proposed openstack/keystone: Replicate domain info in projects table  https://review.openstack.org/21117013:56
marekdlbragstad: i'd have done it long time ago, but chances are i will have to skip the meeting :P13:56
marekdlbragstad: have some evening business tbf.13:56
marekdtbd13:56
lbragstadmarekd: no worries, I think we'll be able to come up with something today13:56
marekdlbragstad: super13:56
*** jasondotstar has quit IRC13:59
*** jasondotstar has joined #openstack-keystone14:00
*** jdandrea has joined #openstack-keystone14:00
*** geoffarnold has joined #openstack-keystone14:02
*** petertr7 is now known as petertr7_away14:03
*** boris-42 has joined #openstack-keystone14:03
*** ayoung has joined #openstack-keystone14:03
*** ChanServ sets mode: +v ayoung14:03
*** hrou has joined #openstack-keystone14:06
*** josecastroleon has quit IRC14:06
*** petertr7_away is now known as petertr714:08
*** Kennan2 has joined #openstack-keystone14:09
*** Kennan has quit IRC14:09
*** arif-ali has joined #openstack-keystone14:10
*** richm1 has joined #openstack-keystone14:10
dstaneksamueldmq: i has hoping to find a way to make the caching in the client optional :-(14:11
samueldmqdstanek: so ... in policy GET calls, the server will be returning max-age in the cache control headers, right?14:11
*** btully has joined #openstack-keystone14:11
*** richm1 is now known as richm14:11
dstaneksamueldmq: yep14:12
samueldmqdstanek: why optional? if we (as a server) send cache control headers, we expect that we (as a client) honor it14:12
samueldmqdstanek: so... in the point of the headers calculation ..14:12
dstaneksamueldmq: i'd like to consider it experimental and not on by default, but i'm not sure that's possible14:13
ayoungmake it a creation option if we don't want to hold on it, but the user can always create a new session if they want, to dump state14:13
samueldmqdstanek: yes, need to look more into it14:14
samueldmqdstanek: so .. we need to get the max-age value here  https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L273-L27414:14
samueldmqdstanek: and it gets calculated in the policy manager (who takes care of the business logic)14:14
samueldmqdstanek: sounds sane so far? so the point is how it gets there14:14
dstanekyes14:15
openstackgerritLance Bragstad proposed openstack/keystone: Additional documentation for services  https://review.openstack.org/21118414:15
dstanekayoung: that's a good idea....it would allow me to make configuration someone else's problem14:15
samueldmqdstanek: so the controllers return either a set or a single entity, in this case an entity in the form {'policy': {content...}}14:15
dstaneksamueldmq: hold on one set14:16
dstaneksec14:16
samueldmqdstanek: sure14:16
openstackgerritMarianne Linhares Monteiro proposed openstack/keystone: List credentials by type  https://review.openstack.org/20862014:17
dstanekthe way i've started to prototype this is workable for most things. a simple decorator @cachecontrol(max_age={num seconds})14:17
ayoungif we do cache, do we keep in memory only, or provide a disk space?  Maybe disk is optional, and a max memory size for caching?14:18
dstanekand then a little logic is in wsgi.py to set the correct headers14:18
*** yottatsa has quit IRC14:18
ayoungwhat do we getfrom the requests library for support in caching?14:18
*** r-daneel has joined #openstack-keystone14:19
dstanekayoung:  nothing. i'm using cachecontrol a library that works with requests14:19
dstaneki doubt the memory cache has memory limits, maybe object limits...14:20
*** yottatsa has joined #openstack-keystone14:20
dstaneki was planning on just doing a filecache by default14:21
dstaneksamueldmq: does that make sense? in most cases you won't case about the object itself. the timeout is just general. these resources only last a few seconds14:22
dstanekayoung: what do you think if i have the thing making the Session object just pass in a cache backend. no backend means no cache14:23
*** fhubik is now known as fhubik_brb14:24
*** fhubik_brb is now known as fhubik14:27
*** josecastroleon has joined #openstack-keystone14:29
*** afazekas has quit IRC14:31
*** yottatsa has quit IRC14:34
*** stevemar has joined #openstack-keystone14:35
*** ChanServ sets mode: +v stevemar14:35
*** katkapilatova has left #openstack-keystone14:37
*** jsavak has joined #openstack-keystone14:37
*** yottatsa has joined #openstack-keystone14:38
morgan_503dstanek: that is mostly reasonable.14:38
*** stevemar has quit IRC14:38
morgan_503dstanek: that also alleviates the issue of cache config in keystoneauth itself14:38
*** jecarey has joined #openstack-keystone14:41
*** stevemar has joined #openstack-keystone14:41
*** ChanServ sets mode: +v stevemar14:41
*** piyanai has quit IRC14:42
samueldmqdstanek: yes, I was talking about a little logic in wsgi.py to set the headers14:42
samueldmqdstanek: so instead of returning only {'policy': entity}, controller could add {'freshness': freshness} to that dict14:43
samueldmqdstanek: wsgi.py would then get it and generate the response with the appropriate cache control (max-age) headers14:43
samueldmqmorgan_503: hey, what's up? :)14:44
samueldmqmorgan_503: back to you regular tz ?14:44
samueldmqyour*14:44
dstaneki don't think the controller needs to change at all for this14:46
samueldmqdstanek: so how the freshness (calculated at manager level) gets to the application level (wsgi request in wsgi.py)14:47
dstaneksamueldmq: today's a code day for me (very little reviews!) so i'll push up my changes to show you14:47
samueldmqdstanek: does it go into the entity itself?14:47
dstaneksamueldmq: what needs to be calculated at all?14:47
*** fifieldt_ has quit IRC14:47
dstanekif we say a resource is generally cacheable for 10 seconds then we just say 10 seconds. no need to calculate anything14:48
samueldmqdstanek: not for policies14:48
samueldmqdstanek: the cache is controled and based on a timeout in the server14:48
dstanekright, that's what i'm talking about14:48
samueldmqdstanek: that's what the whole spec 'Centralized Policies Distribution Mechanism' is about14:48
dstanekso what is there to calculate?14:49
dstanekand how do you calculate it?14:49
samueldmqdstanek: https://review.openstack.org/#/c/209695/1/keystone/policy/core.py14:49
samueldmqdstanek: lines 58-8914:49
dstaneksamueldmq: why are you not just setting the max ago to a static number of seconds?14:51
samueldmqdstanek: multiple endpoint processes behind a proxy14:52
samueldmqdstanek: suppose multiple nova processes (having the same endpoint id at keystone), they must use the same policy consistently14:53
dstanekwith caching they won't - there may be a difference of a second or two14:53
samueldmqdstanek: what caching ? they need the polic yto then cache it right ?14:54
dstanekwhy would that be a problem? it would only be a problem if those instance depended on each other14:54
dstaneksamueldmq: as soon as you just into http caching you are agreeing to a level of eventual consistency14:55
samueldmqdstanek: you can't have different policies at different processes behind a proxy14:55
*** topol has joined #openstack-keystone14:55
*** ChanServ sets mode: +v topol14:55
*** narengan has joined #openstack-keystone14:55
samueldmqdstanek: we need to ensure they will have the same policy at any time14:56
dstanekthen we can't use http caching14:56
samueldmqwhy?14:56
*** henrynash has joined #openstack-keystone14:56
*** ChanServ sets mode: +v henrynash14:56
samueldmqdstanek: we have our own caching mechanism, and we are making use of http headers14:56
samueldmqdstanek: we control both sides of the cache14:57
dstanekif someone uses an intermediary that doesn't have our custom rules you scheme will break14:57
*** fhubik has quit IRC14:57
dstanekand i'd really, really like to get varnish in front of keystone14:57
dstanekwhat is the problem if processes have difference policies for a few seconds?14:58
samueldmqdstanek: I am gonna include the 'private" in the cache control headers14:58
samueldmqdstanek: from the spec: ``private``: indicates that the response message is intended for a single endpoint and must not be cached by a shared cache.14:58
dstaneksamueldmq: why?14:58
samueldmqdstanek: because of the max-age, whch is different for different processes (depending on when they ask for the policy update)14:59
openstackgerritHenrique Truta proposed openstack/keystone: Creating tests for projects acting as domains  https://review.openstack.org/21121914:59
dstaneksamueldmq: but why is that a problem?15:00
samueldmqdstanek: if we don't control the cache that way, processes can have different policies for X seconds, where X is the policy timeout15:00
dstaneksamueldmq: also what is you logic actually calculating?15:00
*** piyanai has joined #openstack-keystone15:00
dstaneksamueldmq: otherwise everything will hit keystone at the same time for a policy update15:01
samueldmqdstanek: no they won't15:01
samueldmqdstanek: we took care of the thundering herd15:01
bretoncould some non-ibmer +2a https://review.openstack.org/#/c/210477/ ?15:01
samueldmqdstanek: we add a delya based on a policy_id hash,15:01
openstackgerritBoris Bobrov proposed openstack/keystone: Adds a notification testcase for unbound methods  https://review.openstack.org/21047815:01
samueldmqdstanek: so different policies times out at different points in the time, but with the same timeout15:02
*** geoffarnold is now known as geoffarnoldX15:02
dstaneksamueldmq: ok, so you are doing lots of logic so that the times are the same so that policies is not different between process, but on the client side you introduce timeouts the combat the herd and that will make policy different for that client?15:03
samueldmqdstanek: the server takes care of the timeouts, so it worries about when it times out15:04
samueldmqdstanek: the only thing the client gets is: max-age15:04
samueldmqdstanek: and respect it15:04
samueldmqdstanek: I believe the section Proposed Solution in the spec has a good (and quick) explanation15:06
samueldmqdstanek: https://review.openstack.org/#/c/197980/12/specs/backlog/dynamic-policies-delivering-mechanism.rst15:06
samueldmqdstanek: and it would confuse you less than I probably can :(15:06
dstanekthe freshness is client side right?15:07
samueldmqdstanek: it is calculated at server side, and the client side respects it15:07
dstanekso how do you prevent the herd?15:07
samueldmqdstanek: ok let me give you an example15:08
dstanekwhen everyone comes back for a policy they will come back at the exact same time right?15:08
samueldmqdstanek: no, they won't, because everyone doesn"t want the same policy15:08
samueldmqdstanek: everyone who wants teh same policy id will come at the same time15:09
samueldmqdstanek: how do I prevent that ? ok ..15:09
*** geoffarnoldX is now known as geoffarnold15:09
samueldmqdstanek: I am the server and I am timing out at 12:00, but each policy will times out around that time, but not at that exact time15:09
samueldmqdstanek: 12:00 + (policy_id % timeout)15:10
samueldmq^15:10
*** thedodd has joined #openstack-keystone15:10
dstaneksamueldmq: so let's step back15:10
samueldmqdstanek: this is when the policy with a given id will actually expires, not exactly at 12:0015:10
samueldmqdstanek: sure15:10
dstaneksamueldmq: after a policy is changed how quickly should the change occur?15:11
samueldmqdstanek: it will occur the next time the server times out for that policy id15:11
samueldmqdstanek: so we have the concept of policy releases15:11
samueldmqdstanek: for policy X, I timed out at 12:00 o'clock, so I will be delivering the same policy as it was at 12:00 until 12:05, if timeout is 30015:12
dstaneksamueldmq: think from a admin perspective. what is the SLA we tell them for when their changes take effect?15:12
*** topol has quit IRC15:13
dstanek10 seconds, 1 minute, 1 hour, etc?15:13
samueldmqdstanek: they would have soem delay to enable the modified policy using puppet15:13
samueldmqdstanek: the max time it will take is the timeout set for policy entities15:13
samueldmqsame*15:13
*** jamie_h has quit IRC15:14
*** geoffarnold has quit IRC15:15
samueldmqwhich is, by default, 300 seonds15:15
samueldmqseconds15:15
dstanekso every 5 minutes the server will check back. so at that point you may have a herd for some policies15:16
dstanekalso that mean you accept that 1 or more nodes may be ouf of sync for up to 5 minutes15:16
samueldmqdstanek: every 5 minutes, the server will release a new policy, but that is not every 5 minutes, that happnes when the next request comes15:16
samueldmqdstanek: and the server detects the policy is out-of-date, then re-release it before returning15:17
dstanekwhat do you mean by releases?15:17
samueldmqdstanek: no we don't allow that15:17
samueldmqdstanek: we have thought about all that :/15:17
samueldmqdstanek: ok, let me explaing all the solution as I see it15:17
samueldmqdstanek: ready?15:18
dstaneksamueldmq: not necessary, i've read the specs15:18
dstaneki just don't think it's as cut and dry as you do15:18
dstanekwhat happens is there is a hiccup getting a policy from the server? do we fail or instruct the client to use what they had?15:19
samueldmqdstanek: ok, so policies time out at different times, but every 5 minutes15:19
*** phalmos has joined #openstack-keystone15:20
samueldmqdstanek: it doesn't matter what client is going to ask the policy entity15:20
samueldmqdstanek: the server returns the requested entity + its freshenss15:20
samueldmqdstanek: that's all the client side have to care about15:21
samueldmqdstanek: other than that, is on server side15:21
dstaneksamueldmq: so what happens if the request to fetch a policy fails?15:21
samueldmqdstanek: whatever HTTP error ? the client needs to care about it, and should retry, etc15:22
samueldmqdstanek: that can happens with nova asking for cinder images for example ?15:23
dstaneksamueldmq: so assume that it can't get the policy for some reason. what happens?15:23
samueldmqdstanek: it is possibly inconsistent with other endpoint processes behind the same policy15:24
samueldmqdstanek: so it needs either i) to reject the request, since it can't get enough info to enforce access control15:24
samueldmqdstanek: or ii) use the "old" policy15:24
samueldmqdstanek: what happens if puppet fails to reach a node when distributing the policies ?15:25
dstaneksamueldmq: what strategy are you implementing?15:27
*** arunkant has joined #openstack-keystone15:27
dstaneki imagine that #2 is what happens with all current configuration management solutions15:28
*** josecastroleon has quit IRC15:28
samueldmqdstanek: currently, when the middleware receives a HTTP error from the client, it is just logging and saying it can't fetch the policy from keystone and is falling to the old mechanism, i.e ignoring changes form the servers15:28
samueldmqdstanek: yes so basically I am doing that ...15:29
*** kiran-r has joined #openstack-keystone15:29
samueldmqdstanek: last lines here https://review.openstack.org/#/c/188561/6/keystonemiddleware/auth_token/_identity.py15:30
samueldmqdstanek: and the exception is caught here15:30
samueldmqdstanek: https://review.openstack.org/#/c/188561/6/keystonemiddleware/auth_token/_policy.py15:30
dstanekso as i said earlier your already accepting the fact that processes can be out of date for up to the policy timeout15:30
*** rajesht has quit IRC15:31
samueldmqdstanek: that's an exceptional behavior, not the planned one15:31
samueldmqdstanek: we can't plan and just accept they can be incosistent between endpint processes all the tiem15:31
samueldmqdstanek: that was a concern from morgan, btw15:32
samueldmqdstanek: and I agree that's important to be considered15:32
dstanekit must be explicitly designed for. in any sufficiently sized deployment i would that exceptional case to happen relatively often15:34
samueldmqdstanek: the network failing and policy request failing ?15:34
dstaneki'd like to design for Amazon scale and hope that one of the OpenStack public clouds get there :-)15:35
samueldmqdstanek: if it fails because the server is unavailable, we wouldn't be able to validate teh token anyway15:35
dstaneksamueldmq: depends on the failure15:35
dstanekotherwise your idea of a retry wouldn't work anyway...15:36
dstanekalso are you expecting two values to be set? one for the timeout and one for the freshness?15:36
samueldmqdstanek: no, just max-age is set15:37
dstanekno, i mean in the config15:37
samueldmqdstanek: the server control the timeout, and according to its own timeout + plicy id hash, it calculates the freshness (max-age)15:37
samueldmqdstanek: just in the server config15:37
*** belmoreira has quit IRC15:38
samueldmqdstanek: and adding support of CacheControl at ksclient, so ksmiddleware doesn't need to care about anything *at all*15:39
samueldmqdstanek: other than just 'self.client.policies.get(id)"15:39
samueldmq(something like that, since it isn't requesting the policy by its id directly, but using the endpoint_id instead)15:43
dstaneksamueldmq: the endpoint_id will always return the same policy right?15:45
*** yottatsa has quit IRC15:45
samueldmqdstanek: it depends on the association in the server side, which is defined by endpoint-policy extension15:47
*** yottatsa has joined #openstack-keystone15:48
openstackgerritIoram Schechtman Sette proposed openstack/keystone-specs: Basic API spec for managing Policy rules in a database  https://review.openstack.org/18490315:48
dstaneksamueldmq: what would make if give a different response?15:49
*** yottatsa has quit IRC15:49
*** jistr has quit IRC15:50
samueldmqdstanek: the different response will come with its respective max-age15:50
samueldmqdstanek: I don't see the point where it could be an issue15:50
dstaneksamueldmq: i'm just thinking it through15:51
samueldmqdstanek: cool, I think you were leading me to see an issue you were seeing already :-)15:52
dstaneksamueldmq: so except for it changing at some point we will always return the same response for the same request. we don't vary it by data in the token or anything else right?15:52
openstackgerritMerged openstack/keystone: Correct enabled emulation query to request no attributes  https://review.openstack.org/18706515:52
*** jorge_munoz has joined #openstack-keystone15:53
*** geoffarnold has joined #openstack-keystone15:53
*** bknudson has joined #openstack-keystone15:54
*** ChanServ sets mode: +v bknudson15:54
samueldmqdstanek: yes, in every 5 minutes time slice, we return the same policy15:54
samueldmqdstanek: even if the policy entity has been changed/deleted, that will only take effect at the next time it times out (when endpoint processes ask for an update)15:55
*** _cjones_ has joined #openstack-keystone15:55
samueldmqdstanek: policy changes/ association changes in the endpoint-policy extension, will take effect in the next timeout15:55
samueldmqdstanek: and that doesn't vary by any data at all15:55
dstaneksamueldmq: no that's fine. i was just making sure that the same request will always get the same response (if the resource hasn't changed)15:56
samueldmqdstanek: only max-age will be different, even if resource ahsn't changed15:56
samueldmqdstanek: makes sense?15:56
dstaneksamueldmq: yep, i'm just looking for the common problems15:57
samueldmqdstanek: if a second request is a second later the first one, the policy will be valid for 1 second less15:57
samueldmqdstanek: nice15:57
*** darrenc has quit IRC15:57
*** darrenc has joined #openstack-keystone15:58
samueldmqdstanek: if a shared cache stores an entity and it has a max-age set, does it update the max-age value when returning the cached entity ?16:02
samueldmqdstanek: I mean, decresing it over the time ?16:02
dstaneksamueldmq: jas in a meeting16:03
*** petertr7 is now known as petertr7_away16:03
*** petertr7_away is now known as petertr716:03
samueldmqdstanek: np, I am gonna continue with the implementation as it is in the specs, want to finish today before the FFE email16:03
samueldmqdstanek: thanks for getting involved16:04
*** browne has joined #openstack-keystone16:05
*** e0ne has joined #openstack-keystone16:13
*** kiran-r has quit IRC16:14
*** jasonsb has quit IRC16:20
*** ankita_wagh has joined #openstack-keystone16:22
*** yottatsa has joined #openstack-keystone16:31
*** e0ne has quit IRC16:33
*** hrou has quit IRC16:39
*** bapalm has joined #openstack-keystone16:43
*** lhcheng has joined #openstack-keystone16:43
*** ChanServ sets mode: +v lhcheng16:43
*** marzif_ has quit IRC16:44
*** marzif_ has joined #openstack-keystone16:44
*** e0ne has joined #openstack-keystone16:47
*** diazjf has quit IRC16:52
*** e0ne has quit IRC16:52
*** petertr7 is now known as petertr7_away16:55
samueldmqdstanek: you ok with the @cachecontrol annotation receiving a function as parameter ?16:56
samueldmqdstanek: you already started that code ?16:56
*** ankita_wagh has quit IRC16:57
*** ankita_wagh has joined #openstack-keystone16:58
*** narengan has quit IRC16:58
samueldmqdstanek: I will keep it simple for now, can use that annotation an improvement/when you submit it :)16:59
*** narengan has joined #openstack-keystone16:59
*** ankita_wagh has quit IRC17:02
openstackgerritMerged openstack/keystone: Fixes an incorrect docstring in notifications  https://review.openstack.org/21047717:02
openstackgerritMerged openstack/keystone: Improve a few random docstrings (H405)  https://review.openstack.org/21060717:03
*** narengan has quit IRC17:04
dstaneksamueldmq: on the server side you mean?17:05
samueldmqdstanek: yes17:06
dstaneksamueldmq: the client side cache should only update the max-age when the server tells it to17:06
dstaneksamueldmq: i have some partially working stuff that i took from a project i worked on in the past17:06
samueldmqdstanek: and how does the server tells it to update ? just passing a max-age value ,17:08
samueldmq?17:08
dstaneksamueldmq: every server response will respond with the current max-age and the client will request again after that getting a new resource and a new max-age17:09
samueldmqdstanek: ++17:10
*** jasonsb has joined #openstack-keystone17:10
*** jamielennox is now known as jamielennox|away17:11
*** jasonsb has quit IRC17:14
*** jasonsb has joined #openstack-keystone17:14
*** ankita_wagh has joined #openstack-keystone17:14
*** bapalm has quit IRC17:16
*** bapalm has joined #openstack-keystone17:16
*** HT_sergio has joined #openstack-keystone17:19
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Enable Cache-Control HTTP values in responses  https://review.openstack.org/21127117:20
samueldmqdstanek: does this look sane to you ? ^17:20
*** bapalm has quit IRC17:21
*** ankita_w_ has joined #openstack-keystone17:24
*** topol has joined #openstack-keystone17:24
*** ChanServ sets mode: +v topol17:24
*** ankita_wagh has quit IRC17:27
*** topol has quit IRC17:29
*** diazjf has joined #openstack-keystone17:31
*** HT_sergio has quit IRC17:34
*** marzif_ has quit IRC17:36
*** marzif_ has joined #openstack-keystone17:36
*** Guest30753 is now known as tsymanczyk17:38
*** marzif_ has quit IRC17:44
*** roxanaghe has joined #openstack-keystone17:53
*** piyanai has quit IRC17:55
*** piyanai has joined #openstack-keystone17:56
*** piyanai has quit IRC17:56
*** HT_sergio has joined #openstack-keystone17:57
*** flwang has quit IRC17:58
*** piyanai has joined #openstack-keystone17:58
*** petertr7_away is now known as petertr718:00
*** hrou has joined #openstack-keystone18:03
*** opilotte has quit IRC18:04
*** opilotte has joined #openstack-keystone18:06
*** e0ne has joined #openstack-keystone18:06
*** bapalm has joined #openstack-keystone18:07
*** bapalm has quit IRC18:07
*** bapalm has joined #openstack-keystone18:08
*** piyanai has quit IRC18:09
*** e0ne has quit IRC18:10
*** flwang has joined #openstack-keystone18:11
*** yottatsa has quit IRC18:14
*** yottatsa has joined #openstack-keystone18:16
*** hrou has quit IRC18:18
*** narengan has joined #openstack-keystone18:19
*** e0ne has joined #openstack-keystone18:21
*** narengan has quit IRC18:21
*** narengan has joined #openstack-keystone18:22
*** toddnni has quit IRC18:23
*** toddnni has joined #openstack-keystone18:23
*** toddnni has quit IRC18:23
*** josecastroleon has joined #openstack-keystone18:24
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Enable Cache-Control HTTP values in responses  https://review.openstack.org/21127118:24
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Fixes query.one() return usage in endpoint-policy  https://review.openstack.org/20860918:24
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Centralized Policies Distribution Mechanism  https://review.openstack.org/20969518:24
*** marzif_ has joined #openstack-keystone18:25
*** narengan has quit IRC18:26
*** bapalm__ has joined #openstack-keystone18:27
*** toddnni has joined #openstack-keystone18:29
*** ankita_wagh has joined #openstack-keystone18:30
*** bapalm has quit IRC18:30
openstackgerritHenrique Truta proposed openstack/keystone: Honor domain operations in project table  https://review.openstack.org/14376318:32
htrutadstanek: ^ here it is18:32
*** ankita_w_ has quit IRC18:32
htruta300 lines smaller18:32
*** ayoung has quit IRC18:33
*** ngupta has joined #openstack-keystone18:34
*** tsymanczyk has quit IRC18:34
*** rm_work|away is now known as rm_work18:36
*** Tedster has quit IRC18:44
*** Tedster has joined #openstack-keystone18:44
*** yottatsa has quit IRC18:46
*** hrou has joined #openstack-keystone18:46
*** eandersson has quit IRC18:46
*** yottatsa has joined #openstack-keystone18:46
*** piyanai has joined #openstack-keystone18:53
*** josecastroleon has quit IRC18:54
*** yottatsa has quit IRC18:54
*** yottatsa has joined #openstack-keystone18:55
*** narengan has joined #openstack-keystone18:56
*** tsymanczyk has joined #openstack-keystone18:57
openstackgerritBoris Bobrov proposed openstack/keystone: Prevent exception due to missing id of LDAP entity  https://review.openstack.org/20796018:57
openstackgerritBoris Bobrov proposed openstack/keystone: Expose exception due to missing id of LDAP entity  https://review.openstack.org/21108818:57
*** tsymanczyk is now known as Guest9663418:57
*** yottatsa has quit IRC19:00
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Fixes query.one() return usage in endpoint-policy  https://review.openstack.org/20860919:00
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Enable Cache-Control HTTP values in responses  https://review.openstack.org/21127119:00
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Centralized Policies Distribution Mechanism  https://review.openstack.org/20969519:01
*** narengan has quit IRC19:01
*** narengan has joined #openstack-keystone19:02
*** petertr7 is now known as petertr7_away19:05
*** narengan has quit IRC19:06
*** petertr7_away is now known as petertr719:06
*** opilotte has quit IRC19:07
*** bapalm_ has quit IRC19:08
*** ankita_w_ has joined #openstack-keystone19:12
*** Guest96634 has quit IRC19:13
*** tsymancz1k has joined #openstack-keystone19:13
*** stevemar has quit IRC19:15
*** ankita_wagh has quit IRC19:15
*** gyee has joined #openstack-keystone19:16
*** ChanServ sets mode: +v gyee19:16
*** stevemar has joined #openstack-keystone19:16
*** ChanServ sets mode: +v stevemar19:16
*** browne has quit IRC19:18
*** narengan has joined #openstack-keystone19:18
*** jsavak has quit IRC19:19
*** ngupta_ has joined #openstack-keystone19:20
*** ngupta has quit IRC19:21
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Centralized Policies Distribution Mechanism  https://review.openstack.org/20969519:21
*** opilotte has joined #openstack-keystone19:22
*** jsavak has joined #openstack-keystone19:23
*** atiwari has joined #openstack-keystone19:28
marekdlbragstad: dolphm why would you need jamies spec?19:30
*** belmoreira has joined #openstack-keystone19:34
*** ayoung has joined #openstack-keystone19:38
*** ChanServ sets mode: +v ayoung19:38
*** ankita_w_ has quit IRC19:38
*** bapalm__ has quit IRC19:44
*** bapalm has joined #openstack-keystone19:45
*** bapalm has quit IRC19:46
*** bapalm has joined #openstack-keystone19:46
samueldmqomg, there is support for endpoint-policy extension on ksclient already19:48
samueldmqI was going to implement it o/19:49
*** ksavich has joined #openstack-keystone19:50
samueldmqayoung: I have all the needed code for the centralized policy distribution (only needing CacheControl support on ksclient + some unit tests on the server patches)19:50
*** jsavak has quit IRC19:51
samueldmqayoung: I am going to draft the FFE request email, will ask for you feedback on it in a bit19:51
*** jsavak has joined #openstack-keystone19:52
dstaneksamueldmq: once i get it working i'll post an alternate server side impl of caching19:53
dstaneki'm trying to figure out the client side tests now19:53
dstanekmarekd: multple IdP's using the same protocol over WebSSO19:53
samueldmqdstanek: nice, thanks19:54
dstaneksamueldmq: your current impl is broken because it is still caching based on the token19:55
dstaneksamueldmq: by default (for whatever historical reason) we add a vary header19:55
*** ankita_wagh has joined #openstack-keystone19:57
samueldmqdstanek: so by default every entity is cached based on the token? in ksclient ...19:57
dstaneksamueldmq: no, on the server side19:58
dstanekwe are adding a vary header19:58
marekddstanek: you don't need multiple routes for this19:59
marekddstanek: i would even say jamie's goal was different19:59
*** tsymanczyk has joined #openstack-keystone19:59
marekdand this is not what he complained about19:59
samueldmqdstanek: what we'll be doing for policies ? not caching at all ?20:00
*** tsymanczyk is now known as Guest8436720:00
samueldmqdstanek: in that case ..20:00
dstanekmarekd: beyond making protocols like "SAML_ipd_a" and "SAML_idp_b" how do you use multiple IdPs?20:00
samueldmqdstanek: in what level do we cache it ?20:01
dstaneksamueldmq: level?20:01
samueldmqdstanek: that should be the first question :)20:01
samueldmqdstanek: manager/controller ?20:01
marekddstanek: so for sso there is one entrypoint20:01
marekd/auth/websso/saml220:01
openstackgerritHenrique Truta proposed openstack/keystone: Creating tests for projects acting as domains  https://review.openstack.org/21121920:01
openstackgerritHenrique Truta proposed openstack/keystone: Honor domain operations in project table  https://review.openstack.org/14376320:01
marekdyou use discovery service, either install some 3rd party stuff, or maybe even implement it yourself20:02
marekdlike in this blogpost20:02
samueldmqdstanek: I am asking because I am worried about the max-age, which changes for every response (so it can't be cached)20:02
openstackgerritHenrique Truta proposed openstack/keystone: List projects filtering by is_domain flag  https://review.openstack.org/15839820:02
dstaneksamueldmq: you're asking about where the the header is defined not where the caching actually happens rigtht?20:03
samueldmqdstanek: if it's at the manager level, we add the max-age at the controllr level20:03
*** tsymancz1k has quit IRC20:03
openstackgerritHenrique Truta proposed openstack/keystone: Restrict inherited role assignments to subdomains  https://review.openstack.org/16418020:03
openstackgerritHenrique Truta proposed openstack/keystone: Remove domain table references  https://review.openstack.org/16593620:03
*** woodster_ has joined #openstack-keystone20:03
openstackgerritHenrique Truta proposed openstack/keystone: Restricting domain_id update  https://review.openstack.org/20721820:03
samueldmqdstanek: I am defining hte header value at controller20:03
openstackgerritHenrique Truta proposed openstack/keystone: Bye Bye Domain Table  https://review.openstack.org/16185420:03
openstackgerritHenrique Truta proposed openstack/keystone: Add is_domain in token response  https://review.openstack.org/19733120:03
dstaneksamueldmq: all of the HTTP logic should be at the controller layer20:03
openstackgerritHenrique Truta proposed openstack/keystone: Change policy to comply with is_domain in token  https://review.openstack.org/20606320:03
samueldmqdstanek: yes I am doing it there20:03
dstanekthe manager shouldn't know anything about HTTP at all20:03
*** gabriel-bezerra has quit IRC20:04
samueldmqdstanek: yes I agree, and I am not doing that :)20:04
samueldmqdstanek: I am worried about where the caching occurs, if we cache the controller return, we would probably be caching the max-age, which is not desired20:04
dstaneksamueldmq: what do you mean by caching the max-age?20:04
samueldmqdstanek: if we cache the manager level, we just cache the entities, so there is no problem at all20:04
dstaneksamueldmq: we are not caching at all on the server side20:05
lbragstadmarekd: but doesn't implementing a discover service mean that everyone that uses that discovery service know all IdPs you use?20:05
samueldmqdstanek: look at how I am doing it right now https://review.openstack.org/#/c/209695/4/keystone/endpoint_policy/controllers.py20:05
samueldmqdstanek: huh, I thought you said we were caching at server side20:06
lbragstaddstanek: cc ^20:06
dstaneksamueldmq: no, we only generate headers on the server side20:06
samueldmqdstanek: where do the caching occurs? the caching that, by default, is based on the token (as we were talking before)20:07
samueldmqdoes the caching occur*** (bad English)20:07
samueldmq:(20:07
dstaneksamueldmq: the actual caching when we talk about HTTP caching is on the client side20:08
marekdlbragstad: it does, but you can also add a hashmap, so the user has to type idp name and it may map to some sort of url.20:08
dstanekmarekd: lbragstad: the map to URL is what i was thinking in my email and sorta what we talked about today20:08
*** Ephur has joined #openstack-keystone20:09
marekdi didn't talk with you today :(20:09
*** bapalm has quit IRC20:09
dstanekmarekd: no, lbragstad, dolphm and i20:09
marekddstanek: sure.20:09
samueldmqsamueldmq | dstanek: so by default every entity is cached based on the token? in ksclient ...20:09
samueldmq+dstanek | samueldmq: no, on the server side20:09
lbragstadok, so once the DS knows what IdP the user wants, what call does it make to keystone? (my second questions)20:09
samueldmqdstanek: we messed up earlier then :p20:09
samueldmq^20:09
*** bapalm has joined #openstack-keystone20:09
lbragstads/questions/question/20:09
marekddstanek: lbragstad so your goal is to add a dashboard for all the clients, so they can come from different IdPs and they cannot see who else is cloud provider's client?20:10
dstaneksamueldmq: this has nothing to do with ksc; right now we add a vary header for the token; this means that any client that implements caching will cache based on the token20:10
lbragstadmarekd: yes, similar to this case that jamielennox|away described -- http://lists.openstack.org/pipermail/openstack-dev/2015-August/071504.html20:11
dstanekok, i have a 2 hour phone call starting soon :-(20:11
marekdlol20:12
*** bapalm has quit IRC20:12
marekdpoor David20:12
*** e0ne has quit IRC20:12
*** bapalm has joined #openstack-keystone20:12
* lbragstad wonders if dstanek is going into management? 20:12
marekdlbragstad: let me read this thread20:12
dstaneklbragstad: i'd rather die20:12
lbragstaddstanek: lol20:12
samueldmqdstanek: hmm, got it ... so in the policy case we will tell the clients to cache based on the policy id (like adding a vary header for it) ..20:12
marekdlbragstad: this is where money lay20:12
samueldmqdstanek: besides respecting the max-age20:12
*** browne has joined #openstack-keystone20:14
lbragstadmarekd: right now, don't we call federated_sso_auth based on the protocol_id?20:14
dstaneksamueldmq: nope, the vary header is a list of headers that should be used as a part of the cache key; the endpoint_id we are using is in the URL which is already a part of the cache key by default20:14
lbragstadI don't think we have a way to call federated_sso_auth based on the idp id alone20:14
lbragstadwhich is what jamielennox|away was thinking about adding in the proposal20:15
samueldmqdstanek: so we just need to remove tje token from that list20:15
samueldmqdstanek: if that is not true, I have not understood anything at all :p20:15
dstaneksamueldmq: in some cases yes that will need to happen20:15
samueldmqdstanek: because using the same client, even if tokens are differnet, we get teh same policy20:16
samueldmqdstanek: nice, thanks o/20:16
samueldmqdstanek: I am preparing the FFE email, I will be updating my patches according to yours as we go this week20:16
dstaneksamueldmq: right, and if we are caching based on the vary header the thing would be fetched and stored twice20:16
samueldmqdstanek: thanks :)20:16
dstaneksamueldmq: do you need a SFE?20:17
samueldmqdstanek: for each token .. just bad , even using CacheControl, which wuld respect it right ?20:17
samueldmqdstanek: I asked for a SFE for it .. but now we need a FFE (L3) right ?20:17
dstaneksamueldmq: do we need a SFE approved to merge into L?20:18
dstaneksamueldmq: yes cachecontrol will respect the vary header and ask for the resource every time the token changes20:18
samueldmqdstanek: I think so.. we needed SFE for new specs being targeted to L after L120:19
marekdlbragstad: heh, i love such threads - everybody clasims everything else and everybody says 'but it was discussed months ago'20:19
samueldmqdstanek: that is keystone specific, and had to be approved/rejected20:19
samueldmqdstanek: at this point I am not sure it matters, because we didn't agree in a decision20:19
lbragstadmarekd: ++20:19
samueldmqdstanek: and FFE is something valid for the whole community (not keystone specific)20:20
samueldmqdstanek: that's my understanding20:20
dstaneksamueldmq: yeah, but if we need to get a SFE from the Keystone team then we need to do that. (i have no idea if it's required)20:21
*** stevemar has quit IRC20:21
*** stevemar has joined #openstack-keystone20:22
*** ChanServ sets mode: +v stevemar20:22
samueldmqdstanek: we needed it post-L1, but I think granting FFE grants, indeed, a SFE20:22
samueldmqdstanek: and SFE doesn't make sense without FFE, at this point20:22
marekdlbragstad: let me please read whole thread tomorrow.20:22
lbragstadmarekd: sounds good20:23
samueldmqdstanek: and I don't know if FFE is a keystone only decision20:23
*** topol has joined #openstack-keystone20:25
*** ChanServ sets mode: +v topol20:25
dstaneksamueldmq: i don't Keystone makes the final decision on that20:25
*** HT_sergio has quit IRC20:26
samueldmqdstanek: yes, so that's another reason we do need an official email asking for FFE20:27
openstackgerritOlivier Pilotte proposed openstack/keystone: Keystone accepts Group IDs from the IdP without any Domain reference  https://review.openstack.org/21058120:29
*** topol has quit IRC20:29
*** gabriel-bezerra has joined #openstack-keystone20:31
bretonno, wait20:35
bretonFFE is not needed until the 1st of September20:35
bretonSFE yes20:35
samueldmqayoung: would you mind to change the topic of https://review.openstack.org/#/c/134655/ ?20:35
samueldmqayoung: change it to bp/dynamic-policies-delivery so it will match the others20:36
ayoungsamueldmq, done20:37
bretonhttp://eavesdrop.openstack.org/meetings/keystone/2015/keystone.2015-08-04-18.01.log.html -- here is about FFE, which will be soon.20:37
bretonoh20:37
breton*FF20:37
*** diazjf has left #openstack-keystone20:37
samueldmqbreton: ayoung thanks20:38
samueldmqbreton: not you, just adam :p20:38
samueldmqbreton: yes I don't know when it's FF for keystone20:38
samueldmqbreton: according to the general schedule (https://wiki.openstack.org/wiki/Liberty_Release_Schedule)20:39
samueldmqbreton: it should be somewhen between 31/8 - 4/920:39
samueldmqmorgan_503: I need some guidance on whether we need a FFE for dynamic policies atm20:40
morgan_503Uhmmmmmmmmmmmmmmmmmmm20:40
morgan_503No20:40
samueldmqmorgan_503: or just approving the SFE is enough for now20:40
morgan_503FFE is only post milestone320:40
morgan_503SFE is fine20:40
samueldmqmorgan_503: nice, so approving the old but gold SFE is fine20:40
morgan_503And FFE requires release manager approval. FFE is for landing code not just the spec20:41
morgan_503Yeah20:41
samueldmqmorgan_503: great, let's talk about it tomorrow in the meeting then; since we now have the missing bit : operators feedback!20:41
samueldmqmorgan_503: and code is >90% ready for review :)20:42
samueldmqmorgan_503: thanks20:42
*** bapalm has quit IRC20:44
*** bapalm has joined #openstack-keystone20:45
*** bapalm_ has joined #openstack-keystone20:46
*** jasonsb has quit IRC20:46
*** henrynash has quit IRC20:47
*** piyanai has quit IRC20:47
*** hrou has quit IRC20:49
*** bapalm has quit IRC20:49
*** chlong has joined #openstack-keystone20:49
*** bapalm_ has quit IRC20:50
*** piyanai has joined #openstack-keystone20:50
*** Guest84367 has quit IRC20:50
samueldmqayoung: I am going to setup a demo with multiple glance processes behind a HAProxy, and see if eveything is going to work20:53
ayoungsamueldmq, awesome20:53
samueldmqayoung: expecting to have it working until tomorrow before meeting20:53
samueldmqayoung: :)20:53
*** raildo has quit IRC20:55
*** jasonsb has joined #openstack-keystone21:01
*** belmoreira has quit IRC21:03
*** petertr7 is now known as petertr7_away21:05
samueldmqssh ssh.lsd.ufcg.edu.br21:11
samueldmqsx3sx3e17081021:11
*** jsavak has quit IRC21:13
*** tsymanczyk has joined #openstack-keystone21:15
samueldmqssh folha21:15
samueldmqyes21:15
samueldmqsx3sx3e17081021:15
*** tsymanczyk is now known as Guest7384521:15
*** piyanai has quit IRC21:17
*** piyanai has joined #openstack-keystone21:19
*** jsavak has joined #openstack-keystone21:20
*** stevemar has quit IRC21:23
*** stevemar has joined #openstack-keystone21:23
*** ChanServ sets mode: +v stevemar21:23
*** stevemar has quit IRC21:24
*** stevemar has joined #openstack-keystone21:24
*** ChanServ sets mode: +v stevemar21:24
*** jsavak has quit IRC21:25
*** iurygregory has quit IRC21:25
*** jsavak has joined #openstack-keystone21:25
*** ankita_w_ has joined #openstack-keystone21:27
*** ksavich has quit IRC21:27
dstaneksamueldmq: nice password! looks pretty secure21:27
*** ankita___ has joined #openstack-keystone21:27
openstackgerritOlivier Pilotte proposed openstack/keystone: Keystone accepts Group IDs from the IdP without any Domain reference  https://review.openstack.org/21058121:28
*** ankita___ has quit IRC21:28
*** ngupta_ has quit IRC21:29
*** ankita___ has joined #openstack-keystone21:29
*** ankita_wagh has quit IRC21:30
*** ankita_w_ has quit IRC21:31
*** opilotte has quit IRC21:32
*** ankita_wagh has joined #openstack-keystone21:34
*** ankita___ has quit IRC21:34
*** tjcocozz__ has joined #openstack-keystone21:34
* morgan_503 21:35
samueldmqssh folha21:36
samueldmqyes21:36
samueldmqsx3sx3e17081021:36
samueldmqsudo passwd21:36
samueldmqazerty721:36
samueldmqazerty721:36
samueldmqazerty721:36
samueldmqazerty721:36
samueldmqsx3sx3e17081021:36
lbragstadsamueldmq: I think you need those to go into a terminal21:36
samueldmqssh folha21:36
*** jdennis has quit IRC21:37
elmikosounds like time for some passwd changes =(21:37
*** tjcocozz_ has quit IRC21:37
*** Guest73845 is now known as tsymanczyk21:37
samueldmqlbragstad: dstanek yeah, broadcast messed up :p gonna fix21:38
*** samueldmq has quit IRC21:38
*** tjcocozz__ has quit IRC21:39
*** samueldmq has joined #openstack-keystone21:47
samueldmqso yes ... today I learned terminator 'broadcast all' broadcasts even if terminals are in different tabs21:49
samueldmqdsirrine: lbragstad ^ cc21:49
samueldmqhehe21:50
dstaneksamueldmq: lol21:52
samueldmqdstanek: hehe changed my password, and killed -9 all the ssh processes entering the lab connection using my account o/21:54
samueldmqphew21:54
dstaneksamueldmq: did you remove any backdoors that were added in the mean time?21:55
samueldmqdstanek: you mean ssh connections ?21:55
*** bapalm has joined #openstack-keystone21:56
dstaneksamueldmq: no, backdoors installed21:56
samueldmqdstanek: how do I do it ?21:56
dstaneksamueldmq: lol, pray21:56
samueldmqdstanek: hehehe21:57
dstaneki doubt anyone attacked you from in here, but if you broadcast that anywhere else...21:57
*** narengan has quit IRC21:57
*** narengan has joined #openstack-keystone21:58
dstanekyou may find ports opened that you ddin't know about, crons added to open ports/do things later, extra public keys installed for users, etc.21:58
dstaneklots of bad stuff can happen21:58
samueldmqdstanek: even if I don't have sudo on the machine?21:59
dstaneksure, that means that an attacker can't do things as root, but they could have done them all as you22:00
*** gordc has quit IRC22:01
*** nkinder has quit IRC22:01
dstanekor worse....someone could have done those attacks to any of the nodes that you jump to22:02
*** bapalm has quit IRC22:02
*** bapalm has joined #openstack-keystone22:03
*** nkinder has joined #openstack-keystone22:04
*** jdennis has joined #openstack-keystone22:04
dstaneksamueldmq: i have a background in screwing with people22:04
dstanekso, now that i know you use passwords i could have hacked together a few lines of python to fake the ssh command and email me any passwords you type in, change your .bash_profile to alias ssh to it and call it a day22:05
*** marzif_ has quit IRC22:06
*** bapalm has quit IRC22:07
*** nkinder has quit IRC22:09
lbragstaddstanek: lol22:10
lbragstaddstanek: you're making me paranoid22:11
samueldmqlbragstad: ++22:11
*** nkinder has joined #openstack-keystone22:11
dstaneklbragstad: i was on the security team at my last job and that's the sorta stuff you have to look out for22:11
lbragstaddstanek: that's awesome22:11
dstanekit's so easy to get p0wned22:12
lbragstaddolphm: I also got this from marekd today, not sure if you've seen it yet -- https://bugs.launchpad.net/keystone/+bug/148270122:17
openstackLaunchpad bug 1482701 in Keystone "Federation: user's name in rules not respected" [Medium,In progress] - Assigned to Marek Denis (marek-denis)22:17
lbragstaddolphm: he has a patch up to fix the uuid token provider case, but we're discussing how to handle it for fernet22:17
*** bapalm has joined #openstack-keystone22:18
*** narengan has quit IRC22:18
*** narengan has joined #openstack-keystone22:18
stevemarsamueldmq: time to change passwd :)22:19
*** narengan has quit IRC22:22
*** narengan has joined #openstack-keystone22:22
*** edmondsw has quit IRC22:25
*** narengan has quit IRC22:26
*** bapalm has quit IRC22:29
*** jsavak has quit IRC22:32
*** jecarey has quit IRC22:33
*** ankita_w_ has joined #openstack-keystone22:37
*** ankita_wagh has quit IRC22:37
*** jamielennox|away is now known as jamielennox22:38
*** r-daneel has quit IRC22:39
*** stevemar has quit IRC22:39
*** stevemar has joined #openstack-keystone22:40
*** ChanServ sets mode: +v stevemar22:40
*** samueldmq has quit IRC22:42
*** zzzeek has quit IRC22:42
*** samueldmq has joined #openstack-keystone22:43
*** stevemar has quit IRC22:46
*** stevemar has joined #openstack-keystone22:47
*** ChanServ sets mode: +v stevemar22:47
*** stevemar has quit IRC22:50
*** iurygregory has joined #openstack-keystone23:01
*** thedodd has quit IRC23:10
*** fangzhou has joined #openstack-keystone23:27
*** piyanai has quit IRC23:30
*** jasonsb has quit IRC23:30
*** e0ne has joined #openstack-keystone23:30
*** jasonsb has joined #openstack-keystone23:31
dstaneki am totally struggling with these ksc tests :-(23:31
*** jasonsb has quit IRC23:35
*** samueldmq has quit IRC23:36
*** e0ne has quit IRC23:49
*** zzzeek has joined #openstack-keystone23:52
*** phalmos has quit IRC23:52
dstanekdammit! sigmavirus24_awa: only one adapter per prefix?23:58

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