Tuesday, 2015-07-28

*** topol has quit IRC00:08
*** markvoelker has joined #openstack-keystone00:09
*** dims has quit IRC00:22
*** snapdey has quit IRC00:30
*** jiaxi has quit IRC00:31
*** roxanaghe has quit IRC00:31
*** dims has joined #openstack-keystone00:32
*** snapdey has joined #openstack-keystone00:34
*** btully has quit IRC00:39
*** openstackgerrit has quit IRC00:46
*** openstackgerrit has joined #openstack-keystone00:47
*** lhcheng has quit IRC00:48
*** _cjones_ has quit IRC00:50
*** telemonster has quit IRC00:56
*** telemonster has joined #openstack-keystone00:57
*** david8hu has quit IRC00:59
*** lhcheng has joined #openstack-keystone01:06
*** ChanServ sets mode: +v lhcheng01:06
*** david8hu has joined #openstack-keystone01:17
*** davechen has joined #openstack-keystone01:18
*** btully has joined #openstack-keystone01:19
*** ankita_w_ has quit IRC01:20
*** snapdey has quit IRC01:22
*** davechen1 has joined #openstack-keystone01:24
*** btully has quit IRC01:24
*** davechen has quit IRC01:25
*** davechen1 is now known as davechen01:26
*** jasonsb has quit IRC01:28
*** topol has joined #openstack-keystone01:28
*** ChanServ sets mode: +v topol01:28
*** woodster_ has quit IRC01:34
*** jiaxi has joined #openstack-keystone01:39
jiaxiayoung: Hi01:39
jiaxiGood morning. Everyone01:40
jiaxiYou Americans go to bed so early ???01:41
*** mylu has joined #openstack-keystone01:41
davechendstanek: ping david?01:54
davechenjiaxi: you are funny. :-D01:55
jiaxidavechen:  为什么。 你才funny呢01:55
jiaxi哈哈01:55
jiaxi他们老外应该都睡觉了01:56
*** mylu has quit IRC01:56
jiaxidavechen: https://review.openstack.org/#/c/200512/  帮为review一下呀。01:56
davechenjiaxi: sure, why using native language?01:58
*** jlvillal has quit IRC01:58
jamielennoxjiaxi: reviewd01:58
davechenjiaxi: ayoung may need transilate in the google again. :)01:58
jiaxidavechen: You are not chinese ?01:58
*** cloudnull is now known as cloudnull_afk01:58
jiaxidavechen: ayoung is naught.01:59
davechenjiaxi: I agree. :)01:59
ayoungUm01:59
ayoungI think you should look up the meaning of the word naught01:59
ayoungI think you jkust meant "not"01:59
jiaxijamielennox: Thank you.01:59
davechenabsolutly right. :)01:59
*** jlvillal has joined #openstack-keystone01:59
jamielennoxjiaxi: that's the first time i've looked at it and i didn't read the histor y so hopefully it's not against what's been said already02:00
ayoungjamielennox, I had +2ed, buyt dstanek had some comments strong enough to warrant a -1, was going to let him come back around on it02:00
jiaxijamielennox: Okay, I will think about it02:01
davechenjiaxi, ayoung is will be mad at you.02:01
dstanekdavechen: pong02:01
davechendstanek: hi boss, good evening.02:01
ayoungjamielennox, V2.0 is not yet marked as deprecated, right?02:01
davechendstanek: I will fix those nits shortly.02:02
jamielennoxayoung, jiaxi: i just don't think you should remove the test02:02
jamielennoxthe others are just preference02:02
ayoungjamielennox, yeah, fair enough.02:02
davechendstanek: but not quite sure how to address one of your comments.02:02
jiaxijamielennox: I should remove .  You didn't see the commit log ??02:02
jamielennoxjiaxi: there's a lot of history there, no i didn't read the comments02:03
jamielennoxhey, reviews cracked the 200000 mark, hadn't noticed that02:03
davechendstanek: so, you meant we should investigate more in the validation and let schema validation to capture the empty body, am i right?02:03
dstanekjiaxi: something i just noticed about your review. when i said to do the % operator and catch the KeyError...well there are other exceptions possible that you probably need to catch02:04
jiaxidavechen: He means empty or null is okey when the agrument is optional.02:04
dstanekjiaxi: ValueError for sure since '%(x)" % {'x': 0} would lead to that02:05
davechenjiaxi: we are talking different things.02:05
dstanekjiaxi: i think i wrote code in the catalo to protect against this...i'll find it02:05
jiaxidstanek: For example ?02:05
davechenjiaxi, dstanek, I am talking my patch. :)02:05
dstanekdavechen: is an {} always bad?02:06
jiaxidavechen: Okay, you won02:06
davechendstanek: I think so, this is what the bug want to address.02:06
dstanekdavechen: the bug if for a missing body right? not an empty one02:07
*** stevemar has joined #openstack-keystone02:07
*** ChanServ sets mode: +v stevemar02:07
*** dolphm has quit IRC02:07
*** d34dh0r53 has quit IRC02:07
*** sigmavirus24 has quit IRC02:07
*** eglute has quit IRC02:07
*** cloudnull_afk has quit IRC02:07
davechendstanek: it's also about the emtpy body. iirc, there is some desc about the empty body as well.02:07
jiaxijamielennox: Jamie Lennox9:58 AM nit: could have put this in catalog/utils.py or somewhere else as it's not going to be required by all the backends. If you put it in catalog/core.py then you wouldn't need to pass the whitelist in.02:08
*** d34dh0r53 has joined #openstack-keystone02:08
*** d34dh0r53 has quit IRC02:08
davechendstanek: https://bugs.launchpad.net/keystone/+bug/1466872, talk something about the empty body.02:08
openstackLaunchpad bug 1466872 in Keystone "v3 - Ambiguous error when no request body is provided for updating service" [Medium,In progress] - Assigned to Dave Chen (wei-d-chen)02:08
*** d34dh0r53 has joined #openstack-keystone02:08
dstanekjiaxi: the excepts here show all of the different types of failures you can get http://git.openstack.org/cgit/openstack/keystone/tree/keystone/catalog/core.py#n6002:09
*** eglute has joined #openstack-keystone02:09
*** dolphm has joined #openstack-keystone02:09
davechendstanek: when the body is empty, the message is not friendly as well.02:09
jiaxijamielennox: I have the check in clean.py, but davechen want me to put it in utils.py. And now you want me to put it in core.py ???????????           What should I listen to ?02:09
*** d34dh0r53 has quit IRC02:09
*** dolphm has quit IRC02:09
*** eglute has quit IRC02:09
davechenjiaxi: of course, you should belive in cores' comments.02:10
*** d34dh0r53 has joined #openstack-keystone02:10
jamielennoxjiaxi: reviewing is a lot of personal preference, generally we put in nit: to mean this is a small thing i would change but i'm not going to hold up the review for it02:10
davechenjiaxi: my review is not such important somhow.02:10
dstanekdavechen: what's the error message for an empty body? the missing body is a 500 right?02:10
jiaxidavechen: Okay, you won again.02:10
*** dolphm has joined #openstack-keystone02:10
*** eglute has joined #openstack-keystone02:10
davechen    "error": {02:10
davechen        "message": "{} does not have enough properties",02:10
davechen        "code": 400,02:10
davechen        "title": "Bad Request"02:10
jamielennoxjiaxi: so i would put it in core.py because i don't think you need to pass whitelist because that won't ever change, but its not worth a -102:11
jamielennoxremoving the old test is the only thing i -1ed for02:11
jiaxijamielennox: Okay, you are right02:11
jiaxijamielennox: What about the wrong test ??? Have a look at the commit log please ?02:12
lhcheng\o/ finally got the tokenless auth running in my devstack02:12
dstanekjamielennox: yeah, i mentioned not removing the test.02:12
davechendstanek: the reporter complain about this message as well, but if you think it's okay, I am okay too. :)02:12
dstanekdavechen: that's not a great message, but at least it's a 400 :-)02:12
dstanekdavechen: looks like that message is straight out of jsonschema02:13
davechendstanek: you are right, it's from jsonschema.02:13
jamielennoxjiaxi: that doesn't mean that there aren't old endpoints with spaces that already exist that might need to be removed in future02:13
davechendstanek: the only way i can see is capture it before the emtpy body go to jsonschema.02:14
jamielennoxjiaxi: the ability to delete those endpoints still exists, we didn't remove that functionality from keystone, so the test is ensuring for future that we don't break that old behaviour02:14
jiaxidstanek: So if I don't delete the old test. The url with space in it  will be valid ......02:14
jamielennoxthere is a lot of unit testing that ensures edge cases that we never remove even though they shouldn't be triggered02:15
dstanekdavechen: i would make them 2 separate commits anyway; 1 to fix the bug and another to catch (and fix) the strange error message02:15
dstanekjiaxi: why would it still be valid? the controller won't let new ones in02:15
jiaxijamielennox: so in patch set. A space in url is valid ?????02:16
jamielennoxjiaxi: ah - if you have to remove it because the old test breaks then that's different02:16
dstanekjamielennox: jiaxi: you just need to add it through the Python API02:16
jamielennoxright, you should be able to change the old test to add via the manager directly02:17
jiaxidstanek: what does ' the controller won't let new ones in' mean'        if a url with space is invalid.. The old test case that deleted by me will not succeed02:17
dstanekjiaxi: that is because it uses the REST API. the manager (Python API) can still be used to add an invalid URL to the database02:18
davechendstanek: but I don't see anything terrible in the current fixing, captch the empty body and show some message and let jsonschem do this and show some error message we are not quite understanding, which one is better?02:19
jiaxidstanek: I don't understand well. Give me a demo ?02:19
dstanekdavechen: i'm just worried that an empty body is or could be valid02:20
dstanekdavechen: are you checking for empty bodies on a DELETE or PUT?02:21
davechendstanek: from the validation itself, this is not allowed i am afraid.02:21
jiaxijamielennox: change the old test? to what purpose ?02:21
davechendstanek: all of them will go to the validation when the body is passing, so the current fixing will address them all.02:21
dstanekjiaxi: to add the invalid URL using the manager code and not the REST API02:21
dstanekdavechen: but DELETEs don't have a body - is that allowed?02:22
jiaxidstanek: Okay, got it.02:22
davechendstanek: yes, no body, nothing to fix.02:22
dstanekdavechen: which review is this?02:22
davechendstanek: delete API has no body, so there is nothing about this bug, am i right?02:24
dstanekdavechen: the way i read the code is that you had to have a body02:24
*** chenhong has joined #openstack-keystone02:25
davechendstanek: great, this might be a issue, let me check it again.02:25
dstanekdavechen: GETs never have a body and we have at least 1 PUT that doesn't have a body02:26
dstaneki would have expected the v3 tests to fail though. so i'm curious to dig is and see what is happening02:26
dstanekdavechen: what's the review number?02:26
davechendstanek: 195903 ?02:27
davechendstanek: if this is the case, why all of the testcase passed.02:28
davechendstanek: interesting, maybe more negative testcase is needed here.02:28
dstanekdavechen: so it's likely because we don't protect them with the validated decorator. so the question is whether or not an empty body is valid for any of our APIs02:29
davechenseem from the current logic, it's not allowed.02:30
dstanekdavechen: what logic prevents it?02:30
davechendstanek: but it's arguable.02:30
davechendstanek: jsonschema itself will not allowed to do this, since there is no schem will nothing in it, this is not make sense.02:31
davechenschem will nothing/schema with nothing02:31
davechentoo many typos.02:31
dstanekdavechen: i'm looking through our schemas now - it's possible to have one with all optional properties02:31
davechendstanek: yeah, i will look into too, if that is indeed allowed, we can do some differentiation.02:32
dstaneklooks like maybe service provider can be empty02:33
davechendstanek: thanks David, take a lot time from you. I02:33
dstanekdavechen: yw. i have lots of time :-)02:34
davechendstanek: really!!02:34
davechendstanek: don't tell me you are off-duty already.02:34
davechendstanek: btw, do you hear something about the collorbration between intel and rackspace.02:35
davechendstanek: maybe a good chance for me to work with you. :)02:35
*** dims has quit IRC02:35
*** jasonsb has joined #openstack-keystone02:36
dstanekdavechen: yes, it sounds pretty cool02:36
dstanekdavechen: will you be onsite?02:37
davechendstanek: depend on whether you jamielennnox or lance are there, looks like more about the operators and bug fixing. :)02:38
*** mylu has joined #openstack-keystone02:44
*** mylu has quit IRC02:45
*** lhcheng has quit IRC02:48
*** hakimo_ has joined #openstack-keystone02:52
*** hakimo has quit IRC02:54
*** stevemar has quit IRC03:01
*** chmouel_ has joined #openstack-keystone03:03
*** chmouel- has joined #openstack-keystone03:04
*** chmouel| has joined #openstack-keystone03:04
*** chmouel^ has joined #openstack-keystone03:05
*** richm has quit IRC03:08
*** chmouel^ has quit IRC03:10
*** chmouel- has quit IRC03:10
*** chmouel_ has quit IRC03:10
*** chmouel| has quit IRC03:10
*** chmouel has quit IRC03:10
*** chmouel has joined #openstack-keystone03:11
*** lhcheng has joined #openstack-keystone03:18
*** ChanServ sets mode: +v lhcheng03:18
*** Kennan2 has quit IRC03:20
*** Kennan has joined #openstack-keystone03:20
*** kiran-r has joined #openstack-keystone03:34
*** kiran-r has quit IRC03:40
*** stevemar has joined #openstack-keystone03:50
*** ChanServ sets mode: +v stevemar03:50
*** htruta_ has quit IRC03:50
*** stevemar has quit IRC03:52
*** ayoung has quit IRC03:58
openstackgerritjiaxi proposed openstack/keystone: Reject create endpoint with invalid urls  https://review.openstack.org/20051204:02
*** markvoelker has quit IRC04:04
*** lhcheng has quit IRC04:07
*** btully has joined #openstack-keystone04:11
*** spandhe has quit IRC04:12
*** ankita_wagh has joined #openstack-keystone04:54
*** markvoelker has joined #openstack-keystone05:05
*** markvoelker has quit IRC05:10
*** Nirupama has joined #openstack-keystone05:12
*** ankita_wagh has quit IRC05:12
*** ankita_wagh has joined #openstack-keystone05:13
*** yottatsa has joined #openstack-keystone05:14
*** e0ne has joined #openstack-keystone05:14
*** ankita_wagh has quit IRC05:17
*** hrou has quit IRC05:27
*** ankita_wagh has joined #openstack-keystone05:29
*** pnavarro has joined #openstack-keystone05:35
*** e0ne has quit IRC05:42
*** e0ne has joined #openstack-keystone05:44
jamielennoxjiaxi: commented on your review05:49
*** e0ne has quit IRC05:51
jiaxijamielennox: ok ,thanks. It's too late in US.  And you are not in US ?05:52
*** jamielennox is now known as jamielennox|away05:52
*** topol has quit IRC05:54
*** e0ne has joined #openstack-keystone05:55
*** lhcheng has joined #openstack-keystone05:56
*** ChanServ sets mode: +v lhcheng05:56
*** jamielennox|away is now known as jamielennox05:56
jamielennoxjiaxi: no. i'm in australia05:58
openstackgerritjiaxi proposed openstack/keystone: Reject create endpoint with invalid urls  https://review.openstack.org/20051205:58
jiaxijamielennox: Good place .  I have updated it .05:59
*** albertom has quit IRC06:01
*** albertom has joined #openstack-keystone06:09
*** jsheeren has joined #openstack-keystone06:11
*** jsheeren has quit IRC06:12
*** e0ne has quit IRC06:13
*** lhcheng has quit IRC06:17
*** chlong has quit IRC06:17
*** belmoreira has joined #openstack-keystone06:25
*** spandhe has joined #openstack-keystone06:25
*** afazekas has joined #openstack-keystone06:44
-openstackstatus- NOTICE: zuul is stuck and about to undergo an emergency restart, please be patient as job results may take a long time06:46
*** ChanServ changes topic to "zuul is stuck and about to undergo an emergency restart, please be patient as job results may take a long time"06:46
*** lhcheng has joined #openstack-keystone06:50
*** ChanServ sets mode: +v lhcheng06:50
*** btully has quit IRC06:52
*** Nirupama has quit IRC06:52
*** spandhe has quit IRC06:57
*** henrynash has joined #openstack-keystone07:04
*** ChanServ sets mode: +v henrynash07:04
*** markvoelker has joined #openstack-keystone07:06
*** pnavarro has quit IRC07:08
*** ankita_wagh has quit IRC07:09
*** ankita_wagh has joined #openstack-keystone07:09
*** markvoelker has quit IRC07:11
*** ankita_wagh has quit IRC07:14
*** fhubik has joined #openstack-keystone07:32
*** browne has quit IRC07:35
*** e0ne has joined #openstack-keystone07:37
*** ajayaa has joined #openstack-keystone07:40
*** lhcheng has quit IRC07:43
*** Nirupama has joined #openstack-keystone07:48
*** yottatsa has quit IRC07:50
*** pnavarro has joined #openstack-keystone07:54
*** ChanServ changes topic to "Liberty-2 this week! Land Code! | MidCycle Etherpad: https://etherpad.openstack.org/p/keystone-liberty-midcycle-meetup"08:02
-openstackstatus- NOTICE: zuul has been restarted and queues restored. It may take some time to work through the backlog.08:02
*** jistr has joined #openstack-keystone08:03
*** henrynash has quit IRC08:05
*** henrynash has joined #openstack-keystone08:06
*** ChanServ sets mode: +v henrynash08:06
*** henrynash has quit IRC08:06
*** topol has joined #openstack-keystone08:06
*** ChanServ sets mode: +v topol08:06
*** topol has quit IRC08:10
*** fhubik is now known as fhubik_afk08:12
*** evrardjp has joined #openstack-keystone08:16
*** fhubik_afk is now known as fhubik08:29
*** yottatsa has joined #openstack-keystone08:41
*** aix has joined #openstack-keystone08:45
*** Nirupama has quit IRC08:54
*** Nirupama has joined #openstack-keystone08:55
*** yottatsa has quit IRC09:01
openstackgerritMarek Denis proposed openstack/keystone: Fernet payloads for federated scoped tokens.  https://review.openstack.org/20217609:01
*** markvoelker has joined #openstack-keystone09:07
*** boris-42 has quit IRC09:10
*** markvoelker has quit IRC09:11
*** henrynash has joined #openstack-keystone09:23
*** ChanServ sets mode: +v henrynash09:23
*** davechen has left #openstack-keystone09:52
*** aix has quit IRC09:55
*** haypo has joined #openstack-keystone09:57
*** henrynash has quit IRC10:04
*** yottatsa has joined #openstack-keystone10:05
*** henrynash has joined #openstack-keystone10:08
*** ChanServ sets mode: +v henrynash10:08
openstackgerritMerged openstack/keystone: Updating sample configuration file  https://review.openstack.org/20622310:18
*** aix has joined #openstack-keystone10:22
*** dims has joined #openstack-keystone10:31
openstackgerritAlexey Miroshkin proposed openstack/keystone: Test admin app in test_admin_version_v3  https://review.openstack.org/20647210:36
*** bradjones has quit IRC10:41
*** henrynash has quit IRC10:48
*** chenhong has quit IRC10:55
*** fhubik is now known as fhubik_afk10:55
*** markvoelker has joined #openstack-keystone11:08
*** markvoelker has quit IRC11:13
openstackgerritAlexey Miroshkin proposed openstack/keystone: Fix test_admin to expect admin endpoint  https://review.openstack.org/20649611:23
*** amakarov_away is now known as amakarov11:25
*** fhubik_afk is now known as fhubik11:35
*** jaosorior has joined #openstack-keystone11:37
*** jiaxi has quit IRC11:45
samueldmqjamielennox: hi, you still around ? we need an advice on how to discover keystone url + version from the service catalog inside cinder service :-)11:48
samueldmqericksonsantos: cc ^11:48
jamielennoxsamueldmq: just caught me, what's up11:48
samueldmqjamielennox: so for hierarchical quotas, once we get a token we need to retrieve its hierarchy from keystone, right ?11:49
samueldmqjamielennox: that way, the only information we have in hands is the token11:49
samueldmqjamielennox: and we need to discover keystone url + if the version is v3 and then supports hierarchical projects, to then be able to make the appropriate calll11:49
jamielennoxsamueldmq: i'm not completely up to date on how much information will be available within the token data11:49
jamielennoxsamueldmq: that auth_token middleware would be able to pass through11:50
jamielennoxi would hope that auth_token middleware can handle most of it because we don't really want every service to have to go through the same process of fetching the project hierarchy11:50
samueldmqjamielennox: yeah. but I remember of something like : 'services don't trust what auth_token say'.. because there is no encryption in the communication, or something like that11:50
jamielennoxsamueldmq: i've never heard that argument, service _must_ trust what auth_token midddleware tells them, that's how they determine the user, and roles etc11:51
samueldmqjamielennox: how does auth_token tells the service the info ?11:51
samueldmqjamielennox: env vars ?11:52
jamielennoxit's also way more likely that auth_token is going to have implemented it correctly, particularly based on how bad service-> service communication is11:52
jamielennoxsamueldmq: yes, we are adding an object that can be passed down but that is also passed through environ11:52
samueldmqjamielennox: how does the service knows it was the middleware who set those env vars ? anyway, that's not what's on the table now :)11:53
samueldmqjamielennox: putting that in auth_token means that every api call would retrieve the hierarchy11:53
samueldmqjamielennox: but not all api calls need the hierarchy ..11:53
samueldmqwe only know if we'll need thta info inside the service when we know what call we're making11:53
jamielennoxsamueldmq: there's really no way to know it was auth_token who set the environ variables, and that's kind of on purpose because it would be perfectly legitimate for another middleware to manipulate those values11:55
jamielennoxbut all of this is happening within the process, it's not like there is some way you could inject different environment variables from outside11:56
jamielennoxit's a matter of configuration11:56
jamielennoxalso it's not every API call that needs the service catalog, but we still include that within every token and it's much more burdensome than the project hierarchy11:58
samueldmqjamielennox: hmm, but in the case of hierarchy it will be only used for quota purposes, but I am considering your suggestion11:59
jamielennoxsamueldmq: i would really prefer we don't have services making what is going to be a really common call back to keystone in a hundred different ways12:02
samueldmqjamielennox: I wonder if, a day, we could map url_calls to what is needed for them, that way middleware could fetch the needed info12:03
samueldmqjamielennox: like for quota calls, I'd say nova will need to know the hierarchy, and then middleware fetches it for that case12:04
jamielennoxsamueldmq: i guess it depends on how often we expect services to need to resolve the hierarchy12:04
samueldmqjamielennox: maybe it will be possible if we put some part of the enforcement logic in the middleware (the roles enforcement only), then we'd know a list of apis .. etec12:04
jamielennoxif it's quota then i would guess that's for every create operation12:05
samueldmqjamielennox: for now it's only quota operations12:05
jamielennoxsamueldmq: right but quota gets checked when you create a vm, create an image, a snapshot whatever12:05
jamielennoxi'm not sure if it gets updated when you remove those things or not12:05
samueldmqjamielennox: actually when you create resources, you only touch the quota of that porject, so no need to get the hierarhcy12:06
samueldmqjamielennox: when you update its quota, however, you need to update parent's quota, that's all12:06
samueldmqericksonsantos: ^ right12:06
ericksonsantossamueldmq, ++12:06
samueldmq?12:06
ericksonsantosmakes sense12:06
jamielennoxit's stored cumulatively?12:07
samueldmqjamielennox: the parent know what quota portion is delegated to its children, that's all .. the children the care about their own children, and so on12:07
jamielennoxok...12:08
samueldmqjamielennox: like : "my quota is defined by waht I use + what I delegated to my children, it doesn't matter how they're using it .. "12:08
jamielennoxseems lacking but whateer12:08
*** yottatsa has quit IRC12:09
*** markvoelker has joined #openstack-keystone12:09
jamielennoxit implies that you delegate quota ahead of time rather than just my quota is everything i'm using + my children12:09
*** fhubik is now known as fhubik_afk12:09
*** fhubik_afk is now known as fhubik_eng12:09
jamielennoxnot the point i guess12:09
samueldmqjamielennox: yeah you delegate the quota, as you have your own12:09
samueldmqjamielennox: you 'allocate' the cquota ahead of time12:09
*** yottatsa has joined #openstack-keystone12:10
jamielennoxok12:10
jamielennoxso what's the issue how to use keystoneclient to do that?12:10
samueldmqjamielennox: know keystone url ..12:11
samueldmqjamielennox: that's where I asked your advice12:11
samueldmqjamielennox: also we need to check if the url is v3 :)12:11
*** topol has joined #openstack-keystone12:11
*** ChanServ sets mode: +v topol12:11
jamielennoxyou shouldn't12:11
*** gordc has joined #openstack-keystone12:11
*** iurygregory has joined #openstack-keystone12:11
samueldmqjamielennox: so how do I do that ?12:11
jamielennoxmake a session, don't know how, attach the plugin that is passed down from auth_token middleware12:11
jamielennoxor you might have to create one from context, i don't know how far cinder got with that12:12
samueldmqjamielennox: hmmmmm , so auth_token passes the plugin ? how does it pass that ?12:12
jamielennoxenv['keystone.token_auth'] i think12:12
samueldmqjamielennox: do you have any example of that anywhere ? also we need fallback to the 'manual' instantiation if it isn't possibel to get a plugin12:13
samueldmqjamielennox: or should the plugin always be available ?12:13
*** raildo has joined #openstack-keystone12:13
jamielennoxsamueldmq: auth_token passes down the plugin, but most of these operations don't happen from the -api service that has auth_token running they use the context12:13
*** markvoelker has quit IRC12:14
jamielennoxand we don't serialize that plugin into the context yet12:14
jamielennoxi need to get back to that12:14
samueldmqjamielennox: I could simply look at the auth_token section of the config ..12:14
samueldmqjamielennox: and instantiate the ksclient .. is that what you're saying all the time ? :)12:14
jamielennoxsamueldmq: morganfainberg sent another email about this, services should not touch the auth_token config section12:15
jamielennoxassume it doesn't exist12:15
jamielennoxyou can get the keystone url from the service catalog12:15
jamielennoxand the plugins will do that for you12:15
samueldmqjamielennox: ok it never existed to me anyway :B12:15
jamielennoxi just don't know how cinder works internally if the plugin is there12:15
samueldmqjamielennox: is there any documentation about such plugins ? I am not familiar with that12:15
jamielennoxsamueldmq: i'm not sure https://github.com/openstack/nova/blob/master/nova/context.py#L37 is the one nova creates12:16
jamielennoxi don't know what cinder does internally12:16
jamielennoxhttps://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L164 is where it is defined in passing down12:17
samueldmqjamielennox: nice, thansk for the links, they'll very helpful :)12:18
samueldmqjamielennox: we'll look at how to get that inside cinder12:18
jamielennoxsamueldmq: find me again tomorrow we can chat some more, i need to sleep - the keystone meeting is not far away12:19
ericksonsantosjamielennox, thanks12:19
jamielennoxnp12:19
samueldmqjamielennox: great thanks, sleep well :)12:19
*** josecastroleon has joined #openstack-keystone12:22
*** jiaxi has joined #openstack-keystone12:23
*** mestery has joined #openstack-keystone12:27
*** diegoadolfo has joined #openstack-keystone12:27
*** jiaxi has quit IRC12:28
*** markvoelker has joined #openstack-keystone12:29
*** bknudson has joined #openstack-keystone12:30
*** ChanServ sets mode: +v bknudson12:30
*** stevemar has joined #openstack-keystone12:31
*** ChanServ sets mode: +v stevemar12:31
*** edmondsw has joined #openstack-keystone12:33
*** stevemar has quit IRC12:38
*** stevemar has joined #openstack-keystone12:45
*** ChanServ sets mode: +v stevemar12:45
*** btully has joined #openstack-keystone12:56
*** gordc is now known as gordc_meeting12:56
odyssey4mejamielennox it seems that you and I are working through a similar issue12:57
samueldmqodyssey4me: I think jamielennox is sleeping :)12:57
odyssey4meah, ok12:58
*** bknudson has quit IRC12:59
*** btully has quit IRC13:00
*** afazekas has quit IRC13:02
*** henrynash has joined #openstack-keystone13:03
*** ChanServ sets mode: +v henrynash13:03
*** jsavak has joined #openstack-keystone13:04
*** TheIntern has joined #openstack-keystone13:13
*** jiaxi has joined #openstack-keystone13:14
*** edmondsw has quit IRC13:14
jiaxidstanek: Hello, David. Did you get up ?13:14
dstanekjiaxi: hello, yep13:14
dstanekjiaxi: it's 9am here so i've been up for a while13:15
*** hrou has joined #openstack-keystone13:15
jiaxidstanek: I'm surprised.13:15
*** rdo has quit IRC13:15
dstanekjiaxi: why's that?13:15
jiaxiAfter many many hours, Jenkins didn't give me +113:16
*** zzzeek has joined #openstack-keystone13:17
jiaxidstanek: Did't give any response ? Was the jenkins sick ?13:17
dstanekjiaxi: it's having problems right now and it catching back up13:17
jiaxidstanek: Okay, I think it's time for +2 now. Please have a look at it.13:18
jiaxidstanek: Jekins will give +1. Because I run tox successfully.13:18
jiaxihttps://review.openstack.org/#/c/200512/13:18
*** browne has joined #openstack-keystone13:19
jiaxiIn China, We will pay for using google.13:19
*** mylu has joined #openstack-keystone13:19
henrynashjiaxi: I’ve taken it…and asked for more info….I can’t see the issue right now13:20
jiaxihenrynash: Why ?13:20
*** bknudson has joined #openstack-keystone13:20
*** ChanServ sets mode: +v bknudson13:20
henrynashjiaxi: why, what? :-)13:21
jiaxihenrynash: Nearly 8 hours . Jekins is still running? Or didn't run ever.13:21
samueldmqhenrynash: hi, good morning sir :)13:21
samueldmqhenrynash: just replied your comment in https://review.openstack.org/#/c/134655/13:21
henrynashjiaxi: sorry, we are probably talking at cross purposes….I was talking about the big report13:22
jiaxihenrynash: https://review.openstack.org/#/c/200512/   Jenkins didn't test my patch set13:22
samueldmqhenrynash: endpoint_ids is a config as any other, but that is a list (multiple values), like : endpoint_ids=id1,id2,id313:22
henrynashsamueldmq: Ok, so I’m probably just being dumb, but I still down’t get what it is for13:22
henrynashsamuedlmq: why do we need it13:22
samueldmqhenrynash: no you're not being dumb13:22
henrynashsamuedlmq: (believe me, it happens plenty!)13:23
jiaxihenrynash: Okay, hurry up.  Come on13:23
samueldmqhenrynash: endpoint policy extension associate policies with endpoints by their ids, right ?13:23
henrynashsamueldmq: yes (or to their service type and/or region)13:23
samueldmqhenrynash: so the endpoint need to know what ids represent it in the keystoene server13:23
samueldmqhenrynash: yes, but the lower level is id13:23
henrynashsamueldmq: OH….so this is instead of mapping url to id?13:24
samueldmqhenrynash: once the sevice endpoint knows who it is, it will say to keystone :'hey I am X, gimme my policy"13:24
jiaxisamueldmq: Hi, sir. My another patch has got a +2.  But needs anothor +2    https://review.openstack.org/#/c/203312/               A very easy one.13:24
samueldmqhenrynash: we'll add url to id later, as input to that config, but we need to allow that to be set directly as the first step13:24
samueldmqjiaxi: I am not allowed to +2 it13:25
henrynashand is this in the endpoint’s project config (e.g. nova.conf) or in the keystone.conf13:25
samueldmqjiaxi: I am not a keystone core, sorry13:25
jiaxihenrynash:samueldmq: What question are you talking about ?13:25
samueldmqhenrynash: as i t will identify the endpoints, it will be in the middleware config of each service13:25
samueldmqhenrynash: in the [keystone_authtoker] of the service config13:26
jiaxisamueldmq: Maybe +1   It's openstackclient. Not keystone13:26
samueldmqjiaxi: will take a look in a bit :)13:26
henrynashsamueldmq: the middleware config of each services…..thinking…..now I am being dumb…what’s the “middleware of each service”?13:26
dstanekjiaxi: jenkins is running behind because it had problems last night13:27
samueldmqhenrynash: in the service pipeline, they deploy ksmiddleware, that receives the requests before the service itself receives it13:27
samueldmqhenrynash: that's clear, right ?13:27
jiaxidstanek: Okay.13:28
samueldmqhenrynash: from the endpoint pov, knowing who it is will serve for 2 purposes: i) fetch my policy from the server13:28
henrynashsamueldmq: …. so they need to set a different setting in each keystone middleware config file  dependiing on the service?  this is clear as mud from the spec13:28
samueldmqhenrynash: ii) enforce endpoint constraint, which is gyee's work13:28
samueldmqhenrynash: basically yes, but for multiple processes behind a proxy, they are the same endpoint entity in keystone server13:29
samueldmqhenrynash: so they'd get teh same ids13:29
jiaxidstanek: Are you still core of openstackclient, David ?13:29
henrynashsamueldmq: and why is this better than having a url to id lookup?13:30
samueldmqhenrynash: we will provide the url -> lookup in a follow on work, but that doesn't work in all the case13:31
samueldmqs13:31
samueldmqhenrynash: let me clarify :13:31
samueldmqhenrynash: suppose ssl is being used, and in a given topology, the used url gets re-written at the ssl termination (maybe a proxy) .. so the endpoint will get a different url than what we have in the catalog13:32
samueldmqhenrynash: so we can't resolve url -> id, right ?13:32
samueldmqhenrynash: if the deployer is doing the sort of thing, he will need to set the ids directly in the config13:32
henrynashsamueldmq: ok, yep can see that issue...but13:32
samueldmqhenrynash: https://review.openstack.org/#/c/134655/15/specs/backlog/dynamic-policies-fetch-cache.rst13:32
henrynashsamueldmq: I really don’t udnerstand this sentenace: “so the endpoint need to know what ids represent it in the keystoene serve”13:32
samueldmqhenrynash: L 201 - 20413:32
samueldmqhenrynash: ok so a running service endpoint can have multiple urls in keystone, as an entity13:33
henrynashsamueldmq: the endpoint has more than one id in the keystones serve?13:33
samueldmqhenrynash: public, internal and amdin interfaces13:33
samueldmqhenrynash: so multiple ids13:33
samueldmqhenrynash: yeeeeeeeeees, and that model is bad imo13:33
openstackgerritMarek Denis proposed openstack/keystone: Fernet payloads for federated scoped tokens.  https://review.openstack.org/20217613:33
samueldmqhenrynash: in v2 different interfaces had a single id, in v3 they are different ids13:33
samueldmqhenrynash: I don't like that at all13:34
dstanekjiaxi: no, what's up?13:34
jiaxidstanek: A very easy patch set.  Got a +2. But the other cores are offline for a very very long time.  https://review.openstack.org/#/c/203312/13:35
henrynashsamueldmq: I guess conceptually that does make sense…..(although definitely complicates things)13:36
samueldmqhenrynash: yeah that complicates things ...13:36
samueldmqhenrynash: there was a bug I saw another day13:36
samueldmqhenrynash: that enpoints registered with v3 couldn't be seen with v213:36
henrynashsamueldmq: Ok, so now at least I understand why we need this thing13:36
samueldmqhenrynash: you know why ? because there is no way to map multiple dids back to a single one (a single endpoint entity)13:37
samueldmqhenrynash: yeah, we can fix the endpoint model later, if needed, but that's a separate issue13:37
dstanekjiaxi: i'm not sure i understand the commit message13:37
jiaxidstanek: You are the top coder of the world.....13:38
jiaxidstanek: Just +1. Needn't understand ...13:38
jiaxidstanek: :)13:38
dstanekjiaxi: i can't +1 if i don't understand :-P13:38
openstackgerritLance Bragstad proposed openstack/keystone: Refactor _supports_bind method  https://review.openstack.org/19769913:39
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Fetch and Cache  https://review.openstack.org/13465513:39
*** btully has joined #openstack-keystone13:39
samueldmqhenrynash: look at it now, I added a sentence clarifying we need to define that for each service endpoint ^13:40
dstanekjiaxi: i'll take a look in a little bit; i don't have that code checked out for reference13:41
jiaxidstanek: Okay13:42
*** Nirupama has quit IRC13:45
*** jsavak has quit IRC13:47
*** fhubik_eng is now known as fhubik13:49
marekdodyssey4me: Hey!13:49
marekdodyssey4me: Can you fetch this patch https://review.openstack.org/#/c/202176 and see if it works in your case? This should solve https://bugs.launchpad.net/keystone/+bug/147128913:50
openstackLaunchpad bug 1471289 in Keystone "Fernet tokens and Federated Identities result in token scope failures" [High,In progress] - Assigned to Marek Denis (marek-denis)13:50
*** stevemar has quit IRC13:50
marekdit worked on my env13:50
openstackgerritDave Chen proposed openstack/keystone: Show helpful message when request body is not provided  https://review.openstack.org/19590313:50
*** jsavak has joined #openstack-keystone13:51
*** belmoreira has quit IRC13:51
*** edmondsw has joined #openstack-keystone13:51
marekdmorganfainberg: how bad is the fact that I just started keeping groups in scoped federated fernet tokens?13:54
openstackgerritDave Chen proposed openstack/keystone: Show helpful message when request body is not provided  https://review.openstack.org/19590313:55
*** jsavak has quit IRC13:56
*** jsavak has joined #openstack-keystone13:56
odyssey4memarekd great, I'll give it a try13:56
*** sigmavirus24_awa has joined #openstack-keystone13:57
marekdodyssey4me: i might have missed some corner cases, however it is unlikely13:57
*** stevemar has joined #openstack-keystone13:57
*** ChanServ sets mode: +v stevemar13:57
*** sigmavirus24_awa is now known as sigmavirus2413:57
*** ajayaa has quit IRC13:58
myluHi guys, the master branch of devstack is missing /ssl/ folder under /etc/keystone .... Last time I deployed devstack on Jul 13 and it was still there and I saw some commits to change keystone on Jul 14 ...13:58
*** stevemar has quit IRC14:02
*** chenhong has joined #openstack-keystone14:04
dstanekmylu: do you have a link to the commits?14:04
dstanekdo we document the endpoint url formatting anywhere?14:05
myludstanek: I saw the commit history on openstack-dev/devstack https://github.com/openstack-dev/devstack/commits/master?page=214:05
jiaxihenrynash: https://review.openstack.org/#/c/203312/ This patch is about compute quota, not volume quota. Volume quota can be set successfully. You can test it ?14:08
dstanekmylu: those two don't look like they have anything to do with ssl. is this on a new devstack or an existing one that the directory doesn't exist?14:08
myludstanek: the new one14:09
dstanekmylu: this is after a ./stack.sh?14:09
myludstanek: I deployed the working on on Jul 13 4pm14:09
myludstanek: yes. ./stack.sh run successfully14:09
myludstanek: also the new one doesn't have anything on the identity page on horizon14:10
dstanekmylu: are you using apache for keystone?14:10
myludstanek: yes14:10
*** boris-42 has joined #openstack-keystone14:10
jiaxihenrynash: Why didn't openstackclient channel exist ?14:10
dstanekmylu: not sure. you may want to ask in the QA channel - i think they are the ones that manage devstack14:10
myludstanek: ahh ok thanks!14:11
*** chenhong has quit IRC14:12
*** richm has joined #openstack-keystone14:14
*** jecarey_ has joined #openstack-keystone14:14
henrynashjiaxi: I agree it’s about compute quotas, but I don’t understand why the test should be different for compuet and volume….surely the voume quotas must be wrong too (and no, I don’t have a set up to test)….just looking at the code, it doesn’t look right14:16
jiaxihenrynash: why the test should be different for compuet and volume???  I have tested, the volume quota is ok. I can tell you why.14:19
henrynashjiaxi: please do!14:19
openstackgerritMarek Denis proposed openstack/keystone: Fernet payloads for federated scoped tokens.  https://review.openstack.org/20217614:19
jiaxiIn common/quota.py   COMPUTE_QUOTAS dict.   key ==value14:19
marekdlbragstad: dolphm ^^14:19
jiaxiSo when we use value as a key to get value, is ok14:20
jiaxihenrynash:  Because it runs okay, so there is no need to change it.14:20
jiaxiI have the test log in the launchpat14:21
henrynashjiaxi: you mean in the volume quotos dict key=value, or in the compuet one?14:22
jiaxiin volume14:22
jiaxihenrynash: in compute, some key = value, others not. but when you use key, all is fine.14:22
jiaxihttps://bugs.launchpad.net/keystone/+bug/1420104,  In the comment,  I have explained in details.14:23
openstackLaunchpad bug 1420104 in python-openstackclient "quota set failed" [Medium,In progress] - Assigned to jiaxi (tjxiter)14:23
henrynashjiaxi: ok, so teh volume code works due to luck!!! I wouldn’t say that means we should not change it.  You should rasie a bug (and mark it as a TODO in the code) to fix the volume test….surely the correct code should be checking on the key, no?14:23
henrynashjiaxi: in teh furture, someone might add a new key (that wasn’t equal to the value) and wouldn’t know to come and change that bit of code14:24
jiaxihenrynash: In dict, we tranfer value through the value. but use the key as a key to store value.14:25
jiaxihenrynash: So key should equal to value.  when ignore '-'  and '_'14:26
jiaxihenrynash: when use a-b-c 12 in command, then the value of a-b-c will be store as a_b_c = 1214:27
jiaxihenrynash: For this bug, we should only fix compute. The volume is okay. Maybe in the future, when the quota of volume increase and become complex , the problem will be triaged. But it's not now14:29
henrynashjiaxi: all seems very straneg to me…..14:30
openstackgerritMarek Denis proposed openstack/keystone: Skip rows with empty remote_ids  https://review.openstack.org/20656114:30
jiaxihenrynash: Do you agree with me?14:30
jiaxihenrynash: You can debug it. Then you will stand in my side.14:31
jiaxihenrynash: Please verify it use debug. Or use cmd.14:31
*** henrynash has quit IRC14:31
*** henrynash has joined #openstack-keystone14:32
*** ChanServ sets mode: +v henrynash14:32
jiaxihenrynash: Please read my comments in https://bugs.launchpad.net/keystone/+bug/142010414:33
openstackLaunchpad bug 1420104 in python-openstackclient "quota set failed" [Medium,In progress] - Assigned to jiaxi (tjxiter)14:33
*** ChanServ sets mode: +o dolphm14:35
*** stevemar has joined #openstack-keystone14:38
*** ChanServ sets mode: +v stevemar14:38
samueldmqis jenkins broken ?14:40
openstackgerritBoris Bobrov proposed openstack/keystone: Test function call result, not function object  https://review.openstack.org/20656714:41
dstanekjiaxi: i found a few things in that url review; i'll post some comments in a bit14:43
samueldmqdstanek: any chance to get one more review on #134655 and #197980 before meeting, so I could update them if needed14:45
samueldmqdstanek: they're the dynamic policy specs, one has a +2 from henrynash14:45
*** ajayaa has joined #openstack-keystone14:45
samueldmqdstanek: and I already addressed your comments (and dolphm's comments) from last week14:46
henrynashdstanek: the mark of death, surely14:46
*** stevemar has quit IRC14:46
dstaneksamueldmq: sure, i can look again14:46
dstanekhenrynash: :-P14:46
samueldmqdstanek: great thanks14:46
jiaxidstanek: Okey, Looking forward to your comments.14:46
samueldmqhenrynash: dstanek what does that mean ? dstanek will certainly -1 it ? :-)14:47
jiaxihenrynash: Have you read my comments in the launchpad ?14:47
henrynashsamueldmq: dstanek stares death in the face and doesn’t flinch….he’s that kind of core14:47
lbragstaddolphm: responded to your comment here https://review.openstack.org/#/c/196877/11/keystone/token/providers/common.py14:47
lbragstaddolphm: does that make sense?14:47
samueldmqhenrynash: hehe14:48
samueldmq++14:48
dolphmlbragstad: why is there a token ID in token ref only sometimes?14:50
dolphmlbragstad: again, feels like a bug if there's an inconsistency...14:50
lbragstaddolphm: agreed, I need to try and dig into the auth api to see what happens before the token provider api is called14:51
jiaxihenrynash: What do you think  about  https://review.openstack.org/#/c/203312/14:51
lbragstadby the time the token_ref hits the validate_v3_token method, it's already either a dict or a string.14:52
henrynashjiaxi: I have commented on it…in my view volume quota code is still (conceptually) incorrect, even if we get away with it right now14:52
*** jasonsb has quit IRC14:53
*** stevemar has joined #openstack-keystone14:54
*** ChanServ sets mode: +v stevemar14:54
jiaxihenrynash: I have replied it. I14:55
jiaxi henrynash: In face, I have explained this question to the other cores. Use the comments onlaunchpat , the comments on review, and the commit log.14:57
jiaxi henrynash: In face - > in fact14:57
dolphmlbragstad: it kind of baffles me that it would ever already be a dict -- isn't the point to convert it to a dict?14:58
dolphmlbragstad: string* to a dict14:58
*** woodster_ has joined #openstack-keystone14:58
jiaxi henrynash: dstanek:  Jenkins is terribly ill.  Give -1 to my patch. That's not right.14:59
lbragstaddolphm: me too, this doesn't seem to shed much light on it either. https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L53114:59
dstanekjiaxi: which patch?14:59
jiaxihttps://review.openstack.org/#/c/200512/14:59
*** diazjf has joined #openstack-keystone15:00
lbragstaddolphm: that's technically what gets passed in as a 'dict'15:00
openstackgerritRodrigo Duarte proposed openstack/keystone: Add is_domain in token response  https://review.openstack.org/19733115:00
openstackgerritRodrigo Duarte proposed openstack/keystone: Bye Bye Domain Table  https://review.openstack.org/16185415:00
openstackgerritRodrigo Duarte proposed openstack/keystone: Honor domain operations in project table  https://review.openstack.org/14376315:00
openstackgerritRodrigo Duarte proposed openstack/keystone: Change policy to comply with is_domain in token  https://review.openstack.org/20606315:00
openstackgerritRodrigo Duarte proposed openstack/keystone: Remove domain table references  https://review.openstack.org/16593615:00
lbragstador it's treated like a dict in token_provider_api.validate_v3_token()15:00
*** jsavak has quit IRC15:01
dolphmlbragstad: token_id should certainly be a string there15:02
lbragstaddolphm: I agree15:02
dolphmlbragstad: is it the v2 controller doing something odd?15:02
dolphmlbragstad: or HEAD vs GET?15:02
lbragstadlet me check15:02
dolphmlbragstad: or like auth_context calling validate for x-auth-token?15:03
*** henrynash has quit IRC15:03
*** jsavak has joined #openstack-keystone15:04
lbragstaddolphm: grepping doesn't give any results for 'validate_v2_token' under keystone/auth/15:04
dolphmlbragstad: keystone/token/controllers.py is where the v2 token stuff lives15:05
*** diegoadolfo has quit IRC15:07
*** amakarov is now known as amakarov_away15:11
*** gordc_meeting has quit IRC15:12
*** mylu has quit IRC15:13
dstaneklbragstad: dolphm: i did some unicode surgery on fernet tokens that i'll be pushing soon. i'd appreciate your eyes on it15:15
dolphmdstanek: sweet15:17
jiaxidstanek: https://review.openstack.org/#/c/200512/  my patch set. Please have a look. It's deep night in Beijing.15:17
dstanekjiaxi: yeah, i'm working on a revision to it now15:17
jiaxi dstanek: David. Before go to bed, I want to update my code according to your comments.15:18
*** mylu has joined #openstack-keystone15:18
jiaxidstanek: I go to have a bath for minutes. come back soon.15:19
lbragstaddstanek: will do15:20
*** ayoung has joined #openstack-keystone15:20
*** ChanServ sets mode: +v ayoung15:20
*** mestery has quit IRC15:20
*** TheIntern has quit IRC15:22
*** jsavak has quit IRC15:24
*** jsavak has joined #openstack-keystone15:25
*** TheIntern has joined #openstack-keystone15:25
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Fetch and Cache  https://review.openstack.org/13465515:28
lbragstaddolphm: figured it out -- https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L238-L24315:31
*** browne has quit IRC15:32
lbragstaddolphm: this token_id is always a string https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L52915:32
*** fhubik is now known as fhubik_afk15:33
*** topol has quit IRC15:33
*** topol has joined #openstack-keystone15:34
*** ChanServ sets mode: +v topol15:34
*** mestery has joined #openstack-keystone15:34
*** topol has quit IRC15:34
dolphmlbragstad: \o/ that whole method is super confusing15:35
ayoungbknudson, https://pypi.python.org/pypi/pyldap  is an attempt to get Py3 support in the existing python-ldap codebase.15:35
dolphmlbragstad: L232 should be moved into the else block...15:35
*** fhubik_afk is now known as fhubik15:35
dolphmlbragstad: so we're passing refs from the cache into validate token?15:36
dolphmlbragstad: maybe that should be a separate method call - like validate_cached_token() or something15:36
jiaxidstanek: Hello. David.15:36
ayoungdolphm, it can't be in the else block...defaults take over.  If the user explicitly requests and unscoped, it need to take precedence15:37
dolphmayoung: but it doesn't do anything with unique_id unless it's a persistent token?15:38
*** aix has quit IRC15:38
lbragstadcorrect15:38
lbragstaddolphm: what about it if we did something like15:38
dolphmlbragstad: maybe my notion of validate_cached_token() is what is actually implemented as _is_valid_token()15:38
ayoungdolphm, think I am lookuing at the wrong file.  THought you meant https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L23215:38
ayoungdolphm, I assume you actually meant https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L23215:39
dolphmlbragstad: what's the difference between token_ref and token there?15:39
dolphmayoung: ah, yeah. i'm looking at the code lance sent15:39
ayoungdolphm, you are correct, we should not pay the price for caluclateing the unique id there...but the logic should be that the unique id in the fernet case is the signature/hmac...so our logic is wonky15:40
*** pballand has joined #openstack-keystone15:40
lbragstadhttp://cdn.pasteraw.com/j7w55wmsv3zrv8diu8ve4c2p7tey1e15:41
*** josecastroleon has quit IRC15:41
dolphmlbragstad: is _validate_token_id() already a thing?15:41
lbragstaddolphm: here it is - https://review.openstack.org/#/c/196877/11/keystone/token/providers/common.py15:41
dolphmlbragstad: ah15:42
dolphmlbragstad: so that returns a token_ref?15:43
lbragstaddolphm: I could make those methods public (validate_token_id and validate_token_ref)15:43
lbragstadyeah15:43
lbragstadthey both use the v3_token_data_helper object to rebuild the reference15:43
dolphmlbragstad: somehow, the token_ref = token_id needs to go away15:43
lbragstadI agree.15:43
lbragstadI can hack something together and a new patch15:43
dolphmlbragstad: so, token_ref = self._validate_token_id(token_id) ?15:43
lbragstadyep15:44
dolphmlbragstad: okay, then i think that makes sense15:44
dolphmlbragstad: send another diff! or review15:44
lbragstaddolphm: I'll push a new patch15:44
*** stevemar has quit IRC15:44
*** gordc has joined #openstack-keystone15:45
jiaxidstanek: https://review.openstack.org/#/c/200512/.  I replied to your response. Hope for your reply.15:46
jiaxidstanek: Hi, David. I have replied to your comments. I think that you are a litter too serious.15:47
dolphmayoung: if you're interested in my raw data on the tree vs list benchmarking https://docs.google.com/spreadsheets/d/1fTnjP-1AoWfRpGw_3TWLx5DxNHxx3JSA8CmDBLlzfJ4/edit?usp=sharing15:47
jiaxia litter->a little15:47
jiaxidstanek: https://review.openstack.org/#/c/200512/.  I have replied. Looking forward to your reply.15:48
dstanekjiaxi: serious?15:49
ayoungdolphm, so no change.  interesting.  My guess is that the tree then basically resolves to a linear search.15:49
ayoungactually, I had just looked at the top line15:49
ayoungsignificnat speedup via the tree for the other cases15:50
ayoungbut maybe not enough to warrant the more complex code?15:50
*** _cjones_ has joined #openstack-keystone15:51
ayoungdolphm, thanks for running that.15:51
dolphmayoung: you think the list implementation is more complex?15:52
ayoungdolphm, no, other way round15:53
ayoungI think the list is slower, but easier to understand15:53
dolphmayoung: right, okay15:53
*** jsavak has quit IRC15:54
dolphmayoung: in the first two benchmarks, the tree and list are basically empty, so i imagine there's enough load to distinguish a meaningful difference15:54
dolphmayoung: hence i ran the benchmark 10 times each lol15:54
ayoungdolphm, so I am wondering if the speedup is worth the code complexity.  I also wonder if there are other points in which we can optimize.15:54
dolphmayoung: i vote for the tree15:54
dolphmayoung: and i *hate* complexity :)15:55
ayoungdolphm,  I wonder if we can somehow make that code more readable.15:55
jiaxidstanek: David, Could you spare some minutes in replying my reply to your comments. https://review.openstack.org/#/c/200512/15:55
ayoungBut, I agree that the tree should perform faster than the list;  good to know that it does.15:56
dstanekjiaxi: i don't see a reply15:56
jiaxidstanek: Review is ill too ?15:58
dolphmjiaxi: you don't need to notify everyone every time you make a comment or post a new patchset - there are several ways that everyone can subscribe to notifications from gerrit15:58
jiaxi David StanekThere is little value to all of these URLs since they test the same case.11:38 PM (Draft)Draft saved at 11:45 PM I think we should test all as we do in v2. And why not? Why not we should do different in v3? Edit15:59
*** spandhe has joined #openstack-keystone15:59
dstanekjiaxi: your comment is a draft which means you have not published it yet15:59
dstanekjiaxi: press the 'Add comment' button16:00
dstanekjiaxi: your drafts are always private16:00
jiaxidstanek: Okay,  I will add soon.16:01
openstackgerritLance Bragstad proposed openstack/keystone: Consolidate the fernet provider validate_v3_token()  https://review.openstack.org/19687716:01
lbragstaddolphm: ^16:01
*** jsavak has joined #openstack-keystone16:01
jiaxidstanek: Okay, Done.16:02
dstanekjiaxi: i'm trying to finish up one last thing and then i'll post the updated patchset. having doc building trouble right now16:02
jiaxidstanek: Ok, waiting for you16:03
*** ankita_wagh has joined #openstack-keystone16:04
* dolphm <rant> i hate variable names that end with _data ... of course it's data, it's a damn variable</rant>16:05
morganfainbergdolphm: i'm going to start renaming all variables to _data16:05
morganfainbergdolphm: ;016:06
openstackgerritLance Bragstad proposed openstack/keystone: Consolidate the fernet provider issue_v2_token()  https://review.openstack.org/19764716:06
openstackgerritLance Bragstad proposed openstack/keystone: Refactor _supports_bind method  https://review.openstack.org/19769916:06
*** yottatsa has quit IRC16:09
*** yottatsa has joined #openstack-keystone16:10
dolphmmorganfainberg: the same applies to _info16:12
morganfainbergdolphm: variable_data_info_data_data_info16:12
morganfainbergnew scheme for everything16:12
lbragstad_ref isn't quite as bad, but that could be clearer, too16:12
morganfainberglbragstad: s/_ref/_data_data_data_data_badger_burger_data16:13
lbragstad++ to badger16:13
dstanekstrange....getting a error building docs because keystone.cmd.rst isn't included in a doctree16:13
morganfainbergbadger badger badger badger badger badger snake16:13
dolphmlbragstad: already showing merge conflict on https://review.openstack.org/#/c/197699/16:14
dolphmmorganfainberg: mushroom mushroom16:14
morganfainbergdolphm: http://www.badgerbadgerbadger.com/16:15
dolphmmorganfainberg: thanks, now the rest of my day is burned16:15
morganfainbergdolphm: happy to help16:15
dolphmi think my ears are being massaged by all the bass16:15
lbragstaddolphm: yeah, there was a merge conflict on that one before. i need to investigate that16:16
openstackgerritDavid Stanek proposed openstack/keystone: Reject create endpoint with invalid urls  https://review.openstack.org/20051216:16
samueldmqmorganfainberg: hhehe haven't seen yet, that's funny :)16:17
samueldmqbut annoying too :p16:18
dolphmsamueldmq: this is from like 199916:18
dolphmor maybe 2001-200316:18
samueldmqdolphm: so that means I am just a bit late :)16:18
dstanekmorganfainberg: i just died a little inside16:18
samueldmqnot that much16:18
samueldmqhehe16:19
dolphmbadgerbadgerbadger.com was registered Creation Date: 2003-09-14T01:22:15.00Z16:19
*** e0ne has quit IRC16:20
samueldmqdolphm: I was looking at the sourcecode , and then opened http://www.badgerbadgerbadger.com/badger.swf16:20
samueldmqdolphm: then another tab was playing the samething16:20
samueldmqlol16:20
*** TheIntern has quit IRC16:20
samueldmqsame thing*16:20
dolphmin one of my highschool classes, someone would whisper "it's a..." during tests, and the entire class would burst out with "badger badger badger..." and start headbobbing in complete and perfect unison16:21
samueldmq"Anything on your mind? Suggestions? Comments? Send them to info (at) badgerbadgerbadger.com"16:21
lbragstaddolphm: lol nice16:22
samueldmqdolphm: hahah that must have been very funny16:22
*** jistr has quit IRC16:22
*** spandhe has quit IRC16:23
*** jiaxi has quit IRC16:24
*** browne has joined #openstack-keystone16:25
dolphmInstalling Linux on a Dead Badger: User's Notes http://www.strangehorizons.com/2004/20040405/badger.shtml16:25
lbragstadwhoever wrote that has too much time on their hands...16:26
samueldmqaha very true16:27
samueldmq"VüDü Tech Tips" ...16:28
samueldmqlook at the section "Common Problems" hahaha16:28
lbragstadmarekd: something you might be interested in taking a look at when you have a minute - https://review.openstack.org/#/c/196877/12/keystone/token/providers/common.py16:29
*** fhubik has quit IRC16:31
*** jasonsb has joined #openstack-keystone16:31
dstaneksamueldmq: don't hate me!16:36
dstaneksamueldmq: lol, those two spec share a *ton* of content16:37
samueldmqdstanek: hate you ?16:37
samueldmqdstanek: again?16:37
samueldmqdstanek: ahha kidding :) I am looking at your comments now16:38
samueldmqdstanek: and yeah, I added more details in there, as henrynash asked for more details16:38
dstaneksamueldmq: i'm really curious to know if you guys came up with a clever algorithm the match URLs16:39
samueldmqdstanek: matching URLs and solving URL -> IDs will be in a follow-on spec16:40
dstanekwon't you need it for that spec too?16:40
samueldmqdstanek: for now we consider endpoint_ids config, that is what we need (will be solved from URL in the feature)16:40
samueldmqdstanek: I am planning to address that as an improvement, fetching by endpoint_ids is what we need16:41
dstaneksamueldmq: so if that config option has multiple ids which one do you use? won't you have to check against the request URL to find out?16:41
samueldmqdstanek: providing that info in the config is the first option, discovering is like an inprovement16:41
samueldmqdstanek: so we'll pass the ids to the server and it will decide what policy return16:41
samueldmqdstanek: the strategy can be the first we find, or even a merge of them ? our model is bad and we allow different policies for the same endpoint (as it has multiple ids)16:42
samueldmqdstanek: fwiw in v2 we hadn't that "issue", since different urls (interfaces) mapped to the same endpoint id16:43
dstaneksamueldmq: what happens if the service has 2 different endpoints in that config entry and each has a different policy?16:43
samueldmqdstanek: so that is a conceptual error, explode the world16:44
samueldmqdstanek: so .. in the service endpoitn we will have just a single policy, in that case, we will fetch one, and ignore the other16:44
samueldmqdstanek: I think we should warn in that is the case16:44
dstaneksamueldmq: what do you mean by conceptual error. based on the tools we are giving the operators here that is entirely possible16:44
samueldmqdstanek: yes, that is possible, but wrong imo16:44
dstaneksamueldmq: yes, so how do we prevent it?16:45
samueldmqdstanek: because there will be only a policy locally, and why do we allow to associate multiple of them16:45
samueldmqdstanek: that's the point, with our current endpoint model, we can't prevent16:45
dstaneksamueldmq: exactly, so why are you letting them do that?16:45
samueldmqdstanek: because there is no way to know what endpoint_ids should be together16:45
samueldmqin the database16:45
dstaneksamueldmq: it just seems that this needs to have more work to think through how we want it to work16:46
samueldmqdstanek: we should fix our endpoint model (imo) howeveer there is no way to migrate current database16:46
*** ankita_wagh has quit IRC16:46
*** ankita_wagh has joined #openstack-keystone16:47
*** roxanaghe has joined #openstack-keystone16:47
samueldmqdstanek: with our current (endpoint / endpoitn policy / policy) model, this is the simpler/best we can implement16:47
samueldmqimo16:47
samueldmqdstanek: for me different endpoint interfaces should belong to the same endpoint entity, I don't know why we did split that when doing v2 -> v316:48
samueldmqdstanek: that way, an url maps uniquely to an endpoint_id, and vice-versa, making it possible to discover the other urls (internal, public ? )16:49
samueldmqdstanek: let's create that way in v416:50
dstaneksamueldmq: i just don't like the idea of handing over a broken model - if anything we should make the policy model of 1 policy per service (instead of 1 per endpoint)16:51
samueldmqdstanek: so you can associate a policy to a service16:51
samueldmqdstanek: and if you don't associate a policy to that endpoint specifically, that will be what it will get16:51
*** dims has quit IRC16:52
samueldmqdstanek: btw I need a spec in the server to specify what will be returned for GET /policy?endpoint_ids=x,y,z16:52
*** dims has joined #openstack-keystone16:52
*** dims has quit IRC16:52
samueldmqdstanek: that will define how we use the endpoint policy extension to define what policy to return for an endpoint16:52
*** dims has joined #openstack-keystone16:53
dstaneksamueldmq: again unless the code is "return policies[random.randint(0, len(policies))]" you need the URI to find the right one16:53
*** ankita_wagh has quit IRC16:53
samueldmqdstanek: that'd be wrong as well , so the policy would depend on the url you use to call keystone ?16:54
dstaneksamueldmq: no, the URL of the service call16:54
samueldmqdstanek: we need to restrict how policies are associated to endpoint ids, and there is no way to do so if we don't know what ids are representing the same serviceendpoint16:55
samueldmqdstanek: yeah that's what I mean, and the policy shouldn't vary depending on the url you use to access the service, see what I said above ^16:55
samueldmqdstanek: at least this isn't the behavior we have so far in openstack16:56
dstaneksamueldmq: but it does if you have multiple endpoint ids for that service in the config. how else do you pick the right one?16:56
samueldmqdstanek: there is no definition of the right one16:56
samueldmqdstanek: we have no way to know, I think that's our model that is broken, we allow assing multiple policies to a single service endpoint16:57
*** haypo has left #openstack-keystone16:57
samueldmqdstanek: and after we don't know which one we should resolve to16:57
dstaneksamueldmq: you see my point then right? if there is no way to pick a right one they by definition you are picking the wrong one :-)16:57
samueldmqdstanek: assigning multiple policies is already wrong, we allow that16:57
samueldmqdstanek: and there is no way to fix that without fixing the endpoint model, since there is no way to know the otehr id already has a policy associated16:58
*** snapdey has joined #openstack-keystone16:58
dstaneksamueldmq: that's why i think we should figure out how to fix the model before we start building on top of it16:58
dstaneksamueldmq: it's mostly useless now so people probably are not using it so right now is the time to change it16:58
samueldmqdstanek: so what I thought was to go for something simpler (like pick the first valid one)16:58
samueldmqdstanek: and after fixing the model, it would be just renaming endpoint_ids to endpoint_ids ?16:59
*** snapdey has quit IRC16:59
samueldmqdstanek: that wouldn't interfeer too much in the exisitng implementation16:59
dstaneki would rather say this new feature won't even use policies for endpoints and have the config option be 'service_id' since that's all we can do16:59
samueldmqdstanek: see this paste from last week http://paste.openstack.org/show/397098/17:01
samueldmqdstanek: this is how I think it shoudl be17:01
samueldmqdstanek: so anyway we need endpoint_ids to enforce the endpoint constraint gyee's working on17:02
samueldmqdstanek: and if we have the endpoitn ids we can get the service, so that'd be possible by only allowing to assign a policy to a service_id in the endpoint policy api17:02
*** snapdey has joined #openstack-keystone17:02
dstaneksamueldmq: does gyee's thing worry about the URL?17:02
*** qwebirc5854 has joined #openstack-keystone17:04
*** mylu has quit IRC17:04
*** mylu has joined #openstack-keystone17:05
*** topol has joined #openstack-keystone17:05
*** ChanServ sets mode: +v topol17:05
dstaneksamueldmq: do my devstack does have many examples of services with multiple endpoints - to make matters worse many use the same URL17:05
samueldmqdstanek: I think it must be enforced in the id17:05
samueldmqdstanek: yeah devstack is doing it bad (because we made the model that way)17:06
*** jsavak has quit IRC17:06
*** spandhe has joined #openstack-keystone17:06
*** jsavak has joined #openstack-keystone17:06
dstaneksamueldmq: which id the endpoint?17:06
samueldmqdstanek: so you need to know all the endpoint ids, if you have at least one in your catalog, you're allowed17:07
samueldmqdstanek: but that would depends in the used url (your point I guess)17:07
samueldmqaarrrg17:07
dstaneksamueldmq: i think we are going in circles now17:07
samueldmqdstanek: we cant be based on the url since it can be rewritten at some point in the communication17:08
samueldmqI think17:08
dstaneksamueldmq: maybe the domain, but not the path17:09
dstaneksamueldmq: now you're making arguments on my side!17:09
samueldmqdstanek: ehhe how do we fix that model ? write a service_endpoint api ? service_endpoint_policy API ?17:09
samueldmqdstanek: we can't fix that easily since we cant migrate17:10
dstaneksamueldmq: you said we already support having a policy associated with a service. just do that. i'm curious about gyee's impl though17:10
*** ankita_wagh has joined #openstack-keystone17:11
samueldmqdstanek: if we only allow a policy per service, managing that through a CMS would be more flexible17:11
samueldmqdstanek: since it would allow a policy per endpoint id... however we do need to know if that's a real usecase17:12
samueldmqin your opinion, it isn't (from what I can see)17:12
dstanekyeah, i don't know if it'17:12
dstaneks a use case17:12
*** mylu has quit IRC17:13
dstanekif you remember a few weeks ago all i wanted to do was add a policy_id to the config and let the deployer specify which one they want17:13
dstanekthat way if the day have 2 nodes (public) that would specify a different policy from the other 2 node (internal) for example17:14
samueldmqdstanek: yeah but you loose the flexibility to change the policy id withou the need of a restart17:14
samueldmqdstanek: we want to make the association in the server, and the endpoint say, hey "it's who I am, gimme my policy"17:15
samueldmqdstanek: keystone would handle the complexity/association17:15
openstackgerritDavid Stanek proposed openstack/keystone: Reject create endpoint with invalid urls  https://review.openstack.org/20051217:15
*** mylu has joined #openstack-keystone17:16
*** boris-42 has quit IRC17:20
*** jsavak has quit IRC17:20
*** jungler has quit IRC17:20
*** mestery has quit IRC17:20
*** jungler has joined #openstack-keystone17:21
*** alex_xu has quit IRC17:21
*** jsavak has joined #openstack-keystone17:21
dstaneki think that one should be a relatively easy one now ^17:21
*** stevemar has joined #openstack-keystone17:21
*** ChanServ sets mode: +v stevemar17:21
*** boris-42 has joined #openstack-keystone17:22
*** alex_xu has joined #openstack-keystone17:23
iurygregoryhello marekd, you make a review in my spec in puppet (https://review.openstack.org/#/c/190361/) can you please take a look at richm reply? (Patch Set 19)17:24
*** diazjf has quit IRC17:27
*** nkinder has quit IRC17:32
*** ayoung has quit IRC17:36
*** jsavak has quit IRC17:39
*** jsavak has joined #openstack-keystone17:40
*** mylu has quit IRC17:44
*** snapdey has quit IRC17:45
*** mylu has joined #openstack-keystone17:45
*** markvoelker has quit IRC17:47
*** piyanai has joined #openstack-keystone17:49
*** jsavak has quit IRC17:50
*** snapdey has joined #openstack-keystone17:50
*** jsavak has joined #openstack-keystone17:50
*** jsavak has quit IRC17:51
*** jsavak has joined #openstack-keystone17:52
marekdiurygregory: hi, so i agree with richm 's comment.17:53
iurygregoryThanks marekd ^^17:53
*** mestery has joined #openstack-keystone17:54
*** lhcheng_ has joined #openstack-keystone17:55
*** lhcheng_ has quit IRC17:55
*** mestery has quit IRC17:55
samueldmqdstanek: I am going to bring that discussion as part of the dynamic policies topic we have today17:56
*** lhcheng_ has joined #openstack-keystone17:56
*** snapdey has quit IRC17:56
samueldmqdstanek: so people can take the better decision for the project now17:56
*** jsavak has quit IRC17:56
dstaneksamueldmq: ++17:57
*** henrynash has joined #openstack-keystone17:58
*** ChanServ sets mode: +v henrynash17:58
*** henrynash has quit IRC17:58
*** henrynash has joined #openstack-keystone17:59
*** ChanServ sets mode: +v henrynash17:59
*** snapdey has joined #openstack-keystone18:00
*** nkinder has joined #openstack-keystone18:01
*** jsavak has joined #openstack-keystone18:01
*** jungler has quit IRC18:04
*** alex_xu has quit IRC18:04
*** jungler has joined #openstack-keystone18:05
*** piyanai has quit IRC18:06
*** ayoung has joined #openstack-keystone18:07
*** ChanServ sets mode: +v ayoung18:07
*** jsavak has quit IRC18:07
*** piyanai has joined #openstack-keystone18:08
*** jsavak has joined #openstack-keystone18:08
*** pnavarro has quit IRC18:08
*** alex_xu has joined #openstack-keystone18:09
*** tellesnobrega has quit IRC18:11
*** tellesnobrega has joined #openstack-keystone18:15
*** yottatsa has quit IRC18:23
*** rm_work is now known as rm_work|away18:29
*** mylu has quit IRC18:34
*** jsavak has quit IRC18:36
*** rdo has joined #openstack-keystone18:37
*** josecastroleon has joined #openstack-keystone18:38
*** mylu has joined #openstack-keystone18:39
*** yottatsa has joined #openstack-keystone18:40
*** markvoelker has joined #openstack-keystone18:42
*** markvoelker_ has joined #openstack-keystone18:46
rodrigodshenrynash, permanent +2? :)18:46
henrynashrodigods: I wouldn;t go that far :-)18:47
morganfainbergrodrigods: i can offer a permanent -2...but you probably don't want that18:47
*** markvoelker has quit IRC18:48
rodrigodsmorganfainberg, =(18:48
*** stevemar has quit IRC18:48
*** diazjf has joined #openstack-keystone18:54
*** TheIntern has joined #openstack-keystone18:57
*** ayoung has quit IRC19:00
samueldmqanother option should be to fix the endpoint model, i.e same id for different interfaces19:00
samueldmqas we had for v219:00
samueldmqI don't understand why we changed that, I can't see the usecase actually19:00
dstaneksamueldmq: if the middleware can be configured via the paste ini to have different ids then using endpoint id is fine19:01
dstaneksamueldmq: the specs are confusing because they contain lots of the same boilerplate and it's tough to know what is actually being proposed19:01
*** ankita_wagh has quit IRC19:01
samueldmqdstanek: how would that work ? what policy to fetch ?19:01
samueldmqdstanek: yeah but some folks asked for details, motivation, use case etc19:02
*** ankita_wagh has joined #openstack-keystone19:02
samueldmqdstanek: I am being as much specific/detailed as I am being asked for19:02
dstaneksamueldmq: what i keep saying about endpoint id is that services have multiple endpoints. which one do they use? if a service deployer can must wrap each endpoint in middleware it solved that problem19:03
*** e0ne has joined #openstack-keystone19:03
samueldmqdstanek: so 3 middlewares ? as they would be using the same policy file to write too, the last one would be kept19:04
*** jsavak has joined #openstack-keystone19:04
henrynashsamueldmq: I think the confusion on specs is the HTTP header one has the same boiler plate, and maybe it should just refer to the other one…19:05
dstaneksamueldmq: you are actually writing the policy file to disk yourself?19:05
samueldmqhenrynash: yeah maybe19:05
samueldmqdstanek: yes, and use the exisitng mechanism from oslo.policy to do the overlay19:05
*** zzzeek has quit IRC19:06
*** ankita_wagh has quit IRC19:06
dstaneksamueldmq: if you are using the HTTP headers to cache and not using a library then the file should be named based on the request anyway19:06
*** snapdey has quit IRC19:07
samueldmqdstanek: I am always caching to one file, let's say: /etc/glance/dynamic-policy.json19:07
dstaneksamueldmq: if you hard code saving the file to /var/run/keystone/policy.cache then we've already lost19:07
samueldmqdstanek: when it times out, I get another dict and write it again to that file, and so on19:07
openstackgerritSam Leong proposed openstack/keystone: Tokenless authz with X.509 SSL client certificate  https://review.openstack.org/15687019:07
*** zzzeek has joined #openstack-keystone19:08
*** josecastroleon has quit IRC19:08
dstaneksamueldmq: that would break anything that runs multiple services on the same node19:08
dstaneksamueldmq: devstack could never have centralized policy enabled if that were the implementation19:09
samueldmqdstanek: that's how policy.json is stored/read from the fie19:09
samueldmqdstanek: we are using exactly the same mechanism, aren't we ?19:09
dstaneksamueldmq: maybe that's just my setup that it'll break because i have been running multiple instances of services for k2k testing19:11
samueldmqdstanek: see https://review.openstack.org/#/c/200257/19:11
dstanekbut that will break if you need to have endpoint policy19:11
*** qwebirc5854 has quit IRC19:11
dstaneksigmavirus24: how do you feel about requests-cache - i remember when i brought it up last time you either thought it was cool or that i'm a complete idiot19:12
sigmavirus24cachecontrol is the way to go dstanek19:12
sigmavirus24requests-cache was by Cory and was deprecated for CacheControl19:12
sigmavirus24CacheControl is far more mature and maintained by someone working on oslo.cache19:12
sigmavirus24dstanek: ^19:12
*** samleon has joined #openstack-keystone19:12
dstaneksigmavirus24: perfect thx19:13
sigmavirus24you're quite welcome19:13
samueldmqdstanek: what is that ?19:13
dstaneksamueldmq: ^ that solves your problem - it will cached based off of the request instead of a static filename and you don't have to interpret http headers19:13
samueldmqdstanek: k I will take a look at it, thanks19:14
dstaneksamueldmq: https://pypi.python.org/pypi/CacheControl/0.9.319:14
dstaneksamueldmq: you would basically do the same .get(....policy/{endpoint_id}/) every single time and it will decide whether to go to the service of just return what it has cached19:15
dstaneksamueldmq: that means thought that olso policy would accept a file like object or json blob (if it already doesn't) so that you can just pass in what you get back from the .get()19:15
samueldmqdstanek: based on the Cache-COntrol header  (max-age) ?19:15
samueldmqdstanek: I mean when caching it does respect the cache control headers right ?19:16
*** jsavak has quit IRC19:17
samueldmqdstanek: k and what about the config, we then keep endpoint_id ?19:17
samueldmqdstanek: and the deployer uses the same he/she used to associate the policy with using the endpoint policy extension ?19:18
samueldmqdstanek: at this point, I am not sure how many keystoners really care about this feature/think it is worth it :(19:18
samueldmqtbh19:18
*** henrynash has quit IRC19:20
dstaneksamueldmq: the library will deal with the headers. you just ask it for the HTTP resource you want. you won't even know if you get a cached version or one from the network19:22
samueldmqdstanek: so that should be used by ksclient ?19:23
dstaneksamueldmq: 1 id for sure. i don't think we can allow different middleware configs without a deployer having something in their paste.ini, but it seems everyone is against that19:23
dstaneksamueldmq: eventually yes, i think it should19:24
samueldmqdstanek: ok I will update the specs, and let's see what happens19:25
samueldmqdstanek: thanks19:25
dstaneksamueldmq: about the keystoners...i don't think it should matter too much what we want as long as there is a clear need from deployers19:25
samueldmqdstanek: yes I've asked adam and others to review that email I wrote to send to ops list19:27
samueldmqdstanek: didn't get too much feedback19:27
samueldmqdstanek: I will stop listening when there is no one talking to me, I will just send it19:27
samueldmqdstanek: as you and dolphm suggested19:27
dstaneksamueldmq: what's that link again? i thought i clicked it, but i can't find it in my huge list of tabs19:28
samueldmqdstanek: https://etherpad.openstack.org/p/centralized-policy-delivery-operators19:28
dstanekthx, i'll have a look19:28
*** markvoelker_ has quit IRC19:29
samueldmqdstanek: nice thanks, going afk for a bit19:29
* samueldmq needs some coffee19:29
*** mestery has joined #openstack-keystone19:30
samueldmqmorganfainberg: how will we proceed with the spec freeze excp request ? it's basically needing to be converted in a ffe bu the end of this week...19:32
samueldmqby*19:33
*** ankita_wagh has joined #openstack-keystone19:34
dstaneksamueldmq: i'm looking at that assignment review and it's letting me know that assignments are much more complicated that i realized19:36
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient.tenant_id|name  https://review.openstack.org/20571019:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient.request methods  https://review.openstack.org/20571119:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Update deprecation text for Session properties  https://review.openstack.org/19151119:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient session and adapter properties  https://review.openstack.org/20580619:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient tenant_id, tenant_name parameters  https://review.openstack.org/20570119:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for httpclient.USER_AGENT  https://review.openstack.org/20583319:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for Session.get_token()  https://review.openstack.org/20581719:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Deprecate create HTTPClient without session  https://review.openstack.org/20583219:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Deprecate create v2_0 Client without session  https://review.openstack.org/20582019:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Deprecate create v3 Client without session  https://review.openstack.org/20582219:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Deprecate ServiceCatalog(region_name)  https://review.openstack.org/20580919:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for CredentialManager data argument  https://review.openstack.org/20582519:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for UserManager project argument  https://review.openstack.org/20582619:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Deprecate ServiceCatalog.get_urls() with no attr  https://review.openstack.org/20581019:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Deprecate create Discover without session  https://review.openstack.org/20582919:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Deprecate use of cert and key  https://review.openstack.org/20581319:43
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for Session.construct()  https://review.openstack.org/20581219:43
*** ayoung has joined #openstack-keystone19:44
*** ChanServ sets mode: +v ayoung19:44
*** yottatsa has quit IRC19:44
*** jsavak has joined #openstack-keystone19:44
ayoungsamueldmq, I think that we are down to the last few nits on https://review.openstack.org/#/c/134655/17/specs/backlog/dynamic-policies-fetch-cache.rst  .  I assume you are making the last changes, or shall I?19:45
*** snapdey has joined #openstack-keystone19:45
samueldmqdstanek: yes they are, group/inherited needs to expand to users/subprojects19:46
samueldmqdstanek: that code is very complex19:46
samueldmqdstanek: and it did took time to get it right19:46
dstaneksamueldmq: hey...i'll be the judge of that :-P19:47
*** jsavak has quit IRC19:47
samueldmqayoung: I am making the changes, and changing endpoint_ids -> endpoint_id19:47
samueldmqayoung: thanks, and after all this work, I will struggle to get the endpoint model fixed, if there is no strong reason to have multiple ids for multiple interfaces19:48
ayoungsamueldmq, excellent.  I'm about to respond to the review.  PLease take a look at my comments.19:48
samueldmqdstanek: hehe19:48
samueldmqayoung: ok please19:48
*** jsavak has joined #openstack-keystone19:55
*** topol has quit IRC19:56
samueldmqayoung: could you see my reply at L60 https://review.openstack.org/#/c/134655/17/specs/backlog/dynamic-policies-fetch-cache.rst ?19:56
*** pnavarro has joined #openstack-keystone19:56
ayoungsamueldmq, ah...goood point...ok, I'll retract.  You do have a type above that, BTW (frenquently)19:57
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecation for httpclient.USER_AGENT  https://review.openstack.org/20583320:01
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Update deprecation text for Session properties  https://review.openstack.org/19151120:01
openstackgerritMerged openstack/keystone: Replace 401 to 404 when token is invalid  https://review.openstack.org/20555420:03
*** mestery has quit IRC20:08
*** ankita_w_ has joined #openstack-keystone20:12
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Fetch and Cache  https://review.openstack.org/13465520:13
samueldmqayoung: dstanek there we go ... ^20:13
*** jsavak has quit IRC20:13
samueldmqendpoint_id ftw ... I am going to update the keystone side spec to reflect it, and point to this one instead of repeating motivation,usecase,etc20:13
*** ankita_wagh has quit IRC20:15
*** e0ne has quit IRC20:19
*** ankita_wagh has joined #openstack-keystone20:19
*** e0ne has joined #openstack-keystone20:21
*** e0ne has quit IRC20:21
*** ankita_w_ has quit IRC20:22
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Distribution Mechanism  https://review.openstack.org/19798020:23
samueldmqayoung: dstanek removed almost 200 lines by saying : 'look at the ksmiddleware spec'20:23
samueldmq^^20:23
*** topol has joined #openstack-keystone20:24
*** ChanServ sets mode: +v topol20:24
samueldmqdstanek: ayoung I meant almost 100 ...20:24
*** jsavak has joined #openstack-keystone20:34
*** gordc has quit IRC20:41
*** mestery has joined #openstack-keystone20:43
*** hrou has quit IRC20:58
morganfainbergdstanek: ping20:58
dstanekmorganfainberg: pong20:59
*** raildo has quit IRC21:01
dstanekmorganfainberg: you weren't expecting such a quick response were you? i've been working on my pong reflexes21:03
morganfainbergdstanek: hey.21:04
morganfainbergdstanek: no i was in an elevator21:04
morganfainbergdstanek: mind working with dhellmann on liberty-2 release21:04
morganfainbergToday?21:04
morganfainbergI need to jump into a meeting.21:04
dstanekmorganfainberg: sure, i'll ping him and see what he needs21:04
morganfainbergThis would be ~10mins post x-project meeting21:05
morganfainbergThis will be bp/bug review21:05
morganfainbergPunting things out of l2 as needed21:05
morganfainbergEtc21:05
dstaneksure, so basically walking through things scheduled for l2 and punt if they are not merged?21:06
*** aix has joined #openstack-keystone21:06
*** jdennis has quit IRC21:07
*** mylu has quit IRC21:07
dstanekoops..missing the x-project...21:07
*** jdennis has joined #openstack-keystone21:13
*** jsavak has quit IRC21:16
*** mestery has quit IRC21:25
*** piyanai has quit IRC21:26
*** piyanai has joined #openstack-keystone21:30
*** jsavak has joined #openstack-keystone21:30
*** BAKfr has quit IRC21:30
*** pnavarro has quit IRC21:30
*** diazjf has left #openstack-keystone21:33
*** BAKfr has joined #openstack-keystone21:36
*** topol has quit IRC21:39
*** jaosorior has quit IRC21:41
*** dims has quit IRC21:42
*** gordc has joined #openstack-keystone21:42
*** snapdey has quit IRC21:47
*** snapdey has joined #openstack-keystone21:54
*** bknudson has quit IRC21:59
*** ankita_w_ has joined #openstack-keystone21:59
*** ankita_wagh has quit IRC22:02
*** dims has joined #openstack-keystone22:02
*** snapdey has quit IRC22:06
*** jecarey_ has quit IRC22:08
*** snapdey has joined #openstack-keystone22:10
*** jsavak has quit IRC22:11
*** piyanai has quit IRC22:23
*** gordc has quit IRC22:31
*** topol has joined #openstack-keystone22:40
*** ChanServ sets mode: +v topol22:40
dstaneki'm not sure why ChanServ give topol voice - he talks too much22:41
*** TheIntern has quit IRC22:42
*** topol has quit IRC22:44
*** snapdey has quit IRC22:46
*** piyanai has joined #openstack-keystone22:51
*** rm_work|away is now known as rm_work22:51
*** Guest47142 is now known as dan22:56
*** zzzeek has quit IRC22:56
*** hrou has joined #openstack-keystone22:57
*** piyanai has quit IRC23:04
*** dims has quit IRC23:05
*** edmondsw has quit IRC23:07
*** sigmavirus24 is now known as sigmavirus24_awa23:07
*** r-daneel has joined #openstack-keystone23:24
*** r-daneel has quit IRC23:24
*** r-daneel has joined #openstack-keystone23:25
*** dims has joined #openstack-keystone23:34
*** albertom has quit IRC23:46
*** albertom has joined #openstack-keystone23:48
*** jasonsb has quit IRC23:56

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