| *** jistr has quit IRC | 00:07 | |
| *** jistr has joined #openstack-keystone | 00:08 | |
| *** ivve has quit IRC | 00:16 | |
| *** gyee has quit IRC | 01:48 | |
| *** awalende has joined #openstack-keystone | 02:00 | |
| *** awalende has quit IRC | 02:04 | |
| adriant | Not sure who the best person to ask is, but I'm not 100% sure my use of Keystonemiddleware is correct. | 04:15 |
|---|---|---|
| adriant | I always seem to get the following log entries: http://paste.openstack.org/show/787015/ | 04:15 |
| adriant | I looked at the code a while back and it looked like the middle ware complained about those values... but cheerfully passed them along to Keystoneauth or whatever underneath to connect to keystone itself, but the fact that it complains like that about values which 'are' used always felt weird to me. | 04:16 |
| adriant | As if I was doing something wrong, or like I should turn some warning off. Despite them, the service works. | 04:17 |
| adriant | this is where I wrap my Django app with the keystone middleware: https://github.com/openstack/adjutant/blob/master/adjutant/wsgi.py | 04:17 |
| adriant | The other question I have, how do I pass a verify=False config to this? So that when the middleware connects to keystone it doesn't bother verifying the cert. | 04:18 |
| adriant | I tried adding 'verify': False to it, but it didn't seem to work | 04:18 |
| *** tkajinam has quit IRC | 05:02 | |
| *** tkajinam has joined #openstack-keystone | 05:33 | |
| *** tkajinam_ has joined #openstack-keystone | 07:18 | |
| *** tkajinam_ has quit IRC | 07:19 | |
| *** tkajinam_ has joined #openstack-keystone | 07:20 | |
| *** tkajinam has quit IRC | 07:21 | |
| *** Blinkiz9 has joined #openstack-keystone | 07:50 | |
| *** trident has quit IRC | 07:51 | |
| *** johanssone has quit IRC | 07:51 | |
| *** Blinkiz has quit IRC | 07:51 | |
| *** Blinkiz9 has quit IRC | 07:51 | |
| *** trident has joined #openstack-keystone | 07:51 | |
| *** Blinkiz has joined #openstack-keystone | 07:52 | |
| *** johanssone has joined #openstack-keystone | 07:52 | |
| *** Blinkiz has quit IRC | 07:53 | |
| *** Blinkiz has joined #openstack-keystone | 07:53 | |
| openstackgerrit | Merged openstack/keystonemiddleware master: Remove v2.0 functionality https://review.opendev.org/669706 | 07:54 |
| openstackgerrit | Merged openstack/keystonemiddleware master: Change ec2 URLs to v3 https://review.opendev.org/678386 | 07:54 |
| *** awalende has joined #openstack-keystone | 08:14 | |
| *** tesseract has joined #openstack-keystone | 08:16 | |
| *** amoralej|off is now known as amoralej | 08:46 | |
| *** ivve has joined #openstack-keystone | 08:51 | |
| *** tkajinam_ has quit IRC | 09:20 | |
| *** gshippey has joined #openstack-keystone | 09:25 | |
| *** dasp has quit IRC | 09:42 | |
| *** dasp has joined #openstack-keystone | 09:43 | |
| *** rcernin has quit IRC | 10:06 | |
| *** pcaruana has joined #openstack-keystone | 10:08 | |
| *** dmellado has quit IRC | 10:33 | |
| *** dmellado has joined #openstack-keystone | 10:35 | |
| *** vishalmanchanda has joined #openstack-keystone | 11:34 | |
| *** awalende_ has joined #openstack-keystone | 11:37 | |
| *** trident has quit IRC | 11:40 | |
| *** awalende has quit IRC | 11:41 | |
| *** trident has joined #openstack-keystone | 11:43 | |
| *** raildo has joined #openstack-keystone | 11:56 | |
| *** amoralej is now known as amoralej|lunch | 12:30 | |
| *** dasp has quit IRC | 13:12 | |
| *** dasp has joined #openstack-keystone | 13:12 | |
| *** amoralej|lunch is now known as amoralej | 13:57 | |
| *** dave-mccowan has joined #openstack-keystone | 14:02 | |
| *** trident has quit IRC | 14:24 | |
| *** trident has joined #openstack-keystone | 14:25 | |
| *** jhesketh has quit IRC | 14:27 | |
| *** jhesketh has joined #openstack-keystone | 14:28 | |
| *** pcaruana has quit IRC | 14:33 | |
| *** dave-mccowan has quit IRC | 14:42 | |
| *** pcaruana has joined #openstack-keystone | 15:04 | |
| *** awalende_ has quit IRC | 15:25 | |
| *** awalende has joined #openstack-keystone | 15:26 | |
| *** awalende has quit IRC | 15:30 | |
| knikolla | o/ | 15:34 |
| cmurphy | team meeting in about 25 minutes | 15:35 |
| *** tesseract has quit IRC | 15:37 | |
| *** tesseract has joined #openstack-keystone | 15:48 | |
| *** jmlowe has quit IRC | 15:52 | |
| *** aloga has joined #openstack-keystone | 15:55 | |
| cmurphy | team meeting now in #openstack-meeting-alt | 16:02 |
| cmurphy | aloga: hi, do you want to discuss your agenda item with us in #openstack-meeting-alt? | 16:07 |
| *** jmlowe has joined #openstack-keystone | 16:09 | |
| *** cmart has joined #openstack-keystone | 16:11 | |
| *** ivve has quit IRC | 16:15 | |
| *** cmart has quit IRC | 16:17 | |
| aloga | cmurphy: sure | 16:17 |
| *** ade_lee_ has joined #openstack-keystone | 16:19 | |
| *** gyee has joined #openstack-keystone | 16:19 | |
| *** dave-mccowan has joined #openstack-keystone | 16:19 | |
| *** tesseract has quit IRC | 17:03 | |
| lbragstad | cmurphy are we planning on starting office hours right now? | 17:04 |
| lbragstad | or are we going to wait for the folks from at&t? | 17:06 |
| cmurphy | lbragstad: i was waiting to hear from gagehugo, i'm not sure what the agenda is but i thought it was mostly to get info from the at&t people? | 17:07 |
| lbragstad | ok - that sounds good | 17:07 |
| lbragstad | i'm going to grab lunch really quick - back in 5 minutes | 17:07 |
| cmurphy | ok | 17:07 |
| * lbragstad back | 17:13 | |
| cmurphy | lightning lunch speed | 17:14 |
| lbragstad | it's a super power | 17:14 |
| lbragstad | nobigdeal | 17:14 |
| cmurphy | lol | 17:15 |
| bnemec | It's easy to do a liquid lunch in five minutes. ;-) | 17:16 |
| bnemec | Not that I would know... | 17:16 |
| lbragstad | ssshh! | 17:17 |
| lbragstad | giving away my secrets | 17:18 |
| gagehugo | lbragstad: think he might join here in a bit | 17:19 |
| lbragstad | sweet | 17:21 |
| *** rick_bartra has joined #openstack-keystone | 17:27 | |
| gagehugo | rick_bartra: o/ | 17:27 |
| rick_bartra | gagehugo hello | 17:28 |
| cmurphy | o/ | 17:28 |
| lbragstad | o/ | 17:28 |
| lbragstad | ade_lee_ o/ | 17:28 |
| ade_lee_ | lbragstad, ack | 17:29 |
| gagehugo | thanks for hopping in on short notice | 17:29 |
| rick_bartra | gagehugo np | 17:29 |
| *** lamt has joined #openstack-keystone | 17:31 | |
| gagehugo | rick_bartra: I believe lbragstad and ade_lee_ had some questions on patrole | 17:31 |
| rick_bartra | gagehugo sure I can try my best to answer | 17:32 |
| lbragstad | well, it sounds like a lot of it came up during the summit | 17:32 |
| lbragstad | i know cmurphy ade_lee_ and a few others were there | 17:33 |
| cmurphy | we didn't talk that much about patrole tbh | 17:33 |
| lbragstad | but - we have a significant effort to redo policy across openstack - and keystone completed the majority of the effort last cycle | 17:33 |
| lbragstad | we're testing the functionality we introduced with "protection" tests, but they're currently specific to keystone | 17:34 |
| lbragstad | in the discussions we've had with other projects, like barbican, we've been asked if patrole could ease some of the testing effort required to make these changes | 17:34 |
| ade_lee_ | I'm interested as to why keystone chose to write policy specific unit tests as opposed to using something like patrole to generate the tests | 17:34 |
| redrobot | 👀 | 17:35 |
| ade_lee_ | and whether you guys have done any of this keystone testing using patrole | 17:35 |
| lbragstad | not to my knowledge | 17:35 |
| gagehugo | ade_lee_ iirc we looked previously at patrole in one of the denver ptgs, but that was a while ago | 17:36 |
| lbragstad | at the time, i had two concerns | 17:36 |
| rick_bartra | as far as I know, none of the Patrole tests have been updated and no new tests have been added to Patrole to test the changes made in Keystone | 17:36 |
| gagehugo | I don't think we ever got too far past a conceptual idea | 17:36 |
| lbragstad | rick_bartra i have a question about gating on patrole | 17:37 |
| ade_lee_ | gagehugo, I got the impression from lbragstad that you guys had started using patrole a lot more internally to test policy? | 17:37 |
| lbragstad | ade_lee_ keystone? or AT&T? | 17:37 |
| ade_lee_ | at&t | 17:37 |
| gagehugo | yeah | 17:37 |
| ade_lee_ | so I'm trying to understand whether its worth using it to test -- for instance -- barbican policy | 17:38 |
| rick_bartra | We do use it internally because we make a lot of policy overrides and use Patrole to verify that our changes are in line with our requirements | 17:38 |
| lbragstad | rick_bartra so you supply patrole with a copy of the policy files that are deployed, right? | 17:39 |
| gagehugo | lbragstad: yeah | 17:40 |
| rick_bartra | lbragstad our internal testing approach follow this: https://docs.openstack.org/patrole/latest/framework/requirements_authority.html | 17:40 |
| ade_lee_ | and if so, presumably we could generate the default policy files and pass those to patrole in the gate? | 17:41 |
| rick_bartra | so we actually don't provide the policy file, we provide a "golden" requirements yaml file and test against that | 17:41 |
| rick_bartra | there are two ways of testing in patrole, one way is you provide the policy file, and the other is you test against a requirements file | 17:41 |
| rick_bartra | in the Patrole gate we test with the policy file or policy in code | 17:42 |
| rick_bartra | it is just internally that we test against the requirements file | 17:42 |
| *** jhesketh has quit IRC | 17:42 | |
| lbragstad | rick_bartra so - if we want to incorporate this into the gate for barbican or keystone, how would we protect against bad policy changes? | 17:43 |
| lbragstad | (e.g., i propose a patch the unprotects the identity:list_users policy by setting it to ""_ | 17:43 |
| lbragstad | s/_/) | 17:43 |
| *** jhesketh has joined #openstack-keystone | 17:44 | |
| ade_lee_ | interesting -- it seems like the requirements file is yet another way of expressing policy? | 17:44 |
| cmurphy | i have in my notes that i couldn't get the custom requirements file to work properly with implied roles | 17:46 |
| rick_bartra | lbragstad I think that would require the requirement testing approach, so someone would need to define what is "good" policy. Then if someone changes an action to use a "bad" policy, then Patrole would fail the test for that policy action with either an underpermission (the role should have access but it doesn't) or an overpermission (the role has | 17:46 |
| rick_bartra | access but it shouldn't) | 17:46 |
| lbragstad | ok - so this would require each service, or a pop-up team, to go through define what they should be for each role and API? | 17:47 |
| gmann | lbragstad: rick_bartra it will avoid you rename or change default + over protection but not unprotection case (as long as jobs are tested with all possible defaults. currently patrole tests one role per job. ) | 17:47 |
| rick_bartra | lbragstad yeah that would be required | 17:47 |
| * lbragstad nods | 17:48 | |
| gmann | for example. if policy is changed as lbragstad mentioned then tests using any role will still pass as oslo will return the permission ok and so does API. | 17:48 |
| lbragstad | ^ that's what i was worried about previously | 17:48 |
| lbragstad | but it sounds like the "golden" requirements file is supposed to mitigate that? | 17:49 |
| rick_bartra | gmann that is correct, but if you choose to test against a requirements file then it would perform the desired check | 17:49 |
| rick_bartra | lbragstad that is correct | 17:49 |
| lbragstad | the main problem that the requirements file sounds (based on how i understand it) is it seeds the projects with a known good behavior | 17:49 |
| rick_bartra | internally we have a yaml file that defines which roles should have access to which policy actions and we test against that | 17:50 |
| lbragstad | instead of generating the assertions from the defaults in code | 17:50 |
| bnemec | No matter what tooling you use you would need to come up with the definition of the expected behavior. | 17:50 |
| lbragstad | (which would leave the defaults in code unprotected?) | 17:50 |
| bnemec | In keystone that was done in the unit tests. | 17:50 |
| bnemec | It sounds like in patrole that would be the requirements file. | 17:50 |
| rick_bartra | bnemec that is corret | 17:50 |
| bnemec | But it sounds like there are some limitations to the requirements file. | 17:50 |
| gmann | i did not get the requirement file things ? | 17:50 |
| lbragstad | gmann https://docs.openstack.org/patrole/latest/framework/requirements_authority.html | 17:51 |
| bnemec | Specifically cmurphy's comment above and the note at the bottom of https://docs.openstack.org/patrole/latest/framework/requirements_authority.html#custom-requirements-file | 17:51 |
| bnemec | (also that oslo.policy doc link is broken :-( ) | 17:51 |
| gmann | ohk, i thought requirement.txt | 17:52 |
| lbragstad | rick_bartra i have another question - does at&t validate requirements for domain users? | 17:52 |
| lbragstad | or do you have deployments that need domains users of some kind? | 17:52 |
| rick_bartra | we don't at the moment | 17:52 |
| gagehugo | we will though | 17:52 |
| lbragstad | ok - i was curious if the requirement approach was granular enough to support "this user can list projects, but only projects within their domain" | 17:53 |
| lbragstad | in keystone we have a lot of tests like this - https://opendev.org/openstack/keystone/src/branch/master/keystone/tests/protection/v3/test_projects.py#L162-L170 | 17:54 |
| gmann | i do not think we have any job on gate testing that ? rick_bartra you remember | 17:54 |
| rick_bartra | gmann i don't think we do either | 17:55 |
| gmann | yeah that's should cover most of the cases. i am writing nova policy tests similar to that approach but with mock the operation . | 17:55 |
| cmurphy | lbragstad: i don't think patrole supports that, iiuc all it can do is check the return code | 17:56 |
| lbragstad | rick_bartra do you know if there is a plan to support that at some point in the future? ^ | 17:56 |
| rick_bartra | lbragstad I don't think the requirements approach can handle that. Internally we did RBAC in such a way that we have role that are designed to have either global or tenant level access | 17:56 |
| gmann | I think such asserts are valid to do in current tests also. for example extend the tests to verify the response for such policy. | 17:57 |
| lbragstad | ok - regardless of the level, do you think patrole will incorporate a "filtering" check of some kind? | 17:57 |
| rick_bartra | lbragstad for the past year or so at&t hasn't been putting too much engineering effort into patrole, so I can't say if it will be done or not | 17:58 |
| * lbragstad nods | 17:58 | |
| cmurphy | gmann: at that point i wonder what patrole is really providing above and beyond what tempest does? you still have to write tests and assert state | 17:58 |
| lbragstad | ade_lee_ redrobot do y'all have any questions? i feel like i'm being a time hog | 17:59 |
| gmann | yeah. tests need to modify or written to cover those asserts | 17:59 |
| ade_lee_ | lbragstad, just listening right now -- for barbican though, I think this might be very useful | 17:59 |
| gmann | how many such cases of policies are there in keystone? i mean filter one ? | 18:00 |
| lbragstad | gmann there are quite a few, we make sure users can't view things outside of their tenancy | 18:00 |
| lbragstad | (projects, users, groups, role assignments to name a few) | 18:00 |
| gmann | i see, you have user, groups level etc also | 18:01 |
| ade_lee_ | we can easily create a requyirements file for barbican and I think most policy checks can be covered there. we may still need additional policy tests, but those would be for things we've added -- like per-resource acls | 18:01 |
| cmurphy | wouldn't it mean adding tests to patrole and having the qa/patrole teams own those barbican tests? | 18:01 |
| cmurphy | or can patrole tests be split out into their own plugins? | 18:02 |
| gmann | that is good point. those should be own by barbarian team. | 18:02 |
| ade_lee_ | that would certainly be preferable .. | 18:02 |
| lbragstad | gmann yeah - we definitely want certain users to see 200s when they call specific APIs, but we absolutely want to test they aren't able to violate tenancy | 18:02 |
| gmann | we have not finalized the patrole plugin approach yet but discussed about that in denver PTG. | 18:02 |
| ade_lee_ | rick_bartra, is patrole doing plugins? | 18:03 |
| gmann | lbragstad: yeah in nova, we have list servers case in same way | 18:03 |
| gmann | ade_lee_: not yet. | 18:03 |
| bnemec | Turning it around, are there a lot of tests where you _don't_ care about the list of things returned? | 18:03 |
| gmann | one approach is to write the patrole tests in tempest plugin using patole framework | 18:03 |
| bnemec | So you wouldn't necessarily have to write new tests. | 18:03 |
| rick_bartra | ade_lee_ internally we Heat RBAC tests that use patrole as a plugin and we also have done this with contrail as well | 18:04 |
| gmann | because creating plugin framework for patrole will be two level plugin for Tempest as patrole itself is Tempest plugin | 18:04 |
| rick_bartra | ade_lee_ I believe last year, Patrole was accepting some neutron plugin tests into Patrole itself | 18:04 |
| ade_lee_ | thats not neccesarily an issue though -- barbican already has functional tests to test the extra things -- we'd just keep those in our functional tests. and just do standard patrole + requirements file for most of the permissions | 18:05 |
| gmann | you mean in barbican tempest plugin right ? | 18:06 |
| ade_lee_ | they're in the barbican functional tests iirc | 18:06 |
| *** renich has joined #openstack-keystone | 18:06 | |
| * lbragstad is taking notes | 18:06 | |
| lbragstad | https://etherpad.openstack.org/p/policy-rbac-patrole-evaluation | 18:07 |
| gmann | doing in barbican functional tests will be different approach i think not actually using the patrole (tempest) like tests where you can benefit the common framework and run capability | 18:08 |
| gmann | different approach or duplicating approach. if you do in barbican tempest plugin then you have all service clients available to interact to API. | 18:09 |
| ade_lee_ | gmann, ack -- its just whats there now .. we can move to tempest later or see what we can do in patrole. Most of the policy though I think could be tested in patrole. | 18:10 |
| gmann | i was thinking to have under /policy/ in this - https://github.com/openstack/barbican-tempest-plugin/tree/master/barbican_tempest_plugin/tests | 18:11 |
| ade_lee_ | gmann, indirectly, I think we do actually test our acls in the barbican-tempest-plugin because we test octavia type setups .. | 18:11 |
| ade_lee_ | well maybe not there .. | 18:12 |
| ade_lee_ | (I mean currently having tests) -- putting policy tests under where you described is not a bad idea | 18:13 |
| lbragstad | ade_lee_ then would you invoke them as patrole tests or as tempest plugin tests? | 18:14 |
| gmann | yeah, if you are writing patrole tests then it can be explicit separate from other tests so that you can test them via different roles and requirement file | 18:14 |
| ade_lee_ | rick_bartra, so if I understand how patrole works - we point it to a requirements file and it will create a bunch of users etc. and generate a bunch of api tests -- and confirm that all works as expected? | 18:15 |
| *** jmlowe has quit IRC | 18:15 | |
| ade_lee_ | or do we need to explicitly write tests? | 18:15 |
| *** jmlowe has joined #openstack-keystone | 18:15 | |
| lbragstad | afaict you still need to write tests | 18:16 |
| rick_bartra | ade_lee_ you need to write the tests, create the roles, and define which roles are being tested in the tempest.conf | 18:16 |
| lbragstad | these are patrole's existing tests | 18:16 |
| lbragstad | https://github.com/openstack/patrole/tree/master/patrole_tempest_plugin/tests/api | 18:16 |
| cmurphy | i think it uses tempests' default users | 18:16 |
| ade_lee_ | ah .. then what is patrole providing then? | 18:16 |
| cmurphy | ade_lee_: this is what i've been wondering :) | 18:17 |
| rick_bartra | the framework for RBAC testing | 18:17 |
| cmurphy | there's also this issue with non-dynamic credentials https://storyboard.openstack.org/#!/story/1714413 | 18:17 |
| gmann | yeah non-dynamic cred case needs to be fixed. | 18:18 |
| lbragstad | bnemec getting back to your question - i feel like filtering is going to become more and more important | 18:19 |
| lbragstad | bnemec imo - that's the pattern i noticed when we introduced support for system, domain, and project scope with admin, member, and reader | 18:20 |
| gmann | ade_lee_: basically, patrole switch the testing cred role as per configured role or requirement file and run the tests and assert accordingly. so you need to write the tests which call the API + do extra response verification. current tests are just call API. | 18:20 |
| lbragstad | because it makes behaviors less binary | 18:20 |
| bnemec | Yeah, so maybe we need to focus on making it as easy as possible to write those tests. | 18:20 |
| lbragstad | cmurphy had a leg up on that i believe | 18:21 |
| *** vishalmanchanda has quit IRC | 18:21 | |
| *** vishalmanchanda has joined #openstack-keystone | 18:21 | |
| cmurphy | https://review.opendev.org/686073 https://review.opendev.org/686306 | 18:22 |
| *** jmlowe has quit IRC | 18:24 | |
| bnemec | So we're pretty much back to what cmurphy said in the first place. Patrole isn't a great fit for these tests and they probably need to be either Tempest or unit tests, depending on the project. | 18:26 |
| *** awalende has joined #openstack-keystone | 18:27 | |
| gmann | Patrole cover basic RBAC testing as of now but require 1. current tests perform the full operation so not suitable where API operations are heavy like nova create/evacuate server. 2. need to write tests for any new projects which can be done in tempest plugin 3. write or modify tests to cover filter cases 4. adopt system scope via tempest | 18:27 |
| gmann | if i am correct, 3rd and 4th are the only items required for keystone right? | 18:28 |
| gmann | barbican need 2nd too. (hope API operation are not so heavy) | 18:28 |
| lbragstad | given our currently level of testing, yes.. i would think so | 18:29 |
| lbragstad | but i'm curious to hear what others have to say | 18:29 |
| gmann | in nova, main obstacle to not gate patrole is 1st item | 18:30 |
| ade_lee_ | gotta head out, guys - but its been very informative --I need to chew over what was said here | 18:30 |
| ade_lee_ | thanks for the info | 18:31 |
| *** awalende has quit IRC | 18:31 | |
| lbragstad | ++ | 18:35 |
| lbragstad | thank you for the time rick_bartra | 18:35 |
| cmurphy | ++ thank you | 18:35 |
| lbragstad | and answering our endless barrage of questions | 18:36 |
| gagehugo | rick_bartra: ++ thanks! | 18:36 |
| *** raildo has quit IRC | 18:37 | |
| *** raildo has joined #openstack-keystone | 18:38 | |
| *** jmlowe has joined #openstack-keystone | 18:39 | |
| rick_bartra | no problem :) | 18:43 |
| *** rick_bartra has quit IRC | 18:43 | |
| *** ayoung has quit IRC | 18:52 | |
| *** gmann is now known as gmann_afk | 19:00 | |
| *** amoralej is now known as amoralej|off | 19:20 | |
| *** awalende has joined #openstack-keystone | 19:20 | |
| *** awalende has quit IRC | 19:24 | |
| *** ivve has joined #openstack-keystone | 19:28 | |
| *** gmann_afk is now known as gmann | 20:25 | |
| *** vesper11 has quit IRC | 20:49 | |
| *** vesper11 has joined #openstack-keystone | 20:51 | |
| *** raildo has quit IRC | 21:16 | |
| *** awalende has joined #openstack-keystone | 22:00 | |
| *** awalende has quit IRC | 22:04 | |
| *** pcaruana has quit IRC | 22:06 | |
| *** cmart has joined #openstack-keystone | 22:40 | |
| *** cmart has quit IRC | 22:41 | |
| *** ade_lee__ has joined #openstack-keystone | 22:43 | |
| *** ade_lee_ has quit IRC | 22:46 | |
| *** ade_lee has joined #openstack-keystone | 22:50 | |
| *** cmart has joined #openstack-keystone | 22:50 | |
| *** ade_lee__ has quit IRC | 22:54 | |
| *** ade_lee has quit IRC | 22:56 | |
| *** tkajinam has joined #openstack-keystone | 22:56 | |
| *** rcernin has joined #openstack-keystone | 22:57 | |
| *** cmart has quit IRC | 23:02 | |
| *** ade_lee has joined #openstack-keystone | 23:18 | |
| *** stokvis has quit IRC | 23:29 | |
| *** stokvis has joined #openstack-keystone | 23:29 | |
| *** ivve has quit IRC | 23:47 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!