*** topol has quit IRC | 00:08 | |
*** markvoelker has joined #openstack-keystone | 00:09 | |
*** dims has quit IRC | 00:22 | |
*** snapdey has quit IRC | 00:30 | |
*** jiaxi has quit IRC | 00:31 | |
*** roxanaghe has quit IRC | 00:31 | |
*** dims has joined #openstack-keystone | 00:32 | |
*** snapdey has joined #openstack-keystone | 00:34 | |
*** btully has quit IRC | 00:39 | |
*** openstackgerrit has quit IRC | 00:46 | |
*** openstackgerrit has joined #openstack-keystone | 00:47 | |
*** lhcheng has quit IRC | 00:48 | |
*** _cjones_ has quit IRC | 00:50 | |
*** telemonster has quit IRC | 00:56 | |
*** telemonster has joined #openstack-keystone | 00:57 | |
*** david8hu has quit IRC | 00:59 | |
*** lhcheng has joined #openstack-keystone | 01:06 | |
*** ChanServ sets mode: +v lhcheng | 01:06 | |
*** david8hu has joined #openstack-keystone | 01:17 | |
*** davechen has joined #openstack-keystone | 01:18 | |
*** btully has joined #openstack-keystone | 01:19 | |
*** ankita_w_ has quit IRC | 01:20 | |
*** snapdey has quit IRC | 01:22 | |
*** davechen1 has joined #openstack-keystone | 01:24 | |
*** btully has quit IRC | 01:24 | |
*** davechen has quit IRC | 01:25 | |
*** davechen1 is now known as davechen | 01:26 | |
*** jasonsb has quit IRC | 01:28 | |
*** topol has joined #openstack-keystone | 01:28 | |
*** ChanServ sets mode: +v topol | 01:28 | |
*** woodster_ has quit IRC | 01:34 | |
*** jiaxi has joined #openstack-keystone | 01:39 | |
jiaxi | ayoung: Hi | 01:39 |
---|---|---|
jiaxi | Good morning. Everyone | 01:40 |
jiaxi | You Americans go to bed so early ??? | 01:41 |
*** mylu has joined #openstack-keystone | 01:41 | |
davechen | dstanek: ping david? | 01:54 |
davechen | jiaxi: you are funny. :-D | 01:55 |
jiaxi | davechen: 为什么。 你才funny呢 | 01:55 |
jiaxi | 哈哈 | 01:55 |
jiaxi | 他们老外应该都睡觉了 | 01:56 |
*** mylu has quit IRC | 01:56 | |
jiaxi | davechen: https://review.openstack.org/#/c/200512/ 帮为review一下呀。 | 01:56 |
davechen | jiaxi: sure, why using native language? | 01:58 |
*** jlvillal has quit IRC | 01:58 | |
jamielennox | jiaxi: reviewd | 01:58 |
davechen | jiaxi: ayoung may need transilate in the google again. :) | 01:58 |
jiaxi | davechen: You are not chinese ? | 01:58 |
*** cloudnull is now known as cloudnull_afk | 01:58 | |
jiaxi | davechen: ayoung is naught. | 01:59 |
davechen | jiaxi: I agree. :) | 01:59 |
ayoung | Um | 01:59 |
ayoung | I think you should look up the meaning of the word naught | 01:59 |
ayoung | I think you jkust meant "not" | 01:59 |
jiaxi | jamielennox: Thank you. | 01:59 |
davechen | absolutly right. :) | 01:59 |
*** jlvillal has joined #openstack-keystone | 01:59 | |
jamielennox | jiaxi: 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 already | 02:00 |
ayoung | jamielennox, I had +2ed, buyt dstanek had some comments strong enough to warrant a -1, was going to let him come back around on it | 02:00 |
jiaxi | jamielennox: Okay, I will think about it | 02:01 |
davechen | jiaxi, ayoung is will be mad at you. | 02:01 |
dstanek | davechen: pong | 02:01 |
davechen | dstanek: hi boss, good evening. | 02:01 |
ayoung | jamielennox, V2.0 is not yet marked as deprecated, right? | 02:01 |
davechen | dstanek: I will fix those nits shortly. | 02:02 |
jamielennox | ayoung, jiaxi: i just don't think you should remove the test | 02:02 |
jamielennox | the others are just preference | 02:02 |
ayoung | jamielennox, yeah, fair enough. | 02:02 |
davechen | dstanek: but not quite sure how to address one of your comments. | 02:02 |
jiaxi | jamielennox: I should remove . You didn't see the commit log ?? | 02:02 |
jamielennox | jiaxi: there's a lot of history there, no i didn't read the comments | 02:03 |
jamielennox | hey, reviews cracked the 200000 mark, hadn't noticed that | 02:03 |
davechen | dstanek: so, you meant we should investigate more in the validation and let schema validation to capture the empty body, am i right? | 02:03 |
dstanek | jiaxi: 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 catch | 02:04 |
jiaxi | davechen: He means empty or null is okey when the agrument is optional. | 02:04 |
dstanek | jiaxi: ValueError for sure since '%(x)" % {'x': 0} would lead to that | 02:05 |
davechen | jiaxi: we are talking different things. | 02:05 |
dstanek | jiaxi: i think i wrote code in the catalo to protect against this...i'll find it | 02:05 |
jiaxi | dstanek: For example ? | 02:05 |
davechen | jiaxi, dstanek, I am talking my patch. :) | 02:05 |
dstanek | davechen: is an {} always bad? | 02:06 |
jiaxi | davechen: Okay, you won | 02:06 |
davechen | dstanek: I think so, this is what the bug want to address. | 02:06 |
dstanek | davechen: the bug if for a missing body right? not an empty one | 02:07 |
*** stevemar has joined #openstack-keystone | 02:07 | |
*** ChanServ sets mode: +v stevemar | 02:07 | |
*** dolphm has quit IRC | 02:07 | |
*** d34dh0r53 has quit IRC | 02:07 | |
*** sigmavirus24 has quit IRC | 02:07 | |
*** eglute has quit IRC | 02:07 | |
*** cloudnull_afk has quit IRC | 02:07 | |
davechen | dstanek: it's also about the emtpy body. iirc, there is some desc about the empty body as well. | 02:07 |
jiaxi | jamielennox: 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-keystone | 02:08 | |
*** d34dh0r53 has quit IRC | 02:08 | |
davechen | dstanek: https://bugs.launchpad.net/keystone/+bug/1466872, talk something about the empty body. | 02:08 |
openstack | Launchpad 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-keystone | 02:08 | |
dstanek | jiaxi: 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#n60 | 02:09 |
*** eglute has joined #openstack-keystone | 02:09 | |
*** dolphm has joined #openstack-keystone | 02:09 | |
davechen | dstanek: when the body is empty, the message is not friendly as well. | 02:09 |
jiaxi | jamielennox: 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 IRC | 02:09 | |
*** dolphm has quit IRC | 02:09 | |
*** eglute has quit IRC | 02:09 | |
davechen | jiaxi: of course, you should belive in cores' comments. | 02:10 |
*** d34dh0r53 has joined #openstack-keystone | 02:10 | |
jamielennox | jiaxi: 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 it | 02:10 |
davechen | jiaxi: my review is not such important somhow. | 02:10 |
dstanek | davechen: what's the error message for an empty body? the missing body is a 500 right? | 02:10 |
jiaxi | davechen: Okay, you won again. | 02:10 |
*** dolphm has joined #openstack-keystone | 02:10 | |
*** eglute has joined #openstack-keystone | 02: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 |
jamielennox | jiaxi: 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 -1 | 02:11 |
jamielennox | removing the old test is the only thing i -1ed for | 02:11 |
jiaxi | jamielennox: Okay, you are right | 02:11 |
jiaxi | jamielennox: 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 devstack | 02:12 |
dstanek | jamielennox: yeah, i mentioned not removing the test. | 02:12 |
davechen | dstanek: the reporter complain about this message as well, but if you think it's okay, I am okay too. :) | 02:12 |
dstanek | davechen: that's not a great message, but at least it's a 400 :-) | 02:12 |
dstanek | davechen: looks like that message is straight out of jsonschema | 02:13 |
davechen | dstanek: you are right, it's from jsonschema. | 02:13 |
jamielennox | jiaxi: that doesn't mean that there aren't old endpoints with spaces that already exist that might need to be removed in future | 02:13 |
davechen | dstanek: the only way i can see is capture it before the emtpy body go to jsonschema. | 02:14 |
jamielennox | jiaxi: 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 behaviour | 02:14 |
jiaxi | dstanek: So if I don't delete the old test. The url with space in it will be valid ...... | 02:14 |
jamielennox | there is a lot of unit testing that ensures edge cases that we never remove even though they shouldn't be triggered | 02:15 |
dstanek | davechen: i would make them 2 separate commits anyway; 1 to fix the bug and another to catch (and fix) the strange error message | 02:15 |
dstanek | jiaxi: why would it still be valid? the controller won't let new ones in | 02:15 |
jiaxi | jamielennox: so in patch set. A space in url is valid ????? | 02:16 |
jamielennox | jiaxi: ah - if you have to remove it because the old test breaks then that's different | 02:16 |
dstanek | jamielennox: jiaxi: you just need to add it through the Python API | 02:16 |
jamielennox | right, you should be able to change the old test to add via the manager directly | 02:17 |
jiaxi | dstanek: 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 succeed | 02:17 |
dstanek | jiaxi: that is because it uses the REST API. the manager (Python API) can still be used to add an invalid URL to the database | 02:18 |
davechen | dstanek: 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 |
jiaxi | dstanek: I don't understand well. Give me a demo ? | 02:19 |
dstanek | davechen: i'm just worried that an empty body is or could be valid | 02:20 |
dstanek | davechen: are you checking for empty bodies on a DELETE or PUT? | 02:21 |
davechen | dstanek: from the validation itself, this is not allowed i am afraid. | 02:21 |
jiaxi | jamielennox: change the old test? to what purpose ? | 02:21 |
davechen | dstanek: all of them will go to the validation when the body is passing, so the current fixing will address them all. | 02:21 |
dstanek | jiaxi: to add the invalid URL using the manager code and not the REST API | 02:21 |
dstanek | davechen: but DELETEs don't have a body - is that allowed? | 02:22 |
jiaxi | dstanek: Okay, got it. | 02:22 |
davechen | dstanek: yes, no body, nothing to fix. | 02:22 |
dstanek | davechen: which review is this? | 02:22 |
davechen | dstanek: delete API has no body, so there is nothing about this bug, am i right? | 02:24 |
dstanek | davechen: the way i read the code is that you had to have a body | 02:24 |
*** chenhong has joined #openstack-keystone | 02:25 | |
davechen | dstanek: great, this might be a issue, let me check it again. | 02:25 |
dstanek | davechen: GETs never have a body and we have at least 1 PUT that doesn't have a body | 02:26 |
dstanek | i would have expected the v3 tests to fail though. so i'm curious to dig is and see what is happening | 02:26 |
dstanek | davechen: what's the review number? | 02:26 |
davechen | dstanek: 195903 ? | 02:27 |
davechen | dstanek: if this is the case, why all of the testcase passed. | 02:28 |
davechen | dstanek: interesting, maybe more negative testcase is needed here. | 02:28 |
dstanek | davechen: 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 APIs | 02:29 |
davechen | seem from the current logic, it's not allowed. | 02:30 |
dstanek | davechen: what logic prevents it? | 02:30 |
davechen | dstanek: but it's arguable. | 02:30 |
davechen | dstanek: jsonschema itself will not allowed to do this, since there is no schem will nothing in it, this is not make sense. | 02:31 |
davechen | schem will nothing/schema with nothing | 02:31 |
davechen | too many typos. | 02:31 |
dstanek | davechen: i'm looking through our schemas now - it's possible to have one with all optional properties | 02:31 |
davechen | dstanek: yeah, i will look into too, if that is indeed allowed, we can do some differentiation. | 02:32 |
dstanek | looks like maybe service provider can be empty | 02:33 |
davechen | dstanek: thanks David, take a lot time from you. I | 02:33 |
dstanek | davechen: yw. i have lots of time :-) | 02:34 |
davechen | dstanek: really!! | 02:34 |
davechen | dstanek: don't tell me you are off-duty already. | 02:34 |
davechen | dstanek: btw, do you hear something about the collorbration between intel and rackspace. | 02:35 |
davechen | dstanek: maybe a good chance for me to work with you. :) | 02:35 |
*** dims has quit IRC | 02:35 | |
*** jasonsb has joined #openstack-keystone | 02:36 | |
dstanek | davechen: yes, it sounds pretty cool | 02:36 |
dstanek | davechen: will you be onsite? | 02:37 |
davechen | dstanek: depend on whether you jamielennnox or lance are there, looks like more about the operators and bug fixing. :) | 02:38 |
*** mylu has joined #openstack-keystone | 02:44 | |
*** mylu has quit IRC | 02:45 | |
*** lhcheng has quit IRC | 02:48 | |
*** hakimo_ has joined #openstack-keystone | 02:52 | |
*** hakimo has quit IRC | 02:54 | |
*** stevemar has quit IRC | 03:01 | |
*** chmouel_ has joined #openstack-keystone | 03:03 | |
*** chmouel- has joined #openstack-keystone | 03:04 | |
*** chmouel| has joined #openstack-keystone | 03:04 | |
*** chmouel^ has joined #openstack-keystone | 03:05 | |
*** richm has quit IRC | 03:08 | |
*** chmouel^ has quit IRC | 03:10 | |
*** chmouel- has quit IRC | 03:10 | |
*** chmouel_ has quit IRC | 03:10 | |
*** chmouel| has quit IRC | 03:10 | |
*** chmouel has quit IRC | 03:10 | |
*** chmouel has joined #openstack-keystone | 03:11 | |
*** lhcheng has joined #openstack-keystone | 03:18 | |
*** ChanServ sets mode: +v lhcheng | 03:18 | |
*** Kennan2 has quit IRC | 03:20 | |
*** Kennan has joined #openstack-keystone | 03:20 | |
*** kiran-r has joined #openstack-keystone | 03:34 | |
*** kiran-r has quit IRC | 03:40 | |
*** stevemar has joined #openstack-keystone | 03:50 | |
*** ChanServ sets mode: +v stevemar | 03:50 | |
*** htruta_ has quit IRC | 03:50 | |
*** stevemar has quit IRC | 03:52 | |
*** ayoung has quit IRC | 03:58 | |
openstackgerrit | jiaxi proposed openstack/keystone: Reject create endpoint with invalid urls https://review.openstack.org/200512 | 04:02 |
*** markvoelker has quit IRC | 04:04 | |
*** lhcheng has quit IRC | 04:07 | |
*** btully has joined #openstack-keystone | 04:11 | |
*** spandhe has quit IRC | 04:12 | |
*** ankita_wagh has joined #openstack-keystone | 04:54 | |
*** markvoelker has joined #openstack-keystone | 05:05 | |
*** markvoelker has quit IRC | 05:10 | |
*** Nirupama has joined #openstack-keystone | 05:12 | |
*** ankita_wagh has quit IRC | 05:12 | |
*** ankita_wagh has joined #openstack-keystone | 05:13 | |
*** yottatsa has joined #openstack-keystone | 05:14 | |
*** e0ne has joined #openstack-keystone | 05:14 | |
*** ankita_wagh has quit IRC | 05:17 | |
*** hrou has quit IRC | 05:27 | |
*** ankita_wagh has joined #openstack-keystone | 05:29 | |
*** pnavarro has joined #openstack-keystone | 05:35 | |
*** e0ne has quit IRC | 05:42 | |
*** e0ne has joined #openstack-keystone | 05:44 | |
jamielennox | jiaxi: commented on your review | 05:49 |
*** e0ne has quit IRC | 05:51 | |
jiaxi | jamielennox: ok ,thanks. It's too late in US. And you are not in US ? | 05:52 |
*** jamielennox is now known as jamielennox|away | 05:52 | |
*** topol has quit IRC | 05:54 | |
*** e0ne has joined #openstack-keystone | 05:55 | |
*** lhcheng has joined #openstack-keystone | 05:56 | |
*** ChanServ sets mode: +v lhcheng | 05:56 | |
*** jamielennox|away is now known as jamielennox | 05:56 | |
jamielennox | jiaxi: no. i'm in australia | 05:58 |
openstackgerrit | jiaxi proposed openstack/keystone: Reject create endpoint with invalid urls https://review.openstack.org/200512 | 05:58 |
jiaxi | jamielennox: Good place . I have updated it . | 05:59 |
*** albertom has quit IRC | 06:01 | |
*** albertom has joined #openstack-keystone | 06:09 | |
*** jsheeren has joined #openstack-keystone | 06:11 | |
*** jsheeren has quit IRC | 06:12 | |
*** e0ne has quit IRC | 06:13 | |
*** lhcheng has quit IRC | 06:17 | |
*** chlong has quit IRC | 06:17 | |
*** belmoreira has joined #openstack-keystone | 06:25 | |
*** spandhe has joined #openstack-keystone | 06:25 | |
*** afazekas has joined #openstack-keystone | 06:44 | |
-openstackstatus- NOTICE: zuul is stuck and about to undergo an emergency restart, please be patient as job results may take a long time | 06: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-keystone | 06:50 | |
*** ChanServ sets mode: +v lhcheng | 06:50 | |
*** btully has quit IRC | 06:52 | |
*** Nirupama has quit IRC | 06:52 | |
*** spandhe has quit IRC | 06:57 | |
*** henrynash has joined #openstack-keystone | 07:04 | |
*** ChanServ sets mode: +v henrynash | 07:04 | |
*** markvoelker has joined #openstack-keystone | 07:06 | |
*** pnavarro has quit IRC | 07:08 | |
*** ankita_wagh has quit IRC | 07:09 | |
*** ankita_wagh has joined #openstack-keystone | 07:09 | |
*** markvoelker has quit IRC | 07:11 | |
*** ankita_wagh has quit IRC | 07:14 | |
*** fhubik has joined #openstack-keystone | 07:32 | |
*** browne has quit IRC | 07:35 | |
*** e0ne has joined #openstack-keystone | 07:37 | |
*** ajayaa has joined #openstack-keystone | 07:40 | |
*** lhcheng has quit IRC | 07:43 | |
*** Nirupama has joined #openstack-keystone | 07:48 | |
*** yottatsa has quit IRC | 07:50 | |
*** pnavarro has joined #openstack-keystone | 07: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-keystone | 08:03 | |
*** henrynash has quit IRC | 08:05 | |
*** henrynash has joined #openstack-keystone | 08:06 | |
*** ChanServ sets mode: +v henrynash | 08:06 | |
*** henrynash has quit IRC | 08:06 | |
*** topol has joined #openstack-keystone | 08:06 | |
*** ChanServ sets mode: +v topol | 08:06 | |
*** topol has quit IRC | 08:10 | |
*** fhubik is now known as fhubik_afk | 08:12 | |
*** evrardjp has joined #openstack-keystone | 08:16 | |
*** fhubik_afk is now known as fhubik | 08:29 | |
*** yottatsa has joined #openstack-keystone | 08:41 | |
*** aix has joined #openstack-keystone | 08:45 | |
*** Nirupama has quit IRC | 08:54 | |
*** Nirupama has joined #openstack-keystone | 08:55 | |
*** yottatsa has quit IRC | 09:01 | |
openstackgerrit | Marek Denis proposed openstack/keystone: Fernet payloads for federated scoped tokens. https://review.openstack.org/202176 | 09:01 |
*** markvoelker has joined #openstack-keystone | 09:07 | |
*** boris-42 has quit IRC | 09:10 | |
*** markvoelker has quit IRC | 09:11 | |
*** henrynash has joined #openstack-keystone | 09:23 | |
*** ChanServ sets mode: +v henrynash | 09:23 | |
*** davechen has left #openstack-keystone | 09:52 | |
*** aix has quit IRC | 09:55 | |
*** haypo has joined #openstack-keystone | 09:57 | |
*** henrynash has quit IRC | 10:04 | |
*** yottatsa has joined #openstack-keystone | 10:05 | |
*** henrynash has joined #openstack-keystone | 10:08 | |
*** ChanServ sets mode: +v henrynash | 10:08 | |
openstackgerrit | Merged openstack/keystone: Updating sample configuration file https://review.openstack.org/206223 | 10:18 |
*** aix has joined #openstack-keystone | 10:22 | |
*** dims has joined #openstack-keystone | 10:31 | |
openstackgerrit | Alexey Miroshkin proposed openstack/keystone: Test admin app in test_admin_version_v3 https://review.openstack.org/206472 | 10:36 |
*** bradjones has quit IRC | 10:41 | |
*** henrynash has quit IRC | 10:48 | |
*** chenhong has quit IRC | 10:55 | |
*** fhubik is now known as fhubik_afk | 10:55 | |
*** markvoelker has joined #openstack-keystone | 11:08 | |
*** markvoelker has quit IRC | 11:13 | |
openstackgerrit | Alexey Miroshkin proposed openstack/keystone: Fix test_admin to expect admin endpoint https://review.openstack.org/206496 | 11:23 |
*** amakarov_away is now known as amakarov | 11:25 | |
*** fhubik_afk is now known as fhubik | 11:35 | |
*** jaosorior has joined #openstack-keystone | 11:37 | |
*** jiaxi has quit IRC | 11:45 | |
samueldmq | jamielennox: hi, you still around ? we need an advice on how to discover keystone url + version from the service catalog inside cinder service :-) | 11:48 |
samueldmq | ericksonsantos: cc ^ | 11:48 |
jamielennox | samueldmq: just caught me, what's up | 11:48 |
samueldmq | jamielennox: so for hierarchical quotas, once we get a token we need to retrieve its hierarchy from keystone, right ? | 11:49 |
samueldmq | jamielennox: that way, the only information we have in hands is the token | 11:49 |
samueldmq | jamielennox: 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 calll | 11:49 |
jamielennox | samueldmq: i'm not completely up to date on how much information will be available within the token data | 11:49 |
jamielennox | samueldmq: that auth_token middleware would be able to pass through | 11:50 |
jamielennox | i 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 hierarchy | 11:50 |
samueldmq | jamielennox: 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 that | 11:50 |
jamielennox | samueldmq: i've never heard that argument, service _must_ trust what auth_token midddleware tells them, that's how they determine the user, and roles etc | 11:51 |
samueldmq | jamielennox: how does auth_token tells the service the info ? | 11:51 |
samueldmq | jamielennox: env vars ? | 11:52 |
jamielennox | it's also way more likely that auth_token is going to have implemented it correctly, particularly based on how bad service-> service communication is | 11:52 |
jamielennox | samueldmq: yes, we are adding an object that can be passed down but that is also passed through environ | 11:52 |
samueldmq | jamielennox: 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 |
samueldmq | jamielennox: putting that in auth_token means that every api call would retrieve the hierarchy | 11:53 |
samueldmq | jamielennox: but not all api calls need the hierarchy .. | 11:53 |
samueldmq | we only know if we'll need thta info inside the service when we know what call we're making | 11:53 |
jamielennox | samueldmq: 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 values | 11:55 |
jamielennox | but all of this is happening within the process, it's not like there is some way you could inject different environment variables from outside | 11:56 |
jamielennox | it's a matter of configuration | 11:56 |
jamielennox | also 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 hierarchy | 11:58 |
samueldmq | jamielennox: hmm, but in the case of hierarchy it will be only used for quota purposes, but I am considering your suggestion | 11:59 |
jamielennox | samueldmq: 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 ways | 12:02 |
samueldmq | jamielennox: I wonder if, a day, we could map url_calls to what is needed for them, that way middleware could fetch the needed info | 12:03 |
samueldmq | jamielennox: like for quota calls, I'd say nova will need to know the hierarchy, and then middleware fetches it for that case | 12:04 |
jamielennox | samueldmq: i guess it depends on how often we expect services to need to resolve the hierarchy | 12:04 |
samueldmq | jamielennox: 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 .. etec | 12:04 |
jamielennox | if it's quota then i would guess that's for every create operation | 12:05 |
samueldmq | jamielennox: for now it's only quota operations | 12:05 |
jamielennox | samueldmq: right but quota gets checked when you create a vm, create an image, a snapshot whatever | 12:05 |
jamielennox | i'm not sure if it gets updated when you remove those things or not | 12:05 |
samueldmq | jamielennox: actually when you create resources, you only touch the quota of that porject, so no need to get the hierarhcy | 12:06 |
samueldmq | jamielennox: when you update its quota, however, you need to update parent's quota, that's all | 12:06 |
samueldmq | ericksonsantos: ^ right | 12:06 |
ericksonsantos | samueldmq, ++ | 12:06 |
samueldmq | ? | 12:06 |
ericksonsantos | makes sense | 12:06 |
jamielennox | it's stored cumulatively? | 12:07 |
samueldmq | jamielennox: the parent know what quota portion is delegated to its children, that's all .. the children the care about their own children, and so on | 12:07 |
jamielennox | ok... | 12:08 |
samueldmq | jamielennox: 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 |
jamielennox | seems lacking but whateer | 12:08 |
*** yottatsa has quit IRC | 12:09 | |
*** markvoelker has joined #openstack-keystone | 12:09 | |
jamielennox | it implies that you delegate quota ahead of time rather than just my quota is everything i'm using + my children | 12:09 |
*** fhubik is now known as fhubik_afk | 12:09 | |
*** fhubik_afk is now known as fhubik_eng | 12:09 | |
jamielennox | not the point i guess | 12:09 |
samueldmq | jamielennox: yeah you delegate the quota, as you have your own | 12:09 |
samueldmq | jamielennox: you 'allocate' the cquota ahead of time | 12:09 |
*** yottatsa has joined #openstack-keystone | 12:10 | |
jamielennox | ok | 12:10 |
jamielennox | so what's the issue how to use keystoneclient to do that? | 12:10 |
samueldmq | jamielennox: know keystone url .. | 12:11 |
samueldmq | jamielennox: that's where I asked your advice | 12:11 |
samueldmq | jamielennox: also we need to check if the url is v3 :) | 12:11 |
*** topol has joined #openstack-keystone | 12:11 | |
*** ChanServ sets mode: +v topol | 12:11 | |
jamielennox | you shouldn't | 12:11 |
*** gordc has joined #openstack-keystone | 12:11 | |
*** iurygregory has joined #openstack-keystone | 12:11 | |
samueldmq | jamielennox: so how do I do that ? | 12:11 |
jamielennox | make a session, don't know how, attach the plugin that is passed down from auth_token middleware | 12:11 |
jamielennox | or you might have to create one from context, i don't know how far cinder got with that | 12:12 |
samueldmq | jamielennox: hmmmmm , so auth_token passes the plugin ? how does it pass that ? | 12:12 |
jamielennox | env['keystone.token_auth'] i think | 12:12 |
samueldmq | jamielennox: do you have any example of that anywhere ? also we need fallback to the 'manual' instantiation if it isn't possibel to get a plugin | 12:13 |
samueldmq | jamielennox: or should the plugin always be available ? | 12:13 |
*** raildo has joined #openstack-keystone | 12:13 | |
jamielennox | samueldmq: 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 context | 12:13 |
*** markvoelker has quit IRC | 12:14 | |
jamielennox | and we don't serialize that plugin into the context yet | 12:14 |
jamielennox | i need to get back to that | 12:14 |
samueldmq | jamielennox: I could simply look at the auth_token section of the config .. | 12:14 |
samueldmq | jamielennox: and instantiate the ksclient .. is that what you're saying all the time ? :) | 12:14 |
jamielennox | samueldmq: morganfainberg sent another email about this, services should not touch the auth_token config section | 12:15 |
jamielennox | assume it doesn't exist | 12:15 |
jamielennox | you can get the keystone url from the service catalog | 12:15 |
jamielennox | and the plugins will do that for you | 12:15 |
samueldmq | jamielennox: ok it never existed to me anyway :B | 12:15 |
jamielennox | i just don't know how cinder works internally if the plugin is there | 12:15 |
samueldmq | jamielennox: is there any documentation about such plugins ? I am not familiar with that | 12:15 |
jamielennox | samueldmq: i'm not sure https://github.com/openstack/nova/blob/master/nova/context.py#L37 is the one nova creates | 12:16 |
jamielennox | i don't know what cinder does internally | 12:16 |
jamielennox | https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L164 is where it is defined in passing down | 12:17 |
samueldmq | jamielennox: nice, thansk for the links, they'll very helpful :) | 12:18 |
samueldmq | jamielennox: we'll look at how to get that inside cinder | 12:18 |
jamielennox | samueldmq: find me again tomorrow we can chat some more, i need to sleep - the keystone meeting is not far away | 12:19 |
ericksonsantos | jamielennox, thanks | 12:19 |
jamielennox | np | 12:19 |
samueldmq | jamielennox: great thanks, sleep well :) | 12:19 |
*** josecastroleon has joined #openstack-keystone | 12:22 | |
*** jiaxi has joined #openstack-keystone | 12:23 | |
*** mestery has joined #openstack-keystone | 12:27 | |
*** diegoadolfo has joined #openstack-keystone | 12:27 | |
*** jiaxi has quit IRC | 12:28 | |
*** markvoelker has joined #openstack-keystone | 12:29 | |
*** bknudson has joined #openstack-keystone | 12:30 | |
*** ChanServ sets mode: +v bknudson | 12:30 | |
*** stevemar has joined #openstack-keystone | 12:31 | |
*** ChanServ sets mode: +v stevemar | 12:31 | |
*** edmondsw has joined #openstack-keystone | 12:33 | |
*** stevemar has quit IRC | 12:38 | |
*** stevemar has joined #openstack-keystone | 12:45 | |
*** ChanServ sets mode: +v stevemar | 12:45 | |
*** btully has joined #openstack-keystone | 12:56 | |
*** gordc is now known as gordc_meeting | 12:56 | |
odyssey4me | jamielennox it seems that you and I are working through a similar issue | 12:57 |
samueldmq | odyssey4me: I think jamielennox is sleeping :) | 12:57 |
odyssey4me | ah, ok | 12:58 |
*** bknudson has quit IRC | 12:59 | |
*** btully has quit IRC | 13:00 | |
*** afazekas has quit IRC | 13:02 | |
*** henrynash has joined #openstack-keystone | 13:03 | |
*** ChanServ sets mode: +v henrynash | 13:03 | |
*** jsavak has joined #openstack-keystone | 13:04 | |
*** TheIntern has joined #openstack-keystone | 13:13 | |
*** jiaxi has joined #openstack-keystone | 13:14 | |
*** edmondsw has quit IRC | 13:14 | |
jiaxi | dstanek: Hello, David. Did you get up ? | 13:14 |
dstanek | jiaxi: hello, yep | 13:14 |
dstanek | jiaxi: it's 9am here so i've been up for a while | 13:15 |
*** hrou has joined #openstack-keystone | 13:15 | |
jiaxi | dstanek: I'm surprised. | 13:15 |
*** rdo has quit IRC | 13:15 | |
dstanek | jiaxi: why's that? | 13:15 |
jiaxi | After many many hours, Jenkins didn't give me +1 | 13:16 |
*** zzzeek has joined #openstack-keystone | 13:17 | |
jiaxi | dstanek: Did't give any response ? Was the jenkins sick ? | 13:17 |
dstanek | jiaxi: it's having problems right now and it catching back up | 13:17 |
jiaxi | dstanek: Okay, I think it's time for +2 now. Please have a look at it. | 13:18 |
jiaxi | dstanek: Jekins will give +1. Because I run tox successfully. | 13:18 |
jiaxi | https://review.openstack.org/#/c/200512/ | 13:18 |
*** browne has joined #openstack-keystone | 13:19 | |
jiaxi | In China, We will pay for using google. | 13:19 |
*** mylu has joined #openstack-keystone | 13:19 | |
henrynash | jiaxi: I’ve taken it…and asked for more info….I can’t see the issue right now | 13:20 |
jiaxi | henrynash: Why ? | 13:20 |
*** bknudson has joined #openstack-keystone | 13:20 | |
*** ChanServ sets mode: +v bknudson | 13:20 | |
henrynash | jiaxi: why, what? :-) | 13:21 |
jiaxi | henrynash: Nearly 8 hours . Jekins is still running? Or didn't run ever. | 13:21 |
samueldmq | henrynash: hi, good morning sir :) | 13:21 |
samueldmq | henrynash: just replied your comment in https://review.openstack.org/#/c/134655/ | 13:21 |
henrynash | jiaxi: sorry, we are probably talking at cross purposes….I was talking about the big report | 13:22 |
jiaxi | henrynash: https://review.openstack.org/#/c/200512/ Jenkins didn't test my patch set | 13:22 |
samueldmq | henrynash: endpoint_ids is a config as any other, but that is a list (multiple values), like : endpoint_ids=id1,id2,id3 | 13:22 |
henrynash | samueldmq: Ok, so I’m probably just being dumb, but I still down’t get what it is for | 13:22 |
henrynash | samuedlmq: why do we need it | 13:22 |
samueldmq | henrynash: no you're not being dumb | 13:22 |
henrynash | samuedlmq: (believe me, it happens plenty!) | 13:23 |
jiaxi | henrynash: Okay, hurry up. Come on | 13:23 |
samueldmq | henrynash: endpoint policy extension associate policies with endpoints by their ids, right ? | 13:23 |
henrynash | samueldmq: yes (or to their service type and/or region) | 13:23 |
samueldmq | henrynash: so the endpoint need to know what ids represent it in the keystoene server | 13:23 |
samueldmq | henrynash: yes, but the lower level is id | 13:23 |
henrynash | samueldmq: OH….so this is instead of mapping url to id? | 13:24 |
samueldmq | henrynash: once the sevice endpoint knows who it is, it will say to keystone :'hey I am X, gimme my policy" | 13:24 |
jiaxi | samueldmq: 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 |
samueldmq | henrynash: 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 step | 13:24 |
samueldmq | jiaxi: I am not allowed to +2 it | 13:25 |
henrynash | and is this in the endpoint’s project config (e.g. nova.conf) or in the keystone.conf | 13:25 |
samueldmq | jiaxi: I am not a keystone core, sorry | 13:25 |
jiaxi | henrynash:samueldmq: What question are you talking about ? | 13:25 |
samueldmq | henrynash: as i t will identify the endpoints, it will be in the middleware config of each service | 13:25 |
samueldmq | henrynash: in the [keystone_authtoker] of the service config | 13:26 |
jiaxi | samueldmq: Maybe +1 It's openstackclient. Not keystone | 13:26 |
samueldmq | jiaxi: will take a look in a bit :) | 13:26 |
henrynash | samueldmq: the middleware config of each services…..thinking…..now I am being dumb…what’s the “middleware of each service”? | 13:26 |
dstanek | jiaxi: jenkins is running behind because it had problems last night | 13:27 |
samueldmq | henrynash: in the service pipeline, they deploy ksmiddleware, that receives the requests before the service itself receives it | 13:27 |
samueldmq | henrynash: that's clear, right ? | 13:27 |
jiaxi | dstanek: Okay. | 13:28 |
samueldmq | henrynash: from the endpoint pov, knowing who it is will serve for 2 purposes: i) fetch my policy from the server | 13:28 |
henrynash | samueldmq: …. 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 spec | 13:28 |
samueldmq | henrynash: ii) enforce endpoint constraint, which is gyee's work | 13:28 |
samueldmq | henrynash: basically yes, but for multiple processes behind a proxy, they are the same endpoint entity in keystone server | 13:29 |
samueldmq | henrynash: so they'd get teh same ids | 13:29 |
jiaxi | dstanek: Are you still core of openstackclient, David ? | 13:29 |
henrynash | samueldmq: and why is this better than having a url to id lookup? | 13:30 |
samueldmq | henrynash: we will provide the url -> lookup in a follow on work, but that doesn't work in all the case | 13:31 |
samueldmq | s | 13:31 |
samueldmq | henrynash: let me clarify : | 13:31 |
samueldmq | henrynash: 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 catalog | 13:32 |
samueldmq | henrynash: so we can't resolve url -> id, right ? | 13:32 |
samueldmq | henrynash: if the deployer is doing the sort of thing, he will need to set the ids directly in the config | 13:32 |
henrynash | samueldmq: ok, yep can see that issue...but | 13:32 |
samueldmq | henrynash: https://review.openstack.org/#/c/134655/15/specs/backlog/dynamic-policies-fetch-cache.rst | 13:32 |
henrynash | samueldmq: I really don’t udnerstand this sentenace: “so the endpoint need to know what ids represent it in the keystoene serve” | 13:32 |
samueldmq | henrynash: L 201 - 204 | 13:32 |
samueldmq | henrynash: ok so a running service endpoint can have multiple urls in keystone, as an entity | 13:33 |
henrynash | samueldmq: the endpoint has more than one id in the keystones serve? | 13:33 |
samueldmq | henrynash: public, internal and amdin interfaces | 13:33 |
samueldmq | henrynash: so multiple ids | 13:33 |
samueldmq | henrynash: yeeeeeeeeees, and that model is bad imo | 13:33 |
openstackgerrit | Marek Denis proposed openstack/keystone: Fernet payloads for federated scoped tokens. https://review.openstack.org/202176 | 13:33 |
samueldmq | henrynash: in v2 different interfaces had a single id, in v3 they are different ids | 13:33 |
samueldmq | henrynash: I don't like that at all | 13:34 |
dstanek | jiaxi: no, what's up? | 13:34 |
jiaxi | dstanek: 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 |
henrynash | samueldmq: I guess conceptually that does make sense…..(although definitely complicates things) | 13:36 |
samueldmq | henrynash: yeah that complicates things ... | 13:36 |
samueldmq | henrynash: there was a bug I saw another day | 13:36 |
samueldmq | henrynash: that enpoints registered with v3 couldn't be seen with v2 | 13:36 |
henrynash | samueldmq: Ok, so now at least I understand why we need this thing | 13:36 |
samueldmq | henrynash: you know why ? because there is no way to map multiple dids back to a single one (a single endpoint entity) | 13:37 |
samueldmq | henrynash: yeah, we can fix the endpoint model later, if needed, but that's a separate issue | 13:37 |
dstanek | jiaxi: i'm not sure i understand the commit message | 13:37 |
jiaxi | dstanek: You are the top coder of the world..... | 13:38 |
jiaxi | dstanek: Just +1. Needn't understand ... | 13:38 |
jiaxi | dstanek: :) | 13:38 |
dstanek | jiaxi: i can't +1 if i don't understand :-P | 13:38 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Refactor _supports_bind method https://review.openstack.org/197699 | 13:39 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Fetch and Cache https://review.openstack.org/134655 | 13:39 |
*** btully has joined #openstack-keystone | 13:39 | |
samueldmq | henrynash: look at it now, I added a sentence clarifying we need to define that for each service endpoint ^ | 13:40 |
dstanek | jiaxi: i'll take a look in a little bit; i don't have that code checked out for reference | 13:41 |
jiaxi | dstanek: Okay | 13:42 |
*** Nirupama has quit IRC | 13:45 | |
*** jsavak has quit IRC | 13:47 | |
*** fhubik_eng is now known as fhubik | 13:49 | |
marekd | odyssey4me: Hey! | 13:49 |
marekd | odyssey4me: 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/1471289 | 13:50 |
openstack | Launchpad 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 IRC | 13:50 | |
marekd | it worked on my env | 13:50 |
openstackgerrit | Dave Chen proposed openstack/keystone: Show helpful message when request body is not provided https://review.openstack.org/195903 | 13:50 |
*** jsavak has joined #openstack-keystone | 13:51 | |
*** belmoreira has quit IRC | 13:51 | |
*** edmondsw has joined #openstack-keystone | 13:51 | |
marekd | morganfainberg: how bad is the fact that I just started keeping groups in scoped federated fernet tokens? | 13:54 |
openstackgerrit | Dave Chen proposed openstack/keystone: Show helpful message when request body is not provided https://review.openstack.org/195903 | 13:55 |
*** jsavak has quit IRC | 13:56 | |
*** jsavak has joined #openstack-keystone | 13:56 | |
odyssey4me | marekd great, I'll give it a try | 13:56 |
*** sigmavirus24_awa has joined #openstack-keystone | 13:57 | |
marekd | odyssey4me: i might have missed some corner cases, however it is unlikely | 13:57 |
*** stevemar has joined #openstack-keystone | 13:57 | |
*** ChanServ sets mode: +v stevemar | 13:57 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 13:57 | |
*** ajayaa has quit IRC | 13:58 | |
mylu | Hi 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 IRC | 14:02 | |
*** chenhong has joined #openstack-keystone | 14:04 | |
dstanek | mylu: do you have a link to the commits? | 14:04 |
dstanek | do we document the endpoint url formatting anywhere? | 14:05 |
mylu | dstanek: I saw the commit history on openstack-dev/devstack https://github.com/openstack-dev/devstack/commits/master?page=2 | 14:05 |
jiaxi | henrynash: 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 |
dstanek | mylu: 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 |
mylu | dstanek: the new one | 14:09 |
dstanek | mylu: this is after a ./stack.sh? | 14:09 |
mylu | dstanek: I deployed the working on on Jul 13 4pm | 14:09 |
mylu | dstanek: yes. ./stack.sh run successfully | 14:09 |
mylu | dstanek: also the new one doesn't have anything on the identity page on horizon | 14:10 |
dstanek | mylu: are you using apache for keystone? | 14:10 |
mylu | dstanek: yes | 14:10 |
*** boris-42 has joined #openstack-keystone | 14:10 | |
jiaxi | henrynash: Why didn't openstackclient channel exist ? | 14:10 |
dstanek | mylu: not sure. you may want to ask in the QA channel - i think they are the ones that manage devstack | 14:10 |
mylu | dstanek: ahh ok thanks! | 14:11 |
*** chenhong has quit IRC | 14:12 | |
*** richm has joined #openstack-keystone | 14:14 | |
*** jecarey_ has joined #openstack-keystone | 14:14 | |
henrynash | jiaxi: 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 right | 14:16 |
jiaxi | henrynash: 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 |
henrynash | jiaxi: please do! | 14:19 |
openstackgerrit | Marek Denis proposed openstack/keystone: Fernet payloads for federated scoped tokens. https://review.openstack.org/202176 | 14:19 |
jiaxi | In common/quota.py COMPUTE_QUOTAS dict. key ==value | 14:19 |
marekd | lbragstad: dolphm ^^ | 14:19 |
jiaxi | So when we use value as a key to get value, is ok | 14:20 |
jiaxi | henrynash: Because it runs okay, so there is no need to change it. | 14:20 |
jiaxi | I have the test log in the launchpat | 14:21 |
henrynash | jiaxi: you mean in the volume quotos dict key=value, or in the compuet one? | 14:22 |
jiaxi | in volume | 14:22 |
jiaxi | henrynash: in compute, some key = value, others not. but when you use key, all is fine. | 14:22 |
jiaxi | https://bugs.launchpad.net/keystone/+bug/1420104, In the comment, I have explained in details. | 14:23 |
openstack | Launchpad bug 1420104 in python-openstackclient "quota set failed" [Medium,In progress] - Assigned to jiaxi (tjxiter) | 14:23 |
henrynash | jiaxi: 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 |
henrynash | jiaxi: 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 code | 14:24 |
jiaxi | henrynash: In dict, we tranfer value through the value. but use the key as a key to store value. | 14:25 |
jiaxi | henrynash: So key should equal to value. when ignore '-' and '_' | 14:26 |
jiaxi | henrynash: when use a-b-c 12 in command, then the value of a-b-c will be store as a_b_c = 12 | 14:27 |
jiaxi | henrynash: 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 now | 14:29 |
henrynash | jiaxi: all seems very straneg to me….. | 14:30 |
openstackgerrit | Marek Denis proposed openstack/keystone: Skip rows with empty remote_ids https://review.openstack.org/206561 | 14:30 |
jiaxi | henrynash: Do you agree with me? | 14:30 |
jiaxi | henrynash: You can debug it. Then you will stand in my side. | 14:31 |
jiaxi | henrynash: Please verify it use debug. Or use cmd. | 14:31 |
*** henrynash has quit IRC | 14:31 | |
*** henrynash has joined #openstack-keystone | 14:32 | |
*** ChanServ sets mode: +v henrynash | 14:32 | |
jiaxi | henrynash: Please read my comments in https://bugs.launchpad.net/keystone/+bug/1420104 | 14:33 |
openstack | Launchpad bug 1420104 in python-openstackclient "quota set failed" [Medium,In progress] - Assigned to jiaxi (tjxiter) | 14:33 |
*** ChanServ sets mode: +o dolphm | 14:35 | |
*** stevemar has joined #openstack-keystone | 14:38 | |
*** ChanServ sets mode: +v stevemar | 14:38 | |
samueldmq | is jenkins broken ? | 14:40 |
openstackgerrit | Boris Bobrov proposed openstack/keystone: Test function call result, not function object https://review.openstack.org/206567 | 14:41 |
dstanek | jiaxi: i found a few things in that url review; i'll post some comments in a bit | 14:43 |
samueldmq | dstanek: any chance to get one more review on #134655 and #197980 before meeting, so I could update them if needed | 14:45 |
samueldmq | dstanek: they're the dynamic policy specs, one has a +2 from henrynash | 14:45 |
*** ajayaa has joined #openstack-keystone | 14:45 | |
samueldmq | dstanek: and I already addressed your comments (and dolphm's comments) from last week | 14:46 |
henrynash | dstanek: the mark of death, surely | 14:46 |
*** stevemar has quit IRC | 14:46 | |
dstanek | samueldmq: sure, i can look again | 14:46 |
dstanek | henrynash: :-P | 14:46 |
samueldmq | dstanek: great thanks | 14:46 |
jiaxi | dstanek: Okey, Looking forward to your comments. | 14:46 |
samueldmq | henrynash: dstanek what does that mean ? dstanek will certainly -1 it ? :-) | 14:47 |
jiaxi | henrynash: Have you read my comments in the launchpad ? | 14:47 |
henrynash | samueldmq: dstanek stares death in the face and doesn’t flinch….he’s that kind of core | 14:47 |
lbragstad | dolphm: responded to your comment here https://review.openstack.org/#/c/196877/11/keystone/token/providers/common.py | 14:47 |
lbragstad | dolphm: does that make sense? | 14:47 |
samueldmq | henrynash: hehe | 14:48 |
samueldmq | ++ | 14:48 |
dolphm | lbragstad: why is there a token ID in token ref only sometimes? | 14:50 |
dolphm | lbragstad: again, feels like a bug if there's an inconsistency... | 14:50 |
lbragstad | dolphm: agreed, I need to try and dig into the auth api to see what happens before the token provider api is called | 14:51 |
jiaxi | henrynash: What do you think about https://review.openstack.org/#/c/203312/ | 14:51 |
lbragstad | by the time the token_ref hits the validate_v3_token method, it's already either a dict or a string. | 14:52 |
henrynash | jiaxi: I have commented on it…in my view volume quota code is still (conceptually) incorrect, even if we get away with it right now | 14:52 |
*** jasonsb has quit IRC | 14:53 | |
*** stevemar has joined #openstack-keystone | 14:54 | |
*** ChanServ sets mode: +v stevemar | 14:54 | |
jiaxi | henrynash: I have replied it. I | 14: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 fact | 14:57 |
dolphm | lbragstad: 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 |
dolphm | lbragstad: string* to a dict | 14:58 |
*** woodster_ has joined #openstack-keystone | 14:58 | |
jiaxi | henrynash: dstanek: Jenkins is terribly ill. Give -1 to my patch. That's not right. | 14:59 |
lbragstad | dolphm: me too, this doesn't seem to shed much light on it either. https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L531 | 14:59 |
dstanek | jiaxi: which patch? | 14:59 |
jiaxi | https://review.openstack.org/#/c/200512/ | 14:59 |
*** diazjf has joined #openstack-keystone | 15:00 | |
lbragstad | dolphm: that's technically what gets passed in as a 'dict' | 15:00 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Add is_domain in token response https://review.openstack.org/197331 | 15:00 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Bye Bye Domain Table https://review.openstack.org/161854 | 15:00 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Honor domain operations in project table https://review.openstack.org/143763 | 15:00 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Change policy to comply with is_domain in token https://review.openstack.org/206063 | 15:00 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Remove domain table references https://review.openstack.org/165936 | 15:00 |
lbragstad | or it's treated like a dict in token_provider_api.validate_v3_token() | 15:00 |
*** jsavak has quit IRC | 15:01 | |
dolphm | lbragstad: token_id should certainly be a string there | 15:02 |
lbragstad | dolphm: I agree | 15:02 |
dolphm | lbragstad: is it the v2 controller doing something odd? | 15:02 |
dolphm | lbragstad: or HEAD vs GET? | 15:02 |
lbragstad | let me check | 15:02 |
dolphm | lbragstad: or like auth_context calling validate for x-auth-token? | 15:03 |
*** henrynash has quit IRC | 15:03 | |
*** jsavak has joined #openstack-keystone | 15:04 | |
lbragstad | dolphm: grepping doesn't give any results for 'validate_v2_token' under keystone/auth/ | 15:04 |
dolphm | lbragstad: keystone/token/controllers.py is where the v2 token stuff lives | 15:05 |
*** diegoadolfo has quit IRC | 15:07 | |
*** amakarov is now known as amakarov_away | 15:11 | |
*** gordc_meeting has quit IRC | 15:12 | |
*** mylu has quit IRC | 15:13 | |
dstanek | lbragstad: dolphm: i did some unicode surgery on fernet tokens that i'll be pushing soon. i'd appreciate your eyes on it | 15:15 |
dolphm | dstanek: sweet | 15:17 |
jiaxi | dstanek: https://review.openstack.org/#/c/200512/ my patch set. Please have a look. It's deep night in Beijing. | 15:17 |
dstanek | jiaxi: yeah, i'm working on a revision to it now | 15:17 |
jiaxi | dstanek: David. Before go to bed, I want to update my code according to your comments. | 15:18 |
*** mylu has joined #openstack-keystone | 15:18 | |
jiaxi | dstanek: I go to have a bath for minutes. come back soon. | 15:19 |
lbragstad | dstanek: will do | 15:20 |
*** ayoung has joined #openstack-keystone | 15:20 | |
*** ChanServ sets mode: +v ayoung | 15:20 | |
*** mestery has quit IRC | 15:20 | |
*** TheIntern has quit IRC | 15:22 | |
*** jsavak has quit IRC | 15:24 | |
*** jsavak has joined #openstack-keystone | 15:25 | |
*** TheIntern has joined #openstack-keystone | 15:25 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Fetch and Cache https://review.openstack.org/134655 | 15:28 |
lbragstad | dolphm: figured it out -- https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L238-L243 | 15:31 |
*** browne has quit IRC | 15:32 | |
lbragstad | dolphm: this token_id is always a string https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L529 | 15:32 |
*** fhubik is now known as fhubik_afk | 15:33 | |
*** topol has quit IRC | 15:33 | |
*** topol has joined #openstack-keystone | 15:34 | |
*** ChanServ sets mode: +v topol | 15:34 | |
*** mestery has joined #openstack-keystone | 15:34 | |
*** topol has quit IRC | 15:34 | |
dolphm | lbragstad: \o/ that whole method is super confusing | 15:35 |
ayoung | bknudson, https://pypi.python.org/pypi/pyldap is an attempt to get Py3 support in the existing python-ldap codebase. | 15:35 |
dolphm | lbragstad: L232 should be moved into the else block... | 15:35 |
*** fhubik_afk is now known as fhubik | 15:35 | |
dolphm | lbragstad: so we're passing refs from the cache into validate token? | 15:36 |
dolphm | lbragstad: maybe that should be a separate method call - like validate_cached_token() or something | 15:36 |
jiaxi | dstanek: Hello. David. | 15:36 |
ayoung | dolphm, it can't be in the else block...defaults take over. If the user explicitly requests and unscoped, it need to take precedence | 15:37 |
dolphm | ayoung: but it doesn't do anything with unique_id unless it's a persistent token? | 15:38 |
*** aix has quit IRC | 15:38 | |
lbragstad | correct | 15:38 |
lbragstad | dolphm: what about it if we did something like | 15:38 |
dolphm | lbragstad: maybe my notion of validate_cached_token() is what is actually implemented as _is_valid_token() | 15:38 |
ayoung | dolphm, think I am lookuing at the wrong file. THought you meant https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L232 | 15:38 |
ayoung | dolphm, I assume you actually meant https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L232 | 15:39 |
dolphm | lbragstad: what's the difference between token_ref and token there? | 15:39 |
dolphm | ayoung: ah, yeah. i'm looking at the code lance sent | 15:39 |
ayoung | dolphm, 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 wonky | 15:40 |
*** pballand has joined #openstack-keystone | 15:40 | |
lbragstad | http://cdn.pasteraw.com/j7w55wmsv3zrv8diu8ve4c2p7tey1e | 15:41 |
*** josecastroleon has quit IRC | 15:41 | |
dolphm | lbragstad: is _validate_token_id() already a thing? | 15:41 |
lbragstad | dolphm: here it is - https://review.openstack.org/#/c/196877/11/keystone/token/providers/common.py | 15:41 |
dolphm | lbragstad: ah | 15:42 |
dolphm | lbragstad: so that returns a token_ref? | 15:43 |
lbragstad | dolphm: I could make those methods public (validate_token_id and validate_token_ref) | 15:43 |
lbragstad | yeah | 15:43 |
lbragstad | they both use the v3_token_data_helper object to rebuild the reference | 15:43 |
dolphm | lbragstad: somehow, the token_ref = token_id needs to go away | 15:43 |
lbragstad | I agree. | 15:43 |
lbragstad | I can hack something together and a new patch | 15:43 |
dolphm | lbragstad: so, token_ref = self._validate_token_id(token_id) ? | 15:43 |
lbragstad | yep | 15:44 |
dolphm | lbragstad: okay, then i think that makes sense | 15:44 |
dolphm | lbragstad: send another diff! or review | 15:44 |
lbragstad | dolphm: I'll push a new patch | 15:44 |
*** stevemar has quit IRC | 15:44 | |
*** gordc has joined #openstack-keystone | 15:45 | |
jiaxi | dstanek: https://review.openstack.org/#/c/200512/. I replied to your response. Hope for your reply. | 15:46 |
jiaxi | dstanek: Hi, David. I have replied to your comments. I think that you are a litter too serious. | 15:47 |
dolphm | ayoung: 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=sharing | 15:47 |
jiaxi | a litter->a little | 15:47 |
jiaxi | dstanek: https://review.openstack.org/#/c/200512/. I have replied. Looking forward to your reply. | 15:48 |
dstanek | jiaxi: serious? | 15:49 |
ayoung | dolphm, so no change. interesting. My guess is that the tree then basically resolves to a linear search. | 15:49 |
ayoung | actually, I had just looked at the top line | 15:49 |
ayoung | significnat speedup via the tree for the other cases | 15:50 |
ayoung | but maybe not enough to warrant the more complex code? | 15:50 |
*** _cjones_ has joined #openstack-keystone | 15:51 | |
ayoung | dolphm, thanks for running that. | 15:51 |
dolphm | ayoung: you think the list implementation is more complex? | 15:52 |
ayoung | dolphm, no, other way round | 15:53 |
ayoung | I think the list is slower, but easier to understand | 15:53 |
dolphm | ayoung: right, okay | 15:53 |
*** jsavak has quit IRC | 15:54 | |
dolphm | ayoung: in the first two benchmarks, the tree and list are basically empty, so i imagine there's enough load to distinguish a meaningful difference | 15:54 |
dolphm | ayoung: hence i ran the benchmark 10 times each lol | 15:54 |
ayoung | dolphm, 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 |
dolphm | ayoung: i vote for the tree | 15:54 |
dolphm | ayoung: and i *hate* complexity :) | 15:55 |
ayoung | dolphm, I wonder if we can somehow make that code more readable. | 15:55 |
jiaxi | dstanek: David, Could you spare some minutes in replying my reply to your comments. https://review.openstack.org/#/c/200512/ | 15:55 |
ayoung | But, I agree that the tree should perform faster than the list; good to know that it does. | 15:56 |
dstanek | jiaxi: i don't see a reply | 15:56 |
jiaxi | dstanek: Review is ill too ? | 15:58 |
dolphm | jiaxi: 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 gerrit | 15: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? Edit | 15:59 |
*** spandhe has joined #openstack-keystone | 15:59 | |
dstanek | jiaxi: your comment is a draft which means you have not published it yet | 15:59 |
dstanek | jiaxi: press the 'Add comment' button | 16:00 |
dstanek | jiaxi: your drafts are always private | 16:00 |
jiaxi | dstanek: Okay, I will add soon. | 16:01 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Consolidate the fernet provider validate_v3_token() https://review.openstack.org/196877 | 16:01 |
lbragstad | dolphm: ^ | 16:01 |
*** jsavak has joined #openstack-keystone | 16:01 | |
jiaxi | dstanek: Okay, Done. | 16:02 |
dstanek | jiaxi: i'm trying to finish up one last thing and then i'll post the updated patchset. having doc building trouble right now | 16:02 |
jiaxi | dstanek: Ok, waiting for you | 16:03 |
*** ankita_wagh has joined #openstack-keystone | 16:04 | |
* dolphm <rant> i hate variable names that end with _data ... of course it's data, it's a damn variable</rant> | 16:05 | |
morganfainberg | dolphm: i'm going to start renaming all variables to _data | 16:05 |
morganfainberg | dolphm: ;0 | 16:06 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Consolidate the fernet provider issue_v2_token() https://review.openstack.org/197647 | 16:06 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Refactor _supports_bind method https://review.openstack.org/197699 | 16:06 |
*** yottatsa has quit IRC | 16:09 | |
*** yottatsa has joined #openstack-keystone | 16:10 | |
dolphm | morganfainberg: the same applies to _info | 16:12 |
morganfainberg | dolphm: variable_data_info_data_data_info | 16:12 |
morganfainberg | new scheme for everything | 16:12 |
lbragstad | _ref isn't quite as bad, but that could be clearer, too | 16:12 |
morganfainberg | lbragstad: s/_ref/_data_data_data_data_badger_burger_data | 16:13 |
lbragstad | ++ to badger | 16:13 |
dstanek | strange....getting a error building docs because keystone.cmd.rst isn't included in a doctree | 16:13 |
morganfainberg | badger badger badger badger badger badger snake | 16:13 |
dolphm | lbragstad: already showing merge conflict on https://review.openstack.org/#/c/197699/ | 16:14 |
dolphm | morganfainberg: mushroom mushroom | 16:14 |
morganfainberg | dolphm: http://www.badgerbadgerbadger.com/ | 16:15 |
dolphm | morganfainberg: thanks, now the rest of my day is burned | 16:15 |
morganfainberg | dolphm: happy to help | 16:15 |
dolphm | i think my ears are being massaged by all the bass | 16:15 |
lbragstad | dolphm: yeah, there was a merge conflict on that one before. i need to investigate that | 16:16 |
openstackgerrit | David Stanek proposed openstack/keystone: Reject create endpoint with invalid urls https://review.openstack.org/200512 | 16:16 |
samueldmq | morganfainberg: hhehe haven't seen yet, that's funny :) | 16:17 |
samueldmq | but annoying too :p | 16:18 |
dolphm | samueldmq: this is from like 1999 | 16:18 |
dolphm | or maybe 2001-2003 | 16:18 |
samueldmq | dolphm: so that means I am just a bit late :) | 16:18 |
dstanek | morganfainberg: i just died a little inside | 16:18 |
samueldmq | not that much | 16:18 |
samueldmq | hehe | 16:19 |
dolphm | badgerbadgerbadger.com was registered Creation Date: 2003-09-14T01:22:15.00Z | 16:19 |
*** e0ne has quit IRC | 16:20 | |
samueldmq | dolphm: I was looking at the sourcecode , and then opened http://www.badgerbadgerbadger.com/badger.swf | 16:20 |
samueldmq | dolphm: then another tab was playing the samething | 16:20 |
samueldmq | lol | 16:20 |
*** TheIntern has quit IRC | 16:20 | |
samueldmq | same thing* | 16:20 |
dolphm | in 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 unison | 16:21 |
samueldmq | "Anything on your mind? Suggestions? Comments? Send them to info (at) badgerbadgerbadger.com" | 16:21 |
lbragstad | dolphm: lol nice | 16:22 |
samueldmq | dolphm: hahah that must have been very funny | 16:22 |
*** jistr has quit IRC | 16:22 | |
*** spandhe has quit IRC | 16:23 | |
*** jiaxi has quit IRC | 16:24 | |
*** browne has joined #openstack-keystone | 16:25 | |
dolphm | Installing Linux on a Dead Badger: User's Notes http://www.strangehorizons.com/2004/20040405/badger.shtml | 16:25 |
lbragstad | whoever wrote that has too much time on their hands... | 16:26 |
samueldmq | aha very true | 16:27 |
samueldmq | "VüDü Tech Tips" ... | 16:28 |
samueldmq | look at the section "Common Problems" hahaha | 16:28 |
lbragstad | marekd: 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.py | 16:29 |
*** fhubik has quit IRC | 16:31 | |
*** jasonsb has joined #openstack-keystone | 16:31 | |
dstanek | samueldmq: don't hate me! | 16:36 |
dstanek | samueldmq: lol, those two spec share a *ton* of content | 16:37 |
samueldmq | dstanek: hate you ? | 16:37 |
samueldmq | dstanek: again? | 16:37 |
samueldmq | dstanek: ahha kidding :) I am looking at your comments now | 16:38 |
samueldmq | dstanek: and yeah, I added more details in there, as henrynash asked for more details | 16:38 |
dstanek | samueldmq: i'm really curious to know if you guys came up with a clever algorithm the match URLs | 16:39 |
samueldmq | dstanek: matching URLs and solving URL -> IDs will be in a follow-on spec | 16:40 |
dstanek | won't you need it for that spec too? | 16:40 |
samueldmq | dstanek: for now we consider endpoint_ids config, that is what we need (will be solved from URL in the feature) | 16:40 |
samueldmq | dstanek: I am planning to address that as an improvement, fetching by endpoint_ids is what we need | 16:41 |
dstanek | samueldmq: 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 |
samueldmq | dstanek: providing that info in the config is the first option, discovering is like an inprovement | 16:41 |
samueldmq | dstanek: so we'll pass the ids to the server and it will decide what policy return | 16:41 |
samueldmq | dstanek: 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 |
samueldmq | dstanek: fwiw in v2 we hadn't that "issue", since different urls (interfaces) mapped to the same endpoint id | 16:43 |
dstanek | samueldmq: what happens if the service has 2 different endpoints in that config entry and each has a different policy? | 16:43 |
samueldmq | dstanek: so that is a conceptual error, explode the world | 16:44 |
samueldmq | dstanek: so .. in the service endpoitn we will have just a single policy, in that case, we will fetch one, and ignore the other | 16:44 |
samueldmq | dstanek: I think we should warn in that is the case | 16:44 |
dstanek | samueldmq: what do you mean by conceptual error. based on the tools we are giving the operators here that is entirely possible | 16:44 |
samueldmq | dstanek: yes, that is possible, but wrong imo | 16:44 |
dstanek | samueldmq: yes, so how do we prevent it? | 16:45 |
samueldmq | dstanek: because there will be only a policy locally, and why do we allow to associate multiple of them | 16:45 |
samueldmq | dstanek: that's the point, with our current endpoint model, we can't prevent | 16:45 |
dstanek | samueldmq: exactly, so why are you letting them do that? | 16:45 |
samueldmq | dstanek: because there is no way to know what endpoint_ids should be together | 16:45 |
samueldmq | in the database | 16:45 |
dstanek | samueldmq: it just seems that this needs to have more work to think through how we want it to work | 16:46 |
samueldmq | dstanek: we should fix our endpoint model (imo) howeveer there is no way to migrate current database | 16:46 |
*** ankita_wagh has quit IRC | 16:46 | |
*** ankita_wagh has joined #openstack-keystone | 16:47 | |
*** roxanaghe has joined #openstack-keystone | 16:47 | |
samueldmq | dstanek: with our current (endpoint / endpoitn policy / policy) model, this is the simpler/best we can implement | 16:47 |
samueldmq | imo | 16:47 |
samueldmq | dstanek: for me different endpoint interfaces should belong to the same endpoint entity, I don't know why we did split that when doing v2 -> v3 | 16:48 |
samueldmq | dstanek: 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 |
samueldmq | dstanek: let's create that way in v4 | 16:50 |
dstanek | samueldmq: 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 |
samueldmq | dstanek: so you can associate a policy to a service | 16:51 |
samueldmq | dstanek: and if you don't associate a policy to that endpoint specifically, that will be what it will get | 16:51 |
*** dims has quit IRC | 16:52 | |
samueldmq | dstanek: btw I need a spec in the server to specify what will be returned for GET /policy?endpoint_ids=x,y,z | 16:52 |
*** dims has joined #openstack-keystone | 16:52 | |
*** dims has quit IRC | 16:52 | |
samueldmq | dstanek: that will define how we use the endpoint policy extension to define what policy to return for an endpoint | 16:52 |
*** dims has joined #openstack-keystone | 16:53 | |
dstanek | samueldmq: again unless the code is "return policies[random.randint(0, len(policies))]" you need the URI to find the right one | 16:53 |
*** ankita_wagh has quit IRC | 16:53 | |
samueldmq | dstanek: that'd be wrong as well , so the policy would depend on the url you use to call keystone ? | 16:54 |
dstanek | samueldmq: no, the URL of the service call | 16:54 |
samueldmq | dstanek: 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 serviceendpoint | 16:55 |
samueldmq | dstanek: 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 |
samueldmq | dstanek: at least this isn't the behavior we have so far in openstack | 16:56 |
dstanek | samueldmq: 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 |
samueldmq | dstanek: there is no definition of the right one | 16:56 |
samueldmq | dstanek: we have no way to know, I think that's our model that is broken, we allow assing multiple policies to a single service endpoint | 16:57 |
*** haypo has left #openstack-keystone | 16:57 | |
samueldmq | dstanek: and after we don't know which one we should resolve to | 16:57 |
dstanek | samueldmq: 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 |
samueldmq | dstanek: assigning multiple policies is already wrong, we allow that | 16:57 |
samueldmq | dstanek: 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 associated | 16:58 |
*** snapdey has joined #openstack-keystone | 16:58 | |
dstanek | samueldmq: that's why i think we should figure out how to fix the model before we start building on top of it | 16:58 |
dstanek | samueldmq: it's mostly useless now so people probably are not using it so right now is the time to change it | 16:58 |
samueldmq | dstanek: so what I thought was to go for something simpler (like pick the first valid one) | 16:58 |
samueldmq | dstanek: and after fixing the model, it would be just renaming endpoint_ids to endpoint_ids ? | 16:59 |
*** snapdey has quit IRC | 16:59 | |
samueldmq | dstanek: that wouldn't interfeer too much in the exisitng implementation | 16:59 |
dstanek | i 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 do | 16:59 |
samueldmq | dstanek: see this paste from last week http://paste.openstack.org/show/397098/ | 17:01 |
samueldmq | dstanek: this is how I think it shoudl be | 17:01 |
samueldmq | dstanek: so anyway we need endpoint_ids to enforce the endpoint constraint gyee's working on | 17:02 |
samueldmq | dstanek: 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 api | 17:02 |
*** snapdey has joined #openstack-keystone | 17:02 | |
dstanek | samueldmq: does gyee's thing worry about the URL? | 17:02 |
*** qwebirc5854 has joined #openstack-keystone | 17:04 | |
*** mylu has quit IRC | 17:04 | |
*** mylu has joined #openstack-keystone | 17:05 | |
*** topol has joined #openstack-keystone | 17:05 | |
*** ChanServ sets mode: +v topol | 17:05 | |
dstanek | samueldmq: do my devstack does have many examples of services with multiple endpoints - to make matters worse many use the same URL | 17:05 |
samueldmq | dstanek: I think it must be enforced in the id | 17:05 |
samueldmq | dstanek: yeah devstack is doing it bad (because we made the model that way) | 17:06 |
*** jsavak has quit IRC | 17:06 | |
*** spandhe has joined #openstack-keystone | 17:06 | |
*** jsavak has joined #openstack-keystone | 17:06 | |
dstanek | samueldmq: which id the endpoint? | 17:06 |
samueldmq | dstanek: so you need to know all the endpoint ids, if you have at least one in your catalog, you're allowed | 17:07 |
samueldmq | dstanek: but that would depends in the used url (your point I guess) | 17:07 |
samueldmq | aarrrg | 17:07 |
dstanek | samueldmq: i think we are going in circles now | 17:07 |
samueldmq | dstanek: we cant be based on the url since it can be rewritten at some point in the communication | 17:08 |
samueldmq | I think | 17:08 |
dstanek | samueldmq: maybe the domain, but not the path | 17:09 |
dstanek | samueldmq: now you're making arguments on my side! | 17:09 |
samueldmq | dstanek: ehhe how do we fix that model ? write a service_endpoint api ? service_endpoint_policy API ? | 17:09 |
samueldmq | dstanek: we can't fix that easily since we cant migrate | 17:10 |
dstanek | samueldmq: you said we already support having a policy associated with a service. just do that. i'm curious about gyee's impl though | 17:10 |
*** ankita_wagh has joined #openstack-keystone | 17:11 | |
samueldmq | dstanek: if we only allow a policy per service, managing that through a CMS would be more flexible | 17:11 |
samueldmq | dstanek: since it would allow a policy per endpoint id... however we do need to know if that's a real usecase | 17:12 |
samueldmq | in your opinion, it isn't (from what I can see) | 17:12 |
dstanek | yeah, i don't know if it' | 17:12 |
dstanek | s a use case | 17:12 |
*** mylu has quit IRC | 17:13 | |
dstanek | if 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 want | 17:13 |
dstanek | that way if the day have 2 nodes (public) that would specify a different policy from the other 2 node (internal) for example | 17:14 |
samueldmq | dstanek: yeah but you loose the flexibility to change the policy id withou the need of a restart | 17:14 |
samueldmq | dstanek: we want to make the association in the server, and the endpoint say, hey "it's who I am, gimme my policy" | 17:15 |
samueldmq | dstanek: keystone would handle the complexity/association | 17:15 |
openstackgerrit | David Stanek proposed openstack/keystone: Reject create endpoint with invalid urls https://review.openstack.org/200512 | 17:15 |
*** mylu has joined #openstack-keystone | 17:16 | |
*** boris-42 has quit IRC | 17:20 | |
*** jsavak has quit IRC | 17:20 | |
*** jungler has quit IRC | 17:20 | |
*** mestery has quit IRC | 17:20 | |
*** jungler has joined #openstack-keystone | 17:21 | |
*** alex_xu has quit IRC | 17:21 | |
*** jsavak has joined #openstack-keystone | 17:21 | |
dstanek | i think that one should be a relatively easy one now ^ | 17:21 |
*** stevemar has joined #openstack-keystone | 17:21 | |
*** ChanServ sets mode: +v stevemar | 17:21 | |
*** boris-42 has joined #openstack-keystone | 17:22 | |
*** alex_xu has joined #openstack-keystone | 17:23 | |
iurygregory | hello 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 IRC | 17:27 | |
*** nkinder has quit IRC | 17:32 | |
*** ayoung has quit IRC | 17:36 | |
*** jsavak has quit IRC | 17:39 | |
*** jsavak has joined #openstack-keystone | 17:40 | |
*** mylu has quit IRC | 17:44 | |
*** snapdey has quit IRC | 17:45 | |
*** mylu has joined #openstack-keystone | 17:45 | |
*** markvoelker has quit IRC | 17:47 | |
*** piyanai has joined #openstack-keystone | 17:49 | |
*** jsavak has quit IRC | 17:50 | |
*** snapdey has joined #openstack-keystone | 17:50 | |
*** jsavak has joined #openstack-keystone | 17:50 | |
*** jsavak has quit IRC | 17:51 | |
*** jsavak has joined #openstack-keystone | 17:52 | |
marekd | iurygregory: hi, so i agree with richm 's comment. | 17:53 |
iurygregory | Thanks marekd ^^ | 17:53 |
*** mestery has joined #openstack-keystone | 17:54 | |
*** lhcheng_ has joined #openstack-keystone | 17:55 | |
*** lhcheng_ has quit IRC | 17:55 | |
*** mestery has quit IRC | 17:55 | |
samueldmq | dstanek: I am going to bring that discussion as part of the dynamic policies topic we have today | 17:56 |
*** lhcheng_ has joined #openstack-keystone | 17:56 | |
*** snapdey has quit IRC | 17:56 | |
samueldmq | dstanek: so people can take the better decision for the project now | 17:56 |
*** jsavak has quit IRC | 17:56 | |
dstanek | samueldmq: ++ | 17:57 |
*** henrynash has joined #openstack-keystone | 17:58 | |
*** ChanServ sets mode: +v henrynash | 17:58 | |
*** henrynash has quit IRC | 17:58 | |
*** henrynash has joined #openstack-keystone | 17:59 | |
*** ChanServ sets mode: +v henrynash | 17:59 | |
*** snapdey has joined #openstack-keystone | 18:00 | |
*** nkinder has joined #openstack-keystone | 18:01 | |
*** jsavak has joined #openstack-keystone | 18:01 | |
*** jungler has quit IRC | 18:04 | |
*** alex_xu has quit IRC | 18:04 | |
*** jungler has joined #openstack-keystone | 18:05 | |
*** piyanai has quit IRC | 18:06 | |
*** ayoung has joined #openstack-keystone | 18:07 | |
*** ChanServ sets mode: +v ayoung | 18:07 | |
*** jsavak has quit IRC | 18:07 | |
*** piyanai has joined #openstack-keystone | 18:08 | |
*** jsavak has joined #openstack-keystone | 18:08 | |
*** pnavarro has quit IRC | 18:08 | |
*** alex_xu has joined #openstack-keystone | 18:09 | |
*** tellesnobrega has quit IRC | 18:11 | |
*** tellesnobrega has joined #openstack-keystone | 18:15 | |
*** yottatsa has quit IRC | 18:23 | |
*** rm_work is now known as rm_work|away | 18:29 | |
*** mylu has quit IRC | 18:34 | |
*** jsavak has quit IRC | 18:36 | |
*** rdo has joined #openstack-keystone | 18:37 | |
*** josecastroleon has joined #openstack-keystone | 18:38 | |
*** mylu has joined #openstack-keystone | 18:39 | |
*** yottatsa has joined #openstack-keystone | 18:40 | |
*** markvoelker has joined #openstack-keystone | 18:42 | |
*** markvoelker_ has joined #openstack-keystone | 18:46 | |
rodrigods | henrynash, permanent +2? :) | 18:46 |
henrynash | rodigods: I wouldn;t go that far :-) | 18:47 |
morganfainberg | rodrigods: i can offer a permanent -2...but you probably don't want that | 18:47 |
*** markvoelker has quit IRC | 18:48 | |
rodrigods | morganfainberg, =( | 18:48 |
*** stevemar has quit IRC | 18:48 | |
*** diazjf has joined #openstack-keystone | 18:54 | |
*** TheIntern has joined #openstack-keystone | 18:57 | |
*** ayoung has quit IRC | 19:00 | |
samueldmq | another option should be to fix the endpoint model, i.e same id for different interfaces | 19:00 |
samueldmq | as we had for v2 | 19:00 |
samueldmq | I don't understand why we changed that, I can't see the usecase actually | 19:00 |
dstanek | samueldmq: if the middleware can be configured via the paste ini to have different ids then using endpoint id is fine | 19:01 |
dstanek | samueldmq: the specs are confusing because they contain lots of the same boilerplate and it's tough to know what is actually being proposed | 19:01 |
*** ankita_wagh has quit IRC | 19:01 | |
samueldmq | dstanek: how would that work ? what policy to fetch ? | 19:01 |
samueldmq | dstanek: yeah but some folks asked for details, motivation, use case etc | 19:02 |
*** ankita_wagh has joined #openstack-keystone | 19:02 | |
samueldmq | dstanek: I am being as much specific/detailed as I am being asked for | 19:02 |
dstanek | samueldmq: 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 problem | 19:03 |
*** e0ne has joined #openstack-keystone | 19:03 | |
samueldmq | dstanek: so 3 middlewares ? as they would be using the same policy file to write too, the last one would be kept | 19:04 |
*** jsavak has joined #openstack-keystone | 19:04 | |
henrynash | samueldmq: 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 |
dstanek | samueldmq: you are actually writing the policy file to disk yourself? | 19:05 |
samueldmq | henrynash: yeah maybe | 19:05 |
samueldmq | dstanek: yes, and use the exisitng mechanism from oslo.policy to do the overlay | 19:05 |
*** zzzeek has quit IRC | 19:06 | |
*** ankita_wagh has quit IRC | 19:06 | |
dstanek | samueldmq: if you are using the HTTP headers to cache and not using a library then the file should be named based on the request anyway | 19:06 |
*** snapdey has quit IRC | 19:07 | |
samueldmq | dstanek: I am always caching to one file, let's say: /etc/glance/dynamic-policy.json | 19:07 |
dstanek | samueldmq: if you hard code saving the file to /var/run/keystone/policy.cache then we've already lost | 19:07 |
samueldmq | dstanek: when it times out, I get another dict and write it again to that file, and so on | 19:07 |
openstackgerrit | Sam Leong proposed openstack/keystone: Tokenless authz with X.509 SSL client certificate https://review.openstack.org/156870 | 19:07 |
*** zzzeek has joined #openstack-keystone | 19:08 | |
*** josecastroleon has quit IRC | 19:08 | |
dstanek | samueldmq: that would break anything that runs multiple services on the same node | 19:08 |
dstanek | samueldmq: devstack could never have centralized policy enabled if that were the implementation | 19:09 |
samueldmq | dstanek: that's how policy.json is stored/read from the fie | 19:09 |
samueldmq | dstanek: we are using exactly the same mechanism, aren't we ? | 19:09 |
dstanek | samueldmq: maybe that's just my setup that it'll break because i have been running multiple instances of services for k2k testing | 19:11 |
samueldmq | dstanek: see https://review.openstack.org/#/c/200257/ | 19:11 |
dstanek | but that will break if you need to have endpoint policy | 19:11 |
*** qwebirc5854 has quit IRC | 19:11 | |
dstanek | sigmavirus24: 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 idiot | 19:12 |
sigmavirus24 | cachecontrol is the way to go dstanek | 19:12 |
sigmavirus24 | requests-cache was by Cory and was deprecated for CacheControl | 19:12 |
sigmavirus24 | CacheControl is far more mature and maintained by someone working on oslo.cache | 19:12 |
sigmavirus24 | dstanek: ^ | 19:12 |
*** samleon has joined #openstack-keystone | 19:12 | |
dstanek | sigmavirus24: perfect thx | 19:13 |
sigmavirus24 | you're quite welcome | 19:13 |
samueldmq | dstanek: what is that ? | 19:13 |
dstanek | samueldmq: ^ 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 headers | 19:13 |
samueldmq | dstanek: k I will take a look at it, thanks | 19:14 |
dstanek | samueldmq: https://pypi.python.org/pypi/CacheControl/0.9.3 | 19:14 |
dstanek | samueldmq: 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 cached | 19:15 |
dstanek | samueldmq: 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 |
samueldmq | dstanek: based on the Cache-COntrol header (max-age) ? | 19:15 |
samueldmq | dstanek: I mean when caching it does respect the cache control headers right ? | 19:16 |
*** jsavak has quit IRC | 19:17 | |
samueldmq | dstanek: k and what about the config, we then keep endpoint_id ? | 19:17 |
samueldmq | dstanek: and the deployer uses the same he/she used to associate the policy with using the endpoint policy extension ? | 19:18 |
samueldmq | dstanek: at this point, I am not sure how many keystoners really care about this feature/think it is worth it :( | 19:18 |
samueldmq | tbh | 19:18 |
*** henrynash has quit IRC | 19:20 | |
dstanek | samueldmq: 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 network | 19:22 |
samueldmq | dstanek: so that should be used by ksclient ? | 19:23 |
dstanek | samueldmq: 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 that | 19:23 |
dstanek | samueldmq: eventually yes, i think it should | 19:24 |
samueldmq | dstanek: ok I will update the specs, and let's see what happens | 19:25 |
samueldmq | dstanek: thanks | 19:25 |
dstanek | samueldmq: about the keystoners...i don't think it should matter too much what we want as long as there is a clear need from deployers | 19:25 |
samueldmq | dstanek: yes I've asked adam and others to review that email I wrote to send to ops list | 19:27 |
samueldmq | dstanek: didn't get too much feedback | 19:27 |
samueldmq | dstanek: I will stop listening when there is no one talking to me, I will just send it | 19:27 |
samueldmq | dstanek: as you and dolphm suggested | 19:27 |
dstanek | samueldmq: what's that link again? i thought i clicked it, but i can't find it in my huge list of tabs | 19:28 |
samueldmq | dstanek: https://etherpad.openstack.org/p/centralized-policy-delivery-operators | 19:28 |
dstanek | thx, i'll have a look | 19:28 |
*** markvoelker_ has quit IRC | 19:29 | |
samueldmq | dstanek: nice thanks, going afk for a bit | 19:29 |
* samueldmq needs some coffee | 19:29 | |
*** mestery has joined #openstack-keystone | 19:30 | |
samueldmq | morganfainberg: 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 |
samueldmq | by* | 19:33 |
*** ankita_wagh has joined #openstack-keystone | 19:34 | |
dstanek | samueldmq: i'm looking at that assignment review and it's letting me know that assignments are much more complicated that i realized | 19:36 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient.tenant_id|name https://review.openstack.org/205710 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient.request methods https://review.openstack.org/205711 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Update deprecation text for Session properties https://review.openstack.org/191511 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient session and adapter properties https://review.openstack.org/205806 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for HTTPClient tenant_id, tenant_name parameters https://review.openstack.org/205701 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for httpclient.USER_AGENT https://review.openstack.org/205833 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for Session.get_token() https://review.openstack.org/205817 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Deprecate create HTTPClient without session https://review.openstack.org/205832 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Deprecate create v2_0 Client without session https://review.openstack.org/205820 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Deprecate create v3 Client without session https://review.openstack.org/205822 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Deprecate ServiceCatalog(region_name) https://review.openstack.org/205809 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for CredentialManager data argument https://review.openstack.org/205825 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for UserManager project argument https://review.openstack.org/205826 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Deprecate ServiceCatalog.get_urls() with no attr https://review.openstack.org/205810 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Deprecate create Discover without session https://review.openstack.org/205829 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Deprecate use of cert and key https://review.openstack.org/205813 | 19:43 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for Session.construct() https://review.openstack.org/205812 | 19:43 |
*** ayoung has joined #openstack-keystone | 19:44 | |
*** ChanServ sets mode: +v ayoung | 19:44 | |
*** yottatsa has quit IRC | 19:44 | |
*** jsavak has joined #openstack-keystone | 19:44 | |
ayoung | samueldmq, 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-keystone | 19:45 | |
samueldmq | dstanek: yes they are, group/inherited needs to expand to users/subprojects | 19:46 |
samueldmq | dstanek: that code is very complex | 19:46 |
samueldmq | dstanek: and it did took time to get it right | 19:46 |
dstanek | samueldmq: hey...i'll be the judge of that :-P | 19:47 |
*** jsavak has quit IRC | 19:47 | |
samueldmq | ayoung: I am making the changes, and changing endpoint_ids -> endpoint_id | 19:47 |
samueldmq | ayoung: 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 interfaces | 19:48 |
ayoung | samueldmq, excellent. I'm about to respond to the review. PLease take a look at my comments. | 19:48 |
samueldmq | dstanek: hehe | 19:48 |
samueldmq | ayoung: ok please | 19:48 |
*** jsavak has joined #openstack-keystone | 19:55 | |
*** topol has quit IRC | 19:56 | |
samueldmq | ayoung: 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-keystone | 19:56 | |
ayoung | samueldmq, ah...goood point...ok, I'll retract. You do have a type above that, BTW (frenquently) | 19:57 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecation for httpclient.USER_AGENT https://review.openstack.org/205833 | 20:01 |
openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Update deprecation text for Session properties https://review.openstack.org/191511 | 20:01 |
openstackgerrit | Merged openstack/keystone: Replace 401 to 404 when token is invalid https://review.openstack.org/205554 | 20:03 |
*** mestery has quit IRC | 20:08 | |
*** ankita_w_ has joined #openstack-keystone | 20:12 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Fetch and Cache https://review.openstack.org/134655 | 20:13 |
samueldmq | ayoung: dstanek there we go ... ^ | 20:13 |
*** jsavak has quit IRC | 20:13 | |
samueldmq | endpoint_id ftw ... I am going to update the keystone side spec to reflect it, and point to this one instead of repeating motivation,usecase,etc | 20:13 |
*** ankita_wagh has quit IRC | 20:15 | |
*** e0ne has quit IRC | 20:19 | |
*** ankita_wagh has joined #openstack-keystone | 20:19 | |
*** e0ne has joined #openstack-keystone | 20:21 | |
*** e0ne has quit IRC | 20:21 | |
*** ankita_w_ has quit IRC | 20:22 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Distribution Mechanism https://review.openstack.org/197980 | 20:23 |
samueldmq | ayoung: dstanek removed almost 200 lines by saying : 'look at the ksmiddleware spec' | 20:23 |
samueldmq | ^^ | 20:23 |
*** topol has joined #openstack-keystone | 20:24 | |
*** ChanServ sets mode: +v topol | 20:24 | |
samueldmq | dstanek: ayoung I meant almost 100 ... | 20:24 |
*** jsavak has joined #openstack-keystone | 20:34 | |
*** gordc has quit IRC | 20:41 | |
*** mestery has joined #openstack-keystone | 20:43 | |
*** hrou has quit IRC | 20:58 | |
morganfainberg | dstanek: ping | 20:58 |
dstanek | morganfainberg: pong | 20:59 |
*** raildo has quit IRC | 21:01 | |
dstanek | morganfainberg: you weren't expecting such a quick response were you? i've been working on my pong reflexes | 21:03 |
morganfainberg | dstanek: hey. | 21:04 |
morganfainberg | dstanek: no i was in an elevator | 21:04 |
morganfainberg | dstanek: mind working with dhellmann on liberty-2 release | 21:04 |
morganfainberg | Today? | 21:04 |
morganfainberg | I need to jump into a meeting. | 21:04 |
dstanek | morganfainberg: sure, i'll ping him and see what he needs | 21:04 |
morganfainberg | This would be ~10mins post x-project meeting | 21:05 |
morganfainberg | This will be bp/bug review | 21:05 |
morganfainberg | Punting things out of l2 as needed | 21:05 |
morganfainberg | Etc | 21:05 |
dstanek | sure, so basically walking through things scheduled for l2 and punt if they are not merged? | 21:06 |
*** aix has joined #openstack-keystone | 21:06 | |
*** jdennis has quit IRC | 21:07 | |
*** mylu has quit IRC | 21:07 | |
dstanek | oops..missing the x-project... | 21:07 |
*** jdennis has joined #openstack-keystone | 21:13 | |
*** jsavak has quit IRC | 21:16 | |
*** mestery has quit IRC | 21:25 | |
*** piyanai has quit IRC | 21:26 | |
*** piyanai has joined #openstack-keystone | 21:30 | |
*** jsavak has joined #openstack-keystone | 21:30 | |
*** BAKfr has quit IRC | 21:30 | |
*** pnavarro has quit IRC | 21:30 | |
*** diazjf has left #openstack-keystone | 21:33 | |
*** BAKfr has joined #openstack-keystone | 21:36 | |
*** topol has quit IRC | 21:39 | |
*** jaosorior has quit IRC | 21:41 | |
*** dims has quit IRC | 21:42 | |
*** gordc has joined #openstack-keystone | 21:42 | |
*** snapdey has quit IRC | 21:47 | |
*** snapdey has joined #openstack-keystone | 21:54 | |
*** bknudson has quit IRC | 21:59 | |
*** ankita_w_ has joined #openstack-keystone | 21:59 | |
*** ankita_wagh has quit IRC | 22:02 | |
*** dims has joined #openstack-keystone | 22:02 | |
*** snapdey has quit IRC | 22:06 | |
*** jecarey_ has quit IRC | 22:08 | |
*** snapdey has joined #openstack-keystone | 22:10 | |
*** jsavak has quit IRC | 22:11 | |
*** piyanai has quit IRC | 22:23 | |
*** gordc has quit IRC | 22:31 | |
*** topol has joined #openstack-keystone | 22:40 | |
*** ChanServ sets mode: +v topol | 22:40 | |
dstanek | i'm not sure why ChanServ give topol voice - he talks too much | 22:41 |
*** TheIntern has quit IRC | 22:42 | |
*** topol has quit IRC | 22:44 | |
*** snapdey has quit IRC | 22:46 | |
*** piyanai has joined #openstack-keystone | 22:51 | |
*** rm_work|away is now known as rm_work | 22:51 | |
*** Guest47142 is now known as dan | 22:56 | |
*** zzzeek has quit IRC | 22:56 | |
*** hrou has joined #openstack-keystone | 22:57 | |
*** piyanai has quit IRC | 23:04 | |
*** dims has quit IRC | 23:05 | |
*** edmondsw has quit IRC | 23:07 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 23:07 | |
*** r-daneel has joined #openstack-keystone | 23:24 | |
*** r-daneel has quit IRC | 23:24 | |
*** r-daneel has joined #openstack-keystone | 23:25 | |
*** dims has joined #openstack-keystone | 23:34 | |
*** albertom has quit IRC | 23:46 | |
*** albertom has joined #openstack-keystone | 23:48 | |
*** jasonsb has quit IRC | 23:56 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!