| *** rushil has quit IRC | 00:03 | |
| *** _cjones_ has joined #openstack-keystone | 00:06 | |
| *** openstack has joined #openstack-keystone | 00:07 | |
| *** zzzeek has quit IRC | 00:09 | |
| *** _cjones_ has quit IRC | 00:13 | |
| *** samueldmq has quit IRC | 00:15 | |
| *** _cjones_ has joined #openstack-keystone | 00:16 | |
| *** samueldmq has joined #openstack-keystone | 00:16 | |
| samueldmq | lhcheng, hi, you still there ? | 00:17 |
|---|---|---|
| samueldmq | lhcheng, sorry I was afk | 00:17 |
| samueldmq | dstanek, ping - any news on the devstack thing ? | 00:17 |
| lhcheng | samueldmq: hey, np | 00:18 |
| samueldmq | lhcheng, was just concerning your comment on the 'dynamic policy' overview spec | 00:18 |
| lhcheng | samueldmq: I know are testing v3 on devstack, wondering if you're using the v3 policy file for keystone | 00:18 |
| samueldmq | lhcheng, I replied there | 00:19 |
| samueldmq | lhcheng, yes I am, no for now I am not changing the default for keystone | 00:19 |
| *** rm_work is now known as rm_work|away | 00:20 | |
| samueldmq | lhcheng, btw , my team made some work on checking a cloud policy | 00:21 |
| samueldmq | ayoung, cc ^ | 00:21 |
| lhcheng | samueldmq: thanks on working on that, looking forward on the revised spec | 00:21 |
| samueldmq | I wonder if that could be useful to have for L | 00:22 |
| samueldmq | maybe a separate project to validate the policies .. dunno | 00:22 |
| lhcheng | samueldmq: It would be nice if we can get the v3 policy file working | 00:22 |
| *** markvoelker has quit IRC | 00:23 | |
| lhcheng | samueldmq: there are couple of folks from horizon trying to exercise the v3 policy file, and fixing the policy as they go. | 00:24 |
| samueldmq | lhcheng, hmm, I think we had defined different roles for cloud admin + domain admin + project admin | 00:24 |
| samueldmq | lhcheng, tomorrow I can try to retrieve the work we've done last year .. | 00:24 |
| samueldmq | lhcheng, when I get to the laboratory | 00:24 |
| lhcheng | I remember seeing that patch | 00:25 |
| samueldmq | lhcheng, maybe it can help you guys | 00:25 |
| lhcheng | I like that idea | 00:25 |
| samueldmq | lhcheng, yeah but I think we didnt get enough people interested on | 00:25 |
| samueldmq | lhcheng, the general idea was to have a cloud policy on all the services | 00:25 |
| samueldmq | (except domain admin in services, since other projects do not knwo about domains .. ) | 00:26 |
| samueldmq | and this will change since they will all be working with v3 auth on L | 00:26 |
| samueldmq | :) | 00:26 |
| lhcheng | samueldmq: bummer, specific roles makes it clearer for deployer. should make their life easier | 00:26 |
| samueldmq | lhcheng, yeah do you know domain-roles? | 00:27 |
| samueldmq | lhcheng, I think that is what you're talking about ! | 00:27 |
| lhcheng | yeah | 00:27 |
| *** dims has joined #openstack-keystone | 00:27 | |
| samueldmq | lhcheng, https://review.openstack.org/#/c/133855/10/specs/kilo/domain-roles.rst | 00:27 |
| lhcheng | samueldmq: no I am talking about: "cloud admin + domain admin + project admin" | 00:27 |
| lhcheng | but I also know about the domain roles | 00:28 |
| samueldmq | lhcheng, there are conflicting ideas around domain-roles (henrynash) vs hierarchical roles (ayoung) | 00:28 |
| samueldmq | lhcheng, we will talk about it on tomorrow s meeting, to agree on them | 00:28 |
| lhcheng | samueldmq: two roles enter one role leave | 00:29 |
| lhcheng | :P | 00:29 |
| samueldmq | three enter :p | 00:29 |
| lhcheng | hah | 00:29 |
| samueldmq | we completely drop the global admin everyone hates | 00:29 |
| samueldmq | lhcheng, trust me , L will be amazing :p | 00:30 |
| samueldmq | lhcheng, everyone running v3 on the gate jobs + dynamic policies (fine-grained, more powerful roles, etc) | 00:30 |
| samueldmq | lhcheng, I will be focusing on these ^ | 00:30 |
| lhcheng | samueldmq: yeah, but consuming v2 policy file is bad though. I hope we can tackle consuming the v3 policy file too in L. | 00:31 |
| lhcheng | v2 -> default | 00:32 |
| lhcheng | samueldmq: looking forward to those :) | 00:34 |
| lhcheng | samueldmq: anyway, we can look at consuming v3 policy later. one step at a time. :) | 00:34 |
| samueldmq | lhcheng, yeah .. but deployers have their custom policy files ... | 00:35 |
| samueldmq | lhcheng, maybe someone already has a fully-working cloud policy working | 00:35 |
| samueldmq | lhcheng, :p | 00:35 |
| lhcheng | samueldmq: we need to have them come out :D | 00:35 |
| samueldmq | lhcheng, I remember we my team was working on this someone said: 'I saw the ops summit and I didnt see anyone blaming the policy file' | 00:37 |
| samueldmq | lhcheng, so I think someone has it working :p | 00:37 |
| samueldmq | lhcheng, but yeah, we will get there | 00:37 |
| lhcheng | cool, the horizon folks are submitting bugs too as they go trying to use the v3 policy file. Hopefully by the time you switch to v3 policy file, all glitch are cleared :) | 00:39 |
| samueldmq | lhcheng, ++ | 00:40 |
| samueldmq | lhcheng, they're submitting for all services? | 00:40 |
| samueldmq | lhcheng, also, it will be better to have a full cloud policy when everyone talk v3, then we can have the cloud admin there :) | 00:41 |
| lhcheng | no, they're still trying to get all keystone operation to work. Haven't got to other services yet. | 00:41 |
| samueldmq | lhcheng, I meant domain admin | 00:41 |
| samueldmq | lhcheng, since using v3 they will know about domains | 00:41 |
| samueldmq | lhcheng, k makes sense to have it already on keystone | 00:41 |
| samueldmq | ++ | 00:41 |
| lhcheng | samueldmq: good stuff | 00:42 |
| lhcheng | samueldmq: have to step out for a bit | 00:42 |
| lhcheng | samueldmq: chat with you later | 00:43 |
| *** _cjones_ has quit IRC | 00:43 | |
| samueldmq | lhcheng, np see you | 00:44 |
| *** markvoelker has joined #openstack-keystone | 00:54 | |
| *** markvoelker has quit IRC | 00:59 | |
| *** stevemar has joined #openstack-keystone | 01:01 | |
| *** ChanServ sets mode: +v stevemar | 01:01 | |
| jamielennox | samueldmq: so what are you looking at specifically with regard to v3 and devstack as this is something i'm doing a lot around as well | 01:13 |
| *** edmondsw has quit IRC | 01:13 | |
| jamielennox | i don't think i have patches up for devstack yet, just some WIP stuff but i've mostly been looking at what services break and fixing those up first | 01:13 |
| *** josecastroleon has joined #openstack-keystone | 01:17 | |
| *** josecastroleon has quit IRC | 01:18 | |
| *** alexsyip has quit IRC | 01:20 | |
| *** junhongl has quit IRC | 01:24 | |
| *** junhongl has joined #openstack-keystone | 01:25 | |
| *** erkules_ has joined #openstack-keystone | 01:31 | |
| *** fifieldt has joined #openstack-keystone | 01:32 | |
| *** erkules has quit IRC | 01:34 | |
| samueldmq | jamielennox, hi yes | 01:35 |
| samueldmq | jamielennox, I know you are the guy for v3 auth compatibility :) | 01:36 |
| samueldmq | jamielennox, you have been doing an amazing job on clients, I think most of them work with with sessions / v3 right ? | 01:36 |
| jamielennox | samueldmq: cheers - yea, most work, there are still some left - at the moment i'm looking at services and how they use those clients so we can shift those over to v3 | 01:37 |
| samueldmq | jamielennox, great! what I am doing now is to have experimental jobs with v2 API disabled on devstack, and then tempest set to use auth v3 only | 01:37 |
| jamielennox | cool, how many errors are you seeing? | 01:38 |
| samueldmq | jamielennox, no one yet, since this is still wip :p | 01:38 |
| samueldmq | jamielennox, I tried to set up devstack manually and then disable v2, set tempest to use v3 all manually | 01:39 |
| samueldmq | jamielennox, but looks like devstack has a bug ... dstanek was looking at it .. | 01:39 |
| samueldmq | after installed, we're getting 500 from keystone | 01:39 |
| samueldmq | (with no changes, just devstack installing normally) | 01:39 |
| jamielennox | ok, that sounds like a keystone issue, i'll let you guys figure that out | 01:40 |
| jamielennox | have you got patches up for devstack v3 only or waiting for that to be sorted otu? | 01:41 |
| jamielennox | out? | 01:41 |
| samueldmq | no morgan is working on this front | 01:41 |
| samueldmq | I will probably be working on the gate thing | 01:42 |
| samueldmq | will write the job at project-config, then devstack-gate, and then devstack | 01:43 |
| samueldmq | in this point https://github.com/openstack-dev/devstack/blob/3894170067a4ca26952ef9b1315864c8dde8e1ad/lib/keystone#L197 | 01:43 |
| samueldmq | where we will need to change the paste deploy in order to remove the /v2.0 endpoints | 01:43 |
| samueldmq | and morgan is taking care of the devstack to change all places it use v2 to v3 | 01:44 |
| samueldmq | sounds good ? let me know if you have any suggestions :) | 01:44 |
| samueldmq | jamielennox, ^ | 01:44 |
| jamielennox | samueldmq: yea, that sounds fine - i knew morganfainberg was looking at this as well i just didn't want to see us get in each others way | 01:46 |
| *** dims has quit IRC | 01:46 | |
| samueldmq | jamielennox, yes, we're getting now .. ftw | 01:47 |
| jamielennox | i know i need a devstack where i can disable v2 for testing rather than doing my own hacks, so i'll just waiting and see what patches people come up with rather than write them again | 01:47 |
| samueldmq | jamielennox, it would be great if we could get it working before summit | 01:47 |
| jamielennox | we could maybe disable the CRUD v2 interface by then, v2 auth will still take a while longer | 01:48 |
| samueldmq | jamielennox, well, both we need to deprecate and wait right ? | 01:48 |
| samueldmq | I dont know how many cycles .. I am new here :/ | 01:48 |
| jamielennox | samueldmq: sure, we can't get rid of them immediately - it's normally 2 cycles | 01:49 |
| samueldmq | jamielennox, ++ | 01:49 |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Create AccessInfo auth plugin from token https://review.openstack.org/178024 | 01:52 |
| *** ncoghlan has joined #openstack-keystone | 01:54 | |
| *** browne has quit IRC | 01:55 | |
| *** markvoelker has joined #openstack-keystone | 01:55 | |
| ayoung | morganfainberg, marekd OK...public demo of SAML and ECP is up and running | 01:59 |
| *** ayoung has quit IRC | 01:59 | |
| *** markvoelker has quit IRC | 01:59 | |
| *** ayoung has joined #openstack-keystone | 02:00 | |
| *** ChanServ sets mode: +v ayoung | 02:00 | |
| ayoung | mordred, stevemar, dstanek https://review.openstack.org/#/c/138519/ is very much critical path: it will hold up lots of other patches. Can you please bump priority of reviewing it | 02:04 |
| ayoung | er mordred meant that for morganfainberg | 02:04 |
| ayoung | but you can look, too | 02:04 |
| jamielennox | ayoung: why not push it to keystone for now | 02:13 |
| ayoung | jamielennox, no more churn. It needs to be in both | 02:14 |
| jamielennox | ayoung: i'm still not convinced i want to allow token building facilities in ksc, and with the split out of ksa i think it's going to take a while before it finds a home | 02:14 |
| ayoung | jamielennox, I have the follow on patches that replace the access info in KC with this | 02:14 |
| ayoung | jamielennox, token building will use this, but it is not token building, but just strict parsing | 02:15 |
| jamielennox | ayoung: only because we have a crappy implementation of revocations in client that was copy and pasted from the server | 02:15 |
| jamielennox | ayoung: strict parsing isn't required from a client perspective | 02:15 |
| jamielennox | s/required/wanted | 02:15 |
| ayoung | http://c2.com/cgi/wiki?StringlyTyped | 02:15 |
| ayoung | jamielennox, policy enforcement is also going to depend on this. It needs to be out of Keystone | 02:16 |
| ayoung | client should be the primary consumer | 02:16 |
| ayoung | and horizon | 02:16 |
| jamielennox | i'll look again, but from last review i don't see what it provides that a cleaned up accessinfo doesn't, and we get to clean it up with ksa | 02:17 |
| ayoung | jamielennox, the revocation even needs to move from server to client as well, but got held up due to the swtich to Fernet | 02:17 |
| jamielennox | there is revocation events in ksc, i tried to make them work with auth_token but it's horrible and relies on its own made up token format | 02:17 |
| ayoung | jamielennox, right now, we can't write policy rules that are enforced the same way on both keysrtone server and on the clients | 02:17 |
| ayoung | jamielennox, right. Revocation events needs this, too | 02:18 |
| ayoung | jamielennox, once I make some progress on this, I will clean up the client revocation events using this code in place of that bastardized crud | 02:19 |
| *** richm has quit IRC | 02:19 | |
| jamielennox | ayoung: why can't we just create a standard flat @property based interface with the existing AccessInfo | 02:20 |
| jamielennox | essentially the same as what AccessInfo is now without the dict subclass | 02:20 |
| jamielennox | and a better factor y | 02:20 |
| ayoung | jamielennox, cuz this is the right way to code. Properties and dictionaries are marshalled forms of types. | 02:33 |
| ayoung | This way, we document, cannonically, what we mean the base types to be | 02:33 |
| ayoung | as best as we can in a dynamica language, but it is not that bad | 02:33 |
| ayoung | it should not be flat | 02:34 |
| ayoung | the json structure is, roughly the right representation | 02:34 |
| ayoung | just, JSON is a marshalling format | 02:34 |
| ayoung | jamielennox, bascially, we need to enforce the same logic based on the objects regardless of where things live, or how the objects were created. For example, Keystone policy in the tokenless case needs to be enforced on the same structure as it will be enforced on in the existing token case | 02:37 |
| ayoung | revocation events should not be aware of whether it is running in the keystone server or external | 02:38 |
| jamielennox | i agree with the concept, i just think it's dumping all sorts of server specific code into the client | 02:38 |
| jamielennox | i don't want a way to build tokens in the client | 02:38 |
| ayoung | pretty much anything that needs to consume the access info needs to look the same. The fact that it has been done as a dict in the client for so long is due to the fact it was coming from marhsslled string | 02:38 |
| ayoung | jamielennox, there is nothing server specific here | 02:38 |
| jamielennox | i don't want to expose that a domain is an object with properties | 02:38 |
| jamielennox | the @property domain_id is good for this | 02:39 |
| ayoung | jamielennox, everything is an object with properties | 02:39 |
| ayoung | the general pattern is: parse to cannocial, muinge, marshall to new format | 02:39 |
| jamielennox | i see no point in exposing the layout of the token as the standard abstraction because it may not always fit | 02:39 |
| ayoung | jamielennox, except that some things need Domain name instead | 02:39 |
| ayoung | We already do | 02:40 |
| jamielennox | @property domain_name also exists | 02:40 |
| ayoung | the layougt of the token is the API spec | 02:40 |
| jamielennox | right - but it changed from v2 to v3 | 02:40 |
| jamielennox | and i expect it to change again | 02:40 |
| ayoung | well, we cleaned it up a bunch | 02:40 |
| ayoung | @properties are for string based operations. Granted, a domain is a trivial object, but others are less so | 02:41 |
| ayoung | and we treat them all the same | 02:41 |
| ayoung | if you code in python, you should be working with objects, not strings | 02:41 |
| jamielennox | you're still working with strings - you're just going through an object to get there | 02:41 |
| ayoung | this is...basic object oriented programming | 02:41 |
| ayoung | I'm really having trouble explaining it. It seems so basic and obvious to me. | 02:43 |
| ayoung | hmmm | 02:43 |
| ayoung | jamielennox, the problem with doing things in a flat way is that you cannot then convert things to arrays or lists. And, since both the User and Project domain are both domain objects, if we need to, we can make common code that works with both of them..and it cleans up the service catalog greatly | 02:45 |
| ayoung | it cleans up the roles | 02:45 |
| jamielennox | why do i want to convert an object to an array | 02:46 |
| ayoung | we had this whole crazy thing where role names were sometimes joined with their id and sometimes not..they should always be together. And contractually bound | 02:46 |
| jamielennox | sure - but that's an abstraction issue | 02:46 |
| ayoung | array of roles? array of projects? | 02:46 |
| ayoung | Its code..it is all abstaction | 02:46 |
| *** dims has joined #openstack-keystone | 02:47 | |
| ayoung | jamielennox, I just glanced through this article, but it lays out a lot of the rationale http://blogs.forrester.com/mike_gilpin/11-05-27-canonical_information_modeling_a_best_practice_for_soa | 02:48 |
| ayoung | its not just about AccessInfo, its about how you code in general | 02:48 |
| ayoung | it jhust so happens that I am working with AccessInfo today. I should have done this back when I started on the project, and I think morganfainberg kindof feels the same way. You do know this was his idea, rioght? | 02:48 |
| ayoung | http://www.eaipatterns.com/CanonicalDataModel.html | 02:49 |
| ayoung | jamielennox, the goal is to keep this set of classes non-version specific. Only the endpoints have violated that thus far | 02:49 |
| ayoung | and even there...we could make it work if I was willing to accept the V2 as the baseline, but I like the contract of the v3..so we will keep v2 just for transitions sake | 02:50 |
| *** dims has quit IRC | 02:52 | |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Common Token Model https://review.openstack.org/178034 | 02:53 |
| jamielennox | ayoung: ^ is pretty much my ideal token model | 02:53 |
| jamielennox | then if you want to do things on the server to ensure that no-one is adding extra stuff - do it, but i don't need to care on the client | 02:54 |
| jamielennox | policy, revocations etc all target that interface | 02:54 |
| ayoung | jamielennox, so one antiapattern is abuse of inheritance. FOr a Data tranfer object, it should be the base object itself, and not an abstract base class | 02:54 |
| ayoung | my way is actually simpler | 02:55 |
| ayoung | yours implies that you are trying to leave the data at rest inside the json and just pull out the value that you need. | 02:55 |
| jamielennox | rubbish - this is just pythons way of doing an interface, if it was java, c++ or anything else we would just write it slightly differently | 02:55 |
| ayoung | Mine is certainly a bit more expensive, but there are actually parses that can optimize that away | 02:55 |
| *** markvoelker has joined #openstack-keystone | 02:56 | |
| ayoung | jamielennox, no, not rubbish. I've spent...decades fighting that particular anitpattern | 02:56 |
| ayoung | DTOs are classes, not interfaces | 02:56 |
| jamielennox | actually mine very explicitly does not care if you maintain the json format or not | 02:56 |
| ayoung | if this were C++ or Java, I would be making them immutable | 02:56 |
| ayoung | ] | 02:57 |
| ayoung | not interfaces, not abstract base classes, or even mix-ins | 02:57 |
| ayoung | jamielennox, yours does not define the implementation, allowing for varied implementations, with different assumptions. | 02:58 |
| ayoung | Mine is designed to make all assumptions documented in the code itself | 02:58 |
| ayoung | count yourself lucky that you missed the whole J2EE Entity beans debacle | 02:59 |
| ayoung | but we are in Python, and Python is already a dynaic language, and has wonderful features for treating objects as dictionaries when required | 03:00 |
| *** markvoelker has quit IRC | 03:00 | |
| jamielennox | it very much allows for different implementations - that's my goal - the only reason i want to define this interface at all is to allow certain methods to work on the client side and on the server side | 03:01 |
| jamielennox | I guess it's my opinion here that the server should be adopting the client, and not the other way around | 03:01 |
| ayoung | jamielennox, mine stays the same regardless of format: you have a different builder for every mime type, so it will work for K2k SAML, or qany other format we come up with | 03:02 |
| ayoung | client side or server side is irrelevant | 03:02 |
| ayoung | and, in order to consume the object, you don't end up with library dependencies on the underlying format. Only the builder needs those | 03:03 |
| ayoung | So if you need to conver from one base format to another, it is marshall too cannonical, marshall from cannonical | 03:03 |
| ayoung | and that is the real benefit | 03:03 |
| ayoung | it means we are not tied to the token format, but we do stand by the set of data that we put in it | 03:03 |
| ayoung | so we can support a wider array of content types as necessary, or data stores, LDAP, SQL, NoSQL | 03:04 |
| ayoung | jamielennox, on a different topic | 03:08 |
| ayoung | jamielennox, I have a public demo of both WebSSO and of ECP | 03:09 |
| jamielennox | I guess it doesn't matter, but i can't change AccessInfo - too much relies on it so it just means we're going to need to maintain two formats again | 03:09 |
| ayoung | but the ECP does not work with the client... need jdennis and marekd to close the distance | 03:09 |
| jamielennox | ah - nice, i needed to look into those saml2 plugins again for the new repo | 03:09 |
| *** lhcheng has quit IRC | 03:10 | |
| ayoung | jamielennox, so...kerberos needs to be something different, I think | 03:10 |
| ayoung | for example | 03:10 |
| ayoung | say I am doing Ipsilon, and I want to do Kerberos to Ipsilon, not to Horizon | 03:10 |
| ayoung | then I need to add the negotiate header on the call to Ipsilon, | 03:10 |
| ayoung | it needs to be a decorator for other plugins, I think | 03:11 |
| ayoung | like...add Kerberos to the SAML2AuthPlugin or the OAuthPLugin or whatever else we end up with | 03:11 |
| jamielennox | decorator? i don't follow - if we do kerberos via federation i thought it was the same workflo | 03:11 |
| ayoung | jamielennox, if we do ECP, then the call from the KC to the IdP needs to be Kerberos | 03:12 |
| ayoung | --negotiate rather | 03:12 |
| jamielennox | oh - hmm, yea - i remember looking at that at the beginning that basicauth was not the only way to do ECP | 03:12 |
| ayoung | not webSSO | 03:12 |
| ayoung | that works OK | 03:12 |
| jamielennox | you're supposed to support x509 and kerb as well | 03:12 |
| jamielennox | so we're down to sub-sub plugins | 03:13 |
| jamielennox | the saml plugin needs to accept a way to support the inner auth exchange | 03:13 |
| ayoung | right. THe setup I have right now bascially coppies jdennis use of a digest in a flat file. I can do ECP to Ipsilon with Kerberos, but the client would not support it (I think) | 03:13 |
| jamielennox | it shouldn't be all that hard actually | 03:14 |
| jamielennox | though it's getting confusing with all the config options | 03:14 |
| ayoung | jamielennox, If we did multiple plugins, we could have one that just does Neotiate without setting a value in the token body. I think that is what we would need | 03:14 |
| ayoung | NegotiateDecorator | 03:14 |
| jamielennox | ayoung: so there's two ways to do it | 03:14 |
| jamielennox | 1st make saml a base class and subclass for each new method | 03:15 |
| jamielennox | and name them each something different like --os-auth-plugin kerbsaml2 | 03:15 |
| jamielennox | or we make a new plugin structure that handles the inner auth so --os-auth-plugin saml2 --os-method kerb | 03:15 |
| jamielennox | either is doable | 03:16 |
| jamielennox | i have no real preference | 03:16 |
| ayoung | jamielennox, I think I like --os-method kerb | 03:17 |
| ayoung | that way make it something you can specify multiple times? | 03:17 |
| ayoung | it would let you do client cert, kerberos, saml.... | 03:18 |
| jamielennox | yea, could do | 03:20 |
| jamielennox | the arg handling could get confusing there but it's doable | 03:21 |
| ayoung | jamielennox, I think we could get away with implementing that only in python-keystonekerberos to start. I would not be surprised if that ended up being the only place that needed it. | 03:24 |
| ayoung | but it keeps the kerberso stuff out of the saml, and the reverse | 03:24 |
| jamielennox | hmm, yea the dependencies are a bit funny there | 03:25 |
| jamielennox | because you need to define the saml extensions in the ksc-saml2 repo and then rely on them from ksc-kerberos | 03:25 |
| jamielennox | i guess there's no reason to define an ABC in saml2, just specify it needs to be an object with a method named X | 03:26 |
| *** samueldmq has quit IRC | 03:38 | |
| *** browne has joined #openstack-keystone | 03:42 | |
| ayoung | jamielennox, back to waht you said " i can't change AccessInfo - too much relies on it so it just means we're going to need to maintain two formats again" so you dobn't think this patch will work: https://review.openstack.org/#/c/160134/9 | 03:42 |
| jamielennox | ayoung: i haven't gone through that patch | 03:44 |
| ayoung | jamielennox, that one is the one that uses the model for the existing Access Info use cases, and was instrumental in me getting this righ | 03:45 |
| ayoung | t | 03:45 |
| ayoung | if I hadn't tried to match what the client was already doing, I'd be off in the weeds | 03:45 |
| ayoung | I just tried to keep each patch reviewable | 03:45 |
| ayoung | jamielennox, the predecessor is the one that changes the tests, and is the one that needs to pass the most scruitiny. I think I mostly cleaned up assumptions in the tests | 03:46 |
| ayoung | things like putting ids into the endpoints in the sample data and so on | 03:47 |
| *** lhcheng has joined #openstack-keystone | 03:48 | |
| *** ChanServ sets mode: +v lhcheng | 03:48 | |
| ayoung | the only change to the tests was to remove explicit checks like self.assertIsInstance(access_info, access.AccessInfoV2) as the access info is identical now between each version | 03:48 |
| *** markvoelker has joined #openstack-keystone | 03:56 | |
| *** markvoelker has quit IRC | 04:01 | |
| morganfainberg | ayoung, does accessinfo live in client o keystoneauth lib long term? | 04:01 |
| morganfainberg | ayoung: not immediately fwiw, can port your code to keystoneauth if it ends up there | 04:02 |
| ayoung | morganfainberg, it doesn't feel like the same thing as keystoneauth, but what is the fault line? | 04:02 |
| morganfainberg | ayoung: well it can't be client long term i don't think, because it breaks the model of not needing ksc | 04:03 |
| morganfainberg | to interact with the plugins etc | 04:03 |
| morganfainberg | and auth | 04:03 |
| morganfainberg | so maybe we do need to move to keystonecommon for things like accessinfo and cms? | 04:03 |
| ayoung | morganfainberg, its the cannonical representation of what the token data represents, but it doesn't need auth mechanisms... | 04:03 |
| morganfainberg | ayoung: but the auth mechanisms should utilize it | 04:04 |
| ayoung | cms should probably be rethought | 04:04 |
| morganfainberg | meaning we shouldn't need ksc for the keystonauth lib | 04:04 |
| ayoung | I would like it as a standalone mechanism, to support messages as well as tokens | 04:04 |
| ayoung | so what would be in common besides that> | 04:04 |
| morganfainberg | i think today keystoneauth is the closest we have. | 04:04 |
| ayoung | It might be just this | 04:04 |
| morganfainberg | common - no idea if we even need it | 04:04 |
| ayoung | morganfainberg, so, what is going into keystoneauth? | 04:04 |
| morganfainberg | ayoung: session, discovery, catalog | 04:04 |
| morganfainberg | ayoung: auth plugins | 04:05 |
| ayoung | catalog? then yes | 04:05 |
| morganfainberg | ayoung: yeah catalog parser. | 04:05 |
| morganfainberg | it's meant to be everything you need to spin up a session, auth, and hand off to a $client$ or other tool | 04:05 |
| ayoung | morganfainberg, let me phrase it this way. Is it OK if Keystone server links in keystoneauth? | 04:05 |
| morganfainberg | yes | 04:05 |
| ayoung | I assume it would need to for K2K, right? | 04:05 |
| morganfainberg | in fact, i would expect it to. | 04:05 |
| morganfainberg | yes | 04:05 |
| ayoung | OK, then that is where it should go | 04:06 |
| morganfainberg | i expect middleware to be using keystoneauth as well instead of KSC | 04:06 |
| ayoung | and horizon? | 04:06 |
| morganfainberg | same thing. | 04:06 |
| morganfainberg | DOA can use KSA instead of needing ksc | 04:06 |
| ayoung | OK, then accessinfo goes to keystoneauth | 04:06 |
| morganfainberg | ksc doesn't provide it with anything it needs except extra identity and asscess managment crud interfaces | 04:06 |
| morganfainberg | which shouldn't be needed to handle auth stuff | 04:07 |
| ayoung | Oh YAY! http://www.freeipa.org/page/V4/User_Certificates | 04:07 |
| morganfainberg | it seemed like a clear delineation | 04:07 |
| morganfainberg | :) | 04:07 |
| ayoung | gnigh | 04:11 |
| *** ayoung has quit IRC | 04:11 | |
| jamielennox | ah - missed all that | 04:13 |
| jamielennox | morganfainberg: i think with the split to ksa we'll need to do more looking at accessinfo than i had initially thought | 04:16 |
| morganfainberg | jamielennox: likely | 04:17 |
| jamielennox | but i really don't know if i want a full multiple object cannonical model, all i want is a way to pull information out of the token | 04:17 |
| jamielennox | and i don't want to start rejecting tokens on the client side because the model isn't quite perfect | 04:17 |
| morganfainberg | jamielennox: we should discuss that because we have an issue where tokens are poorly defined | 04:18 |
| jamielennox | i don't see us doing a ksa release before summit | 04:18 |
| jamielennox | i was hoping the gerrit would be done by now, but either way we can look at it then | 04:18 |
| morganfainberg | jamielennox: i actually expect us to do a 0.x release early | 04:18 |
| morganfainberg | for testing | 04:18 |
| morganfainberg | a 1.x post summit | 04:18 |
| jamielennox | ok, well either way we can't change the property interface that AccessInfo currently has so we can stick with that initially and figure out adams thing later | 04:19 |
| morganfainberg | in 1.x we can make that change | 04:19 |
| morganfainberg | but the key is we should be discussing that at the summit at the very least | 04:20 |
| *** jaosorior has joined #openstack-keystone | 04:34 | |
| *** kiran-r has joined #openstack-keystone | 04:42 | |
| *** lhcheng has quit IRC | 04:47 | |
| *** markvoelker has joined #openstack-keystone | 04:47 | |
| *** lhcheng has joined #openstack-keystone | 05:28 | |
| *** ChanServ sets mode: +v lhcheng | 05:28 | |
| *** ajayaa has joined #openstack-keystone | 05:29 | |
| *** rushiagr_away is now known as rushiagr | 05:29 | |
| *** rm_work|away is now known as rm_work | 05:32 | |
| *** mflobo has quit IRC | 05:42 | |
| *** harlowja_ is now known as harlowja_away | 05:53 | |
| *** josecastroleon has joined #openstack-keystone | 06:01 | |
| *** david8hu has quit IRC | 06:03 | |
| *** david8hu has joined #openstack-keystone | 06:03 | |
| *** stevemar has quit IRC | 06:04 | |
| *** krotscheck has quit IRC | 06:05 | |
| *** krotscheck has joined #openstack-keystone | 06:05 | |
| *** henrynash has joined #openstack-keystone | 06:06 | |
| *** ChanServ sets mode: +v henrynash | 06:06 | |
| *** mabrams has joined #openstack-keystone | 06:06 | |
| *** josecastroleon has quit IRC | 06:09 | |
| *** josecastroleon has joined #openstack-keystone | 06:09 | |
| *** lhcheng has quit IRC | 06:12 | |
| *** mflobo has joined #openstack-keystone | 06:15 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core https://review.openstack.org/171916 | 06:17 |
| openstackgerrit | Jamie Lennox proposed openstack/keystone: Move endpoint policy into keystone core https://review.openstack.org/171448 | 06:17 |
| *** mabrams has quit IRC | 06:35 | |
| *** mabrams has joined #openstack-keystone | 06:36 | |
| *** spandhe has joined #openstack-keystone | 06:39 | |
| *** e0ne has joined #openstack-keystone | 06:39 | |
| *** browne has quit IRC | 06:49 | |
| *** browne has joined #openstack-keystone | 06:50 | |
| *** ajayaa has quit IRC | 06:50 | |
| *** spandhe has quit IRC | 07:10 | |
| *** ajayaa has joined #openstack-keystone | 07:11 | |
| *** ajayaa has quit IRC | 07:21 | |
| *** pcaruana has joined #openstack-keystone | 07:33 | |
| *** ajayaa has joined #openstack-keystone | 07:33 | |
| *** afazekas_ has joined #openstack-keystone | 07:39 | |
| *** e0ne has quit IRC | 07:41 | |
| *** erkules_ has quit IRC | 07:43 | |
| marekd | jamielennox: hi, still here? | 07:44 |
| marekd | jamielennox: how about symlinking files? | 07:44 |
| marekd | https://review.openstack.org/#/c/177704/ | 07:44 |
| *** markvoelker has quit IRC | 07:44 | |
| *** rushiagr is now known as rushiagr_away | 07:46 | |
| *** rushiagr_away is now known as rushiagr | 07:49 | |
| *** abhijeetm has joined #openstack-keystone | 07:50 | |
| *** abhijeetm has quit IRC | 07:52 | |
| *** jistr has joined #openstack-keystone | 07:55 | |
| openstackgerrit | Marek Denis proposed openstack/python-keystoneclient: Rename v3/federated.py to v3/federation.py https://review.openstack.org/177704 | 07:57 |
| *** ajayaa has quit IRC | 08:00 | |
| *** ajayaa has joined #openstack-keystone | 08:13 | |
| *** markvoelker has joined #openstack-keystone | 08:15 | |
| *** markvoelker has quit IRC | 08:20 | |
| *** openstackgerrit has quit IRC | 08:20 | |
| *** openstackgerrit has joined #openstack-keystone | 08:21 | |
| *** ncoghlan has quit IRC | 08:26 | |
| openstackgerrit | Victor Stinner proposed openstack/keystonemiddleware: Port keystonemiddleware to Python 3 https://review.openstack.org/177701 | 08:30 |
| *** ajayaa has quit IRC | 08:51 | |
| *** ajayaa has joined #openstack-keystone | 09:02 | |
| *** fhubik has joined #openstack-keystone | 09:04 | |
| *** e0ne has joined #openstack-keystone | 09:05 | |
| *** aix has joined #openstack-keystone | 09:07 | |
| *** markvoelker has joined #openstack-keystone | 09:16 | |
| *** browne has quit IRC | 09:19 | |
| *** markvoelker has quit IRC | 09:21 | |
| *** fhubik is now known as fhubik_afk | 09:22 | |
| *** fhubik_afk is now known as fhubik | 09:22 | |
| *** rushiagr is now known as rushiagr_away | 09:52 | |
| *** fhubik is now known as fhubik_afk | 09:57 | |
| *** fifieldt has quit IRC | 09:58 | |
| *** xianghui has quit IRC | 10:04 | |
| *** xianghui has joined #openstack-keystone | 10:04 | |
| *** xianghui has quit IRC | 10:07 | |
| *** dims has joined #openstack-keystone | 10:12 | |
| *** markvoelker has joined #openstack-keystone | 10:17 | |
| *** fhubik_afk is now known as fhubik | 10:20 | |
| *** markvoelker has quit IRC | 10:21 | |
| *** zigo has quit IRC | 10:29 | |
| *** samueldmq has joined #openstack-keystone | 10:33 | |
| samueldmq | morning | 10:33 |
| *** e0ne is now known as e0ne_ | 10:33 | |
| *** zigo_ has joined #openstack-keystone | 10:33 | |
| *** e0ne_ has quit IRC | 10:35 | |
| *** e0ne has joined #openstack-keystone | 10:39 | |
| *** aix has quit IRC | 10:47 | |
| *** henrynash has quit IRC | 10:50 | |
| *** fhubik is now known as fhubik_afk | 10:52 | |
| *** jamielennox is now known as jamielennox|away | 10:57 | |
| *** e0ne is now known as e0ne_ | 10:58 | |
| *** aix has joined #openstack-keystone | 10:58 | |
| marekd | Morning. | 11:04 |
| *** mabrams has left #openstack-keystone | 11:04 | |
| *** e0ne_ has quit IRC | 11:09 | |
| morganfainberg | Mornin. | 11:12 |
| breton | morning | 11:15 |
| *** markvoelker has joined #openstack-keystone | 11:18 | |
| *** markvoelker has quit IRC | 11:23 | |
| marekd | morganfainberg: whoa, morganfainberg so unusual to have you here soooo early! | 11:23 |
| morganfainberg | marekd: on the east coast until tomorrow. | 11:23 |
| *** e0ne has joined #openstack-keystone | 11:26 | |
| *** jistr is now known as jistr|class | 11:34 | |
| *** aix has quit IRC | 11:34 | |
| *** dims has quit IRC | 11:44 | |
| samueldmq | morning :) | 11:45 |
| *** rushiagr_away is now known as rushiagr | 11:46 | |
| *** rushiagr is now known as rushiagr_away | 11:48 | |
| *** aix has joined #openstack-keystone | 11:50 | |
| *** dims has joined #openstack-keystone | 11:51 | |
| *** fhubik_afk is now known as fhubik | 12:03 | |
| *** erkules_ has joined #openstack-keystone | 12:03 | |
| *** bdossant has joined #openstack-keystone | 12:04 | |
| *** rushiagr_away is now known as rushiagr | 12:06 | |
| *** markvoelker has joined #openstack-keystone | 12:13 | |
| *** iurygregory has joined #openstack-keystone | 12:14 | |
| *** ajayaa has quit IRC | 12:19 | |
| *** Ephur has joined #openstack-keystone | 12:20 | |
| *** kiran-r has quit IRC | 12:29 | |
| *** gordc has joined #openstack-keystone | 12:35 | |
| *** mordred has quit IRC | 12:35 | |
| *** mordred has joined #openstack-keystone | 12:35 | |
| *** rushiagr is now known as rushiagr_away | 12:36 | |
| -openstackstatus- NOTICE: Gate is experiencing epic failures due to issues with mirrors, work is underway to mitigate and return to normal levels of sanity | 12:41 | |
| *** ChanServ changes topic to "Gate is experiencing epic failures due to issues with mirrors, work is underway to mitigate and return to normal levels of sanity" | 12:41 | |
| openstackgerrit | David Charles Kennedy proposed openstack/keystonemiddleware: enforce endpoint constraint https://review.openstack.org/177661 | 12:47 |
| samueldmq | dstanek, hi - let me know when you're around | 12:51 |
| samueldmq | dstanek, would like to discuss about the devstack + keystone 500 error | 12:51 |
| dstanek | samueldmq: i'm here | 12:51 |
| samueldmq | dstanek, hi, do you have any news ? | 12:51 |
| samueldmq | dstanek, I am always getting the 500 and I can see the assignment controllers import error on keystone log | 12:52 |
| samueldmq | dstanek, at /var/log/apache2/keystone.log | 12:52 |
| samueldmq | dstanek, also, I can't import in from python | 12:52 |
| dstanek | samueldmq: no, i'm not having that problem on fedora | 12:54 |
| samueldmq | dstanek, hmm, so maybe that's a specific ubuntu 14.04 issue ... :/ | 12:54 |
| samueldmq | dstanek, and I suppose infra doesn't use this image (as gate jobs still work) | 12:55 |
| dstanek | fedora is busted for me though :-( | 12:55 |
| dstanek | i get this http://paste.openstack.org/show/210138/ | 12:55 |
| samueldmq | dstanek it's the same, isnt ? | 12:56 |
| dstanek | what's the same? | 12:57 |
| samueldmq | 'Unable to establish connection' actually could be a bunch of possible errors (500, 404) ... | 12:57 |
| samueldmq | Unable to establish connection to http://10.0.2.15:35357/v2.0/tokens | 12:57 |
| dstanek | samueldmq: no, that should mean that nothing is listening on that port | 12:58 |
| dstanek | before i was actually seeing keystone up and running, but returning 500s in a few requests | 12:58 |
| samueldmq | dstanek, this is so scary | 12:59 |
| *** bknudson has joined #openstack-keystone | 12:59 | |
| *** ChanServ sets mode: +v bknudson | 12:59 | |
| samueldmq | dstanek, for the error I am getting, I googled and found that Import error, could not import name 'controllers' could be caused by cyclical dependencies | 13:00 |
| *** jimbaker has quit IRC | 13:00 | |
| samueldmq | dstanek, which is unlikely since it working on other places | 13:01 |
| *** jistr|class is now known as jistr | 13:01 | |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone: Prohibit invalid ids in subtree and parents list https://review.openstack.org/158720 | 13:04 |
| *** jimbaker has joined #openstack-keystone | 13:04 | |
| *** jimbaker has quit IRC | 13:04 | |
| *** jimbaker has joined #openstack-keystone | 13:04 | |
| *** ajayaa has joined #openstack-keystone | 13:07 | |
| *** raginbajin has quit IRC | 13:08 | |
| *** raginbajin has joined #openstack-keystone | 13:09 | |
| *** edmondsw has joined #openstack-keystone | 13:09 | |
| *** nkinder has quit IRC | 13:11 | |
| dstanek | samueldmq: that could be cyclic dependencies or possibly other things | 13:21 |
| dstanek | i don't think we are doing anything exotic with import anywhere | 13:21 |
| dstanek | samueldmq: actually my issue may be a memory issue | 13:24 |
| samueldmq | dstanek, why ? because it works randomly ? | 13:25 |
| dstanek | no, because i'm seeing memory issue in the logs - i moved to fedora20 yesterday because i didn't have enough time to debug the ubuntu issue | 13:26 |
| *** krykowski has joined #openstack-keystone | 13:26 | |
| dstanek | i'm giving a talk on Friday and found out over the weekend that they don't have wifi so i've been trying to get screenshots to mimic what i was going to do live | 13:26 |
| dstanek | :-( | 13:26 |
| samueldmq | dstanek, and you need devstack right / | 13:28 |
| *** e0ne is now known as e0ne_ | 13:28 | |
| samueldmq | dstanek, maybe I can get you a working vm if this helps :) | 13:28 |
| dstanek | :-) i just started creating a devstack instance in Rackspace's public cloud - i really wanted it locally, but i don't seem to have enough horsepower | 13:29 |
| dstanek | i need to upgrade my hardware | 13:31 |
| *** richm has joined #openstack-keystone | 13:33 | |
| *** e0ne_ is now known as e0ne | 13:37 | |
| *** Zanatoz has joined #openstack-keystone | 13:37 | |
| Zanatoz | I enabled keystone v3 and made my admin account an admin for the default domain but it doesn't allow me to create or edit users in horizon. Anyone run into the same behavior? | 13:39 |
| *** amakarov_away is now known as amakarov | 13:40 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:40 | |
| *** stevemar has joined #openstack-keystone | 13:44 | |
| *** ChanServ sets mode: +v stevemar | 13:44 | |
| openstackgerrit | Victor Stinner proposed openstack/python-keystoneclient: Remove discover and iso8601 dependencies https://review.openstack.org/177687 | 13:59 |
| marekd | dstanek still on macbook air? | 14:00 |
| dstanek | marekd: yep | 14:03 |
| *** nkinder has joined #openstack-keystone | 14:05 | |
| *** rushil has joined #openstack-keystone | 14:05 | |
| *** dims has quit IRC | 14:15 | |
| *** dims has joined #openstack-keystone | 14:15 | |
| *** fmarco76 has joined #openstack-keystone | 14:16 | |
| *** fmarco76 has quit IRC | 14:16 | |
| *** ajayaa has quit IRC | 14:17 | |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: Dual Scoped Token https://review.openstack.org/176054 | 14:17 |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 14:17 |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: Recursive deletion https://review.openstack.org/148730 | 14:18 |
| *** zzzeek has joined #openstack-keystone | 14:19 | |
| *** fhubik has quit IRC | 14:23 | |
| dstanek | marekd: i was thinking of getting an x1, but i really want 16gb ram | 14:23 |
| *** ayoung has joined #openstack-keystone | 14:25 | |
| *** ChanServ sets mode: +v ayoung | 14:25 | |
| *** mattfarina has joined #openstack-keystone | 14:28 | |
| *** mflobo has left #openstack-keystone | 14:29 | |
| *** josecastroleon has quit IRC | 14:31 | |
| *** josecastroleon has joined #openstack-keystone | 14:31 | |
| *** notmyname has quit IRC | 14:31 | |
| *** rushil has quit IRC | 14:33 | |
| *** afazekas_ has quit IRC | 14:33 | |
| *** notmyname has joined #openstack-keystone | 14:34 | |
| *** browne has joined #openstack-keystone | 14:34 | |
| *** mflobo has joined #openstack-keystone | 14:38 | |
| *** pnavarro has joined #openstack-keystone | 14:39 | |
| morganfainberg | dstanek: the 8gb of ram is an issue with the x1 and xps13 developer | 14:40 |
| morganfainberg | dstanek: you could go with a 13" mbpr | 14:40 |
| morganfainberg | And install Linux on it. :P | 14:41 |
| *** joesavak has joined #openstack-keystone | 14:41 | |
| bknudson | drop X windows so you have more memory | 14:41 |
| *** ajayaa has joined #openstack-keystone | 14:44 | |
| *** mattfarina has quit IRC | 14:44 | |
| dstanek | morganfainberg: i don't think i want to go the apple route again - although the hardware lasts longer than anything i've ever had | 14:45 |
| dstanek | bknudson: :-P | 14:45 |
| marekd | dstanek: why no apple? | 14:46 |
| marekd | dstanek: TBH i am thinking about starting my journey with apple.... | 14:46 |
| dstanek | i'm not a fan of OSX | 14:46 |
| morganfainberg | dstanek: I don't get why ultrabooks all have 8gb of ram max. It is lame. | 14:47 |
| morganfainberg | X1, xps13, etc. all only 8gb of ram. | 14:47 |
| morganfainberg | I want 1Tb of ram. | 14:47 |
| morganfainberg | :P | 14:47 |
| stevemar | marekd, i'm going to be forced to start a journey with apple soon | 14:47 |
| dstanek | stevemar: run! | 14:47 |
| marekd | stevemar: how come? | 14:47 |
| stevemar | we're getting some at work, i think, that's the rumor | 14:48 |
| bknudson | stevemar drank the kool-aid. | 14:48 |
| marekd | stevemar: IBM bought Apple? :P | 14:48 |
| stevemar | marekd, lol | 14:48 |
| morganfainberg | bknudson: koooooooooooool aid..... | 14:48 |
| *** henrynash has joined #openstack-keystone | 14:48 | |
| *** ChanServ sets mode: +v henrynash | 14:48 | |
| dstanek | OSX was usable (not awesome, but usable) until Yosemite broke everything - and i really miss linux | 14:49 |
| morganfainberg | marekd: I heard apple bought IBM </unsubstantiated rumor> | 14:49 |
| morganfainberg | dstanek: Yosemite is a trainwreck of an OS | 14:49 |
| dstanek | no hacky package management using brew, no unavoidable issues will Apple controlled libs (ldap, ssl, etc) | 14:49 |
| bknudson | I thought we just ran a VM for development anyways. | 14:50 |
| marekd | morganfainberg: i am not at the either of those sides (apple, ibm), so I will not despair...or maybe after they destroy T or X Lenovo lines. | 14:50 |
| stevemar | marekd, use a W :P | 14:51 |
| marekd | B(rick, you said? :P | 14:51 |
| marekd | B(rick) | 14:51 |
| stevemar | yup | 14:51 |
| marekd | my eyes are getting worse and worse, but I am also becomming a fan of smaller laptops. | 14:52 |
| dstanek | i wish lenovo would let me filter laptops by ram and size | 14:52 |
| *** henrynash has quit IRC | 14:52 | |
| marekd | so i have T430 14 inch and 12.5 x230 and I really find that 14 inch laptop HEAVY | 14:52 |
| dstanek | stevemar: is ibm moving to apple? | 14:52 |
| bknudson | Mem: 32509048k total, 32239544k used, 269504k free, 626828k buffers | 14:52 |
| stevemar | dstanek, doubt it - but apparently some teams can ask for them | 14:54 |
| dstanek | marekd: aren't those only 4lbs? | 14:54 |
| marekd | dstanek: which ones? | 14:54 |
| bknudson | you could always bring your own mac. | 14:54 |
| marekd | dstanek: 12.5 or 14 | 14:55 |
| *** ajayaa has quit IRC | 14:57 | |
| marekd | heh, so at cern i could either take mac or lenovo/dell, wanted a small screen to make it as portable as possible and honestly i got scared that small screen without tiling WMs I am used to would be not enough. | 15:00 |
| dstanek | i thought the 14. i've been looking through lots of laptops recently | 15:01 |
| *** henrynash has joined #openstack-keystone | 15:01 | |
| *** ChanServ sets mode: +v henrynash | 15:01 | |
| marekd | dstanek: i have 9 cell battery | 15:02 |
| dstanek | marekd: haha | 15:02 |
| dstanek | there's your problem right there | 15:02 |
| marekd | dstanek: battery? | 15:02 |
| dstanek | yeah. 3lb laptop w/ 8lb battery :-) | 15:03 |
| marekd | i don't have any problem since I have my x230 | 15:03 |
| marekd | (and extra 4gb of RAM) | 15:04 |
| *** e0ne is now known as e0ne_ | 15:04 | |
| *** e0ne_ is now known as e0ne | 15:05 | |
| *** rushiagr_away is now known as rushiagr | 15:09 | |
| *** samueldmq_ has joined #openstack-keystone | 15:14 | |
| ayoung | marekd, OK, I have a public demo of the ECP/SAML/Keystone setup | 15:16 |
| marekd | What's the difference between public, admin and internal urls in the endpoint? | 15:16 |
| marekd | ayoung: public idp you mean? | 15:16 |
| *** joesavak has quit IRC | 15:16 | |
| *** ChanServ sets mode: +v marekd | 15:17 | |
| ayoung | marekd, yep | 15:17 |
| ayoung | marekd, ipa.younglogic.net and rdo.younglogic.net for Horizon | 15:18 |
| *** ajayaa has joined #openstack-keystone | 15:18 | |
| rodrigods | ayoung, nice! | 15:18 |
| marekd | ayoung: i can try to setup my VM with that | 15:18 |
| rodrigods | ayoung, create an account for me! :) | 15:19 |
| marekd | ayoung: http://rdo.younglogic.net:5000/v3/OS-FEDERATION/identity_providers/ipsilon/protocols/saml2/auth/mellon/metadata why mellon/metadata at the end? | 15:20 |
| marekd | and yes, can i have an account there? | 15:20 |
| marekd | ayoung: FYI, emailed jdennis yesterday and awaiting his response now. | 15:20 |
| *** joesavak has joined #openstack-keystone | 15:21 | |
| stevemar | ayoung, i'm in! | 15:23 |
| ayoung | stevemar, have you worked with ECP at all? | 15:23 |
| stevemar | yeah, waaaay back when when we first started with our federation adventure | 15:23 |
| marekd | stevemar: i think stevemar was the one who confirmed it worked with IBM IdP. | 15:24 |
| stevemar | yep | 15:24 |
| stevemar | that was a pain =\ | 15:24 |
| stevemar | ayoung, i have an admin role on this cloud :D | 15:25 |
| stevemar | something is a bit buggy with horizon i think | 15:25 |
| stevemar | getting a lot of error popups on the top right | 15:26 |
| ayoung | stevemar, yeah,something is not quite right in the RDO set up. | 15:26 |
| stevemar | does rdo have the latest DOA? | 15:26 |
| marekd | ayoung: account pls? | 15:26 |
| stevemar | i think lhcheng cleaned up those error | 15:26 |
| stevemar | marekd, we can share one? | 15:26 |
| ayoung | I have a dev here in house I'm going to be talking to...I'll check back on IRC in a bit... | 15:26 |
| marekd | stevemar: yes, please | 15:26 |
| *** davidckennedy has joined #openstack-keystone | 15:26 | |
| Zanatoz | when I log into horizon with v3 keystone enabled I get RBAC: Invalid token and I can't modify users. anyone see this kind of behavior before? | 15:27 |
| *** henrynash has quit IRC | 15:28 | |
| *** jsavak has joined #openstack-keystone | 15:31 | |
| *** joesavak has quit IRC | 15:34 | |
| -openstackstatus- NOTICE: gerrit has been restarted to clear an issue with its event stream. any change events between 14:43-15:30 utc should be rechecked or have their approval votes reapplied to trigger jobs | 15:36 | |
| *** bdossant has quit IRC | 15:38 | |
| *** _cjones_ has joined #openstack-keystone | 15:40 | |
| *** _cjones_ has quit IRC | 15:42 | |
| *** joesavak has joined #openstack-keystone | 15:43 | |
| *** jsavak has quit IRC | 15:43 | |
| *** lhcheng has joined #openstack-keystone | 15:44 | |
| *** ChanServ sets mode: +v lhcheng | 15:44 | |
| *** _cjones_ has joined #openstack-keystone | 15:45 | |
| *** lhcheng has quit IRC | 15:45 | |
| *** lhcheng has joined #openstack-keystone | 15:45 | |
| *** ChanServ sets mode: +v lhcheng | 15:45 | |
| marekd | bknudson: re: https://review.openstack.org/#/c/177704/ so when we deprecate whole class...where should it print any depr. warnings? When using *any* of the method from the deprecated class ? | 15:45 |
| bknudson | marekd: it can happen at import time if the whole module is deprecated. | 15:49 |
| *** rushiagr is now known as rushiagr_away | 15:50 | |
| morganfainberg | Rc2 *is* Kilo release. Release will happen on Thursday before normal us time(s) | 15:52 |
| *** ChanServ changes topic to "Liberty Development Open | Review Liberty Specs | Provide feedback on Liberty Priorities: https://etherpad.openstack.org/p/keystone-liberty-priority-specs" | 15:52 | |
| *** tqtran has joined #openstack-keystone | 16:01 | |
| *** jistr has quit IRC | 16:02 | |
| *** joesavak has quit IRC | 16:03 | |
| *** samueldmq_ has quit IRC | 16:04 | |
| *** joesavak has joined #openstack-keystone | 16:11 | |
| *** pcaruana has quit IRC | 16:14 | |
| *** Bjoern__ has joined #openstack-keystone | 16:15 | |
| *** kiran-r has joined #openstack-keystone | 16:15 | |
| *** Bjoern__ is now known as bjoernT | 16:16 | |
| *** bjoernT is now known as BjoernT | 16:16 | |
| ayoung | morganfainberg, good to know | 16:17 |
| ayoung | marekd, I'll give you an account | 16:17 |
| marekd | bknudson: ok, maybe there is some code so I could see how it was implemented in somewhere else ? | 16:18 |
| bknudson | marekd: you should be able to use the standard warnings module. | 16:19 |
| *** alexsyip has joined #openstack-keystone | 16:21 | |
| *** krykowski has quit IRC | 16:25 | |
| openstackgerrit | David Charles Kennedy proposed openstack/keystone: Service with no endpoints should not be in catalog https://review.openstack.org/176383 | 16:27 |
| *** davidckennedy has quit IRC | 16:27 | |
| ayoung | stevemar, the mapping I set up is pretty simplistic. I did something more complex when using SSSD, but making the mapping sometihg the end user can modify is going to be very important, I think, once Federation takes off | 16:35 |
| marekd | bknudson: I see some examples here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/apiclient/__init__.py#L25-L27 but on the other hand there is also this https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/shell.py#L59-L67 Looks like the latter is the correct way of doing that right? | 16:38 |
| bknudson | marekd: the former is fine. | 16:41 |
| bknudson | the change in shell.py was just so that the warning would always be printed. | 16:41 |
| bknudson | but in the case of a library it should be the application that's configuring the warnings library | 16:42 |
| marekd | bknudson: which will probably never happen.... | 16:42 |
| bknudson | y, but it's their choice | 16:42 |
| marekd | understood. | 16:43 |
| *** browne has quit IRC | 16:50 | |
| *** gyee has joined #openstack-keystone | 16:51 | |
| *** ChanServ sets mode: +v gyee | 16:51 | |
| *** e0ne has quit IRC | 16:52 | |
| *** josecastroleon has quit IRC | 17:00 | |
| *** henrynash has joined #openstack-keystone | 17:03 | |
| *** ChanServ sets mode: +v henrynash | 17:03 | |
| *** rushil has joined #openstack-keystone | 17:03 | |
| *** joesavak has quit IRC | 17:05 | |
| *** joesavak has joined #openstack-keystone | 17:05 | |
| *** joesavak has quit IRC | 17:06 | |
| *** _cjones_ has quit IRC | 17:06 | |
| morganfainberg | jamielennox|away: ping http://logs.openstack.org/86/177186/3/check/check-tempest-dsvm-full/38a8915//logs/screen-n-api.txt.gz?level=WARNING#_2015-04-28_16_07_18_793 | 17:07 |
| morganfainberg | jamielennox|away: we are seeing tons and tons and tons and tons of these across a lot of services | 17:07 |
| morganfainberg | jamielennox|away: this doesn't look super useful as a warning | 17:07 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware: Remove superfluous / spammy log line https://review.openstack.org/178292 | 17:08 |
| bknudson | libraries really shouldn't log anything above debug. | 17:08 |
| bknudson | if they need to tell the application about an issue then provide a callback or something. | 17:08 |
| ayoung | morganfainberg, do you know what was meant on the Sumit brainstorm ehter pad line 68 https://etherpad.openstack.org/p/Keystone-liberty-summit-brainstorm | 17:09 |
| ayoung | Deprecation of non-HA stuff | 17:09 |
| morganfainberg | bknudson: correct. | 17:09 |
| ayoung | what non HA stuff specifically? | 17:09 |
| morganfainberg | uhm | 17:09 |
| morganfainberg | no idea | 17:09 |
| morganfainberg | bknudson: warning - something an operator really should care about | 17:10 |
| morganfainberg | bknudson: esp in keystonemiddleware | 17:10 |
| *** ir2ivps8_ has quit IRC | 17:11 | |
| ayoung | morganfainberg, cuz we have someone talking on HA Keystone at the summit. My team's Program Manager. | 17:11 |
| ayoung | and would really like to be in sync with that | 17:11 |
| ayoung | https://openstacksummitmay2015vancouver.sched.org/event/0ff177c7525d10423ddf638ffa69c1fd#.VT-_i7seEa0 | 17:12 |
| morganfainberg | https://review.openstack.org/#/q/Iab569a14a9f3268abef6bc36e46cf15dc16564b9,n,z could use some review love btw | 17:12 |
| morganfainberg | should be *really* easy | 17:12 |
| ayoung | morganfainberg, so if there is anything we want to get the message out about HA..that is a good channel | 17:13 |
| ayoung | morganfainberg, I'll trade you that for an AccessInfo review | 17:14 |
| morganfainberg | ayoung: thats not a fair trade btw | 17:15 |
| ayoung | morganfainberg, life is not fair | 17:15 |
| samueldmq | morganfainberg, I've added 'FKs constraints between model entities defined at common/models.py and enforced on managers using an annotation' | 17:15 |
| morganfainberg | ayoung: those ^^ should go out as .Z releases | 17:15 |
| openstackgerrit | David Stanek proposed openstack/keystone: Why worry about py33. py34 ftw. https://review.openstack.org/178296 | 17:15 |
| openstackgerrit | Lin Hua Cheng proposed openstack/keystonemiddleware: Remove superfluous / spammy log line https://review.openstack.org/178292 | 17:15 |
| morganfainberg | ayoung: like today if they merge btw. | 17:15 |
| ayoung | morganfainberg, +2 +1 from me | 17:15 |
| samueldmq | morganfainberg, is this too detailed for now ? or I can add specific things like this ^ | 17:15 |
| morganfainberg | ayoung: i'm at a conference so i'll try and look at the accessinfo today | 17:15 |
| morganfainberg | if not today when i;m home on thursday | 17:15 |
| ayoung | morganfainberg, thanks | 17:15 |
| samueldmq | ayoung, cc ^ | 17:16 |
| ayoung | samueldmq, which review? | 17:16 |
| samueldmq | ayoung, I am talking about the etherpad of ideas to L | 17:17 |
| samueldmq | ayoung, L 75 | 17:17 |
| ayoung | samueldmq, ++ excpet maybe for the use of annotation ,which I hate but might be the only way | 17:17 |
| *** markvoelker has quit IRC | 17:18 | |
| openstackgerrit | ayoung proposed openstack/python-keystoneclient: Inherit roles project calls on keystoneclient v3 https://review.openstack.org/167613 | 17:18 |
| samueldmq | ayoung, ahah let's let the idea there :) and hten we decide how to implement | 17:18 |
| samueldmq | ayoung, and like this we will stop having bugs on things that aren't properly validated | 17:18 |
| ayoung | htruta, please do a review -d 167613 before making changes | 17:18 |
| ayoung | samueldmq, maybe...I am trying, though, to push splitting off more microservices from Keystone. For example, policy might become its own service. | 17:20 |
| *** _cjones_ has joined #openstack-keystone | 17:20 | |
| stevemar | ayoung, it pretty much is at this poiint | 17:21 |
| *** harlowja_away is now known as harlowja_ | 17:21 | |
| ayoung | stevemar, exactly, and the Kent folks are working on some DB code that uses dnf. THe library is Py3 only | 17:22 |
| stevemar | dnf? | 17:22 |
| ayoung | I think that is the format...let me check | 17:22 |
| samueldmq | hehe | 17:22 |
| ayoung | stevemar, \`Disjunctive Normal Form (DNF)`: http://en.wikipedia.org/wiki/Disjunctive_normal_form | 17:23 |
| samueldmq | ayoung, I dont see a big advantage on having separate microservices ... since they will always be deployed together .. | 17:23 |
| ayoung | which, of course clashes with the Yum replacement | 17:23 |
| bknudson | they can be scaled separately | 17:23 |
| samueldmq | ayoung, it's much bettter to have a consistent and well organized architecture, as well mostly have today | 17:23 |
| ayoung | samueldmq, also, separation of concerns | 17:24 |
| samueldmq | bknudson, yeah, that should be good for identity | 17:24 |
| ayoung | plus, it is easier to enforce API stability at the web level than at the python level, as morganfainberg will tell you | 17:24 |
| samueldmq | but I dont see the need to separate other than that | 17:24 |
| ayoung | Identity on one server . Federation and assignment together. Policy a third server. | 17:25 |
| ayoung | EC2 and the other extension somewhere over there... | 17:25 |
| *** samleon has joined #openstack-keystone | 17:25 | |
| samueldmq | shouldnt federation be much more identity than assignment ? | 17:25 |
| samueldmq | I mean, it's about identity, isnt it ? | 17:26 |
| samueldmq | ayoung, anyway, it's a separate discussion, and just to clarify, I like identity going as a separate microservice | 17:27 |
| samueldmq | :) | 17:27 |
| *** e0ne has joined #openstack-keystone | 17:28 | |
| samueldmq | bknudson, ayoung hmm, microservices doesn't mean separate repos | 17:32 |
| samueldmq | we just separate the rest applicaitons, I am right ? | 17:32 |
| bknudson | separate repos makes more sense to me since then you have a clear separation | 17:33 |
| samueldmq | I did something like this when I started on OpenStack .. I created a guide for scaling out the heat-api | 17:33 |
| samueldmq | http://docs.openstack.org/developer/heat/scale_deployment.html | 17:33 |
| samueldmq | bknudson, and then we will need a sort of devstack-keystone ot have keystone server running ? | 17:34 |
| *** ir2ivps8_ has joined #openstack-keystone | 17:34 | |
| bknudson | it's already easy to run only keystone in devstack | 17:34 |
| morganfainberg | bknudson: we might need a ds-g config for it (in the matrix) | 17:35 |
| morganfainberg | but otherwise yes it's easy | 17:35 |
| bknudson | the only odd thing is that keystone-only devstack requires configuring a message broker. | 17:35 |
| *** aix has quit IRC | 17:36 | |
| morganfainberg | bknudson: does it? | 17:36 |
| samueldmq | sounds good, I am just concerned on how we split things, to not have unnecessary granularity | 17:36 |
| bknudson | I always set ENABLED_SERVICES=key,mysql,rabbit | 17:36 |
| bknudson | maybe that's changed | 17:36 |
| *** henrynash has quit IRC | 17:36 | |
| *** _cjones_ has quit IRC | 17:39 | |
| marekd | bknudson: and what happens if you skip rabbit? | 17:40 |
| *** _cjones_ has joined #openstack-keystone | 17:42 | |
| *** grizz_ has joined #openstack-keystone | 17:42 | |
| *** mattamizer has joined #openstack-keystone | 17:43 | |
| bknudson | marekd: it works fine now. Somebody must have fixed it. | 17:44 |
| morganfainberg | marekd: have some questions re keystone behavior for metadata stuff | 17:47 |
| morganfainberg | marekd: will need to wait until later this week | 17:47 |
| morganfainberg | but - some interesting questions about behavior with aggregates for identity | 17:48 |
| marekd | morganfainberg: sure. | 17:48 |
| marekd | morganfainberg: next ksc version released will be 1.3.2, right? | 17:49 |
| *** markvoelker has joined #openstack-keystone | 17:49 | |
| morganfainberg | marekd: for kilo, yes | 17:49 |
| bknudson | should be 2.0.0 since we removed middleware | 17:49 |
| morganfainberg | marekd, for master no. | 17:49 |
| morganfainberg | marekd: looking at 2.x.x | 17:49 |
| morganfainberg | bknudson: yes | 17:50 |
| bknudson | we could get rid of other deprecated cruft too if there is any | 17:50 |
| morganfainberg | bknudson: i'd like to also do the keystoneauth switch-over when we cut 2.x.x if possible | 17:50 |
| morganfainberg | bknudson: trying to push through the keystoneauth repo todya | 17:50 |
| marekd | morganfainberg: bknudson so what version shall i specify in the auth/identity/v3/federated.py ? 1.3.2 or 2.0.0 ? | 17:50 |
| *** kiran-r has quit IRC | 17:51 | |
| morganfainberg | marekd: uhmmm... | 17:51 |
| bknudson | marekd: whatever's in global-requirements: http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt | 17:51 |
| morganfainberg | marekd: ^^ | 17:51 |
| bknudson | and if the version in g-r isn't new enough then bump it up. | 17:51 |
| bknudson | http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n124 | 17:52 |
| rodrigods | marekd, stevemar could use some reviews here https://review.openstack.org/#/c/172536/ :) (and in the following patch) | 17:52 |
| marekd | rodrigods: perhaps after the meeting, ok ? | 17:52 |
| rodrigods | ++ | 17:52 |
| *** markvoelker has quit IRC | 17:54 | |
| marekd | bknudson: is there any reason why g-r has ksc 1.1.0 whereas pypi has 1.3.2 ? Different release cycles or g-r is simply outdated? | 17:55 |
| bknudson | marekd: there's nothing that requires a newer version of keystoneclient yet. | 17:55 |
| *** itlinux has joined #openstack-keystone | 17:56 | |
| bknudson | I've got a review out to up it to 1.3.0: https://review.openstack.org/#/c/168187/ | 17:56 |
| itlinux | hi Adam, how are you doing? | 17:56 |
| bknudson | proposed over a month ago. | 17:56 |
| *** henrynash has joined #openstack-keystone | 17:57 | |
| *** ChanServ sets mode: +v henrynash | 17:57 | |
| *** rushil has quit IRC | 17:57 | |
| *** e0ne has quit IRC | 17:58 | |
| *** ir2ivps8_ has quit IRC | 17:58 | |
| marekd | bknudson: ok, i am little confused. We are at the 1.3.1 version of ksc, so it looks illogical to specify that I deprecate something since 1.1.0... | 17:58 |
| morganfainberg | almost meeting time (hey having the meeting *POST* lunch is nice) | 17:58 |
| * morganfainberg should move to the east coast or something. | 17:59 | |
| samueldmq | morganfainberg, hehe :) | 17:59 |
| marekd | morganfainberg: werent you supposed to move somewhere to NYC? | 17:59 |
| bknudson | marekd: that would be illogical... it'll be deprecated as of the next release. | 17:59 |
| samueldmq | ayoung, just to keep you updated, I did some changes on the overview spec | 18:00 |
| samueldmq | ayoung, will wait for post-meeting when we decide the scope of hierarchical roles | 18:00 |
| ayoung | samueldmq, too much notification. I assure you I will see it | 18:00 |
| *** samleon has quit IRC | 18:00 | |
| ayoung | But I appreciate your enthusiasm | 18:00 |
| marekd | bknudson: correct. | 18:00 |
| marekd | bknudson: but still, there will be two release numbers. | 18:01 |
| samueldmq | ayoung, just want you to know I am planning to run fast with it, as you're doing | 18:01 |
| bknudson | marekd: how are there 2 release numbers? | 18:01 |
| ayoung | You are running. I am sitting on my Kiester | 18:01 |
| samueldmq | ayoung, nah, we run together | 18:01 |
| marekd | bknudson: 1.3.2 for kilo and 2.0.0 | 18:01 |
| marekd | for master | 18:01 |
| marekd | anyways, i mist have messed something up. | 18:01 |
| bknudson | oh, this change is backported? I don't have a problem with reporting something as deprecated in backported change. | 18:03 |
| *** jamielennox|away is now known as jamielennox | 18:04 | |
| *** _cjones_ has quit IRC | 18:05 | |
| *** BjoernT has left #openstack-keystone | 18:05 | |
| *** browne has joined #openstack-keystone | 18:09 | |
| *** iamjarvo has joined #openstack-keystone | 18:19 | |
| *** tqtran has quit IRC | 18:19 | |
| dolphm | samueldmq: my normal process for writing release notes is to gather a list of links to every Wishlist bug and blueprint implemented in the cycle, then start replacing those links with corresponding release notes | 18:23 |
| *** ir2ivps8_ has joined #openstack-keystone | 18:23 | |
| dolphm | samueldmq: we can do that in an etherpad to iterate faster, and then put the result into the wiki for broader collaboration | 18:23 |
| samueldmq | dolphm, ++ https://etherpad.openstack.org/p/keystone-kilo-release-notes | 18:24 |
| dolphm | samueldmq: cool | 18:24 |
| *** mattamizer has quit IRC | 18:28 | |
| *** grizz_ has quit IRC | 18:30 | |
| samueldmq | dolphm, done, I've got the info available on the links for the versions | 18:33 |
| marekd | gyee: sadly, never heard of conductor - what's the purpose of that. Somekind of interface/stub class for drivers? | 18:33 |
| samueldmq | dolphm, but in the link for K-1 there is only 2 bps, and you put 3 on the etherpad .. I wonder if there is another place to look into | 18:33 |
| dolphm | samueldmq: sweet, next step is to write a release note for each, but some links won't deserve mention in the release notes | 18:34 |
| dolphm | samueldmq: like this one https://bugs.launchpad.net/keystone/+bug/1438983 | 18:34 |
| openstack | Launchpad bug 1438983 in Keystone "The directory holding dev docs is "doc" instead of "docs"." [Wishlist,Fix released] - Assigned to DWang (darren-wang) | 18:34 |
| dolphm | samueldmq: I'd argue that one should really have been a Low impact, not Wishlist | 18:34 |
| samueldmq | dolphm, basically nits or something we don't have much to talk | 18:34 |
| dolphm | samueldmq: if it doesn't impact end users, it doesn't deserve mention in the release notes | 18:35 |
| samueldmq | dolphm, ++ | 18:35 |
| dolphm | samueldmq: some wishlist bugs legitimately only impact keystone developers, for example | 18:35 |
| samueldmq | dolphm, also, there is a bunch of bugs as Undefined or kilo-3 | 18:35 |
| dolphm | samueldmq: i'll look at triaging those then first | 18:36 |
| samueldmq | dolphm, I just included the ones clearly marked as Wishlist | 18:36 |
| dolphm | samueldmq: if i triage anymore as wishlist, i'll include them | 18:36 |
| samueldmq | dolphm, nice thanks | 18:36 |
| samueldmq | dolphm, also, make sure there isn't any other bug/blueprint that is not in that list and need to be included | 18:37 |
| samueldmq | dolphm, I saw you included 'Provide Endpoint for ECP wrapped assertions' to kilo-1 (which is not on https://launchpad.net/keystone/+milestone/kilo-1) | 18:37 |
| stevemar | didn't ^ land in kilo3 or kilorc1? | 18:39 |
| samueldmq | stevemar, we don't tag specific releases on the release notes, so I think it doesnt matter at the end | 18:41 |
| dolphm | samueldmq: which bp was that? | 18:41 |
| dolphm | https://blueprints.launchpad.net/keystone/+spec/ecp-wrapped-saml-assertions ? | 18:41 |
| samueldmq | dolphm, L 5 | 18:42 |
| dolphm | samueldmq: that's on kilo-rc1, not kilo-1 | 18:42 |
| samueldmq | dolphm, you added that on the etherpad | 18:42 |
| dolphm | samueldmq: to kilo-1 or kilo-rc1? (i'm trying to figure out how i made a mistake) | 18:42 |
| dolphm | (in case i made more) | 18:42 |
| samueldmq | dolphm, to k-1 | 18:42 |
| dolphm | hmm, well: fixed | 18:43 |
| samueldmq | dolphm, yeah I can't check the list in kilo-1 against what is in https://launchpad.net/keystone/+milestone/kilo-1 | 18:43 |
| samueldmq | dolphm, also the wishlist bugs ... there are two on the page ^ | 18:43 |
| samueldmq | dolphm, and you listed three in the pad | 18:43 |
| dolphm | samueldmq: it looks like i did kilo-rc1 entirely instead of kilo-1 | 18:44 |
| *** _cjones_ has joined #openstack-keystone | 18:45 | |
| dolphm | must have been looking at the wrong page | 18:45 |
| samueldmq | dolphm, can I fix it ? | 18:46 |
| dolphm | samueldmq: fixed! thanks | 18:46 |
| samueldmq | dolphm, you did, np | 18:46 |
| samueldmq | dolphm, it should be a short description of what was implemented right ? | 18:46 |
| samueldmq | dolphm, feel free to fix something I write badly | 18:47 |
| dolphm | samueldmq: a short description of what changed, how it impacts the deployer / end user, and i personally like to link to relevant documentation if possible | 18:49 |
| dolphm | samueldmq: it should basically read like a list of facts | 18:49 |
| *** markvoelker has joined #openstack-keystone | 18:49 | |
| samueldmq | dolphm, got it, I will have most of them by tonight (doing other thing in parallel now) | 18:51 |
| *** ajayaa has quit IRC | 18:53 | |
| *** erkules_ is now known as erkules | 18:54 | |
| *** markvoelker has quit IRC | 18:54 | |
| dolphm | samueldmq: same - i'm trying to wrap up a few other things first | 18:54 |
| samueldmq | dolphm, ++ | 18:54 |
| gyee | dolphm, lbragstad, you didn't get I was joking the first time around | 18:55 |
| lbragstad | gyee: got it, I missed the sarcasm there ;) | 18:55 |
| dolphm | i'm not sure i saw the first comment | 18:55 |
| *** samueldmq_ has joined #openstack-keystone | 18:56 | |
| gyee | I was responding to marekd's "i think we will have to stick with token-per-cloud for now." comment | 18:56 |
| marekd | gyee felt offended :P | 18:57 |
| gyee | noooh, I was merely having fun | 18:58 |
| marekd | dolphm: nobody wants to blindly share any tokens.... | 18:58 |
| marekd | if share that there would be a clear boundary on access, so admin@cloudA will not mean admin@cloudB | 18:59 |
| *** e0ne has joined #openstack-keystone | 18:59 | |
| ayoung | Ok.. henrynash hierarchical roles | 19:00 |
| dolphm | marekd: secret gist of fernet keys can provide clear boundary between clouds | 19:01 |
| ayoung | or, as I preferred to call them, implied roles | 19:01 |
| *** geoffarnold has joined #openstack-keystone | 19:01 | |
| *** Rockyg has joined #openstack-keystone | 19:01 | |
| gyee | ayoung, call them nested groups | 19:01 |
| marekd | dolphm: then you are safe | 19:01 |
| dolphm | gyee: that's what trusts are for | 19:01 |
| dolphm | morganfainberg: i think? ^ | 19:01 |
| *** ioram has joined #openstack-keystone | 19:01 | |
| ayoung | gyee, they are really sets | 19:01 |
| gyee | dolphm, right, federation is a form of trust | 19:01 |
| ayoung | if the bottom level permission is the API you are calling, then a role is a set of APIs | 19:02 |
| amakarov | gyee, and a trust is a form of assignment )) | 19:02 |
| gyee | amakarov, full circle :) | 19:02 |
| morganfainberg | dolphm: hmm? | 19:02 |
| morganfainberg | dolphm: hah secret gist of fernet keys | 19:02 |
| morganfainberg | dolphm: wow, such secure ;) | 19:02 |
| ayoung | gyee, but I need henrynash as he's the one that -2ed it | 19:03 |
| ayoung | and I think I know why | 19:03 |
| gyee | henrynash's objection over naming? | 19:03 |
| ayoung | https://review.openstack.org/#/c/125704/ | 19:04 |
| ayoung | DAMNIT HENRY GET IN HERE! | 19:04 |
| haneef | does keytone team own pycadf? | 19:04 |
| ayoung | haneef, yep | 19:04 |
| morganfainberg | haneef: yes | 19:04 |
| dolphm | haneef: ye | 19:04 |
| samueldmq | ayoung, hi, I am on the boat of role-groups :) | 19:04 |
| morganfainberg | haneef: though it is a different core group than keystone-core | 19:04 |
| samueldmq | ayoung, I can talk about it if you need to | 19:04 |
| stevemar | haneef, yep | 19:04 |
| samueldmq | but yeah it would be great to discuss with henrynash as well | 19:04 |
| haneef | https://github.com/openstack/pycadf/blob/master/setup.cfg -- why do we include service specific conf file in pycadf install? | 19:04 |
| morganfainberg | dolphm: btw, Keystone should be the IAM project not AAA [things you learn when getting asked to talk at conferences] | 19:04 |
| morganfainberg | dolphm: but AAA is cooler | 19:05 |
| henrynash | ayoung, samueldmq: so I think I could fo for teh role-grousp idea (especialy as that’s what I called them in teh first first spec) | 19:05 |
| morganfainberg | gordc: ping ^ haneef's question | 19:05 |
| samueldmq | henrynash, yes, I would prefer to have this name back, since we could have groups of global roles | 19:05 |
| morganfainberg | stevemar: unless you know | 19:05 |
| ayoung | henrynash, OK, I want each token ideally to have only one role-group. | 19:05 |
| gyee | henrynash, nested role groups | 19:05 |
| ayoung | let's drop the name role for a moment | 19:05 |
| samueldmq | henrynash, which may not specifically be i na domain | 19:05 |
| samueldmq | henrynash, right? | 19:05 |
| stevemar | morganfainberg, haneef in a meeting | 19:06 |
| ayoung | there are APIs. like "compute_extension:admin_actions": "rule:admin_api", | 19:06 |
| ayoung | and we have rules that say a user can operate on that API | 19:06 |
| henrynash | samueldmq: I guess I don’t see why you shouldn’t allow “global” role-grousp as well as “domain specific ones" | 19:06 |
| stevemar | haneef, you mean the data files? https://github.com/openstack/pycadf/blob/master/setup.cfg#L25-L31 | 19:06 |
| ayoung | nova doens't even check which role for the most part | 19:06 |
| haneef | yes | 19:06 |
| ayoung | "admin_or_owner": "is_admin:True or project_id:%(project_id)s", | 19:06 |
| ayoung | any role and you can do any of the Owner operations | 19:07 |
| morganfainberg | those probably belong in the respective projects stevemar. | 19:07 |
| samueldmq | henrynash, I am agreeing with you, we should have global or domain specific role-groups | 19:07 |
| ayoung | henrynash, so I want to head towards a norm where each API rule has two parts: | 19:07 |
| gyee | ayoung, right, not just nova, if you have any access to the project, you are by definition "owner" | 19:07 |
| haneef | stevemar: everycomponents etc has this file, | 19:08 |
| ayoung | 1. scope. mostly to make sure we match the project_id correctly | 19:08 |
| gyee | as ownership is established at the project level right now | 19:08 |
| ayoung | as that as you saw in the cloudsample, can get really tricky | 19:08 |
| ayoung | 2. role | 19:08 |
| henrynash | ayoung, samueldmq: the difference in my mind between me views and ayoung’s is that I don’t connect this with any change in token necessarily…i.e. you could do all that I ahve said and tokens never know about role-groups | 19:08 |
| amakarov | dstanek, o/ | 19:08 |
| ayoung | er... damin I used the term role | 19:08 |
| amakarov | dstanek, is there bp or spec about functional testing? | 19:09 |
| samueldmq | henrynash, ayoung yeah I think you diverge on where we expand roles | 19:09 |
| ayoung | henrynash, you want the private roles, don't you? And to make that easy, you just add more public roles to the token? | 19:09 |
| henrynash | ayoung, samueldmq: a further extension of the role-groups idea is that we allow the policy engine to know about them (and hecen you can put them ina token) | 19:09 |
| samueldmq | ayoung, want ot expand them on the service side, while you want in the keystone (as it is today ) | 19:09 |
| ayoung | lets call them role-sets, just cuz the name group is used elsewhere | 19:09 |
| gyee | hanrynash, but you do need all the roles in the hierarchy | 19:10 |
| ayoung | and set makes sense, as it is "member-of or not-member-of" | 19:10 |
| amakarov | ayoung, amplua! | 19:10 |
| henrynash | gyee: there may or may not be a (role) hierarchy | 19:10 |
| henrynash | gyee: imho…that’s a further extension | 19:10 |
| gyee | unless we have "effective roles" which is at the botton of the hierarchy | 19:11 |
| ayoung | so you want: a private role would implcitly get a role-set, and then we add that role set to the token, and on the policy side we convert from role-set to individual operations? | 19:11 |
| gordc | haneef: i believe it related to packaging rpms | 19:11 |
| gyee | those are the ones recognized by the policies | 19:11 |
| gordc | haneef: https://github.com/openstack/pycadf/commit/f2c5f6305a58f3f69144470409a84b5fc93e61ab | 19:11 |
| gordc | haneef: that said, i'm not really familiar with the entire packaging process | 19:11 |
| henrynash | ayoung: was I “you” in that sentance? | 19:11 |
| ayoung | henrynash, yes | 19:11 |
| henrynash | ayoung: :-) | 19:11 |
| ayoung | henrynash, I know you were driving toward private roles | 19:11 |
| ayoung | and so I am assuming that is your starting point | 19:12 |
| ayoung | trying to connect from that through to enforcement | 19:12 |
| samueldmq | henrynash, ayoung if someone wants , one can implement hierarchies with role-sets | 19:12 |
| ayoung | we currently enforce on role-name. | 19:12 |
| henrynash | ayoung: actually, what I want is to separate the concept of role-sets and policy/token changes….to first decide if we want teh roel set fucntionaly at all | 19:12 |
| ayoung | henrynash, remember, we can't easily change the token data without a major API revision | 19:13 |
| haneef | gordc: If you do python setup.py install on keytone or any other service, it gets insalled. rpm is not involved here. That comment is misleading | 19:13 |
| henrynash | ayoung: if we diecde we do (and I think we do)….then we can decie how we solve the token boat problem (which is, I think, the only reaons NOT to expand it on token generation) | 19:13 |
| ayoung | I think we are stuck with roles, | 19:13 |
| ayoung | so a role group would have to remain a server side construct | 19:13 |
| henrynash | ayoung: oh….I’m arguing NOT to chaneg the token format! | 19:13 |
| haneef | gordc: Shouldn't this file go to respective service. why does keystone install get trove audit file? | 19:13 |
| gyee | ayoung, we don't need to change the API so as long as we have "effective roles", which are directly corresponding to the APIs | 19:13 |
| gyee | we can have one to one mapping | 19:14 |
| gyee | effective role = operation | 19:14 |
| samueldmq | # info domain-roles and hierarchical roles died... role-sets rises ftw | 19:14 |
| ayoung | gyee, when you enforce, you enforce on the "effective role"? | 19:14 |
| samueldmq | henrynash, ayoung cc ^ | 19:14 |
| gyee | ayoung, yes | 19:14 |
| gyee | otherwise, it will be messy | 19:14 |
| ayoung | gyee, and effective roles are grouped together into role-sets | 19:14 |
| gyee | ayoung, yes | 19:14 |
| ayoung | role-sets *are* roles, as we need to transfer them in the tokens? | 19:15 |
| gordc | haneef: the reason it's managed within pycadf is because the CADF event model isn't adopted beyond a few services. | 19:15 |
| gyee | ayoung, correct, similar to how we resolve group membership today | 19:15 |
| *** ajayaa has joined #openstack-keystone | 19:15 | |
| gyee | by walking to tree | 19:15 |
| ayoung | gyee, yeah, that is what I meant by hierarchical roles. Its what henrynash -2ed | 19:15 |
| henrynash | ayoung: well…I’m trying to say that they are not…..we could implement them without a toekn every seinga role-set | 19:15 |
| ayoung | that is where I think we need to be | 19:16 |
| samueldmq | gyee, ayoung wants to put role-sets in the token, henrynash doesnt | 19:16 |
| gordc | haneef: i wouldn't mind having those files in the corresponding services... but that needs wide community support. which we didn't have at the time. (and i'm not sure we have now) | 19:16 |
| gyee | noooh, don't put role set into the token | 19:16 |
| samueldmq | one approach is to have everything as it is today (henrynash) | 19:16 |
| gyee | token stay the same | 19:16 |
| gyee | token contains "effective roles" | 19:16 |
| samueldmq | gyee, so you agree with henrynahs | 19:16 |
| gyee | that what henrynash said? | 19:17 |
| ayoung | henrynash, what if we make it really easy to define a new role-set, | 19:17 |
| ayoung | ugh, a role is a Permission-set really | 19:17 |
| gyee | for the same reason we don't put user groups in the token | 19:17 |
| *** itlinux has quit IRC | 19:17 | |
| samueldmq | gyee, yeah, that is | 19:17 |
| ayoung | if one role inherits another role, it is now a union permissions explicitly assigned to itself and the other role | 19:18 |
| samueldmq | gyee, and the api to define role-sets would be as the groups one is ... adding and removing individual roles or other role-sets to them | 19:18 |
| gyee | right, we differentiate between roles and role-sets | 19:18 |
| gyee | only roles goes into the token | 19:18 |
| ayoung | henrynash, I think what you want is for the token to have an identifier that links to the private role, and then on the policy side the private role gets expanded out to its individual operations | 19:19 |
| henrynash | ayoung, samueldmq: so my big thing is that I feel we are mixing the reasosn for doings things…i.e. we can add role-sets and don’t change tokens….we tehn have a problem of token bloat…how do we solve that…there are different solutions…one is pusing the role-set concet to the policy, another is token set caching (as we discussed breifly at the last mid cycle) | 19:19 |
| samueldmq | ayoung, I think this approach goes well as a fiest step | 19:19 |
| samueldmq | ayoung, after we can migrate the expasion logic to the services, etc if we decide to | 19:19 |
| henrynash | ayoung: nope, I don’t think so | 19:19 |
| ayoung | henrynash, so, no token bloat | 19:19 |
| samueldmq | ayoung, but it's independent | 19:19 |
| ayoung | here is what I think | 19:19 |
| haneef | gordc: Those services that are using pycadf will be willing to have the config file there. If we have these files in pycadf, then do we plan to release a new version for each services mapping change. In a controller node , we have a copy of these files for each service | 19:19 |
| ayoung | we take ioram 's code as the starting point | 19:19 |
| ayoung | generate the policy file from the database | 19:19 |
| ayoung | use the idea of one role containing other roles as one of the inputs | 19:20 |
| ayoung | and generate the policy file from that | 19:20 |
| ayoung | at the individual API level, we specify the lower role possible to execute that API | 19:20 |
| gordc | haneef: got it... i see the issue. | 19:20 |
| ayoung | at the top of the policy file, we have rules generated from the hierarchy | 19:20 |
| gordc | haneef: " Those services that are using pycadf will be willing to have the config file there" -- is that an assumption? | 19:21 |
| ayoung | so if I get a token that says "Member" I hit a rule that say "Memeber implies read, writer, and a executor" | 19:21 |
| ayoung | but, if I want, I could create a token that only has "writer" in it | 19:21 |
| samueldmq | ayoung, read, writter and executor can be roles, and Member a role-set | 19:21 |
| ayoung | and then I would be limited to the operatiosn either explicitly assinged to writer, or to any roles it contains | 19:21 |
| ayoung | samueldmq, writer is a role-set, too | 19:22 |
| ayoung | writer assumes reader | 19:22 |
| samueldmq | ayoung, yeah, so role-sets and in the lowest level we have roles | 19:22 |
| ayoung | but..sure | 19:22 |
| gordc | haneef: currently, i'm not sure who is consuming the audit middleware aside from ibm and a few other companies (not sure if in production or testing) | 19:22 |
| samueldmq | ayoung, as leaf | 19:22 |
| haneef | gordc: Yes. if not why do they even they care about mapping. They should own it otherwise who can verify service mapping | 19:23 |
| ayoung | roles are sets of operations, and can be defined in terms of unions of other roles | 19:23 |
| samueldmq | ayoung, yes I agree | 19:23 |
| ayoung | henrynash, does that still raise warning flags? | 19:23 |
| henrynash | ayoung: see, imho, the reason why some us find this hard to swallow is taht you haev pulled in half a dozen differnet things (whcih we may or may not think customers want) rolled these intoa big sollution and that’s the answer…..I guess I’m just wary of making these leaps…..and think that as keystone we should be taking this incrementally, seeing what things customers actually use….if tehy don’t use it ditch it…when they use | 19:23 |
| henrynash | something alot and it causes a performace problem, we thensolve it cuase we know its a REAL problem | 19:23 |
| samueldmq | ayoung, henrynash, gyee I think the all the policcy thing is changing too much now, we should be conservative and to not change the enforcement, what goes in the token etc | 19:24 |
| henrynash | ayoung: /rant odd | 19:24 |
| gyee | you don't need to generate any policy files, oslo policy allow you to set the rules directly | 19:24 |
| henrynash | h | 19:24 |
| henrynash | (stops ranting) | 19:24 |
| ayoung | henrynash, so...I could actually implement this now, without server side support. In fact, it is one of the tools I am going to talk about in the summit policy talk; | 19:24 |
| ayoung | lets take that rule I showed before...or better yet.. | 19:24 |
| ayoung | "compute_extension:admin_actions:createBackup": "rule:admin_or_owner", | 19:25 |
| gordc | haneef: well those individual projects didn't create those mappings. they were created by someone who was auditing those services. | 19:25 |
| ayoung | OK...let's start by saying we want to change "owner" to mean "member" | 19:25 |
| ayoung | so this should expand out to | 19:25 |
| ayoung | project_id:%(project_id)s and role:admin or role:Member | 19:25 |
| gordc | haneef: we can give it a try... but i'm pretty sure someone is going to ask "what is this, and what is pycadf" | 19:25 |
| henrynash | ayoung: so which cuystomer says we want to do that? | 19:25 |
| ayoung | cuz..."Admin" without scope is bad | 19:25 |
| ayoung | henrynash, um...oldest bug in the bug tracker? | 19:26 |
| henrynash | ayoung: what is the real, in teh field, probem that we are solving | 19:26 |
| morganfainberg | ayoung: but I wants my admin scope... my precious... admin scope...seses | 19:26 |
| morganfainberg | ayoung: :P | 19:26 |
| samueldmq | morganfainberg, lol | 19:26 |
| gyee | heh | 19:26 |
| gyee | my precious | 19:26 |
| ayoung | https://bugs.launchpad.net/keystone/+bug/968696 | 19:26 |
| openstack | Launchpad bug 968696 in Keystone ""admin"-ness not properly scoped" [High,Confirmed] - Assigned to Adam Young (ayoung) | 19:26 |
| morganfainberg | ayoung: look at that bug number | 19:26 |
| morganfainberg | annnnncient [in terms of openstack] | 19:26 |
| ayoung | 2012-03-29 | 19:26 |
| morganfainberg | and keystone | 19:26 |
| ayoung | yep...and I didn;t have a way to solve it | 19:27 |
| samueldmq | ayoung, you know we can solve that today by adding scope checks to all endpoints in the polciyc right ? | 19:27 |
| ayoung | henrynash, so there is that problem, and also the ability to limit the amount we delegate to another user | 19:27 |
| ayoung | samueldmq, and break everything | 19:27 |
| morganfainberg | jamielennox: hopefully will have KSA in gerrit today | 19:27 |
| jamielennox | morganfainberg: \o/ | 19:27 |
| ayoung | samueldmq, "admin" needs to go in and fix things | 19:27 |
| henrynash | ayuong: you mean I can only delegate the roles I ahve? | 19:27 |
| ayoung | henrynash, yes | 19:28 |
| samueldmq | ayoung, how can we then fix the behavor without breakin what's wrong | 19:28 |
| morganfainberg | jamielennox: and for initial work, to cleanup/strip down 1-core +2/+A, we do a full review before we cut release. | 19:28 |
| ayoung | samueldmq, that is what I am trying to lay out, piece by piece | 19:28 |
| *** markvoelker has joined #openstack-keystone | 19:28 | |
| morganfainberg | jamielennox: see if anything is needed before it becomes a "real lib" and released. | 19:28 |
| haneef | gordc: I agree with you, IMO we should not allow checkin of "someone's specific audit mapping requirement" into pycadf project. We should have asked them to talk to the services | 19:28 |
| ayoung | this is core to it, but not yet sufficient | 19:28 |
| samueldmq | ayoung, henrynash we can do that with role-sets by only allowing delegation of subroles, right ? | 19:28 |
| jamielennox | morganfainberg: what do you want to do about changes to keystoneclient since you split | 19:28 |
| morganfainberg | jamielennox: port them | 19:29 |
| jamielennox | morganfainberg: or changes that are still proposed | 19:29 |
| morganfainberg | jamielennox: or reporpose against KSA | 19:29 |
| ayoung | samueldmq, we need your hierarchical assignemnts, too | 19:29 |
| *** _cjones_ has quit IRC | 19:29 | |
| morganfainberg | i'll be getting it in g-r as soon as we have a release | 19:29 |
| *** markvoelker has quit IRC | 19:29 | |
| henrynash | ayoung: so the reason you want role “hierarchies” is to solve this bug…? | 19:29 |
| jamielennox | i have a bunch of changes that are still proposed for client - should we just wait and put them in ksa? | 19:29 |
| ayoung | so If I am a domain admin, I can get admin on any lower scope | 19:29 |
| samueldmq | ayoung, hierarchies can be implemented with role-sets | 19:29 |
| morganfainberg | jamielennox: if we can move on KSA quickly, yes | 19:29 |
| *** markvoelker has joined #openstack-keystone | 19:29 | |
| *** markvoelker has quit IRC | 19:29 | |
| *** markvoelker has joined #openstack-keystone | 19:29 | |
| gordc | haneef: fair enough. that's probably a plan we envisioned initially. but then i became jaded.lol | 19:30 |
| samueldmq | we can definetively solve that with role-sets ... you can only delegate a subset of yout roels . | 19:30 |
| henrynash | ayoung: whay doesn’t teh v3cloudpolciy sample some the initial bug description? | 19:30 |
| samueldmq | and this makes sense to me | 19:30 |
| samueldmq | 19:30 | |
| gordc | haneef: do you happen to use the audit middleware or do you just want those files out of pycadf? | 19:30 |
| henrynash | (solve the...) | 19:30 |
| ayoung | henrynash, becasue that is for Keystone only | 19:30 |
| ayoung | henrynash, there are many other services that are worse off | 19:30 |
| ayoung | v3 is a good step | 19:31 |
| ayoung | I would say that it is probably the most complex part, too | 19:31 |
| henrynash | ayoung: (playing devils advocate): ok, but if it can solve it for keystone, why don’t we just enourage otehr services to so something similar? | 19:31 |
| ayoung | henrynash, ok, so I work in this full time, and I had trouble parsing v3 | 19:31 |
| ayoung | so while the logic is good, the organization needs help | 19:32 |
| ayoung | alos, it does not allow for delegation of a subset of permissions | 19:32 |
| geoffarnold | Naive question: one of my prod mgrs is asking about anonymous domains (region admin wouldn't be able to see inside/mess with anything inside). Should I just tell him to go away? | 19:32 |
| ayoung | you can create a trust with a subset of what you can do, but if you can't break your roles down more granular, all you can delegate is "everything" | 19:33 |
| ayoung | geoffarnold, no | 19:33 |
| henrynash | ayoung: for delegation…..why is taht polify file related….isn’t it just at the point of delegation? | 19:33 |
| ayoung | geoffarnold, reseller spec is for solving that...but can we hold off | 19:33 |
| *** ajayaa has quit IRC | 19:33 | |
| geoffarnold | k | 19:33 |
| haneef | gordc: we plan to use, and we want to have our own files, and definitely don't want to have trove files in keystone installation | 19:33 |
| ayoung | henrynash, point of delegation is policuy enforcement | 19:33 |
| samueldmq | ,isnt that role assignments and token generation ? | 19:33 |
| ayoung | henrynash, lets say I split the nova operations up into three sorts: admin, change state, read state | 19:34 |
| gyee | geoffarnold, there's no region admin concept | 19:34 |
| ayoung | if I am a Member, I get to read state or change state | 19:34 |
| gyee | geoffarnold, domain admin can only manage resource with his domain | 19:34 |
| ayoung | if I am an auditor, I should only be able to read state | 19:34 |
| gordc | haneef: if you're willing to support the adoption of CADF, i'm all for it and will help you move it | 19:34 |
| ayoung | so on a given operation, I can either say" | 19:34 |
| *** mestery has quit IRC | 19:34 | |
| openstackgerrit | David Stanek proposed openstack/keystone: Script to sync oslo https://review.openstack.org/114305 | 19:34 |
| ayoung | role:member or role:auditor | 19:35 |
| ayoung | or I can say | 19:35 |
| ayoung | rule:auditor | 19:35 |
| henrynash | ayoung: so your argument is that if all peopel do is admin and member, then there’s not enough granularity…but I’m not sure what a productin deployemetn woudn;t have lots of roels (e.g. vm_viewer, vm_creator, vm_destroyer) etc….then couldn’t we allow just a portion of those to be delegted? | 19:35 |
| gyee | what is auditor? a role set? | 19:35 |
| ayoung | and the auditor role: memeber or role:auditor | 19:35 |
| ayoung | henrynash, at its most granular yes | 19:35 |
| haneef | gordc: sure | 19:35 |
| ayoung | but what we assign to a user is the role-set...the effective role, some node higher up the tree | 19:36 |
| ayoung | member implies (or contains): vm_viewer, vm_creator, vm_destroyer | 19:36 |
| henrynash | ayoung: so is your argument for hierachies/role-sets in policy fundamentally about simplifying the writing of policy rules… and not about solving token bloat? | 19:36 |
| gyee | ayoung, auditor has to be an effective role then | 19:37 |
| ayoung | henrynash, yes, and also simpifying role assignemnt | 19:37 |
| ayoung | and for making delegation more granular without bloat | 19:37 |
| gyee | otherwse, it will be messy, means we'll have to put role sets into the token, which is precisely what we're trying to avoid | 19:37 |
| henrynash | ayoung: eek, another concept being incuded...aaahhh | 19:37 |
| ayoung | henrynash, not another concept | 19:37 |
| openstackgerrit | Doug Hellmann proposed openstack/keystonemiddleware: Drop use of 'oslo' namespace package https://review.openstack.org/178360 | 19:37 |
| ayoung | another supporting use case | 19:37 |
| ayoung | the concept is "assing one role, get multiple effective roles" | 19:38 |
| ayoung | heh | 19:38 |
| ayoung | assign | 19:38 |
| ayoung | "assign one role, get multiple effective roles" | 19:38 |
| henrynash | yep get that concept | 19:38 |
| samueldmq | and effective roles is what goes in the token | 19:39 |
| samueldmq | as we currently do | 19:39 |
| ayoung | henrynash we actually have thngs like this in our rules where we say admin_or_owner. I would change the naming pattern so that it was just Owner | 19:39 |
| samueldmq | by expanding grouping, hierarhcies, etc | 19:39 |
| ayoung | owner implies admin | 19:39 |
| *** mestery has joined #openstack-keystone | 19:39 | |
| gyee | so we're all on the same page then? | 19:39 |
| ayoung | chop the scope matching off your rules, and just list them explicitly in the operations | 19:40 |
| gyee | seem like we are all in agreement | 19:40 |
| ayoung | so in v3ckloud sample, I would change (let me see) | 19:40 |
| samueldmq | gyee, I have this feeling all the time | 19:40 |
| samueldmq | gyee, I think the point of divergence is that ayoung wants role-sets to be passed in the token | 19:40 |
| ayoung | (note, not changing what is actuallty enforced, just the name) | 19:40 |
| henrynash | ok, so this has helped me understand the rationale….part of my objection to this is (even thoug you worked har to lay out incremental steps), is that it assumes a certin point of view os the right destination…any I have struggled to convince myslef that are exploring teh alternatives for some of those steps | 19:40 |
| gyee | samuelmq, kumbaya | 19:40 |
| samueldmq | gyee, and then used in the policy | 19:40 |
| ayoung | "admin_and_matching_target_project_domain_id": "rule:admin_required and domain_id:%(target.project.domain_id)s", | 19:41 |
| ayoung | which is used on | 19:41 |
| ayoung | "identity:update_project": "rule:cloud_admin or rule:admin_and_matching_target_project_domain_id", | 19:41 |
| ayoung | "identity:delete_project": "rule:cloud_admin or rule:admin_and_matching_target_project_domain_id", | 19:41 |
| ayoung | and one more | 19:41 |
| samueldmq | gyee, hehe | 19:41 |
| ayoung | and write those as | 19:41 |
| henrynash | I need to drop offline….the eveing is movig on her in the UK..but I can mull on his overnight now | 19:41 |
| gyee | you don't need policy files, just construct the rules and set them in oslo policy | 19:41 |
| ayoung | matching_target_project_domain_id: domain_id:%(target.project.domain_id)s | 19:41 |
| gyee | set_rules() | 19:42 |
| ayoung | and then | 19:42 |
| ayoung | "identity:delete_project": "rule:matching_target_project_domain_id and role:admin" | 19:42 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware: Remove superfluous / spammy log line https://review.openstack.org/178292 | 19:42 |
| henrynash | you mean you don’t liek that fact that my meaning names consume 99.9% of all the charcters ina polic file? | 19:42 |
| ayoung | or...today, since the role: rule doesn do hierarchy | 19:42 |
| samueldmq | gyee, the policies will be stored in keystone managed by keystone, then others services fetch their policies via keystone api | 19:42 |
| ayoung | role_admin: role:admin | 19:42 |
| ayoung | "identity:delete_project": "rule:matching_target_project_domain_id and rule:role_admin" | 19:43 |
| gyee | samueldmq, my understanding is the enforcement will be done by the new middleware | 19:43 |
| ayoung | henrynash, nah, I'm ok with that | 19:43 |
| gyee | taking security duty out of the hands of the services | 19:43 |
| ayoung | henrynash, what I want is for it to be easy to come by later and say | 19:43 |
| ayoung | "identity:delete_project": "rule:matching_target_project_domain_id and rule:role_member" | 19:43 |
| samueldmq | gyee, I also like the middleware, but the current spec defines keystoneclient | 19:43 |
| samueldmq | gyee, we need to revisit this as well | 19:43 |
| gyee | nooh, not the client | 19:43 |
| samueldmq | gyee, maybe next eeting | 19:43 |
| ayoung | what we expect is for people to tweak the roles assigned to APIs, | 19:43 |
| gyee | security 101, never trust the client | 19:44 |
| jamielennox | gyee: >.> | 19:44 |
| bknudson | that's what the cert is for. | 19:44 |
| morganfainberg | gyee: i dunno, the client could pay me lots of money and i can trust it. | 19:44 |
| gyee | damn straight! | 19:44 |
| morganfainberg | gyee: lots and lots of money, right? | 19:44 |
| ayoung | henrynash, I think that your rules for v3 are correct. I just want to make it clear for people to modify them from there on out | 19:44 |
| bknudson | bitcoins | 19:44 |
| samueldmq | hehee | 19:44 |
| morganfainberg | bknudson: YES! | 19:44 |
| henrynash | ayoung: ok..will mull on it…tahnks for clarifying…and I don’t disagree that ppolciy file wrting is, today, a bit of a black art if you wnat to avoid the admin-ness scoped issue | 19:44 |
| morganfainberg | bknudson: dogecoin? | 19:44 |
| gyee | nice | 19:44 |
| bknudson | I'll use mongodb to store by dogecoins | 19:45 |
| morganfainberg | bknudson: i hear we should have a driver that uses the blockchain to store user info | 19:45 |
| ayoung | henrynash, thanks. I won't do anything until I am sure you and I share the same vision. THis is too important. | 19:45 |
| gyee | bknudson, we are running mongo | 19:45 |
| morganfainberg | bknudson: gyee: that is how we replicate the data. commit the data to a cryptocurrency blockchain and download it at the remote site | 19:45 |
| jamielennox | gyee, samueldmq: i haven't been paying attention and only read a little bit of scrollback - but the client will be responsible for fetching the policy file from keystone, then we either enforce directly with oslo.policy or figure out some middleware piece or other to do enforcement | 19:45 |
| morganfainberg | KSCoin? | 19:46 |
| gyee | hahahaha | 19:46 |
| gyee | lmao | 19:46 |
| jamielennox | the point is that ksc is only for the CRUD operations for fetching the policy file | 19:46 |
| breton | I've just remembered | 19:46 |
| gyee | jamielennox, middleware should do that | 19:46 |
| morganfainberg | "your keystone node needs a GPU now, to mine enough coins to store your userdata" | 19:46 |
| gyee | fetch the policy and do the enforcement | 19:46 |
| samueldmq | jamielennox, so middleware uses the client | 19:46 |
| breton | we missed Alembic during the meeting in "Non-API Impacting Priorities" | 19:46 |
| breton | morganfainberg: | 19:46 |
| samueldmq | jamielennox, to get the policy and then enforce | 19:46 |
| jamielennox | gyee: middleware might instigate it - but client is where all the code to fetch it live | 19:47 |
| ayoung | jamielennox, yes | 19:47 |
| morganfainberg | breton: ah right. | 19:47 |
| gyee | services just need to register new APIs/capability with keystone, the same way we do endpoint registration | 19:47 |
| morganfainberg | breton: that one should be straightforward like the stevedore one is | 19:47 |
| jamielennox | samueldmq: right | 19:47 |
| samueldmq | jamielennox, so the middleware uses the client to fetch (and client caches) | 19:47 |
| samueldmq | jamielennox, hmm ... | 19:47 |
| ayoung | jamielennox, and we want to make the policy library flexible enough that it can get its policy from multiple locations, as it is used for more than just access control. | 19:47 |
| jamielennox | probably middleware caches | 19:47 |
| gyee | jaimelennox, oh that, yeah, you mean the CRUD, then yes | 19:47 |
| samueldmq | jamielennox, ++ | 19:47 |
| ayoung | so maybe middleware is cache management | 19:47 |
| breton | morganfainberg: yep, it is also almost ready and on review, I'll polish it for summit. There is a little change to the spec too. | 19:47 |
| samueldmq | makes sense to me | 19:48 |
| gyee | but enforcement still in middleware | 19:48 |
| samueldmq | ayoung, makes sense to me | 19:48 |
| ayoung | middleware exposes a python api that looks like the policy api, but does the following: | 19:48 |
| ayoung | 1. check for a policy file | 19:48 |
| ayoung | 2. If policy file exists, checks freshness | 19:48 |
| ayoung | 3. If either of those fail, fetch policy file | 19:48 |
| jamielennox | i'm still unsure if we can do this from middleware | 19:48 |
| ayoung | 4. call oslo.policy | 19:48 |
| gyee | you don't need "file" | 19:49 |
| gyee | you can set the rules directly | 19:49 |
| ayoung | jamielennox, ok, lets assume we can't | 19:49 |
| samueldmq | gyee, ayoung, jamielennox so for me we should clearly separate what is the dynamic part of policies (fetching them via API) from things like hierarchical roles etc (which are givning more power ... ) | 19:49 |
| gyee | just cache the rules and check for freshness | 19:49 |
| jamielennox | for the same reason that it's hard to write policy as a decorator - you really need to know the objects before you can enforce it | 19:49 |
| ayoung | we need to build those 4 steps into the oslo policy library, but provide...a callback? so it can fetch the policy from Keystone | 19:49 |
| ayoung | jamielennox, right..it has to be a python API | 19:49 |
| samueldmq | gyee, I don't think we will have a file (at least it was my udnerstanding) | 19:50 |
| ayoung | which is why I didn;t really want it in middleware | 19:50 |
| morganfainberg | breton: might be able to land it and the code at the summit | 19:50 |
| jamielennox | samueldmq: sure - i think that's a fairly easy split, for dynamic we are just talking about where policy files come from | 19:50 |
| morganfainberg | jamielennox: /me resists terrible joke about where policy files come from. | 19:50 |
| openstackgerrit | Marek Denis proposed openstack/python-keystoneclient: Deprecate auth.identity.v3.federated module https://review.openstack.org/177704 | 19:50 |
| samueldmq | jamielennox, exactly, ayoung you agree ^ ? | 19:51 |
| jamielennox | i still like the idea of a policy enforcement point, an external service that caches policy files that has an api that returns a yes/no response | 19:51 |
| ayoung | we put cache management in keystonemiddleware so that it can share the cached dir with other things like certs, and can get its Keystone client from the same place, but it has to be an API call | 19:51 |
| gyee | ayoung, you can fetch policy using the existing APIs | 19:51 |
| ayoung | jamielennox, it does have its appeal | 19:51 |
| morganfainberg | ayoung: kspolicy://<ks_endpoint>/policy | 19:52 |
| gyee | they are essentially JSON blob | 19:52 |
| ayoung | jamielennox, but that doesn't solve the problem, as you now need to fetch the object from the database, and then extact the values you are going to use for enforcing policy, before calling to the PEP | 19:52 |
| morganfainberg | ayoung: file://<local file> | 19:52 |
| jamielennox | i was looking at oslo mesaging again yesterday and i don't know any other way to reliably have a thread that can listen to notifications and handle other requests | 19:52 |
| *** openstackstatus has quit IRC | 19:52 | |
| samueldmq | ayoung, if it was to be in the keystoneclient, the calls would then be callend enforce(...) and keystone would be known as policy enforcement service | 19:52 |
| ayoung | gyee, you need a token to get policy..unless we want to drop that requirement, in which case it could be as simpkle as putting an URL in the nova config file | 19:53 |
| jamielennox | ayoung: sure you still need to fetch and save - but it becomes almost trivial in a standalone app | 19:53 |
| *** openstackstatus has joined #openstack-keystone | 19:53 | |
| *** ChanServ sets mode: +v openstackstatus | 19:53 | |
| gyee | ayoung, right, we can leveraging the existing policy CRUD | 19:53 |
| samueldmq | openstackstatus, hi | 19:53 |
| ayoung | jamielennox, on the messaging side, I would absolutely want it in process, no RPC | 19:54 |
| ayoung | fetch and cache, operate locally | 19:54 |
| jamielennox | the problem i see is are we just redesigning congress? if you assume the request call is going to involve amqp rather than dbus or whatever then we could share that message bus between all services | 19:54 |
| *** ajayaa has joined #openstack-keystone | 19:54 | |
| ayoung | jamielennox, for now, lets focus on the API servers | 19:54 |
| openstackgerrit | Marek Denis proposed openstack/python-keystoneclient: Deprecate auth.identity.v3.federated module https://review.openstack.org/177704 | 19:55 |
| jamielennox | ayoung: if we are going to have this external cache i'd prefer to ask it questions rather than fetch the policy blob from it | 19:55 |
| ayoung | we can discuss with the congress team at the summit..would love to share ideas here, and maybe the servers should be merged, but only once we have the Keystone side fully speced | 19:55 |
| ayoung | jamielennox, from the nova perspective, it will ask questions | 19:55 |
| morganfainberg | ayoung: congress is not looking to really do PEP like we do | 19:55 |
| ayoung | and...yes, we could make that a remote service | 19:55 |
| morganfainberg | ayoung: had a chat w/ sean roberts | 19:56 |
| morganfainberg | it's just not what thye are really in | 19:56 |
| ayoung | the tricky part, as I see it, is fetching the policy file if the API is protected...maybe we predicate this on tokenless operations? | 19:56 |
| morganfainberg | they are looking at ACLs / compliance (not RBAC) for resources | 19:56 |
| jamielennox | morganfainberg: they are much higher level - but i've never seen a good definition of where congress wants to draw the line | 19:56 |
| jamielennox | neutron has it's own policy engine thingy now as well | 19:56 |
| *** samueldmq_ has quit IRC | 19:56 | |
| morganfainberg | ayoung: so we don't have anything to talk about on this front w/ congress | 19:56 |
| morganfainberg | jamielennox: exactly | 19:56 |
| jamielennox | again - not quite policy like we're talking about, but something something policy | 19:56 |
| morganfainberg | jamielennox: and neutron's isn't RBAC policy | 19:57 |
| morganfainberg | different concern | 19:57 |
| ayoung | ours is specifically Access control. THe term policy menas differnt thngs in differnt context, but usually in Congress terms it involves placement of resources | 19:57 |
| morganfainberg | ayoung: they are way outside the scope of what we're working on here fwiw | 19:57 |
| morganfainberg | based on my last couple convos | 19:57 |
| samueldmq | morganfainberg, ++ finding unexpected/inconsistent states in a cloud | 19:57 |
| gyee | Ca ca ca congress?!!! | 19:57 |
| morganfainberg | they really are compliance for a ruleset | 19:57 |
| ayoung | morganfainberg, that is why I specifically had "Access COntrol" in my talk's title | 19:58 |
| morganfainberg | not access controll | 19:58 |
| ayoung | but I still expect at least once question about Congress | 19:58 |
| morganfainberg | ayoung: yes. i was just saying we don't really have much to talk about re: congress at the summit | 19:58 |
| ayoung | thinking that slide 0, will just be | 19:58 |
| ayoung | "THIS IS NOT ABOUT CONGRESS" | 19:58 |
| gyee | heh | 19:58 |
| raildo | ++ | 19:58 |
| jamielennox | ayoung: then give a few minutes for people to leave | 19:58 |
| morganfainberg | ayoung: hehe | 19:58 |
| *** geoffarnold has quit IRC | 19:59 | |
| *** gyee has quit IRC | 20:00 | |
| samueldmq | ayoung, so can I split the 'hierarchical roles and such' form the dynamic policy spec | 20:00 |
| samueldmq | ? | 20:00 |
| ayoung | samueldmq, nope | 20:00 |
| ayoung | its is the heart of it | 20:00 |
| ayoung | dynamic is the overview | 20:01 |
| samueldmq | ayoung, they're not about dynamic policy | 20:01 |
| ayoung | hier has its own spec | 20:01 |
| ayoung | samueldmq, it is a prereq | 20:01 |
| samueldmq | ayoung, I see dynamic as being the away we fetch the policy etc | 20:01 |
| ayoung | samueldmq, nope | 20:01 |
| samueldmq | ayoung, nothing to do with the power of roles, etc | 20:01 |
| ayoung | not *just* | 20:01 |
| ayoung | its about making policy dynamic for the openstack deployemtn | 20:01 |
| ayoung | and policy is Access Control | 20:02 |
| ayoung | just making the files easier to distribute buys us nothing. We could do that with puppet | 20:02 |
| ayoung | it only means something when the changes on the server have a channel to affect change in enforcement | 20:02 |
| samueldmq | modify the policy rules via the api ? | 20:03 |
| ayoung | and the biggest change I expect to see is the role used to provide access to an API | 20:03 |
| samueldmq | that's still not about hierarhcicla roles | 20:03 |
| samueldmq | hmm, I will keep making the changes, but maybe there are thigns that are not clear | 20:03 |
| *** iamjarvo has quit IRC | 20:03 | |
| samueldmq | I share this thinkign on what's dynamic policy with jamielennox and henrynash | 20:04 |
| ayoung | hierarchical roles will be used to generate policy files | 20:04 |
| samueldmq | they both agreed with me | 20:04 |
| samueldmq | I am not saying you're wrong, but we need to say what dynamic policy exactly is then .. | 20:04 |
| ayoung | ioram's code will read the roles table to generate a portion of the policy file | 20:04 |
| ayoung | I laid it out in the overview | 20:04 |
| ayoung | that is why that is an overview spec. | 20:05 |
| ayoung | ties ll the related specs together | 20:05 |
| * ayoung needs to write his presentation | 20:05 | |
| ayoung | ok..meeting time | 20:05 |
| *** ayoung is now known as ayoung-mtg | 20:05 | |
| *** _cjones_ has joined #openstack-keystone | 20:05 | |
| samueldmq | k but dynamic policy looks to be just the fetching etc, I still think we are mixing things | 20:06 |
| samueldmq | I think we should make the concepts standing by themselves, but ok maybe just the name dynamic policy | 20:07 |
| samueldmq | could be superpolicy improvement, in the overview :p | 20:07 |
| openstackgerrit | Marek Denis proposed openstack/python-keystoneclient: Deprecate auth.identity.v3.federated module https://review.openstack.org/177704 | 20:07 |
| openstackgerrit | Marek Denis proposed openstack/python-keystoneclient: Add docstrings for ``protocol`` parameter https://review.openstack.org/177303 | 20:08 |
| *** iamjarvo has joined #openstack-keystone | 20:12 | |
| *** _cjones_ has quit IRC | 20:14 | |
| *** joesavak has joined #openstack-keystone | 20:17 | |
| *** e0ne has quit IRC | 20:17 | |
| *** samleon has joined #openstack-keystone | 20:18 | |
| *** amakarov is now known as amakarov_away | 20:18 | |
| openstackgerrit | Marek Denis proposed openstack/python-keystoneclient: Add docstrings for ``protocol`` parameter https://review.openstack.org/177303 | 20:19 |
| *** markvoelker has quit IRC | 20:20 | |
| *** markvoelker has joined #openstack-keystone | 20:21 | |
| stevemar | morganfainberg, what's this keystoneauth you are asking for? | 20:21 |
| morganfainberg | stevemar: session, catalog parsing, access info, discovery. | 20:24 |
| jamielennox | stevemar: it's the base auth stuff that all clients need - so session, adapter, auth plugins, discovery | 20:24 |
| stevemar | jamielennox, morganfainberg neat | 20:25 |
| stevemar | so the other clients can just used that, instead of importing all of ksc | 20:25 |
| *** _cjones_ has joined #openstack-keystone | 20:25 | |
| *** markvoelker has quit IRC | 20:25 | |
| morganfainberg | Yep. | 20:25 |
| *** ajayaa has quit IRC | 20:26 | |
| stevemar | would most people also import both then? | 20:26 |
| stevemar | presumably someone would want access to the apis too? | 20:26 |
| jamielennox | stevemar: no, what remains in ksc will be mostly the CRUD | 20:26 |
| jamielennox | it makes ksc like most other clients, just a way to access the crud rest apis | 20:27 |
| jamielennox | ksa will be all the other clients require - obviously horizon, osc etc will still need ksc | 20:27 |
| stevemar | jamielennox, i guess most authenticated users won't care for keystone CRUD? | 20:27 |
| stevemar | yeah | 20:27 |
| stevemar | i think that was warping my thinking | 20:27 |
| stevemar | since osc will still need both | 20:28 |
| *** itlinux has joined #openstack-keystone | 20:28 | |
| stevemar | but i guess nova/glance wouldn't need ksc at that point | 20:28 |
| *** samueldmq has quit IRC | 20:29 | |
| bknudson | the *clients won't need ksc. | 20:30 |
| stevemar | yeah | 20:32 |
| *** samueldmq_ has joined #openstack-keystone | 20:34 | |
| *** e0ne has joined #openstack-keystone | 20:36 | |
| *** joesavak has quit IRC | 20:37 | |
| *** pnavarro has quit IRC | 20:38 | |
| *** e0ne has quit IRC | 20:39 | |
| *** samueldmq_ has quit IRC | 20:47 | |
| *** zigo_ is now known as zigo | 20:50 | |
| *** markvoelker has joined #openstack-keystone | 20:51 | |
| *** harlowja_ has quit IRC | 20:55 | |
| *** raildo has quit IRC | 20:55 | |
| *** markvoelker has quit IRC | 20:56 | |
| *** iamjarvo has quit IRC | 20:57 | |
| openstackgerrit | Merged openstack/keystonemiddleware: Port keystonemiddleware to Python 3 https://review.openstack.org/177701 | 21:00 |
| *** jaosorior has quit IRC | 21:02 | |
| *** gyee has joined #openstack-keystone | 21:02 | |
| *** ChanServ sets mode: +v gyee | 21:02 | |
| *** lhcheng_ has joined #openstack-keystone | 21:06 | |
| *** lhcheng has quit IRC | 21:07 | |
| *** gyee has quit IRC | 21:11 | |
| *** gyee has joined #openstack-keystone | 21:14 | |
| *** ChanServ sets mode: +v gyee | 21:14 | |
| *** _cjones_ has quit IRC | 21:15 | |
| *** _cjones_ has joined #openstack-keystone | 21:19 | |
| *** ioram has quit IRC | 21:24 | |
| *** henrynash has quit IRC | 21:25 | |
| *** iamjarvo has joined #openstack-keystone | 21:26 | |
| *** iamjarvo has quit IRC | 21:26 | |
| *** _cjones_ has quit IRC | 21:26 | |
| *** henrynash has joined #openstack-keystone | 21:26 | |
| *** ChanServ sets mode: +v henrynash | 21:26 | |
| *** iamjarvo has joined #openstack-keystone | 21:27 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/178414 | 21:37 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/178415 | 21:37 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/oslo.policy: Updated from global requirements https://review.openstack.org/178424 | 21:42 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/pycadf: Updated from global requirements https://review.openstack.org/178425 | 21:42 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/178426 | 21:42 |
| *** henrynash has quit IRC | 21:46 | |
| stevemar | dhellmann, could you kick off this guy? https://review.openstack.org/#/c/168187/ | 21:46 |
| *** markvoelker has joined #openstack-keystone | 21:52 | |
| *** markvoelker has quit IRC | 21:56 | |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Use stevedore for backend drivers https://review.openstack.org/166543 | 22:04 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Use short names for drivers https://review.openstack.org/166622 | 22:04 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Tests enforce use of stevedore loading https://review.openstack.org/171854 | 22:04 |
| *** harlowja has joined #openstack-keystone | 22:04 | |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Update sample config file https://review.openstack.org/171860 | 22:15 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Remove unnecessary oauth_api check https://review.openstack.org/177603 | 22:16 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: De-duplicate auth methods https://review.openstack.org/177604 | 22:16 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Use [] where a value is required https://review.openstack.org/171907 | 22:16 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Remove support for loading auth plugin by class https://review.openstack.org/171906 | 22:16 |
| *** bknudson has quit IRC | 22:19 | |
| *** iamjarvo has quit IRC | 22:21 | |
| *** _cjones_ has joined #openstack-keystone | 22:22 | |
| *** gordc has quit IRC | 22:23 | |
| *** Rockyg has quit IRC | 22:27 | |
| *** nkinder has quit IRC | 22:29 | |
| *** iamjarvo has joined #openstack-keystone | 22:32 | |
| *** stevemar has quit IRC | 22:35 | |
| *** ericksonfgds has joined #openstack-keystone | 22:46 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 22:46 | |
| *** markvoelker has joined #openstack-keystone | 22:52 | |
| *** markvoelker has quit IRC | 22:57 | |
| *** Ephur has quit IRC | 22:59 | |
| *** browne has quit IRC | 23:00 | |
| *** browne has joined #openstack-keystone | 23:01 | |
| *** ericksonfgds has quit IRC | 23:15 | |
| *** ayoung-mtg has quit IRC | 23:21 | |
| *** bknudson has joined #openstack-keystone | 23:27 | |
| *** ChanServ sets mode: +v bknudson | 23:27 | |
| *** dims_ has joined #openstack-keystone | 23:29 | |
| *** josecastroleon has joined #openstack-keystone | 23:29 | |
| *** dims has quit IRC | 23:31 | |
| *** josecastroleon has quit IRC | 23:34 | |
| *** lsmola_ has joined #openstack-keystone | 23:38 | |
| *** lsmola__ has quit IRC | 23:40 | |
| *** lsmola_ has quit IRC | 23:45 | |
| *** _cjones_ has quit IRC | 23:52 | |
| *** iamjarvo has quit IRC | 23:56 | |
| *** markvoelker has joined #openstack-keystone | 23:58 | |
| *** lsmola_ has joined #openstack-keystone | 23:58 | |
| *** _cjones_ has joined #openstack-keystone | 23:59 | |
| *** _cjones_ has quit IRC | 23:59 | |
| *** drjones has joined #openstack-keystone | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!