Tuesday, 2015-06-16

*** csoukup has quit IRC00:00
*** HT_sergio has joined #openstack-keystone00:03
*** mtecer has joined #openstack-keystone00:06
*** zzzeek has quit IRC00:07
*** browne has quit IRC00:08
*** ncoghlan has joined #openstack-keystone00:09
*** ncoghlan has quit IRC00:18
*** stevemar has joined #openstack-keystone00:18
*** ChanServ sets mode: +v stevemar00:18
*** geoffarnold has quit IRC00:21
*** david-lyle has quit IRC00:24
*** charlesw has joined #openstack-keystone00:27
*** dims has quit IRC00:33
*** kfox1111 has quit IRC00:34
*** _cjones_ has quit IRC00:37
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Remove confusing deprecation comment  https://review.openstack.org/19150900:39
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Proper deprecations  https://review.openstack.org/19151100:39
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Remove confusing deprecation comment from token_to_cms  https://review.openstack.org/19151000:39
stevemarjamielennox, i'm excited to see what happens to your devstack patches00:39
jamielennoxstevemar: i really hope they work - it took me 2 weeks to get all the release stuff coordinated and i really hope i didn't miss anything00:40
* stevemar shrugs to jamielennox, 00:40
stevemarlet's sit and watch zuul00:40
* lbragstad pulls a chair up next to stevemar00:40
* stevemar hands lbragstad some popcorn00:41
jamielennoxi did that one early so i could go for a run and see what happens when i get back00:41
* lbragstad loves popcorn00:41
jamielennoxthen again - it's getting really cosy in here00:41
stevemarjamielennox, run away00:41
lbragstadjamielennox: running?! training for anything?00:41
jamielennoxlbragstad: no, i was fit there for a while and then did a few injuries, it got cold, blah, blah, blah00:45
jamielennoxjust trying to get back into it again00:45
bknudsonhow cold did it get?00:46
*** dims has joined #openstack-keystone00:46
jamielennoxgoogle says it's 13 now, that's 55 for everyone else00:46
bknudsonperfect for jogging00:47
jamielennoxsydney was worse, but not like it's going to impress anyone with how cold it gets here00:47
bknudsonI suppose it's winter there... another reason to go to the meetup.00:48
stevemarjamielennox, looks like you've got a bashate error somewhere00:52
bknudsonjamielennox: https://review.openstack.org/#/c/191511/2/keystoneclient/v2_0/client.py -- what does this comment mean?00:52
stevemarbut otherwise i think it's going well00:52
lbragstadjamielennox: nice, that's perfect jogging weather00:52
bknudsondoes it mean going into the if leg is deprecated or not going into the if leg is deprecated?00:53
*** dguerri is now known as dguerri`00:59
lbragstadis it db2 ci discussion time yet? cc stevemar bknudson morganfainberg00:59
stevemarlbragstad, o yeah01:01
bknudsonI hope yanfengxi shows up.01:01
bknudsonI can try to answer any questions but as has been shown I'm not too familiar with the setup.01:02
stevemarbknudson, give him a few minutes, he's only just starting his morning :P01:02
openstackgerritMerged openstack/keystonemiddleware: Ensure cache keys are a known/fixed length  https://review.openstack.org/18697101:03
*** yanfengxi_ has joined #openstack-keystone01:04
yanfengxi_Hi, everyone01:04
bknudsonyanfengxi_: hi01:05
yanfengxi_I am here bother you minutes, to talk about DB2 CI enablement.01:05
bknudsonlbragstad: morganfainberg stevemar -- ready to get started?01:05
bknudsondolphm: ayoung , etc01:05
ayoungbknudson, the number you have reached has been disconnected01:06
ayoungbknudson, if you feel you have reached this recording in error, please hang up and try your call again01:06
lbragstadyanfengxi_: from the wiki page here https://wiki.openstack.org/wiki/IBM/IBM_DB2_CI01:07
lbragstad"The DB2 third party CI is being transitioned to the US due to issues with firewall restrictions in China."01:07
lbragstadthis just means that the infrastructure lives in the US, but it is still maintained by counterparts in China, right?01:07
ayounglbragstad, I still don't get why you are doing this, but ok01:07
lbragstadayoung: several people had questions01:08
yanfengxi_Please ask01:08
stevemaryanfengxi_, do we know if the py27 tests pass now? with a db2 backend?01:08
lbragstadyanfengxi_: I think stevemar asking the keystone meeting if there was a way for us to tell if it was stable prior to flipping the switch01:08
stevemarlbragstad, yes01:09
bknudsonstevemar: I don't know if you can do live testing at all?01:09
bknudsonI haven't tried it for a while... should try it again sometime.01:09
lbragstadaccording to the wiki page there isn't any skipped tests it looks like01:09
ayounglbragstad, why is IBM pushing integration with a prioprietary database when they don't plan on supporting upstream openstack, only their own particular release of it?  What is in it for either side?  I mean, I get that they will idenitify problems before they hit their distro, but, still, seems like more work than it is worth.01:09
bknudsonlbragstad: there are very few tests that are run, only the identity tests.01:10
yanfengxi_stevemar_, yes, it passes py2701:10
stevemaryanfengxi_, cool, then i'm all for it01:10
ayoungDon't get me wrong, I love having another datapoint for making sure our DB code is not MySQL specific01:10
yanfengxi_because all are ci environment is based on py2701:10
stevemaras long as it work now, i'm happy with that01:10
stevemaryanfengxi_, what versions of db2 are you guys testing? multiple versions or just 1?01:11
ayoungBut I expect exactly 0 people that are not IBM customers are running DB2 with OpenStack in production.  Am I wrong?01:11
bknudsonayoung: we support upstream openstack01:11
stevemarayoung, same argument can be said for any 3rd party CI (cinder or not)01:11
yanfengxi_just one01:11
stevemarayoung, and it doesn't cost us anything01:12
*** geoffarnold has joined #openstack-keystone01:12
ayoungstevemar, there is a difference, but, sure.01:12
ayoungCinder is more "we bought this hardware, we need to integrate with it"01:12
lbragstadyanfengxi_: do you notice specific failures with certain tests or it is transient?01:12
ayoungchosing a Database is a little different01:12
stevemarayoung, it's handy to have it publicized i suppose01:12
ayoungI mean, personally, I like DB2 more than MySQL.01:12
ayoungGBut that might be "damned by faint praise"01:12
stevemari'm not involved with this at all, i just think its worth the effort01:13
yanfengxi_lbragstad_: the failures may caused by environment issue, patch code common issue, and mostly important, db2 issue.01:13
bknudsonshows what tests are actually run01:13
stevemarbknudson, that's just tempest tests01:14
stevemarnot keystone tests01:14
bknudsononly tempest is run01:14
yanfengxi_we only run tempest01:14
lbragstadyanfengxi_: in your note, you said you noticed about an 88% failure rate?01:14
*** geoffarnold has quit IRC01:14
stevemarokay - i was reading this as running the keystone unit tests01:14
openstackgerritMerged openstack/keystone: Pass environment variables of proxy to tox  https://review.openstack.org/19160201:15
ayoungstevemar, you guys going to replace Rabbit MQ with MQ Series, too?01:15
bknudsonthere aren't unit tests running for any database now as far as I know01:15
yanfengxi_not ut, only tempests are ran01:15
stevemarbknudson, huh? whatever, the functional tests we have (post moving them around)01:15
bknudsonstevemar: the only functional testing that's done is tempest now.01:16
stevemarI want these run01:16
stevemari want 5000+ tests, not 12001:16
stevemarwhat the heck does 120 buy us01:16
stevemarwhatever, 15001:16
bknudsonstevemar: the functional tests aren't run at all yet.01:16
openstackgerritMerged openstack/keystone: Refactor: move PKI-specific tests into the appropriate class  https://review.openstack.org/19187301:17
lbragstadyanfengxi_: do you know what the avg failure rate is for tempest runs?01:17
stevemarwhats the hold up on that?01:17
stevemarwe can have this an initial step, i guess01:17
bknudsonstevemar: https://review.openstack.org/#/c/139137/01:17
bknudsonwhich is blocked by https://review.openstack.org/#/c/151310/7 at this point01:17
bknudsonstevemar: you -1d it01:18
yanfengxi_lbragstad_: in most of the CI running, the tempoest failure rate is 0%.01:18
stevemarbknudson, there's no way we can just devstack things with a db2 backend and run tox -e py27 under keystone?01:18
bknudsonI don't think the live tests for any database run all 5k tests.01:18
bknudsonstevemar: It might be possible.01:19
*** tobe has joined #openstack-keystone01:19
stevemarbknudson, you are also -1'ing that patch01:19
bknudsony, but I -1 everything01:19
bknudsonpeople have learned to ignore it01:19
lbragstadyanfengxi_: I'm just trying to gauge the frequency of runs that will happen and fail but not fail because of the proposed change01:19
yanfengxi_Just curious, unit tests are testing on code logic. do unit tests has any neccessary on db backend?01:20
*** sigmavirus24 is now known as sigmavirus24_awa01:20
bknudsonthe unit tests validate a lot more than the tempest tests01:20
bknudsonthe tempest tests are only supposed to be for cross-project testing01:20
bknudsonso there really should be no identity tempest tests01:20
stevemaryanfengxi_, bknudson there are entire branches of things that are not being tested01:21
stevemarso tempest doesn't test any of our extension right?01:21
bknudsonstevemar: I agree the tempest tests don't cover much.01:21
bknudsonone thing they do cover, of course, is keystone-manage db-sync01:21
yanfengxi_lbragstad_: if the CI fails because of non-patch-related reasons, we will try to recheck it, until it succeeds.01:21
*** tqtran has quit IRC01:22
stevemarif our extensions are doing something in a backend via sqlalchemy that isn't supported by db2 we won't know01:22
bknudsonand they must be getting tokens and stuff.01:22
bknudsonat least all the extensions are now having their migrations run01:22
stevemarbknudson, thats true01:22
bknudsonthat's typically where the issues are anyways.01:23
lbragstadyanfengxi_: and so if the patch succeeds, it will leave a comment, and if it doesn't it just won't say anything?01:23
yanfengxi_Yes, if it fails, we will leave a comment of failure, as every CI does.01:24
lbragstadyanfengxi_: but it's not voting,01:24
yanfengxi_yes, it's none-voting01:24
yanfengxi_should only voting CIs give failure comments?01:25
lbragstadyanfengxi_: I don't know what policy is, which is why I asked,01:25
lbragstadbut it does look bad from a reviewers perspective because it will deter people from reviewing the patch if it has a downvote01:26
bknudsonif it doesn't -1 on failures it's going to be hard for me to find any changes that break db2.01:26
bknudsonvs changes that db2 didn't report on for whatever reason01:26
lbragstadit's hard for a committer to fix something they don't have access to dev on01:26
yanfengxi_This is an example, of what will none-voting CIs do01:26
bknudsonDB2 Express-C is free to download01:27
yanfengxi_They will give failure comments, but will not -1, and will not hold off the patch merging01:27
bknudsonyou can see in cinder they have external CI reporting failures all over the place01:28
bknudsonI think they've gotten used to it.01:28
bknudsonnot that I want us to get used to it01:28
lbragstadthen it's pointless01:28
stevemaralright, i'm for this, i'd prefer it to be as less noisy as possible01:28
yanfengxi_Do you think the failures are nosy?01:29
yanfengxi_and the successful message are beautiful?01:29
bknudsonIf it's failing for any reason other than the code breaks db2 then it's noise.01:29
yanfengxi_yes, that's true01:30
bknudsonand since we rarely change code that affects the db then there should be approximately 0 failures.01:30
yanfengxi_But we will recheck the ci until the nosy failures are gone.01:30
lbragstadand if it doesn't break db2, but db2 doesn't pass it, then if it does leave a -1 other reviewers are less reluctant to review the patch because they think the committer still has work to do01:30
lbragstadbknudson: ++ and that code is usually heavily reviewed01:31
yanfengxi_And in our history tests recently, this kind of failures are becomming less, because we move our CI slaves onto a reliable Could.01:31
openstackgerritMerged openstack/keystone: Needn't load fernet keys twice  https://review.openstack.org/19160801:31
lbragstadyanfengxi_: did you notice the 88% before or after the migration?01:32
lbragstadjust curious01:32
yanfengxi_and environment reason is a small part of it.01:33
lbragstadyanfengxi_: yeah, that's understandable01:33
yanfengxi_Most of them are because of patch common failures which alfo fails jenkins, and other CIs.01:33
yanfengxi_and some others are DB2 related.01:33
openstackgerritDavanum Srinivas (dims) proposed openstack/keystonemiddleware: Remove install_venv_common and fix typo in memorycache  https://review.openstack.org/18911301:34
openstackgerritDavanum Srinivas (dims) proposed openstack/python-keystoneclient: Remove unnecessary install_venv_common module  https://review.openstack.org/18912301:35
yanfengxi_If it fails for environment reason,  we will recheck it, until it shows happy news.01:35
bknudsonyou're going to be awake all day rechecking changes? or this is automatic?01:35
lbragstadyanfengxi_: is there a way for us to know if it broke because of an environment reason or if the patch actually broke db2?01:35
yanfengxi_88% is the successful rate, failure rate is 12%.01:35
bknudsonI don't think anyone's going to be happy with a 12% failure rate.01:36
yanfengxi_looking at the logs. And the rechecking work will be done by DB2 CI maintainers, not developers themselves.01:36
bknudsonyou're promising to be awake 24 hours a day?01:37
*** browne has joined #openstack-keystone01:37
yanfengxi_No, 8+ hours in my time. If it fails during other time, I will handle it in my time next day.01:38
yanfengxi_Is this accepptable?01:38
bknudsonI don't want things to be broken for 16 hours.01:38
bknudsonif it had a 1% failure rate maybe that would be ok, but it's 12%, so there are going to be failures every day.01:39
yanfengxi_OK, actually, our resources managers are seeking some guys to co-work with me later.01:39
yanfengxi_Some US guys01:40
yanfengxi_But it still needs time.01:40
morganfainbergbknudson, yanfengxi_: so I have a question... Is this for db2 internal knowledge or because we expect upstream to work with db2? Because frankly I don't want to use 3rd party ci as a marketing driver for "we are 100% tested upstream"01:40
*** gyee_ has quit IRC01:40
bknudsonupstream works with db2.01:40
yanfengxi_bknudson, do you know have any CIs that only have 1% failure rate01:40
bknudsonwe don't have any changes internally to keystone to make it work with db201:41
bknudsonyanfengxi_: I don't know the stats for any CIs.01:41
lifelessyanfengxi_: openstackCI :)01:42
lifelessyanfengxi_: when it gets up things fall over VERY VERY fast at scale01:42
lbragstadlifeless: ++01:42
yanfengxi_As I know, there are no such CIs. The failures could because of many reasons.01:42
yanfengxi_lifeless_: of cause, the community jenkins01:43
*** lhcheng has quit IRC01:43
yanfengxi_As this patch shows, many CI fails even if jenkins works.01:44
lbragstadbut that's not always a good thing, since it can be out of the developers hands to fix it.01:45
bknudsonin that patch, jenkins didn't really work, since check-tempest-dsvm-full-sheepdog-nv and check-tempest-dsvm-full-drbd-devstack-nv failed although for some reason developers don't care.01:45
stevemarjamielennox, fix yo bashate!01:46
jamielennoxstevemar: just looking now01:46
*** kiran-r has joined #openstack-keystone01:47
openstackgerritDave Chen proposed openstack/keystone-specs: Use oslo-versioned-objects to deal with upgrades  https://review.openstack.org/16719501:47
stevemarjamielennox, in lib/swift !!01:47
jamielennoxstevemar: i've fixed this same issue a couple of times, must have got lost in a rebase01:47
jamielennoxstevemar: swift failures :(01:48
stevemarjamielennox, i was just going to say...01:48
stevemarUnauthorized. Check username/id, password, tenant name/id and user/tenant domain name/id01:49
jamielennoxstevemar: i don't see why though - i specifically didn't change anything about v2 auth01:49
jamielennoxkeystoneclient.auth.identity.v3.base: DEBUG: Making authentication request to
jamielennoxwho told swift to do that?01:50
*** dims has quit IRC01:50
*** yanfengxi_ has quit IRC01:52
*** yanfengxi has joined #openstack-keystone01:53
yanfengxibknudson_: Hi, here are some examples where DB2 CI works, but many other CIs fails:01:55
stevemarjamielennox, looks like the functional tests told them to do that01:55
stevemarif tf.skip or tf.skip2 or tf.skip_if_not_v3:01:55
stevemar            raise SkipTest('AUTH VERSION 3 SPECIFIC TEST')01:55
yanfengxihttps://review.openstack.org/#/c/163647/ https://review.openstack.org/#/c/190579/ https://review.openstack.org/#/c/191209/01:55
yanfengxiI just want to say, CI failures are normal, but it's important for CI maintainers to handle the unacceptable publish in time.01:56
yanfengxiIf there are no body handle them, it's indeed really nosy.01:57
jamielennoxstevemar: it passed in the first patch: http://logs.openstack.org/78/186678/4/check/check-swift-dsvm-functional/2ab21b1/console.html#_2015-06-16_00_59_00_469 so it's not that it only just realized v3 was available01:58
stevemarjamielennox, and the remaining failed tests have the same flag: https://github.com/openstack/swift/blob/0a1a447b0198c3192810ab45b32fa41a27bd22bd/test/functional/test_container.py#L1562-L156301:58
stevemarjamielennox, fix the bash8 problem and it'll magically resolve itself01:59
jamielennoxstevemar: pushed01:59
lbragstadyanfengxi: so, if db2 ci fails on my patch do I just recheck it and ping you?02:01
yanfengxilbragstad_: if it fails because of environment reason, you can recheck it. If it's because of common issues or db2 related, it's not neccesary.02:02
lbragstadyou mean a recheck it's necessary?02:03
jamielennoxstevemar: http://logs.openstack.org/80/186680/6/check/check-swift-dsvm-functional/aa549c0/logs/apache/keystone.txt.gz#_2015-06-16_01_00_44_95095102:04
stevemarjamielennox, context?02:04
jamielennoxstevemar: no idea, but i'm guessing that's causing the failure02:05
jamielennoxstevemar: doh - yea, it's my fault02:05
yanfengxilbragstad_: no, I didn't mean that. I mean, it's better to let our CI maintainers to do this for you.02:06
*** charlesw has quit IRC02:06
yanfengxiBecause we have more experience on the failure judgement02:06
jamielennoxstevemar: https://review.openstack.org/#/c/186680/7..8/lib/swift02:07
stevemarjamielennox, what hppned?02:07
jamielennoxat least it's a simple fix02:07
*** david-lyle has joined #openstack-keystone02:08
morganfainbergyanfengxi bknudson: so if the judgement on failure is not something a developer cares about, and is something your ci/internal team manages, is there a reason reporting to upstream is worth it?02:09
lbragstadyanfengxi: I agree, I just don't really know why it would have to be reporting back to the upstream patch then.02:09
morganfainbergIt could just as well send an email to internal teams at IBM.02:09
morganfainbergDeveloper in this case = someone like me not affiliated with IBM or strictly upstream.02:10
bknudsonmorganfainberg: I think the problem is we can't tell if it's our problem or not?02:10
bknudsonbut you're correct, if there was a way to tell this was an internal issue vs external one then external reporting is not useful02:11
lbragstadeven if it is an external issue, it's still really hard for the external developer working for another company to fix it02:11
yanfengxibknudson_: yes, agree. I don't think developers could tell the error is about DB202:11
morganfainbergbknudson: the question is, will $upstream_developer be able to know what is going on and or fix it?02:11
yanfengxior it's an environment issue.02:11
morganfainbergOr even really care.02:12
*** kiran-r has quit IRC02:12
bknudsonI hope that developers will care if they make a change that breaks db2.02:12
bknudsonWith the DB2 CI not reporting I've been commenting on reviews that would have broken db202:12
bknudsonthere was a migration recently added that didn't work on db202:13
yanfengxithe db2 ci is to detect patches that breaks db2.02:13
lbragstadyanfengxi: it sounds like you guys have that..02:13
bknudsontypically the issue will show up as a failure in keystone-migrate db_sync phase02:14
bknudsonkeystone-manage db_sync02:14
yanfengxilbragstad_: have what?02:14
lbragstadyanfengxi: detection if a patch incompatible with db202:14
yanfengxibknudson_: agree, that's the point02:14
morganfainbergbknudson: is there value in more than db_sync then?02:15
bknudsonif that happens I can look into the issue... or if a developer wants to install DB2 Express-C for free and figure it out themselves...02:15
lbragstadbut is that what runs in the ci?02:15
bknudsonmorganfainberg: I like that the tests are getting tokens and validating more than just db_sync.02:16
yanfengxilbragstad_: Yes, will long time working on this, we could rapidly judge what kind of failure we have.02:16
morganfainbergbknudson: so, my concern is this *feels* like a marketing ploy from IBM. not saying it is.02:16
morganfainbergIt feels like the same concept of "I want to 3rd party ci test my wacky proprietary Python interpreter" to say it works.02:16
morganfainbergI'm just trying to make sure it isn't that.02:17
bknudsonthere's lots of 3rd party CI working against cinder, for example.02:17
bknudsonand neutron02:17
bknudsonand nova02:17
morganfainbergAnd my biggest concern is getting a care about db2 from unaffiliated folks.02:17
morganfainbergHaving to download and install db2 express is a high barrier to "fix" things.02:18
lbragstadI've never heard of db2 express,02:18
bknudsonit's not super-easy to install db2 express-C... you'll have to agree to a license that you may not be allowed to.02:19
morganfainbergAs far as I knew there was no way to debug db2 directly until just now.02:19
lbragstadbut we do see some behavior different between mysql and sqlite02:19
lbragstadwould it be a situation like that?02:19
morganfainbergbknudson: that is a dealbreaker unless IBM is dealing with the failures 100% of the time or that is changed.02:19
morganfainbergI can't ask everyone to agree to licenses to debug things.02:20
morganfainbergMySQL and SQLite are easy to install and don't require extra licenses to debug issues here.02:20
bknudsonup to now I've been dealing with them.02:21
morganfainbergSo you see my concern though. We're blocking changes based upon a proprietary db that cannot be debugged by a developer. So you and stevemar are basically on the hook for it every time.02:22
yanfengxibknudson_: I don't think community developers needs to verify the failures themselves. IBM guys could help out.02:22
lbragstadright, it's on the IBM guys, which doesn't necessarily make sense to have it report to upstream developers if you have a solid notification framework in place internally02:23
bknudsony, and I can't promise to always be available either... I'm often told to work on other things.02:23
morganfainbergI don't know how this works with cinder and neutron. It is why 3rd party ci exists but if there isn't active eyes consistently on it I don't want to be blocking things because of it.02:24
lbragstadyou'd still know if a patch breaks db2 at the same point in time, regardless if it's reporting upstream or not02:24
bknudsonmorganfainberg: maybe a question for the mailing list or x-project meeting?02:24
morganfainbergThe difference is, I think, a significant vested interest in keeping the 3rd party stuff looked at in the other projects.02:24
bknudsonI have a vested interest in having this work.02:25
bknudsonbecause when it breaks I get a defect that I have to fix.02:25
morganfainbergBecause it is their product. This feels like pushing it onto non IBM developers without that same investment. It isn't you it's more than a single person should be on it.02:25
morganfainbergIf it is only you, and your time is split all over (which it is) this feels like a non-investment from IBM. I am not questioning you at all. You're good. It's the broader interest.02:26
davechenstevemar, jamielennox: Does `ec2 credentials create` got merged in the OSC? or KS?02:26
bknudsonI'm not the only person here that can work on db2 issues... we've got ibmers working on nova, cinder, heat, etc.02:26
stevemardavechen, yep, it's in 1.4.0 release02:27
stevemarjamielennox, whats up with https://review.openstack.org/#/c/186684/02:27
yanfengxiIf one patch breaks db2, failure will not -1, and will not hold back the merging.02:27
morganfainbergSo, I'm ok with trying a report (non-vote) but if it gets backed up / not looked at I'm going to call it noise.02:27
davechenstevemar, jamielennox: Does that mean create ec2 credential will not be supported by `credentials create` in the near future?02:27
morganfainbergAnd we will ask that it stop reporting.02:27
stevemardavechen, we could still support it there too02:27
yanfengxiwe will have a bug internally tacking it. If our IBM guys can help out in time, it's fine. If can't, they can commit fix later after the code merged.02:27
morganfainbergyanfengxi: that is just noise then.02:28
stevemardavechen, we want `os credentials create` to use the /credentials API02:28
davechenstevemar, jamielennox: :-) this sounds good.02:28
lbragstadnon of that involves the upstream developer02:28
morganfainbergyanfengxi: then just send the email internally and fix it later yourself. See what I'm driving at? I don't want it to just be broken for a window of time because no one can look at it.02:28
morganfainbergFrom IBM.02:28
yanfengximorganfainberg_: what I talked about is failures that breaks db2.02:29
davechenstevemar, jamielennox: is that what we are doing now, credentials create once not use /credentials API?02:29
stevemardavechen, right now, if you call `os ec2 credentials create` it'll call /v3/OS-EC2... we don't advertise that extension ... https://github.com/openstack/keystone/blob/675a1cff0c007f749cf4a1fe6dc30d209bdbc179/keystone/contrib/ec2/routers.py#L6402:29
davechenstevemar: great! lets me take a look at the code.02:30
morganfainbergI don't know how to resolve this. Let's ask at x-project how this is working for cinder and neutron.02:30
stevemardavechen, the /credentials API isn't used at all :(02:30
morganfainbergThen model after that. If it isn't possible, then we say it doesn't get to report.02:30
davechenstevemar: so, is there any need to get that patch in? or we just abandon it? your thoughts?02:30
stevemardavechen, which patch?02:31
*** fangzhou has quit IRC02:31
morganfainbergbknudson: yanfengxi ^^ that work for you?02:31
stevemarright now i don't think it makes much sense to expose the /credentials API through the CLI right now, no one is using it02:31
davechenstevemar: some info on how to create an ec2 credentials with os credentials create.02:31
bknudsonmorganfainberg: that works for me. I'd like to know why they accept so many failures.02:31
lbragstadyanfengxi: can you make it to this meeting? https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting02:31
stevemardavechen, probably not02:31
lbragstadbknudson: who is they?02:32
stevemardavechen, i want to delete `os credentials` :\02:32
davechenstevemar: really?02:32
bknudsonlbragstad: cinder , nova, neutron, and other projects that have external CI02:32
stevemari want to delete the entire /credentials API that keystone has, i don't think anyone uses it02:32
davechenstevemar: haha. i saw you have a bug relevant with this.02:32
bknudsonlbragstad: these things seem to be reporting failures all the time and it doesn't seem to bother them.02:32
lbragstadbknudson: I'd rather not have that in Keystone :-/02:33
yanfengxilbragstad_: it's more than normal to publish results by third party CIs.02:33
jamielennoxstevemar, davechen; i looked at doing it with the credentials api but it involves passing specially formed serialized JSON over the CLI02:34
yanfengxilbragstad_: what's this meeting for: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting? Is there needs for me to attend it?02:34
*** _cjones_ has joined #openstack-keystone02:34
jamielennoxgiven the EC2 extension is there we may as well use it02:34
davechenstevemar: hope to see that happens sooner than later since there is little help with OSC when we want to create credentails but it's nice to see there is also a sepearte command to create ec2 credentails.02:34
lbragstadyanfengxi: it's the cross project meeting morganfainberg was just talking about02:34
*** bradjones has quit IRC02:35
stevemardavechen, yep, and with barbican on it's way, we shouldn't be storing credentials in keystone anyway :)02:35
jamielennoxstevemar, davechen: the command could use /credentials in OSC - however the EC2 ext generates keys for you so we would have to port that to OSC02:35
bknudsonstevemar: barbican has already arrived.02:35
jamielennoxv4 won't have /credneitlas :)02:35
bknudsonthat train has left the station02:35
stevemarbknudson, then why aren't we using it to store thing :P02:35
*** bradjones has joined #openstack-keystone02:35
*** bradjones has quit IRC02:35
*** bradjones has joined #openstack-keystone02:35
stevemarjamielennox, v4 won't have a lot of things02:36
bknudsonstevemar: because you didn't write the code!02:36
stevemarbknudson, it was my job ?!02:36
davechenjamielennox: v4? is there any plan for v4?02:36
stevemardavechen, nah, we just joke about v302:36
jamielennoxdavechen: hehe, no, i keep bringing it up cause it annoys morganfainberg02:36
morganfainbergjamielennox: huh?02:37
stevemardavechen, official disclaimer: there are absolutely no plans to make v4 of the identity api02:37
jamielennoxmorganfainberg: v4 for the win!02:37
stevemarjamielennox, you awoke the beast02:37
davechenhehe, i am a really slow.02:37
morganfainbergjamielennox: decouple auth first.02:37
jamielennoxit's getting there02:37
yanfengximorganfainberg_: this meeting is Wed 5:00 AM in beijing time, a little early for me.02:38
davechenstevemar: i won't say v4 stuff in my blogs, relax. :P02:38
*** dguerri` is now known as dguerri02:38
stevemardavechen, oh where are you blogs?02:39
bknudsonsubmit a summit presentation on identity v4.02:39
davechenstevemar: you cannot read it, I need transilate for you.02:39
davechenstevemar: it's not write in english :)02:40
morganfainbergOk so, just was chatting with anteaya about how this all works for other projects.02:40
morganfainbergIt is 100% on the driver maintainers to debug failures.02:40
bknudsonthat's how we've always been treating it02:41
bknudsonalthough in cases like cinder you'd need to actually buy hardware to debug it02:41
morganfainbergI will allow db2 ci to run, but I'm holding IBM to a high high standard to keep on top of it.02:41
bknudsondb2 ci you can at least get it for free02:41
morganfainbergIf it is regularly broken or not being looked at, I'll just say to stop reporting.02:42
stevemardavechen, send me the link anyway, google chrome will translate some of it :P02:42
morganfainbergAnd at that point i won't want it reporting again. So stay on top of it.02:42
bknudsonso what I've heard is that the failure rate is 12%02:43
morganfainberg12% due to transient (aka normal) gate bugs?02:43
morganfainbergOr 12% because of db202:43
morganfainbergIf it is the latter, fix that before reporting.02:44
bknudsonthere haven't been any failures due to actual changes that broke db2.02:44
morganfainberg12% seems really really high.02:44
yanfengxithe failure rate is on other projects, which are more problematic than keystone.02:44
morganfainbergI don't think we are that bad in the gate in general.02:44
lbragstadI have a question. Let's say I propose a patch that breaks db2, and I work with the IBM folks to get my patch passing db2 but it requires the code to change in a way that would require a test upstream. How do we account for testing on something like that?02:44
yanfengximorganfainberg_: In my mind now, I think it's better not publish results to keystone patch, and will handle them internally.02:45
bknudsonlbragstad: there aren't any tests for workarounds for mysql or postgres02:45
*** richm has quit IRC02:45
morganfainbergyanfengxi: ok. Once the failure rate is a bit lower / cleaned up I'm ok with reporting again. Just let me know and be ready to keep on top of it.02:45
yanfengximorganfainberg_: OK, thanks02:46
lbragstadbknudson: just curious02:46
bknudsonyou'd have to mock to test it.02:46
morganfainbergI really want to avoid noise to developers who cannot debug it (having an icky license that people may/may not be able to agree to is untestable/not debuggable outside of IBM)02:46
lbragstadmorganfainberg: so, no x-project meeting tomorrow about this?02:47
yanfengximorganfainberg_: Yes, understand.02:47
morganfainbergIf db2 was an "apt-get db2" with no license issues, I'd be more open to it.02:47
morganfainberglbragstad: looks like not needed.02:47
bknudsonI can't say if the license is actually problematic... it's obviously not GPL or BSD or Apache.02:47
morganfainbergbknudson: having to independently agree to a license is an issue for developers.02:47
bknudsony, and that's why I mentioned it, because it is there, where mysql people just install it.02:48
*** dguerri is now known as dguerri`02:48
*** kiran-r has joined #openstack-keystone02:48
morganfainbergIf I have to do the oracle thing, and there isn't an openjdk equivalent, it (in my mind) is not in the realm of a reasonable ask02:48
bknudsoneven though it's got a license that people may not agree with02:48
morganfainbergThat's all.02:48
morganfainbergIf IBM makes it more accessible, it becomes easier to be a reasonable ask.02:49
bknudsonlet me just call up the CEO!02:49
morganfainbergYou should ;)02:49
morganfainbergMake Topol do it.02:49
bknudsonTopol could probably make it happen himself.02:50
morganfainbergbknudson: let's see if we can get the failure rate on par with the normal gate failures then have you report.02:50
morganfainbergThen IBM should have less overhead with it and it becomes easier to not be just noise on be patches.02:50
morganfainbergWe thankfully have few migrations.02:51
yanfengximorganfainberg_: So here is the plan: we will not publish results to keystone patch, and handle issues internally. Once the failure rate is acceptable(maybe 2% or lower), I will reach you, to ask to publish.02:51
bknudsonworks for me.02:51
yanfengxiThanks, everyone.02:52
yanfengxiHave a good night :-)02:52
jamielennoxbknudson: you have a minute to discuss some auth_token stuff?02:52
bknudsonjamielennox: I can try to stay awake02:53
lbragstadyanfengxi: no problem, thanks!02:53
jamielennoxbknudson: i guess i just want to figure out what we are looking for from caching02:53
bknudsonI think it's trying to reduce the load on keystone02:53
jamielennoxat the moment we cache the result of a token validation - not the token returned from the server necessarily - but the yes/no result02:53
bknudsonsince tokens should be reused02:54
bknudsonI thought the token was stored?02:54
jamielennoxit does, but i mean if you fail validation even if the result from the server was good you get an 'invalid' in the cache02:54
jamielennoxi was pushing towards we should only cache the response from the keystone server02:54
jamielennoxthat the cache is just a way of fetching a token and that we should do things like expiry validation every time02:55
bknudson?? how do you get the server saying the token is ok but it's not ok?02:55
jamielennoxbknudson: i'm not sure but the code says you can02:55
jamielennoxbind validation02:55
jamielennoxumm, i guess there are some things02:55
bknudsonI like the idea that the cache is really just sitting in front of the rest calls.02:56
jamielennoxbind validation is broken actually because it will cache the invalid status if you have the wrong bind and wont check again in future02:56
jamielennoxbut bind validation is broken in a bunch of ways...02:56
bknudsonseems like that's what it should be... would be easier to understand02:56
bknudsonthat does sound broken02:56
jamielennoxok, cool - that was where i was going, should the cache be just in front of the REST calls, or should we be looking to cache all validation02:57
jamielennoxthe distinction is important if it's in front of keystone02:57
bknudsonlet's not complicate things... maybe there's some way to encode the request info in the key02:57
bknudsone.g., SHA256(02:58
bknudson'GET /v3/tokens'02:58
bknudsonmaybe requests already has something?02:58
jamielennoxbknudson: i think not complicated things is only caching responses from the identity server02:58
jamielennoxso that bind validation and expiry is done regardless of whether it's been seen before02:59
jamielennoxand not caching PKI related information at all02:59
bknudsonin future we might do something like fetching the catalog separately from the token02:59
bknudsonas in, maybe PKI tokens never have the catalog02:59
jamielennoxbknudson: there are ways we could handle that03:00
bknudsonthat should use the cache03:00
jamielennoxthere will still be a cache, i'm just looking at where you draw the line03:00
bknudsonand if the cache was just in front of the REST calls it would be automatic03:00
jamielennoxwhat's in the base auth_token, what's in auth_token and what's in keysotne03:00
morganfainberglbragstad: can you propose a back port of the memcache + fernet in middleware ?03:01
morganfainberglbragstad: to stable/kilo03:01
bknudsonmorganfainberg: middleware release?03:01
morganfainbergbknudson: planning on it at l103:02
morganfainbergGoing to track milestones based on convos with dhellmann and ttx03:02
bknudsonmorganfainberg: jamielennox was just proposing using keystonemiddleware in keystone.03:03
morganfainbergI know.03:03
jamielennoxi'm a few patches short, i don't mind if we wait for it03:04
jamielennoxeverything i've been changing recently i've kept private so a release now won't cause any problems03:05
bknudsonsomebody here was asking for a release because a change they want to use merged.03:05
jamielennox- didn't phrase that well, i don't mind if we release now and just do another when these patches are ready03:05
*** stevemar has quit IRC03:06
morganfainbergbknudson: stable/kill releases I'll make as needed (same with any stable).03:06
morganfainbergFor liberty we'll track milestones.03:07
*** kiran-r has quit IRC03:08
*** nkinder__ has quit IRC03:08
bknudsonit's a little strange to have something in a stable/kilo release that's not available on master yet03:09
jamielennoxbknudson: anyway, thanks. I just wanted to check that using the cache only for REST calls is ok, that we can do the additional validation steps each time03:09
*** mtecer has quit IRC03:10
*** _cjones_ has quit IRC03:10
morganfainbergbknudson: it is on master, just not tagged03:10
morganfainbergOn pypi03:11
*** yanfengxi has quit IRC03:11
jamielennoxmorganfainberg: what changes did e need for fernet in middleware?03:11
morganfainbergIf you are cd already you'd cd middleware too.03:11
morganfainbergjamielennox: the cache fix that merged.03:11
jamielennoxoh the sha256 everything03:12
jamielennoxwhat is a memcache max length?03:12
morganfainbergUh. 64bytes? 100bytes? Dunno03:12
*** kiran-r has joined #openstack-keystone03:12
morganfainbergSha256 works.03:12
morganfainberg250 bytes.03:13
morganfainbergIt looks like.03:13
jamielennoxsha256 + 'token-' or whatever we prefix it with03:14
*** _cjones_ has joined #openstack-keystone03:14
morganfainbergYeah. That is a fine length.03:14
morganfainbergIt's the full fernet token ID that was a problem.03:15
morganfainbergjamielennox: the fix merged to master already for middleware.03:15
morganfainbergJust needs a back port.03:15
morganfainbergWas asking a non-stable core for keystone to propose the back port.03:15
jamielennoxmorganfainberg: yea, i saw it and was fine, i think i had a coment about the secure form03:16
jamielennoxmorganfainberg: so i did a bunch of keystoneauth patches yesterday03:16
jamielennoxand ksc on ksa if you have some time later03:16
morganfainbergYeah I saw.03:16
morganfainbergAnd my ksa1 patch now needs a rebase :(03:17
jamielennoxmorganfainberg: :) i had these started and i saw the move - i probably should have merged that one first03:17
morganfainbergThat one is an icky rebase.03:18
morganfainbergWill get to it later this week.03:18
*** tobe has quit IRC03:20
*** kiran-r has quit IRC03:20
*** tobe has joined #openstack-keystone03:23
*** _cjones_ has quit IRC03:31
*** _cjones_ has joined #openstack-keystone03:32
*** mfisch has quit IRC03:32
*** HT_sergio has quit IRC03:32
*** mfisch has joined #openstack-keystone03:36
*** mfisch is now known as Guest6866003:36
*** _cjones_ has quit IRC03:37
*** dims has joined #openstack-keystone03:46
*** liusheng has quit IRC03:50
*** dims has quit IRC03:51
*** redrobot has quit IRC03:55
*** ayoung has quit IRC04:12
*** mabrams has joined #openstack-keystone04:20
*** belmoreira has joined #openstack-keystone04:26
*** Ephur has quit IRC04:29
*** belmoreira has quit IRC04:31
*** tobe has quit IRC04:47
jamielennoxbknudson, morganfainberg: what is the policy on utf-8 in urls?04:48
jamielennoxdo we percent encode everything?04:48
morganfainbergI think you have to.04:50
morganfainbergAnd what does urllib support?04:51
jamielennoxit seems it can work04:52
jamielennoxlike modern enough everything and you can just use utf-804:52
jamielennoxbut i don't see anywhere it's officially supported04:52
*** ncoghlan has joined #openstack-keystone05:05
*** tobe has joined #openstack-keystone05:07
*** kiran-r has joined #openstack-keystone05:08
jamielennoxoh god our CLI is worse than i ever knew :(05:18
bigjoolsyes, yes it is05:19
jamielennoxi mean deprecated for sure, but it's just all over the place05:20
jamielennoxtrying to do a utf-8 fix and there is really nowhere that i can just fix it for everyone05:20
bigjoolsfrom a user PoV, openstackclient is terrible too05:20
morganfainbergjamielennox: yeah don't use our CLI. Just don't.05:22
* morganfainberg 05:22
* morganfainberg sobs at the ksc CLI05:23
jamielennoxmorganfainberg: i'm going to have to backport something - but i really suspect that OSC will have the same problems05:23
morganfainbergbigjools: osc is better than ksc.05:23
bigjoolsmorganfainberg: ksc must be really bad then :)05:23
morganfainbergjamielennox: yeah I just hit my head on osc ux a week ago. Just ugh.05:23
jamielennoxbigjools: it is05:23
morganfainbergbigjools: try using it. Tell me how much you like it.05:23
jamielennoxbut yes, it's a shame you have to deal with versions in osc05:24
morganfainbergjamielennox: can we just use shade for everything?05:24
jamielennoxmy brain goes in about 3 directions even thinking about that05:24
bigjoolsoh morganfainberg FWIW I found an interim solution to federate with websso until it's all working with k2k05:24
morganfainbergI'd be ok if the OpenStack interface was ansible.05:25
morganfainbergbigjools: document it!!05:25
morganfainbergPublish it!05:25
bigjoolsyes :)05:25
bigjoolswill blog soon05:25
morganfainbergMake people happy!05:25
bigjoolsIt needs a little development work in horizon but that would need to happen anyway05:25
* morganfainberg is thinking more and more ansible is a good idea.05:25
morganfainbergSomehow I think devstack wouldn't accept it though.05:26
bigjoolsit uses a little-known feature of Shibboleth, whose Login URL has a GET API05:26
morganfainbergI'm kinda scared about that. But sounds good.05:26
bigjoolsI have my ticket to pyconau05:26
bigjoolswell you can comment when I've blogged it :)05:26
* morganfainberg has to redo an abstract so lifeless isn't mad at him.05:27
bigjoolslifeless never gets mad! :)05:27
bigjoolsI think I owe him some beers05:28
morganfainbergOh crap I need to submit / may have missed LCA cfp05:28
jamielennoxmorganfainberg: oo, i haven't changed my abstract either05:28
jamielennoxLCA is still open afaik05:29
morganfainbergI don't know what I want to talk about at LCA.05:29
morganfainbergI Do know what I'm submitting to Tokyo. And it isn't a keystone presentation.05:29
jamielennoxi was thinking i might just go on my own to LCA05:30
jamielennoxas in not propose anything05:30
jamielennoxi haven't been and i'm keen05:30
*** stevemar has joined #openstack-keystone05:30
*** ChanServ sets mode: +v stevemar05:30
morganfainbergIt's a long flight to "go for the fun of"05:30
jamielennoxfor you, sure05:31
*** tobe has quit IRC05:37
lifelessmorganfainberg: LCA is still open05:39
lifelessmorganfainberg: thank you05:39
morganfainberglifeless: I apologize it might be the end of the week for the abstract for PyCon.05:40
morganfainbergHad some stuff going on and trying to deal with that.05:40
morganfainberglifeless: hah wait you know what was up. Nvm. /face palms.05:40
jamielennoxlifeless: i have no excuse05:41
morganfainbergAnyway. Yeah it's on the short list.05:41
jamielennoxbut soon05:41
jamielennoxwe haven't forgotten you stevemar05:43
stevemarjamielennox, i didn't suspect you did05:43
stevemarjust saying howdy05:43
jamielennoxstevemar: it looks like v3 is passing05:44
stevemarindeed it is05:44
*** lhcheng has joined #openstack-keystone05:47
*** ChanServ sets mode: +v lhcheng05:47
marekdstevemar: morganfainberg: There was some VoIP conference a few hours ago?05:49
morganfainbergstevemar: isn't it stupid late there?05:49
morganfainbergmarekd: there was?05:50
* morganfainberg doesn't do VoIP.05:50
marekdi don't know, bknudson was asking if we all are ready to get started, and i was also pinged...05:51
morganfainbergNo seriously, there was a VoIP thing?05:51
marekdmaybe the topics got mixed.05:51
jamielennoxi think it was the db2 chat05:52
jamielennoxwasn't there going to be a call-in for that?05:52
marekdyep, they were waiting for somebody from China.05:52
morganfainbergOh. That was kn IRC.05:53
morganfainbergNot VoIP.05:53
marekdmorganfainberg: so, pparently the topics were mixed.05:53
stevemarmarekd, morganfainberg jamielennox there was a meeting, but just here -keystone, no voip05:54
morganfainbergSo the db2 ci, we are not getting reports until they are closer to baseline (2%) failure rate. So we don't have excessive noise.05:54
stevemarmorganfainberg, yes it's stupid late, but i have been trying to sleep for about 2 hrs05:54
morganfainbergstevemar: you know computer screens have the wrong color/white balance to help sleep right?05:54
stevemarphones too? :P05:55
marekdmorganfainberg: that's what IBM pts on their corporate laptoptops to make them work even more :P05:55
jamielennoxhave you tried installing that redshift thing though, was horrible to work with05:55
morganfainbergstevemar: yep.05:55
morganfainbergstevemar: you need a redshift or f.lux like app.05:55
*** belmoreira has joined #openstack-keystone05:55
morganfainberg(Btw those give me massive headaches when I use them). But it makes you sleepier than he blue-ish light from lcds05:56
morganfainbergmarekd: ahaha05:56
stevemari just turn down the brightness05:57
marekdjamielennox: going to attend todays...erm..tomorrow's meeting?06:00
jamielennoxmarekd: no06:00
jamielennoxmarekd: that's like 2am and my team meeting got cancelled06:00
marekdjamielennox: OK06:01
jamielennoxmarekd: something on there i should know about?06:01
jamielennoxi haven't looked yet06:01
marekdjamielennox: no06:01
morganfainbergjamielennox: wait it's 2am meeting for you? Eek06:01
jamielennoxmorganfainberg: i'm on the west coast (aus) for the next week or so06:01
morganfainbergThat explains it.06:02
marekdjamielennox: so you can basically work remotely, right?06:02
jamielennoxit'll go back to its usual 4 soon06:02
jamielennoxmarekd: yea06:02
*** tobe has joined #openstack-keystone06:02
marekdjamielennox: i wanted to talk about incorporating k2k into kmw.06:04
marekdjamielennox: you might remember our convo at the summit.06:04
jamielennoxmorganfainberg: yes06:04
jamielennoxmarekd: type away, i've got about 2 minutes to fix up this patch06:05
*** krykowski has joined #openstack-keystone06:08
*** lhcheng has quit IRC06:11
marekdjamielennox: i have this use case for image sharing, where eventually you suggested having client doing all the k2k stuff and getting remote scoped token. I think we cannot have anything better at the moment (kmw doing it itself), but I am thinking about service discovery. Let's assume a client did all the k2k stuff and now has 2 tokens - a local one, and a remote. He will now request a new task at his local glance to share an image. A client will06:11
*** spandhe has quit IRC06:12
*** lhcheng has joined #openstack-keystone06:12
*** ChanServ sets mode: +v lhcheng06:12
marekdjamielennox: Another thing is that ultimately I'd like to have nice 1:N architecture (one glance pushing images to N glance-clients) and I am fearing that having to all create N tasks and managing them by a client might be a little bit intimidating06:13
jamielennoxmarekd: so  i think you lost the end of your first sentence06:15
jamielennoxmarekd: so in any situation like this i think to "push" is wrong06:15
marekdjamielennox: i have this use case for image sharing, where eventually you suggested having client doing all the k2k  stuff and getting remote scoped token. I think we cannot have anything better at the moment (kmw doing it itself), but  I am thinking about service discovery. Let's assume a client did all the k2k stuff and now has 2 tokens - a local one,06:16
marekd and a remot. He will now request a new task  at his local glance to share an image. A client will need to send two  tokens- a local one, for validating itself, and a remote, as the glance will need to work on behalf of the user. I  feel like kmw should at least do some sort of service discovery so it knows where exactly is the remote glance. Do you  see anything 'that cannot be done' in this thinking?06:16
marekdjamielennox: let's leave the push vs pull model apart, because it's been heavily discusssed with glance guys and they insisted on it.06:16
jamielennoxinsist on push?06:16
marekdjamielennox: yes.06:16
jamielennoxglance already has "download from url" why would they want it pushed06:17
jamielennoxhonestly i think something like swift tempurls is the easiest way to do this06:17
jamielennoxand then use existing glance pull features from a one time url06:18
marekdjamielennox: because tasks are async and there might be significant time gap in between you create a task and it starts executing.06:18
marekdjamielennox: swift if just one backedn to glance, right?06:18
jamielennoxright - i wasn't thinking of doing it via swift, just the mechanism06:18
jamielennoxso won't any issue of token expiry work both ways?06:19
jamielennoxif i push instead of pull and it takes some time then it's possible my remote token might expire in that time as well06:20
marekdjamielennox: then the task fails. And I don't think it'd be 24hours delay of executing the task.06:20
jamielennoxmarekd: wait so you want to submit the assertion, not a token?06:21
stevemarlhcheng, needed an extra pair of eyes on: https://review.openstack.org/#/c/189947/06:21
marekdjamielennox: i would probably wish we could do this, but on the other hand we would always have to easily pass all the scoping information to kmw06:22
lhchengstevemar: sure, on it.06:23
marekdjamielennox: and kmw would have to do all the k2k work.06:23
marekdjamielennox: i am ok taking the easiest route atm and making client doing all that, and client would send two tokens- local and remote06:24
marekdjamielennox: i;d need to teach kmw to distinguish between local and remote tokens and fetch endpoint url from remote service catalog.06:24
jamielennoxmarekd: i'm really uneasy about sending scoping information to auth_token and expecting it to do something with it06:24
marekdjamielennox: so, two tokens.06:25
jamielennoxmarekd: you can do it as a different piece of middleware but i'm not sure if it's something general purpose06:26
marekdjamielennox: i think it will eventually become a general purpose06:27
marekdjamielennox: i think we will get to the point where nova@A will communicate with glance@B06:27
jamielennoxyou're saying though that for every request with this information we're adding another 2 requests to keystone06:27
jamielennoxand once you start talking about service to service communication like nova to glance, then nova will fetch a remote token, then glance will fetch another one06:27
jamielennoxstevemar: as you're awake anyway can you read through above and tell me your thoughts?06:29
jamielennoxyou two are the ones that know this best06:29
jamielennoxi'm willing to be wrong but it doesn't seem like auth_token middleware should be doing this for you if you need to supply all the scoping information anyway06:30
marekdjamielennox: i don't want to communicate services now, but i think eventually federating at the identity only level will not be enough...06:30
jamielennoxmarekd: i agree06:30
stevemarcatching up06:31
jamielennoxand i think federated resources is going to be really hard and require buy in from all the services06:31
marekdjamielennox: i agree06:31
jamielennoxi don't know if it's something we can abstract away at the keystone level06:31
marekdjamielennox: to be honest i am at the moment 'let's try design some propotype and see how it works'. I see some difficulties in kmw doing k2k stuff, that's why i had said that we could leverage on client doing so, and just sending two scoped, openstack tokens.06:33
marekdjamielennox: kmw would have much easier job with figuring out the remote image endpoint.06:34
jamielennoxmarekd: so conceptually when you talk about federated resources we will need to provide some way of identifying where a resource id lives06:34
jamielennoxlike image_id@local_glance06:34
jamielennoxand have the catalog smart enough to know what local_glance is06:34
marekdthat would become an attribute of image.06:34
jamielennoxwould it? why?06:35
jamielennoxi don't think it can be06:35
marekdconceptually there is still one token per cloud -> one service catalog per cloud.06:35
marekdand client must specify which cloud he wants to use.06:35
*** belmoreira has quit IRC06:36
marekdi already gave up with ideas like "openstack image list" where all the images from all your clouds are listed.06:36
stevemarmarekd, trying to understand this... so you want your local nova to use my glance images?06:36
marekdstevemar: no :-)06:36
jamielennoxwe moved a bit into ffuture work06:37
marekdstevemar: there was a guy at the summit who wanted to actually do that and ayoung got quite excited about that, but i am not that hardcore.06:37
stevemarwhat are you proposing (simple terms, i am not a smart man)06:37
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/19040506:37
marekdstevemar: i want to be able to request my glance to push an image to your glance, because we agreed that i'd be able to do so.06:37
marekd(oh, sir, you are smart man)06:37
marekdstevemar: i want glances to  communicate directly, because my and your DC have nice bandtwidth, whereas my home link is very poor.06:38
marekdstevemar: I don't want to create any sort of service accounts, and storing passwords in any of the glance, but leverage on k2k06:39
stevemaroh okay, you don't want to download the image06:39
marekdstevemar: not to my local laptop and later manually upload it.06:39
stevemarso you still kinda want to use your nova in your DC and my glance image in my DC06:40
marekdstevemar: not at the moment.06:40
marekdstevemar: my nova will be able to use my glance only.06:40
stevemarso you just want to list my images?06:40
marekdi can do this today with federation :-)06:41
stevemaror actually save them?06:41
jamielennoxstevemar: essentially we want replication of the same image amongst multiple glances06:41
jamielennoxover k2k06:41
marekdstevemar: ^^ the man is right.06:41
stevemarokay, let's work it backwards from there06:41
jamielennoxstevemar: so my first thought is that this should not be push based, you want to go to the remote cloud and tell it to pull from local cloud, because glance can kind of do that already06:42
jamielennoxbut apparently the glance team is anti that, it needs to be push based06:42
*** dguerri` is now known as dguerri06:42
* jamielennox thinks the glance team is wrong 06:43
marekdjamielennox: in their bp from 2014 they were proposing pull model, later switched to push, so there must be something they had noticed and we don't see now :-)06:43
stevemari was thinking that the local cloud would pull it from remote cloud when it's necessary06:43
jamielennoxstevemar: if we say it's always necessarily immediately i agree06:44
marekdstevemar: okay, this doesn't matter pull or push, because we still need to solve identity part, one glance is a client here, another is a server.06:44
jamielennoxlike the mechanism is on demand, and you just demand it straight away06:44
stevemarmarekd, so where does ksm fit into this?06:44
jamielennoxmarekd: i disagree, i think the model will change this dramatically06:44
marekdjamielennox: identity design? why?06:45
jamielennoxmarekd: answer stevemar first06:45
stevemary plz :)06:45
marekdstevemar: you need to request your local glance to connect with a remote glance and fetch/upload some images. so your local glance will impersonate you.06:46
marekdstevemar: ksm must be smart enough to distinguish between two tokens (local and remote) as well as (probably) fetch proper endpoint (remote 'image' endpoint in this case) to know where is that remote glance.06:47
*** dguerri is now known as dguerri`06:50
marekdjamielennox: your turn :-)06:50
jamielennoxso i have an issue with making auth_token request a token from a remote cloud06:51
stevemarjamielennox, marekd, does ksm even handle token auth nicely? i thought it mainly works with service accounts / service password06:51
jamielennoxauth_token is about validation and i don't what to start adding a bunch of headers that are going to trigger an additional auth step given that the service is going to need to parse them seperately06:51
marekdjamielennox: no matter what model we use (push vs pull), it's always your local cloud which initiates the action....06:54
jamielennoxmarekd: i guess all my options involve generating both tokens ahead of time06:55
*** henrynash has joined #openstack-keystone06:56
*** ChanServ sets mode: +v henrynash06:56
marekdjamielennox: sorry if i misunderstood - you are okay with generating both scoped tokens by the client (like ksc/ksa) and passing them to the local glance, correct?06:57
marekdlocal token will be for..well, validating the request with the local side, whilst remote for remote side...06:58
marekdjamielennox: i could live with ksc/ksa finding the remote image endpoint in the remote token as well and passing this as a parameter/header06:59
jamielennoxmarekd: that pattern has no real involvement from auth_token middleware07:00
jamielennoxi mean it would validate the local token as per normal, but it does'nt know how to validate a token for a remote cloud07:00
jamielennoxso you would essentially just be providing that token for glance to do what it liked with07:00
marekdjamielennox: so, how does kmw validate the token today? how does it figure out auth_url ?07:01
jamielennoxit doesn't, it's provided via conf07:01
jamielennoxno, it gets it from the catalog of the local token i think07:01
marekdso we could repeat it for remote token.07:02
jamielennoxbut auth_token can't validate a remote_token07:02
marekdwhy then?07:02
marekdcerts etc?07:02
jamielennoxcerts, you would need to know which keystone to go to, you would need service accounts for that keysotne07:02
marekdhm, right.07:03
jamielennoxbut that's fine, you would just pass it through as a blob and when glance needed to use it it would be validated by the remote auth_token07:03
marekdjamielennox: allright. now given that you know what I want to do - do you see it can happen in ksc/ksa ?07:03
jamielennoxauth_token will only touch the headers that it knows about, everything else just passes through07:03
marekdjamielennox: cool!07:04
jamielennoxmarekd: so the issue i see is knowing the endpoints from the token07:04
jamielennoxhmm, which i guess is a reason for auth_token07:05
jamielennoxif you get a blob you have no idea where the remote glance is07:05
jamielennoxmarekd: i'm happy for you to do all this in glance, i'm just concerned about it in middlewarew07:05
marekdjamielennox: i went to the simpliest use-case, a client sends: local-token, remote-token (passed to the glance task),  image-url (a url, where this task should be directed)07:06
marekdok, let's not call it image-url, but remote-glance-url07:06
jamielennoxyou can run all the same sequence you had in mind directly from glance, fetch a k2k token on behalf of current token, that will give you all the catalog you need, push to that server07:07
*** greghaynes has quit IRC07:08
marekdjamielennox: that was my initial idea, and i thought identity bits in glance (hence ksm) would be the best part...07:08
marekdi don't think inplementing k2k-client in glance is a good idea...07:08
marekdand that's why i started thinking about kmw+k2k07:08
jamielennoxmarekd: auth_token is not the only place that gets to do identity operations07:08
jamielennoxyou can do it from wherever you like07:08
marekdjamielennox: so, for instance glance would depend on ksa (if it doesn't today) and run some auth-like plugin somewhere inside itself?07:09
jamielennoxmarekd: yea07:09
jamielennoxyou would use the plugin from auth_token as the local cloud plugin, then wrap the k2k around that07:10
marekdjamielennox: do you think it would be wise to do so?07:10
marekdmaybe we shoould make another middleware, but for k2k purposes like this?07:10
jamielennoxi think that the use case for generating this token on the fly doesn't make sense in the general case07:10
jamielennoxbecause you are still going to need to have glance do a whole lot of work that is specific to this use case07:11
*** greghaynes has joined #openstack-keystone07:11
jamielennoxlike use this token and this service catalog instead of the normal one07:11
marekdthis sounds like general use-case07:11
jamielennoxi think having glance handle the k2k makes sense because you can submit the remote sp as part of request rather than tacking on headers07:12
jamielennoxmarekd: it will have to be general at some point once we do federated resources07:12
marekdjamielennox: i would also need to pass all the scoping information, and i will probably not want to do this in a image specific request.07:12
jamielennoxbut even then i expect every service is going to have a different way of suggesting how it should point at a different cloud, or which sp to use07:13
jamielennoxmarekd: you don't need scoping if you've got two tokens07:13
*** rlt has joined #openstack-keystone07:13
marekdjamielennox: if i pass two tokens to service like glance i don't need it to do any k2k then.07:14
marekdbecause i already did this with ksa on my local laptop.07:14
* marekd will be back in 5 mins07:14
jamielennoxmarekd: you don't need scoping information you just need the sp name/id07:15
*** chlong has quit IRC07:18
*** browne has quit IRC07:19
*** woodster_ has quit IRC07:21
marekdjamielennox: suppose i pass sp id, it gets data from the service catalog, fetches the remote token but the token is unscoped.07:22
marekdand i need to scope it to make it usable.07:22
jamielennoxmarekd: i didn't think you could do that07:22
jamielennoxk2k was always scoped to scoped07:22
marekdjamielennox: no :(07:22
marekdjamielennox: from the remote cloud, it's like old federation07:22
marekdjamielennox: that's why it's also this: https://review.openstack.org/#/c/188881/07:23
marekdjamielennox: i cant remember 100% now why, but i think the reason was that http request was being lost between the calls to SP, IdP and SP again.07:27
marekdso there was no way to actually send scoping info in the first call....07:28
*** bradjones has quit IRC07:30
jamielennoxthen yes, you need scoping as well07:32
jamielennoxwe are going to need a way of addressing this stuff, damnit, maybe adam is rigth07:32
*** bradjones has joined #openstack-keystone07:36
*** bradjones has quit IRC07:36
*** bradjones has joined #openstack-keystone07:36
*** tobe has quit IRC07:40
*** pnavarro has joined #openstack-keystone07:41
jamielennoxstevemar: you still awake?07:42
marekdadam? about what?07:42
marekdjamielennox: ^^07:43
jamielennoxoh, the way you might need to describe a resource07:43
jamielennoxresource_id IN project_id IN cloud_id07:44
*** tobe has joined #openstack-keystone07:47
marekdjamielennox: ok, let's try to make some conclusions - are you okay for me trying to implementing a design, where two scoped tokens will be created in the ksc/ksa and simply passed to the glance? This would line up with our curent k2k in ksa efforts. I'd also try to design modules in glance in a way, that we could inject some auth modules later on so glance would handle k2k workflow.07:50
marekdmakes sense?07:50
jamielennoxi would prefer to go the other way07:50
jamielennoxstart in glance and then we'll abstract what is common to auth_token07:50
ccardanyone have any comments on my issue here: http://lists.openstack.org/pipermail/openstack/2015-June/013061.html07:50
*** bdossant has joined #openstack-keystone07:51
marekdjamielennox: allright, so already first question: information like sp_id, and scoping info for remote token would be passed in the HTTP headers, ok?07:52
* marekd http://openstackreactions.enovance.com/2015/06/getting-a-token-from-keystone/ relevant to the discussion...07:53
jamielennoxccard: it's really not my area but it seems unlikely that horizon should be the difference because it's just using the keystone APIs07:53
jamielennoxso i guess what you are looking for is what is happening when you shut down an ldap from keystone07:53
jamielennoxi honestly have no idea, but i would try with like keystone requests in a loop and see if there is a bad response there at some point07:54
*** belmoreira has joined #openstack-keystone07:54
jamielennoxmarekd: umm, i don't know - how much user interaction do you expect there to be in this interation07:56
jamielennoxis the user saying where to replicate to /07:56
marekdjamielennox: yes.07:56
jamielennoxso why wouldn't it be part of the glance payload07:56
marekdbecause it looks like a identity part.07:56
ccardjamielennox: I agree that it must be something in keystone, possibly interacting with Apache. My plan is to find all the keystone requests made as part of the horizon login and run them by hand to see if anything pops out.07:57
jamielennoxccard: my guess is that if there is an active LDAP connection when the machine goes down for whatever reason the connection is being closed rather than data returned07:58
jamielennoxso turn the keystone workers down to 107:58
jamielennoxput in some sleep statements and see what happens if a connection goes away07:59
ccardjamielennox: I've restarted Apache (and hence horizon and keystone) after shutting down the LDAP server, and I still see the same behaviour07:59
jamielennoxoh - ongoing ?07:59
jamielennoxas in easily reproducable?07:59
ccardevery time07:59
jamielennoxok, well put in pdb and step through it08:00
ccardhow do I run an Apache wsgi app under pdb? (not a Python expert :( )08:01
jamielennoxso look at rpdb08:01
jamielennoxput an import rpdb; rpdb.set_trace() where things start to get interesting08:01
jamielennoxit will open a local tcp socket that you can netcat to08:01
jamielennoxi can't remember the port but it will say on the rpdb page08:02
jamielennoxfrom there it's the same as pdb08:02
ccardthanks, I'll take a look at that - sounds like it will be a useful technique in general08:02
jamielennoxit's the only way i know to put breakpoints in under apache08:02
jamielennoxprobably still a good idea to turn the workers down to 1 as i think it gets messed up if you start having multiple calls all hit the rpdb statement08:03
jamielennoxmarekd: i honestly don't know for any of this stuff, if you start with headers then we can look at the implementation and see if that or in the data makes more sense08:04
jamielennoxi think you just doc that the remote cloud token has to be scoped to what you want08:04
jamielennoxthe alternative is just ugly08:04
jamielennoxbut i think you should do the k2k step as part of glance08:05
jamielennoxugh, scoping info still :(08:05
*** tobe has quit IRC08:06
marekdpasing the http headers will be too much ?08:06
jamielennoxyou can try it, but you've got project_id, project_name, project_domain_id, project_domain_name08:07
jamielennoxall optional08:07
marekdok, i will keep you updated...08:07
marekdit's a bit harder for me to make it work, as I am sometimes getting constraints from two separate teams :-)08:08
marekdkeystone and glance08:08
jamielennoxmarekd: i think you should organize like a joint meeting08:10
jamielennoxi don't think the glance team is going to fully understand the implications of k2k08:10
jamielennoxand i've no idea what glance wants for there service08:10
marekdjamielennox: they don't understand k2k and they basically say "it's good that you (me) understand this so you will make it work". When I was explaining a whole use case to them, half of my time was spend on expalining simplified k2k workflow...which is hard to understand at first.08:12
jamielennoxso scoping would be an issue you wouldn't have with a pull based flow08:13
jamielennoxbut yea, i can understand their position as well08:13
marekdi think i'd still have same issue. i need a remote token scoped to something, no matter if i wantto push something there or want to pull something from there (my request still neds to be validated wrt my project/domain)08:14
jamielennoxsure but you'd know on the client side whether it worked and whether the scoping info was present08:14
marekdi don't follow. It's the client who provides scoping info.08:15
jamielennoxyou wouldn't have to provide that info to the servers08:15
jamielennoxeither glance08:15
*** tobe has joined #openstack-keystone08:16
*** fhubik has joined #openstack-keystone08:19
*** jaosorior has joined #openstack-keystone08:27
*** afazekas has joined #openstack-keystone08:28
openstackgerritMarcos Fermín Lobo proposed openstack/python-keystoneclient: Added endpoint group filter manager methods  https://review.openstack.org/18265808:34
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Fetch resource ID as unicode  https://review.openstack.org/19210408:36
jamielennoxah, that was stupidly more difficult than it should have been08:36
*** btully has quit IRC08:37
*** henrynash has quit IRC08:38
*** henrynash_ has joined #openstack-keystone08:38
*** ChanServ sets mode: +v henrynash_08:38
*** btully has joined #openstack-keystone08:39
*** rushiagr_away is now known as rushiagr08:44
*** viktors|afk has quit IRC08:47
*** mtecer has joined #openstack-keystone08:49
*** viktors has joined #openstack-keystone08:51
*** stevemar has quit IRC08:52
*** mtecer has quit IRC08:54
*** lhcheng has quit IRC08:56
*** chlong has joined #openstack-keystone08:59
*** aix has joined #openstack-keystone09:00
*** ncoghlan has quit IRC09:03
*** chlong has quit IRC09:07
*** e0ne has joined #openstack-keystone09:12
*** dims has joined #openstack-keystone09:18
*** chlong has joined #openstack-keystone09:20
*** e0ne is now known as e0ne_09:21
*** dims has quit IRC09:23
*** e0ne_ has quit IRC09:25
*** krykowski has quit IRC09:27
rushiagrhello keystone folks!09:27
*** e0ne has joined #openstack-keystone09:28
rushiagrI was looking at stable driver interface effort, and want to contribute to it09:28
rushiagrIt's unclear to me what is decides with regards to direction09:28
rushiagrthe etherpad from the Vancouver summit talks about many options -- StrictABC, double book accounting, and Testing. I'm not sure what was the final decision09:30
rushiagrI see patches for StrictABC and for passing information between driver & manager via objects09:31
rushiagrso I was just curious that if something is already decided, I can help with reviews and code too...09:31
rushiagrI am of the opinion that we can write tests which will test driver methods by passing data, and checking if the methods are returning information correctly. This, and some tooling around maintaining and checking driver versions should suffice09:38
*** henrynash_ has quit IRC09:40
rushiagrthoughts? or if there is any spec/blueprint which can point me to more detailed analysis of various approaches, that would be great. It's slightly difficult to gather conclusions from etherpad where things are somewhat condensed..09:40
*** henrynash has joined #openstack-keystone09:40
*** ChanServ sets mode: +v henrynash09:40
*** fhubik is now known as fhubik_afk09:41
*** tobe has quit IRC09:46
*** dguerri` is now known as dguerri09:48
*** kiran-r has quit IRC09:50
*** MaxV has joined #openstack-keystone09:51
MaxVHello all, I have an issue with the setup of keystone using the v3 endpoint only09:53
MaxVI start with a from scratch config and I want to config keystone (creating users, projects)09:53
MaxVbut it seems that I am not using the good path of initialization09:53
MaxVI have an admin token and everything works fine on the v2 endpoint09:53
MaxVbut when using the v3 endpoint I keep running into 401 error09:53
MaxVI tried to ask for a new token using the token_admin, but I get a 40409:53
marekdMaxV: what's you environment setup?09:53
marekdMaxV: env | grep OS09:54
MaxVmarekd: backend sql, using debian, keystone from master branch on github09:56
marekdi meant env :-)09:56
*** tobe has joined #openstack-keystone09:56
MaxVno OS setup09:57
MaxVusing only curl09:57
MaxVno openstack-client09:57
MaxVopenstack-client works because it uses the v2 endpoint09:58
*** fhubik_afk is now known as fhubik09:59
MaxVbasically I only have a OS_ENDPOINT and a OS_TOKEN when dealing with keystone v210:00
*** aix has quit IRC10:01
marekdso what is that your are sending to keystone ?10:02
MaxVonly the OS_TOKEN in order to create users and projects10:03
MaxVwhich works on the v2 endpoint10:03
marekdok, but you must send some HTTP request to some url.10:03
marekdwhat is this url for instance?10:04
*** e0ne is now known as e0ne_10:06
MaxVmarekd: ok, so I missed a point with the domain10:08
MaxVmarekd: I noticed it when I get back on the doc10:09
marekdit's weird that it was 40410:09
MaxVmarekd: sorry for the disturbance10:09
marekdMaxV: not a problem at all10:09
*** aix has joined #openstack-keystone10:12
*** e0ne_ has quit IRC10:12
*** e0ne has joined #openstack-keystone10:17
ccardjamielennox: it seems that the problem was the initial POST /v3/auth/tokens request with username/password was taking too long for horizon. When I tested it by hand it was taking about 30 seconds when one of the ldap servers was down.10:35
ccardIf I set use_pool and pool_connection_timeout in the [ldap] section, login from horizon appears to work ok.10:36
jamielennoxccard: ok, good you found it, i would have hoped that if there was a connection error it was reported rather than dropped10:39
jamielennoxis there a firewall or something that is dropping packets rather than rejecting them>10:39
*** fhubik is now known as fhubik_afk10:42
ccardjamielennox: yes, there is a firewall between keystone and ldap, the servers are on different subnets, so the route goes through the firewall.10:43
jamielennoxccard: might be worth checking if you can get the firewall to reject and so it knows it's a bad connection rather than having to wait for timeout10:44
*** lhcheng has joined #openstack-keystone10:45
*** ChanServ sets mode: +v lhcheng10:45
ccardgood idea, I'll talk to the firewall experts round here10:46
*** lhcheng has quit IRC10:50
*** tobe has quit IRC10:50
*** tobe has joined #openstack-keystone10:51
*** henrynash has quit IRC10:53
*** henrynash has joined #openstack-keystone10:56
*** ChanServ sets mode: +v henrynash10:56
*** tobe has quit IRC10:56
*** mabrams has quit IRC11:01
*** e0ne is now known as e0ne_11:12
*** dims has joined #openstack-keystone11:20
*** e0ne_ has quit IRC11:23
*** dims has quit IRC11:25
*** fhubik_afk is now known as fhubik11:26
*** dims has joined #openstack-keystone11:29
*** jdennis has quit IRC11:33
*** e0ne has joined #openstack-keystone11:37
*** kiran-r has joined #openstack-keystone11:41
*** bdossant has quit IRC11:42
*** jdennis has joined #openstack-keystone11:42
*** josecastroleon has quit IRC11:42
*** bdossant has joined #openstack-keystone11:42
*** josecastroleon has joined #openstack-keystone11:44
*** neelabh has joined #openstack-keystone11:45
*** henrynash_ has joined #openstack-keystone11:46
*** ChanServ sets mode: +v henrynash_11:46
*** henrynash has quit IRC11:47
*** henrynash_ is now known as henrynash11:47
neelabhHi Guys, I am in trouble, please help, I am using devstack, openstack(kilo).  I mistaken delete keystone.conf from /etc/httpd/conf.d,  What should I do..11:47
samueldmqneelabh, hi11:48
neelabh<samueldmq>, hi11:48
samueldmqneelabh, you're in a test environment (since you're using devstack), right ?11:48
samueldmqneelabh, have you tried (in the devstack directory): ./unstack.sh and then ./stack.sh again?11:49
neelabhOne more thing I want to tell, I create file keystone.conf from other back-up, but still it is giving proble, should I remove this file before running above command11:51
jamielennoxneelabh: devstack is only for testing, if you run it again it will create the file again11:52
samueldmqjamielennox, ++11:54
neelabhjamielennox, sorry to disturb, One more question, what will be password for admin, I have changed the admin password..11:57
*** kodoku has joined #openstack-keystone11:58
neelabhafter runninng above commad11:58
jamielennoxneelabh: if you didn't set it with an env command then it will generate one randomly11:59
jamielennoxit will be put into the devstack/accrc/admin/admin file11:59
jamielennoxsamueldmq: OSC 1.4 was released so _most_ of the v3 only reviews are working12:00
*** edmondsw has joined #openstack-keystone12:00
jamielennoxsamueldmq: starts here https://review.openstack.org/#/c/186678/12:01
samueldmqjamielennox, oh great, very happy to hear :)12:01
samueldmqjamielennox, at the end of that chain of review .. does it work ? do we need other patches ?12:02
jamielennoxsamueldmq: there's a bug in OSC :(12:05
jamielennoxso i need to look at how i can hack around that because i don't want to wait for a new release again12:05
samueldmqjamielennox, yes makes sense12:05
samueldmqjamielennox, btw is the bug what is making your last patch to fail ?12:05
jamielennoxit made it fail on the vm i was testing on12:06
jamielennoxso i assume so12:06
samueldmqjamielennox, 'Convert identity defaults to keystone v3 api' (https://review.openstack.org/#/c/186684/)12:06
*** kodoku has quit IRC12:06
samueldmqjamielennox, k makes sense12:06
jamielennoxyep that one - and that error12:06
jamielennoxwe're blaming martinelli when you get a chance :p12:07
samueldmqjamielennox, haha12:07
samueldmqjamielennox, so when querying endpoints by name, keystone server returns a list12:08
samueldmqjamielennox, and the client was assuming that would be a single element (however endpoint name doesn't uniquely identify the enedpoint)12:09
samueldmqjamielennox, am I right ?12:09
*** kodoku has joined #openstack-keystone12:10
*** raildo has joined #openstack-keystone12:11
kodokuHi, I try to make that ==> http://docs.openstack.org/security-guide/content/secure-reference-architectures.html But I have Issue with keystone. Keystone bind localhost in http protocol. I have a local apache proxy for SSL.12:11
kodokuBut when I request keystone not works because keystone send me ==> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to http://server:5000/v2.0/tokens12:12
kodokunot https://server:5000.....12:12
kodokuso cinder python client no works because it use this link for make his request12:12
kodokuAny idea for my issue ?12:13
jamielennoxkodoku: so if you've got HA proxy or something else doing the SSL termination you will need to move keystone to something else12:14
jamielennoxeg port 500112:14
jamielennoxand then the terminator will operate on port 5000 and redirect to 500112:15
kodokuwhy ?12:15
jamielennoxkodoku: because only one service can listen on a port12:15
kodokuapache listen on my IP:500012:15
kodokukeystone listen on
kodokuand apache redirect IP:5000 on
kodokuworks now12:16
jamielennoxoh you bound them to the ip?12:16
kodokubut cinder client no works because it use keystone links return12:16
jamielennoxumm, it should work i've never tried12:16
kodokuit works with all service ^^12:16
jamielennoxthe service catalog?12:16
kodokuwhen request on /v2.012:16
jamielennoxso you can do like openstack endpoint list or something similar and change the endpoints12:17
jamielennoxthe easier way i do though is just open up the 'endpoint' table in the database and make sure they are pointing to the public IPs12:17
*** kiran-r has quit IRC12:17
kodokuendpoint is conf on my apache proxy with HTTPS12:17
kodokubecause keystone return  =>  "id": "v2.0", "links": [{"href": "http://juno001:5000/v2.0/", "rel": "self"}, {"href": "http://openstk............12:18
kodokuand my endpoint is https12:18
jamielennoxoh, right12:18
jamielennoxthere is a fix for that...12:18
jamielennoxso you can either set the public_endpoint and admin_endpoint in the keystone.conf12:19
jamielennoxthat will hard code it for you12:19
kodokuI don't know why cinder client use this link and nova client use endpoint links12:19
kodokuCan I force this links in keystone.conf ?12:20
jamielennoxkodoku: this is for GET / on keysotne right?12:20
kodokurequest is => DEBUG:keystoneclient.session:REQ: curl -i --insecure -X GET https://juno001:5000/v2.0/12:21
jamielennoxand GET /v2.0 i guess12:21
jamielennoxkodoku: yes, if you set public_endpoint = https://juno001:5000/v2.0 in keystone.conf it will fix it12:21
jamielennoxyou probably want to do the same with admin_endpoint but for port 3535712:22
*** bknudson has quit IRC12:22
kodokuok, I look conf of keystone thx12:23
*** fhubik has quit IRC12:24
*** fhubik has joined #openstack-keystone12:25
*** mtecer_ has joined #openstack-keystone12:27
kodokujamielennox ok the link is modify :)12:31
*** mtecer_ has quit IRC12:32
*** lhcheng has joined #openstack-keystone12:34
*** ChanServ sets mode: +v lhcheng12:34
*** kodoku has quit IRC12:38
*** lhcheng has quit IRC12:39
*** redrobot has joined #openstack-keystone12:42
*** redrobot is now known as Guest7499312:42
*** Guest74993 is now known as el_robot_rojo12:43
*** el_robot_rojo is now known as redrobot12:44
*** amakarov_away is now known as amakarov12:46
*** henrynash has quit IRC12:47
*** dsirrine has joined #openstack-keystone12:48
*** henrynash has joined #openstack-keystone12:49
*** ChanServ sets mode: +v henrynash12:49
*** bknudson has joined #openstack-keystone12:50
*** ChanServ sets mode: +v bknudson12:50
*** sbezverk has joined #openstack-keystone12:56
sbezverkHello, I am trying to bring up heat in Kilo, when I try to create endpoint with type cloudformation, I get error and keystone.log shows Warining message " Could not find service: cloudformation". Any suggestions how it can be extended or fixed?12:58
*** lhcheng has joined #openstack-keystone12:58
*** ChanServ sets mode: +v lhcheng12:58
amakarovmorganfainberg, hello! May I ask you about an invitation letter again? :)13:00
*** lhcheng has quit IRC13:03
*** kiran-r has joined #openstack-keystone13:03
neelabhjamielennox, Thank-you very much, you save my day....13:03
*** zzzeek has joined #openstack-keystone13:05
*** afazekas has quit IRC13:09
*** ayoung has joined #openstack-keystone13:10
*** ChanServ sets mode: +v ayoung13:10
samueldmqneelabh, great, feel free to come here with questions when you're blocked, #keystone community will be glad to help you13:10
samueldmqneelabh, that's part of why opensource is amazing :)13:10
*** rushiagr is now known as rushiagr_away13:10
viktorslbragstad: hi! Just a tiny reminder about the patch https://review.openstack.org/#/c/80630/13:12
lbragstadviktors: ah cool, you pushed a new patch. Thanks!13:13
*** fhubik has quit IRC13:19
*** richm1 has joined #openstack-keystone13:19
*** fhubik has joined #openstack-keystone13:19
*** richm1 is now known as richm13:20
*** fhubik is now known as fhubik_afk13:22
*** mtecer has joined #openstack-keystone13:29
*** mtecer has quit IRC13:33
*** Ctina has joined #openstack-keystone13:40
*** csoukup has joined #openstack-keystone13:41
openstackgerritMarcos Fermín Lobo proposed openstack/python-keystoneclient: Added endpoint group filter manager methods  https://review.openstack.org/18265813:43
*** neelabh has quit IRC13:43
*** RichardRaseley has joined #openstack-keystone13:44
*** fhubik_afk is now known as fhubik13:45
*** e0ne is now known as e0ne_13:51
*** bdossant has quit IRC13:54
*** e0ne_ is now known as e0ne13:54
*** fhubik is now known as fhubik_afk14:07
*** fangzhou has joined #openstack-keystone14:08
*** woodster_ has joined #openstack-keystone14:09
*** henrynash_ has joined #openstack-keystone14:09
*** ChanServ sets mode: +v henrynash_14:09
*** RichardRaseley has quit IRC14:10
*** fhubik_afk is now known as fhubik14:10
*** fhubik is now known as fhubik_afk14:10
*** henrynash has quit IRC14:10
*** henrynash_ is now known as henrynash14:10
*** sigmavirus24_awa is now known as sigmavirus2414:16
*** RichardRaseley has joined #openstack-keystone14:18
lbragstado/ dolphm wondering if I could get your input on this guy https://bugs.launchpad.net/keystone/+bug/146544414:20
openstackLaunchpad bug 1465444 in Keystone "Fernet key rotation removing keys early" [High,Triaged] - Assigned to Dolph Mathews (dolph)14:20
lbragstaddolphm: oh, nevermind, you've already seen it14:20
ayoungmorganfainberg, I'm blown away.  That presentation rocks.14:20
morganfainbergamakarov: I passed on the info to the foundation. I will follow up today/tomorrow.14:21
amakarovmorganfainberg, thank you14:21
morganfainbergayoung: it still needs work. It's a descent primer on keystone, but some slides are still too verbose and a few graphics need to be cleaned up.14:22
ayoungmorganfainberg, yeah, I have an hour...lots of slides to get through in that time14:22
morganfainbergayoung: I also want to change the section breaks and title slide/questions slide theme.14:22
ayoungmorganfainberg, also,  SSSD is not future work...it can be done today...I think I'm miving that slide to after the SAML flow in federation14:23
morganfainbergThis deck was designed for ~40-45 min including 5min q&a14:23
ayoungI'll try to get something more clear about how it works.14:23
ayoungmorganfainberg, that should be perfect....you are making me look good here....14:23
morganfainbergBut easy to expand, esp if there is any interactive stuff.14:23
morganfainbergGive Steve credit too, he did a huge chunk of it.14:24
ayoungmorganfainberg, I'm working on a "set up a demo" code base, using the python clients.  Once I get it to a reasonable level, I'll share14:24
morganfainbergThis was a collaboration between us, and stealing some of nkinder's graphics.14:24
bknudsonis the presentation posted somewhere?14:24
ayoungmorganfainberg, I was going to give him props first, but as you see, he is not here.. I'll thank him later14:24
bknudsonI'd like to have something to point people at14:25
morganfainbergbknudson: it will be soon. Need to convert to html14:25
ayoungbknudson, its being shared around on google docs.  I made a copy that I am hacking on a bit14:25
morganfainbergbknudson: on my short list for this week while I'm mostly afk from irc14:25
morganfainbergThen I'll get it published.14:25
morganfainbergOh..  I need to setup the "call for a new keystone mascot" and subsequent logo email.14:27
ayoungmorganfainberg, should I add an "authors" slide at the end?14:27
morganfainbergayoung: sure.14:27
morganfainbergIf you want.14:27
morganfainbergI won't be upset if you don't ;)14:27
ayoungmorganfainberg, so, you, steve , nate...anyone else?14:27
morganfainbergSteve, Nate, me, and you if your hacking on it.14:28
* morganfainberg kicks autocorrect14:28
*** henrynash has quit IRC14:28
bknudsonshould be called autoincorrect14:29
*** kiran-r has quit IRC14:29
*** kiran-r has joined #openstack-keystone14:29
*** blewis has joined #openstack-keystone14:30
*** Guest68660 is now known as mfisch14:30
*** mfisch is now known as Guest8122614:31
morganfainbergbknudson: yes14:32
ayoungmorganfainberg, do you want your gmail or your HP email address on it?14:32
morganfainbergGmail plz14:32
morganfainbergIf you put a title then it's master technologist, hp. But I don't use hp email for upstream.14:32
*** henrynash has joined #openstack-keystone14:33
*** ChanServ sets mode: +v henrynash14:33
*** dsirrine has quit IRC14:33
ayoungmorganfainberg, nah, just doing the email address.14:35
*** kiran-r has quit IRC14:35
*** dsirrine has joined #openstack-keystone14:35
*** henrynash_ has joined #openstack-keystone14:37
*** ChanServ sets mode: +v henrynash_14:37
*** Guest81226 has quit IRC14:38
*** henrynash has quit IRC14:39
*** henrynash_ is now known as henrynash14:39
bretonthere was patch https://review.openstack.org/#/c/127066/14:40
bretonwhich options should be used instead of deprecated ones?14:40
bretonare they listed on http://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html ?14:41
*** obedmr has joined #openstack-keystone14:43
bknudsonbreton: http://www.jamielennox.net/blog/2015/02/23/v3-authentication-with-auth-token-middleware/14:46
*** ayoung has quit IRC14:46
*** e0ne is now known as e0ne_14:47
*** e0ne_ is now known as e0ne14:47
*** henrynash_ has joined #openstack-keystone14:49
*** ChanServ sets mode: +v henrynash_14:49
bretonbknudson: thank you14:49
*** stevemar has joined #openstack-keystone14:50
*** ChanServ sets mode: +v stevemar14:50
stevemarjamielennox, so close!14:51
*** henrynash has quit IRC14:52
*** henrynash_ is now known as henrynash14:52
*** henrynash has quit IRC14:54
*** henrynash has joined #openstack-keystone14:54
*** ChanServ sets mode: +v henrynash14:54
*** fhubik_afk is now known as fhubik14:56
*** mfisch has joined #openstack-keystone14:56
*** mfisch is now known as Guest2567614:56
*** ayoung has joined #openstack-keystone15:00
*** ChanServ sets mode: +v ayoung15:00
*** Guest25676 is now known as mfisch15:01
*** mfisch has quit IRC15:02
*** mfisch has joined #openstack-keystone15:02
openstackgerritDiane Fleming proposed openstack/keystone-specs: Add side-by-side comparison table of v2 and v3 APIs  https://review.openstack.org/18702715:03
*** belmoreira has quit IRC15:05
*** jaypipes has quit IRC15:06
*** henrynash_ has joined #openstack-keystone15:07
*** ChanServ sets mode: +v henrynash_15:07
*** fhubik is now known as fhubik_afk15:08
*** henrynash has quit IRC15:10
*** henrynash_ has quit IRC15:13
*** henrynash has joined #openstack-keystone15:14
*** ChanServ sets mode: +v henrynash15:14
*** ngupta has joined #openstack-keystone15:14
*** Ctina has quit IRC15:14
dstanekgood morning all15:15
*** Ctina has joined #openstack-keystone15:15
*** RichardRaseley is now known as RichardRaseley|A15:15
bknudsondstanek: happy birthday15:16
dstanekbknudson: thx15:16
lbragstaddstanek: mornin'15:17
*** henrynash_ has joined #openstack-keystone15:18
*** ChanServ sets mode: +v henrynash_15:18
*** henrynash has quit IRC15:20
*** henrynash_ is now known as henrynash15:20
*** kfox1111 has joined #openstack-keystone15:21
*** henrynash_ has joined #openstack-keystone15:23
*** ChanServ sets mode: +v henrynash_15:23
*** eandersson has joined #openstack-keystone15:24
*** henrynash has quit IRC15:26
*** henrynash_ is now known as henrynash15:26
*** fhubik_afk is now known as fhubik15:26
*** fhubik has quit IRC15:27
*** thedodd has joined #openstack-keystone15:27
*** henrynash_ has joined #openstack-keystone15:41
*** ChanServ sets mode: +v henrynash_15:41
*** henrynash has quit IRC15:44
*** henrynash_ is now known as henrynash15:44
richmWith the v2.0 API and the openstack user create command, doing --project projname would create the user and add the new user to the given project15:44
richmWith the v3 API, openstack user create --project projname does not add the new user to the project, using token credentials15:45
richmIs this something that is allowed/denied by the policy?15:45
richmIf so, what is the policy?  update_project?15:47
richmnote I have updated the policy to use is_admin:1 everywhere that users/projects are referenced in the policy15:50
richmI'm hoping that this will involve a simple fix before I have to go off and implement support for adding the user to the project in puppet . . .15:51
*** fangzhou has quit IRC15:52
*** ayoung has quit IRC15:57
eanderssonIs there a specific reason why a call to v3/ec2tokens would not return the values for access?16:00
eanderssonIt causes this heat code to fail https://github.com/openstack/heat/blob/master/heat/api/aws/ec2token.py#L22116:02
*** henrynash_ has joined #openstack-keystone16:03
*** ChanServ sets mode: +v henrynash_16:03
*** RichardRaseley|A is now known as RichardRaseley16:04
*** henrynash has quit IRC16:05
*** henrynash_ is now known as henrynash16:05
*** ayoung has joined #openstack-keystone16:10
*** ChanServ sets mode: +v ayoung16:10
*** browne has joined #openstack-keystone16:17
samueldmqdstanek, morning, happy birthday :)16:23
dstaneksamueldmq: thx16:28
*** henrynash_ has joined #openstack-keystone16:28
*** ChanServ sets mode: +v henrynash_16:28
*** henrynash has quit IRC16:31
*** henrynash_ is now known as henrynash16:31
*** MaxV has quit IRC16:32
*** tqtran has joined #openstack-keystone16:32
samueldmqayoung, could you please take a look at https://wiki.openstack.org/wiki/DynamicPolicies when you have a chance ?16:33
*** kiran-r has joined #openstack-keystone16:35
*** blewis has quit IRC16:39
samueldmqayoung, I will add a point to our today's meeting .. to discuss about timing ... and what we possibly could be addressing this release (the scope from the global roadmap)16:39
samueldmqayoung, sounds good ?16:39
*** rushiagr_away is now known as rushiagr16:43
*** _cjones_ has joined #openstack-keystone16:43
*** henrynash has quit IRC16:44
*** kiran-r has quit IRC16:45
*** e0ne has quit IRC16:48
*** kfox1111 has quit IRC16:49
*** kfox1111 has joined #openstack-keystone16:50
*** dguerri is now known as dguerri`16:53
*** thedodd has quit IRC16:53
*** RichardRaseley has quit IRC16:56
ayoungsamueldmq, looking now16:57
ayoungsamueldmq, I don't think the user stories are quite right, but its a great  starting point for discussion16:58
*** dguerri` is now known as dguerri16:58
ayoungStory 4 - As a user, I want to define role hierarchies, allowing one to only delegate a subset of her roles16:58
ayounglets start there16:58
*** dguerri is now known as dguerri`16:59
ayoung"As a user, I want to request a long running task for a remote service, and only delegate to the remote service the minimal amount of authority necessary to perform that task."16:59
ayoungso that user is going to consume the role hierarchy16:59
ayoungit requires support from the admins....16:59
*** Ephur has joined #openstack-keystone17:00
samueldmqayoung, as far as I understand, a user should be able to delegate a subset of her roles, right ?17:01
ayoungsamueldmq, right, but the use is not going to be setting up the role hierarchy17:02
samueldmqayoung, it doesn't matter the one she is delegating to (maybe a service)17:02
ayoungjust consuming it17:02
samueldmqayoung, who defines the roles ?17:02
samueldmqayoung, hierarchies ...17:02
ayoungan end user does not "define role hierarchies,"17:02
samueldmqayoung, I am talking about the definition on that user story ...17:02
samueldmqayoung, yes I agree I need to be more specific,17:02
samueldmqayoung, 'As an admin'...'17:03
samueldmqayoung, since I am talking about the role hierarchy definition17:03
samueldmqayoung, makes sense?17:03
ayoungsamueldmq  the role hierarchy is defined global to the openstack deployemnt, and needs to map to the APIs for the individual endpoint17:03
ayoungthe endpoint admin should be saying what role a user needs in order to be able to execute an API17:03
ayoung"As a domain admin, I want to define roles that are meaningful to my business"  is a good one17:04
ayoungso...lets extend that.17:04
ayoung"As an endpoint admin, I want to define what roles a user needs to be able to access an API"17:04
samueldmqayoung, who creates the role hierarhcy ? we provide that with the keystone bootstrap ? by default ? (we don't create the admin role automatically today)17:04
*** lufix has joined #openstack-keystone17:04
ayoungsamueldmq, good question...that might be the key question17:05
stevemarrichm, around?17:06
samueldmqayoung, I think anyone with power to create roles should be able to create them hierarchically17:06
ayoungsamueldmq, if the domain admin is defining roles for their organization, then the domain admin must also be defining at least a portion of the role hierarchy17:07
samueldmqayoung, exactly17:07
ayounglets put it under the domain admin in the use case list, then17:07
samueldmqayoung, and by default ,we could be talking about 'cloud', 'domain' and 'project' admins17:07
samueldmqayoung, which solves the global admin issue, and is a simple but good default17:07
ayoungsamueldmq, I don't think, at this stage, we allow project admins to define new roles17:08
ayoungif we were to do  that...it would almost make sense to expand the roles on the keystone side instead of in the policy engine17:08
ayoungwhat if....17:09
*** blewis has joined #openstack-keystone17:09
ayoungI still like the idea of splitting the policy check up into a role check and a scope check.  I think that is key17:10
ayoungonly role checks are dynamic17:10
samueldmqayoung, trhere is an user story for that17:10
ayoungscope checks should be coded by the project team17:10
samueldmqayoung, exactly17:10
ayoung" As a dev, I want to split policy enforcement between Middleware and the services"17:10
samueldmqayoung, yes, sounds good ?17:10
ayoungsamueldmq, those are not usually user stories17:11
ayoungbut...in this mcase ,sure17:11
ayoung why not17:11
samueldmqayoung, :)17:11
samueldmqayoung, that's why I put 'As a *dev*'17:11
samueldmqayoung, since that isn't affecting external behavior17:11
ayoung"as an application developer I want to enforce the scope check separate from the role check"17:12
ayoungsamueldmq, I get it...it allows us to treat the other openstack services as just other types of users.  I like that17:12
*** spandhe has joined #openstack-keystone17:12
samueldmqayoung, not sure I follow what you just got :)17:13
ayoungsamueldmq, lets run with this approch::  what use cases do we need to support, Nova, glance, etc...17:13
samueldmqayoung, get use cases from them ?17:13
*** htruta_ has joined #openstack-keystone17:13
ayoung"as an application deployer, I want to register my application with Keystone so it can manage policy for me?"17:13
samueldmqayoung, the use cases, from lets say, nova, will be associated in one of those specs17:14
ayoungsamueldmq, lets say that a deployer wants to add a new application to an existing cloud...something that Keystone didn't know about ahead of time17:14
ayoungif we solve that, we shoudl also solve what Keystone needs to do for Nova etc today17:14
samueldmqayoung, for example, that's not about 'we need to upload service policy to keystone', but 'how we do that ? from code (what they said), etc'17:14
ayoungsamueldmq, "from Code" I think means a couple different things17:15
ayoung1.  get decent defaults17:15
ayoung2. making sure it extends as new APIs are added without each api developer having to be a policy expert17:15
*** fangzhou has joined #openstack-keystone17:15
ayoung3.  making sure it is enforces with a reasonable default prio to the service getting fully "integrate" into Keystone, whatever that may mean17:16
ayoungSo...here is a new use case:17:16
samueldmqayoung, the CMS should upload the endpoint's policy based on its url (when it is setting the endpoiint on keystone as well)17:16
ayoung"as an application developer I want to add policy enforcement for a new API"17:16
samueldmqayoung, if there is a change from the default (we store that separetely on keystone), we should warn17:17
samueldmqayoung, that covers their needs  ^17:17
*** blewis` has joined #openstack-keystone17:17
*** neelabh has joined #openstack-keystone17:17
ayoungsamueldmq, are you editing the Wiki doc with these changes?17:18
samueldmqayoung, yes17:18
openstackgerritRodrigo Duarte proposed openstack/keystoneauth: Add Keystone2KeystoneAuthPlugin for K2K federation  https://review.openstack.org/18858117:19
samueldmqayoung, but .. 'as an application developer I want to add policy enforcement for a new API'17:19
samueldmqayoung, this would be solved with the CMS uploading the policy for that endpoint to keystone17:19
samueldmqayoung, wouldn't it ?17:19
samueldmqayoung, let me show you how I see things:17:20
*** blewis has quit IRC17:20
samueldmqayoung, i) cms create endpoint in keystone ii) upload default policy and associate to endpoint based on its URL17:20
samueldmqayoung, do this ^ for each endpoint being added on the system17:21
samueldmqayoung, if an endpoint was upgraded, do ii) ... updating its default17:21
samueldmqayoung, if something is different from the default, warn (should be nova use case)17:22
samueldmqayoung, (we should be storing 'default' and 'actual' policy, somehting like that)17:22
samueldmqthat's how I see17:22
ayoungsamueldmq, I think it would be something like an "upload-but-don't override" approach17:23
ayoungsamueldmq, lets say nova ships with policy.json that has their defaults17:23
ayoungehtn, they add a newe API.  But, in the meantime, the deployment has customized the policy for the other APIS17:23
samueldmqayoung, the 'actual' policy will be kept, only the default one will be updated17:24
ayoungwhen the Nova code updates, they upload the default file.  For any rules that are not in the existing poiocy DB, they add the new rules, but ignore all the other old ones17:24
samueldmqayoung, 'actual' contains what you customized, based on default17:24
*** gyee has quit IRC17:24
samueldmqayoung, and getting the policy is : GET 'default' + override what is in 'actual'17:25
ayoungbut, if we associate an endpoint with an explicit policy, the new APIs would not get protected by the rules...or would get the default rule17:25
*** pnavarro has quit IRC17:25
*** rushiagr is now known as rushiagr_away17:25
david8huayoung, good idea.  We don't want to override the policy that is already in the db.17:25
*** Ephur has quit IRC17:25
openstackgerritOpenStack Proposal Bot proposed openstack/oslo.policy: Updated from global requirements  https://review.openstack.org/19231017:26
ayoungdavid8hu, but we also want to cover existing endpoints with new and updated APIs...it is a tricky problem17:26
samueldmqayoung, if you just upgraded ... you will get the defaults, unless you customize what comes from defualt17:26
samueldmqayoung, and I think that makes sense17:26
*** gyee has joined #openstack-keystone17:26
*** ChanServ sets mode: +v gyee17:26
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements  https://review.openstack.org/19231917:26
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient-saml2: Updated from global requirements  https://review.openstack.org/19232017:26
ayoungsamueldmq, did you read http://adam.younglogic.com/2015/06/dyn-policy-microversions/17:28
samueldmqayoung, http://paste.openstack.org/show/295858/17:29
samueldmqayoung, that covers the case where a new api is added17:29
samueldmqayoung, yes I did, and following this approach solves that as well ^17:29
samueldmqayoung, considering 'compute:create_container:v3.14.15'17:29
samueldmqayoung, since it would be like a new API added17:30
ayoungendpoint X {'a':'1', 'b':'2'}17:30
samueldmqvery basic example :)17:30
ayoungsamueldmq, don't you mean APIs there?17:30
samueldmqayoung, yes sure, I am just communicating about the way we work, not about the content right now17:30
ayoungare you thinking in terms of the database driven approach, and uploading a rule for a new API?17:30
samueldmqayoung, those are APIs for sure17:31
ayoungOK...those are not endpoints17:31
ayoungtargets, Ithink; is the term you want17:31
samueldmqayoung, let me get you a more concrete example17:31
ayoungsamueldmq, nah, I get it...17:31
samueldmqayoung, nice :)17:32
samueldmqayoung, does that make sense ?17:32
samueldmqayoung, we solve what we want + what nova people want, and that is simple17:32
ayoungsamueldmq, yeah, I was essentially saying the same thing, but assuming that you are uploading a whole policy file at once17:32
samueldmqayoung, although that does not include unified policy, (what would be fine, at least for now imo)17:32
ayoungsamueldmq, so...think in terms of unified policy.  And default policy.  If we upload a new set of targets, those should get merged in to the default policy17:33
samueldmqayoung, for example ?17:34
samueldmqayoung, let's ship individual policies that make sense in a whole, together17:35
samueldmqayoung, with consistent common rules (is_admin ?), we should be able to put them together later if we want17:35
*** lhcheng has joined #openstack-keystone17:37
*** ChanServ sets mode: +v lhcheng17:37
samueldmqayoung, this way we do a smaller set of changes, that already fits our needs + other people needs + fixes 96869617:37
david8husamueldmq, I like the idea.  We can get the policy right without going unified first.17:37
samueldmqayoung, yes, 96869617:37
*** aix has quit IRC17:37
samueldmqayoung, you'll be happy (everybody will) solving that 968696 :)17:37
ayoungsamueldmq, one sec...17:38
samueldmqayoung, and we attack that in a baby steps appraoch17:38
samueldmqayoung, sure17:38
*** lufix has quit IRC17:38
samueldmqdavid8hu, yes I think that makes more sense, we change less and get what we want for now17:38
david8husamueldmq, ayoung, all we need is a better default to solve 968696 from get go.17:38
*** dguerri` is now known as dguerri17:38
samueldmqdavid8hu, + more power when defining roles + dynamically management of policies17:39
samueldmqdavid8hu, I think you had said me people from your team were working on providing better defaults17:40
samueldmqdavid8hu, maybe it was not you, I am just confirming :)17:41
david8husamueldmq, I was me :)17:41
samueldmqdavid8hu, nice !17:41
samueldmqdavid8hu, I still have some working memory in my head17:42
david8husamueldmq, Not corrupted at all;)17:43
*** csoukup has quit IRC17:51
*** roxanaghe has joined #openstack-keystone17:51
stevemarkeystoners, reminder to populate the wiki with meeting topics: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting17:55
samueldmqstevemar, done ! : )17:55
stevemarsamueldmq, ty!17:55
samueldmqayoung, just put a topic to let people know how things on dynamic policies are17:56
marekdstevemar: i just removed one topic.17:56
stevemarmarekd, the idp deletion one?17:56
marekdstevemar: nope, i had one k2k in kmw, but i've dicussed it with jamie this morning.17:59
stevemarmarekd, cool, if theres time we can chat about it17:59
*** marzif_ has joined #openstack-keystone18:00
*** csoukup has joined #openstack-keystone18:01
*** marzif has quit IRC18:01
*** henrynash has joined #openstack-keystone18:02
*** ChanServ sets mode: +v henrynash18:02
*** henrynash_ has joined #openstack-keystone18:04
*** ChanServ sets mode: +v henrynash_18:04
*** henrynash has quit IRC18:06
*** henrynash_ is now known as henrynash18:06
*** jasondotstar has joined #openstack-keystone18:07
*** Ctina_ has joined #openstack-keystone18:10
*** Ctina has quit IRC18:13
*** htruta_ has quit IRC18:25
*** esp has left #openstack-keystone18:29
*** lhcheng has quit IRC18:32
*** lhcheng has joined #openstack-keystone18:32
*** ChanServ sets mode: +v lhcheng18:32
*** blewis` has quit IRC18:33
*** lhcheng_ has joined #openstack-keystone18:34
*** gokrokve has joined #openstack-keystone18:34
*** marzif has joined #openstack-keystone18:36
*** lhcheng has quit IRC18:38
*** e0ne has joined #openstack-keystone18:47
*** lhcheng_ is now known as lhcheng18:52
*** ChanServ sets mode: +v lhcheng18:52
*** pauloewerton has joined #openstack-keystone18:53
*** tqtran is now known as tqtran_afk19:01
gyeestevemar, nice job running the show!19:01
stevemargyee, danke19:01
ayounggyee, so, on endpoint binding,  the endpoint does not know its own ID19:01
*** tqtran_afk is now known as tqtran19:01
ayoungwhat we were saying for policy is that we are going to enforce by endpoint URL19:01
gyeeayoung, you can :)19:01
ayoungis that what you have coded?19:01
*** gokrokve has quit IRC19:01
gyeeayoung, its all determine by policy19:02
*** gokrokve has joined #openstack-keystone19:02
ayounggyee, hmmm19:02
gyeeayoung, btw, your changes to oslo policy made it possible :)19:02
ayounggyee, so there is something missing19:02
ayoungif we do dynamic poolicy, there will be no way of saying "this is what My hostname is"19:03
ayoungor something like that19:03
ayoungunless we rewrite rules upon fetch from Keystone...yuck19:03
gyeeayoung, %(host)s19:04
ayoungbetter to have something that pulls the URL out of the config file, yeah, like that19:04
*** zzzeek has quit IRC19:04
gyeeright, its a few lines of chef/ansible/puppet/whatever19:04
*** amakarov is now known as amakarov_away19:04
ayounggyee, right, and we want that for the policy fetch as well.  We want to make sure we are in sync on both sides; fetching and enforcing policy19:05
ayoungso instead of {"global": "token.catalog.endpoints.id:%(endpoint_id)s"}19:05
ayoungis should be19:05
*** zzzeek has joined #openstack-keystone19:05
ayoung{"global": "token.catalog.endpoints.url:%(endpoint_url)s"}19:05
gyeeayoung, where do we get the params?19:06
ayounggyee, yes19:06
ayoung[auth_token] section19:06
gyeeayoung, yes, endpoint_id is already there19:06
ayoungCONF.auth_token.endpoint_url?  samueldmq ?  morganfainberg that works, right?19:06
ayounggyee, not ID19:06
gyeewhy not?19:07
ayounggyee, ID is assigned by keystone. Puppet will only know hostname19:07
*** gokrokve has quit IRC19:07
ayoungso it could precalculate the URL, but not the ID19:07
gyeeayoung, it could be a two step configuration19:07
morganfainbergayoung: yes19:07
ayounggyee, as you said, " its a few lines of chef/ansible/puppet/whatever"  to set the URL, but more so to set the ID, and then we'd have to reread the config19:07
morganfainbergdo not use a uuid, use a url19:07
ayounggyee, ^^19:07
ayoungwe've already decvdied we are doing this for fetch of the policy19:08
gyeeso you want both endpoint_id and endpoint_url or just endpoint_url?19:08
morganfainbergand it can even be a template if you need to handle project/domain replacement19:08
*** Ephur has joined #openstack-keystone19:08
ayounggyee, just URL19:08
morganfainbergjust the url that the endpoint knows it's own id.  you need to know the url a priori anyway19:08
gyeeayoung, morganfainberg, how about I pass in whatever from the auth_token section?19:09
*** neelabh has quit IRC19:09
morganfainberggyee:  i have no idea what you're proposing19:09
ayounggyee, so long as the CONF is in the policy enforcement dictionary, I think we can support it19:09
ayoungso it would look like19:09
gyeemorganfainberg, for policy enforcement19:09
morganfainbergbut long and the short is the URL should be the id that is used for endpoint enforcement, etc19:09
ayoung{"global": "token.catalog.endpoints.url:%(CONF.auth_token.endpoint_url)s"}19:09
gyeeenforce(global, CONF, cred)19:10
morganfainbergsince a uuid becomes a 2+step setup and requires restarting after injecting things into keystone19:10
morganfainbergthats all.19:10
morganfainbergayoung: you've got what i'm looking for.19:10
gyeek, easy change then19:10
* morganfainberg ducks out again.19:10
gyeeso to summarize, support CONF.auth_token.endpoint_url19:11
gyeeand keep the functionality in auth_token, no separate middleware19:11
gyeeI'll have a patch ready after lunch19:11
ayounggyee, do we need the check  if not auth_ref.has_service_catalog():19:11
ayoungor will the policy fail anyway?19:11
gyeeayoung, yes, there's a check there already19:11
ayoungmorganfainberg, Ok, so here is my new thinking19:12
ayoungwe get gyee '19:12
ayoungs patch in19:12
ayoungthen we use that as the start point for the next step of DYn Policy19:12
gyeeayoung, yeah, we can build the policy fetch on top of it19:13
ayoungwe split the policy files into a static portion and a dynamic portion, and enforce the dynamic here, based on API,19:13
ayoungscope check stays where it is now, in the code embedded in the projects19:13
ayoungwe keep the role check completely separate from the scope check.  THis part would just do checks likeL19:13
ayoung"GET /v3/users/" : "role:member"19:14
gyeehow do we split policy files?19:15
ayounggyee, chainsaw!19:16
gyeeits one giant JSON right now19:16
ayounggyee, seriously, though, we just remove the role check from the ones from the projects, and add in explicit scope checking19:16
*** Rockyg has joined #openstack-keystone19:16
gyeelemme think it over at lunch19:16
ayounggyee, please do,19:16
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/19040519:16
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/19237519:16
gyeek, gotta run19:17
ayounggyee, the idea is that matchins "where is the scope on this request" is not something we want end users to change19:17
samueldmqayoung, gyee so we agreed on using the CONF.auth_token.endpoint_url for token endpoint binding ?19:18
*** pnavarro has joined #openstack-keystone19:18
ayoungsamueldmq, I think we agreed to that.19:19
*** sbezverk has quit IRC19:19
samueldmqayoung, the issue with endpoint_url for fetchign the policy is that an URL can map to multiple endpoint ids, and consequently to multiple policies19:19
samueldmqayoung, morganfainberg said me to rethink the policy CRUD as it didn't exist19:20
samueldmqayoung, in sumary, we need to provide an explicity way to assign policy to URL19:20
samueldmqayoung, Story 1 in https://wiki.openstack.org/wiki/DynamicPolicies#Dynamic_Policies19:20
ayoungsamueldmq, is that true>19:21
*** mtecer has joined #openstack-keystone19:21
ayoungI thought that an endpoint URL had to be unique19:21
samueldmqayoung, it isn't :/19:21
samueldmqayoung, in devstac, glance has 3 enpoints with the same :9292 url19:21
samueldmqayoung, differing on admin, public and internal interfaces19:22
ayoungsamueldmq, I got ERROR: openstack More than one endpoint exists with the name ''19:22
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/19238619:23
samueldmqayoung, exactly ... but in this openstack client specifically, it is a bug (it should show the list)19:23
samueldmqayoung, jamielennox was talking about this error earlier today ^19:23
ayoungsamueldmq, the thing is, we really don't care...19:23
ayoungthe server is going to use the same policy file19:24
samueldmqayoung, we allow people to define policy per endpoint id19:24
ayoungso, the fact that the endpoint has multiple IDs is irrelevant19:24
samueldmqayoung, what do I do if I get multiple policies from /policies?endpoint_url=<encoded_url>19:24
ayoungsamueldmq, let's propose a constraint in Keystone:  if two endpoint IDs have the same URL they have the same policy association19:24
samueldmqayoung, we need to fix that, we need an explicit way to associate a policy with an URL19:25
samueldmqayoung, that might work, but how to migrate ?19:25
ayoungmake it implicit, based on the existing API, and a new API to set it by URL, too19:25
ayoungsamueldmq, I'll write up that spec19:25
*** harlowja has quit IRC19:25
samueldmqayoung, ok but we need to sync up with morganfainberg on that point19:25
samueldmqayoung, a spec should be good19:25
ayoungsamueldmq, I will19:26
ayounghaving the spec just gives us a place to record comments19:26
samueldmqayoung, I will update that dynamic policy wiki with our ealier conversation19:26
samueldmqayoung, and I will put a workflow on how things would work in general, as I was talking to you earlier19:26
samueldmqayoung, if you agree on that, it would be amazing, since it fits nova requirements as well19:27
morganfainbergayoung: why do we care about the uuid?19:28
morganfainbergit's useless as an identifier for the API in this case for the endpoint19:28
ayoungmorganfainberg, only because that is how the existing API works19:28
morganfainbergso lose the current api19:28
morganfainbergno one is using it19:28
morganfainbergit is terrible.19:28
morganfainbergcargocult programming/APIs is a bad idea.19:29
ayoungmorganfainberg, so,  we can deprecate it, but for now, lets put the constraint that it defaults to assigning the policy by the URL associated with that ID19:29
morganfainbergi am against using the current API at all. fwiw19:29
ayoungthe big thing is fetch by URL19:29
morganfainbergi don't want to wedge extra stuff on top of a poorly designed API here that no one uses.19:29
ayoungmorganfainberg, agreed.  We'll add 2 API calls19:29
samueldmqI think providing a way to associate by URL + fetch by URL would be great19:30
ayoung1.  Associate policy with endpoint_url19:30
ayoung2. Fetch policy by endpoint URL19:30
samueldmqayoung, ++++19:30
morganfainbergyou know what.. i don't care fine do that.19:30
ayoungin addition, we'll change the existing code to associate with the endpoint_url if it comes in via ID19:30
morganfainbergyou're makin the UX beyond awful here.19:30
ayoungand we'll deprecate at the same time19:30
morganfainbergjust direclty use the url19:30
morganfainbergdon't bother with the current api at all19:30
* morganfainberg doesn't see a need to layer things on something no one uses because it's unusable19:31
ayoungmorganfainberg, what do you mean by "just direclty use the url"19:31
samueldmqany endpoint containing that url, will map to the policy associated to that url19:31
morganfainbergthe id is the url.19:31
morganfainbergno API with UUIDs19:31
morganfainbergor b64 url19:31
ayoungmorganfainberg, please don't tease me19:31
ayoungI hate UUIDs as much as youi19:31
ayoungprobably more19:31
morganfainbergayoung: i'm serious, throw away the current API as useless. no one can use it.19:32
* morganfainberg is needing food soon, so will not continue this.19:32
samueldmq /policies/<policy_id>/endpoints/<encoded_url> ?19:32
morganfainbergif you need to keep the current API, fine.19:32
ayoungmorganfainberg, I'm not the one that decided the rules here19:32
morganfainbergso i have no ide awhat policy_id is meant to represent19:32
morganfainbergayoung: assume /policy is dead, use /rbac_policy :P19:33
samueldmqmorganfainberg, you create a policy, then you associate it with an URL19:33
ayoungmorganfainberg, um...different API19:33
samueldmqmorganfainberg, or should endpoint_url be a prperty of policy ?19:33
ayoungmorganfainberg, one sec....19:33
morganfainbergayoung: yep. just make a new API, assume policy was poorly thought out subsystem19:33
morganfainbergand should go away19:33
ayoungmorganfainberg, we are talking http://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3/identity-api-v3-os-endpoint-policy.rst19:33
* morganfainberg should really be not on IRC.19:34
*** mtecer has quit IRC19:34
ayoungwe want most of that anyway19:34
samueldmqmorganfainberg, go, enjoy o/19:34
ayoungthe only part that really needs to change is the fetch19:34
* samueldmq is going afk for a bit ... he needs some food19:34
ayounghttp://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3/identity-api-v3-os-endpoint-policy.rst#n220  is the API we were planning on using before changing over to fetching by URL19:34
*** RichardRaseley has joined #openstack-keystone19:38
openstackgerritDoug Hellmann proposed openstack/keystone: Update version for Liberty  https://review.openstack.org/19240519:51
*** csoukup has quit IRC20:00
openstackgerritayoung proposed openstack/keystone-specs: Policy by URL  https://review.openstack.org/19242220:02
*** kfox1111 has quit IRC20:03
ayoungsamueldmq, ^^20:06
*** gokrokve has joined #openstack-keystone20:08
*** henrynash has quit IRC20:09
*** Ctina_ has quit IRC20:15
samueldmqayoung, great, will add to the wiki20:22
richmstevemar: sorry, back now20:42
stevemarrichm, that was a long lunch20:42
stevemarrichm, was gonna ask about your ML post20:42
stevemarrichm, oh, just if you could give me more info on what's going on20:50
*** tqtran is now known as tqtran_afk20:51
*** e0ne has quit IRC20:53
samueldmqayoung, morganfainberg dynamic policy workflow: http://paste.openstack.org/show/296334/20:56
samueldmqthis fits what we need + nova requirements20:56
samueldmqayoung, let me know what you think about this20:56
samueldmqayoung, I want your opinion before putting that on the wiki20:57
richmstevemar: let me first start by saying that I don't know if it is an issue with OSC - perhaps Keystone changed such that in v3, openstack user create --project $project does not add the new user to $project - I don't know, I haven't tried the REST API directly20:57
ayoungI have not looked at it yet and already know I like it20:57
ayoungsamueldmq, step 3 is unnecssary20:57
ayoungdefault will be associated by....default.  But I like that you called that out...maybe move it to the front of the flow20:58
richmstevemar: All I know is that with v2.0, openstack user create --project $project adds the new user to $project, and with v3, it doesn't20:58
samueldmqayoung, step 3 is what allow us to cover nova case20:58
richmstevemar: If that is by design, ok, I'll work around it in puppet20:58
samueldmqayoung, I was planning to have two "policies" by endpoint, the default uploaded by the CMS at bootstraping20:58
ayoungsamueldmq, start with "CMS uploads default policy to Keystone"20:58
samueldmqayoung, + the custom, defined by the user, who may get warnings when going away from the default20:59
samueldmqayoung, that's for comparison20:59
ayoungthen upload a second and associate it explicitly with the endpoint20:59
ayoungyou are on the right track, though20:59
ayoungsamueldmq, how'd you generate that diagram>20:59
samueldmqayoung, so default policy is per service, njot per endpoint ?20:59
samueldmqayoung, by hand ... 5 hours to do so21:00
ayoungsamueldmq, default policy is for everything21:00
samueldmqayoung, kidding ...  http://asciiflow.com/21:00
ayoungsamueldmq, heh21:00
ayoungsamueldmq, so...there is a better tool,  let me find the link21:00
samueldmqayoung, and when we do away from the defaults, we get the warnings nova people want21:00
samueldmqayoung, so you agree with the direction I am following there ..21:01
ayoungsamueldmq, http://interactive.blockdiag.com/seqdiag/21:01
samueldmqayoung, the single point of divergence between that representation and what you want is whether define the unified policy or not21:01
ayoungsamueldmq, yes, very much so.21:01
ayoungsamueldmq, so, if we don't do default policy, we don't get a unified roles hierarchy, and we need to make that happen by hand...which means we jump ahead to the database code21:02
ayoungunified is, I think, the right point, we just need to handle the microversions21:02
ayoungbut, I think unified policy becomes much easier if we drop the scope portion and just do roles21:03
samueldmqayoung, what if we do that without unified for now, should we fail ?21:03
samueldmqayoung, I mean, as I described in that diagram21:03
samueldmqayoung, I think that is a very good scope for L21:03
samueldmqayoung, role hierarchies, per domain, unified, etc could come later21:04
samueldmqayoung, that way we can bring the dynamic fetchign this cycle21:04
*** pnavarro has quit IRC21:05
ayoungsamueldmq, without unified poliyc, at a minimum we ened to have one policy file defined per service.21:05
ayoungWe can start with that21:06
samueldmqayoung, one policy file per service is like what we have today21:06
samueldmqayoung, I think that scope is very good for L21:06
samueldmqayoung, and we can have better ideas/improve the existing ones as we go with this required base21:07
samueldmqayoung, for the dynamic policy stuff21:07
samueldmqayoung, <ayoung> We can start with that21:09
samueldmqayoung, I am understanding you then agreed with that diagram :D21:09
samueldmqayoung, I will talk to sdague and see what he thinks, since that fits nova requirements21:09
samueldmqayoung, if we agree on that, or somehting based on that, we're good for L21:10
*** csoukup has joined #openstack-keystone21:10
ayoungOk for now...I'm still thinking it through.  I think that splitting policy into role vs scope will be what we want long term, and just want to make sure we don't mess that up21:11
ayoungI think we are OK, though21:11
samueldmqayoung, :)21:12
* samueldmq is happy know21:12
openstackgerritayoung proposed openstack/keystone-specs: Policy by URL  https://review.openstack.org/19242221:13
*** harlowja has joined #openstack-keystone21:13
*** marzif has quit IRC21:13
*** tqtran_afk is now known as tqtran21:16
ayoungsamueldmq, http://interactive.blockdiag.com/seqdiag/image?compression=deflate&encoding=base64&src=eJzNUc1OwzAMvvcprN7XPkApHGDiMAYSPyc0IdO4xSJLSpKuqhDvTtIU1ILGGV8cJ9-P7Vh6E4wNvCcA59u7wicUe1bh0FkyIV_rAxYQwhcbGqzTiorEF3kOlvetJFDaoWOtogxAefqNhEeJzyShhLRrpUYBgmrspINWS66GdFdMLE8KXjPCBdXsFcbbtRKtZuXg4fYK0MGWhZDUoyGotKq5AVRB23sM4Fs_cEXp7u-GDDVsHZmlQ-wojA-rRUtlerm-h7wzMkK-YoT8dpjgccwzmtSfPL3MsmzmcrJautxs4uP4FUH49afwtElF_WKLxwlora4YHc040LN721:20
ayoungsamueldmq, actually21:21
ayoungsamueldmq, http://tinyurl.com/oxwnmdc21:22
*** Daviey has quit IRC21:30
*** gokrokve has quit IRC21:32
*** pballand has joined #openstack-keystone21:39
*** doug-fish has joined #openstack-keystone21:44
stevemarrichm, how are testing if the user has been added to the project?21:47
stevemarrichm, also, to be pedantic, users are not "added" to a project, they must be assigned a role on a project21:47
richmstevemar: openstack user list --project $project and openstack project list --user $user21:49
richmone of those doesn't work with v2.021:49
*** edmondsw has quit IRC21:52
*** pballand has quit IRC21:52
*** doug-fish has left #openstack-keystone21:55
stevemarrichm, what about if you add a role to the user on the project21:56
stevemarrichm, $ openstack role add member --user $user --project $project21:56
*** harlowja has quit IRC22:00
*** harlowja has joined #openstack-keystone22:02
richmstevemar: yes, that works - then the user shows up as a member of the project22:11
richmstevemar: That's the workaround I'll use in puppet22:11
*** mtecer has joined #openstack-keystone22:11
stevemarrichm, that's the way v3 is intended to work22:12
richmstevemar: ok - thanks22:12
*** bknudson has quit IRC22:13
*** dguerri is now known as dguerri`22:22
*** pballand has joined #openstack-keystone22:25
*** pballand has quit IRC22:35
*** dguerri` is now known as dguerri22:36
*** ayoung has quit IRC22:37
*** openstackgerrit has quit IRC22:38
*** dguerri is now known as dguerri`22:39
*** openstackgerrit has joined #openstack-keystone22:39
*** dguerri` is now known as dguerri22:48
*** csoukup has quit IRC22:51
*** dguerri is now known as dguerri`23:00
*** obedmr has quit IRC23:03
*** lhcheng has quit IRC23:04
*** lhcheng has joined #openstack-keystone23:07
*** ChanServ sets mode: +v lhcheng23:07
*** chlong has quit IRC23:15
*** Rockyg has quit IRC23:26
*** browne has quit IRC23:27
*** tqtran has quit IRC23:27
*** roxanaghe has quit IRC23:27
*** tqtran has joined #openstack-keystone23:28
*** browne has joined #openstack-keystone23:28
*** kfox1111 has joined #openstack-keystone23:31
*** jaosorior has quit IRC23:35
*** sigmavirus24 is now known as sigmavirus24_awa23:42
*** stevemar has quit IRC23:44
*** stevemar has joined #openstack-keystone23:44
*** ChanServ sets mode: +v stevemar23:44
*** zzzeek has quit IRC23:48
*** Kennan2 is now known as Kennan23:51
jamielennoxstevemar: wow, fixed, released, done23:52
jamielennoxthat patch is at the end of the series so i didn't need it that desperately - but thanks - and it passes gate!23:53

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!