Tuesday, 2018-07-10

*** gyee has quit IRC00:09
*** jmlowe has joined #openstack-keystone00:13
*** markguz has joined #openstack-keystone00:17
markguzanyone know what this error means when syncing config to db in pike :  InvalidDomainConfig: Invalid domain specific configuration: The value of group signing specified in the config should be a dictionary of options.00:17
markguzthis is the config I;m trying to sync to db: http://paste.openstack.org/show/725379/00:21
*** markguz has quit IRC00:40
kmalloclbragstad: looking now01:04
kmalloclbragstad: just got back from appt...01:04
*** masuberu has quit IRC01:09
kmalloclbragstad, wxy: sorry -1, we cannot hard-code role names. The answer is (any option works): 1) Prohibit Filtering on project_id; 2) check service-token only (mostly insufficient as anyone can provide a service token; 3) use callback and make your own cred/target dict that can confirm "project_id" filter is there (pass directly to the enforcer); 4) Wait for oslo_policy and new check types (Stein release); 5) Maybe01:18
kmallocdoable via backflips i can add in Flask-RBAC Enforcer.01:18
*** masber has joined #openstack-keystone01:29
adriantkmalloc: given the refactor work in progress for tokens, I'm tempted to push the auth receipt stuff to Stein until the refactor is done for tokens. Then I can sync up with what we end up with so the receipt and token patterns are the same.01:39
adriantNone of the other pieces for MFA with receipts would be ready until Stein anyway, so it's not a huge issue, and now that I have something that works with the API side mostly defined I can start the work in keystoneauth + elsewhere so it's ready once auth receipts is merged into master during Stein01:41
adriantlbragstad: that work for you? I've started working through all your token provider refactors, and once those are close to done can sync my stuff with them.01:43
adriantkmalloc: seems like the most sensible solution rather than me inventing a third pattern for auth receipts when it should really match tokens.01:44
*** andymccr has quit IRC01:57
*** andymccr has joined #openstack-keystone01:57
wxykmalloc: ++ for the policy enforcer way. I tried it in my first patch, but it doesn't work as I thought. So I really like your proposal during last weekly meeting. I want to wait for new oslo_policy, but without "project_id" filter, the "show_hierarchy" filter will be blocked as well (https://review.openstack.org/#/c/579331/8/keystone/limit/core.py@131). So I'd like choose 2) in R, and continue 4) in S.02:05
kmallocSounds good.02:06
kmallocThe only reason I could build the enforcer (custom) is because I've just been working heavily in the enforcer ;)02:07
kmallocI might make this doable with moving to flask.02:08
kmallocFYI, but need to land the bits before I move apis to flask.02:08
wxykmalloc: I'll dig into your flask-enforcer patches today.02:08
kmallocIt's mostly ready, just needs some extra +2s02:09
*** masuberu has joined #openstack-keystone02:12
*** jmlowe_ has joined #openstack-keystone02:13
*** spotz_ has joined #openstack-keystone02:14
*** tadams12083_ has joined #openstack-keystone02:16
*** chudly_ has joined #openstack-keystone02:16
*** cwright_ has joined #openstack-keystone02:17
*** rodrigod` has joined #openstack-keystone02:18
*** Neptu_ has joined #openstack-keystone02:19
*** rvba has quit IRC02:19
*** Neptu has quit IRC02:19
*** timss has quit IRC02:19
*** cloudnull has quit IRC02:19
*** masber has quit IRC02:19
*** jdennis has quit IRC02:19
*** vishakha has quit IRC02:19
*** cwright has quit IRC02:19
*** jdennis has joined #openstack-keystone02:19
*** spotz has quit IRC02:19
*** jmlowe has quit IRC02:19
*** chudly has quit IRC02:19
*** rodrigods has quit IRC02:19
*** tadams12083 has quit IRC02:19
*** kukacz_ has quit IRC02:19
*** vishakha has joined #openstack-keystone02:19
*** cloudnull has joined #openstack-keystone02:19
*** timss has joined #openstack-keystone02:19
*** timss has quit IRC02:20
*** jdennis has quit IRC02:20
*** rvba has joined #openstack-keystone02:20
*** timss has joined #openstack-keystone02:20
*** cloudnull is now known as Guest297402:21
*** rvba has quit IRC02:23
*** rvba has joined #openstack-keystone02:23
*** jdennis has joined #openstack-keystone02:25
*** kukacz_ has joined #openstack-keystone02:30
*** hoonetorg has quit IRC02:31
*** hoonetorg has joined #openstack-keystone02:47
*** sapd_ has joined #openstack-keystone03:04
*** sapd__ has quit IRC03:04
kmallocwxy: we might need a separate api for security reasons if the reason we limit project_id filter is security03:18
kmallocwxy: because anyone could provide a service token, it just wont be useful for other service-only things03:19
kmallocwxy: lets chat w/ lbragstad tomorrow and come to a good solution :)03:19
openstackgerritAdrian Turjak proposed openstack/keystone master: Implement auth receipts spec  https://review.openstack.org/57228603:24
wxykmalloc: then a new policy like "limit_limits_with_project_id: role: admin or service"?. I thought it's a little heave so I dropped this choice when coding. But I'm ok with it if we like it.03:25
adriantkmalloc, lbragstad: auth receipts marked as -1 workflow for now then, and I've added myself to all reviews for https://bugs.launchpad.net/keystone/+bug/1778945 so I can keep an eye on how they shape up, will at some stage start work on KeystoneAuth using the existing auth-receipts patch as the API interaction is unlikely to change.03:38
openstackLaunchpad bug 1778945 in OpenStack Identity (keystone) "Complexity in token provider APIs" [Medium,In progress] - Assigned to Lance Bragstad (lbragstad)03:38
openstackgerritwangxiyuan proposed openstack/keystone master: Strict two level limit model  https://review.openstack.org/55769603:39
openstackgerritwangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit  https://review.openstack.org/57933003:39
openstackgerritwangxiyuan proposed openstack/keystone master: Add show hierarchy filter  https://review.openstack.org/57933103:39
openstackgerritwangxiyuan proposed openstack/keystone master: Update project depth check  https://review.openstack.org/58025803:39
openstackgerritwangxiyuan proposed openstack/keystone master: Add project hierarchical tree check when Keystone start  https://review.openstack.org/58033103:39
openstackgerritwangxiyuan proposed openstack/keystone master: Filter project_id for list limits  https://review.openstack.org/58117703:39
kmallocadriant: ok03:39
kmallocwxy: yeah, let's chat tomorrow. But that might be the path forward, but I want to check a couple things.03:40
kmallocI have some ideas.03:40
wxykmalloc: cool03:40
*** masuberu has quit IRC03:43
lbragstadadriant: ok - that sounds fine04:08
lbragstadto be fair - the rest of that refactor shouldn't take too long04:08
lbragstadit's just a bit of testing concerns and that should be about it04:09
lbragstadwxy: did you say you were waiting for a new version of oslo.policy?04:25
*** jappleii__ has quit IRC04:25
*** threestrands has joined #openstack-keystone04:25
kmalloclbragstad: the "does element in Target dict" check I proposed n05:07
kmallocRight now we can't do that at all.05:08
kmallocit could be done with a callback or custom call to enforce05:12
kmallocit would be wonky/difficult05:13
kmallocflask work makes it easier, but not "easy"05:13
kmalloca "does element exist in target" would make a big difference05:13
*** sonuk has joined #openstack-keystone05:15
*** sonuk_ has quit IRC05:17
*** links has joined #openstack-keystone05:22
*** gagehugo has quit IRC05:33
*** martinus__ has joined #openstack-keystone05:54
*** ispp has joined #openstack-keystone06:29
*** threestrands has quit IRC06:30
openstackgerritVu Cong Tuan proposed openstack/python-keystoneclient master: Switch to stestr  https://review.openstack.org/58121306:35
*** links has quit IRC06:38
*** links has joined #openstack-keystone06:53
*** aloga has joined #openstack-keystone07:07
*** tesseract has joined #openstack-keystone07:13
*** peereb has joined #openstack-keystone07:19
openstackgerritVu Cong Tuan proposed openstack/pycadf master: Switch to stestr  https://review.openstack.org/58122807:23
openstackgerritwangxiyuan proposed openstack/keystone master: Strict two level limit model  https://review.openstack.org/55769607:32
openstackgerritwangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit  https://review.openstack.org/57933007:32
openstackgerritwangxiyuan proposed openstack/keystone master: Add show hierarchy filter  https://review.openstack.org/57933107:32
openstackgerritwangxiyuan proposed openstack/keystone master: Update project depth check  https://review.openstack.org/58025807:32
openstackgerritwangxiyuan proposed openstack/keystone master: Add project hierarchical tree check when Keystone start  https://review.openstack.org/58033107:32
wxylbragstad: yes if oslo.policy can check the request filter in policy way like kmalloc mentioned during last weekly meeting. But we can't just wait, we should find another solution in R.07:37
*** tosky has joined #openstack-keystone07:39
*** ispp has quit IRC07:43
*** links has quit IRC07:44
*** rcernin has quit IRC07:47
*** amoralej|off is now known as amoralej07:48
*** kimamisa has joined #openstack-keystone07:50
*** links has joined #openstack-keystone07:57
*** vishakha has quit IRC08:28
openstackgerritVu Cong Tuan proposed openstack/python-keystoneclient master: Switch to stestr  https://review.openstack.org/58121308:37
*** deepak_mourya has quit IRC09:26
*** itlinux has joined #openstack-keystone09:30
openstackgerritMerged openstack/keystone master: Implement enforcement model logic in Manager  https://review.openstack.org/56271509:34
*** gagehugo has joined #openstack-keystone09:38
*** rcernin has joined #openstack-keystone09:44
*** rcernin has quit IRC09:47
*** itlinux has quit IRC09:56
*** itlinux has joined #openstack-keystone10:04
*** sapd_ has quit IRC10:11
*** sapd has joined #openstack-keystone10:11
openstackgerritVu Cong Tuan proposed openstack/ldappool master: Switch to stestr  https://review.openstack.org/58130710:14
*** mvk_ has quit IRC10:22
*** mvk_ has joined #openstack-keystone10:48
*** itlinux has quit IRC11:21
openstackgerritVu Cong Tuan proposed openstack/keystone-specs master: Switch to stestr  https://review.openstack.org/58132611:23
*** edmondsw has joined #openstack-keystone11:25
openstackgerritVu Cong Tuan proposed openstack/keystone-specs master: Switch to stestr  https://review.openstack.org/58132611:36
*** ispp has joined #openstack-keystone11:48
*** amoralej is now known as amoralej|lunch11:55
*** markvoelker has quit IRC12:18
*** markvoelker has joined #openstack-keystone12:21
*** raildo has joined #openstack-keystone12:21
openstackgerritSami Makki proposed openstack/keystone master: Invalidate 'computed assignments' cache when creating or deleting project.  https://review.openstack.org/58134612:29
*** markvoelker has quit IRC12:31
*** markvoelker has joined #openstack-keystone12:35
*** amoralej|lunch is now known as amoralej12:49
*** ispp has quit IRC13:11
*** ispp has joined #openstack-keystone13:23
*** itlinux has joined #openstack-keystone13:44
*** wxy| has joined #openstack-keystone13:50
*** jdennis has quit IRC13:59
*** jdennis has joined #openstack-keystone13:59
*** viks_ has quit IRC14:00
*** dklyle has quit IRC14:01
*** dklyle has joined #openstack-keystone14:01
*** itlinux has quit IRC14:04
*** yikun has quit IRC14:06
*** felipemonteiro has joined #openstack-keystone14:09
*** felipemonteiro_ has joined #openstack-keystone14:11
*** ispp has quit IRC14:11
*** wxy|_ has joined #openstack-keystone14:12
*** spilla has joined #openstack-keystone14:13
*** wxy| has quit IRC14:14
*** felipemonteiro has quit IRC14:15
*** ispp has joined #openstack-keystone14:17
*** Guest2974 is now known as cloudnull14:19
*** spilla has quit IRC14:21
*** spilla has joined #openstack-keystone14:24
*** spotz_ is now known as spotz14:31
*** EmilienM is now known as EvilienM14:42
*** peereb has quit IRC14:45
*** ispp has quit IRC14:45
*** ispp has joined #openstack-keystone14:54
kmallocwxy: interesting.14:56
*** markguz has joined #openstack-keystone14:57
kmallocwxy: so i think the best plan is a service API that is locked to a better rule for filtering by project_id.14:57
kmallocwxy: rather than a list interface.14:57
kmallocwxy: that way we have a separate action that can be controlled.14:57
kmallocwxy: i slept on the whole design and the "change behavior based upon filter" seems weird.14:57
kmalloclbragstad: ^ cc14:58
kmallocif we isolate that API to a separate URL, we have a lot more control over it. and we can do explicit checks.14:58
kmallocwxy: even if we could "check if filter is present" in this case, i'd advocate for a separate API, as it's a different concern/result/set of business logic to be run (different use-case)14:59
lbragstadi think i agree15:01
lbragstadlooking at this while context switching though15:01
kmalloci just wanted to drop that in before meeting today15:04
wxy|_kmalloc: lbragstad: so maybe a url like projects/{project_id}/limits to fetch the specified project limits?15:24
lbragstadas in the hierarchy?15:25
*** links has quit IRC15:26
kmallocwxy|_: that would work, we could also put it under the /limits/ URL prefix somehow.15:26
kmallocbut not sure how to adhere to the "rest-ish" style15:26
kmalloci would prefer to keep it in /limits, but seeing as i don't have a good way to do that.15:27
kmallocshort of /limits/by-project-id/{projet_id}15:27
kmallocand i don't like that.15:27
lbragstadwould you want to denote the project with the token scope?15:27
kmallocthis is the service user getting limits for a project15:28
kmallocthough... i guess we could use x-subject-token here?15:28
kmallocas an alternative15:28
kmallocget it by x-auth-token, or x-subject-token15:28
kmallocbut that runs afoul of the same issues with security15:28
kmallochard to limit (new check_str), but x-subject-token we could at least check for today.15:29
kmallocoh.. wait. no we can't...15:29
lbragstadso - if you're an admin on a project15:29
lbragstadlet's say you have project A, B, and C15:30
lbragstadand they are in a linear relationship15:30
lbragstad(ignore the two-level enforcement model requirement for now)15:30
kmallocwe have another problem15:30
kmallocwe have a hard-coded role name that is landed in tree15:31
kmallocwe need to fix that as well.15:31
wxy|_kmalloc: ++15:32
kmallocwe need a new API, that the services can work from.15:32
kmallocwe can't keep this merged together like it is.15:32
kmalloclist limits is locked to your current scope.15:32
kmallocif you need external to your current scope (global or other wise) we need APIs that can do that so we can lock them down how we want with correct check strings.15:33
kmallocuser vs admin vs cloud-admin uses15:33
wxy|_the original purpose for list limits API is that non-admin user in a project can only fetch the limits belong to this project. and admin can fetch all the limits15:34
kmallocright. so lets make a new API for the admin interactions15:34
kmalloceither under /project15:34
kmallocor something new under /limits15:34
lbragstadwell - the good thing about it being experimental is that we can break the functionality that requires elevated authorization out15:34
kmalloclbragstad: ++15:34
kmallocit *sounds* like we need something under /limits15:35
lbragstadbut... we do have a project API for listing hierarchies already15:35
kmallocwe could add per-project limits [admin, filtered to project] under /project/{project_id}/limits15:35
kmallocthat doesn't list/emit limit data15:35
*** felipemonteiro_ has quit IRC15:35
kmallocthere are 3 concerns here:15:35
kmalloc1) User getting list for current scope ( /v3/limits <-- list)15:36
kmalloc2) admin getting *all* limits (cloud-admin)15:36
kmalloc2a) admin getting *all* hierarchy-limits (project/domain admin)15:36
kmalloc3) project-specific "get limits" [filtered by project]15:36
kmalloci am unsure how this breaks down API, 2a/3 might be one thing.15:37
kmallocbut 1 and 2 are clearly distinct actions.15:37
lbragstadis 1 expecting a hierarchy?15:37
lbragstador just limits for a single project?15:38
kmallocwxy|_: ^?15:38
wxy|_i think just limits15:38
kmallocno hierarchy, just current scope.15:38
kmallocthat is fine.15:38
wxy|_hierarchy information should not exposed to common users15:38
lbragstadso - as an end user15:38
kmallocyeah, that is what it looks like from the base code impl15:38
lbragstadi just need to get limits for a project i'm working on15:38
lbragstadi shouldn't be able to query all the hierarchy information15:39
lbragstadpertaining to limits15:39
kmallocnot with that api15:39
lbragstadok - so we need a separate api for domain/project administrators15:39
kmalloc"what is my current set of expected limits"15:39
lbragstadto be able to query for the limits of a tree15:39
lbragstadwhich is 2a?15:39
kmallocyep, which an end-user may be granted permission to do.15:40
kmallocthat is 2a15:40
lbragstadso - this really sounds like https://bugs.launchpad.net/keystone/+bug/175066015:41
openstackLaunchpad bug 1750660 in OpenStack Identity (keystone) "The v3 project API should account for different scopes" [High,Triaged]15:41
lbragstador very similar to it15:41
wxy|_are 2) and 2a) the same API? their response structure is different.15:44
kmallocyou have "get my current scope limits" and "get me a hierarchy" ... that is not system vs project scope15:44
kmallocget me current scope vs get me all, might be project vs system scope15:45
lbragstadthe "get me a hierarchy" part should take scope into account (e.g. a domain/project admin asking for the hierarchy versus a system admin)15:45
kmallocah ++15:45
kmallocso 2 and 2a *are* the same thing15:45
lbragstadbut yeah - the other one sounds like a different API15:45
kmallocjust scope-specific15:45
lbragstadright now we have GET /v3/limits/15:46
lbragstadGET /v3/limits *15:46
lbragstadand we don't have the hierarchical API, yet...15:47
lbragstadthat was something we were going to do with the query parameter?15:47
lbragstadquery string*15:47
wxy|_yeah, show_hierarchy15:47
kmallocoverloading via a qp and totally changing the output structure seems like the wrong choice15:48
kmalloca qp should maintain the same output format15:48
kmallocbut apply rules to it (e.g. expired_ok, filter by x [where not a security issue])15:49
kmallocif we are emitting a totally different structure (if show hierarchy is embeded in the current structure, that is one thing)15:49
kmallocit should be a different api15:49
lbragstadwhat if we added a query string to the project API that aggregated limit information?15:49
*** jmlowe_ has quit IRC15:50
lbragstadso - everything we have to build the hierarchy of projects stays in the same spot, but it just populates limit information15:50
kmallocthat is fine, populate the limit data in the "get_hierarchy" data api already15:51
lbragstadthis is an invite to poke holes :)15:51
kmallocas long as it doesn't meaningfully change the output (limit data may be added in the project output, maybe we don't need a qp for that at all, just do it?)15:51
kmallocs/output/output structure, e.g. no wildly different data struct15:52
lbragstadif we add a query parameter, we could signal that it is experimental though, couldn't we?15:52
kmallocah. opt-in sure15:52
kmallocand when we move away from expirimental, just make it the default?15:52
lbragstadjust in case we decide we don't like it15:52
kmallocsince we ignore un-used qps.15:52
kmallocso that solves the "get me the hierarchy" one.15:53
kmallocwe have the end-user one today15:53
kmallocand the heierarchy one solves the system vs project/domain admin scope15:53
lbragstadsure - because that should take token scope into account15:53
kmallocdo we need a "filtered by project" one e.g. /projects/{project_id}/limits api?15:54
kmallocis there a use for that api?15:54
lbragstadand GET /v3/limits should take token scope into account, too15:54
lbragstadbut it won't return a hierarchy, right?15:54
kmallocit cannot return a hierarchy unless the end user one also does (or we embed the hierarchy info somehow, don't embed it awkwardly imo)15:54
lbragstadi'm fine with only supporting one way to get the hierarchy15:55
*** gyee has joined #openstack-keystone15:55
lbragstaddo we have a /projects/{project_id}/limits API today, or is it just GET /v3/limits ?15:55
wxy|_we only have /v3/limits now.15:56
lbragstadok - cool15:56
lbragstadso - that API should take token scope into account (eventually)15:56
kmallocdo we need /projects/{project_id}/limits ?15:56
kmalloci don't think we do with the hierarchy bits.15:56
lbragstadi'm inclined to say no, but i'm willing to be convinced otherwise15:56
lbragstadbeacuse GET /v3/limits will take the project from the token context, if present15:57
lbragstadand filter the response accordingly15:57
wxy|_kmalloc: what if a cloud admin want to fetch a specified project's limits?15:57
lbragstadwith a system scoped token?15:58
kmallocwxy|_: i'm ok with adding filters for systme-scope as long as we don't change the format of the end-user get15:58
kmallocwhich should be a list anyway15:58
kmallocso end-user list: [{limit, inc. project_id}, {limit, inc. project_id}, {limit, inc. project_id}}15:58
wxy|_then we don't need /projects/{project_id}/limits15:59
kmallocsystem-scope would be [{limit, inc. project_id-1}, {limit, inc. project_id-2} ...]15:59
kmallocand ?project_id=XXX would limit the returned output/filter15:59
kmallocfor consistency, we could allow end-users to filter and return an empty list if they filter for a project outside of their current scope16:00
lbragstadi'm not sure i'd want to allow someone to get limits for a project without using a token scope though?16:01
lbragstadeither way - we can pick this up after the meeting16:01
lbragstador raise it in open discussion :)16:01
kmalloclbragstad: i'm not advocating anything of the sort, limits would require a token scope (project, my current scope), (system, all, filterable)16:01
lbragstadok - so the query string would simply be there to be consistent16:02
kmallocbut for consistency, filters might need to work on the project-scope as well. just if you filter for a project that isn't your current scope, the returned list is empty16:02
kmallocbecause you said "filter for project X" and X isn't there16:02
lbragstadand if they filter by the project they are scoped to, it's a noop16:03
lbragstadok - that seems reasonably safe16:03
kmallockeep the filtering behavior VERY consistent16:03
wxy|_v3/limits for end users by default, /v3/limits?project_id=xxx works for system-scope only. end user will get empty response if using project_id filter.16:03
kmallocwxy|_: if project_id differs from the current scope, the list would be empty16:04
ayoungMeeting now?16:04
kmallocin the non-system-scope16:04
kmallocadriant: yes16:04
kmallocayoung: ^16:04
kmallocwxy|_: basically in the non-system scope we just do "project_id == filtered_project_id_qp or []"16:05
kmallocin the system-scope we actually filter. behavior should be the same in both scopesso you can't accidently filter for project X and get project Y regardless of project vs system scope16:05
*** jmlowe has joined #openstack-keystone16:08
*** jmlowe has quit IRC16:09
*** ispp has quit IRC16:13
wxy|_kmalloc: lbragstad: I add some note here about the filter https://etherpad.openstack.org/p/limits-filter16:49
wxy|_if it works, I'll complete the patch tomorrow.16:49
lbragstadwxy|_: aweosme16:49
kmallocwxy|_: fantastic!16:50
*** kimamisa has quit IRC16:50
toskyuh, I have a question about service_token_roles_required; recently openstack-ansible-os_nova switched the value to true for nova, and that lead to an error in Sahara tests16:52
toskyI put together my findings in the last comment (before recheck) of patchset 7 here: https://review.openstack.org/#/c/569886/16:52
kmallocayoung: man, python 3.7 is going to be NICE.16:53
toskybut I'm not sure if how this can be fixed on the sahara side16:53
toskyor if it's just a deployment issue16:53
* kmalloc is somewhat said we don't get to rely on 3.6/3.7 things 16:53
kmalloclbragstad: btw, we can drop/should drop the v3-only test16:53
kmalloclbragstad: since... we only have v3 now16:53
kmallocor vice-versa16:53
kmallocdrop the non-v3-only version16:53
kmalloclbragstad: we have a gate job.. v3-only16:54
kmallocor had at least16:54
kmalloclbragstad: ah nvm, looks like it is gone16:55
lbragstad#startmeeting keystone-office-hours17:00
openstacklbragstad: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.17:00
kmalloclbragstad: did you forget to end the last office hours?17:01
*** openstack changes topic to "Rocky release schedule: https://releases.openstack.org/rocky/schedule.html | Meeting agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h | Trello: https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap !!NOTE!! This Channel is Logged ( https://tinyurl.com/OpenStackKeystone )"17:01
openstackMeeting ended Tue Jul 10 17:01:26 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-07-03-17.01.html17:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-07-03-17.01.txt17:01
openstackLog:            http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-07-03-17.01.log.html17:01
lbragstad#startmeeting keystone-office-hours17:01
openstackMeeting started Tue Jul 10 17:01:35 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.17:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:01
*** openstack changes topic to " (Meeting topic: keystone-office-hours)"17:01
*** ChanServ changes topic to "Rocky release schedule: https://releases.openstack.org/rocky/schedule.html | Meeting agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h | Trello: https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap !!NOTE!! This Channel is Logged ( https://tinyurl.com/OpenStackKeystone )"17:01
openstackThe meeting name has been set to 'keystone_office_hours'17:01
* lbragstad shrugs17:01
*** amoralej is now known as amoralej|off17:03
*** wxy|_ has quit IRC17:05
*** tesseract has quit IRC17:07
*** jmlowe has joined #openstack-keystone17:09
toskyehm, is there some specific topic or can I (re)ask a question?17:09
*** mvk_ has quit IRC17:11
*** spilla has quit IRC17:13
lbragstadtosky: no - this is just office hours17:16
lbragstadtosky: the failure linked in the patch is just warning though - it looks like keystone isn't preventing nova from responding?17:18
toskylbragstad: I may have swapped the working and the failing log17:20
*** spilla has joined #openstack-keystone17:20
lbragstadpass http://logs.openstack.org/02/579602/2/check/openstack-ansible-functional-ubuntu-xenial/a54186d/logs/openstack/openstack1/nova/nova-api-wsgi.log.txt.gz#_2018-07-03_00_14_49_78317:20
lbragstadfail http://logs.openstack.org/14/573514/3/check/openstack-ansible-functional-ubuntu-xenial/88d0dd9/logs/openstack/openstack1/nova/nova-api-wsgi.log.txt.gz#_2018-06-27_06_32_09_75317:20
toskyyes, I swapped the label, sorry17:21
lbragstadkeystonemiddleware doesn't actually throw an error there - http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n38517:21
lbragstadit's just a warning i believe17:22
toskythe working log shows the warning, and it works17:22
toskythe failing log (marked incorrectly as PASS) throws a 401 on that operation which was working before17:22
toskyso the question is: is that an error in nova? (which apparently can pass the tempest tests)? Should sahara change something there?17:29
lbragstadtosky: sounds related to https://bugs.launchpad.net/keystone/+bug/177988917:33
openstackLaunchpad bug 1779889 in OpenStack Identity (keystone) "Lack of documentation for validating expired tokens with service users" [Medium,Triaged]17:33
lbragstadcan you confirm that the nova service is using a service token?17:34
lbragstadthe irc log in that bug report goes into detail about how service tokens work17:34
toskyuh, I'm not sure about the nova configuraton, but I can check how it was setup17:35
toskybut shouldn't the bug be visible also with some other tests?17:36
lbragstadnova's configuration file will have a section in it for keystone_authtoken17:36
*** felipemonteiro has joined #openstack-keystone17:36
lbragstadso if a deployment tool is setting that up to use service tokens, but not setting up the service user properly, then you'll likely have a problem17:36
toskyapparently not: http://logs.openstack.org/86/569886/7/check/openstack-ansible-functional-centos-7/e34b95c/logs/etc/openstack/openstack1/nova/nova.conf.txt.gz17:39
toskythe change that introduced service_token_roles_required=true did not add anything else relevant to [keystone_authtoken]: https://review.openstack.org/#/c/578618/17:40
lbragstadtosky: https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L55417:44
lbragstadso osa is setting https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L210-L215 to true17:45
lbragstadbut https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L202-L209 is still the default of 'service'17:45
lbragstadso a "service token" is considered a token with a role named "service" in it17:45
lbragstaddoes osa have that role and does it use it with nova?17:45
lbragstadif not, that's probably causing the issue17:45
*** spilla has quit IRC17:45
toskyI suspect it does not, but I will raise the question (aka: a bug)17:46
toskyit looks like the source of the issue17:46
toskyoooh, thanks for askin there17:48
*** mvk_ has joined #openstack-keystone17:57
*** spilla has joined #openstack-keystone17:58
*** kimamisa has joined #openstack-keystone18:10
*** markguz has quit IRC18:34
*** ayoung has quit IRC18:35
*** kimamisa has quit IRC18:38
*** gyee has quit IRC18:38
*** rmascena has joined #openstack-keystone18:46
*** itlinux has joined #openstack-keystone18:47
*** ayoung has joined #openstack-keystone18:48
*** raildo has quit IRC18:49
*** rmascena is now known as raildo18:49
lbragstadgagehugo: didn't we have a bug open for https://review.openstack.org/#/c/576640/ ?18:54
gagehugolbragstad did we?18:54
lbragstadi'm parsing the meeting logs and i thought we said something about it?18:55
lbragstadmaybe i'm imagining things18:55
gagehugoI didn't make one, I can though18:59
lbragstadno worries - it probably isn't necessary18:59
lbragstadi was just double checking18:59
*** felipemonteiro_ has joined #openstack-keystone19:04
*** itlinux has quit IRC19:05
*** felipemonteiro has quit IRC19:08
*** nicodemus_ has joined #openstack-keystone19:18
nicodemus_I've configured keystone federation, with Keystone acting as an SP with an external IdP19:19
nicodemus_Login works just fine, but if I logout and then try to login again, I'm not asked for my user/pass (as if the session was never destroyed)19:19
nicodemus_Has anyone seen something like that? I'm unsure where to begin looking (keystone logs don't show any error19:20
lbragstadi have not personally experienced that19:25
lbragstadkmalloc: we should revisit https://review.openstack.org/#/c/555279/19:26
cmurphynicodemus_: that's normal, your idp stores a cookie saying you are logged in and there's no way for horizon to be aware of that so logging out of horizon doesn't affect it19:27
*** jmlowe has quit IRC19:27
* kmalloc looks19:27
cmurphythere might be an endpoint/button you can go to on your idp to log out of it directly19:27
lbragstadthanks cmurphy19:27
cmurphyor you can clear your cookies19:27
cmurphyit'll also time out eventually19:30
*** kimamisa has joined #openstack-keystone19:40
nicodemus_cmurphy: so, if I logout from horizon that doesn't trigger a logout to the IdP?19:44
nicodemus_I imagined the logout endpoints from the Mellon metadata would somehow handle the logout19:45
cmurphynicodemus_: you're right that should be possible but I don't think we've hooked that up between horizon and keystone and saml19:46
*** jmlowe has joined #openstack-keystone19:51
nicodemus_cmurphy: got it. So at least for now, I cloud say that login works fine but logout needs to be done outside of horizon19:52
cmurphynicodemus_: yes19:52
nicodemus_thanks a lot!19:53
*** itlinux has joined #openstack-keystone19:53
*** spilla has quit IRC19:56
kmalloclbragstad: yeah we should revisit that cleanup19:57
lbragstadhttp://flask.pocoo.org/docs/1.0/quickstart/#unique-urls-redirection-behavior explains some of the stuff we had to fix in our implementation20:02
lbragstadin case anyone else is wondering about the 418 Teapot stuff in the flaskification review20:03
kmallocyeah, we had some weirdness20:08
kmallocthe 418 teapot stuff [yes we can change the error code]20:08
openstackgerritGage Hugo proposed openstack/keystone master: Add docs for case-insensitivity in keystone  https://review.openstack.org/57664020:09
kmallocwe also had a number of cases where [even before flask] we referenced an incorrect url and got a 40420:10
kmallocwe expected a 404 in our tests20:10
kmallocbut it was the wrong kind of 40420:10
kmallocit was "app level" 404 not "not found resource" 40420:11
kmalloclbragstad: do you want me to move from 418 to something else, like 499 or something for testing?20:11
kmallocit isn't hard to change that code out... but, *shrug* i like 418, it wont be used for anything serious20:12
*** felipemonteiro__ has joined #openstack-keystone20:13
*** felipemonteiro_ has quit IRC20:13
*** felipemonteiro__ is now known as felipemonteiro20:16
*** felipemonteiro_ has joined #openstack-keystone20:28
openstackgerritGage Hugo proposed openstack/keystone master: Add docs for case-insensitivity in keystone  https://review.openstack.org/57664020:29
*** felipemonteiro has quit IRC20:32
*** raildo has quit IRC20:43
*** itlinux has quit IRC20:53
lbragstadyeah - doesn't matter to me i don't thik20:56
lbragstadi understand the reasoning for it now20:56
*** felipemonteiro_ has quit IRC20:58
*** felipemonteiro_ has joined #openstack-keystone20:59
*** jmlowe has quit IRC21:10
*** openstack changes topic to "Rocky release schedule: https://releases.openstack.org/rocky/schedule.html | Meeting agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h | Trello: https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap !!NOTE!! This Channel is Logged ( https://tinyurl.com/OpenStackKeystone )"21:17
openstackMeeting ended Tue Jul 10 21:17:08 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:17
openstackMinutes:        http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-07-10-17.01.html21:17
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-07-10-17.01.txt21:17
openstackLog:            http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-07-10-17.01.log.html21:17
*** jmlowe has joined #openstack-keystone21:18
*** jmlowe has quit IRC21:23
*** jmlowe has joined #openstack-keystone21:36
*** martinus__ has quit IRC21:38
*** edmondsw has quit IRC22:01
openstackgerritDoug Hellmann proposed openstack/oslo.limit master: import zuul job settings from project-config  https://review.openstack.org/58150622:01
openstackgerritDoug Hellmann proposed openstack/oslo.policy master: import zuul job settings from project-config  https://review.openstack.org/58151022:01
*** felipemonteiro_ has quit IRC22:04
openstackgerritSami Makki proposed openstack/keystone master: Invalidate 'computed assignments' cache when creating or deleting project.  https://review.openstack.org/58134622:14
*** rcernin has joined #openstack-keystone22:22
*** kimamisa has quit IRC22:26
openstackgerritMerged openstack/keystone master: Only upload SP metadata to testshib.org if IDP id is testshib  https://review.openstack.org/54547122:44
*** elibrokeit is now known as meltdown_spectre22:51
*** meltdown_spectre is now known as elibrokeit22:59
*** spilla has joined #openstack-keystone23:07
*** tosky has quit IRC23:08
*** spilla has quit IRC23:09
*** edmondsw has joined #openstack-keystone23:16
*** edmondsw has quit IRC23:21
*** bhagyashri_s has quit IRC23:27
*** bhagyashri_s has joined #openstack-keystone23:28

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