Monday, 2017-03-27

*** edmondsw has quit IRC00:02
*** catintheroof has joined #openstack-keystone00:06
catintheroofguys hi, if i have a fernet token in my hands, and of course access to fernet keys on keystone server, whats the best way to know to whom that token belongs and how it is configured ?00:08
catintheroofconfigured i mean, scoped00:13
*** oomichi has quit IRC00:39
*** oomichi has joined #openstack-keystone00:42
bretonmake a GET request to /v3/auth/tokens00:48
bretonwith the token in X-Subject-Token header00:48
*** lucasxu has joined #openstack-keystone00:56
*** lucasxu has quit IRC00:57
catintheroofbreton: nice! does this needs to be authenticated ?00:58
*** jamielennox is now known as jamielennox|away01:01
*** markvoelker has joined #openstack-keystone01:01
*** liujiong has joined #openstack-keystone01:19
*** jamielennox|away is now known as jamielennox01:19
*** tovin07 has joined #openstack-keystone01:41
*** oomichi has quit IRC02:08
*** dave-mccowan has quit IRC02:09
*** oomichi has joined #openstack-keystone02:12
*** niteshnarayanlal has joined #openstack-keystone02:44
*** links has joined #openstack-keystone03:09
*** catintheroof_ has joined #openstack-keystone03:32
*** edmondsw has joined #openstack-keystone03:33
*** lamt has joined #openstack-keystone03:34
*** catintheroof has quit IRC03:36
*** edmondsw has quit IRC03:37
*** nicolasbock has quit IRC03:45
*** prashkre_ has joined #openstack-keystone04:12
*** jamielennox is now known as jamielennox|away04:14
*** jamielennox|away is now known as jamielennox04:22
*** lamt has quit IRC04:28
*** prashkre_ has quit IRC04:35
*** niteshnarayanlal has quit IRC05:01
*** rcernin has joined #openstack-keystone05:26
*** lamt has joined #openstack-keystone05:34
*** richm has quit IRC05:43
*** aojea has joined #openstack-keystone05:54
*** oomichi has quit IRC05:58
*** oomichi has joined #openstack-keystone06:01
*** aojea has quit IRC06:04
*** aojea has joined #openstack-keystone06:04
*** aojea has quit IRC06:09
*** jaosorior has joined #openstack-keystone06:13
*** lamt has quit IRC06:20
*** prashkre_ has joined #openstack-keystone06:21
*** lamt has joined #openstack-keystone06:26
*** oomichi has quit IRC06:28
*** oomichi has joined #openstack-keystone06:32
*** oomichi has quit IRC06:39
*** oomichi has joined #openstack-keystone06:43
*** lamt has quit IRC06:53
*** jaosorior has quit IRC06:58
*** oomichi has quit IRC06:58
*** oomichi has joined #openstack-keystone07:03
*** oomichi has quit IRC07:08
*** edmondsw has joined #openstack-keystone07:09
*** dikonoor has joined #openstack-keystone07:09
*** oomichi has joined #openstack-keystone07:13
*** edmondsw has quit IRC07:14
*** aojea has joined #openstack-keystone07:17
*** jaosorior has joined #openstack-keystone07:18
*** pcaruana has joined #openstack-keystone07:20
*** oomichi has quit IRC07:38
*** oomichi has joined #openstack-keystone07:43
*** tesseract has joined #openstack-keystone07:44
*** namnh has joined #openstack-keystone07:49
bretoncatintheroof_: yes07:52
*** prashkre_ has quit IRC07:58
*** delaf has left #openstack-keystone07:59
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:01
*** Aqsa has joined #openstack-keystone08:10
*** bjornar_ has joined #openstack-keystone08:24
*** rakhmerov has quit IRC08:26
*** rakhmerov has joined #openstack-keystone08:26
*** lxnch has joined #openstack-keystone08:31
*** prashkre_ has joined #openstack-keystone08:31
*** prashkre__ has joined #openstack-keystone08:33
*** openstackgerrit has quit IRC08:33
*** prashkre_ has quit IRC08:35
*** namnh has quit IRC08:54
*** namnh has joined #openstack-keystone08:55
*** edmondsw has joined #openstack-keystone08:57
*** edmondsw has quit IRC09:02
*** nishaYadav has joined #openstack-keystone09:15
*** dikonoor has quit IRC09:29
*** dikonoor has joined #openstack-keystone09:29
*** aojea_ has joined #openstack-keystone09:34
*** aojea has quit IRC09:37
*** liujiong has quit IRC10:09
*** richm has joined #openstack-keystone10:14
*** dikonoor has quit IRC10:25
*** tovin07 has quit IRC10:27
*** mvk has quit IRC10:29
*** ayoung has joined #openstack-keystone10:36
*** nicolasbock has joined #openstack-keystone10:42
*** edmondsw has joined #openstack-keystone10:46
*** edmondsw has quit IRC10:50
*** raildo has joined #openstack-keystone10:51
*** dikonoor has joined #openstack-keystone11:06
*** dikonoor has quit IRC11:10
*** dikonoor has joined #openstack-keystone11:12
*** catintheroof_ has quit IRC11:13
*** nicolasbock has quit IRC11:16
*** dave-mccowan has joined #openstack-keystone11:19
*** nicolasbock has joined #openstack-keystone11:19
*** prashkre__ has quit IRC11:29
*** zhurong has joined #openstack-keystone11:30
*** prashkre__ has joined #openstack-keystone11:30
*** nicolasbock has quit IRC11:42
*** dikonoor has quit IRC11:44
*** mvk has joined #openstack-keystone11:44
*** thorst has joined #openstack-keystone11:45
*** nicolasbock has joined #openstack-keystone11:45
*** dikonoor has joined #openstack-keystone11:50
*** namnh has quit IRC11:53
*** catintheroof has joined #openstack-keystone12:08
*** erlon has joined #openstack-keystone12:11
*** dave-mccowan has quit IRC12:12
*** zhurong has quit IRC12:12
*** edmondsw_ has joined #openstack-keystone12:29
*** openstackgerrit has joined #openstack-keystone12:30
openstackgerritAqsa Malik proposed openstack/keystone master: Fix mapping_purge failure
*** niteshnarayanlal has joined #openstack-keystone12:35
*** links has quit IRC12:40
*** niteshnarayanlal has quit IRC12:41
*** markvoelker has quit IRC12:47
Aqsarodrigods : Can you please have a look at the patchset I uploaded.12:47
rodrigodsAqsa, sure!12:47
AqsaI actually got this error : "This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset." should I rebase it?12:48
bretonAqsa: yes, please do rebase12:50
*** chlong has joined #openstack-keystone12:51
*** niteshnarayanlal has joined #openstack-keystone12:57
openstackgerritAqsa Malik proposed openstack/keystone master: Fix mapping_purge failure
AqsaStill got the same error.13:00
rodrigodsAqsa, locally do: "git checkout master"13:01
rodrigodsthen "git pull origin master"13:01
rodrigodsthen you change again to your branch and do a "git rebase master"13:01
*** prashkre__ has quit IRC13:03
*** prashkre__ has joined #openstack-keystone13:04
dstanekrodrigods: git pull will merge commit depending on setup13:06
rodrigodsdstanek, not if working in a separate branch13:07
rodrigodsi have assumed that13:07
*** spilla has joined #openstack-keystone13:07
dstanek'git review -d ####; git fetch; git rebase origin master' is really what you want to do13:07
rodrigodsdstanek, if the master code isn't updated, the rebase is useless13:08
rodrigodsdoes git fetch do that?13:08
dstaneklbragstad: getting closer....bugs need to get trimmed more though13:08
rodrigodsi thought it would only get the branches, not the commits13:08
dstanek'git fetch' pulls changes from the remote and makes them available locally without changing local branches13:09
dstanekfor instance, your local master branch isn't touched, but the origin/master remotes will have the updated commits locally13:09
rodrigodsdstanek, hmm good to know13:11
*** niteshnarayanlal has quit IRC13:20
nishaYadavrodrigods, hey13:24
rodrigodshi nishaYadav13:24
nishaYadavrodrigods, in case you get some time, can you please review a keystone doc patch?13:25
rodrigodsnishaYadav, sure13:25
nishaYadavrodrigods, thanks a lot :)
rodrigodsnishaYadav, looks like you have made pretty nice comments there, will keep this review on my list and circle back when they submit another patch13:26
rodrigodssounds good?13:26
nishaYadavrodrigods, yeah, that would be really nice :)13:27
lbragstaddstanek well - we're down to 91 in keystone13:34
rodrigodslbragstad, re: i'm a bit overwhelmed but intend to send another patchset shortly13:36
rodrigodsi have noticed it currently breaks our functional tests (which include the federation tests - one of them is not passing)13:36
lbragstadrodrigods cool - i'll be on the look out for it13:37
lbragstadrodrigods what you have locally is breaking functional tests?13:37
dstaneklbragstad: i was really hoping for the 80s13:37
lbragstaddstanek i think we should be able to get there this week13:37
lbragstaddstanek we got a good bit of stuff done last week, i bet after we follow up on a few patches we'll be there13:38
dstaneklbragstad: 70s by the end of bug day13:38
rodrigodslbragstad, i didn't test :( don't have a proper federated env currently set13:38
lbragstadrodrigods gotcha13:38
dstaneklbragstad: had some test trouble Friday, but got them working on Sat -
lbragstaddstanek nice!13:39
dstaneklbragstad: i did a bunch of test improvements this weekend. just trying to get them in a state where I can commit them13:40
lbragstaddstanek awesome13:40
lbragstaddstanek are any of them bug related? or just general improvements?13:40
dstaneklbragstad: improvements. things i noticed and some speedups.13:43
*** gsilvis has quit IRC13:43
lbragstaddstanek is the translation patch something we should backport to ocata?13:46
*** gsilvis has joined #openstack-keystone13:49
dstaneklbragstad: no13:50
dstaneklbragstad: oh, wait. the bug fix one right? that one yes13:50
dstanekthe translation link from above no13:51
dstaneklbragstad: if you want i can backport it13:51
lbragstaddstanek it's already proposed13:51
dstaneklbragstad: looking13:57
*** markvoelker has joined #openstack-keystone14:00
*** agrebennikov has joined #openstack-keystone14:01
*** nishaYadav has quit IRC14:07
*** knangia has joined #openstack-keystone14:08
*** chlong has quit IRC14:09
*** zhurong has joined #openstack-keystone14:11
*** gyee has joined #openstack-keystone14:13
*** gyee has quit IRC14:13
*** dave-mccowan has joined #openstack-keystone14:16
*** bjornar_ has quit IRC14:18
*** ravelar has joined #openstack-keystone14:22
openstackgerritRichard Avelar proposed openstack/keystone master: Add federated support for get user
*** niteshnarayanlal has joined #openstack-keystone14:31
*** dr_dolphm is now known as dolphm14:37
*** rderose has joined #openstack-keystone14:40
*** zhurong has quit IRC14:41
*** phalmos has joined #openstack-keystone14:43
*** szaher has quit IRC14:45
*** szaher has joined #openstack-keystone14:46
*** sjain has joined #openstack-keystone14:55
*** dikonoor has quit IRC14:58
*** rcernin has quit IRC15:07
*** shewless has joined #openstack-keystone15:12
shewlessHello. If I know my domain name, and my project name, is there a way to get my project_id?15:15
*** shewless_ has joined #openstack-keystone15:17
lbragstadshewless you can list projects and filter by name15:17
shewless_@lbragstad: sorry I got disconnected before completing my question15:17
lbragstadGET /v3/projects/?name=foo15:18
shewless_I tried exactly that but it seems like by default normal users don't have permissions to do that15:18
lbragstadshewless_ the default policy for project operations is admin_required15:18
shewless_so I thought maybe there was another way..15:18
shewless_@lbragstad: so how would a normal user (non admin) be able to use the API if they don't know their project_id?15:19
openstackgerritAnthony Washington proposed openstack/keystone master: Move trust to DocumentedRuleDefault
dstanekshewless_: what exactly are you trying to do?15:19
*** shewless has quit IRC15:19
shewless_dstanek: I'm trying to write a simple script that uses curl to list a users stacks15:20
shewless_the user has their environemnt set with a token, a project name, and a domain name15:20
shewless_and they can use the openstack cli with this environment15:20
dstanekshewless_: that api won't accept a name?15:21
shewless_dstanek: hmm. I can try it. Maybe it does. The API says "project_id" so I assumed it would only accept the ID15:21
shewless_let me try15:21
lbragstadshewless_ the openstack cli will do some stuff based on filtering15:23
openstackgerritAnthony Washington proposed openstack/keystone master: Move group policies to DocumentedRuleDefault
shewless_dstanek: I get a 403 error (even as admin) if I try and list stacks using the project_name instead of project_id.  8004/v1/<project_name>/stacks15:25
*** chlong has joined #openstack-keystone15:25
shewless_@lbragstad: any way I can see what the CLI is doing ?15:26
lbragstadthis is what i can do locally -
shewless_I tried --debug15:26
shewless_@lbragstad: is the for a normal user?15:26
lbragstadthat's an admin user15:27
lbragstadquerying the projects15:27
shewless_@lbragstad: right.. but a normal user won't be able to do that right?15:27
lbragstadi was just using it to show case the usage of the client15:27
lbragstadwhere you can do `openstack project show {name}`15:27
lbragstadbut you can also do `openstack project show {id}`15:27
lbragstadshewless_ can your user do either of those?15:28
shewless_@lbragstad specifically form the CLI?15:28
*** nishaYadav has joined #openstack-keystone15:29
*** lucasxu has joined #openstack-keystone15:29
shewless_@lbragstad: no they cannot do either of those15:30
shewless_if they do "openstack stack list" it works somehow :)15:31
shewless_maybe I lied about that last part15:31
lbragstadstack list is a heat API15:31
shewless_@lbragstad: yes but it needs to authenticate first15:31
shewless_let me have a look at this. I think the CLI is just as busted as the API for normal users15:32
shewless_(if only token, project_name, and domain name are specified)15:32
shewless_maybe project_id is required to be set in the environment for non admin users?15:32
lbragstadshewless_ are you able to get a project scoped token?15:33
lbragstadshewless_ using you project name and domain name?15:33
openstackgerritAnthony Washington proposed openstack/keystone master: Move access token to DocumentedRuleDefault
shewless_@lbragstad: yes I believe so15:33
lbragstadshewless_ look in the auth response15:34
lbragstadshewless_ if you have a project scoped token, you should see a project specific section of the token response that has information about the project you're scoped to15:34
shewless_@lbragstad: let me have a look. This is how I'm generating the token BTW:
openstackgerritAnthony Washington proposed openstack/keystone master: Move revoke events to DocumentedRuleDefault
lbragstadshewless_ yeah - if you inspect the entire request, you should be able to find some project information in there, since you're asking for a project-scoped token15:36
shewless_@lbragstad: I've set that request to be a one time action. The user subsequently would already have their token15:37
shewless_and basically no other information15:37
shewless_I'm thinking I might just change the policy to allow users to list projects15:38
shewless_since this is a private cloud15:38
* lbragstad shewless_ you can get the project id from the auth response -
lbragstadusing project name and domain name to scope the token15:39
lbragstadshewless_ this is the request I made -
shewless_@lbragstad: interesting let me try that15:41
shewless_..and thank you so far for the help15:41
lbragstadshewless_ no problem - i smashed both into a single paste -
openstackgerritAnthony Washington proposed openstack/keystone master: Move region policies to DocumentedRuleDefault
openstackgerritGage Hugo proposed openstack/keystone-specs master: Add Project tags
shewless_@lbragstad: I could make my auth method "token" if I already have a token right?15:43
lbragstadshewless_ yep15:43
lbragstadshewless_ but are you trying to reauthenticate for a token?15:44
lbragstadshewless_ you should be able to get the same information if you validate the token you just got in your first step15:45
openstackgerritRichard Avelar proposed openstack/keystone master: Remove policy file from source and refactor tests
lbragstadshewless_ for example -
lbragstadshewless_ so - based on your script (
lbragstadyou should be able to do `curl -X GET -H "X-Subject-Token: $token" -H "X-Auth-Token: $token" http://localhost:35357/v3/auth/tokens | python -m json.tool`15:48
*** aojea has joined #openstack-keystone15:48
lbragstadto validate the token you just received using your script15:48
lbragstadsubstituting the auth endpoint for your own15:49
shewless_@lbragstad: not trying to get a new token15:49
shewless_just want to validate the one I already received15:50
lbragstadshewless_ cool - so you should be able to validate the token you already have from authenticating via your script15:50
*** aojea_ has quit IRC15:50
lbragstadyou can validate the token you already have (with itself) by passing it as the X-Auth-Token and the X-Subject-Token and perform a GET /v3/auth/token/15:51
lbragstadthe response from token validation should contain all the information should received about the token when it was created15:52
openstackgerritGage Hugo proposed openstack/keystone-specs master: Remove pbr warnerrors in favor of sphinx check
shewless_@lbragstad: thanks. I'll play around with this info and see what I can do15:53
dolphmlbragstad: i'd suggest landing this ASAP to avoid endless merge conflict resolution - i assume dstanek would +2 after his revision
lbragstadshewless_ sounds good15:53
lbragstaddolphm ++ good call15:53
lbragstaddolphm I saw that this morning - i'll review it before lunch15:54
dolphmlbragstad: it's super straight forward, other than the testing changes15:55
lbragstaddolphm did you see any follow ups from sdages concerns?15:55
openstackgerritAnthony Washington proposed openstack/keystone master: Move user policies to DocumentedRuleDefault
lbragstaddolphm i should clarify - sdague had some comments on a similar patch being made to nova15:59
*** aojea has quit IRC15:59
dolphmlbragstad: on the mailing list?15:59
lbragstaddolphm yeah - there was a thread on the mailing list16:00
lbragstaddstanek let me see if I can dig it up16:00
*** aojea has joined #openstack-keystone16:00
lbragstader dolphm ^16:00
dolphmlbragstad: i read through several posts - the only concerns i recall from sdague were about the reversal of policy and removing supporting testing infrastructure, etc, from nova16:01
lbragstaddolphm i must have stumbled across it in review16:01
dolphmlbragstad: i basically only read as far as to understand the i18n team's position - which make sense to me (although i might have suggested simply appending the translated log messages to the english ones, if they're available)16:01
lbragstaddolphm oh - instead of removing the translated ones altogether, just supply both?16:02
dolphmi trust that they know their audience better than we do16:02
dolphmlbragstad: right; keep the _LI() calls, but have the translation engine simply append the translation in oslo.i18n16:03
lbragstadthat's not a bad suggestion16:03
dolphmthat way you get the english thing that's google-able, and the translated thing that's localized for you16:03
dolphmlbragstad: if it's worth suggesting, i could revive the november thread16:04
antwashlbragstad : thanks for taking the time to comment on the policies patches16:04
*** aojea has quit IRC16:04
lbragstadantwash no problem - that's for proposing them16:04
lbragstadantwash still working through a bunch of them16:04
lbragstaddolphm the testing/maintenance concern is still tricky though16:05
dstanekdolphm: that's my favorite patch16:05
dolphmdstanek: lol16:05
dolphmlbragstad: on our end, my suggestion wouldn't change anything in terms of testing or maintenance16:05
lbragstaddolphm right - it's more of a maintenance thing for the i18n team16:06
*** prashkre__ has quit IRC16:06
dstanekin another channel someone was saying that the expectation is that operators understand English already16:06
lbragstadi remember that being an argument like 4 years ago when I worked on an openstack product16:07
Aqsadstanek : Thanks it worked.16:08
dstaneki don't remeber all of the cited sources, but config, code, etc. are in English16:08
lbragstadi specifically remember operators wanting to keep the english version of the logs because it was easier to find tracebacks16:08
lbragstadand more google-able16:08
dstanekAqsa: the git stuff?16:18
openstackgerritRichard Avelar proposed openstack/keystone master: Validate rolling upgrade is run in order
Aqsadstanek: yes16:18
dstanekAqsa: awesome. i fetch and rebase a lot in my workflow16:19
openstackgerritRichard Avelar proposed openstack/keystone master: Validate rolling upgrade is run in order
Aqsadstanek: is it possible to change the ownership of the bug to yourself if you are just an author?16:21
*** MasterOfBugs has joined #openstack-keystone16:28
dstanekAqsa: you want it assigned to you, you mean?16:29
dstanekor to someone else?16:29
*** mvk has quit IRC16:29
AqsaI mean i am submitting patches to the bug that is owned by someone else, i want to change the ownership to myself too.16:30
dstanekAqsa: you can do it manually by just assigning it to yourself. i believe there is still automation that will do that for you, but i'm not entirely sure.16:31
dstanekhonsestly, i usually don't explicitly assign things to me although i probably should16:31
lbragstadif you propose a patch with 'closes-bug #{bug_number}16:33
lbragstadin the message, there is some infrastructure that will go through and automatically assign the bug to the person who committed the patch set16:34
AqsaOh alright!16:36
lbragstadAqsa no problem16:37
*** rcernin has joined #openstack-keystone16:37
*** adrian_otto has joined #openstack-keystone16:38
*** Aqsa has quit IRC16:41
*** jaosorior has quit IRC16:41
*** nishaYadav has quit IRC16:43
*** sjain has quit IRC16:47
*** gyee has joined #openstack-keystone16:54
*** tesseract has quit IRC16:59
dolphmantwash: i'm definitely not going to leave this comment on all your patches, but before i continue reviewing:
dolphmantwash: will operations ever include anything other than method/path pairs in dictionaries?17:04
dolphmantwash: i.e. are there any other keys that might appear in an operation?17:04
dolphmantwash: like a header, or something?17:04
*** rcernin has quit IRC17:08
*** mvk has joined #openstack-keystone17:12
*** pcaruana has quit IRC17:12
*** nishaYadav has joined #openstack-keystone17:15
*** harlowja has quit IRC17:18
*** nishaYadav has quit IRC17:20
*** chlong has quit IRC17:22
*** markvoelker has quit IRC17:23
*** harlowja has joined #openstack-keystone17:24
*** bjornar_ has joined #openstack-keystone17:25
lbragstaddolphm will operators ever include anything other than method/path or will developers even include anything other than method/path?17:28
lbragstadFYI for everyone - there is a spec proposed for keystone to accept the storage of limits to improve the hierarchical quotas story
lbragstadwe should be sure to review that ^ document well since it will have quite a bit of keystone related work17:30
*** prashkre__ has joined #openstack-keystone17:30
dolphmlbragstad: both? i'm moreso asking what the API supports17:33
dolphmlbragstad: [('METHOD'17:33
dolphmlbragstad: whoops, [('METHOD', '/path/'), ... ] would have been easier to maintain if that's the case17:34
openstackgerritMerged openstack/keystone master: Remove log translations in keystone
*** chlong has joined #openstack-keystone17:38
*** prashkre has joined #openstack-keystone17:39
openstackgerritRon De Rose proposed openstack/keystone-specs master: API keys
*** lucasxu has quit IRC17:40
*** prashkre__ has quit IRC17:42
*** dave-mccowan has quit IRC17:46
openstackgerritRichard Avelar proposed openstack/keystone master: Validate rolling upgrade is run in order
*** nishaYadav has joined #openstack-keystone17:50
*** nishaYadav is now known as Guest4716917:51
*** Guest47169 is now known as nishaYadav_17:51
*** nishaYadav_ has quit IRC17:51
notmorgansamueldmq: FYI, I just cancelled my boston lodging, wont be able to make it17:55
notmorgantoo much personal stuff going on right around that time17:55
samueldmqnotmorgan: oh17:56
samueldmqnotmorgan: sure, I am glad you take care of your personal life too! :)17:56
samueldmqnotmorgan: thanks for letting me know17:56
*** adrian_otto has quit IRC17:57
notmorganyou'll kill it for that presentation though17:57
samueldmqnotmorgan: that's my hope. I won't leave space for demo gods.17:59
lbragstaddolphm oh - sure, i see what you mean18:01
*** dave-mccowan has joined #openstack-keystone18:01
lbragstaddolphm afaik - only developers will be using the API18:01
lbragstaddolphm well - to be more specific, project developers looking to supply more details for policy18:02
antwashdolphm : sorry I was zoned out, but when the policy in generated it shows in the format "method" : "path"18:04
lbragstadravelar did you have a similar patch to somewhere?18:04
*** aojea has joined #openstack-keystone18:05
openstackgerritRichard Avelar proposed openstack/keystone master: Remove policy file from source and refactor tests
ravelarlbragstad ^18:06
* notmorgan zones out again.18:08
openstackgerritAnthony Washington proposed openstack/keystone master: Move user policies to DocumentedRuleDefault
ravelarlbragstad I have Implements: blueprint policy-in-code in
*** aojea has quit IRC18:10
hlo323rodrigods: hi, I have set up a devstack environment. what should be my next step?18:10
ravelarlbragstad not sure if it matters if I put it in both or just one of the patches and implements in the other18:10
*** lucasxu has joined #openstack-keystone18:11
lbragstadravelar technically i don't think it matters, i think it's just an un-enforced formality?18:11
dstanekrderose: lbragstad: i'll going to call the current though of an api keys implementation 'restricted passwords' because i don't have a better name18:12
lbragstaddstanek did you have a path for making api keys replace tokens?18:12
lbragstaddstanek via signed requests?18:12
dstaneklbragstad: that is definitely a path forward18:12
dstanekcould we/will we? no idea, but true api keys are a step in that direction18:13
openstackgerritRichard Avelar proposed openstack/keystone master: Remove policy file from source and refactor tests
lbragstaddstanek was that documented/eluded to in your proposal?18:14
*** catintheroof has quit IRC18:15
lbragstaddstanek i believe was the one?18:16
dstaneklbragstad: don't remember, but i don't think so. that's what we were discussing at PTG18:16
dstaneklbragstad: yep, that was my brain dump of how api keys would work, since the other api key spec was describing restricted passwords18:17
lbragstaddstanek right18:17
lbragstaddstanek we should take a stab at laying out the path to removing bearer tokens with api keys18:18
*** MasterOfBugs has quit IRC18:18
lbragstaddstanek what was the gist of it?18:18
*** lamt has joined #openstack-keystone18:23
lbragstadravelar FYI - i abandon in favor of your approach18:24
*** Aqsa has joined #openstack-keystone18:26
*** ravelar has quit IRC18:26
lbragstadrderose do you have anything regarding the API key spec that you want to discuss tomorrow during the keystone meeting18:27
lbragstadrderose i'm filling out the agenda and I have some time carved off for spec discussion18:27
rderoselbragstad: yeah, you could add me at the end18:28
rderoseI'm working on the spec now18:28
lbragstadrderose sounds good18:28
dstaneklbragstad: if you had api keys then you implement request signing. that's it for support. i don't know what would have to happen to move all of openstack to use it. i think there would be some deployment complexities18:30
*** d0ugal has quit IRC18:31
*** aojea has joined #openstack-keystone18:32
*** ravelar has joined #openstack-keystone18:34
*** aojea has quit IRC18:37
openstackgerritRon De Rose proposed openstack/keystone-specs master: Access Keys
dstanekrderose: what made you choose the name access keys?18:41
rderosedstanek: I think the 'key' part makes sense18:45
rderosedstanek: and decided on 'access' since this version of the spec requires requesting a scoped token18:45
dstanekrderose: that's what aws calls their api keys18:45
openstackgerritAnthony Washington proposed openstack/keystone master: Move trust to DocumentedRuleDefault
*** d0ugal has joined #openstack-keystone18:47
antwashlbragstad : -- I don't see any problem with it. We could easily add "Deprecated" to the description18:48
rderosedstanek: I also wanted a name that would allow us to move towards a more standard API key.18:48
openstackgerritAnthony Washington proposed openstack/keystone master: Move user policies to DocumentedRuleDefault
rderosedstanek: So maybe we start with requiring you to request a scoped token, but later we rework it so that you don't have to18:48
dstanekrderose: what do you mean?18:48
lbragstadantwash true - dstanek dolphm rderose do you have a preference?18:49
dstanekrderose: i don't think we want to call it access keys since that's not really what it is18:49
rderosedstanek: it's not AWS's access key18:50
lbragstadantwash also - we should have some sort of convention for punctuation in descriptions18:50
dstanekrderose: exactly18:50
lbragstadantwash i'm seeing some patches that have it proposed in the description, and others that don't18:50
dstaneklbragstad: ?18:50
antwashYeah I was seeing that missing the "."18:50
rderosedstanek: but again, it could be more like AWS access key in the future. to me this would just be a start; improves security today.18:51
rderosebiting off a small chunk now18:51
antwashdstanek: adding "deprecated" to the policy description18:51
lbragstadantwash i suppose our help text for configuration options is complete with periods, we could be consistent with that18:52
dstanekrderose: what take an intermediate step? if we add a real api-key concept then we'd have to some up with another name right?18:52
antwashList projects for user (deprecated)18:52
antwash^ example18:52
dstanekantwash: what's the question? do i like that?18:52
lbragstad`GET /v3/OS-FEDERATION/projects List projects for federated user (deprecated).`18:52
antwashdstanek : yeah how do you all feel about adding that "deprecated" portion mainly18:53
dstanekrderose: i think what we really need to have in that spec the rationale, usecases and future vision. i don't think i'd waste time on an implementation until we have that18:53
lbragstaddstanek in the descriptions for policies, should we advertise deprecated policies as such?18:53
rderosedstanek: we have the use case (at least the one I'm trying to address); still working on this spec18:54
dstanekantwash: if it's deprecated then we should add it. deprecating policies seems really, really hard to me18:54
lbragstader - a better question would be, should we advertise deprecated API as such in policy descriptions?18:54
rderosedstanek: I'll add future vision as well18:54
dstanekrderose: i think the reason you keep changing the implementation is that we don't have that part solid yet18:54
rderosedstanek: true18:55
dstanekantwash: for example if we remvove a policy entry or remove a label then we are potentially making someone's cloud really insecure18:55
lbragstaddstanek i don't think we're that far yet - right now we're just trying to figure out if we use the policy file as another thing to advertise deprecated APIs18:56
dstanekrderose: your best bet is just stick with an architecture design process. collect input from stakeholders and come up with a vision from there18:56
lbragstadnot deprecating policies18:56
dstaneklbragstad: oh, then no. i wouldn't document API deprecations there. people will be confused like I just was.18:57
lbragstadcc antwash18:57
lbragstaddstanek that's a valid point18:57
antwashcool, I'll remove it :) thanks guys18:57
lbragstadantwash no problem - thank you18:58
lbragstadantwash and if i made that comment on other patch sets, feel free to disregard18:58
lbragstadantwash if you update, just say we talked about it in IRC :)18:58
* lbragstad meanders away to find a cup of coffee18:59
antwashlbragstad: also if that's the case they should be removed from here to :
*** phalmos has quit IRC19:02
openstackgerritAnthony Washington proposed openstack/keystone master: Move user policies to DocumentedRuleDefault
antwashawe never mind I had it confused lol you're referring to the method19:05
openstackgerritAnthony Washington proposed openstack/keystone master: Move user policies to DocumentedRuleDefault
*** aojea has joined #openstack-keystone19:09
*** adrian_otto has joined #openstack-keystone19:12
lbragstadravelar passes for me locally19:13
antwashTo answer your question here: -- I was using ( to figure out some of the mapping19:13
lbragstadbut it might require a patch to tempest19:13
*** erlon has quit IRC19:15
notmorganlbragstad: if you didn't see, skipping boston19:15
notmorganlbragstad: sorry =/19:15
lbragstadnotmorgan i saw :(19:16
lbragstadantwash it looks like all your DocumentedDefaultRule patches are in a single string based on one another?19:19
antwashlbragstad, yeah I did them all on the same branch -- is that bad?19:19
lbragstadantwash no - that's not necessarily bad19:20
lbragstadantwash we just might be able to move through them faster if they are all based on master individually?19:21
lbragstadsince i don't think there is a reason they all can't be based directly on master, right?19:21
*** samueldmq has quit IRC19:23
*** samueldmq has joined #openstack-keystone19:24
*** lamt has quit IRC19:56
*** antwash_ has quit IRC19:57
*** lamt has joined #openstack-keystone19:58
*** niteshnarayanlal has quit IRC20:08
*** markvoelker has joined #openstack-keystone20:09
*** jamielennox is now known as jamielennox|away20:13
*** markvoelker has quit IRC20:22
*** catintheroof has joined #openstack-keystone20:23
*** jamielennox|away is now known as jamielennox20:24
*** catintheroof has quit IRC20:39
*** shewless_ has quit IRC20:42
antwashlbragstad: well I really made the first change parent to the Policy 5 implementation and the rest just followed right after. That's really why they're like that20:49
lbragstadantwash ah - so once merges we should be able to rebase all of those on master20:51
lbragstadthat should make reviewing them go much faster20:51
antwashlbragstad: yeah that makes sense, then theres no conflicts20:54
*** aojea has quit IRC20:57
*** aojea has joined #openstack-keystone20:57
lbragstadantwash well - for the most part conflicts will be minimal from what i can tell, but it makes it so that we can approve several of them in parallel20:57
lbragstadantwash instead of only sending one through the gate at a time.20:57
*** aojea has quit IRC21:02
*** aojea has joined #openstack-keystone21:02
*** edmondsw_ has quit IRC21:03
*** edmondsw_ has joined #openstack-keystone21:05
*** prashkre has quit IRC21:07
*** edmondsw_ has quit IRC21:09
*** bjornar_ has quit IRC21:12
*** prashkre has joined #openstack-keystone21:18
*** prashkre has quit IRC21:20
*** dave-mccowan has quit IRC21:27
*** lucasxu has quit IRC21:34
*** Aqsa has quit IRC21:37
*** lucasxu has joined #openstack-keystone21:41
*** lxnch has quit IRC21:41
*** spilla has quit IRC21:42
antwashlbragstad: awe I see what you're saying now. good to know for the future21:42
*** raildo has quit IRC21:44
openstackgerritRichard Avelar proposed openstack/keystone master: Validate rolling upgrade is run in order
*** thorst has quit IRC22:02
*** thorst has joined #openstack-keystone22:03
*** chlong has quit IRC22:03
*** david-lyle has quit IRC22:04
*** david-lyle has joined #openstack-keystone22:05
*** thorst has quit IRC22:07
*** aojea has quit IRC22:13
*** aojea has joined #openstack-keystone22:13
*** aojea has quit IRC22:18
*** amrith has left #openstack-keystone22:20
*** lamt has quit IRC22:36
*** edmondsw has joined #openstack-keystone22:47
*** thorst has joined #openstack-keystone22:50
*** lucasxu has quit IRC22:51
*** edmondsw has quit IRC22:52
*** markvoelker has joined #openstack-keystone22:52
*** thorst has quit IRC22:53
*** agrebennikov has quit IRC22:53
*** thorst has joined #openstack-keystone23:24
*** nkinder has quit IRC23:36
*** thorst has quit IRC23:39

Generated by 2.14.0 by Marius Gedminas - find it at!