Wednesday, 2015-05-27

*** emagana has quit IRC00:01
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove oslo.utils dependency from keystoneauth  https://review.openstack.org/18578900:11
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove lxml test-requirement  https://review.openstack.org/18579000:14
morganfainbergmordred, ^ no more lxml in keystoneauth!00:15
mordredwoot!00:15
morganfainbergdown to i18n and config as oslo deps00:15
*** markvoelker has joined #openstack-keystone00:16
morganfainbergi18n i'm just going to toss to the curb00:16
morganfainbergconfig will take a bit more thought00:16
*** sigmavirus24_awa is now known as sigmavirus2400:17
*** alanf-mc has joined #openstack-keystone00:19
*** david-lyle has quit IRC00:20
*** markvoelker has quit IRC00:23
*** markvoelker has joined #openstack-keystone00:23
morganfainbergmordred: well crap my attempt at killing oslo_utils failed because osprofiler00:24
morganfainbergmordred: :*(00:24
openstackgerritMerged openstack/keystoneauth: Remove oslo serialization dependency  https://review.openstack.org/18549700:27
dimsmorganfainberg: oslo-free keystone?00:30
morganfainbergdims: only keystoneauth lib00:30
dimsah :)00:30
*** Ephur has joined #openstack-keystone00:35
morganfainbergdims: since keystoneauth needs to have effectively no dependencies00:37
dims++ morganfainberg00:38
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove oslo.utils dependency from keystoneauth  https://review.openstack.org/18578900:41
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove lxml test-requirement  https://review.openstack.org/18579000:41
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove oslo.utils dependency from keystoneauth  https://review.openstack.org/18578900:43
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove lxml test-requirement  https://review.openstack.org/18579000:43
*** _cjones_ has quit IRC00:50
morganfainberghmm00:58
morganfainbergdims: so i am worried about i18n00:58
morganfainbergdims: we have a *lot* of strings to be translated00:58
morganfainbergdims: in keystoneauth00:59
morganfainbergdims: but i'm not sure how those are translated as is.00:59
morganfainbergdims: i also worry about the dependency graph issues when including i18n from oslo. *really* want to eliminate all oslo libs from this library, - is that a concern to keep it at all?01:00
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove oslo.i18n dependency  https://review.openstack.org/18579901:04
dimsmorganfainberg: if the library does not need to have end user visible strings, that's perfectly ok01:05
morganfainbergdims: here is the thing... it currently does.01:05
morganfainbergdims: however long term I think we can mitigate that01:05
dimsmorganfainberg: here's the primer on how translation is done https://wiki.openstack.org/wiki/Translations01:05
morganfainbergdims: but afaik keystoneclient isn't receiving translations as it is01:06
morganfainbergso the net impact is: we already aren't translating these01:06
dimsmorganfainberg: right, if you want then we have to set that up. instructions are on that page. i've done it once and we'll need andreas' help01:06
morganfainbergdims: my concern *really* is that i18n brings in incompatible dependencies, keystoneauth breaks in bad ways. so i think we just need to eliminate end-user facing trings01:06
morganfainbergstrings*01:06
dimsi agree01:07
dimsseveral oslo projects don't use i18n either01:07
morganfainbergok so i'll go with tossing i18n lib to the floor for this pass. we can work on the strings bit01:07
dimsack01:07
dimsi gotta wrap up. we can talk tomorrow. i'll do some reviews then as well.01:07
morganfainbergif you wouldn't mind just saying you have no isseus with this on that review? ^https://review.openstack.org/18579901:07
morganfainbergdims: when you get a chance01:08
morganfainbergjust so no one flips that we're doing this w/o planning01:08
morganfainbergdims: have a good one and thnx01:08
*** tobe has joined #openstack-keystone01:09
dimsmorganfainberg: one more way to slowly get rid of it is to do something like http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/_i18n.py#n4501:10
dims_ = _LI = _LW = _LE = _LC = lambda x: x01:10
morganfainbergdims: i think i smacked them all down already :)01:10
dimswill look deeper tomorrow. thanks01:10
dimscool :)01:11
*** dims has quit IRC01:12
openstackgerritMorgan Fainberg proposed openstack/keystoneauth: Remove oslo.i18n dependency  https://review.openstack.org/18579901:12
morganfainbergjamielennox|away: ^^ oslo_utils and oslo_i18n removed. down to oslo_config01:14
morganfainbergjamielennox|away: not sure how we want to handle that one.01:14
mfischlbragstad: do I need to hup keystone when I rotate fernet keys?01:18
morganfainbergmfisch: shouldn't need to01:19
mfischlbragstad: and can I do rotation on my own outside of fernet_rotate?01:19
morganfainbergmfisch: it should read out of the repository directly01:19
mfischI think I'll manage keys in hiera and rotate them as a commit01:19
morganfainbergmfisch: and you should be able to rotate outside of that too01:19
morganfainbergtool01:19
mfischthanks01:19
morganfainbergmfisch: just be sure it formats the repo as expected01:19
mfischhighest is primary, 0 is on-deck01:20
morganfainbergyep01:20
*** davechen has joined #openstack-keystone01:20
mfischso my plan is to keep re-using 0,1,201:20
morganfainbergkeep as many as you need to ensure validation01:20
mfischbut rotate them in my hiera01:20
morganfainbergmy expectation is most people will rotate ~1/wk or every 2wks01:20
morganfainbergeven though you could rotate much more often01:20
mfischwith our deployment schedule thats about what we'll do01:21
*** jamielennox|away is now known as jamielennox01:23
*** sigmavirus24 is now known as sigmavirus24_awa01:24
*** davechen1 has joined #openstack-keystone01:25
jamielennoxmorganfainberg: yea, oslo_config is hard - but looking at it there really aren't any deps from oslo.config01:26
*** davechen has quit IRC01:26
*** alanf-mc has quit IRC01:27
jamielennoxmorganfainberg: did i not upload the oslo.utils removal patch01:30
morganfainbergjamielennox: only saw serialization.01:31
jamielennoxi must have forgotten to upload them01:31
morganfainbergWe still have the dep issues. We will need to remove Oslo.config.01:31
mordredmorganfainberg, jamielennox: I see zero reasons for keystoneauth to grok oslo.config01:32
mordredwhat uses it?01:32
morganfainbergmordred: agreed. But today the auth plugins do.01:32
mordredwhy does an auth plugin grok oslo.config?01:32
* mordred doesn't want to know does he?01:32
*** ayoung has joined #openstack-keystone01:33
*** ChanServ sets mode: +v ayoung01:33
morganfainbergBecause it sources that data directly instead of passed it. Was/is an artifact from ksc and session there.01:33
morganfainbergNothing terrible.01:33
morganfainbergJust something to fix.01:34
mordredkk01:34
jamielennoxmordred: initially because the plugins need to be able to register themselves against a config file01:34
jamielennoxand then we used the oslo.config Opt classes for the get_options01:35
openstackgerritJamie Lennox proposed openstack/keystoneauth: Remove some cruft from the service catalog  https://review.openstack.org/18580501:35
openstackgerritJamie Lennox proposed openstack/keystoneauth: Make utils file private  https://review.openstack.org/18580601:35
openstackgerritJamie Lennox proposed openstack/keystoneauth: Remove oslo.utils dependency  https://review.openstack.org/18580701:35
*** setmason has quit IRC01:35
*** david-lyle has joined #openstack-keystone01:35
jamielennoxmorganfainberg: so that's what i didn't upload, i think we should do the first two and i don't cares which of the remove oslo.utils we do01:35
morganfainbergjamielennox: yeah I don't care. Just as long as it's done ;)01:35
jamielennoxrebasing that middle one will be a pain though01:36
morganfainbergI almost did that to the utile module in mine too. Hah.01:37
jamielennoxi have a patch open with debtcollector for it to take the positional decorator, i don't know if we would want that dep or not though01:38
morganfainbergI am not familiar with how debtcollector is moving. I'm inclined to be hesitant taking on another dep.01:39
morganfainbergIn an ideal world six and requests.01:39
jamielennoxstevedore or are you thinking that's a different lib01:39
morganfainbergBut I also see the need for stevedore.01:39
jamielennoxhttps://github.com/openstack/debtcollector/blob/master/requirements.txt01:39
mordredbabel is super heavyweight01:40
jamielennoxbut i have a review open to remove oslo.utils from debtcollector01:40
morganfainbergmordred: posted a change to drop babel and i18n already.01:40
jamielennoxthere is a circular dependency oslo.utils -> debtcollector -> oslo.utils - and people say pip is bad01:40
mordred:)01:41
morganfainbergjamielennox: let's carry positional. When we hit py3 we can make it go away.01:41
morganfainbergFor ksa at least.01:41
morganfainbergPy3 only*01:41
jamielennoxdhellmann: around?01:43
jamielennoxi keep missing him to ask about the ksc/ksa gate branch01:44
morganfainbergjamielennox: hehe. Got to be earlier. He is east coast.01:45
jamielennoxcan you ask him about it tomorrow?01:45
jamielennoxotherwise i've got the infra review ready to go and we can problably get it merged quick01:45
morganfainbergI shall try and bug him tomorrow.01:46
*** lhcheng_ has quit IRC01:46
*** kiran-r has joined #openstack-keystone01:55
mfischmorganfainberg: is there any middleware changes needed for the other services to handle fernet? I think the answer is no but would like a confirm02:09
mfischor a minimal version for other services to use fernet with...02:09
mfischI hope to blog about this when its working so that you dont have to answer the same questions02:10
*** kiran-r has quit IRC02:17
*** kiran-r has joined #openstack-keystone02:31
*** david-lyle has quit IRC02:33
*** setmason has joined #openstack-keystone02:33
*** gyee has quit IRC02:36
*** spandhe has quit IRC02:38
morganfainbergmfisch: you need a new enough django_openstack_auth02:40
morganfainbergmfisch: but no specific middleware changes should be needed.02:41
mfischmorganfainberg: django for horizon right not for other stuff02:42
mfischwe do have that iirc02:42
morganfainbergYes.02:42
morganfainbergThe new one doesn't try to hash fernet tokens.02:42
mfischyeah we're ahead of master on Horizon02:42
mfischlots of changes02:42
morganfainbergThen you should be good.02:42
mfischthanks for defeating all the FUD02:43
mfischUUID supporters are everywhere and not to be trusted02:43
dolphmmfisch: were you at the summit?! i never saw you02:44
mfischyeah I thought I'd do 4 talks02:44
mfischand then Tuesday I was in the puppet room02:44
mfischdolphm: were you at the +2 party?02:45
mfischI saw steve and brad there02:46
dolphmmfisch: i was not :(02:46
*** gokrokve has joined #openstack-keystone02:52
*** browne has quit IRC03:00
*** gokrokve has quit IRC03:06
*** gokrokve has joined #openstack-keystone03:07
*** lhcheng has joined #openstack-keystone03:07
*** ChanServ sets mode: +v lhcheng03:07
*** tobe has quit IRC03:08
*** gokrokve has quit IRC03:11
*** david-lyle has joined #openstack-keystone03:11
*** kiran-r has quit IRC03:18
morganfainbergmfisch: I am going to make devstack default to fernet this cycle.03:20
*** samueldmq has quit IRC03:21
*** tobe has joined #openstack-keystone03:26
*** pnavarro has quit IRC03:27
*** browne has joined #openstack-keystone03:30
*** stevemar has joined #openstack-keystone03:33
*** ChanServ sets mode: +v stevemar03:33
*** jaosorior has joined #openstack-keystone03:44
*** emagana has joined #openstack-keystone03:51
*** tobe has quit IRC03:58
openstackgerritJamie Lennox proposed openstack/keystoneauth: Remove old request method  https://review.openstack.org/18549204:04
*** links has joined #openstack-keystone04:15
*** markvoelker has quit IRC04:31
*** tobe has joined #openstack-keystone04:34
*** spandhe has joined #openstack-keystone04:49
*** gokrokve has joined #openstack-keystone04:56
*** spandhe has quit IRC04:59
*** kiran-r has joined #openstack-keystone05:00
*** tobe has quit IRC05:04
*** henrynash has joined #openstack-keystone05:10
*** ChanServ sets mode: +v henrynash05:10
*** csoukup has quit IRC05:12
*** gokrokve has quit IRC05:14
*** spandhe has joined #openstack-keystone05:20
*** henrynash has quit IRC05:23
*** belmoreira has joined #openstack-keystone05:23
*** cloudm2 has quit IRC05:32
*** setmason has quit IRC05:34
*** setmason has joined #openstack-keystone05:35
*** ncoghlan has joined #openstack-keystone05:38
*** gabriel-bezerra has joined #openstack-keystone05:45
*** tobe has joined #openstack-keystone05:50
*** emagana has quit IRC06:00
*** emagana has joined #openstack-keystone06:01
*** e0ne has joined #openstack-keystone06:01
*** gabriel-bezerra has left #openstack-keystone06:02
*** gabriel-bezerra has quit IRC06:02
*** emagana has quit IRC06:05
*** gabriel-bezerra has joined #openstack-keystone06:07
*** e0ne has quit IRC06:11
*** lhcheng has quit IRC06:19
*** tobe has quit IRC06:20
*** lhcheng has joined #openstack-keystone06:21
*** ChanServ sets mode: +v lhcheng06:21
*** ayoung has quit IRC06:22
*** lufix_ has joined #openstack-keystone06:29
*** mflobo has quit IRC06:29
*** mflobo1 has joined #openstack-keystone06:29
*** mflobo1 has quit IRC06:31
*** mflobo has joined #openstack-keystone06:33
*** tobe has joined #openstack-keystone06:38
*** ankita_wagh has joined #openstack-keystone06:45
*** ankita_wagh has quit IRC06:45
*** User17 has quit IRC06:52
*** pece has joined #openstack-keystone06:53
*** Ephur has quit IRC06:56
*** urtz has joined #openstack-keystone06:57
openstackgerritDave Chen proposed openstack/keystone: Add testcases to test DefaultDomain  https://review.openstack.org/18585506:57
*** urtz has quit IRC06:58
*** mabrams has joined #openstack-keystone06:58
openstackgerritDave Chen proposed openstack/keystone: Add testcases to test DefaultDomain  https://review.openstack.org/18585507:03
*** setmason has quit IRC07:06
*** spandhe has quit IRC07:10
*** setmason has joined #openstack-keystone07:12
*** markvoelker has joined #openstack-keystone07:17
*** stevemar has quit IRC07:20
*** emagana has joined #openstack-keystone07:25
*** ncoghlan has quit IRC07:26
*** emagana has quit IRC07:30
*** krykowski has joined #openstack-keystone07:30
*** tobe has quit IRC07:37
*** dims has joined #openstack-keystone07:38
*** tobe has joined #openstack-keystone07:38
*** dguerri`away is now known as dguerri07:40
*** setmason has quit IRC07:41
*** dims has quit IRC07:44
*** chlong has quit IRC07:45
*** lufix has quit IRC07:47
*** jistr has joined #openstack-keystone07:52
*** g2` has quit IRC07:58
*** emagana has joined #openstack-keystone08:04
*** g2` has joined #openstack-keystone08:05
*** emagana has quit IRC08:09
*** e0ne has joined #openstack-keystone08:15
*** henrynash has joined #openstack-keystone08:15
*** ChanServ sets mode: +v henrynash08:15
*** e0ne has quit IRC08:19
*** tobe has quit IRC08:42
*** lhcheng has quit IRC08:43
*** tobe has joined #openstack-keystone08:43
*** lhcheng has joined #openstack-keystone08:43
*** ChanServ sets mode: +v lhcheng08:43
*** fhubik has joined #openstack-keystone08:53
*** lhcheng has quit IRC08:54
*** emagana has joined #openstack-keystone08:59
*** lifeless has quit IRC09:00
*** lifeless_ has joined #openstack-keystone09:00
*** emagana has quit IRC09:03
*** fhubik is now known as fhubik_afk09:12
*** belmoreira has quit IRC09:15
*** ekarlso has quit IRC09:16
*** rushiagr_away is now known as rushiagr09:18
*** ekarlso has joined #openstack-keystone09:22
*** e0ne has joined #openstack-keystone09:23
*** e0ne is now known as e0ne_09:23
*** lhcheng has joined #openstack-keystone09:30
*** ChanServ sets mode: +v lhcheng09:30
*** lhcheng has quit IRC09:30
*** lhcheng has joined #openstack-keystone09:31
*** ChanServ sets mode: +v lhcheng09:31
*** e0ne_ is now known as e0ne09:31
*** lhcheng has quit IRC09:32
*** fhubik_afk is now known as fhubik09:33
mabramshi. need a link to the openstack keystone upstream etherpad pls.09:33
*** mattfarina has joined #openstack-keystone09:41
*** jaosorior has quit IRC09:42
*** mattfarina has quit IRC09:42
*** lhcheng has joined #openstack-keystone09:47
*** ChanServ sets mode: +v lhcheng09:47
*** davechen1 has left #openstack-keystone09:48
*** henrynash has quit IRC09:48
*** henrynash_ has joined #openstack-keystone09:48
*** ChanServ sets mode: +v henrynash_09:48
*** emagana has joined #openstack-keystone09:53
*** emagana has quit IRC09:57
*** lhcheng has quit IRC09:59
*** rushiagr has quit IRC10:08
*** dims has joined #openstack-keystone10:09
*** henrynash_ has quit IRC10:13
*** fhubik has quit IRC10:14
*** fhubik has joined #openstack-keystone10:14
*** fhubik is now known as fhubik_afk10:42
*** fmarco76 has joined #openstack-keystone10:46
*** emagana has joined #openstack-keystone10:47
*** fmarco76 has left #openstack-keystone10:47
*** emagana has quit IRC10:48
*** emagana has joined #openstack-keystone10:48
*** emagana has quit IRC10:53
*** lufix_ has quit IRC10:57
*** samueldmq has joined #openstack-keystone11:00
samueldmqmorning11:00
*** rushiagr_away has joined #openstack-keystone11:00
*** e0ne is now known as e0ne_11:26
*** dsirrine has quit IRC11:26
*** openstack has joined #openstack-keystone11:37
*** emagana has joined #openstack-keystone11:43
*** aix has joined #openstack-keystone11:47
*** emagana has quit IRC11:48
*** tobe has joined #openstack-keystone11:52
*** tobe has quit IRC11:56
*** tobe has joined #openstack-keystone11:57
*** markvoelker has quit IRC12:04
*** markvoelker has joined #openstack-keystone12:04
*** e0ne is now known as e0ne_12:09
*** e0ne_ is now known as e0ne12:14
*** jaosorior has joined #openstack-keystone12:19
samueldmqjamielennox, ping - you around ?12:26
samueldmqjamielennox, just to confirm, ksclient does not implement the policy CRUD, does it ?12:26
*** raildo has joined #openstack-keystone12:27
samueldmqjamielennox, well .. it does https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/policies.py12:27
samueldmq:)12:27
*** dims has quit IRC12:31
*** dims has joined #openstack-keystone12:32
*** emagana has joined #openstack-keystone12:37
*** emagana has quit IRC12:41
*** josecastroleon has joined #openstack-keystone12:49
*** ekarlso has quit IRC12:53
*** ekarlso has joined #openstack-keystone12:53
*** gordc has joined #openstack-keystone12:58
*** henrynash has joined #openstack-keystone13:02
*** ChanServ sets mode: +v henrynash13:02
lbragstadmfisch: just following up, you can rotate outside of that tool (you'll also need to find a way to distribute if your syncing your key repository across multiple keystone nodes -- which isn't supported by keystone-manage)13:02
*** ayoung has joined #openstack-keystone13:04
*** ChanServ sets mode: +v ayoung13:04
samueldmqayoung, henrynash hi !13:06
*** bknudson has joined #openstack-keystone13:06
*** ChanServ sets mode: +v bknudson13:06
samueldmqgood morning :)13:06
henrynashsamuelsmq: hi13:06
samueldmqhenrynash, ayoung +1ed the domain-roles spec ... but he prefers to call it namespaced roles13:06
samueldmqhenrynash, ayoung I'd like to put it on the table and discuss a little bit if you are available13:07
*** Ephur has joined #openstack-keystone13:07
ayounghenrynash, yes, me too13:07
samueldmqgreat13:07
henrynashayoung: so in princple that seems fine…is there an idea that a namespace might be more than a domain?13:07
henrynashayoung: i.e. some other namespace?13:08
samueldmqhenrynash, ++ that's the question .. should we consider per project roles ?13:08
ayounghenrynash, I was wondering if I had maybe misunderstood what you wanted with domain scoped roles.  And...I was thinking, how would we make sure, say, admin for openstack did not conflict with admin for something else, like13:08
ayoungIf we want to serve rolls...er roles, damn now I am all hungry13:08
ayounganyway, if we want to serve our roles for multiple applications, the namespace would keep them separate, but that was not what I thought you wanted with domain scoped roles.  But, it might be?13:09
henrynashayoung: so I would say decision 1 is: do we add namespace to a role (i.e. they are no longer global)….and I think that’s separate from whether that namespace can only be a domain namespace, or other namepaces13:10
ayounghenrynash, so...why domain scoped?13:10
samueldmqhenrynash, I guess ayoung wants some other namespaces, like: openstack, wordpress, etc13:10
samueldmqayoung, I think henry wants you to explain him any use case to have other than domain :)13:11
henrynashayoung: the need I see is for a company to be able to define the roles that are meaningful to them, and not just live with whatever teh cloud provider has created…..in installations where many customers are hosted on a cloud, and each customer is defined as a domain (which is teh usual case, I think )13:11
ayoungsamueldmq, yeah, but I want to make sure our problem definitions are aligning...I think they might be13:11
samueldmqmaybe you guys want to solve different problems13:11
samueldmqayoung, ++13:11
ayounghenrynash, you once said that you don't want other people to see the roles, but then we decided we needed to be able to enforce policy on the role.  Would a namespacing for the role (and who could define it)  solve your problem set?  I would see that we would want to lock down who could define what for a given organization...13:13
*** radez_g0n3 is now known as radez13:13
ayoungI'm not 100% namespacing is the entirety of the problem, but I think it is part of the way13:13
ayoungso...each domain *could* be a namespace....13:13
henrynashayoung, samueldmq: I think the other namespace taht could be relevant is a service namesapce…..i.e. a cloud wants to allow new services to onboarded that can then be “bought” by some of the customers…..and maybe the servcie provider (who is not the cloud provider) should be able to define the roles needed to execute the APIs offererd by that service13:13
ayoungand we could also have global namespaces for standard things like  wordpress13:14
ayounghenrynash, I think that is it.  We definitely want nested namespaces, with domain being a potential outer, one.13:14
*** Ephur has quit IRC13:14
samueldmqcool .. so we have domain-namespaces *and* global namespaces13:15
samueldmqso let's just call it namespaced roles :)13:15
ayoungactaully...yes, we'd always start with an outer namespace13:15
henrynashayoung: agreed, nested namespaces wil neeeded13:15
ayoungthe global would come from the admin domain, and would be assumed if no namespace was specified13:15
ayounghenrynash, you are a freaking jenious13:15
henrynasha service name spaces might be a child of the global name spaces13:15
ayoungthe global namespace would be the domains names13:16
samueldmqyeah, and we could namespace global roles with "openstack:" if we wanted to ...13:16
samueldmqso if we had "wordpress:", etc it would be clearer13:16
ayoungsamueldmq, yeah, something like that13:16
ayoungsamueldmq, and then, if the, say,  ibm.com domain wanted to have their own namespace, they would define  ibm.dom:wordpress:custom13:17
samueldmqayoung, yeah, as it fits better13:17
ayoungdom dom dom dom13:17
samueldmqayoung, henrynash great! and namespaced roles can contains other namespaced roles ? as per user grouping ? (that's the original idea from domain-roles)13:17
samueldmqayoung, hehhe13:17
ayoungso...need to figure out how that works with policy.13:18
ayoungI think global poliocy files are not going to cut it.13:18
ayoungthey are going to be too big, and have too much data.13:18
henrynashayoung: yeah, that’s where I usually come unstuck and regress into “hey, expand out the namespaced roles into global roles in the token”…then I can stop worrying!13:18
henrynashayoung: but you have convinced me that that does not work in the long run13:19
henrynashayoung: token bloat13:19
samueldmqhenrynash, namespaced roles can be or not contained by global roles, but anyway that will be huge i nthe future13:19
samueldmqhenrynash, ++13:19
samueldmqare we going to introduce role-namespace (or something like that) as a keystone citizen ?13:20
ayounghenrynash, really what we need is to be able to fetch policy for a service as the main way of working, with endpoint resolving to service.  So...  maybe we drop the idea of fetching a default opolicy file, and instead, always fetch buy endpoint....we can use the unified default as the file that gets returned for openstack services13:21
henrynashif we include the namespace in the defintion or a role (where it is referred to by policy), then we can start doing thi sproperly13:21
ayoungsamueldmq, I think namespaced roles will be M, not Liberty, but yes13:21
ayounghenrynash, ++13:21
samueldmqI think namespaced roles will be quite fun to implement with you :p13:22
samueldmqbtw, ayoung do you agree with the idea that namespaced roles can contain other namespaced roles (or gloabl roles)13:22
samueldmq?13:22
henrynashayoung: I’m pretty sure you are right, it will take a couple of releases….since wherever there is a role (assignment, token, policy rule) we need to be able to handle a namespace (or it by an ID such that it is unique anyway)13:22
ayoungThe siphonaptera lives!13:23
ayoung"Big fleas have little fleas,13:26
ayoungUpon their backs to bite 'em,13:26
ayoungAnd little fleas have lesser fleas,13:26
ayoungand so, ad infinitum."13:26
samueldmq:)13:26
samueldmqayoung, btw in the policy stuff ... do you plan to add the capability to have a policy per domain, irght ?13:27
samueldmqthis is so very important for reseller imo13:27
*** henrynash has quit IRC13:27
*** emagana has joined #openstack-keystone13:31
ayoungsamueldmq, not per domain, yet, but people keep asking for scoped policy.  I just need to figure out how to distribute it.13:33
samueldmqayoung, a service endpoint would need to be able to know what service/domain(s) it is serving when fetching the policy files13:34
*** krykowski has quit IRC13:35
*** krykowski_ has joined #openstack-keystone13:35
ayoungsamueldmq, something like that...but how do you keep each token from triggering a fetch for a different policy...13:35
*** emagana has quit IRC13:35
samueldmqayoung, well ... token scope always contain a domain_id (directly or via project)13:36
*** jsavak has joined #openstack-keystone13:36
samueldmqayoung, but yes, there are tricky questions to care about .. and this is future work :)13:37
ayoungyep13:37
ayoungbaby steps13:37
ayoungor at least, walkin steps...and looking before we leap13:37
samueldmq:)13:37
samueldmqayoung, btw, pm'd you13:37
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Fix assertion examples  https://review.openstack.org/18598513:38
*** links has quit IRC13:41
*** cloudm2 has joined #openstack-keystone13:42
*** mabrams has quit IRC13:44
*** mabrams has joined #openstack-keystone13:50
*** gsilvis has quit IRC13:53
*** gsilvis has joined #openstack-keystone13:54
openstackgerritNikita Konovalov proposed openstack/python-keystoneclient: Fix logging of binary contentent in request  https://review.openstack.org/18351413:57
*** Ephur has joined #openstack-keystone14:01
*** chlong has joined #openstack-keystone14:05
*** sigmavirus24_awa is now known as sigmavirus2414:06
*** csoukup has joined #openstack-keystone14:13
mabramsayoung: where'z the upstream etherpad? thx14:13
*** rlt_ has joined #openstack-keystone14:14
ayoungmabrams, um...   https://etherpad.openstack.org/p/testing-keystone-ldap-nondefault-domain  was one...14:14
ayoungwhich topic?14:14
*** tobe has quit IRC14:15
mabramsayoung: nevermind ID-10T error14:15
ayoungmabrams, I'm trying to get something to work with Rabbit.  I think there is a way to see all events on the broker, if you run in debug mode.  I think it will help test the notifications14:18
mabramsayoung: makes sense; will do that14:19
ayoungmabrams, let me see if I can get it to work.  It supposedly needs a web browser, but I don't really have one on the system I have installed,except for Lynx14:19
ayoungmabrams, I did a yum install of rabbitmqadmin14:20
ayoung sudo rabbitmq-plugins enable rabbitmq_management14:21
mabramsayoung: then set DEBUG mode?14:21
ayoungsudo systemctl restart rabbitmq-server.service14:21
ayoungI'm still learning this...14:21
*** timcline has joined #openstack-keystone14:21
ayoungyou can then get the cli by running14:22
ayoungwget  http://10.10.10.40:15672/cli  but with your local ipaddress14:22
mabramsgotcha14:22
ayounghttps://www.rabbitmq.com/management-cli.html14:22
ayoungmabrams, but I have not yet been able to see the keystone messages.  Looking at the topic:14:23
mabramsayoung: are there otherwise meaningful msgs tho?14:23
ayoungmabrams, I ran packstack, so I was able to find the password in the answers.txt file14:23
ayoung python rabbitmqadmin -H 10.10.10.40 -P 15672 -u guest -p guest list exchanges14:23
ayoungbut maybe I should be using a different account?14:24
mabramsprolly14:24
mabramsseems guest is a guest14:24
ayoungmabrams, but...the keystone.conf file also has guiest/guest14:24
*** kiran-r has quit IRC14:25
ayoungrabbit_userid=guest14:25
*** kiran-r has joined #openstack-keystone14:25
ayoungmabrams, I was following the code example here http://chrigl.de/blogentries/oslo-messaging-example14:26
ayoungWhere is stevemar when I need him?14:26
ayoungmabrams, so I modified the recv code to try and listen to the keystone topic, but no messages14:27
ayoungI should probably ask in an oslo room...14:27
*** HT_sergio has joined #openstack-keystone14:28
mabramsayoung: https://etherpad.openstack.org/p/HMT-hierachical_multitenancy but dare i say tcms :-o formats it better14:28
ayoungmabrams, yeah, but then it is behind a firewall.14:29
mabramsayoung: yup14:29
ayoungmabrams, lets see if we can scare up someone that knows this better'n I do14:29
mabramsayoung: appreciate your troubles14:30
ayounghtruta, raildo care to take a look at mabrams ' etherpad?  He's working on a test plan for HMT?14:30
raildoayoung, sure, I'll take a look now :)14:31
ayoungTYVM raildo14:31
htrutaayoung: sure!14:31
htrutamight interest rodrigods as well14:31
*** kiran-r has quit IRC14:32
ayoungmabrams, there will bhe a little churn, as your focus thus far has been RHOS, but we need publically available distros for a public test like this.  We shouold probably put links to the RDO repos we are suggesting for testing14:32
ayounglet me see....14:32
*** mestery has quit IRC14:33
*** krykowski_ has quit IRC14:33
*** mestery has joined #openstack-keystone14:34
*** dims has quit IRC14:35
*** krykowski has joined #openstack-keystone14:37
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Fix assertion examples  https://review.openstack.org/18598514:38
*** emagana has joined #openstack-keystone14:40
*** ksavich has joined #openstack-keystone14:41
*** hemnafk is now known as hemna14:50
*** dims_ has joined #openstack-keystone14:55
*** gokrokve has joined #openstack-keystone14:59
*** timcline has quit IRC15:01
*** timcline has joined #openstack-keystone15:02
*** krykowski has quit IRC15:08
*** e0ne is now known as e0ne_15:13
*** tobe has joined #openstack-keystone15:15
*** tobe has quit IRC15:20
*** e0ne_ is now known as e0ne15:22
*** mabrams has quit IRC15:26
*** gokrokve has quit IRC15:27
*** gokrokve has joined #openstack-keystone15:28
lbragstadnkinder: is this something we still want to backport? https://review.openstack.org/#/c/182603/115:30
nkinderlbragstad: yes, I think so15:31
*** setmason has joined #openstack-keystone15:31
*** gokrokve has quit IRC15:32
*** csoukup has quit IRC15:33
*** browne has quit IRC15:39
*** gokrokve has joined #openstack-keystone15:42
*** lifeless_ is now known as lifeless15:53
*** fhubik is now known as fhubik_afk15:57
*** alanf-mc has joined #openstack-keystone15:59
*** emagana has quit IRC16:00
*** emagana has joined #openstack-keystone16:02
*** jistr has quit IRC16:07
*** alanf-mc_ has joined #openstack-keystone16:09
*** stevemar has joined #openstack-keystone16:11
*** ChanServ sets mode: +v stevemar16:11
*** alanf-mc_ has quit IRC16:11
*** alanf-mc has quit IRC16:11
*** alanf-mc has joined #openstack-keystone16:12
*** browne has joined #openstack-keystone16:17
*** fhubik_afk is now known as fhubik16:18
*** gokrokve has quit IRC16:19
*** gokrokve has joined #openstack-keystone16:19
*** _cjones_ has joined #openstack-keystone16:20
*** gokrokve has quit IRC16:21
*** vilobhmm has joined #openstack-keystone16:22
openstackgerritMichael Simo proposed openstack/python-keystoneclient: Fixed grammatical errors in the V2 Client API doc  https://review.openstack.org/18607416:24
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Fixe example code in Using Sessions page  https://review.openstack.org/17513516:30
*** BrAsS_mOnKeY has joined #openstack-keystone16:37
openstackgerritIan Cordasco proposed openstack/keystoneauth: Replace datetime calculations with utility functions  https://review.openstack.org/18607616:42
openstackgerritMichael Simo proposed openstack/python-keystoneclient: Fixed grammatical errors in the V2 Client API doc  https://review.openstack.org/18607416:46
*** claps has joined #openstack-keystone16:47
*** timsim has joined #openstack-keystone16:47
*** radez is now known as radez_g0n316:48
clapsSuper basic question: Can you have many users with different roles under a single project?16:48
*** ksavich has quit IRC16:48
*** timcline has quit IRC16:50
rodrigodsclaps, yep... you can assign how many roles you want to a user in a project16:51
*** alanf-mc has quit IRC16:52
raildoclaps, and the same for groups :)16:53
*** alanf-mc has joined #openstack-keystone16:53
*** emagana has quit IRC16:53
clapsCool :)16:55
*** hemna is now known as hemnafk17:03
*** tobe has joined #openstack-keystone17:04
morganfainberglbragstad: http://lists.openstack.org/pipermail/openstack/2015-May/012885.html17:06
morganfainberglbragstad: ldap identity + fernet.17:06
morganfainbergLooks like we have some issues.17:06
morganfainbergCc dolphm ^17:06
morganfainbergI'll take a gander at it post food if you haven't already.17:07
ayoungmorganfainberg, how does the ID source adffect the token  based on FOrmat?17:07
ayoungValueError: badly formed hexadecimal UUID string17:07
morganfainbergayoung: because ldap hairs partial DN and we I think did the silly and assumed UUID.17:08
*** fhubik is now known as fhubik_afk17:08
ayoung"/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/token_formatters.py", line 416, in assemble17:08
ayoungcls.convert_uuid_hex_to_bytes17:08
morganfainbergThis would also possibly break on mapped users with the sha25617:08
ayoungmorganfainberg, sure looks like it17:08
morganfainbergYep.17:08
morganfainbergI need food then I'm going to poke at this with a stick.17:09
morganfainbergUnless I can get lbragstad or dolphm to.17:09
*** tobe has quit IRC17:09
*** rlt_ has quit IRC17:10
*** fhubik_afk is now known as fhubik17:12
*** vilobhmm has quit IRC17:12
*** vilobhmm has joined #openstack-keystone17:13
*** alanf-mc has quit IRC17:14
*** vilobhmm has quit IRC17:16
*** alanf-mc has joined #openstack-keystone17:16
*** e0ne is now known as e0ne_17:16
*** gokrokve has joined #openstack-keystone17:17
*** zzzeek has joined #openstack-keystone17:18
*** alanf-mc has quit IRC17:18
lbragstadmorganfainberg: it's because we try to convert the uuid string to bytes to make the token smaller17:19
morganfainberglbragstad: yep. We can't make that assumption.17:20
lbragstadmorganfainberg: that should be a pretty easy fix17:20
morganfainberglbragstad: we have ids that are sha256 and partial dn.17:20
lbragstadmorganfainberg: we do the same thing with domain ids17:20
morganfainbergYeah. Just raising it up.17:20
*** e0ne_ is now known as e0ne17:20
morganfainbergDomain I assume you have a special case for "default"?17:20
*** alanf-mc has joined #openstack-keystone17:20
lbragstadhttps://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/token_formatters.py#L363-L36717:21
morganfainberglbragstad: we'll need to fix this for liberty and backport to kilo. I can file the big and tackle post food or you can.17:21
morganfainbergS/big/bug17:21
morganfainbergEither way. Will check with you before i start working on it.17:22
*** fhubik has quit IRC17:23
lbragstadmorganfainberg: we already have a method that should handle that case17:23
stevemarlbragstad, gerrit powered agenda is alive17:23
*** claps has quit IRC17:23
morganfainberglbragstad: cool.17:23
lbragstadthis guy https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/token_formatters.py#L41517:23
lbragstadjust needs to use attempt_convert_uuid_hex_to_bytes17:24
lbragstadlike we do here https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/token_formatters.py#L50917:24
*** fhubik has joined #openstack-keystone17:24
mfischlbragstad morganfainberg next time you guys add a new key provider which may be never again, I'd vote for supporting multiple token backends17:24
*** e0ne has quit IRC17:25
lbragstadmorganfainberg: patch http://cdn.pasteraw.com/2d2vvm3nvm1yilx6b2wpfhi1dzx2rza17:25
lbragstadmorganfainberg: that should retain the original username17:25
openstackgerritIoram Schechtman Sette proposed openstack/keystone-specs: API spec for searching on the Policy database  https://review.openstack.org/18609317:26
lbragstadstevemar: ++ (finally?)17:26
lbragstads/username/userid/17:26
*** mrutkows has joined #openstack-keystone17:26
stevemardamn fernet, this is why we need real functional tests :(17:26
lbragstadmfisch: so, you mean you'd want something that's smart enough to know the difference between the token formats and do stuff based on the token?17:27
mfischso please humor me, but wouldnt that be simple?17:27
mfischif not please say so17:27
mfischa UUID token and a fernet looks different enough to me17:27
mfischthis way I dont have to take any outage to switch17:28
mfischMorgan already said no to me on this but he's not a friendly upper midwesterner like you lbragstad17:28
lbragstadmfisch: I guess that would all depend on the deployment and how they want to handle each token format... it feels like there is a lot of room for edge cases...17:29
*** emagana has joined #openstack-keystone17:31
mfischlbragstad: thats probably true, just something to think about17:31
lbragstadmfisch: like if you wanted to migrate from uuid tokens to fernet tokens, and every time a user authenticates, how do you determine what kind of token to give them?17:32
mfischI've not done much thinking about the design, but if you have a list of token providers, you'd grant using the 1st entry but accept both17:33
mfischperhaps17:33
mfischwe're switching regardless17:33
mfischbut it would be nicer of a process17:33
lbragstadmfisch: yeah, I could see that17:33
openstackgerritIoram Schechtman Sette proposed openstack/keystone-specs: API spec for searching on the Policy database  https://review.openstack.org/18609317:33
samueldmqmorganfainberg, I was looking at https://wiki.openstack.org/wiki/CrossProjectLiaisons17:33
lbragstadmfisch: mind if I ask how you're handling the migration currently?17:33
samueldmqmorganfainberg, and I think lhcheng could be set as Horizon/Keystone, if he is willing to17:34
bknudsondidn't we used to have pki and uuid runs in tempest?17:34
samueldmqmorganfainberg, in the 'Inter-project Liaisons' section17:34
bknudsonI guess we can't have fernet runs in tempest until devstack supports it17:34
morganfainbergbknudson: correct.17:34
mfischlbragstad: emailing customers telling them there will be a small outage and combining it with a keystone to liberty upgrade17:34
bknudsonseems like we need to call fernet tokens unsupported until we get tests17:34
bknudsonalthough we don't have an ldap functional test either17:35
morganfainbergbknudson: we wouldn't have caught this with devstack tests.17:35
mfischglad to be using 2 untested features!17:35
*** vhoward has left #openstack-keystone17:35
lbragstadmfisch: ok, so then they will just have to reauthenticate and all tokens prior to the migration will be invalid (because they were UUID), right?17:35
*** aix has quit IRC17:35
mfischyou guys talking about a fernet issue that I should know about?17:35
mfischlbragstad: yeah, we'll do it when we have low API usage. We have predictable customers17:35
*** vilobhmm has joined #openstack-keystone17:35
lbragstadhttp://lists.openstack.org/pipermail/openstack/2015-May/012885.html mfisch17:35
lbragstadmfisch: gotcha17:36
morganfainbergbknudson: so I'll be spending time today to get fernet in gate or lined up for it.17:36
samueldmqbknudson, so we need devstack to be able to deploy keystone with ldap and with fernet tokens as well (with different flags, of course) ?17:36
mfischthanks for that pointer lbragstad17:36
samueldmqmorganfainberg, ++17:36
bknudsonmorganfainberg: do they want a full tempest run for it? I thought they wanted functional tests in keystone17:36
morganfainbergThe LDAP issue will be functional testing based.17:36
lbragstadmfisch: are your user ids stored as something other than uuid?17:36
mfischlbragstad: no, but we kinda use LDAP17:37
morganfainbergbknudson: I am planning on supporting it. I want fernet to be the default in devstack.17:37
mfischwe store user details in mysql though17:37
morganfainbergbknudson: this cycle.17:37
bknudsonok, so we'd have uuid as functional tests then17:37
morganfainbergbknudson: yes.17:37
bknudsonseems like we should have a set of common functional tests and reconfigure for uuid, pki, or fernet17:37
morganfainbergbknudson: but work is required on the fernet front before that. And it's he same work.17:37
morganfainbergSo I'll do what I can to get that done today.17:38
morganfainbergOr at least in Gerrit.17:38
lbragstadmfisch: the issue is that when you use LDAP identity with user IDs that aren't UUID, the Fernet token provider/formatter doesn't know how to convert them to bytes (because they aren't uuid).17:38
*** vilobhmm has quit IRC17:38
lbragstadbknudson: I was working on that kind of consolidation17:38
mfischah17:38
mfischI think we wont have that issue but I will test more17:39
lbragstadbknudson: instead of having a bunch of "different" tests for the token providers that test the same situations17:39
bknudsonwe're going to have a lot of functional test jobs17:39
*** hemnafk is now known as hemna17:39
stevemarbknudson, don't have to fun them all at once17:40
mfischlbragstad: I'm writing my own python code to manage keys inside yaml, have jenkins propose the rotate as a review and merge it on my schedule17:41
lbragstadmfisch: nice17:42
mfischI thought generating a key would be some difficult black magic, its just 1 line17:42
lbragstadmfisch: yeah, it's not too bad17:42
mfischlbragstad: I'll tell you from experience and trying to explain it that a diagram on key rotation would go a long way17:43
lbragstadmfisch: I think we did have one floating around17:43
lbragstadmfisch: https://docs.google.com/presentation/d/1T1ULahHFhgEcRIT6OsG0b24yjDAlV3nYS7x9d2yCtpM/edit?usp=sharing starting at slide 1417:44
mfischlbragstad: this?  https://s-media-cache-ak0.pinimg.com/originals/a4/87/96/a4879637ca54b1a16712db680a00f229.jpg17:44
lbragstadexactly, something like that!17:44
openstackgerritMerged openstack/keystoneauth: Remove some cruft from the service catalog  https://review.openstack.org/18580517:44
mfischlbragstad: I hope to do a nice blog post about this to explain it once we're live17:45
mfischshould be in dev today or tomorrow17:45
mfischdepending on my battle with eyaml17:45
lbragstadmfisch: that would be great, let me know how it goes!17:45
* mfisch saves that link for the blog17:45
*** vilobhmm has joined #openstack-keystone17:48
*** vilobhmm has quit IRC17:48
lbragstadmfisch: also have these incase they help http://lbragstad.com/?p=133 http://lbragstad.com/?p=156 http://lbragstad.com/?p=16717:49
*** vilobhmm has joined #openstack-keystone17:49
mfischoh yeah I've read those17:49
*** emagana has quit IRC17:50
*** chlong has quit IRC17:53
*** vilobhmm has quit IRC17:53
*** timcline has joined #openstack-keystone17:57
*** rushiagr_away is now known as rushiagr18:00
rodrigodslbragstad, nice posts - nice to read "real world" deployments issues/solutions18:01
lbragstadrodrigods: not sure how real world they are ;) I just hoped they would help explain the concepts a little bit18:01
*** dims_ has quit IRC18:02
*** dims_ has joined #openstack-keystone18:03
*** lhcheng_ has joined #openstack-keystone18:03
rodrigodslbragstad, hehe see how fernet helps to solve distributed stuff is really cool18:03
lbragstadrodrigods: thanks!18:03
*** fhubik has quit IRC18:04
*** e0ne has joined #openstack-keystone18:06
*** e0ne is now known as e0ne_18:06
*** alanf-mc has quit IRC18:06
*** e0ne_ is now known as e0ne18:07
*** alanf-mc has joined #openstack-keystone18:07
*** lufix has joined #openstack-keystone18:10
*** lufix has quit IRC18:11
*** setmason has quit IRC18:11
*** lufix has joined #openstack-keystone18:12
*** setmason has joined #openstack-keystone18:13
lbragstadmorganfainberg: do you have a bug open for that Fernet issue?18:20
lbragstadmorganfainberg: if not I can open one, but I didn't want to duplicate it if you already had one18:21
*** setmason has quit IRC18:21
*** vilobhmm has joined #openstack-keystone18:23
openstackgerritMerged openstack/keystone: Update dev setup requirements for Python 3.4  https://review.openstack.org/17521618:24
morganfainberglbragstad: no bug yet. Saw that as I was walking to food.18:25
lbragstadmorganfainberg: I got it, no worries18:25
*** vilobhmm1 has joined #openstack-keystone18:27
*** lufix has quit IRC18:29
openstackgerritLance Bragstad proposed openstack/keystone: Don't fail on converting user ids to bytes  https://review.openstack.org/18612018:30
*** vilobhmm has quit IRC18:30
lbragstadmorganfainberg: https://bugs.launchpad.net/keystone/+bug/145938218:31
openstackLaunchpad bug 1459382 in Keystone "Fernet tokens can fail with LDAP identity backends" [Medium,In progress] - Assigned to Lance Bragstad (lbragstad)18:31
morganfainberglbragstad: I might classify that as high. As it breaks fernet in a common scenario.18:31
morganfainberglbragstad: otherwise ++18:31
lbragstadmorganfainberg: go for it18:31
morganfainbergcommon deployment scenario.18:31
*** setmason has joined #openstack-keystone18:31
morganfainbergWill do once I'm done with food and off mobile.18:32
bknudsonfernet's not supported so it should be low18:34
ayoungmorganfainberg, can you remove -2 from Henry's spec https://review.openstack.org/#/c/133855/  ? I think we each  have a better understanding of what the other wants, and this has the potential to be very valuable18:34
*** setmason has quit IRC18:34
lbragstadbknudson: morganfainberg you guys can triage however you see fit, but the patch is up18:34
*** setmason has joined #openstack-keystone18:34
morganfainbergayoung: re propose to backlog or Liberty then I'll un -218:35
ayoungmorganfainberg, can you un -2 first, so I can submit with same change request ID?18:35
ayoungI don't think I can as is...or can I?18:35
ayoungMaybe I can...I was thinking abandoned.  OK18:35
morganfainbergYah.18:35
morganfainbergAbandon needs restored first. -2 is just sticky.18:36
morganfainberglbragstad: I don't really care as long as it is fixed *and* back ported to kilo.18:36
openstackgerritayoung proposed openstack/keystone-specs: Add support for domain specific roles.  https://review.openstack.org/13385518:36
morganfainberglbragstad: priority is not super important on that front. We are fixing it and making sure it's in place.18:36
ayoungmorganfainberg, done18:37
morganfainbergayoung: -2 removed.18:37
mfischlbragstad: curious about the permissions you chose for the key folder and the keys18:39
mfischlbragstad: wouldn't you want only root to be able to write new keys?18:39
lbragstadmfisch: I think it's just meant to be whatever user is the keystone user18:39
*** nowen has joined #openstack-keystone18:40
mfischif that user is compromised I guess you might have other issues.18:40
mfischlike the config file18:40
lbragstadexactly18:40
mfischlooks like crytography isn't packaged :(18:41
nkindermfisch: packaged for what?18:41
*** lufix has joined #openstack-keystone18:41
*** lufix has quit IRC18:41
*** lufix has joined #openstack-keystone18:41
mfischnkinder: ubuntu18:41
mfischnot that I can find anyway18:41
nkindernot sure.  I know someone on my team packaged the 0.9.0 release recently for Fedora and is working on RHEL packages (not that it helps you)18:42
lbragstadhttps://cryptography.io/en/latest/installation/#supported-platforms18:43
nowengreetings - I'm wondering if it's possible to use mod-auth-radius for authentication?18:43
*** mattfarina has joined #openstack-keystone18:43
lbragstadmfisch: are you using ubuntu 14.04?18:43
mfischy18:43
nkindernowen: mod_auth_* should work if it sets REMOTE_USER18:44
nkindernowen: the difficulty is figuring out how you supply the credentials depending on the client application18:44
mfischlooks like it's in U and beyond, but not in 14.0418:44
lbragstadmfisch: might be worth dropping in the #cryptography-dev channel?18:44
mfischI have upload rights if I can find the motivation to not just use pip18:45
*** lufix has quit IRC18:47
*** vilobhmm has joined #openstack-keystone18:47
*** vilobhmm1 has quit IRC18:48
nowennkinder:  ok - and I gather I have to uncomment external = keystone.auth.plugins.external.DefaultDomain for it to work?18:49
nkindernowen: yes18:50
morganfainbergdstanek: looking forwrd to seeing keystone + Flask18:50
*** mattfarina has quit IRC18:50
morganfainbergdstanek: btw :)18:50
nkindernowen: something similar to this - https://github.com/nkinder/rdo-vm-factory/blob/master/rdo-kerberos-setup/vm-post-cloud-init-rdo.sh#L130-L13218:51
nkindernowen: you should be able name it 'radius' instead of 'kerberos', then use DefaultDomain instead of KerberosDomain18:51
nowenok18:51
*** tobe has joined #openstack-keystone18:53
*** gokrokve has quit IRC18:53
*** mattfarina has joined #openstack-keystone18:54
morganfainbergayoung: is there any reason why the identity manager shouldn't be doing the auto-id generation and why this lives at the controller level?18:55
morganfainbergayoung: it seems weird that the controller is responsible for business logic18:55
ayoungmorganfainberg, predates me18:55
ayoungit was how termie wrote it18:55
morganfainbergayoung: s/identity/resource18:55
morganfainbergayoung: sure. i'm asking more from a "should we make an effort to push this down a layer" and try and keep business logic out of the controller?18:55
ayoungI think we can safely bury it18:56
*** gokrokve has joined #openstack-keystone18:56
ayoungI know that I was dumb in ussing UUIDs for Revocation events18:56
morganfainbergayoung: it's not a lot of changes, just one of those "hmmmm" we should just do that type things18:56
ayoungwould have been better to autoinc those from the DB, but those are not exposed anyway18:56
morganfainbergayoung: we can still move to an autoinc, it's not a complex migration18:56
ayoungseems to be a Backend specific logic, just shared to use uuids, I think18:57
ayoungyah, just have not done so.  Its on my list18:57
morganfainbergbreton: do we have a review to push it to liberty? if not can you make that happen so we can start getting alembic awesome in keystone18:58
*** tobe has quit IRC18:58
morganfainbergayoung: yeah no rush there. i'm still poindering how to move the extension migration repos into the main migration repo.18:58
morganfainbergayoung: so we can finish that cleanup18:58
ayoungmorganfainberg, if the tables don't have constraints between them. it is cleaner to have them in separate repos18:59
*** e0ne has quit IRC18:59
ayoungmake the migration number assignement easier to deconflict18:59
morganfainbergayoung: alembic gets weird with multiple repos in a single db afaik19:00
ayoungand, it makes a path toward ID and  Assignment into two services19:00
morganfainbergayoung: that last part is going to be the same work regardless19:00
morganfainbergayoung: since those two are already merged19:00
morganfainbergi'm thinking revocation events, endpoint filtering, etc19:00
ayoungtrue, but that was my rationale for putting extensions in their own repos in the first place19:01
morganfainbergayoung: right and since we're doing away with in-tree extensions19:01
*** rushiagr is now known as rushiagr_away19:01
*** spandhe has joined #openstack-keystone19:01
ayoungmorganfainberg, If I were starting from scratch, I would put each of the backends in their own migrate repo19:01
morganfainbergayoung: having them always migrated w/o needing the extra shim to lookup/call the right repo migration is probably better19:01
morganfainbergayoung: i'd put them in their own database.19:02
ayoungI think that was what temrie had in mind originally, he just only had one backend in sql19:02
morganfainbergnot just separate repos/tables19:02
ayoungyep19:02
ayoungin order to do that, we need to be able to have separate DB connectison, which we need for other features, too19:02
morganfainbergnow, i don't think the former extensions belong in the corner like they are19:03
ayoungI'd like to use the same approach as domain specific backend for that, but call it named resources, and a DB connection would be a named resource.  should tie in with dstanek 's DI cleanup19:03
ayoungagreed19:03
morganfainbergthe endpoint filtering belongs in the same place catalog does19:03
ayoungmorganfainberg, assignemnt, oauth, and trusts all need to be in the same DB19:04
morganfainbergrevocation events belong in the same place token-things do.19:04
ayoungno19:04
ayoungtokens and revoke actually should be 2 DBs19:04
ayoungthe life cycle of them are different19:04
morganfainbergok well let me just say we shouldn't have bad shim code in place just to remember to migration another repo.19:05
ayoungagreed19:05
morganfainbergright now that is what we have19:05
morganfainbergi'd rather see (until oslo.db gets better) everything always migrated from a single source.19:05
morganfainbergbecause i don't know when the extra connector work will be done19:05
ayoungbut that is cuz our CLI only assumes there is on repo.  db_sync should migrate all active repos, not \"the real one and oh by the way these others"19:05
morganfainbergif that can be done soon, great separate things better19:05
ayoungand db_version should be version by module19:05
ayoungmorganfainberg, why not leave it until we get an alembic solution in place, then, and do it as part of the alembic work, instead of doing it twice?19:06
morganfainbergayoung: i was thinking we would do the collapse to 1 repo with alembic landing19:06
ayoungI see no reason to waste cycles on SQL-A imigrations f we are not going to stick with them long term19:06
ayoungIs anyone taking on alembic?19:07
morganfainbergayoung: ^^ i was just asking breton about it19:07
morganfainbergayoung: which lead me to this convo :)19:07
morganfainbergayoung: i wouldn't merge with SQL-A-Migrate.19:07
morganfainbergnot worth the effort unless alembic is going to be late M-cycle or beyond19:08
gabriel-bezerraayoung: What is the link to the spec you assigned me and David Chadwick on Trello?19:08
ayounggabriel-bezerra, https://trello.com/b/260v4Gs7/dynamic-policy19:08
gabriel-bezerraI can see many database things here: https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+branch:master+topic:dynamic-policy,n,z19:08
ayounggabriel-bezerra, miscliecked, was supposed to iorem19:09
gabriel-bezerraplus this one, that is in another topic: https://review.openstack.org/#/c/13381419:09
gabriel-bezerraayoung: ok19:09
ayounggabriel-bezerra, that is not assignment, BTW  I'm just trying to track who is working on what,   General guidance, not "you are on the hook"19:11
ayoungat least, not there19:11
*** mattfarina has quit IRC19:12
morganfainbergayoung: is there a reason dynamic policy board on trello is private?19:13
* morganfainberg would think it should be public.19:13
morganfainbergbut thats just a open development view.19:13
HT_sergioI'm fairly sure I found a bug in keystonemiddleware.auth_token. Who can talk to about this ?19:15
ayoungmorganfainberg, Just don't know how it would scale.  I can try to make it public19:15
morganfainbergayoung: no worries just wasn't sure about it19:15
morganfainbergHT_sergio: you can chat here. whats up?19:15
ayoungmorganfainberg, I am OK with anyone reading it, bu I only want people assigned to make changes.19:15
morganfainbergayoung: i only noticed it was private when i clicked on the link above ^^19:16
ayoungmorganfainberg, I just made it public.  According to the docs that means that only people added can make cahnges.  but anyone can read it19:16
morganfainbergcool19:16
*** gyee has joined #openstack-keystone19:16
*** ChanServ sets mode: +v gyee19:16
morganfainbergayoung: yeah much better19:17
HT_sergiomorganfainberg: I'm storing tokens in memcache. When I restart memcache the tokens are lost, but keystonemiddleware seems to be caching them internally which is causing nova/cinder/glance to fail pretty hard19:17
HT_sergio*I'm storing = keystone is storing19:17
ayoungHT_sergio, yep19:17
ayoungits a feature19:17
morganfainbergHT_sergio: there is an internal cache for validated tokens for middleware19:17
morganfainbergHT_sergio: you can disable that cache, use (similarly) a memcache back19:18
morganfainbergHT_sergio: (there was an or between those two statements)19:18
morganfainbergbut yes the endpoints to cache by default (300s) for a validated token19:18
HT_sergioit's the nova/cinder/glance service's token (not the user token) that's being cached. When keystone rejects it, keystonemiddleware isn't asking for another token, it's just failing19:18
morganfainbergHT_sergio: which version of openstack are you running?19:19
HT_sergiohow can this cache be disabled? I wasn't able to find such an option19:19
HT_sergioJuno19:19
morganfainbergHT_sergio: keystonemiddleware should be re-requesting tokens for the service user when it fails.19:19
HT_sergiorecently updated from Icehouse19:19
HT_sergioit doesn't seem to be re-requesting tokens. I've confirmed this in the keystone logs (I see it rejecting the same token over and over, and it's not the user's token)19:20
morganfainbergayoung: and this is yet another reason i greatly lookforward to fernet tokens being the default.19:20
morganfainbergHT_sergio: UUID tokens or PKI?19:20
HT_sergioUUID19:20
ayoungmorganfainberg, this is not going to be fixed by Fernet.  A cached expired token should act the same way19:21
ayoung" When keystone rejects it, keystonemiddleware isn't asking for another token"19:21
morganfainbergayoung: no this is memcache being restarted and dumping all active tokens19:21
ayoungNope19:21
ayoungthat should be a viable thing to do19:21
morganfainbergayoung: yes. not the user token.19:21
ayoungkeystone middleware needs to request a new token19:21
morganfainbergayoung: but the whole not-dumping everything on a service restart would make this less icky.19:22
ayoungI suspect it is the service token19:22
ayoungit would just hiodc the bug19:22
morganfainbergayoung: i'm looking at ksm now to see what is going on19:22
ayoungwe have it out in daylight.  SQUASH IT!19:22
HT_sergioayoung: you've seen this before ?19:22
ayoungHT_sergio, nah, but I can guess at what is going on19:23
HT_sergioit is the nova (for example) token that's being rejected19:23
ayoungright19:23
morganfainbergHT_sergio: haven't seen this actually occur since sometime around grizzly19:23
ayoungHe's runnning essex19:23
* ayoung ducks19:23
HT_sergiomorganfainberg: I didn't see this in Icehouse either19:23
morganfainbergayoung: hah19:23
HT_sergioonly since switching to juno19:23
morganfainbergHT_sergio: so nova gets the token the first time (on start) but doesn't refresh19:24
ayoungHT_sergio, In juno, that code lives in Keystoneclient still (I think)19:24
morganfainbergwhen you dump active keystone tokens by restarting memcache19:24
morganfainbergayoung: nope, juno moved to ksm package19:24
ayoungmorganfainberg, wasn't it just a link over...ah it was the other way19:24
ayoungKSC to KSM19:24
HT_sergioit's Keystone checking the tokens. I can see the rejection in KS's log19:25
morganfainbergayoung: never linked either, circular deps19:25
morganfainbergayoung: due to cms and subsequently session19:25
morganfainbergHT_sergio: in your nova past.ini you're referencing the keystonemiddleware package for auth_token not keystoneclient.middleware correct?19:25
* morganfainberg is just making sure we're chasing the right code.19:26
* HT_sergio checking19:26
HT_sergiomorganfainberg: [filter:authtoken] paste.filter_factory = keystonemiddleware.auth_token:filter_factory19:27
morganfainbergHT_sergio: great.19:27
morganfainbergHT_sergio: and which version of keystonemiddleware are you using (should be... 1.3 something? or 1.2 something?)19:28
*** jsavak has quit IRC19:28
*** jsavak has joined #openstack-keystone19:28
morganfainbergassuming ubuntu dpkg can tell you, on RDO you can search for the rpm.19:28
HT_sergiohmm, it's 1.0.019:28
morganfainbergok19:28
HT_sergiopython-keystonemiddleware           1.0.0-1~cloud019:28
morganfainbergcool that's fine19:29
openstackgerritFernando Diaz proposed openstack/python-keystoneclient: WIP - Add openid connect client support  https://review.openstack.org/13470019:29
rodrigodsmorganfainberg, ping... need to ask you about the possibility of backporting some patches19:29
*** mrutkows has quit IRC19:30
morganfainbergrodrigods: sure. also bknudson and dolphm are good for stable questions as well.19:30
rodrigodsmorganfainberg, yep... bknudson is already ok with them19:30
*** timcline has quit IRC19:30
rodrigodsmorganfainberg, https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:stable/kilo+topic:bug/1442787,n,z19:30
HT_sergiomorganfainberg: I'll msg you later about my issue. I still don't know how I can fix it19:31
*** timcline has joined #openstack-keystone19:31
*** mattfarina has joined #openstack-keystone19:31
morganfainbergHT_sergio: i'm looking right now at it :)19:31
HT_sergiooh ok thanks  :)19:31
morganfainbergtying to see if there is a fix that was applied between 1.0.0 and sometime later19:31
morganfainbergi remember something like this happening at one point19:31
morganfainbergHT_sergio: in the log do you see: 'Keystone rejected admin token, resetting'19:32
morganfainbergHT_sergio: (this would be in nova log it looks like)19:33
HT_sergiono19:33
HT_sergiolet me paste the log from KS19:33
HT_sergioRBAC: Invalid token19:34
*** mattfarina has quit IRC19:34
HT_sergioI added a bit more, so it says why the token was rejected:19:34
HT_sergioRBAC: Invalid token (Could not find token: 871a9a6c11e24b6e896a30a28d69dd24)19:34
morganfainbergHT_sergio: right, on the nova side you should (provided you have logging turned up to WARN for auth_token) see 'Keystone rejected admin token, resetting'19:35
HT_sergioWARNING keystonemiddleware.auth_token [-] Authorization failed for token19:35
morganfainbergHT_sergio: which is the log line we emit when the admin / service token for the nova user (what we use to validate) is rejected.19:35
HT_sergiomorganfainberg: it doesn't say admin token19:36
HT_sergiomorganfainberg: was that always the log statement, even way back in 1.0.0 ?19:36
morganfainbergHT_sergio: yeah i'm looking at the 1.0.0 code in git right now19:36
morganfainberghttps://github.com/openstack/keystonemiddleware/blob/1.0.0/keystonemiddleware/auth_token.py#L1120-L113219:37
morganfainbergoooh i wonder.19:37
morganfainbergayoung, dstanek, dolphm: did Juno have that fun bug where X-AUTH-TOKEN and X-SUBJECT-TOKEN returned the same bad status response?19:37
morganfainbergor was that icehouse?19:37
ayoungmorganfainberg, look in the bug tracker, I forget19:38
morganfainbergayoung: i'm going to go look at some commits in github first. searching LP is a nightmare.19:38
morganfainbergayoung: i think that was icehouse19:40
*** csoukup has joined #openstack-keystone19:40
*** timcline has quit IRC19:42
*** timcline has joined #openstack-keystone19:42
morganfainbergHT_sergio: So this looks like to me that the user's token is being rejected [based on the logs] not the "nova" token.19:43
morganfainbergHT_sergio: just from what you've shown and what i can see in the code19:43
morganfainbergHT_sergio: so let me ask one more question19:43
morganfainbergHT_sergio: and i'll keep looking19:44
HT_sergiomorganfainberg: I thought this too at first. But I'm seeing that nova rejects *all* tokens after restarting memcache. Here's what I did:19:44
morganfainbergHT_sergio: ok let me see what your steps are and i'll poke at this a bit more19:44
HT_sergio`nova --debug list` works. I see the token used in the debug output. Restart memcached and try the command again. I see the new token in the debug log, but keystone rejects it. In the keystone log I see it rejecting a different token (not the one from CLI debug output)19:45
HT_sergio** I see the new token in the debug output19:45
HT_sergiobecause each CLI command uses a new token19:45
HT_sergioeach time I try `nova --debug list` I see it using a different token, but I see the keystone logs rejecting the same token over and over19:46
HT_sergioI can repeat these steps now and pastebin the output if you want19:47
morganfainberghm. what status is keystone returning on the rejected token(s)?19:48
morganfainberg404 or 401?19:48
HT_sergiolet me put into debug and find out19:49
morganfainbergsounds good19:49
gabriel-bezerraayoung: no worries. (about the assigning tasks on trello issue)19:49
HT_sergiomorganfainberg: yup it is indeed 40119:50
HT_sergiothe CLI command output was saying 401 as well19:51
*** Aless has joined #openstack-keystone19:51
morganfainbergthe CLI to nova part i expected that19:51
HT_sergiothere's 1 more funny thing that might shed some light on this19:51
*** timcline has quit IRC19:51
morganfainbergif keystone is sending a 401 back to nova (auth_token middleware) and we're not getting a new token some logic is being weeeeeeiiirrrrddd19:51
morganfainbergsince the code looks to be doing 100% the right thing19:52
AlessHello There I'm curious, is the Domain Approach feasible to divide Admin/Service Users from the "Regular" LDAP Users?19:52
*** timcline has joined #openstack-keystone19:52
HT_sergiomorganfainberg: it should be following the code path from the link you sent me19:52
AlessOr would i rather use something like a hybrid backend for that?19:52
HT_sergiomorganfainberg: I'll see if I can confirm that19:52
morganfainbergHT_sergio: please do. I don19:52
morganfainbergt see where the bug is directly, and I clearly haven't experienced it myself.19:53
HT_sergiomorganfainberg: The Nova should use keystonemiddleware too, right ?19:55
morganfainbergok so nova uses keystonemiddleware19:55
morganfainbergHT_sergio: keystone uses a special bit of middleware because keystonemiddleware doesn't work inside keystone19:55
morganfainbergit needs to make http requests to keystone..19:55
*** gokrokve has quit IRC19:55
morganfainbergseparate code paths19:55
morganfainbergHT_sergio: so it is [NOVA (keystonemiddleware)] ------> [Keystone (keystone's special token validation middleware: keystone.middleware.AuthContextMiddleware)]19:56
morganfainbergwhat runs inside keystone has the ability to directly query/validate with the internals of keystone. what runs in nova uses the REST calls to validate19:57
morganfainbergooh19:58
morganfainbergHT_sergio: so. really really really dumb question19:58
morganfainbergHT_sergio: when everything is broken like this19:58
HT_sergiomorganfainberg: yes keystone CLI commands still work. Is that the question ?19:58
morganfainbergah nope that wasn't the question, but it answered my question19:58
morganfainbergHT_sergio: darn.19:59
morganfainbergHT_sergio: this is a weird one.19:59
HT_sergiomorganfainberg: Right. So i expected the nova CLI stack trace to include middleware. It doesn't: http://paste.openstack.org/show/240571/19:59
morganfainbergHT_sergio: you'd need to look at nova's logs not what the client outputs19:59
HT_sergiook, nvm that then :)20:00
*** mestery_ has joined #openstack-keystone20:00
morganfainbergHT_sergio: i havr a call i need to hop on.20:00
HT_sergiomorganfainberg: Ok thanks for everything so far!20:00
morganfainbergHT_sergio: i'll standup a devstack with juno once i'm done and see what happens20:00
morganfainbergHT_sergio: i know where to look and the rough duplication steps. i'll be back in ~60-90mins.20:00
*** Rockyg has joined #openstack-keystone20:01
*** mestery has quit IRC20:03
*** g2` has quit IRC20:09
gabriel-bezerraAless: what do you mean by Domain Approach?20:19
Alessgabriel-bezerra: https://wiki.openstack.org/wiki/Domains20:20
gabriel-bezerraAless: a feasible way to do it is to have your regular users in a domain backed by a domain-specific ldap. Then you admin/service users can be in the default (or other) domain.20:20
gabriel-bezerras/Then you/Then your/20:20
Alessgabriel-bezerra: Does this have any limits on how the service in the default domains are not able to "do" stuff in the regular users domain?20:22
Alessgabriel-bezerra: What I miss is some sort of list of implications.20:22
gabriel-bezerraAless: I don't think the services will be limited with the default policy-file samples.20:24
gabriel-bezerraayoung: ^20:25
gabriel-bezerrasamueldmq rodrigods ^20:25
Alessgabriel-bezerra: OK, so is this something that others are doing as well? I want follow the happy path as close as possible. :-)20:25
ayoungyes Aless many have trod this happy path20:26
AlessOK great, thanks guys!20:26
gabriel-bezerrayou're welcome20:27
AlessSo, am I assuming right that this is sort of the answer to all this hybrid approach requests?20:31
Alesshttps://github.com/SUSE-Cloud/keystone-hybrid-backend/tree/devel and the likes20:32
gabriel-bezerraAless: this is AN answer that seems to be an easy way to do it. You can kind of reach the same goal with federation, for instance, but it will be a lot more complex if you don't already have a SAML Identity Provider.20:37
*** tobe has joined #openstack-keystone20:42
*** stevemar has quit IRC20:43
ayoungdstanek, our unit tests take way too long.20:45
dstanekayoung: haha, yes they do20:45
Alessgabriel-bezerra: another alternative would be the use of REMOTE_USER header and have the frontend to use multiple backends - but i'm not sure whether this is being broadly used, based on online-readings20:45
ayoungdstanek, I remember when running them was not counterproductive.  How do we get back to that state?20:45
*** dsirrine has joined #openstack-keystone20:45
dstanekthey are much faster now than what they were when i started working on keystone - we need to trim all of the shared setup as a first step20:46
*** tobe has quit IRC20:46
gabriel-bezerraAless: I've never tried to do it in such way. I don't know about its adoption in production.20:50
Alessgabriel-bezerra: Alright I will start off with seperate Domains, thanks for the quick support again.21:04
*** Aless has quit IRC21:04
*** alanf-mc_ has joined #openstack-keystone21:05
HT_sergioAless: if you have questions about the hybrid driver, feel free to ask me21:05
*** jsavak has quit IRC21:06
morganfainbergHT_sergio: I'm back and standing up a devstack so I can do some direct reproduction of your case with Juno21:07
HT_sergiomorganfainberg: cool thanks !21:08
*** alanf-mc has quit IRC21:08
HT_sergioI've done a bit more poking around in the mean time21:08
morganfainbergHT_sergio: I will be using the raw git checkouts vs. a distribution since i can roll commits forwards and backwards as needed21:08
morganfainbergHT_sergio: i might need to snag a copy of your auth_token section from nova config (omitting passwords of course), if this isn't straightforward to duplicate21:09
HT_sergiomorganfainberg: ok21:09
morganfainbergHT_sergio: i need to grab lunch soon and more coffee, but I'll do that once I kick off the actual devstack install21:09
morganfainbergHT_sergio: you using 12.04? 14.04? some suse distro? Fedora?21:10
HT_sergiomorganfainberg: a little more info: the log msg 'Keystone rejected admin token, resetting' was not being printed for some reason, but it is going down that code path !21:10
HT_sergio14.0421:10
morganfainbergok great21:10
morganfainbergHT_sergio: just making sure i'm setting up similar environments21:10
*** alanf-mc_ has quit IRC21:10
HT_sergioit looks like keystonemiddleware is somehow logging at WARN level, but the rest of the log is at INFO21:10
morganfainbergHT_sergio: hopefully it's something trivial to fix (though i know how frustrating it gets)21:10
HT_sergioI hope so too.21:11
*** samueldmq has quit IRC21:11
HT_sergioideally it's just something silly I've done wrong :)21:11
morganfainbergHT_sergio: auth_token is by design meant to log a bit higher for certain cases.21:11
morganfainbergHT_sergio: but we need to downgrade some of those messages a bit too imo21:11
morganfainbergtoo verbose in some ways21:11
*** mestery_ is now known as mestery21:12
*** alanf-mc has joined #openstack-keystone21:12
* morganfainberg sees a mestery and suddenly doesn't remember the important network-y question he had.21:12
mesterymorganfainberg: lol21:12
mestery:)21:13
morganfainbergmestery: so... $network_question? what do you think?21:13
morganfainbergmestery :P21:13
mesteryrofl21:13
* mestery hand waves, muttering SDN21:13
*** lsmola_ has quit IRC21:13
morganfainbergmestery: just the kind of response I'd expect!21:14
mesterylol21:14
* morganfainberg handwaves and mutters identity, and access... SDNy things phaw21:14
morganfainbergok. that was silly21:15
HT_sergiomorganfainberg: On this line: https://github.com/openstack/keystonemiddleware/blob/1.0.0/keystonemiddleware/auth_token.py#L112221:18
HT_sergioI printed self.admin_token before and after. I found that it wasn't defined before !21:18
HT_sergiothat seems wrong to me ?21:18
morganfainbergthats a bit odd.21:19
*** alanf-mc_ has joined #openstack-keystone21:20
morganfainberglet me finish up the setup here21:20
morganfainbergand i'll poke around a bit and see if i can duplicate the issue21:20
HT_sergioah I think I found the issue!21:20
morganfainberg?21:20
HT_sergiothere's self.admin_token and self._admin_token21:20
HT_sergiolet me confirm this is the problem21:20
*** alanf-mc has quit IRC21:20
morganfainberghmmmm.21:22
morganfainberginteresting21:22
morganfainbergyep21:22
HT_sergiorenaming it to self._admin_token seems to have fixed it21:22
morganfainberglooks like we missed the _ on line: https://github.com/openstack/keystonemiddleware/blob/1.0.0/keystonemiddleware/auth_token.py#L112221:22
HT_sergioWOOHOO!21:23
HT_sergioI think this is my first major bugfix in an openstack project :D21:23
morganfainbergHT_sergio: can you file a bug for me on launchpad against this? let me check the more modern versions as well.21:23
morganfainberghopefully this is not too widespread21:23
HT_sergiomorganfainberg: yes please do. I'll make the bug21:23
morganfainbergah21:24
morganfainbergso21:24
boris-42morganfainberg: hey there21:24
boris-42morganfainberg: I will update rally jobs during this week21:24
morganfainbergboris-42: thanks21:24
boris-42morganfainberg: I didn't forgot=) just too many things to do21:24
morganfainbergHT_sergio: this might already be fixed21:24
morganfainbergboris-42: yes i know. post summit :)21:25
boris-42forget*21:25
boris-42morganfainberg: crazy period of life each time=)21:25
mfischits getting all fernetty in my dev environment!21:25
morganfainbergHT_sergio: the stable/juno branch is a good deal further forward than the 1.0.0 release21:25
morganfainbergHT_sergio: can I have you try duplicating this with the code from https://github.com/openstack/keystonemiddleware/tree/stable/juno21:26
HT_sergiosure21:26
HT_sergioit'll take me a few minutes21:27
morganfainbergHT_sergio: it might already be fixed and the cloud archive you're installing from just doesn't have the updated code.21:27
morganfainbergit even looks like this might be fixed in 1.1.021:28
morganfainbergHT_sergio: (i like fixes I can point people at when they're already done)21:28
morganfainbergmfisch: just wait until you also have a flask for all the fernet21:29
morganfainbergmfisch: /me stops making bad jokes.21:29
morganfainberg(thats a lie, i wont stop making bad jokes)21:29
mfischjust rolled it to my hwdev21:29
mfischokay so far21:29
*** samueldmq has joined #openstack-keystone21:30
mfischmorganfainberg: do I need to bounce the openstack services?21:31
HT_sergiomorganfainberg: it does look like 1.1.0 has the fix21:31
HT_sergioshould I even bother testing latest ?21:31
openstackgerritayoung proposed openstack/keystone: IAM Models  https://review.openstack.org/18465121:31
morganfainbergHT_sergio: the stable/juno branch is officially the supported branch for juno releases21:31
morganfainbergHT_sergio: you don't need to test it, but you might want to use it (for security backports etc)21:32
mfischwow, services do NOT like us swithcing token providers! reboot all the things!21:33
morganfainbergmfisch: the services should just fail with their service token and have to re-request21:34
*** pece has quit IRC21:34
morganfainbergmfisch: *should*21:34
mfischI had to bounce them21:35
mfischI waited 3-4 mins21:35
morganfainberghm.21:35
HT_sergiomfisch: maybe you ran into exactly the problem I'm here about ?21:35
morganfainbergi'll need to poke at that, it should be easier.21:35
HT_sergiowhich, for me, boiled down to: I'm using keystonemiddleware v1.0.021:36
mfischwe're all up21:36
mfischrebooted all services21:36
mfischthey dont like the switchover21:36
mfischmorganfainberg: how long should we have waited?21:37
morganfainbergmfisch: we should explore that as an option. it should be perfectly fine to swap the token provider and not need to restart everything21:37
ayoungmorganfainberg, ^^ is the patch formerly known as access_info21:37
morganfainbergmfisch: it should have been "on the next request that hits auth_token middleware"21:38
morganfainbergmfisch: no specific timeframe.21:38
morganfainbergmfisch: but immediate.21:38
mfischwe were up to 25 icinga criticals before I bounced services21:38
morganfainbergmfisch: juno services?21:39
mfischyes21:39
morganfainbergkilo keystone?21:39
mfischyes21:39
morganfainbergand which version of middleware?21:39
mfischwe can repro this again tomorrow in my other environment21:39
mfischlooking21:39
morganfainbergyou really might have just hit that same bug as HT_sergio21:39
morganfainbergif you are running 1.0.021:40
morganfainbergit's borked21:40
mfischkeystonemiddleware (1.0.0)21:40
mfischboom21:40
*** ducttape_ has joined #openstack-keystone21:40
morganfainbergmove to the stable/juno branch (whatever the last tag there is)21:40
mfischwelcome eric21:40
morganfainbergi think that is a 1.3.x but not 100% sure21:40
mfischmorganfainberg: we're doing a K upgrade soon, should we just wait?21:40
morganfainbergmfisch: well, this is an issue you probably want to move to at least 1.1.021:41
morganfainbergto prevent things being just broken for a real juno deploy21:41
mfischmorganfainberg: is it an issue even after the restart you mean?21:41
morganfainbergmfisch: it will continue to be an issue as tokens for the service users expire21:41
*** gordc has quit IRC21:41
*** kfox1111 has joined #openstack-keystone21:41
kfox1111can an unscoped token access the catalog?21:42
morganfainbergsince ATM doesn't know that the token needs to be refreshed. a bug in the logic21:42
ducttape_restarting the svc should kick in new tokens though21:42
morganfainbergkfox1111: I think so, but the catalog looks really odd.21:42
mfischso when these current tokens expire, everything breaks again?21:42
morganfainbergkfox1111: because things don't substitute correctly21:42
kfox1111know where it shows up in the python-keystone v3 client object?21:42
mfischthat doesnt seem righth21:42
morganfainbergmfisch: well no, not when expires21:42
kfox1111ah. that makes sense.21:42
morganfainbergmfisch: if a token is ever beyond expired/otherwise invalid21:43
morganfainbergit can refresh near expiry21:43
mfischit only refreshes on expiry, got it21:43
morganfainbergit *cant* handle a invalidated token21:43
kfox1111I don't think barbican puts the project in the url, so that would probably be ok.21:43
mfischgot it!21:43
mfischmorganfainberg: so technically we're okay for now with 1.0.0 if we restart21:43
morganfainbergmfisch: yeah21:43
morganfainbergbut i'd still upgrade to 1.1.0 if you're looking at any real lag out towards a full k upgrade21:43
mfischok21:43
morganfainbergat least 1.1.021:43
mfischthanks!21:43
morganfainbergHT_sergio: thanks for all the help on this today!21:44
morganfainbergkfox1111: yeah that should be fine21:44
ducttape_it's mo' betta' - much faster with this stuff21:44
mfischglance is still unhappy with us21:44
HT_sergiomorganfainberg: thank you man!21:44
morganfainbergmfisch: figures.. poor glance, no love21:44
ducttape_fernet should be the keystone / devstack default (my $.02)21:45
HT_sergioyou're now on my list of people to buy beer for at the next summit :)21:45
morganfainbergducttape_: it will be this cycle21:45
mfisch+100021:45
morganfainbergducttape_: there is some work that needs to happen first. but it's on my short list21:45
kfox1111hm... so this doesn't work unscoped: [i.to_dict() for i in ic.endpoints.list()]21:45
morganfainberglike... making devstack able to deploy fernet at all21:45
kfox1111is there another part of the client I should be using?21:45
morganfainbergkfox1111: oh via client? i don't think it will work via client21:46
kfox1111ic being a v3 Client.21:46
morganfainbergkfox1111: sorry i thought pure API call21:46
morganfainbergkfox1111: pure api, it probably works.21:46
morganfainbergkfox1111: but it's a bit wonky in client :(21:46
kfox1111I'm guessing I'm not looking in the right place, cause its: Forbidden: You are not authorized to perform the requested action: identity:list_endpoints (HTTP 403)21:46
*** ducttape_ has left #openstack-keystone21:46
morganfainbergkfox1111: /auth/catalogh21:47
morganfainberg v3/auth/catalog21:47
kfox1111k. thanks.21:47
morganfainbergbut it might get really weird21:47
morganfainbergor might just be very confusing21:47
kfox1111thats ok. I'm usually in that state. ;)21:47
morganfainbergwe have not included a catalog in unscoped tokens historically so this is pushing the limits of what we've tested.21:47
morganfainbergayoung does [iirc] want to put a catalog in unscoped (or jamielennox did) - not opposed to it but it changes the responses somewhat21:48
morganfainbergand we need to be careful about that21:48
kfox1111fair enough. I'm just prototyping something at the moment for the nova instance -> barbican workflow.21:49
kfox1111Just trying to figure out if it will fly at all.21:49
kfox1111Its close to being doable I think.21:49
kfox1111if it will work, I'll write up a spec and pass it around.21:49
kfox1111morganfainberg: The v3/auth/catalog is the url path?21:50
kfox1111I'm still trying to find bits in the python client.21:50
morganfainbergkfox1111: should be.21:51
kfox1111I'm in the nova code at the moment, so don't want to talk to keystone directly.21:51
openstackgerritLance Bragstad proposed openstack/keystone: Don't fail on converting user ids to bytes  https://review.openstack.org/18612021:51
morganfainberglet me 2x check21:51
morganfainbergkfox1111: https://github.com/openstack/keystone/blob/master/keystone/auth/routers.py#L41-L4521:52
morganfainbergkfox1111: that is at least a kilo-ism21:52
morganfainbergchecking earlier21:52
kfox1111ah. the cloud I'm testing with is juno at the moment.21:52
morganfainbergkfox1111: https://github.com/openstack/keystone/blob/stable/juno/keystone/auth/routers.py#L45-L4921:53
*** nowen has quit IRC21:53
morganfainberglooks ok on juno checking code as well to see if it needs a scope21:53
morganfainbergit might21:53
morganfainbergkfox1111: doh! https://github.com/openstack/keystone/blob/stable/juno/keystone/auth/controllers.py#L611-L61521:54
morganfainbergkfox1111: yep you need a scope21:54
morganfainbergkfox1111: sorry21:54
kfox1111yeah... hmm. ok.21:54
kfox1111and kilo too.21:54
*** mattfarina has joined #openstack-keystone21:55
kfox1111there is no catalog included with the token on authentication?21:55
kfox1111yeah, the check is in trunk too.21:56
morganfainbergkfox1111: we should have a catalog for non-scoped things21:57
kfox1111can you take a scoped token and switch projects?21:57
morganfainbergbut most services can't work with no-scope21:57
morganfainbergkfox1111: yep you can21:57
kfox1111ok, so I can probably just make a dummy project for things so they are scoped to something and the catalog works.21:57
morganfainbergkfox1111: long term we don't want you to do that, we want you to explicitly scope then if you need a new scope you use the unscoped token again.21:58
morganfainbergtoday you can do scoped -> scoped21:58
morganfainbergbut for security reasons this is not optimal21:58
morganfainbergthe unscoped token should be like a session - and only used between client and keystone21:58
kfox1111(I know of one individual using a scoped token to get a new scoped token on the same project to refresh the token btw)21:58
morganfainbergkfox1111: unless they've changed the keystone code, the expiry is maintained from the original token21:59
morganfainbergso it doesn't actually refresh the token :P21:59
morganfainbergthere is at least one big deployer that allows for re-issue+extend expiry of a token21:59
kfox1111hmm... I'll double check with him. maybe he's just using it to validate the token is valid.21:59
kfox1111I can't quite remember now.21:59
kfox1111whichever the case, I told him its a bad idea. :)21:59
morganfainbergkfox1111: could also just do a HEAD for the token validate to see ifit's valid21:59
kfox1111yeah. that sounds better.22:00
morganfainbergkfox1111: i actually want to eventually support an IMS check22:00
morganfainbergfor lots of things in keystone22:00
kfox1111ok. so long term, keystone would like the unscoped+service catalog for this case.22:00
morganfainbergkfox1111: yes. i would like to have at least a usable (maybe just pointing at keystone, otherthings to add later) service catalog in unscoped22:00
kfox1111I'm working on prototyping the nova instance keystone user thingy we talked about at the summit.22:01
morganfainbergah nice22:01
kfox1111maybe a flag in the catalog saying the service works unscoped.22:01
morganfainbergsure.22:01
kfox1111I've got the vm asking nova metadata service for a token, and getting one back now.22:01
kfox1111and nova creating a user named <instances-uuiud> in the nova domain.22:02
*** gokrokve has joined #openstack-keystone22:02
morganfainberglots of options on how to handle all of this22:02
kfox1111I was hoping to pass back the catalog too, and then the vm could look at the catalog/token and contact barbican directly.22:02
kfox1111With its authorization stuff, I think it would work with an unscoped token,22:02
kfox1111so the vm wouldn't have to get a scoped one from keystone.22:03
morganfainbergwell... nova *always* requires a scope to work22:03
morganfainbergafaik22:03
morganfainbergotherwise it doesn't know where things belong/who owns them22:03
kfox1111I'm thinking I pass back the token, the catalog, then the vm can find the barbican endpoint in the list, and contact it with the unscoped token. At that point in the proces, nova's out of the picture.22:04
bknudsonan unscoped token doesn't have any roles so the user won't have any auth.22:06
*** bknudson has quit IRC22:06
kfox1111I think for barbican, since they are validating the token is valid, but since they are doing acl's themselves, thats probably ok.22:07
kfox1111I need to install barbican on this system and try that part of it. but I'm stuck at the previous step, trying to have the vm figure out where barbican is.22:08
kfox1111so, should I put in a blueprint for having the catalog work with unscoped tokens then?22:09
*** lhcheng_ has quit IRC22:11
*** Rockyg has quit IRC22:11
kfox1111and would I need to file one for both keystone and python-keystoneclient?22:12
*** timcline has quit IRC22:14
morganfainbergkfox1111: i think we have a spec/bp for that22:15
morganfainbergkfox1111: check with ayoung and jamielennox on where we are on that22:15
kfox1111ok. cool. thanks. :)22:16
morganfainbergkfox1111: but keep in mind, scope is important if you want anything more than authn22:16
morganfainbergbecause unscoped token is effectively just AuthN22:16
morganfainbergno authZ implied22:16
kfox1111agreed. I'm going to leave that up to the vm to go from unscoped to whichever scope they want.22:16
kfox1111well, let me ask you this...22:17
kfox1111policy is very open at the moment.22:17
kfox1111I could add the project the vm's being launched under into the vm's user, but it would be able to do a lot of bad things, like delete itself, or delete every other vm in the project.22:17
kfox1111So I'm thinking, if I leave it unscoped, and not assign a project to it at all, it will probably work for the barbican case as is,22:18
kfox1111and for more complicated things, the user (or heat) can add projects to the user themselves.22:18
*** dguerri is now known as dguerri`away22:18
morganfainbergkfox1111: so the issue is how do you know how to audit that data if there is no project?22:19
kfox1111in barbican, they just associate the secrets with users directly in their acl's, I think.22:20
morganfainbergusers can have access to many projects/tenants all with different groups that care if the resources are used and how22:20
kfox1111hmm....22:20
morganfainberghow many secrets are allocated? how much space can be used.22:20
morganfainbergoften a specific user doesn't have a creditcard associated [strawman here]22:20
morganfainbergbut the project or domain would22:20
morganfainbergit's the "encompassing account" vs "that specific user"22:20
kfox1111yeah, so you almost need trusts again, but that was considered too heavy weight.22:21
morganfainbergthis is even more of an issue when you start getting into federated identity w/ ephemeral users22:21
jamielennoxmorganfainberg: want to +a https://review.openstack.org/#/c/171448 - there's 2 +2s and we can get this underway22:21
morganfainberg(users that don't linger in keystone)22:21
morganfainbergjamielennox: looking22:21
morganfainbergjamielennox: +a22:21
morganfainbergkfox1111: just keep all of that in mind.22:22
kfox1111I was pushing for acl's to live in keystone, since it can more easily deal with some of these issues, but someone, I don't remember who, was pushing back and recomending each project manage the acl's themselves.22:22
morganfainbergkfox1111: we can consider ACL support in keystone - but that starts looking a lot like dynamic policy, or keystone having to be asked for everything an *extra* time not just at token validation22:23
morganfainbergkfox1111: it's a delicate line to walk - how far does keystone reach into the other projects22:23
kfox1111trueish, but I think you can avoid it somewhat the same way keystone middleware did. its under the keystone umbrella, but pushed to the services.22:23
morganfainbergkfox1111: you should see if the dynamic policy stuff ayoung is striving for could be used.22:24
kfox1111the acl's show up in the token, or something like that, and the policy engine help enforce.22:24
morganfainbergkfox1111: exactly. poke at ayoung some.22:24
kfox1111ok. will do. :)22:24
openstackgerritJamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core  https://review.openstack.org/17191622:24
morganfainbergkfox1111: i am not opposed to making keystone better at the "AM" part of IAM22:24
kfox1111cool. :)22:25
morganfainbergkfox1111: I want to be very careful to not be a bottleneck or worse try and do everything for everyone.22:25
kfox1111so, with the plan so far, doing unscoped tokens, fixing the catalog, that would work for the barbican case, and maybe the dynamic policy stuff or trusts or scoping the unscoped token, would work for other services.22:26
morganfainbergkfox1111: sounds like a good place to start looking at things.22:26
kfox1111agreed. with my op hat on, I don't want to deploy it if it wont scale. :)22:26
kfox1111ok. I'll prototype this a bit further to make sure I can get it to work end to end and there are no other gotcha's, then submit some specs.22:27
kfox1111Thanks for the help. :)22:27
kfox1111hmm... is there any push to get v3 rc files into horizon?22:28
kfox1111remembering all the things to tweak to get a v2 to v3 hurts. :/22:28
*** HT_sergio has quit IRC22:29
*** tobe has joined #openstack-keystone22:30
david-lylekfox1111:  v3 rc files?22:31
*** jaosorior has quit IRC22:32
kfox1111if you go to horizon, -> access & security -> api access, -> "Download OpenStack RC File", you get a file that has env vars for keystone v2.22:33
jamielennoxhas anyone ever seen a CONF.project attribute? https://review.openstack.org/#/c/180769/922:33
jamielennoxi pulled it up in a previous review because i don't know how widespread this is22:34
david-lylekfox1111: we could easily support a v3 version in Horizon22:34
morganfainbergjamielennox: that is a good question22:34
morganfainbergdavid-lyle: can we please support a v3 version in horizon? ;)22:35
jamielennoxi'm wondering if it's one of those things nova doesn't realize they're the only one22:35
david-lylekfox1111: is it safe to assume if you're using v3 in horizon, you're using v3 throughout22:35
kfox1111that would be awesome. I'm worried when we go to pure v3, the users experience would be.... bad currently. :/22:35
*** tobe has quit IRC22:35
kfox1111with juno, some of the clients were broken with v3 creds.22:35
kfox1111neutron specifically. not sure about any of the others.22:36
kfox1111I heard they fixed that in kilo, so maybe pure v3 might be ok now.22:36
kfox1111we really REALLY would like to switch to v3 for everything on our cloud, since our users are ldap authenticated, and would like to have our service accounts in sql.22:36
david-lylekfox1111: that's my only worry22:37
kfox1111but in juno, some of the openstack components wouldn't work with v3 or without the service accounts being outside of the default domain. :/22:37
david-lylebut I'll work on a patch22:37
morganfainbergkfox1111: heat has some issues with pure v3 in some odd ways22:37
morganfainbergkfox1111: but it shouldn't stop your users from only using v322:38
kfox1111I'd say, for now, if its easy to add a v3 instead of just replacing the v2, that might be good. or alternatly, make it so that both v2 and v3 are in the same config, and has a flag to switch between them safely.22:38
morganfainbergkfox1111: i think there are 2 or three other minor issues22:38
morganfainbergkfox1111: but it should all be purely server-to-server not user facing at this point22:38
david-lylekfox1111: do you know what you're missing specifically in the rc file?22:38
*** vilobhmm has left #openstack-keystone22:38
kfox1111david-lyle: let me dig up an example...22:39
david-lyledomain_id or domain_name I would think22:39
kfox1111we're doing something like this:22:42
kfox1111http://pastebin.com/80cV3m6422:42
kfox1111but I'm not sure that's 100% complete.22:42
kfox1111I think I still have to specify --os-identity-api-version 3 on cli's sometimes.22:43
david-lyleok, ENV var name changes too22:43
david-lylemakes sense22:43
kfox1111we started adding the unsets so that when we swtich from v2 -> v3 and back, things don't break. :/22:43
kfox1111it gets pretty grumpy otherwise.22:44
*** csoukup has quit IRC22:44
david-lylemakes sense to me22:44
*** geoffarnold has joined #openstack-keystone22:44
*** timcline has joined #openstack-keystone22:44
openstackgerritIan Cordasco proposed openstack/keystoneauth: Replace datetime calculations with utility functions  https://review.openstack.org/18607622:48
*** timcline has quit IRC22:49
morganfainbergjamielennox: re: https://review.openstack.org/#/c/185806/22:49
morganfainbergI am inclined to say _utils should not be aliased as "utils" as suggested, but the @_utils... is really a wonky convention22:50
*** dsirrine has quit IRC22:50
jamielennoxmorganfainberg: i don't mind, i was just looking to make the file private22:50
morganfainbergjamielennox: we could quickly just do the alias fix as suggested and push it through22:50
morganfainbergjamielennox: happy to make that change for ya, i'd like to keep KSA momentum.22:51
* morganfainberg needs to rebase some changes onto your chain anyway22:51
*** afazekas has quit IRC22:51
jamielennoxthat's ok, i will22:51
morganfainbergok.22:51
jamielennoxmorganfainberg: did you catch dhellmann22:51
morganfainbergyes.22:51
morganfainbergi need to just drop him a sha and the branch name22:51
morganfainbergwas in meetings but that should get in line tomorrow22:51
kfox1111if you set the default project on user create, does it actually associate the user to the project too, or just registers a preference?22:52
*** geoffarnold has quit IRC22:53
*** csoukup has joined #openstack-keystone23:00
*** Rockyg has joined #openstack-keystone23:01
openstackgerritJamie Lennox proposed openstack/keystoneauth: Replace datetime calculations with utility functions  https://review.openstack.org/18607623:01
openstackgerritJamie Lennox proposed openstack/keystoneauth: Make utils file private  https://review.openstack.org/18580623:01
openstackgerritJamie Lennox proposed openstack/keystoneauth: Remove oslo.utils dependency  https://review.openstack.org/18580723:01
sigmavirus24jamielennox: thanks for rebasing the entire chain23:03
jamielennoxsigmavirus24: np23:04
*** gokrokve has quit IRC23:04
*** csoukup has quit IRC23:05
*** chlong has joined #openstack-keystone23:05
openstackgerritMerged openstack/keystone: Move endpoint policy into keystone core  https://review.openstack.org/17144823:07
openstackgerritJamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core  https://review.openstack.org/17191623:09
openstackgerritJamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core  https://review.openstack.org/17191623:09
morganfainbergjamielennox: once https://review.openstack.org/#/c/186220/ merges your new branch is ready23:19
jamielennoxmorganfainberg: nice! i was expecting it to be in another repo so was surprised when i went to review and had +223:20
*** tobe has joined #openstack-keystone23:31
morganfainbergjamielennox: feature branches when done right are way better than new repo things23:32
samueldmq2x * [(+2) + (workflow+1)] = 18622023:32
jamielennoxit appears that feature branch reviews don't show up in channel23:32
morganfainbergjamielennox: no they don't23:33
morganfainbergby design23:33
jamielennoxthat's probably ok23:33
morganfainbergwe'd need to add them to the project-config23:33
morganfainbergi'd rather not23:33
jamielennoxok, well i added https://review.openstack.org/#/c/186223/1 just to see if it all works23:35
*** tobe has quit IRC23:36
*** Ephur has quit IRC23:38
jamielennoxmorganfainberg:  we're going to have to turn off the requirements job for the feature branch23:38
*** dims_ has quit IRC23:38
*** dims_ has joined #openstack-keystone23:40
*** vilobhmm has joined #openstack-keystone23:41
vilobhmmjamielennox : ping23:43
jamielennoxvilobhmm: hello23:43
vilobhmmwhen a project/tenant is created how does the default quota get assigned to every project and how does the behaviour might change when we go to heirarchical projects ?23:43
vilobhmmi am working on implementing nested quota driver for cinder23:43
vilobhmmthe thing i want to achieve is parent/root project gets default quota as set in /etc/cinder/cinder.conf or https://github.com/openstack/cinder/blob/master/cinder/quota.py#L3723:44
vilobhmmwhereas when the child project is created the child should be assigned a default quota of zero for all resources23:45
vilobhmmjust to avoid the race23:45
*** timcline has joined #openstack-keystone23:46
morganfainbergvilobhmm: so quota owned by the project itself, e.g. nova, cinder etc23:46
vilobhmmok23:47
vilobhmmmakes sense23:47
morganfainbergvilobhmm: we don't actively provision anything (afaik) when things happen.23:47
morganfainberge.g. new project created23:47
morganfainbergwhen you boot an instance nova does some internal bootstrapping23:47
morganfainbergand the like. i believe you can pre-allocate for some things23:47
morganfainbergeven if nova hasn't seen the project yet (there was a spec to call out and validate such things existed)23:48
morganfainbergwe make an effort to not have keystone actively provision things like quota with other services.23:48
jamielennoxvilobhmm: what he said :)23:48
jamielennoxmorganfainberg: https://review.openstack.org/#/c/186228/23:48
vilobhmmmorganfainberg : thanks…what i want to do is intialize default quota values = 0 for child projects whereas for the root keep them to default values…like quota_volumes=10, etc23:49
vilobhmmjust to prevent for gettign into some race conditions23:49
morganfainbergvilobhmm: that makes sense. you will need to ensure the heirarchy is available. that should be related to the "does this exist" spec I saw a bit ago23:49
morganfainbergfor nova (asking keystone if something existed or not)23:50
vilobhmmok cool23:50
*** timcline has quit IRC23:50
*** lsmola has joined #openstack-keystone23:51
vilobhmmbut this module https://github.com/openstack/cinder/blob/master/cinder/quota.py#L37 will remain the same for parent and child and will govern the conf values so how do we distinguish what values to apply to a root and what for the child ? in the project's table we have fields like "parent_id" so in a heirarchical projects root will have parent_id=NULL where as for child projects it will be not NULL23:53
vilobhmmmorganfainberg, jamielennox : I don't think https://review.openstack.org/#/c/186228/ points to the right spec…23:55
jamielennoxvilobhmm: that's something else that we were discussing23:55
vilobhmmok …do you have the spec link handy by any chance..23:56
jamielennoxyou'll have to ask morganfainberg, i'm not sure which one he's referring to in nova23:59

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