| *** brault has joined #openstack-meeting-cp | 00:00 | |
| *** brault has quit IRC | 00:05 | |
| *** aselius has quit IRC | 00:11 | |
| *** diablo_rojo has quit IRC | 01:20 | |
| *** gouthamr has quit IRC | 02:33 | |
| *** edmondsw has joined #openstack-meeting-cp | 02:35 | |
| *** edmondsw has quit IRC | 02:40 | |
| *** brault has joined #openstack-meeting-cp | 06:00 | |
| *** lamt has joined #openstack-meeting-cp | 06:04 | |
| *** brault has quit IRC | 06:04 | |
| *** brault has joined #openstack-meeting-cp | 06:27 | |
| *** lamt has quit IRC | 06:30 | |
| *** rarcea has joined #openstack-meeting-cp | 06:45 | |
| *** jroll has quit IRC | 07:12 | |
| *** edmondsw has joined #openstack-meeting-cp | 07:59 | |
| *** edmondsw has quit IRC | 08:04 | |
| *** sdague has joined #openstack-meeting-cp | 09:44 | |
| *** edmondsw has joined #openstack-meeting-cp | 09:49 | |
| *** edmondsw has quit IRC | 09:54 | |
| *** jroll has joined #openstack-meeting-cp | 10:25 | |
| *** edmondsw has joined #openstack-meeting-cp | 11:42 | |
| *** hemna has quit IRC | 11:47 | |
| *** dansmith has quit IRC | 11:48 | |
| *** hemna has joined #openstack-meeting-cp | 11:49 | |
| *** dansmith has joined #openstack-meeting-cp | 11:51 | |
| *** dansmith is now known as Guest36154 | 11:51 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 13:42 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 13:44 | |
| *** felipemonteiro has quit IRC | 13:47 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:51 | |
| *** zhipeng_ has joined #openstack-meeting-cp | 13:58 | |
| *** Guest36154 is now known as dansmith | 14:00 | |
| *** lamt has joined #openstack-meeting-cp | 14:34 | |
| *** jaugustine has joined #openstack-meeting-cp | 14:46 | |
| *** aselius has joined #openstack-meeting-cp | 14:53 | |
| *** ayoung has joined #openstack-meeting-cp | 15:14 | |
| *** docaedo has left #openstack-meeting-cp | 15:21 | |
| *** felipemonteiro_ has quit IRC | 15:29 | |
| *** gagehugo has joined #openstack-meeting-cp | 15:36 | |
| *** notmyname has quit IRC | 15:57 | |
| *** hrybacki has joined #openstack-meeting-cp | 15:58 | |
| *** blancos has joined #openstack-meeting-cp | 15:59 | |
| *** notmyname has joined #openstack-meeting-cp | 16:01 | |
| lbragstad | #startmeeting policy | 16:01 |
|---|---|---|
| openstack | Meeting started Wed May 24 16:01:39 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| *** openstack changes topic to " (Meeting topic: policy)" | 16:01 | |
| openstack | The meeting name has been set to 'policy' | 16:01 |
| knikolla | o/ | 16:01 |
| lbragstad | ping raildo, ktychkova, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, morgan, raj_singh, johnthetubaguy, knikolla, nhelgeson | 16:01 |
| lbragstad | o/ | 16:01 |
| blancos | o/ | 16:01 |
| hrybacki | o/ | 16:01 |
| gagehugo | o/ | 16:01 |
| lbragstad | #link https://etherpad.openstack.org/p/keystone-policy-meeting | 16:02 |
| lbragstad | agenda^ | 16:02 |
| nhelgeson | o/ | 16:02 |
| ayoung | hrybacki, too! | 16:02 |
| ayoung | lbragstad, I took the liberty of copuying most of last weeks agenda forward. take a look and please OK/object | 16:03 |
| ayoung | we got through so little last week | 16:03 |
| *** diablo_rojo has joined #openstack-meeting-cp | 16:03 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 16:04 | |
| lamt | o/ | 16:04 |
| felipemonteiro | o/ | 16:04 |
| ayoung | From the previous discussions, it sounds like getting a solution to Admin-everywhere is highest priority | 16:05 |
| ayoung | as such, I wrote up an explanation in the plainest terms I could muster | 16:05 |
| lbragstad | look like this weeks agenda is a copy/paste of last weeks | 16:05 |
| ayoung | #link http://adam.younglogic.com/2017/05/fixing-bug-96869/ | 16:05 |
| lbragstad | had a blip there with my network connection | 16:05 |
| ayoung | lbragstad, yep, it is. We spent all of last week on the Goals doc | 16:05 |
| ayoung | I wanted to hit some more tactical stuff before we get back into that | 16:06 |
| ayoung | OK with you? | 16:06 |
| *** MarkBaker has quit IRC | 16:06 | |
| gagehugo | fixing-bug-968696 was a good read | 16:06 |
| ayoung | gagehugo, TYVM | 16:06 |
| edmondsw | o/ | 16:06 |
| lbragstad | ayoung: do you mind if we start with http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html | 16:06 |
| ayoung | If you have not read it, please do so. It should help make clearer what we are trying to do. | 16:06 |
| lbragstad | ? | 16:07 |
| ayoung | #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html | 16:07 |
| lbragstad | thanks | 16:07 |
| hrybacki | gagehugo++ | 16:07 |
| ayoung | lbragstad, So, regardless of is_admin_project vs global roles, the policy will need to be enforced in the remote services. It think my write up still applies, with minor modifications | 16:08 |
| ayoung | lets talk global roles for a moment, though | 16:08 |
| lbragstad | ayoung: absolutely | 16:08 |
| ayoung | Kubernetes has a similar concept; Roles vs ClusterRoles | 16:08 |
| ayoung | a ClusterRole is not scoped to a namespace | 16:08 |
| ayoung | k8s is kubernetes for short | 16:08 |
| ayoung | namespace is kindof what k8s calls a project | 16:09 |
| ayoung | one thing about having them separate is they could go into the same token response | 16:09 |
| ayoung | lest say we call ours GLobalROles or CLusterRole or whatever, we could have a new section in the token validation response that enumerates them | 16:09 |
| lbragstad | #link https://youtu.be/WvnXemaYQ50?t=19m39s | 16:10 |
| ayoung | role assignments for global roles would be on a global target | 16:10 |
| *** brault has quit IRC | 16:10 | |
| ayoung | good link...but a little long for this meeting. Suggest people watch wjhen they have time | 16:10 |
| edmondsw | ayoung to be honest I wasn't super impressed with what k8s has... better than what we have currently, but not as good as what we've been discussing as our future | 16:10 |
| *** MarkBaker has joined #openstack-meeting-cp | 16:11 | |
| ayoung | edmondsw, fair enough. I'm just learning it myself | 16:11 |
| lbragstad | sure - for folks who want to get an idea of what k8s has for policy and contrast it to what we do today - that link might help | 16:11 |
| ayoung | so, assuming we got with global roles, the steps we'd need would be something like this: | 16:11 |
| ayoung | 1. DEFINE the api for them | 16:11 |
| lbragstad | #topic global roles | 16:11 |
| *** openstack changes topic to "global roles (Meeting topic: policy)" | 16:11 | |
| ayoung | 2. Add global roles GR for short | 16:11 |
| ayoung | 2. Add global roles to token validation response | 16:12 |
| ayoung | 3. Add global roles to oslo-context | 16:12 |
| ayoung | 4. enforce policy on Global roles | 16:12 |
| ayoung | note that this will break exisiting deployments if we do not provide a transition scheme | 16:12 |
| ayoung | ie. no one will have any global roles defined, nor any users with them | 16:12 |
| ayoung | Thus, we'd probably have to adopt the same approach we did with is_admin_project: | 16:13 |
| ayoung | start by making all admin role assignments into GlobalRoles until some switch is set | 16:13 |
| ayoung | otherwise, we end up rewriting policy files twice, and that will be a disaster | 16:14 |
| ayoung | we want to touch nova once and only once and be done with it | 16:14 |
| edmondsw | ayoung it sounds like you're suggesting we have global roles | 16:14 |
| ayoung | edmondsw, no | 16:14 |
| *** spilla has joined #openstack-meeting-cp | 16:14 | |
| ayoung | edmondsw, I'm suggesting I've thought through what it would take to implement them | 16:14 |
| edmondsw | what we've been discussing is roles that could be scoped either locally or globally | 16:14 |
| ayoung | and I want people to be aware of the pain involved | 16:15 |
| edmondsw | not global roles vs. local roles... roles, period | 16:15 |
| edmondsw | and scoping is separate | 16:15 |
| edmondsw | scoping comes in with how you make the assignment | 16:15 |
| ayoung | edmondsw, ok...so let me address that | 16:15 |
| edmondsw | goes back to my "we can do better than k8s" comment | 16:15 |
| ayoung | right now, a token is either scoped or unscoped. Unscoped tokens are not currrently usable outside of keystone | 16:16 |
| ayoung | we could, if we want, use unscoped tokens to do global roles, and put them in the roles field. | 16:16 |
| ayoung | what that would then do with policy is this | 16:16 |
| edmondsw | no | 16:16 |
| edmondsw | we already had this discussion and said no to that | 16:16 |
| ayoung | we'd have two stanzas, one that checked the role for scoped, one that checks the role for unscoped | 16:17 |
| edmondsw | unscoped != global scoped | 16:17 |
| ayoung | edmondsw, which is why I was using a different name for them: GR versus Role | 16:17 |
| edmondsw | unscoped is the empty set, global scoped is the universal set | 16:17 |
| lbragstad | ++ | 16:17 |
| ayoung | edmondsw, or we explicitly request a token with global scoping, yes | 16:17 |
| edmondsw | it's not different types of roles, though... it's roles + scope | 16:17 |
| lbragstad | i would agree but i'd also expect operators/deployers to confirm that | 16:17 |
| ayoung | regardless, the policy file needs to have a different check for a globally scoped role than for a project scoped role | 16:18 |
| edmondsw | ayoung no, scope checks should be in code, not policy | 16:18 |
| ayoung | edmondsw, stop | 16:18 |
| ayoung | edmondsw, you are being argumentative. | 16:18 |
| ayoung | I know that | 16:18 |
| ayoung | please don't be pedantic | 16:18 |
| edmondsw | ayoung ha! pot calling the kettle... ;) | 16:19 |
| ayoung | I am talking about from where we are today | 16:19 |
| ayoung | edmondsw, policy file is the reality on every service. Nova and Keystone have the policy-file-less approach | 16:19 |
| ayoung | I'm not going to tell Neutron it needs to adopt it | 16:19 |
| edmondsw | I thought we already agreed that fixing 968696 will involve doing scope checks in code | 16:19 |
| ayoung | edmondsw, for Keystone and Nova, yes | 16:20 |
| ayoung | edmondsw, for the other projects, I am not willing to rewrite them to that level | 16:20 |
| edmondsw | I'm not sure you can fix this without doing so | 16:20 |
| ayoung | I think that decision can be taken up by whomever choses to fix the bug on those systems | 16:20 |
| edmondsw | stronger than that... I'm pretty sure you can't | 16:20 |
| edmondsw | sure | 16:20 |
| ayoung | edmondsw, so, I don't think there is anything we need to do in python code that you cannot do in the policy.json file today. Just that modifications have a greater probility of breaking things | 16:21 |
| ayoung | glance and neutron and cinder can all be fixed in their default policy files for the first step | 16:21 |
| ayoung | if they go to scope check in code, they should then inherit the fix | 16:22 |
| ayoung | which is an argument against an explicit GLobalROle change. Policy is in flux, and we will soon have python code enforcing the bug effect | 16:22 |
| ayoung | I'd like to get the fix through as fast as possible | 16:23 |
| ayoung | changing from is_admin_project to GlobalRoles will delay that, and confuse the message, even if the term is the better term | 16:23 |
| ayoung | is_admin_project can be seen as an implementation of global roles using exisint mechanisms. It exposes a low level detail that GR does not. | 16:24 |
| lbragstad | i think having operator or deployer input would be valuable | 16:24 |
| lbragstad | because we can implement global role assignments via project scoping | 16:25 |
| ayoung | So, if fixing 968696 is the highest priority, I am going to suggest we not change the mechanism we are using to solve it | 16:26 |
| ayoung | because it will push back the fix by a good bit...we are too late for Pike as it is, Which means it won't go uin until queens, and then the fix for the other projects backs up behind that | 16:27 |
| edmondsw | ayoung I don't see any reason we can't do both in parallel | 16:27 |
| ayoung | R if we are really lucky | 16:27 |
| ayoung | edmondsw, sure | 16:27 |
| ayoung | edmondsw, I'm ok with that, so long as we prioritize 968696 | 16:27 |
| ayoung | And with that, I would like to find out who is actually planning on workin on this | 16:27 |
| ayoung | right now I know of gagehugo actively writing code | 16:28 |
| ayoung | is anyone else willing to work on the fixes for any of the other services? | 16:28 |
| hrybacki | I am willing to dedicate some cycles to the cause | 16:28 |
| ayoung | hrybacki, excellent | 16:28 |
| ayoung | hrybacki, we have need for fixes in | 16:29 |
| ayoung | Neutron and Cinder from scratch | 16:29 |
| ayoung | there is a half-kiestered fix in for glance | 16:29 |
| ayoung | gagehugo is tackling nova | 16:29 |
| hrybacki | gagehugo++ | 16:29 |
| ayoung | and I think was flagged to take the keystone changes too | 16:29 |
| gagehugo | ayoung yeah I was looking at what we might need to do for tempest | 16:30 |
| hrybacki | ayoung: would that mean he is taking over some of the patches you've already got up or something completely new? | 16:30 |
| gagehugo | hrybacki was using ayoungs patches | 16:30 |
| hrybacki | don't mean to de-rail -- I'm happy to help with some guidance (as this clearly has a lot of history) | 16:30 |
| ayoung | hrybacki, all submitted patches are linked to from the etherpad | 16:30 |
| hrybacki | ack | 16:30 |
| ayoung | hrybacki, this is not derailing. The is re-railing | 16:31 |
| lbragstad | i think we need more operator and deployer feedback for the global role or is_admin_project approach | 16:31 |
| ayoung | lbragstad, go for it, but don't hold this up | 16:31 |
| ayoung | I really don;'t think they will care | 16:31 |
| ayoung | RBAC is something that most people ignore until it bites them | 16:31 |
| ayoung | if we document what we are doing, they will get the same end result | 16:31 |
| edmondsw | this operator cares and wants global roles... trying to explain is_admin_project is a mess | 16:32 |
| ayoung | and, if we go in parallel, we can roll this fix in to global roles without hurting them | 16:32 |
| ayoung | edmondsw, it was your idea | 16:32 |
| edmondsw | I'll do it while I have to, but we need to get that replaced with global roles | 16:32 |
| edmondsw | ayoung sort of | 16:32 |
| lbragstad | if we want to do this in parallel - then we should change the is_admin_project bits | 16:33 |
| *** Rockyg has joined #openstack-meeting-cp | 16:33 | |
| hrybacki | do we have a plan for getting more operator feedback? | 16:33 |
| edmondsw | ayoung and that was just to implement a quick fix... 18 months later we still don't have a fix | 16:33 |
| edmondsw | it was never to be a permanent solution | 16:33 |
| lbragstad | hrybacki: #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html | 16:33 |
| *** zhipeng_ has quit IRC | 16:33 | |
| hrybacki | thanks lbragstad | 16:33 |
| ayoung | yep | 16:33 |
| lbragstad | hrybacki: no problem | 16:34 |
| ayoung | So, go write up the global roles spec | 16:34 |
| ayoung | get the code started in keystone, including the transition plan | 16:34 |
| lbragstad | #link https://review.openstack.org/#/c/464763/8/specs/keystone/ongoing/global-roles.rst | 16:34 |
| edmondsw | lbragstad that email was sent to the dev ML... what about the operator ML? | 16:35 |
| lbragstad | edmondsw: #link http://lists.openstack.org/pipermail/openstack-operators/2017-May/013547.html | 16:35 |
| lbragstad | edmondsw: i sent it to the operator and dev lists | 16:36 |
| edmondsw | lbragstad great, tx | 16:36 |
| *** zhipeng_ has joined #openstack-meeting-cp | 16:37 | |
| ayoung | are you serious about doing it in parallel, or do you want to prioritize global roles over is_admin_project for the fix? | 16:38 |
| lbragstad | edmondsw: no problem | 16:38 |
| lbragstad | ayoung: I'm serious about getting the feedback - because I think it is important | 16:39 |
| ayoung | lbragstad, are you putting a hold on the is_admin_project fixes until we get that feed back? | 16:39 |
| lbragstad | i don't want to implement is_admin_project fixes only to have operator migrate to global roles | 16:41 |
| lbragstad | operators* | 16:41 |
| lbragstad | that seems like a lot of work | 16:41 |
| lbragstad | which is why i'm asking for feedback | 16:42 |
| ayoung | lbragstad, a lot of work has been done already | 16:42 |
| ayoung | are you telling me you want to throw that out> | 16:43 |
| lbragstad | ayoung: no - i'm not saying we need to throw it out | 16:43 |
| ayoung | and if so, I would like to point out that the time to have this discussion should have been when that idea was floated | 16:43 |
| ayoung | And when those specs were posted, and approaved. And implemented. | 16:44 |
| lbragstad | ayoung: i'd like to get buy in from operators that they are ok migrating an approach for global roles | 16:45 |
| lbragstad | twice | 16:45 |
| ayoung | This is a long, multi-project effort. Having it reset this late in the process due to a name change is a waste | 16:46 |
| lbragstad | it's not a naming change - it's a structural change for elevated privileges in my opinion | 16:46 |
| ayoung | So, I want to know who is committing to see this through | 16:47 |
| ayoung | its a name change | 16:47 |
| ayoung | is_admin_project to global | 16:47 |
| ayoung | operators want a read-only role | 16:48 |
| ayoung | this is holding that up | 16:48 |
| ayoung | because we've prioritize 968696 over that | 16:48 |
| ayoung | you are doing the operators no favors here. | 16:48 |
| ayoung | so, are you willing to derail the is_admin_project fix, and further postpone RBAC in middleware, to change is_admin_project to global? | 16:49 |
| ayoung | And if so, who is going to pay for it? | 16:50 |
| samueldmq | isn't global related to 968696? | 16:50 |
| ayoung | samueldmq, its another way to get there, but longer | 16:50 |
| samueldmq | I thought it was a way to keep allowing what is possible today: global scope | 16:50 |
| ayoung | it is, but it needs to be implemented | 16:50 |
| ayoung | and we went through the comparable pain already for is_admin_project | 16:50 |
| samueldmq | so the question is use is_admin_project to allow global roles | 16:51 |
| samueldmq | or implement global roles as proposed in lbragstad's spec | 16:51 |
| samueldmq | correct? | 16:51 |
| ayoung | samueldmq, sort of | 16:51 |
| samueldmq | okay, would it be useful to get input from other projects too? | 16:52 |
| ayoung | the question is whether to wait on fixing 968696 in the remote services used the global scope proposed, or to fix it now with the implemented mechanisms | 16:52 |
| samueldmq | I still need to look at global roles spec myself, I understand your proposal, fully got your blog post | 16:52 |
| ayoung | I;'d say it would be useful to stop waste time and effort and just fix the damn thing | 16:52 |
| samueldmq | how do global role (or is_admin_project) go with the current idea for migrating scope checks to the code? | 16:53 |
| samueldmq | do we plan to add that in the files for now, then migrate them to the code later? | 16:53 |
| ayoung | the check needs to be done regardless | 16:53 |
| samueldmq | agreed | 16:53 |
| samueldmq | my question is what's the plan on the check | 16:54 |
| ayoung | if we do it in code, we have the more flexible language of Python to implement | 16:54 |
| samueldmq | we put them on the files for now, and they will go to code once the rest goes too? | 16:54 |
| * samueldmq nods | 16:54 | |
| ayoung | that realyl only matters for advance cases, like domain vs project vs global scoped tokens for creating projects | 16:54 |
| samueldmq | yeah and I guess the answer to that will depend on how fast we can advance on 968696 and how fast migrating scopes to code is gonna take | 16:55 |
| ayoung | So, I have hrybacki and gagehugo that are planning on writing code using the existing mechanisms | 16:55 |
| samueldmq | I was just checking we were in the same page | 16:55 |
| ayoung | for nova, the review is submitted | 16:55 |
| ayoung | for Keystone, its been kicked back and needs a little more work, but what is needed is in place | 16:56 |
| samueldmq | that's good to see we have resources to work on this front | 16:56 |
| ayoung | samueldmq, I cannot work on this myself any more | 16:56 |
| samueldmq | ok, I will review the global roles approach too, before that I can say anything :( | 16:56 |
| ayoung | so if we are going a different direction, someone needs to own that, and understand the real costs | 16:56 |
| samueldmq | but I got your proposal and I understand it solves the issue | 16:57 |
| * samueldmq nods | 16:57 | |
| ayoung | including the hacks we've had to do to provide a forward compatable solution | 16:57 |
| ayoung | a global scope is going to have to map to something people have now, or we are going to have to dual check or something | 16:57 |
| edmondsw | samueldmq we can't fix this in the policy files without adding a bunch of new policy checks, so it's easier (and what we want anyway) to just do scope checks in the code to start with | 16:57 |
| ayoung | which is why we went with is_admin_project | 16:57 |
| ayoung | edmondsw, for Keystone | 16:58 |
| ayoung | edmondsw, not for glance, cinder, or neutron | 16:58 |
| edmondsw | ayoung not only for keystone | 16:58 |
| ayoung | edmondsw, and we already fixed the pyhthon code for nova | 16:58 |
| samueldmq | edmondsw: I get that, that's where my question on what we do now and how we address the to-code migration | 16:58 |
| samueldmq | FYI we're almost out of time | 16:58 |
| ayoung | ASnd we are out of time | 16:58 |
| ayoung | and we did not discuss the RBAC in middleware, because we were once again derailed. | 16:59 |
| hrybacki | :( | 16:59 |
| edmondsw | ayoung you dominated the conversation, so you can't blame anyone else on that ;) | 16:59 |
| samueldmq | #endmeeting | 17:00 |
| lbragstad | #endmeeting | 17:00 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:00 | |
| openstack | Meeting ended Wed May 24 17:00:33 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-05-24-16.01.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-05-24-16.01.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-05-24-16.01.log.html | 17:00 |
| *** zhipeng_ has quit IRC | 17:13 | |
| *** blancos has left #openstack-meeting-cp | 17:23 | |
| *** spilla has quit IRC | 17:53 | |
| *** gagehugo has left #openstack-meeting-cp | 18:07 | |
| *** Rockyg has quit IRC | 18:12 | |
| *** ayoung has left #openstack-meeting-cp | 18:23 | |
| *** prometheanfire has joined #openstack-meeting-cp | 18:53 | |
| *** prometheanfire has left #openstack-meeting-cp | 18:53 | |
| *** jaugustine has quit IRC | 18:58 | |
| *** nhelgeson has quit IRC | 19:17 | |
| *** diablo_rojo has quit IRC | 19:24 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 19:36 | |
| *** felipemonteiro has quit IRC | 19:39 | |
| *** rarcea has quit IRC | 20:10 | |
| *** aselius has quit IRC | 20:13 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 20:37 | |
| *** edmondsw has quit IRC | 21:58 | |
| *** felipemonteiro_ has quit IRC | 22:08 | |
| *** gouthamr has quit IRC | 22:32 | |
| *** gouthamr has joined #openstack-meeting-cp | 23:04 | |
| *** lamt has quit IRC | 23:12 | |
| *** sdague has quit IRC | 23:17 | |
| *** edmondsw has joined #openstack-meeting-cp | 23:32 | |
| *** edmondsw has quit IRC | 23:36 | |
| *** diablo_rojo has quit IRC | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!