| *** tovin07 has joined #openstack-meeting-cp | 00:59 | |
| *** tovin07 has quit IRC | 00:59 | |
| *** tovin07 has joined #openstack-meeting-cp | 01:00 | |
| *** tovin07 has quit IRC | 01:01 | |
| *** tovin07 has joined #openstack-meeting-cp | 01:01 | |
| *** tovin07 has quit IRC | 01:02 | |
| *** tovin07 has joined #openstack-meeting-cp | 01:02 | |
| *** tovin07_ has joined #openstack-meeting-cp | 01:15 | |
| *** zhurong has joined #openstack-meeting-cp | 01:19 | |
| *** brault has quit IRC | 03:04 | |
| *** zhurong has quit IRC | 03:04 | |
| *** zhurong has joined #openstack-meeting-cp | 03:07 | |
| *** zhurong has quit IRC | 03:35 | |
| *** zhurong has joined #openstack-meeting-cp | 03:36 | |
| *** markvoelker has quit IRC | 04:02 | |
| *** jgriffith is now known as jgriffith_away | 04:10 | |
| *** prateek has joined #openstack-meeting-cp | 05:18 | |
| *** markvoelker has joined #openstack-meeting-cp | 06:02 | |
| *** markvoelker has quit IRC | 06:08 | |
| *** gouthamr has joined #openstack-meeting-cp | 07:30 | |
| *** brault has joined #openstack-meeting-cp | 07:39 | |
| *** gouthamr has quit IRC | 09:04 | |
| *** markvoelker has joined #openstack-meeting-cp | 09:32 | |
| *** markvoelker has quit IRC | 09:37 | |
| *** zhurong has quit IRC | 10:01 | |
| *** tovin07_ has quit IRC | 10:06 | |
| *** rakhmerov has quit IRC | 11:01 | |
| *** ativelkov has quit IRC | 11:01 | |
| *** IgorYozhikov has quit IRC | 11:03 | |
| *** ativelkov has joined #openstack-meeting-cp | 11:03 | |
| *** IgorYozhikov has joined #openstack-meeting-cp | 11:03 | |
| *** rakhmerov has joined #openstack-meeting-cp | 11:05 | |
| *** prateek has quit IRC | 11:37 | |
| *** prateek has joined #openstack-meeting-cp | 12:05 | |
| *** prateek has quit IRC | 12:07 | |
| *** prateek has joined #openstack-meeting-cp | 12:08 | |
| *** prateek has quit IRC | 12:10 | |
| *** prateek has joined #openstack-meeting-cp | 12:17 | |
| *** prateek has quit IRC | 12:17 | |
| *** prateek has joined #openstack-meeting-cp | 12:18 | |
| *** prateek has quit IRC | 12:24 | |
| *** prateek has joined #openstack-meeting-cp | 12:25 | |
| *** gouthamr has joined #openstack-meeting-cp | 12:32 | |
| *** prateek_ has joined #openstack-meeting-cp | 13:26 | |
| *** markvoelker has joined #openstack-meeting-cp | 13:28 | |
| *** prateek has quit IRC | 13:30 | |
| *** xyang1 has joined #openstack-meeting-cp | 13:36 | |
| *** lamt has joined #openstack-meeting-cp | 13:39 | |
| *** prateek_ has quit IRC | 13:46 | |
| *** prateek has joined #openstack-meeting-cp | 13:47 | |
| *** prateek_ has joined #openstack-meeting-cp | 13:57 | |
| *** prateek has quit IRC | 13:59 | |
| *** beisner has joined #openstack-meeting-cp | 14:04 | |
| *** parora has joined #openstack-meeting-cp | 14:18 | |
| *** prateek has joined #openstack-meeting-cp | 14:21 | |
| *** prateek_ has quit IRC | 14:22 | |
| *** parora has quit IRC | 14:24 | |
| *** prateek_ has joined #openstack-meeting-cp | 14:24 | |
| *** prateek has quit IRC | 14:27 | |
| *** linux_ has joined #openstack-meeting-cp | 15:05 | |
| *** danielaebert has joined #openstack-meeting-cp | 15:14 | |
| *** prateek_ has quit IRC | 15:46 | |
| *** prateek_ has joined #openstack-meeting-cp | 15:46 | |
| *** danielaebert has quit IRC | 15:47 | |
| *** spilla has joined #openstack-meeting-cp | 15:53 | |
| *** gagehugo has joined #openstack-meeting-cp | 15:58 | |
| *** ktychkova has joined #openstack-meeting-cp | 15:59 | |
| lbragstad | o/ | 16:00 |
|---|---|---|
| lbragstad | ping lbragstad, raildo, ruan_04, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw | 16:00 |
| gagehugo | o/ | 16:01 |
| lamt | o/ | 16:01 |
| rderose | o/ | 16:01 |
| ktychkova | o/ | 16:01 |
| spilla | o/ | 16:01 |
| lbragstad | #startmeeting policy | 16:01 |
| openstack | Meeting started Wed Nov 23 16:01:23 2016 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 |
| *** linux_ has left #openstack-meeting-cp | 16:01 | |
| lbragstad | alright - i imagine this going to be a pretty light meeting, given it's US holiday tomorrow | 16:01 |
| lbragstad | we'll give it until 4 after for others to show up | 16:02 |
| lbragstad | #topic action items from last week | 16:04 |
| *** openstack changes topic to "action items from last week (Meeting topic: policy)" | 16:04 | |
| *** ayoung has joined #openstack-meeting-cp | 16:04 | |
| lbragstad | ACTION ITEM: ayoung to repropose https://review.openstack.org/#/c/391624/ | 16:04 |
| lbragstad | looks like he did - did anyone have a chance to look that spec over? | 16:04 |
| ayoung | Covered a bit of this in the meeting yesterday. The biggest difference is the focus on not-breaking caching | 16:05 |
| lbragstad | ayoung yeah - that would be significant | 16:05 |
| lbragstad | ayoung you broke the proposed implementation into pieces | 16:05 |
| ayoung | the RBAC check is going to be performed in the keystonemiddleware auth_token layer, after token validation, and before returning passing to the calling WSGI applicaion | 16:06 |
| ayoung | we'll keep an option on the table to do the check as part of the token validation, but that will be prioritized after the out-of-band check | 16:06 |
| ayoung | er...whatever the middleware check is called | 16:06 |
| ayoung | would like this to get in to Ocata, or at least the management API | 16:07 |
| ayoung | I am about ready to propose a WIP patch, just trying to sort the JSON home tests and get a clean Tox run first | 16:07 |
| lbragstad | ayoung can you take a step back and define management API for those who missed the keystone meeting yesterday? | 16:07 |
| ayoung | so, before you can enforce RBAC, you need to define the rules | 16:07 |
| lbragstad | which are currently defined in various policy.json files across the services | 16:08 |
| ayoung | the API is going to be built on a new Database entity that I am right now calling url_pattern | 16:08 |
| ayoung | the URL pattern object looks like this | 16:08 |
| ayoung | sql.Column('id', sql.String(length=64), primary_key=True), | 16:08 |
| ayoung | sql.Column('service', sql.String(length=64), nullable=False), | 16:08 |
| ayoung | sql.Column('verb', sql.String(length=64)), | 16:08 |
| ayoung | sql.Column('pattern', sql.Text, nullable=False), | 16:08 |
| ayoung | sql.Column('role_id', sql.String(length=64), primary_key=True), | 16:08 |
| ayoung | we had a discussion about the subtleties around the role_id yesterday that is worth recapping | 16:09 |
| ayoung | the URL pattern here could also be called "operation" | 16:09 |
| *** knikolla has joined #openstack-meeting-cp | 16:10 | |
| ayoung | the unique key is the URL + the Verb | 16:10 |
| ayoung | so GET /v3/users | 16:10 |
| ayoung | or PUT /v3/user/{user_id} | 16:10 |
| ayoung | the service is the string name (not the ID) to be friendly to end deployers | 16:10 |
| ayoung | they know about "compute" not about UUIDs | 16:10 |
| *** thinrichs has joined #openstack-meeting-cp | 16:11 | |
| ayoung | and this is purposely kept separate from the Service Catalog...a point we can debate later if so desired | 16:11 |
| ayoung | do we have a quorum here? | 16:11 |
| ayoung | want to make sure this is actually useful to people (beside lbragstad ) before carrying on? | 16:11 |
| lbragstad | ayoung we have 7 folks here, including you | 16:12 |
| rderose | I'm following | 16:12 |
| ayoung | ++ | 16:12 |
| ayoung | OK, so the interesting part is the role_id | 16:12 |
| thinrichs | Hi all. Sorry I'm late. | 16:12 |
| lbragstad | thinrichs o/ | 16:12 |
| ayoung | that is limited to one role, but via implied roles, it can actually be many | 16:12 |
| *** gouthamr has quit IRC | 16:12 | |
| *** gouthamr has joined #openstack-meeting-cp | 16:13 | |
| ayoung | so if a user has member, and member implied reader, you could have the reader role_id mapped to the URL pattern GET /v3/users | 16:13 |
| ayoung | and so anyone with the Member role would be able to perform it. | 16:13 |
| lbragstad | thinrichs you should be able to get scrollback here in a few minutes - http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-cp/%23openstack-meeting-cp.2016-11-23.log.html | 16:13 |
| thinrichs | lbragstad: thanks! | 16:14 |
| lbragstad | thinrichs but right now we are addressing action items from last week | 16:14 |
| lbragstad | and i completely forgot to publish the agenda #link https://etherpad.openstack.org/p/keystone-policy-meeting | 16:14 |
| thinrichs | lbragstad: great--looking at the agenda right now | 16:14 |
| ayoung | the reason to focus on implied roles is to allow a path to delegating a subset of the roles required to just perform the operation | 16:15 |
| lbragstad | thinrichs ayoung is describing his spec right now... so if anyone has questions on it, now is the time | 16:15 |
| ayoung | lets take a simplified view of computes create server | 16:15 |
| ayoung | this is an API a user calls on Nova, but then nova has to call a few other services: | 16:16 |
| ayoung | glance, neutron, cinder | 16:16 |
| ayoung | so, we would want to have a consistent set of roles across the APIs to those other services that a user could do. Lets call this role create_compute: | 16:16 |
| ayoung | member->create_compute | 16:17 |
| ayoung | read -> as "implies" BTW | 16:17 |
| *** ruan_06 has joined #openstack-meeting-cp | 16:17 | |
| ayoung | so if a user wants to delegat to a service user (say heat via the trust API) they can delegate create_compute even though they are only explicitly assigned member | 16:17 |
| ayoung | the alternative was to say that each url_pattern had multiple roles assigned to it. | 16:18 |
| ayoung | so if we had a system where POST /v2/compute creates a VM | 16:19 |
| ayoung | we could assign multiple roles to that operation. Member would be there for everyone | 16:19 |
| ayoung | but to delegate something that could "only" do POST /v2/compute and not all of the other things that a member can do, we would have to explicitly assign that new role to all the users | 16:20 |
| ayoung | implied roles make it possible to keep this manageable, and to do least privilege | 16:20 |
| rderose | hmm... so in this design, there isn't an admin role for ready and write; you'd have to have multiple roles to perform all operations, correct? | 16:20 |
| rderose | *read and write | 16:20 |
| ayoung | rderose, ok, lets talk that through | 16:20 |
| ayoung | rderose, lets start where we are today | 16:21 |
| ayoung | most of the admin operations would require the admin role | 16:21 |
| ayoung | if you wanted to split them into read and write, you would create two new roles: admin_read, admin_write | 16:21 |
| ayoung | and set admin->admin_read and admin->admin_write | 16:21 |
| ayoung | then you would modify the url_pattern for an operation and explicitly make it admin_read or admin_write | 16:22 |
| lbragstad | (i.e. would POST /v3/domains/{domain_id} fall under a admin_write operation) | 16:22 |
| ayoung | the end administrators would still be able to perform all the actions | 16:22 |
| ayoung | sure | 16:22 |
| ayoung | that is a good example of one | 16:22 |
| ayoung | so that would now get admin_write | 16:22 |
| ayoung | and GET /v3/domains/{domain_id} would get admin_read | 16:22 |
| ayoung | now, lets say that we decide GET /v3/domains/{domain_id} should be world readable | 16:23 |
| ayoung | we create a new role, reader | 16:23 |
| ayoung | admin_read -> reader | 16:23 |
| ayoung | we change GET /v3/domains/{domain_id} so it is associated with reader, and anything to which we delegated the admin_read role would still work | 16:24 |
| ayoung | It allows you to roll-forward policy | 16:24 |
| ruan_06 | don't you think we will toooo many roles to manage? | 16:24 |
| ayoung | ruan_06, eventually, yes | 16:25 |
| thinrichs | Implied roles makes sense. I'm assuming if role r1 implies roles r2 and r3 that r1 gets the union of r1, r2, r3 rights. Correct? | 16:25 |
| ayoung | ruan_06, to start with, no | 16:25 |
| ayoung | ruan_06, as a follow on, however, we can make the following adjustments: | 16:25 |
| *** jgriffith_away is now known as jgriffith | 16:25 | |
| ayoung | today, we expand implied roles in the token validation response | 16:25 |
| thinrichs | agree with ruan_06 that people will almost immediately want tooling to understand what rights any given user actually has. | 16:25 |
| ayoung | thinrichs, tooling is possible, and can be done manually to start, built in a supported tool as a second step | 16:26 |
| ayoung | ok, back to too many rules: | 16:26 |
| ruan_06 | I agree that this can be a short term solution, better than the current solution | 16:26 |
| ayoung | lets talk about validation for a moment | 16:26 |
| ayoung | assuming this is all done in middleware, ithe flow will be like this: | 16:26 |
| thinrichs | ayoung: keystone has implied roles today? I thought this was part of the spec. | 16:27 |
| rderose | ruan_06: but we want a long term solution; not something that is just better than what we have | 16:27 |
| ayoung | after the middleware has validate the token (or fetched the token data from cache) the middleware will fetch the url_patterns from the Keystone server | 16:27 |
| lbragstad | thinrichs implied roles exists today - but i'm not sure what it's current usage distribution is | 16:27 |
| lbragstad | rderose ++ | 16:27 |
| ayoung | that will be done based on the "service" string that middleware will read out of the config file | 16:27 |
| ayoung | lbragstad, I'd assume none, as the CLI is still up for review | 16:28 |
| ayoung | #link https://review.openstack.org/#/c/290253/ | 16:28 |
| ayoung | ok, so it fetches the url_patterns, and matches the one the user requested | 16:28 |
| ruan_06 | redrobot: if you want a real one, we should switch from RBAC to ABAC | 16:28 |
| ayoung | from there it looks at the "role" attribute and does a match with the set of roles in the auth_data | 16:29 |
| ayoung | ruan_06, different conversation | 16:29 |
| ayoung | let's table that for now, as it is important, but will take much longer | 16:29 |
| lbragstad | ayoung so from a performance perspective - i have concerns | 16:29 |
| ayoung | lbragstad, hold on for a moment | 16:29 |
| ayoung | let me finish talking through the validation and too many roles concern | 16:30 |
| ayoung | what we can do when we have more roles is switch to *not* expanding the roles in the token validation response, and instead add those to a "roles" attribute of the url_opattern | 16:30 |
| ayoung | this would be a calculated value, with the implied-roles data used to generate a set. The generation would be backwards from the implied roles; for each implied-role, get the list of prior roles | 16:31 |
| ayoung | should be a small subset per URL pattern | 16:31 |
| ayoung | and it will have to be calculated once per- url pattern list | 16:32 |
| *** thinrichs has quit IRC | 16:32 | |
| *** thinrichs has joined #openstack-meeting-cp | 16:32 | |
| ayoung | the URL pattern list is itself a JSON document, and would be stored in the same Memcache that is used for the tokens | 16:32 |
| ayoung | it would be refetched based on cache timeout, just like the tokens are | 16:32 |
| ayoung | and would not be fetched from Keystone on each token | 16:33 |
| ayoung | OK... lbragstad you had a question about performance? | 16:33 |
| lbragstad | ayoung we currently have each service validate two tokens (the subject token and the auth token) for an operation | 16:33 |
| lbragstad | now we are going to be adding another round trip to the equation to get the list of url_patterns | 16:34 |
| lbragstad | how long would the cache be valid for? | 16:34 |
| lbragstad | if we set invalidation too long we're going to start running into revocation cases | 16:34 |
| lbragstad | if we choose to get a fresh list of url_patterns on every token validation, we're going to be drastically increasing traffic to keystone | 16:36 |
| ayoung | No revocations | 16:37 |
| ayoung | We cache as long as the user is comfortable with holding the data | 16:37 |
| lbragstad | (this is essentially fore-shadowing my concern about the third step in the process that pulls the RBAC decision and url_pattern matching into keystone token validation check) | 16:37 |
| ayoung | 1 minute? | 16:37 |
| ayoung | the url Data will be longer, probably | 16:37 |
| ayoung | 10 minutes, whatever they are comfortable with for a change to RBAC policy | 16:38 |
| ayoung | token validation does not change | 16:38 |
| lbragstad | so what happens if a user does something and the policy or url_patterns change in that time/ | 16:38 |
| ayoung | lbragstad, its an eventual consistency approach. Either the operation has the old behavior or the new | 16:38 |
| ruan_06 | this is the drawback of the token-based approach | 16:39 |
| ayoung | yeah, but this is all trade off for perf | 16:39 |
| ayoung | if we sent each request to the Keystone server, as in the original proposal, we get immediate enforcement, at the cost of perf | 16:39 |
| ayoung | CAP theorem stuff still applies too. | 16:39 |
| ayoung | if you want to create some way to automatically flush the caches, go for it, but it really is outside the scope and control of Keystone | 16:40 |
| ayoung | we've discussed that before, and it just is too invasive | 16:40 |
| ayoung | We could do something in the future where we put a checksum in both the RBAC file and in the tokem, and if they don't match, refetch, but I am not goimng to try and implement that in the context of this review | 16:41 |
| ayoung | too muich | 16:41 |
| ayoung | too little benefit | 16:41 |
| dstanek | ayoung: that could be bolted on later. i don't see that changing your design | 16:42 |
| dstanek | ayoung: tbh, i meant to reread the spec again last night, but ran out of time. | 16:42 |
| thinrichs | Time check: 20min left. Seems we understand the design and tradeoffs for this proposal. Are there other agenda items we want to fit into this meeting? | 16:42 |
| lbragstad | yeah - we had a few more action items from last week | 16:43 |
| lbragstad | I wanted to give ktychkova some time to explain what she has been able to accomplish with Apache Fortress | 16:43 |
| lbragstad | (if she want to) | 16:44 |
| lbragstad | wants* | 16:44 |
| ktychkova | Yes | 16:44 |
| ktychkova | Apache Fortress is a java implementation of RBAC | 16:44 |
| ayoung | It is essentially an external PDP | 16:44 |
| ayoung | more than just RBAC, right? | 16:44 |
| lbragstad | ok - so now that ayoung has filled us in on his spec - i'll leave the action item for folks to go back and continue looking at it. | 16:44 |
| lbragstad | let's carry the discussion about RBAC and url_patterns there | 16:45 |
| ayoung | We'd consider the APache fortress approach full ABAC | 16:45 |
| ayoung | lbragstad, ++ | 16:45 |
| ktychkova | It is possible to integrate it with OpenStack | 16:45 |
| lbragstad | #topic ktychkova to summarize work with Apache Fortress and keystone | 16:45 |
| *** openstack changes topic to "ktychkova to summarize work with Apache Fortress and keystone (Meeting topic: policy)" | 16:45 | |
| lbragstad | #link http://directory.apache.org/fortress/ | 16:45 |
| lbragstad | #link http://xuctarine.blogspot.ru/2016/08/apache-fortress-easiest-way-to-get-full.html | 16:45 |
| ktychkova | ok | 16:45 |
| ktychkova | so Apache Fortress is RBAC implementation with a web interface to manage policies | 16:45 |
| ktychkova | The point is: Apache Fortress should not be some default thing in the OpenStack | 16:46 |
| ktychkova | But it would be nice to support 3rd party apps for the RBAC | 16:46 |
| ktychkova | It doesn't require any changes in Keystone, only in oslo.policy | 16:46 |
| ayoung | ktychkova, so oslo.policy is doing more than just RBAC | 16:46 |
| ayoung | most important, it is doing the scope check | 16:47 |
| ruan_06 | ktychkova: you mean externalize authorization to Fortress? | 16:47 |
| ayoung | is that to be done in Fortress, or left in a static file? | 16:47 |
| ktychkova | ruan_06: yes | 16:47 |
| ayoung | https://blueprints.launchpad.net/keystone/+spec/assignments-in-fortress was posted about a year ago | 16:47 |
| ayoung | #link more recent http://xuctarine.blogspot.com/2016/06/apache-fortress-instead-of-policyjson.html | 16:48 |
| ayoung | #link http://xuctarine.blogspot.com/2016/06/apache-fortress-instead-of-policyjson.html | 16:48 |
| ayoung | more recent doc explaining a POC | 16:48 |
| ayoung | ktychkova, is that your blog? | 16:49 |
| ktychkova | ayoung: yes | 16:49 |
| ruan_06 | that's a good idea to externalize authorization | 16:50 |
| lbragstad | ktychkova it looks like the changes you made to keystone were minimal - most of the work was in oslo.policy, right? | 16:51 |
| ktychkova | right | 16:51 |
| ktychkova | no changes in Keystone | 16:51 |
| lbragstad | just configuration | 16:51 |
| ruan_06 | ktychkova: where to store role-assignment information? | 16:52 |
| lbragstad | ktychkova i assume you had to duplicate all of the policy from policy.json into AF | 16:52 |
| ktychkova | yes, AF stores everything in OpenLDAP | 16:52 |
| ayoung | ktychkova, is it using RFC schemas, or something custom? | 16:53 |
| ktychkova | custom, i guess | 16:53 |
| ayoung | Is this something we could describe to someone with a different LDAP server and say that the implementation would be done the same way? | 16:53 |
| *** stvnoyes has quit IRC | 16:53 | |
| thinrichs | Is every request sent to oslo.policy hopping over the network to ask Fortress? Or is there some caching going on? | 16:53 |
| ayoung | ktychkova not necessarily custom. I did the initial LDAP work and there is a scheme in the RFS to do RVBAC | 16:54 |
| ayoung | RBAC | 16:54 |
| ayoung | organizationalRole IIRC | 16:54 |
| *** Kiall has joined #openstack-meeting-cp | 16:54 | |
| *** stvnoyes has joined #openstack-meeting-cp | 16:54 | |
| lbragstad | ktychkova is https://review.openstack.org/#/c/237521/ the only patch you needed to get things working with oslo.policy? | 16:54 |
| ktychkova | yes | 16:54 |
| lbragstad | well - that's cool | 16:55 |
| ktychkova | ayoung: I'm not sure about schemas, it was out of the scope of my research | 16:56 |
| ktychkova | I used Apache Fortress as is | 16:56 |
| thinrichs | ktychkova: Is every request sent to oslo.policy hopping over the network to ask Fortress? Or is there some caching going on? | 16:56 |
| ayoung | So, I have a couple concerns | 16:57 |
| lbragstad | so - i guess if we wanted to do this today, we'd need to go through the following. 1.) propose a spec to oslo.policy for https://review.openstack.org/#/c/237521/ 2.) formally document AF process in keystone | 16:57 |
| ayoung | the biggest one is how Fortrass treats roles | 16:57 |
| ayoung | are they global, or does it have the concept of a scope? | 16:57 |
| ktychkova | no caching in my patch, but it is PoC | 16:57 |
| lbragstad | two minute warning | 16:58 |
| ayoung | question is whether it is possible to cache. | 16:58 |
| ktychkova | ayoung: what do you mean "scope"? | 16:58 |
| ayoung | ktychkova, a role is assigned to a user "on a project" in openstackl | 16:58 |
| ayoung | so the member role is not a global role | 16:58 |
| thinrichs | ayoung: right question: can we cache? | 16:58 |
| thinrichs | ktychkova: To be clear I think that's a cool POC! | 16:59 |
| ayoung | thinrichs, I think the answer is No. Only identical request can be cached | 16:59 |
| ayoung | each request for a different user or a different operation requires its own decision | 16:59 |
| lbragstad | alright - let's continue our discussion in #openstack-keystone | 16:59 |
| lbragstad | #endmeeting | 16:59 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:59 | |
| openstack | Meeting ended Wed Nov 23 16:59:55 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-11-23-16.01.html | 16:59 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-11-23-16.01.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-11-23-16.01.log.html | 17:00 |
| *** gagehugo has left #openstack-meeting-cp | 17:00 | |
| *** spilla has left #openstack-meeting-cp | 17:01 | |
| *** thinrichs has quit IRC | 17:01 | |
| *** hogepodge has joined #openstack-meeting-cp | 17:28 | |
| *** hogepodge has quit IRC | 17:33 | |
| *** hogepodge has joined #openstack-meeting-cp | 17:43 | |
| *** parora has joined #openstack-meeting-cp | 18:13 | |
| *** prateek_ has quit IRC | 18:16 | |
| *** prateek_ has joined #openstack-meeting-cp | 18:24 | |
| *** parora has quit IRC | 18:27 | |
| *** markvoelker has quit IRC | 18:35 | |
| *** prateek_ has quit IRC | 18:38 | |
| *** jgriffith is now known as jgriffith_away | 18:42 | |
| *** jgriffith_away is now known as jgriffith | 19:14 | |
| *** gouthamr has quit IRC | 20:50 | |
| *** flaper87 has quit IRC | 20:52 | |
| *** xyang1 has quit IRC | 22:59 | |
| *** lamt has quit IRC | 23:43 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!