| *** csoukup has quit IRC | 00:00 | |
| *** HT_sergio has joined #openstack-keystone | 00:03 | |
| *** mtecer has joined #openstack-keystone | 00:06 | |
| *** zzzeek has quit IRC | 00:07 | |
| *** browne has quit IRC | 00:08 | |
| *** ncoghlan has joined #openstack-keystone | 00:09 | |
| *** ncoghlan has quit IRC | 00:18 | |
| *** stevemar has joined #openstack-keystone | 00:18 | |
| *** ChanServ sets mode: +v stevemar | 00:18 | |
| *** geoffarnold has quit IRC | 00:21 | |
| *** david-lyle has quit IRC | 00:24 | |
| *** charlesw has joined #openstack-keystone | 00:27 | |
| *** dims has quit IRC | 00:33 | |
| *** kfox1111 has quit IRC | 00:34 | |
| *** _cjones_ has quit IRC | 00:37 | |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Remove confusing deprecation comment https://review.openstack.org/191509 | 00:39 |
|---|---|---|
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Proper deprecations https://review.openstack.org/191511 | 00:39 |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Remove confusing deprecation comment from token_to_cms https://review.openstack.org/191510 | 00:39 |
| stevemar | jamielennox, i'm excited to see what happens to your devstack patches | 00:39 |
| jamielennox | stevemar: 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 anything | 00:40 |
| * stevemar shrugs to jamielennox, | 00:40 | |
| stevemar | let's sit and watch zuul | 00:40 |
| * lbragstad pulls a chair up next to stevemar | 00:40 | |
| * stevemar hands lbragstad some popcorn | 00:41 | |
| jamielennox | i did that one early so i could go for a run and see what happens when i get back | 00:41 |
| * lbragstad loves popcorn | 00:41 | |
| jamielennox | then again - it's getting really cosy in here | 00:41 |
| stevemar | jamielennox, run away | 00:41 |
| lbragstad | jamielennox: running?! training for anything? | 00:41 |
| jamielennox | lbragstad: no, i was fit there for a while and then did a few injuries, it got cold, blah, blah, blah | 00:45 |
| jamielennox | just trying to get back into it again | 00:45 |
| bknudson | how cold did it get? | 00:46 |
| *** dims has joined #openstack-keystone | 00:46 | |
| jamielennox | google says it's 13 now, that's 55 for everyone else | 00:46 |
| bknudson | perfect for jogging | 00:47 |
| jamielennox | sydney was worse, but not like it's going to impress anyone with how cold it gets here | 00:47 |
| bknudson | I suppose it's winter there... another reason to go to the meetup. | 00:48 |
| stevemar | jamielennox, looks like you've got a bashate error somewhere | 00:52 |
| bknudson | jamielennox: https://review.openstack.org/#/c/191511/2/keystoneclient/v2_0/client.py -- what does this comment mean? | 00:52 |
| stevemar | but otherwise i think it's going well | 00:52 |
| lbragstad | jamielennox: nice, that's perfect jogging weather | 00:52 |
| bknudson | does 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 | |
| lbragstad | is it db2 ci discussion time yet? cc stevemar bknudson morganfainberg | 00:59 |
| stevemar | lbragstad, o yeah | 01:01 |
| bknudson | I hope yanfengxi shows up. | 01:01 |
| bknudson | I can try to answer any questions but as has been shown I'm not too familiar with the setup. | 01:02 |
| stevemar | bknudson, give him a few minutes, he's only just starting his morning :P | 01:02 |
| openstackgerrit | Merged openstack/keystonemiddleware: Ensure cache keys are a known/fixed length https://review.openstack.org/186971 | 01:03 |
| *** yanfengxi_ has joined #openstack-keystone | 01:04 | |
| yanfengxi_ | Hi, everyone | 01:04 |
| bknudson | yanfengxi_: hi | 01:05 |
| yanfengxi_ | I am here bother you minutes, to talk about DB2 CI enablement. | 01:05 |
| bknudson | lbragstad: morganfainberg stevemar -- ready to get started? | 01:05 |
| bknudson | dolphm: ayoung , etc | 01:05 |
| bknudson | marekd: | 01:05 |
| ayoung | bknudson, the number you have reached has been disconnected | 01:06 |
| stevemar | y | 01:06 |
| ayoung | bknudson, if you feel you have reached this recording in error, please hang up and try your call again | 01:06 |
| bknudson | beep | 01:06 |
| lbragstad | yanfengxi_: from the wiki page here https://wiki.openstack.org/wiki/IBM/IBM_DB2_CI | 01:07 |
| lbragstad | "The DB2 third party CI is being transitioned to the US due to issues with firewall restrictions in China." | 01:07 |
| yanfengxi_ | Yes | 01:07 |
| lbragstad | this just means that the infrastructure lives in the US, but it is still maintained by counterparts in China, right? | 01:07 |
| yanfengxi_ | Correct | 01:07 |
| ayoung | lbragstad, I still don't get why you are doing this, but ok | 01:07 |
| lbragstad | ayoung: several people had questions | 01:08 |
| yanfengxi_ | Please ask | 01:08 |
| stevemar | yanfengxi_, do we know if the py27 tests pass now? with a db2 backend? | 01:08 |
| lbragstad | yanfengxi_: I think stevemar asking the keystone meeting if there was a way for us to tell if it was stable prior to flipping the switch | 01:08 |
| stevemar | lbragstad, yes | 01:09 |
| bknudson | stevemar: I don't know if you can do live testing at all? | 01:09 |
| bknudson | I haven't tried it for a while... should try it again sometime. | 01:09 |
| lbragstad | according to the wiki page there isn't any skipped tests it looks like | 01:09 |
| ayoung | lbragstad, 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 |
| bknudson | lbragstad: there are very few tests that are run, only the identity tests. | 01:10 |
| yanfengxi_ | stevemar_, yes, it passes py27 | 01:10 |
| lbragstad | https://wiki.openstack.org/w/index.php?title=ThirdPartySystems/IBM_DB2_CI_BACK/ExcludedTests_BACK&redirect=no#Project_keystone | 01:10 |
| stevemar | yanfengxi_, cool, then i'm all for it | 01:10 |
| ayoung | Don't get me wrong, I love having another datapoint for making sure our DB code is not MySQL specific | 01:10 |
| yanfengxi_ | because all are ci environment is based on py27 | 01:10 |
| stevemar | as long as it work now, i'm happy with that | 01:10 |
| stevemar | yanfengxi_, what versions of db2 are you guys testing? multiple versions or just 1? | 01:11 |
| ayoung | But I expect exactly 0 people that are not IBM customers are running DB2 with OpenStack in production. Am I wrong? | 01:11 |
| bknudson | ayoung: we support upstream openstack | 01:11 |
| stevemar | ayoung, same argument can be said for any 3rd party CI (cinder or not) | 01:11 |
| yanfengxi_ | just one | 01:11 |
| stevemar | ayoung, and it doesn't cost us anything | 01:12 |
| *** geoffarnold has joined #openstack-keystone | 01:12 | |
| ayoung | stevemar, there is a difference, but, sure. | 01:12 |
| ayoung | Cinder is more "we bought this hardware, we need to integrate with it" | 01:12 |
| lbragstad | yanfengxi_: do you notice specific failures with certain tests or it is transient? | 01:12 |
| ayoung | chosing a Database is a little different | 01:12 |
| stevemar | ayoung, it's handy to have it publicized i suppose | 01:12 |
| ayoung | I mean, personally, I like DB2 more than MySQL. | 01:12 |
| ayoung | GBut that might be "damned by faint praise" | 01:12 |
| stevemar | i'm not involved with this at all, i just think its worth the effort | 01:13 |
| bknudson | http://dal05.objectstorage.softlayer.net/v1/AUTH_58396f85-2c60-47b9-aaf8-e03bc24a1a6f/cilog/51/187751/1/only-comments/ibm-db2-ci-keystone/c58ba2b/console.html | 01:13 |
| yanfengxi_ | lbragstad_: the failures may caused by environment issue, patch code common issue, and mostly important, db2 issue. | 01:13 |
| bknudson | shows what tests are actually run | 01:13 |
| stevemar | bknudson, that's just tempest tests | 01:14 |
| stevemar | not keystone tests | 01:14 |
| bknudson | only tempest is run | 01:14 |
| stevemar | ... | 01:14 |
| yanfengxi_ | we only run tempest | 01:14 |
| lbragstad | yanfengxi_: in your note, you said you noticed about an 88% failure rate? | 01:14 |
| yanfengxi_ | Yes | 01:14 |
| *** geoffarnold has quit IRC | 01:14 | |
| stevemar | okay - i was reading this as running the keystone unit tests | 01:14 |
| openstackgerrit | Merged openstack/keystone: Pass environment variables of proxy to tox https://review.openstack.org/191602 | 01:15 |
| ayoung | stevemar, you guys going to replace Rabbit MQ with MQ Series, too? | 01:15 |
| bknudson | there aren't unit tests running for any database now as far as I know | 01:15 |
| yanfengxi_ | not ut, only tempests are ran | 01:15 |
| stevemar | bknudson, huh? whatever, the functional tests we have (post moving them around) | 01:15 |
| bknudson | stevemar: the only functional testing that's done is tempest now. | 01:16 |
| stevemar | I want these run | 01:16 |
| stevemar | http://logs.openstack.org/73/191873/2/check/gate-keystone-python27/f829a5e/testr_results.html.gz | 01:16 |
| stevemar | i want 5000+ tests, not 120 | 01:16 |
| stevemar | what the heck does 120 buy us | 01:16 |
| stevemar | whatever, 150 | 01:16 |
| bknudson | stevemar: the functional tests aren't run at all yet. | 01:16 |
| openstackgerrit | Merged openstack/keystone: Refactor: move PKI-specific tests into the appropriate class https://review.openstack.org/191873 | 01:17 |
| lbragstad | yanfengxi_: do you know what the avg failure rate is for tempest runs? | 01:17 |
| stevemar | whats the hold up on that? | 01:17 |
| stevemar | we can have this an initial step, i guess | 01:17 |
| bknudson | stevemar: https://review.openstack.org/#/c/139137/ | 01:17 |
| bknudson | which is blocked by https://review.openstack.org/#/c/151310/7 at this point | 01:17 |
| bknudson | stevemar: you -1d it | 01:18 |
| yanfengxi_ | lbragstad_: in most of the CI running, the tempoest failure rate is 0%. | 01:18 |
| stevemar | bknudson, there's no way we can just devstack things with a db2 backend and run tox -e py27 under keystone? | 01:18 |
| bknudson | I don't think the live tests for any database run all 5k tests. | 01:18 |
| bknudson | stevemar: It might be possible. | 01:19 |
| *** tobe has joined #openstack-keystone | 01:19 | |
| stevemar | bknudson, you are also -1'ing that patch | 01:19 |
| bknudson | y, but I -1 everything | 01:19 |
| bknudson | people have learned to ignore it | 01:19 |
| lbragstad | yanfengxi_: I'm just trying to gauge the frequency of runs that will happen and fail but not fail because of the proposed change | 01: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_awa | 01:20 | |
| bknudson | the unit tests validate a lot more than the tempest tests | 01:20 |
| bknudson | the tempest tests are only supposed to be for cross-project testing | 01:20 |
| bknudson | so there really should be no identity tempest tests | 01:20 |
| stevemar | yanfengxi_, bknudson there are entire branches of things that are not being tested | 01:21 |
| stevemar | so tempest doesn't test any of our extension right? | 01:21 |
| bknudson | stevemar: I agree the tempest tests don't cover much. | 01:21 |
| bknudson | one thing they do cover, of course, is keystone-manage db-sync | 01: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 IRC | 01:22 | |
| stevemar | if our extensions are doing something in a backend via sqlalchemy that isn't supported by db2 we won't know | 01:22 |
| bknudson | and they must be getting tokens and stuff. | 01:22 |
| bknudson | at least all the extensions are now having their migrations run | 01:22 |
| stevemar | bknudson, thats true | 01:22 |
| bknudson | that's typically where the issues are anyways. | 01:23 |
| lbragstad | yanfengxi_: 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 |
| lbragstad | yanfengxi_: but it's not voting, | 01:24 |
| yanfengxi_ | yes, it's none-voting | 01:24 |
| yanfengxi_ | should only voting CIs give failure comments? | 01:25 |
| lbragstad | yanfengxi_: I don't know what policy is, which is why I asked, | 01:25 |
| lbragstad | but it does look bad from a reviewers perspective because it will deter people from reviewing the patch if it has a downvote | 01:26 |
| bknudson | if it doesn't -1 on failures it's going to be hard for me to find any changes that break db2. | 01:26 |
| yanfengxi_ | https://review.openstack.org/#/c/165655/ | 01:26 |
| bknudson | vs changes that db2 didn't report on for whatever reason | 01:26 |
| lbragstad | it's hard for a committer to fix something they don't have access to dev on | 01:26 |
| yanfengxi_ | This is an example, of what will none-voting CIs do | 01:26 |
| bknudson | DB2 Express-C is free to download | 01:27 |
| yanfengxi_ | They will give failure comments, but will not -1, and will not hold off the patch merging | 01:27 |
| lbragstad | ok | 01:27 |
| bknudson | you can see in cinder they have external CI reporting failures all over the place | 01:28 |
| bknudson | I think they've gotten used to it. | 01:28 |
| yanfengxi_ | Yes | 01:28 |
| bknudson | not that I want us to get used to it | 01:28 |
| lbragstad | exactly | 01:28 |
| lbragstad | then it's pointless | 01:28 |
| stevemar | alright, i'm for this, i'd prefer it to be as less noisy as possible | 01:28 |
| yanfengxi_ | Do you think the failures are nosy? | 01:29 |
| yanfengxi_ | and the successful message are beautiful? | 01:29 |
| bknudson | If it's failing for any reason other than the code breaks db2 then it's noise. | 01:29 |
| yanfengxi_ | yes, that's true | 01:30 |
| bknudson | and 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 |
| lbragstad | and 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 do | 01:30 |
| lbragstad | bknudson: ++ and that code is usually heavily reviewed | 01: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 |
| openstackgerrit | Merged openstack/keystone: Needn't load fernet keys twice https://review.openstack.org/191608 | 01:31 |
| lbragstad | yanfengxi_: did you notice the 88% before or after the migration? | 01:32 |
| lbragstad | just curious | 01:32 |
| yanfengxi_ | after | 01:32 |
| yanfengxi_ | and environment reason is a small part of it. | 01:33 |
| lbragstad | yanfengxi_: yeah, that's understandable | 01: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 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/keystonemiddleware: Remove install_venv_common and fix typo in memorycache https://review.openstack.org/189113 | 01:34 |
| yanfengxi_ | typo...also... | 01:34 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/python-keystoneclient: Remove unnecessary install_venv_common module https://review.openstack.org/189123 | 01:35 |
| yanfengxi_ | If it fails for environment reason, we will recheck it, until it shows happy news. | 01:35 |
| bknudson | you're going to be awake all day rechecking changes? or this is automatic? | 01:35 |
| lbragstad | yanfengxi_: 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 |
| bknudson | I 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 |
| bknudson | you're promising to be awake 24 hours a day? | 01:37 |
| *** browne has joined #openstack-keystone | 01: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 |
| bknudson | I don't want things to be broken for 16 hours. | 01:38 |
| bknudson | if 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 guys | 01:40 |
| yanfengxi_ | But it still needs time. | 01:40 |
| morganfainberg | bknudson, 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 IRC | 01:40 | |
| bknudson | upstream works with db2. | 01:40 |
| yanfengxi_ | bknudson, do you know have any CIs that only have 1% failure rate | 01:40 |
| bknudson | we don't have any changes internally to keystone to make it work with db2 | 01:41 |
| bknudson | yanfengxi_: I don't know the stats for any CIs. | 01:41 |
| lifeless | yanfengxi_: openstackCI :) | 01:42 |
| lifeless | yanfengxi_: when it gets up things fall over VERY VERY fast at scale | 01:42 |
| lbragstad | lifeless: ++ | 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 jenkins | 01:43 |
| *** lhcheng has quit IRC | 01:43 | |
| yanfengxi_ | https://review.openstack.org/#/c/165655/ | 01:44 |
| yanfengxi_ | As this patch shows, many CI fails even if jenkins works. | 01:44 |
| lbragstad | but that's not always a good thing, since it can be out of the developers hands to fix it. | 01:45 |
| bknudson | in 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 |
| stevemar | jamielennox, fix yo bashate! | 01:46 |
| jamielennox | stevemar: just looking now | 01:46 |
| *** kiran-r has joined #openstack-keystone | 01:47 | |
| openstackgerrit | Dave Chen proposed openstack/keystone-specs: Use oslo-versioned-objects to deal with upgrades https://review.openstack.org/167195 | 01:47 |
| stevemar | jamielennox, in lib/swift !! | 01:47 |
| jamielennox | stevemar: i've fixed this same issue a couple of times, must have got lost in a rebase | 01:47 |
| jamielennox | stevemar: swift failures :( | 01:48 |
| stevemar | jamielennox, i was just going to say... | 01:48 |
| stevemar | http://logs.openstack.org/80/186680/6/check/check-swift-dsvm-functional/aa549c0/console.html#_2015-06-16_01_03_45_043 | 01:49 |
| stevemar | Unauthorized. Check username/id, password, tenant name/id and user/tenant domain name/id | 01:49 |
| jamielennox | stevemar: i don't see why though - i specifically didn't change anything about v2 auth | 01:49 |
| jamielennox | keystoneclient.auth.identity.v3.base: DEBUG: Making authentication request to http://127.0.0.1:35357/v3/auth/tokens | 01:50 |
| jamielennox | who told swift to do that? | 01:50 |
| *** dims has quit IRC | 01:50 | |
| *** yanfengxi_ has quit IRC | 01:52 | |
| *** yanfengxi has joined #openstack-keystone | 01:53 | |
| yanfengxi | bknudson_: Hi, here are some examples where DB2 CI works, but many other CIs fails: | 01:55 |
| stevemar | jamielennox, looks like the functional tests told them to do that | 01:55 |
| stevemar | https://github.com/openstack/swift/blob/0a1a447b0198c3192810ab45b32fa41a27bd22bd/test/functional/test_account.py#L857-L862 | 01:55 |
| yanfengxi | https://review.openstack.org/#/c/191209/ | 01:55 |
| yanfengxi | https://review.openstack.org/#/c/190811/ | 01:55 |
| stevemar | if tf.skip or tf.skip2 or tf.skip_if_not_v3: | 01:55 |
| stevemar | raise SkipTest('AUTH VERSION 3 SPECIFIC TEST') | 01:55 |
| yanfengxi | https://review.openstack.org/#/c/191785/ | 01:55 |
| yanfengxi | https://review.openstack.org/#/c/178573/ | 01:55 |
| yanfengxi | https://review.openstack.org/#/c/163647/ https://review.openstack.org/#/c/190579/ https://review.openstack.org/#/c/191209/ | 01:55 |
| yanfengxi | I just want to say, CI failures are normal, but it's important for CI maintainers to handle the unacceptable publish in time. | 01:56 |
| yanfengxi | If there are no body handle them, it's indeed really nosy. | 01:57 |
| jamielennox | stevemar: 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 available | 01:58 |
| stevemar | jamielennox, and the remaining failed tests have the same flag: https://github.com/openstack/swift/blob/0a1a447b0198c3192810ab45b32fa41a27bd22bd/test/functional/test_container.py#L1562-L1563 | 01:58 |
| stevemar | jamielennox, fix the bash8 problem and it'll magically resolve itself | 01:59 |
| jamielennox | stevemar: pushed | 01:59 |
| stevemar | \o/ | 01:59 |
| lbragstad | yanfengxi: so, if db2 ci fails on my patch do I just recheck it and ping you? | 02:01 |
| yanfengxi | lbragstad_: 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 |
| lbragstad | you mean a recheck it's necessary? | 02:03 |
| lbragstad | isnt* | 02:03 |
| jamielennox | stevemar: http://logs.openstack.org/80/186680/6/check/check-swift-dsvm-functional/aa549c0/logs/apache/keystone.txt.gz#_2015-06-16_01_00_44_950951 | 02:04 |
| stevemar | jamielennox, context? | 02:04 |
| jamielennox | stevemar: no idea, but i'm guessing that's causing the failure | 02:05 |
| jamielennox | stevemar: doh - yea, it's my fault | 02:05 |
| yanfengxi | lbragstad_: 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 IRC | 02:06 | |
| yanfengxi | Because we have more experience on the failure judgement | 02:06 |
| jamielennox | stevemar: https://review.openstack.org/#/c/186680/7..8/lib/swift | 02:07 |
| stevemar | jamielennox, what hppned? | 02:07 |
| stevemar | hhahahaha | 02:07 |
| jamielennox | at least it's a simple fix | 02:07 |
| stevemar | y | 02:08 |
| *** david-lyle has joined #openstack-keystone | 02:08 | |
| morganfainberg | yanfengxi 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 |
| lbragstad | yanfengxi: I agree, I just don't really know why it would have to be reporting back to the upstream patch then. | 02:09 |
| morganfainberg | It could just as well send an email to internal teams at IBM. | 02:09 |
| morganfainberg | Developer in this case = someone like me not affiliated with IBM or strictly upstream. | 02:10 |
| bknudson | morganfainberg: I think the problem is we can't tell if it's our problem or not? | 02:10 |
| bknudson | but you're correct, if there was a way to tell this was an internal issue vs external one then external reporting is not useful | 02:11 |
| lbragstad | even if it is an external issue, it's still really hard for the external developer working for another company to fix it | 02:11 |
| yanfengxi | bknudson_: yes, agree. I don't think developers could tell the error is about DB2 | 02:11 |
| morganfainberg | bknudson: the question is, will $upstream_developer be able to know what is going on and or fix it? | 02:11 |
| yanfengxi | or it's an environment issue. | 02:11 |
| morganfainberg | Or even really care. | 02:12 |
| *** kiran-r has quit IRC | 02:12 | |
| bknudson | I hope that developers will care if they make a change that breaks db2. | 02:12 |
| bknudson | With the DB2 CI not reporting I've been commenting on reviews that would have broken db2 | 02:12 |
| bknudson | there was a migration recently added that didn't work on db2 | 02:13 |
| yanfengxi | the db2 ci is to detect patches that breaks db2. | 02:13 |
| lbragstad | yanfengxi: it sounds like you guys have that.. | 02:13 |
| bknudson | typically the issue will show up as a failure in keystone-migrate db_sync phase | 02:14 |
| bknudson | keystone-manage db_sync | 02:14 |
| yanfengxi | lbragstad_: have what? | 02:14 |
| lbragstad | yanfengxi: detection if a patch incompatible with db2 | 02:14 |
| yanfengxi | bknudson_: agree, that's the point | 02:14 |
| morganfainberg | bknudson: is there value in more than db_sync then? | 02:15 |
| bknudson | if 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 |
| lbragstad | but is that what runs in the ci? | 02:15 |
| bknudson | morganfainberg: I like that the tests are getting tokens and validating more than just db_sync. | 02:16 |
| yanfengxi | lbragstad_: Yes, will long time working on this, we could rapidly judge what kind of failure we have. | 02:16 |
| morganfainberg | bknudson: so, my concern is this *feels* like a marketing ploy from IBM. not saying it is. | 02:16 |
| morganfainberg | It feels like the same concept of "I want to 3rd party ci test my wacky proprietary Python interpreter" to say it works. | 02:16 |
| morganfainberg | I'm just trying to make sure it isn't that. | 02:17 |
| bknudson | there's lots of 3rd party CI working against cinder, for example. | 02:17 |
| bknudson | and neutron | 02:17 |
| bknudson | and nova | 02:17 |
| morganfainberg | And my biggest concern is getting a care about db2 from unaffiliated folks. | 02:17 |
| morganfainberg | Having to download and install db2 express is a high barrier to "fix" things. | 02:18 |
| lbragstad | I've never heard of db2 express, | 02:18 |
| bknudson | it'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 |
| morganfainberg | As far as I knew there was no way to debug db2 directly until just now. | 02:19 |
| lbragstad | but we do see some behavior different between mysql and sqlite | 02:19 |
| lbragstad | would it be a situation like that? | 02:19 |
| morganfainberg | bknudson: that is a dealbreaker unless IBM is dealing with the failures 100% of the time or that is changed. | 02:19 |
| morganfainberg | I can't ask everyone to agree to licenses to debug things. | 02:20 |
| morganfainberg | MySQL and SQLite are easy to install and don't require extra licenses to debug issues here. | 02:20 |
| bknudson | up to now I've been dealing with them. | 02:21 |
| morganfainberg | So 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 |
| yanfengxi | bknudson_: I don't think community developers needs to verify the failures themselves. IBM guys could help out. | 02:22 |
| lbragstad | right, 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 internally | 02:23 |
| bknudson | y, and I can't promise to always be available either... I'm often told to work on other things. | 02:23 |
| morganfainberg | I 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 |
| lbragstad | you'd still know if a patch breaks db2 at the same point in time, regardless if it's reporting upstream or not | 02:24 |
| bknudson | morganfainberg: maybe a question for the mailing list or x-project meeting? | 02:24 |
| morganfainberg | The difference is, I think, a significant vested interest in keeping the 3rd party stuff looked at in the other projects. | 02:24 |
| bknudson | I have a vested interest in having this work. | 02:25 |
| bknudson | because when it breaks I get a defect that I have to fix. | 02:25 |
| morganfainberg | Because 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 |
| morganfainberg | If 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 |
| davechen | stevemar, jamielennox: Does `ec2 credentials create` got merged in the OSC? or KS? | 02:26 |
| bknudson | I'm not the only person here that can work on db2 issues... we've got ibmers working on nova, cinder, heat, etc. | 02:26 |
| stevemar | davechen, yep, it's in 1.4.0 release | 02:27 |
| stevemar | jamielennox, whats up with https://review.openstack.org/#/c/186684/ | 02:27 |
| yanfengxi | If one patch breaks db2, failure will not -1, and will not hold back the merging. | 02:27 |
| morganfainberg | So, 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 |
| davechen | stevemar, jamielennox: Does that mean create ec2 credential will not be supported by `credentials create` in the near future? | 02:27 |
| morganfainberg | And we will ask that it stop reporting. | 02:27 |
| stevemar | davechen, we could still support it there too | 02:27 |
| yanfengxi | we 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 |
| morganfainberg | yanfengxi: that is just noise then. | 02:28 |
| stevemar | davechen, we want `os credentials create` to use the /credentials API | 02:28 |
| davechen | stevemar, jamielennox: :-) this sounds good. | 02:28 |
| lbragstad | non of that involves the upstream developer | 02:28 |
| morganfainberg | yanfengxi: 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 |
| morganfainberg | From IBM. | 02:28 |
| yanfengxi | morganfainberg_: what I talked about is failures that breaks db2. | 02:29 |
| davechen | stevemar, jamielennox: is that what we are doing now, credentials create once not use /credentials API? | 02:29 |
| stevemar | davechen, 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#L64 | 02:29 |
| davechen | stevemar: great! lets me take a look at the code. | 02:30 |
| morganfainberg | I don't know how to resolve this. Let's ask at x-project how this is working for cinder and neutron. | 02:30 |
| stevemar | davechen, the /credentials API isn't used at all :( | 02:30 |
| morganfainberg | Then model after that. If it isn't possible, then we say it doesn't get to report. | 02:30 |
| davechen | stevemar: so, is there any need to get that patch in? or we just abandon it? your thoughts? | 02:30 |
| stevemar | davechen, which patch? | 02:31 |
| *** fangzhou has quit IRC | 02:31 | |
| morganfainberg | bknudson: yanfengxi ^^ that work for you? | 02:31 |
| stevemar | right now i don't think it makes much sense to expose the /credentials API through the CLI right now, no one is using it | 02:31 |
| davechen | stevemar: some info on how to create an ec2 credentials with os credentials create. | 02:31 |
| bknudson | morganfainberg: that works for me. I'd like to know why they accept so many failures. | 02:31 |
| lbragstad | yanfengxi: can you make it to this meeting? https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting | 02:31 |
| stevemar | davechen, probably not | 02:31 |
| lbragstad | bknudson: who is they? | 02:32 |
| stevemar | davechen, i want to delete `os credentials` :\ | 02:32 |
| davechen | stevemar: really? | 02:32 |
| bknudson | lbragstad: cinder , nova, neutron, and other projects that have external CI | 02:32 |
| stevemar | i want to delete the entire /credentials API that keystone has, i don't think anyone uses it | 02:32 |
| davechen | stevemar: haha. i saw you have a bug relevant with this. | 02:32 |
| bknudson | lbragstad: these things seem to be reporting failures all the time and it doesn't seem to bother them. | 02:32 |
| lbragstad | bknudson: I'd rather not have that in Keystone :-/ | 02:33 |
| yanfengxi | lbragstad_: it's more than normal to publish results by third party CIs. | 02:33 |
| jamielennox | stevemar, davechen; i looked at doing it with the credentials api but it involves passing specially formed serialized JSON over the CLI | 02:34 |
| yanfengxi | lbragstad_: 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-keystone | 02:34 | |
| jamielennox | given the EC2 extension is there we may as well use it | 02:34 |
| davechen | stevemar: 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 |
| lbragstad | yanfengxi: it's the cross project meeting morganfainberg was just talking about | 02:34 |
| *** bradjones has quit IRC | 02:35 | |
| stevemar | davechen, yep, and with barbican on it's way, we shouldn't be storing credentials in keystone anyway :) | 02:35 |
| jamielennox | stevemar, davechen: the command could use /credentials in OSC - however the EC2 ext generates keys for you so we would have to port that to OSC | 02:35 |
| bknudson | stevemar: barbican has already arrived. | 02:35 |
| jamielennox | v4 won't have /credneitlas :) | 02:35 |
| bknudson | that train has left the station | 02:35 |
| stevemar | bknudson, then why aren't we using it to store thing :P | 02:35 |
| *** bradjones has joined #openstack-keystone | 02:35 | |
| *** bradjones has quit IRC | 02:35 | |
| *** bradjones has joined #openstack-keystone | 02:35 | |
| stevemar | jamielennox, v4 won't have a lot of things | 02:36 |
| bknudson | stevemar: because you didn't write the code! | 02:36 |
| stevemar | bknudson, it was my job ?! | 02:36 |
| davechen | jamielennox: v4? is there any plan for v4? | 02:36 |
| stevemar | davechen, nah, we just joke about v3 | 02:36 |
| stevemar | v4* | 02:36 |
| jamielennox | davechen: hehe, no, i keep bringing it up cause it annoys morganfainberg | 02:36 |
| morganfainberg | jamielennox: huh? | 02:37 |
| stevemar | davechen, official disclaimer: there are absolutely no plans to make v4 of the identity api | 02:37 |
| jamielennox | morganfainberg: v4 for the win! | 02:37 |
| stevemar | jamielennox, you awoke the beast | 02:37 |
| davechen | hehe, i am a really slow. | 02:37 |
| morganfainberg | jamielennox: decouple auth first. | 02:37 |
| jamielennox | it's getting there | 02:37 |
| yanfengxi | morganfainberg_: this meeting is Wed 5:00 AM in beijing time, a little early for me. | 02:38 |
| davechen | stevemar: i won't say v4 stuff in my blogs, relax. :P | 02:38 |
| *** dguerri` is now known as dguerri | 02:38 | |
| stevemar | davechen, oh where are you blogs? | 02:39 |
| bknudson | submit a summit presentation on identity v4. | 02:39 |
| davechen | stevemar: you cannot read it, I need transilate for you. | 02:39 |
| davechen | stevemar: it's not write in english :) | 02:40 |
| morganfainberg | Ok so, just was chatting with anteaya about how this all works for other projects. | 02:40 |
| morganfainberg | It is 100% on the driver maintainers to debug failures. | 02:40 |
| bknudson | that's how we've always been treating it | 02:41 |
| bknudson | although in cases like cinder you'd need to actually buy hardware to debug it | 02:41 |
| morganfainberg | I will allow db2 ci to run, but I'm holding IBM to a high high standard to keep on top of it. | 02:41 |
| bknudson | db2 ci you can at least get it for free | 02:41 |
| morganfainberg | If it is regularly broken or not being looked at, I'll just say to stop reporting. | 02:42 |
| stevemar | davechen, send me the link anyway, google chrome will translate some of it :P | 02:42 |
| morganfainberg | And at that point i won't want it reporting again. So stay on top of it. | 02:42 |
| bknudson | so what I've heard is that the failure rate is 12% | 02:43 |
| morganfainberg | 12% due to transient (aka normal) gate bugs? | 02:43 |
| morganfainberg | Or 12% because of db2 | 02:43 |
| morganfainberg | If it is the latter, fix that before reporting. | 02:44 |
| bknudson | there haven't been any failures due to actual changes that broke db2. | 02:44 |
| morganfainberg | 12% seems really really high. | 02:44 |
| yanfengxi | the failure rate is on other projects, which are more problematic than keystone. | 02:44 |
| morganfainberg | Bre. | 02:44 |
| morganfainberg | Btw* | 02:44 |
| morganfainberg | I don't think we are that bad in the gate in general. | 02:44 |
| lbragstad | I 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 |
| yanfengxi | morganfainberg_: In my mind now, I think it's better not publish results to keystone patch, and will handle them internally. | 02:45 |
| bknudson | lbragstad: there aren't any tests for workarounds for mysql or postgres | 02:45 |
| *** richm has quit IRC | 02:45 | |
| morganfainberg | yanfengxi: 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 |
| yanfengxi | morganfainberg_: OK, thanks | 02:46 |
| lbragstad | bknudson: just curious | 02:46 |
| bknudson | you'd have to mock to test it. | 02:46 |
| morganfainberg | I 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 |
| lbragstad | morganfainberg: so, no x-project meeting tomorrow about this? | 02:47 |
| yanfengxi | morganfainberg_: Yes, understand. | 02:47 |
| morganfainberg | If db2 was an "apt-get db2" with no license issues, I'd be more open to it. | 02:47 |
| morganfainberg | lbragstad: looks like not needed. | 02:47 |
| bknudson | I can't say if the license is actually problematic... it's obviously not GPL or BSD or Apache. | 02:47 |
| morganfainberg | bknudson: having to independently agree to a license is an issue for developers. | 02:47 |
| bknudson | y, 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-keystone | 02:48 | |
| morganfainberg | If 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 ask | 02:48 |
| bknudson | even though it's got a license that people may not agree with | 02:48 |
| morganfainberg | That's all. | 02:48 |
| morganfainberg | If IBM makes it more accessible, it becomes easier to be a reasonable ask. | 02:49 |
| bknudson | let me just call up the CEO! | 02:49 |
| morganfainberg | You should ;) | 02:49 |
| morganfainberg | Make Topol do it. | 02:49 |
| bknudson | Topol could probably make it happen himself. | 02:50 |
| morganfainberg | bknudson: let's see if we can get the failure rate on par with the normal gate failures then have you report. | 02:50 |
| morganfainberg | Then IBM should have less overhead with it and it becomes easier to not be just noise on be patches. | 02:50 |
| morganfainberg | We thankfully have few migrations. | 02:51 |
| yanfengxi | morganfainberg_: 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 |
| bknudson | works for me. | 02:51 |
| yanfengxi | Thanks, everyone. | 02:52 |
| yanfengxi | Have a good night :-) | 02:52 |
| jamielennox | bknudson: you have a minute to discuss some auth_token stuff? | 02:52 |
| bknudson | jamielennox: I can try to stay awake | 02:53 |
| lbragstad | yanfengxi: no problem, thanks! | 02:53 |
| jamielennox | bknudson: i guess i just want to figure out what we are looking for from caching | 02:53 |
| bknudson | I think it's trying to reduce the load on keystone | 02:53 |
| jamielennox | at the moment we cache the result of a token validation - not the token returned from the server necessarily - but the yes/no result | 02:53 |
| bknudson | since tokens should be reused | 02:54 |
| bknudson | I thought the token was stored? | 02:54 |
| jamielennox | it does, but i mean if you fail validation even if the result from the server was good you get an 'invalid' in the cache | 02:54 |
| jamielennox | i was pushing towards we should only cache the response from the keystone server | 02:54 |
| jamielennox | that the cache is just a way of fetching a token and that we should do things like expiry validation every time | 02:55 |
| bknudson | ?? how do you get the server saying the token is ok but it's not ok? | 02:55 |
| jamielennox | bknudson: i'm not sure but the code says you can | 02:55 |
| jamielennox | bind validation | 02:55 |
| jamielennox | umm, i guess there are some things | 02:55 |
| bknudson | I like the idea that the cache is really just sitting in front of the rest calls. | 02:56 |
| jamielennox | bind validation is broken actually because it will cache the invalid status if you have the wrong bind and wont check again in future | 02:56 |
| jamielennox | but bind validation is broken in a bunch of ways... | 02:56 |
| bknudson | seems like that's what it should be... would be easier to understand | 02:56 |
| bknudson | that does sound broken | 02:56 |
| jamielennox | ok, 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 validation | 02:57 |
| jamielennox | the distinction is important if it's in front of keystone | 02:57 |
| bknudson | let's not complicate things... maybe there's some way to encode the request info in the key | 02:57 |
| bknudson | e.g., SHA256( | 02:58 |
| bknudson | 'GET /v3/tokens' | 02:58 |
| bknudson | maybe requests already has something? | 02:58 |
| jamielennox | bknudson: i think not complicated things is only caching responses from the identity server | 02:58 |
| jamielennox | so that bind validation and expiry is done regardless of whether it's been seen before | 02:59 |
| jamielennox | and not caching PKI related information at all | 02:59 |
| bknudson | in future we might do something like fetching the catalog separately from the token | 02:59 |
| bknudson | as in, maybe PKI tokens never have the catalog | 02:59 |
| jamielennox | bknudson: there are ways we could handle that | 03:00 |
| bknudson | that should use the cache | 03:00 |
| jamielennox | there will still be a cache, i'm just looking at where you draw the line | 03:00 |
| bknudson | and if the cache was just in front of the REST calls it would be automatic | 03:00 |
| jamielennox | what's in the base auth_token, what's in auth_token and what's in keysotne | 03:00 |
| morganfainberg | lbragstad: can you propose a back port of the memcache + fernet in middleware ? | 03:01 |
| morganfainberg | lbragstad: to stable/kilo | 03:01 |
| bknudson | morganfainberg: middleware release? | 03:01 |
| morganfainberg | bknudson: planning on it at l1 | 03:02 |
| bknudson | ok | 03:02 |
| morganfainberg | Going to track milestones based on convos with dhellmann and ttx | 03:02 |
| bknudson | morganfainberg: jamielennox was just proposing using keystonemiddleware in keystone. | 03:03 |
| morganfainberg | Yes. | 03:03 |
| morganfainberg | I know. | 03:03 |
| jamielennox | i'm a few patches short, i don't mind if we wait for it | 03:04 |
| jamielennox | everything i've been changing recently i've kept private so a release now won't cause any problems | 03:05 |
| bknudson | somebody 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 ready | 03:05 |
| *** stevemar has quit IRC | 03:06 | |
| morganfainberg | bknudson: stable/kill releases I'll make as needed (same with any stable). | 03:06 |
| morganfainberg | For liberty we'll track milestones. | 03:07 |
| *** kiran-r has quit IRC | 03:08 | |
| *** nkinder__ has quit IRC | 03:08 | |
| bknudson | it's a little strange to have something in a stable/kilo release that's not available on master yet | 03:09 |
| jamielennox | bknudson: 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 time | 03:09 |
| *** mtecer has quit IRC | 03:10 | |
| *** _cjones_ has quit IRC | 03:10 | |
| morganfainberg | bknudson: it is on master, just not tagged | 03:10 |
| morganfainberg | On pypi | 03:11 |
| *** yanfengxi has quit IRC | 03:11 | |
| jamielennox | morganfainberg: what changes did e need for fernet in middleware? | 03:11 |
| morganfainberg | If you are cd already you'd cd middleware too. | 03:11 |
| morganfainberg | jamielennox: the cache fix that merged. | 03:11 |
| jamielennox | oh the sha256 everything | 03:12 |
| jamielennox | ok | 03:12 |
| jamielennox | what is a memcache max length? | 03:12 |
| morganfainberg | Uh. 64bytes? 100bytes? Dunno | 03:12 |
| *** kiran-r has joined #openstack-keystone | 03:12 | |
| morganfainberg | Sha256 works. | 03:12 |
| morganfainberg | 250 bytes. | 03:13 |
| morganfainberg | It looks like. | 03:13 |
| jamielennox | sha256 + 'token-' or whatever we prefix it with | 03:14 |
| *** _cjones_ has joined #openstack-keystone | 03:14 | |
| morganfainberg | Yeah. That is a fine length. | 03:14 |
| jamielennox | ok | 03:14 |
| morganfainberg | It's the full fernet token ID that was a problem. | 03:15 |
| morganfainberg | jamielennox: the fix merged to master already for middleware. | 03:15 |
| morganfainberg | Just needs a back port. | 03:15 |
| morganfainberg | Was asking a non-stable core for keystone to propose the back port. | 03:15 |
| jamielennox | morganfainberg: yea, i saw it and was fine, i think i had a coment about the secure form | 03:16 |
| jamielennox | morganfainberg: so i did a bunch of keystoneauth patches yesterday | 03:16 |
| jamielennox | and ksc on ksa if you have some time later | 03:16 |
| morganfainberg | Yeah I saw. | 03:16 |
| morganfainberg | And my ksa1 patch now needs a rebase :( | 03:17 |
| jamielennox | morganfainberg: :) i had these started and i saw the move - i probably should have merged that one first | 03:17 |
| morganfainberg | That one is an icky rebase. | 03:18 |
| morganfainberg | Will get to it later this week. | 03:18 |
| *** tobe has quit IRC | 03:20 | |
| *** kiran-r has quit IRC | 03:20 | |
| *** tobe has joined #openstack-keystone | 03:23 | |
| *** _cjones_ has quit IRC | 03:31 | |
| *** _cjones_ has joined #openstack-keystone | 03:32 | |
| *** mfisch has quit IRC | 03:32 | |
| *** HT_sergio has quit IRC | 03:32 | |
| *** mfisch has joined #openstack-keystone | 03:36 | |
| *** mfisch is now known as Guest68660 | 03:36 | |
| *** _cjones_ has quit IRC | 03:37 | |
| *** dims has joined #openstack-keystone | 03:46 | |
| *** liusheng has quit IRC | 03:50 | |
| *** dims has quit IRC | 03:51 | |
| *** redrobot has quit IRC | 03:55 | |
| *** ayoung has quit IRC | 04:12 | |
| *** mabrams has joined #openstack-keystone | 04:20 | |
| *** belmoreira has joined #openstack-keystone | 04:26 | |
| *** Ephur has quit IRC | 04:29 | |
| *** belmoreira has quit IRC | 04:31 | |
| *** tobe has quit IRC | 04:47 | |
| jamielennox | bknudson, morganfainberg: what is the policy on utf-8 in urls? | 04:48 |
| jamielennox | do we percent encode everything? | 04:48 |
| morganfainberg | I think you have to. | 04:50 |
| morganfainberg | And what does urllib support? | 04:51 |
| jamielennox | it seems it can work | 04:52 |
| jamielennox | like modern enough everything and you can just use utf-8 | 04:52 |
| jamielennox | but i don't see anywhere it's officially supported | 04:52 |
| *** ncoghlan has joined #openstack-keystone | 05:05 | |
| *** tobe has joined #openstack-keystone | 05:07 | |
| *** kiran-r has joined #openstack-keystone | 05:08 | |
| jamielennox | oh god our CLI is worse than i ever knew :( | 05:18 |
| bigjools | yes, yes it is | 05:19 |
| jamielennox | i mean deprecated for sure, but it's just all over the place | 05:20 |
| jamielennox | trying to do a utf-8 fix and there is really nowhere that i can just fix it for everyone | 05:20 |
| bigjools | from a user PoV, openstackclient is terrible too | 05:20 |
| morganfainberg | jamielennox: yeah don't use our CLI. Just don't. | 05:22 |
| morganfainberg | :P | 05:22 |
| * morganfainberg | 05:22 | |
| * morganfainberg sobs at the ksc CLI | 05:23 | |
| jamielennox | morganfainberg: i'm going to have to backport something - but i really suspect that OSC will have the same problems | 05:23 |
| morganfainberg | bigjools: osc is better than ksc. | 05:23 |
| bigjools | morganfainberg: ksc must be really bad then :) | 05:23 |
| morganfainberg | jamielennox: yeah I just hit my head on osc ux a week ago. Just ugh. | 05:23 |
| jamielennox | bigjools: it is | 05:23 |
| morganfainberg | bigjools: try using it. Tell me how much you like it. | 05:23 |
| jamielennox | but yes, it's a shame you have to deal with versions in osc | 05:24 |
| bigjools | heh | 05:24 |
| morganfainberg | jamielennox: can we just use shade for everything? | 05:24 |
| morganfainberg | #notreallyjoking | 05:24 |
| jamielennox | my brain goes in about 3 directions even thinking about that | 05:24 |
| bigjools | oh morganfainberg FWIW I found an interim solution to federate with websso until it's all working with k2k | 05:24 |
| morganfainberg | I'd be ok if the OpenStack interface was ansible. | 05:25 |
| morganfainberg | bigjools: document it!! | 05:25 |
| morganfainberg | Publish it! | 05:25 |
| bigjools | yes :) | 05:25 |
| bigjools | will blog soon | 05:25 |
| morganfainberg | Make people happy! | 05:25 |
| bigjools | It needs a little development work in horizon but that would need to happen anyway | 05:25 |
| * morganfainberg is thinking more and more ansible is a good idea. | 05:25 | |
| morganfainberg | Somehow I think devstack wouldn't accept it though. | 05:26 |
| bigjools | it uses a little-known feature of Shibboleth, whose Login URL has a GET API | 05:26 |
| morganfainberg | I'm kinda scared about that. But sounds good. | 05:26 |
| bigjools | I have my ticket to pyconau | 05:26 |
| bigjools | well 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 | |
| bigjools | lifeless never gets mad! :) | 05:27 |
| morganfainberg | Hehe. | 05:28 |
| bigjools | I think I owe him some beers | 05:28 |
| morganfainberg | Oh crap I need to submit / may have missed LCA cfp | 05:28 |
| jamielennox | morganfainberg: oo, i haven't changed my abstract either | 05:28 |
| jamielennox | LCA is still open afaik | 05:29 |
| morganfainberg | I don't know what I want to talk about at LCA. | 05:29 |
| morganfainberg | I Do know what I'm submitting to Tokyo. And it isn't a keystone presentation. | 05:29 |
| jamielennox | i was thinking i might just go on my own to LCA | 05:30 |
| jamielennox | as in not propose anything | 05:30 |
| jamielennox | i haven't been and i'm keen | 05:30 |
| *** stevemar has joined #openstack-keystone | 05:30 | |
| *** ChanServ sets mode: +v stevemar | 05:30 | |
| morganfainberg | It's a long flight to "go for the fun of" | 05:30 |
| jamielennox | for you, sure | 05:31 |
| *** tobe has quit IRC | 05:37 | |
| lifeless | morganfainberg: LCA is still open | 05:39 |
| lifeless | morganfainberg: thank you | 05:39 |
| morganfainberg | lifeless: I apologize it might be the end of the week for the abstract for PyCon. | 05:40 |
| morganfainberg | Had some stuff going on and trying to deal with that. | 05:40 |
| morganfainberg | lifeless: hah wait you know what was up. Nvm. /face palms. | 05:40 |
| jamielennox | lifeless: i have no excuse | 05:41 |
| morganfainberg | Anyway. Yeah it's on the short list. | 05:41 |
| jamielennox | but soon | 05:41 |
| stevemar | o/ | 05:43 |
| jamielennox | we haven't forgotten you stevemar | 05:43 |
| stevemar | jamielennox, i didn't suspect you did | 05:43 |
| stevemar | just saying howdy | 05:43 |
| jamielennox | stevemar: it looks like v3 is passing | 05:44 |
| stevemar | indeed it is | 05:44 |
| *** lhcheng has joined #openstack-keystone | 05:47 | |
| *** ChanServ sets mode: +v lhcheng | 05:47 | |
| marekd | o/ | 05:49 |
| marekd | stevemar: morganfainberg: There was some VoIP conference a few hours ago? | 05:49 |
| morganfainberg | stevemar: isn't it stupid late there? | 05:49 |
| morganfainberg | marekd: there was? | 05:50 |
| * morganfainberg doesn't do VoIP. | 05:50 | |
| morganfainberg | :P | 05:50 |
| marekd | i don't know, bknudson was asking if we all are ready to get started, and i was also pinged... | 05:51 |
| marekd | nvm | 05:51 |
| morganfainberg | No seriously, there was a VoIP thing? | 05:51 |
| marekd | maybe the topics got mixed. | 05:51 |
| jamielennox | i think it was the db2 chat | 05:52 |
| jamielennox | wasn't there going to be a call-in for that? | 05:52 |
| marekd | yep, they were waiting for somebody from China. | 05:52 |
| morganfainberg | Oh. That was kn IRC. | 05:53 |
| morganfainberg | Not VoIP. | 05:53 |
| marekd | morganfainberg: so, pparently the topics were mixed. | 05:53 |
| stevemar | marekd, morganfainberg jamielennox there was a meeting, but just here -keystone, no voip | 05:54 |
| morganfainberg | So 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 |
| stevemar | morganfainberg, yes it's stupid late, but i have been trying to sleep for about 2 hrs | 05:54 |
| morganfainberg | stevemar: you know computer screens have the wrong color/white balance to help sleep right? | 05:54 |
| stevemar | phones too? :P | 05:55 |
| marekd | morganfainberg: that's what IBM pts on their corporate laptoptops to make them work even more :P | 05:55 |
| jamielennox | have you tried installing that redshift thing though, was horrible to work with | 05:55 |
| marekd | s/pts/puts/ | 05:55 |
| morganfainberg | stevemar: yep. | 05:55 |
| morganfainberg | stevemar: you need a redshift or f.lux like app. | 05:55 |
| *** belmoreira has joined #openstack-keystone | 05:55 | |
| morganfainberg | (Btw those give me massive headaches when I use them). But it makes you sleepier than he blue-ish light from lcds | 05:56 |
| morganfainberg | marekd: ahaha | 05:56 |
| stevemar | i just turn down the brightness | 05:57 |
| marekd | jamielennox: going to attend todays...erm..tomorrow's meeting? | 06:00 |
| jamielennox | marekd: no | 06:00 |
| jamielennox | marekd: that's like 2am and my team meeting got cancelled | 06:00 |
| marekd | jamielennox: OK | 06:01 |
| jamielennox | marekd: something on there i should know about? | 06:01 |
| jamielennox | i haven't looked yet | 06:01 |
| marekd | jamielennox: no | 06:01 |
| morganfainberg | jamielennox: wait it's 2am meeting for you? Eek | 06:01 |
| jamielennox | morganfainberg: i'm on the west coast (aus) for the next week or so | 06:01 |
| morganfainberg | Ah. | 06:02 |
| morganfainberg | That explains it. | 06:02 |
| marekd | jamielennox: so you can basically work remotely, right? | 06:02 |
| jamielennox | it'll go back to its usual 4 soon | 06:02 |
| jamielennox | marekd: yea | 06:02 |
| *** tobe has joined #openstack-keystone | 06:02 | |
| morganfainberg | Perth? | 06:03 |
| marekd | jamielennox: i wanted to talk about incorporating k2k into kmw. | 06:04 |
| marekd | jamielennox: you might remember our convo at the summit. | 06:04 |
| jamielennox | morganfainberg: yes | 06:04 |
| jamielennox | marekd: type away, i've got about 2 minutes to fix up this patch | 06:05 |
| *** krykowski has joined #openstack-keystone | 06:08 | |
| *** lhcheng has quit IRC | 06:11 | |
| marekd | jamielennox: 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 will | 06:11 |
| *** spandhe has quit IRC | 06:12 | |
| *** lhcheng has joined #openstack-keystone | 06:12 | |
| *** ChanServ sets mode: +v lhcheng | 06:12 | |
| marekd | jamielennox: 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 intimidating | 06:13 |
| jamielennox | marekd: so i think you lost the end of your first sentence | 06:15 |
| jamielennox | marekd: so in any situation like this i think to "push" is wrong | 06:15 |
| marekd | jamielennox: 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 |
| marekd | jamielennox: 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 |
| jamielennox | insist on push? | 06:16 |
| marekd | jamielennox: yes. | 06:16 |
| jamielennox | glance already has "download from url" why would they want it pushed | 06:17 |
| jamielennox | honestly i think something like swift tempurls is the easiest way to do this | 06:17 |
| jamielennox | and then use existing glance pull features from a one time url | 06:18 |
| marekd | jamielennox: because tasks are async and there might be significant time gap in between you create a task and it starts executing. | 06:18 |
| marekd | jamielennox: swift if just one backedn to glance, right? | 06:18 |
| marekd | backend | 06:18 |
| jamielennox | right - i wasn't thinking of doing it via swift, just the mechanism | 06:18 |
| jamielennox | so won't any issue of token expiry work both ways? | 06:19 |
| jamielennox | if i push instead of pull and it takes some time then it's possible my remote token might expire in that time as well | 06:20 |
| marekd | jamielennox: then the task fails. And I don't think it'd be 24hours delay of executing the task. | 06:20 |
| jamielennox | marekd: wait so you want to submit the assertion, not a token? | 06:21 |
| stevemar | lhcheng, needed an extra pair of eyes on: https://review.openstack.org/#/c/189947/ | 06:21 |
| marekd | jamielennox: 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 kmw | 06:22 |
| lhcheng | stevemar: sure, on it. | 06:23 |
| stevemar | \o/ | 06:23 |
| marekd | jamielennox: and kmw would have to do all the k2k work. | 06:23 |
| marekd | jamielennox: i am ok taking the easiest route atm and making client doing all that, and client would send two tokens- local and remote | 06:24 |
| marekd | jamielennox: i;d need to teach kmw to distinguish between local and remote tokens and fetch endpoint url from remote service catalog. | 06:24 |
| jamielennox | marekd: i'm really uneasy about sending scoping information to auth_token and expecting it to do something with it | 06:24 |
| marekd | jamielennox: so, two tokens. | 06:25 |
| jamielennox | marekd: you can do it as a different piece of middleware but i'm not sure if it's something general purpose | 06:26 |
| marekd | jamielennox: i think it will eventually become a general purpose | 06:27 |
| marekd | jamielennox: i think we will get to the point where nova@A will communicate with glance@B | 06:27 |
| jamielennox | you're saying though that for every request with this information we're adding another 2 requests to keystone | 06:27 |
| jamielennox | and 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 one | 06:27 |
| jamielennox | stevemar: as you're awake anyway can you read through above and tell me your thoughts? | 06:29 |
| jamielennox | you two are the ones that know this best | 06:29 |
| jamielennox | i'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 anyway | 06:30 |
| marekd | jamielennox: i don't want to communicate services now, but i think eventually federating at the identity only level will not be enough... | 06:30 |
| jamielennox | marekd: i agree | 06:30 |
| stevemar | catching up | 06:31 |
| jamielennox | and i think federated resources is going to be really hard and require buy in from all the services | 06:31 |
| marekd | jamielennox: i agree | 06:31 |
| jamielennox | i don't know if it's something we can abstract away at the keystone level | 06:31 |
| marekd | jamielennox: 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 |
| marekd | jamielennox: kmw would have much easier job with figuring out the remote image endpoint. | 06:34 |
| jamielennox | marekd: so conceptually when you talk about federated resources we will need to provide some way of identifying where a resource id lives | 06:34 |
| jamielennox | like image_id@local_glance | 06:34 |
| jamielennox | and have the catalog smart enough to know what local_glance is | 06:34 |
| marekd | that would become an attribute of image. | 06:34 |
| jamielennox | would it? why? | 06:35 |
| jamielennox | i don't think it can be | 06:35 |
| marekd | conceptually there is still one token per cloud -> one service catalog per cloud. | 06:35 |
| marekd | and client must specify which cloud he wants to use. | 06:35 |
| *** belmoreira has quit IRC | 06:36 | |
| jamielennox | right | 06:36 |
| marekd | i already gave up with ideas like "openstack image list" where all the images from all your clouds are listed. | 06:36 |
| stevemar | marekd, trying to understand this... so you want your local nova to use my glance images? | 06:36 |
| marekd | stevemar: no :-) | 06:36 |
| stevemar | doh! | 06:37 |
| jamielennox | we moved a bit into ffuture work | 06:37 |
| marekd | stevemar: 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 |
| stevemar | what are you proposing (simple terms, i am not a smart man) | 06:37 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/190405 | 06:37 |
| marekd | stevemar: 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 |
| marekd | stevemar: i want glances to communicate directly, because my and your DC have nice bandtwidth, whereas my home link is very poor. | 06:38 |
| marekd | stevemar: I don't want to create any sort of service accounts, and storing passwords in any of the glance, but leverage on k2k | 06:39 |
| stevemar | oh okay, you don't want to download the image | 06:39 |
| marekd | stevemar: not to my local laptop and later manually upload it. | 06:39 |
| stevemar | so you still kinda want to use your nova in your DC and my glance image in my DC | 06:40 |
| marekd | stevemar: not at the moment. | 06:40 |
| marekd | stevemar: my nova will be able to use my glance only. | 06:40 |
| stevemar | okay | 06:40 |
| stevemar | so you just want to list my images? | 06:40 |
| marekd | i can do this today with federation :-) | 06:41 |
| stevemar | or actually save them? | 06:41 |
| jamielennox | stevemar: essentially we want replication of the same image amongst multiple glances | 06:41 |
| jamielennox | over k2k | 06:41 |
| marekd | stevemar: ^^ the man is right. | 06:41 |
| stevemar | okay, let's work it backwards from there | 06:41 |
| jamielennox | stevemar: 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 already | 06:42 |
| jamielennox | but apparently the glance team is anti that, it needs to be push based | 06:42 |
| *** dguerri` is now known as dguerri | 06:42 | |
| * jamielennox thinks the glance team is wrong | 06:43 | |
| marekd | jamielennox: 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 |
| stevemar | i was thinking that the local cloud would pull it from remote cloud when it's necessary | 06:43 |
| jamielennox | stevemar: if we say it's always necessarily immediately i agree | 06:44 |
| marekd | stevemar: 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 |
| jamielennox | like the mechanism is on demand, and you just demand it straight away | 06:44 |
| stevemar | marekd, so where does ksm fit into this? | 06:44 |
| jamielennox | marekd: i disagree, i think the model will change this dramatically | 06:44 |
| marekd | jamielennox: identity design? why? | 06:45 |
| jamielennox | marekd: answer stevemar first | 06:45 |
| stevemar | y plz :) | 06:45 |
| marekd | stevemar: 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 |
| marekd | stevemar: 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 | |
| marekd | jamielennox: your turn :-) | 06:50 |
| jamielennox | so i have an issue with making auth_token request a token from a remote cloud | 06:51 |
| stevemar | jamielennox, marekd, does ksm even handle token auth nicely? i thought it mainly works with service accounts / service password | 06:51 |
| jamielennox | auth_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 seperately | 06:51 |
| marekd | jamielennox: no matter what model we use (push vs pull), it's always your local cloud which initiates the action.... | 06:54 |
| jamielennox | marekd: i guess all my options involve generating both tokens ahead of time | 06:55 |
| *** henrynash has joined #openstack-keystone | 06:56 | |
| *** ChanServ sets mode: +v henrynash | 06:56 | |
| marekd | jamielennox: 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 |
| marekd | local token will be for..well, validating the request with the local side, whilst remote for remote side... | 06:58 |
| marekd | jamielennox: i could live with ksc/ksa finding the remote image endpoint in the remote token as well and passing this as a parameter/header | 06:59 |
| jamielennox | marekd: that pattern has no real involvement from auth_token middleware | 07:00 |
| jamielennox | i mean it would validate the local token as per normal, but it does'nt know how to validate a token for a remote cloud | 07:00 |
| jamielennox | so you would essentially just be providing that token for glance to do what it liked with | 07:00 |
| marekd | jamielennox: so, how does kmw validate the token today? how does it figure out auth_url ? | 07:01 |
| jamielennox | it doesn't, it's provided via conf | 07:01 |
| jamielennox | actually | 07:01 |
| jamielennox | no, it gets it from the catalog of the local token i think | 07:01 |
| marekd | so we could repeat it for remote token. | 07:02 |
| jamielennox | but auth_token can't validate a remote_token | 07:02 |
| marekd | why then? | 07:02 |
| marekd | certs etc? | 07:02 |
| jamielennox | certs, you would need to know which keystone to go to, you would need service accounts for that keysotne | 07:02 |
| marekd | hm, right. | 07:03 |
| jamielennox | but 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_token | 07:03 |
| marekd | jamielennox: allright. now given that you know what I want to do - do you see it can happen in ksc/ksa ? | 07:03 |
| jamielennox | auth_token will only touch the headers that it knows about, everything else just passes through | 07:03 |
| marekd | jamielennox: cool! | 07:04 |
| jamielennox | marekd: so the issue i see is knowing the endpoints from the token | 07:04 |
| jamielennox | hmm, which i guess is a reason for auth_token | 07:05 |
| jamielennox | if you get a blob you have no idea where the remote glance is | 07:05 |
| marekd | :D | 07:05 |
| jamielennox | marekd: i'm happy for you to do all this in glance, i'm just concerned about it in middlewarew | 07:05 |
| marekd | jamielennox: 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 |
| marekd | ok, let's not call it image-url, but remote-glance-url | 07:06 |
| jamielennox | you 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 server | 07:07 |
| *** greghaynes has quit IRC | 07:08 | |
| marekd | jamielennox: that was my initial idea, and i thought identity bits in glance (hence ksm) would be the best part... | 07:08 |
| marekd | i don't think inplementing k2k-client in glance is a good idea... | 07:08 |
| marekd | and that's why i started thinking about kmw+k2k | 07:08 |
| jamielennox | marekd: auth_token is not the only place that gets to do identity operations | 07:08 |
| jamielennox | you can do it from wherever you like | 07:08 |
| marekd | jamielennox: so, for instance glance would depend on ksa (if it doesn't today) and run some auth-like plugin somewhere inside itself? | 07:09 |
| jamielennox | marekd: yea | 07:09 |
| jamielennox | you would use the plugin from auth_token as the local cloud plugin, then wrap the k2k around that | 07:10 |
| marekd | jamielennox: do you think it would be wise to do so? | 07:10 |
| marekd | maybe we shoould make another middleware, but for k2k purposes like this? | 07:10 |
| jamielennox | i think that the use case for generating this token on the fly doesn't make sense in the general case | 07:10 |
| jamielennox | because you are still going to need to have glance do a whole lot of work that is specific to this use case | 07:11 |
| *** greghaynes has joined #openstack-keystone | 07:11 | |
| jamielennox | like use this token and this service catalog instead of the normal one | 07:11 |
| marekd | this sounds like general use-case | 07:11 |
| jamielennox | i think having glance handle the k2k makes sense because you can submit the remote sp as part of request rather than tacking on headers | 07:12 |
| jamielennox | marekd: it will have to be general at some point once we do federated resources | 07:12 |
| marekd | jamielennox: 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 |
| jamielennox | but 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 use | 07:13 |
| jamielennox | marekd: you don't need scoping if you've got two tokens | 07:13 |
| *** rlt has joined #openstack-keystone | 07:13 | |
| marekd | jamielennox: if i pass two tokens to service like glance i don't need it to do any k2k then. | 07:14 |
| marekd | because i already did this with ksa on my local laptop. | 07:14 |
| * marekd will be back in 5 mins | 07:14 | |
| jamielennox | marekd: you don't need scoping information you just need the sp name/id | 07:15 |
| *** chlong has quit IRC | 07:18 | |
| *** browne has quit IRC | 07:19 | |
| *** woodster_ has quit IRC | 07:21 | |
| marekd | jamielennox: suppose i pass sp id, it gets data from the service catalog, fetches the remote token but the token is unscoped. | 07:22 |
| marekd | and i need to scope it to make it usable. | 07:22 |
| jamielennox | marekd: i didn't think you could do that | 07:22 |
| jamielennox | k2k was always scoped to scoped | 07:22 |
| marekd | jamielennox: no :( | 07:22 |
| jamielennox | ugh | 07:22 |
| marekd | jamielennox: from the remote cloud, it's like old federation | 07:22 |
| marekd | jamielennox: that's why it's also this: https://review.openstack.org/#/c/188881/ | 07:23 |
| jamielennox | :( | 07:24 |
| jamielennox | why | 07:24 |
| marekd | jamielennox: 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 |
| marekd | so there was no way to actually send scoping info in the first call.... | 07:28 |
| *** bradjones has quit IRC | 07:30 | |
| jamielennox | then yes, you need scoping as well | 07:32 |
| jamielennox | we are going to need a way of addressing this stuff, damnit, maybe adam is rigth | 07:32 |
| *** bradjones has joined #openstack-keystone | 07:36 | |
| *** bradjones has quit IRC | 07:36 | |
| *** bradjones has joined #openstack-keystone | 07:36 | |
| *** tobe has quit IRC | 07:40 | |
| *** pnavarro has joined #openstack-keystone | 07:41 | |
| jamielennox | stevemar: you still awake? | 07:42 |
| marekd | adam? about what? | 07:42 |
| marekd | jamielennox: ^^ | 07:43 |
| jamielennox | oh, the way you might need to describe a resource | 07:43 |
| jamielennox | resource_id IN project_id IN cloud_id | 07:44 |
| *** tobe has joined #openstack-keystone | 07:47 | |
| marekd | jamielennox: 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 |
| marekd | makes sense? | 07:50 |
| jamielennox | i would prefer to go the other way | 07:50 |
| jamielennox | start in glance and then we'll abstract what is common to auth_token | 07:50 |
| ccard | anyone have any comments on my issue here: http://lists.openstack.org/pipermail/openstack/2015-June/013061.html | 07:50 |
| *** bdossant has joined #openstack-keystone | 07:51 | |
| marekd | jamielennox: 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 | |
| jamielennox | ccard: it's really not my area but it seems unlikely that horizon should be the difference because it's just using the keystone APIs | 07:53 |
| jamielennox | so i guess what you are looking for is what is happening when you shut down an ldap from keystone | 07:53 |
| jamielennox | i 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 point | 07:54 |
| *** belmoreira has joined #openstack-keystone | 07:54 | |
| jamielennox | marekd: umm, i don't know - how much user interaction do you expect there to be in this interation | 07:56 |
| jamielennox | is the user saying where to replicate to / | 07:56 |
| marekd | jamielennox: yes. | 07:56 |
| jamielennox | so why wouldn't it be part of the glance payload | 07:56 |
| marekd | because it looks like a identity part. | 07:56 |
| ccard | jamielennox: 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 |
| jamielennox | ccard: 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 returned | 07:58 |
| jamielennox | so turn the keystone workers down to 1 | 07:58 |
| jamielennox | put in some sleep statements and see what happens if a connection goes away | 07:59 |
| ccard | jamielennox: I've restarted Apache (and hence horizon and keystone) after shutting down the LDAP server, and I still see the same behaviour | 07:59 |
| jamielennox | oh - ongoing ? | 07:59 |
| jamielennox | as in easily reproducable? | 07:59 |
| ccard | every time | 07:59 |
| jamielennox | ok, well put in pdb and step through it | 08:00 |
| ccard | how do I run an Apache wsgi app under pdb? (not a Python expert :( ) | 08:01 |
| jamielennox | so look at rpdb | 08:01 |
| jamielennox | put an import rpdb; rpdb.set_trace() where things start to get interesting | 08:01 |
| jamielennox | it will open a local tcp socket that you can netcat to | 08:01 |
| jamielennox | i can't remember the port but it will say on the rpdb page | 08:02 |
| jamielennox | from there it's the same as pdb | 08:02 |
| ccard | thanks, I'll take a look at that - sounds like it will be a useful technique in general | 08:02 |
| jamielennox | it's the only way i know to put breakpoints in under apache | 08:02 |
| jamielennox | probably 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 statement | 08:03 |
| jamielennox | marekd: 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 sense | 08:04 |
| jamielennox | i think you just doc that the remote cloud token has to be scoped to what you want | 08:04 |
| jamielennox | the alternative is just ugly | 08:04 |
| jamielennox | but i think you should do the k2k step as part of glance | 08:05 |
| jamielennox | ugh, scoping info still :( | 08:05 |
| *** tobe has quit IRC | 08:06 | |
| marekd | pasing the http headers will be too much ? | 08:06 |
| jamielennox | you can try it, but you've got project_id, project_name, project_domain_id, project_domain_name | 08:07 |
| jamielennox | all optional | 08:07 |
| marekd | ok, i will keep you updated... | 08:07 |
| marekd | it's a bit harder for me to make it work, as I am sometimes getting constraints from two separate teams :-) | 08:08 |
| marekd | keystone and glance | 08:08 |
| jamielennox | marekd: i think you should organize like a joint meeting | 08:10 |
| jamielennox | i don't think the glance team is going to fully understand the implications of k2k | 08:10 |
| jamielennox | and i've no idea what glance wants for there service | 08:10 |
| marekd | jamielennox: 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 |
| jamielennox | so scoping would be an issue you wouldn't have with a pull based flow | 08:13 |
| jamielennox | but yea, i can understand their position as well | 08:13 |
| marekd | i 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 |
| jamielennox | sure but you'd know on the client side whether it worked and whether the scoping info was present | 08:14 |
| marekd | i don't follow. It's the client who provides scoping info. | 08:15 |
| jamielennox | you wouldn't have to provide that info to the servers | 08:15 |
| jamielennox | either glance | 08:15 |
| *** tobe has joined #openstack-keystone | 08:16 | |
| *** fhubik has joined #openstack-keystone | 08:19 | |
| *** jaosorior has joined #openstack-keystone | 08:27 | |
| *** afazekas has joined #openstack-keystone | 08:28 | |
| openstackgerrit | Marcos FermÃn Lobo proposed openstack/python-keystoneclient: Added endpoint group filter manager methods https://review.openstack.org/182658 | 08:34 |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Fetch resource ID as unicode https://review.openstack.org/192104 | 08:36 |
| jamielennox | ah, that was stupidly more difficult than it should have been | 08:36 |
| *** btully has quit IRC | 08:37 | |
| *** henrynash has quit IRC | 08:38 | |
| *** henrynash_ has joined #openstack-keystone | 08:38 | |
| *** ChanServ sets mode: +v henrynash_ | 08:38 | |
| *** btully has joined #openstack-keystone | 08:39 | |
| *** rushiagr_away is now known as rushiagr | 08:44 | |
| *** viktors|afk has quit IRC | 08:47 | |
| *** mtecer has joined #openstack-keystone | 08:49 | |
| *** viktors has joined #openstack-keystone | 08:51 | |
| *** stevemar has quit IRC | 08:52 | |
| *** mtecer has quit IRC | 08:54 | |
| *** lhcheng has quit IRC | 08:56 | |
| *** chlong has joined #openstack-keystone | 08:59 | |
| *** aix has joined #openstack-keystone | 09:00 | |
| *** ncoghlan has quit IRC | 09:03 | |
| *** chlong has quit IRC | 09:07 | |
| *** e0ne has joined #openstack-keystone | 09:12 | |
| *** dims has joined #openstack-keystone | 09:18 | |
| *** chlong has joined #openstack-keystone | 09:20 | |
| *** e0ne is now known as e0ne_ | 09:21 | |
| *** dims has quit IRC | 09:23 | |
| *** e0ne_ has quit IRC | 09:25 | |
| *** krykowski has quit IRC | 09:27 | |
| rushiagr | hello keystone folks! | 09:27 |
| *** e0ne has joined #openstack-keystone | 09:28 | |
| rushiagr | I was looking at stable driver interface effort, and want to contribute to it | 09:28 |
| rushiagr | It's unclear to me what is decides with regards to direction | 09:28 |
| rushiagr | the etherpad from the Vancouver summit talks about many options -- StrictABC, double book accounting, and Testing. I'm not sure what was the final decision | 09:30 |
| rushiagr | I see patches for StrictABC and for passing information between driver & manager via objects | 09:31 |
| rushiagr | so I was just curious that if something is already decided, I can help with reviews and code too... | 09:31 |
| rushiagr | I 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 suffice | 09:38 |
| *** henrynash_ has quit IRC | 09:40 | |
| rushiagr | thoughts? 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-keystone | 09:40 | |
| *** ChanServ sets mode: +v henrynash | 09:40 | |
| *** fhubik is now known as fhubik_afk | 09:41 | |
| *** tobe has quit IRC | 09:46 | |
| *** dguerri` is now known as dguerri | 09:48 | |
| *** kiran-r has quit IRC | 09:50 | |
| *** MaxV has joined #openstack-keystone | 09:51 | |
| MaxV | Hello all, I have an issue with the setup of keystone using the v3 endpoint only | 09:53 |
| MaxV | I start with a from scratch config and I want to config keystone (creating users, projects) | 09:53 |
| MaxV | but it seems that I am not using the good path of initialization | 09:53 |
| MaxV | I have an admin token and everything works fine on the v2 endpoint | 09:53 |
| MaxV | but when using the v3 endpoint I keep running into 401 error | 09:53 |
| MaxV | I tried to ask for a new token using the token_admin, but I get a 404 | 09:53 |
| marekd | MaxV: what's you environment setup? | 09:53 |
| marekd | MaxV: env | grep OS | 09:54 |
| MaxV | marekd: backend sql, using debian, keystone from master branch on github | 09:56 |
| marekd | i meant env :-) | 09:56 |
| *** tobe has joined #openstack-keystone | 09:56 | |
| MaxV | no OS setup | 09:57 |
| MaxV | using only curl | 09:57 |
| MaxV | no openstack-client | 09:57 |
| MaxV | openstack-client works because it uses the v2 endpoint | 09:58 |
| *** fhubik_afk is now known as fhubik | 09:59 | |
| MaxV | basically I only have a OS_ENDPOINT and a OS_TOKEN when dealing with keystone v2 | 10:00 |
| *** aix has quit IRC | 10:01 | |
| marekd | so what is that your are sending to keystone ? | 10:02 |
| MaxV | only the OS_TOKEN in order to create users and projects | 10:03 |
| MaxV | which works on the v2 endpoint | 10:03 |
| marekd | ok, but you must send some HTTP request to some url. | 10:03 |
| marekd | what is this url for instance? | 10:04 |
| *** e0ne is now known as e0ne_ | 10:06 | |
| MaxV | marekd: ok, so I missed a point with the domain | 10:08 |
| MaxV | marekd: I noticed it when I get back on the doc | 10:09 |
| marekd | cool | 10:09 |
| marekd | it's weird that it was 404 | 10:09 |
| marekd | but... | 10:09 |
| MaxV | marekd: sorry for the disturbance | 10:09 |
| marekd | MaxV: not a problem at all | 10:09 |
| *** aix has joined #openstack-keystone | 10:12 | |
| *** e0ne_ has quit IRC | 10:12 | |
| *** e0ne has joined #openstack-keystone | 10:17 | |
| ccard | jamielennox: 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 |
| ccard | If I set use_pool and pool_connection_timeout in the [ldap] section, login from horizon appears to work ok. | 10:36 |
| jamielennox | ccard: ok, good you found it, i would have hoped that if there was a connection error it was reported rather than dropped | 10:39 |
| jamielennox | is there a firewall or something that is dropping packets rather than rejecting them> | 10:39 |
| *** fhubik is now known as fhubik_afk | 10:42 | |
| ccard | jamielennox: yes, there is a firewall between keystone and ldap, the servers are on different subnets, so the route goes through the firewall. | 10:43 |
| jamielennox | ccard: 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 timeout | 10:44 |
| *** lhcheng has joined #openstack-keystone | 10:45 | |
| *** ChanServ sets mode: +v lhcheng | 10:45 | |
| ccard | good idea, I'll talk to the firewall experts round here | 10:46 |
| *** lhcheng has quit IRC | 10:50 | |
| *** tobe has quit IRC | 10:50 | |
| *** tobe has joined #openstack-keystone | 10:51 | |
| *** henrynash has quit IRC | 10:53 | |
| *** henrynash has joined #openstack-keystone | 10:56 | |
| *** ChanServ sets mode: +v henrynash | 10:56 | |
| *** tobe has quit IRC | 10:56 | |
| samueldmq | morning! | 10:57 |
| *** mabrams has quit IRC | 11:01 | |
| *** e0ne is now known as e0ne_ | 11:12 | |
| *** dims has joined #openstack-keystone | 11:20 | |
| *** e0ne_ has quit IRC | 11:23 | |
| *** dims has quit IRC | 11:25 | |
| *** fhubik_afk is now known as fhubik | 11:26 | |
| *** dims has joined #openstack-keystone | 11:29 | |
| *** jdennis has quit IRC | 11:33 | |
| *** e0ne has joined #openstack-keystone | 11:37 | |
| *** kiran-r has joined #openstack-keystone | 11:41 | |
| *** bdossant has quit IRC | 11:42 | |
| *** jdennis has joined #openstack-keystone | 11:42 | |
| *** josecastroleon has quit IRC | 11:42 | |
| *** bdossant has joined #openstack-keystone | 11:42 | |
| *** josecastroleon has joined #openstack-keystone | 11:44 | |
| *** neelabh has joined #openstack-keystone | 11:45 | |
| *** henrynash_ has joined #openstack-keystone | 11:46 | |
| *** ChanServ sets mode: +v henrynash_ | 11:46 | |
| *** henrynash has quit IRC | 11:47 | |
| *** henrynash_ is now known as henrynash | 11:47 | |
| neelabh | Hi 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 |
| samueldmq | neelabh, hi | 11:48 |
| neelabh | <samueldmq>, hi | 11:48 |
| samueldmq | neelabh, you're in a test environment (since you're using devstack), right ? | 11:48 |
| neelabh | yes | 11:49 |
| samueldmq | neelabh, have you tried (in the devstack directory): ./unstack.sh and then ./stack.sh again? | 11:49 |
| neelabh | One 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 command | 11:51 |
| neelabh | <samueldmq>, | 11:51 |
| jamielennox | neelabh: devstack is only for testing, if you run it again it will create the file again | 11:52 |
| neelabh | Thanks | 11:53 |
| samueldmq | jamielennox, ++ | 11:54 |
| neelabh | jamielennox, sorry to disturb, One more question, what will be password for admin, I have changed the admin password.. | 11:57 |
| *** kodoku has joined #openstack-keystone | 11:58 | |
| neelabh | after runninng above commad | 11:58 |
| jamielennox | neelabh: if you didn't set it with an env command then it will generate one randomly | 11:59 |
| jamielennox | it will be put into the devstack/accrc/admin/admin file | 11:59 |
| neelabh | k | 11:59 |
| jamielennox | samueldmq: OSC 1.4 was released so _most_ of the v3 only reviews are working | 12:00 |
| *** edmondsw has joined #openstack-keystone | 12:00 | |
| jamielennox | samueldmq: starts here https://review.openstack.org/#/c/186678/ | 12:01 |
| samueldmq | jamielennox, oh great, very happy to hear :) | 12:01 |
| samueldmq | jamielennox, at the end of that chain of review .. does it work ? do we need other patches ? | 12:02 |
| jamielennox | samueldmq: there's a bug in OSC :( | 12:05 |
| jamielennox | so i need to look at how i can hack around that because i don't want to wait for a new release again | 12:05 |
| samueldmq | jamielennox, yes makes sense | 12:05 |
| samueldmq | jamielennox, btw is the bug what is making your last patch to fail ? | 12:05 |
| jamielennox | it made it fail on the vm i was testing on | 12:06 |
| jamielennox | so i assume so | 12:06 |
| samueldmq | jamielennox, 'Convert identity defaults to keystone v3 api' (https://review.openstack.org/#/c/186684/) | 12:06 |
| *** kodoku has quit IRC | 12:06 | |
| samueldmq | jamielennox, k makes sense | 12:06 |
| jamielennox | http://logs.openstack.org/84/186684/3/check/check-tempest-dsvm-full/241a714/logs/devstacklog.txt.gz#_2015-06-16_09_12_31_122 | 12:06 |
| jamielennox | yep that one - and that error | 12:06 |
| jamielennox | we're blaming martinelli when you get a chance :p | 12:07 |
| samueldmq | jamielennox, haha | 12:07 |
| samueldmq | jamielennox, so when querying endpoints by name, keystone server returns a list | 12:08 |
| samueldmq | jamielennox, and the client was assuming that would be a single element (however endpoint name doesn't uniquely identify the enedpoint) | 12:09 |
| samueldmq | jamielennox, am I right ? | 12:09 |
| *** kodoku has joined #openstack-keystone | 12:10 | |
| *** raildo has joined #openstack-keystone | 12:11 | |
| kodoku | Hi, 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 |
| kodoku | But when I request keystone not works because keystone send me ==> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to http://server:5000/v2.0/tokens | 12:12 |
| kodoku | not https://server:5000..... | 12:12 |
| kodoku | so cinder python client no works because it use this link for make his request | 12:12 |
| kodoku | Any idea for my issue ? | 12:13 |
| jamielennox | kodoku: so if you've got HA proxy or something else doing the SSL termination you will need to move keystone to something else | 12:14 |
| jamielennox | eg port 5001 | 12:14 |
| jamielennox | and then the terminator will operate on port 5000 and redirect to 5001 | 12:15 |
| kodoku | why ? | 12:15 |
| jamielennox | kodoku: because only one service can listen on a port | 12:15 |
| kodoku | nop | 12:15 |
| kodoku | apache listen on my IP:5000 | 12:15 |
| kodoku | keystone listen on 127.0.0.1:5000 | 12:15 |
| kodoku | and apache redirect IP:5000 on 127.0.0.1:5000 | 12:16 |
| kodoku | works now | 12:16 |
| jamielennox | oh you bound them to the ip? | 12:16 |
| kodoku | but cinder client no works because it use keystone links return | 12:16 |
| jamielennox | umm, it should work i've never tried | 12:16 |
| kodoku | it works with all service ^^ | 12:16 |
| jamielennox | the service catalog? | 12:16 |
| kodoku | yes | 12:16 |
| kodoku | when request on /v2.0 | 12:16 |
| jamielennox | so you can do like openstack endpoint list or something similar and change the endpoints | 12:17 |
| jamielennox | the easier way i do though is just open up the 'endpoint' table in the database and make sure they are pointing to the public IPs | 12:17 |
| *** kiran-r has quit IRC | 12:17 | |
| kodoku | endpoint is conf on my apache proxy with HTTPS | 12:17 |
| kodoku | because keystone return => "id": "v2.0", "links": [{"href": "http://juno001:5000/v2.0/", "rel": "self"}, {"href": "http://openstk............ | 12:18 |
| kodoku | and my endpoint is https | 12:18 |
| jamielennox | oh, right | 12:18 |
| jamielennox | there is a fix for that... | 12:18 |
| jamielennox | umm | 12:18 |
| jamielennox | so you can either set the public_endpoint and admin_endpoint in the keystone.conf | 12:19 |
| jamielennox | that will hard code it for you | 12:19 |
| kodoku | I don't know why cinder client use this link and nova client use endpoint links | 12:19 |
| kodoku | Can I force this links in keystone.conf ? | 12:20 |
| jamielennox | kodoku: this is for GET / on keysotne right? | 12:20 |
| kodoku | request is => DEBUG:keystoneclient.session:REQ: curl -i --insecure -X GET https://juno001:5000/v2.0/ | 12:21 |
| jamielennox | and GET /v2.0 i guess | 12:21 |
| jamielennox | ok | 12:21 |
| jamielennox | kodoku: yes, if you set public_endpoint = https://juno001:5000/v2.0 in keystone.conf it will fix it | 12:21 |
| jamielennox | you probably want to do the same with admin_endpoint but for port 35357 | 12:22 |
| *** bknudson has quit IRC | 12:22 | |
| kodoku | ok, I look conf of keystone thx | 12:23 |
| *** fhubik has quit IRC | 12:24 | |
| *** fhubik has joined #openstack-keystone | 12:25 | |
| *** mtecer_ has joined #openstack-keystone | 12:27 | |
| kodoku | jamielennox ok the link is modify :) | 12:31 |
| kodoku | thx | 12:31 |
| *** mtecer_ has quit IRC | 12:32 | |
| *** lhcheng has joined #openstack-keystone | 12:34 | |
| *** ChanServ sets mode: +v lhcheng | 12:34 | |
| *** kodoku has quit IRC | 12:38 | |
| *** lhcheng has quit IRC | 12:39 | |
| *** redrobot has joined #openstack-keystone | 12:42 | |
| *** redrobot is now known as Guest74993 | 12:42 | |
| *** Guest74993 is now known as el_robot_rojo | 12:43 | |
| *** el_robot_rojo is now known as redrobot | 12:44 | |
| *** amakarov_away is now known as amakarov | 12:46 | |
| *** henrynash has quit IRC | 12:47 | |
| *** dsirrine has joined #openstack-keystone | 12:48 | |
| *** henrynash has joined #openstack-keystone | 12:49 | |
| *** ChanServ sets mode: +v henrynash | 12:49 | |
| *** bknudson has joined #openstack-keystone | 12:50 | |
| *** ChanServ sets mode: +v bknudson | 12:50 | |
| *** sbezverk has joined #openstack-keystone | 12:56 | |
| sbezverk | Hello, 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-keystone | 12:58 | |
| *** ChanServ sets mode: +v lhcheng | 12:58 | |
| amakarov | morganfainberg, hello! May I ask you about an invitation letter again? :) | 13:00 |
| *** lhcheng has quit IRC | 13:03 | |
| *** kiran-r has joined #openstack-keystone | 13:03 | |
| neelabh | jamielennox, Thank-you very much, you save my day.... | 13:03 |
| *** zzzeek has joined #openstack-keystone | 13:05 | |
| *** afazekas has quit IRC | 13:09 | |
| *** ayoung has joined #openstack-keystone | 13:10 | |
| *** ChanServ sets mode: +v ayoung | 13:10 | |
| samueldmq | neelabh, great, feel free to come here with questions when you're blocked, #keystone community will be glad to help you | 13:10 |
| samueldmq | neelabh, that's part of why opensource is amazing :) | 13:10 |
| *** rushiagr is now known as rushiagr_away | 13:10 | |
| neelabh | thanks,, | 13:11 |
| viktors | lbragstad: hi! Just a tiny reminder about the patch https://review.openstack.org/#/c/80630/ | 13:12 |
| lbragstad | viktors: ah cool, you pushed a new patch. Thanks! | 13:13 |
| *** fhubik has quit IRC | 13:19 | |
| *** richm1 has joined #openstack-keystone | 13:19 | |
| *** fhubik has joined #openstack-keystone | 13:19 | |
| *** richm1 is now known as richm | 13:20 | |
| *** fhubik is now known as fhubik_afk | 13:22 | |
| *** mtecer has joined #openstack-keystone | 13:29 | |
| *** mtecer has quit IRC | 13:33 | |
| *** Ctina has joined #openstack-keystone | 13:40 | |
| *** csoukup has joined #openstack-keystone | 13:41 | |
| openstackgerrit | Marcos FermÃn Lobo proposed openstack/python-keystoneclient: Added endpoint group filter manager methods https://review.openstack.org/182658 | 13:43 |
| *** neelabh has quit IRC | 13:43 | |
| *** RichardRaseley has joined #openstack-keystone | 13:44 | |
| *** fhubik_afk is now known as fhubik | 13:45 | |
| *** e0ne is now known as e0ne_ | 13:51 | |
| *** bdossant has quit IRC | 13:54 | |
| *** e0ne_ is now known as e0ne | 13:54 | |
| *** fhubik is now known as fhubik_afk | 14:07 | |
| *** fangzhou has joined #openstack-keystone | 14:08 | |
| *** woodster_ has joined #openstack-keystone | 14:09 | |
| *** henrynash_ has joined #openstack-keystone | 14:09 | |
| *** ChanServ sets mode: +v henrynash_ | 14:09 | |
| *** RichardRaseley has quit IRC | 14:10 | |
| *** fhubik_afk is now known as fhubik | 14:10 | |
| *** fhubik is now known as fhubik_afk | 14:10 | |
| *** henrynash has quit IRC | 14:10 | |
| *** henrynash_ is now known as henrynash | 14:10 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:16 | |
| *** RichardRaseley has joined #openstack-keystone | 14:18 | |
| lbragstad | o/ dolphm wondering if I could get your input on this guy https://bugs.launchpad.net/keystone/+bug/1465444 | 14:20 |
| openstack | Launchpad bug 1465444 in Keystone "Fernet key rotation removing keys early" [High,Triaged] - Assigned to Dolph Mathews (dolph) | 14:20 |
| lbragstad | dolphm: oh, nevermind, you've already seen it | 14:20 |
| ayoung | morganfainberg, I'm blown away. That presentation rocks. | 14:20 |
| morganfainberg | Hm? | 14:21 |
| morganfainberg | amakarov: I passed on the info to the foundation. I will follow up today/tomorrow. | 14:21 |
| amakarov | morganfainberg, thank you | 14:21 |
| morganfainberg | ayoung: 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 |
| ayoung | morganfainberg, yeah, I have an hour...lots of slides to get through in that time | 14:22 |
| morganfainberg | ayoung: I also want to change the section breaks and title slide/questions slide theme. | 14:22 |
| ayoung | morganfainberg, also, SSSD is not future work...it can be done today...I think I'm miving that slide to after the SAML flow in federation | 14:23 |
| morganfainberg | This deck was designed for ~40-45 min including 5min q&a | 14:23 |
| ayoung | I'll try to get something more clear about how it works. | 14:23 |
| ayoung | morganfainberg, that should be perfect....you are making me look good here.... | 14:23 |
| morganfainberg | But easy to expand, esp if there is any interactive stuff. | 14:23 |
| morganfainberg | Give Steve credit too, he did a huge chunk of it. | 14:24 |
| ayoung | morganfainberg, 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 share | 14:24 |
| morganfainberg | This was a collaboration between us, and stealing some of nkinder's graphics. | 14:24 |
| bknudson | is the presentation posted somewhere? | 14:24 |
| ayoung | morganfainberg, I was going to give him props first, but as you see, he is not here.. I'll thank him later | 14:24 |
| bknudson | I'd like to have something to point people at | 14:25 |
| morganfainberg | bknudson: it will be soon. Need to convert to html | 14:25 |
| ayoung | bknudson, its being shared around on google docs. I made a copy that I am hacking on a bit | 14:25 |
| morganfainberg | bknudson: on my short list for this week while I'm mostly afk from irc | 14:25 |
| morganfainberg | Then I'll get it published. | 14:25 |
| morganfainberg | Oh.. I need to setup the "call for a new keystone mascot" and subsequent logo email. | 14:27 |
| ayoung | morganfainberg, should I add an "authors" slide at the end? | 14:27 |
| morganfainberg | ayoung: sure. | 14:27 |
| morganfainberg | If you want. | 14:27 |
| morganfainberg | I won't be upset if you don't ;) | 14:27 |
| ayoung | morganfainberg, so, you, steve , nate...anyone else? | 14:27 |
| morganfainberg | Steve, Nate, me, and you if your hacking on it. | 14:28 |
| morganfainberg | Youre* | 14:28 |
| * morganfainberg kicks autocorrect | 14:28 | |
| *** henrynash has quit IRC | 14:28 | |
| bknudson | should be called autoincorrect | 14:29 |
| *** kiran-r has quit IRC | 14:29 | |
| *** kiran-r has joined #openstack-keystone | 14:29 | |
| *** blewis has joined #openstack-keystone | 14:30 | |
| *** Guest68660 is now known as mfisch | 14:30 | |
| *** mfisch is now known as Guest81226 | 14:31 | |
| morganfainberg | bknudson: yes | 14:32 |
| ayoung | morganfainberg, do you want your gmail or your HP email address on it? | 14:32 |
| morganfainberg | Gmail plz | 14:32 |
| ayoung | wilco | 14:32 |
| morganfainberg | If 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-keystone | 14:33 | |
| *** ChanServ sets mode: +v henrynash | 14:33 | |
| *** dsirrine has quit IRC | 14:33 | |
| ayoung | morganfainberg, nah, just doing the email address. | 14:35 |
| *** kiran-r has quit IRC | 14:35 | |
| *** dsirrine has joined #openstack-keystone | 14:35 | |
| *** henrynash_ has joined #openstack-keystone | 14:37 | |
| *** ChanServ sets mode: +v henrynash_ | 14:37 | |
| *** Guest81226 has quit IRC | 14:38 | |
| *** henrynash has quit IRC | 14:39 | |
| *** henrynash_ is now known as henrynash | 14:39 | |
| breton | there was patch https://review.openstack.org/#/c/127066/ | 14:40 |
| breton | which options should be used instead of deprecated ones? | 14:40 |
| breton | are they listed on http://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html ? | 14:41 |
| *** obedmr has joined #openstack-keystone | 14:43 | |
| bknudson | breton: http://www.jamielennox.net/blog/2015/02/23/v3-authentication-with-auth-token-middleware/ | 14:46 |
| *** ayoung has quit IRC | 14:46 | |
| *** e0ne is now known as e0ne_ | 14:47 | |
| *** e0ne_ is now known as e0ne | 14:47 | |
| *** henrynash_ has joined #openstack-keystone | 14:49 | |
| *** ChanServ sets mode: +v henrynash_ | 14:49 | |
| breton | bknudson: thank you | 14:49 |
| *** stevemar has joined #openstack-keystone | 14:50 | |
| *** ChanServ sets mode: +v stevemar | 14:50 | |
| stevemar | jamielennox, so close! | 14:51 |
| *** henrynash has quit IRC | 14:52 | |
| *** henrynash_ is now known as henrynash | 14:52 | |
| *** henrynash has quit IRC | 14:54 | |
| *** henrynash has joined #openstack-keystone | 14:54 | |
| *** ChanServ sets mode: +v henrynash | 14:54 | |
| *** fhubik_afk is now known as fhubik | 14:56 | |
| *** mfisch has joined #openstack-keystone | 14:56 | |
| *** mfisch is now known as Guest25676 | 14:56 | |
| *** ayoung has joined #openstack-keystone | 15:00 | |
| *** ChanServ sets mode: +v ayoung | 15:00 | |
| *** Guest25676 is now known as mfisch | 15:01 | |
| *** mfisch has quit IRC | 15:02 | |
| *** mfisch has joined #openstack-keystone | 15:02 | |
| openstackgerrit | Diane Fleming proposed openstack/keystone-specs: Add side-by-side comparison table of v2 and v3 APIs https://review.openstack.org/187027 | 15:03 |
| *** belmoreira has quit IRC | 15:05 | |
| *** jaypipes has quit IRC | 15:06 | |
| *** henrynash_ has joined #openstack-keystone | 15:07 | |
| *** ChanServ sets mode: +v henrynash_ | 15:07 | |
| *** fhubik is now known as fhubik_afk | 15:08 | |
| *** henrynash has quit IRC | 15:10 | |
| *** henrynash_ has quit IRC | 15:13 | |
| *** henrynash has joined #openstack-keystone | 15:14 | |
| *** ChanServ sets mode: +v henrynash | 15:14 | |
| *** ngupta has joined #openstack-keystone | 15:14 | |
| *** Ctina has quit IRC | 15:14 | |
| dstanek | good morning all | 15:15 |
| *** Ctina has joined #openstack-keystone | 15:15 | |
| *** RichardRaseley is now known as RichardRaseley|A | 15:15 | |
| bknudson | dstanek: happy birthday | 15:16 |
| dstanek | bknudson: thx | 15:16 |
| lbragstad | dstanek: mornin' | 15:17 |
| *** henrynash_ has joined #openstack-keystone | 15:18 | |
| *** ChanServ sets mode: +v henrynash_ | 15:18 | |
| *** henrynash has quit IRC | 15:20 | |
| *** henrynash_ is now known as henrynash | 15:20 | |
| *** kfox1111 has joined #openstack-keystone | 15:21 | |
| *** henrynash_ has joined #openstack-keystone | 15:23 | |
| *** ChanServ sets mode: +v henrynash_ | 15:23 | |
| *** eandersson has joined #openstack-keystone | 15:24 | |
| *** henrynash has quit IRC | 15:26 | |
| *** henrynash_ is now known as henrynash | 15:26 | |
| *** fhubik_afk is now known as fhubik | 15:26 | |
| *** fhubik has quit IRC | 15:27 | |
| *** thedodd has joined #openstack-keystone | 15:27 | |
| *** henrynash_ has joined #openstack-keystone | 15:41 | |
| *** ChanServ sets mode: +v henrynash_ | 15:41 | |
| *** henrynash has quit IRC | 15:44 | |
| *** henrynash_ is now known as henrynash | 15:44 | |
| richm | With 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 project | 15:44 |
| richm | With the v3 API, openstack user create --project projname does not add the new user to the project, using token credentials | 15:45 |
| richm | Is this something that is allowed/denied by the policy? | 15:45 |
| richm | If so, what is the policy? update_project? | 15:47 |
| richm | note I have updated the policy to use is_admin:1 everywhere that users/projects are referenced in the policy | 15:50 |
| richm | I'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 IRC | 15:52 | |
| *** ayoung has quit IRC | 15:57 | |
| eandersson | Is there a specific reason why a call to v3/ec2tokens would not return the values for access? | 16:00 |
| eandersson | It causes this heat code to fail https://github.com/openstack/heat/blob/master/heat/api/aws/ec2token.py#L221 | 16:02 |
| *** henrynash_ has joined #openstack-keystone | 16:03 | |
| *** ChanServ sets mode: +v henrynash_ | 16:03 | |
| *** RichardRaseley|A is now known as RichardRaseley | 16:04 | |
| *** henrynash has quit IRC | 16:05 | |
| *** henrynash_ is now known as henrynash | 16:05 | |
| *** ayoung has joined #openstack-keystone | 16:10 | |
| *** ChanServ sets mode: +v ayoung | 16:10 | |
| *** browne has joined #openstack-keystone | 16:17 | |
| samueldmq | dstanek, morning, happy birthday :) | 16:23 |
| dstanek | samueldmq: thx | 16:28 |
| *** henrynash_ has joined #openstack-keystone | 16:28 | |
| *** ChanServ sets mode: +v henrynash_ | 16:28 | |
| *** henrynash has quit IRC | 16:31 | |
| *** henrynash_ is now known as henrynash | 16:31 | |
| *** MaxV has quit IRC | 16:32 | |
| *** tqtran has joined #openstack-keystone | 16:32 | |
| samueldmq | ayoung, 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-keystone | 16:35 | |
| *** blewis has quit IRC | 16:39 | |
| samueldmq | ayoung, 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 |
| samueldmq | ayoung, sounds good ? | 16:39 |
| *** rushiagr_away is now known as rushiagr | 16:43 | |
| *** _cjones_ has joined #openstack-keystone | 16:43 | |
| *** henrynash has quit IRC | 16:44 | |
| *** kiran-r has quit IRC | 16:45 | |
| *** e0ne has quit IRC | 16:48 | |
| *** kfox1111 has quit IRC | 16:49 | |
| *** kfox1111 has joined #openstack-keystone | 16:50 | |
| *** dguerri is now known as dguerri` | 16:53 | |
| *** thedodd has quit IRC | 16:53 | |
| *** RichardRaseley has quit IRC | 16:56 | |
| ayoung | samueldmq, looking now | 16:57 |
| ayoung | samueldmq, I don't think the user stories are quite right, but its a great starting point for discussion | 16:58 |
| *** dguerri` is now known as dguerri | 16:58 | |
| ayoung | Story 4 - As a user, I want to define role hierarchies, allowing one to only delegate a subset of her roles | 16:58 |
| ayoung | lets start there | 16: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 |
| ayoung | so that user is going to consume the role hierarchy | 16:59 |
| ayoung | it requires support from the admins.... | 16:59 |
| *** Ephur has joined #openstack-keystone | 17:00 | |
| samueldmq | ayoung, as far as I understand, a user should be able to delegate a subset of her roles, right ? | 17:01 |
| ayoung | samueldmq, right, but the use is not going to be setting up the role hierarchy | 17:02 |
| samueldmq | ayoung, it doesn't matter the one she is delegating to (maybe a service) | 17:02 |
| ayoung | just consuming it | 17:02 |
| samueldmq | ayoung, who defines the roles ? | 17:02 |
| samueldmq | ayoung, hierarchies ... | 17:02 |
| ayoung | an end user does not "define role hierarchies," | 17:02 |
| samueldmq | ayoung, I am talking about the definition on that user story ... | 17:02 |
| samueldmq | ayoung, yes I agree I need to be more specific, | 17:02 |
| samueldmq | ayoung, 'As an admin'...' | 17:03 |
| samueldmq | ayoung, since I am talking about the role hierarchy definition | 17:03 |
| samueldmq | ayoung, makes sense? | 17:03 |
| ayoung | samueldmq the role hierarchy is defined global to the openstack deployemnt, and needs to map to the APIs for the individual endpoint | 17:03 |
| ayoung | the endpoint admin should be saying what role a user needs in order to be able to execute an API | 17:03 |
| ayoung | "As a domain admin, I want to define roles that are meaningful to my business" is a good one | 17:04 |
| ayoung | so...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 |
| samueldmq | ayoung, 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-keystone | 17:04 | |
| ayoung | samueldmq, good question...that might be the key question | 17:05 |
| stevemar | richm, around? | 17:06 |
| samueldmq | ayoung, I think anyone with power to create roles should be able to create them hierarchically | 17:06 |
| ayoung | samueldmq, 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 hierarchy | 17:07 |
| samueldmq | ayoung, exactly | 17:07 |
| ayoung | lets put it under the domain admin in the use case list, then | 17:07 |
| samueldmq | ayoung, and by default ,we could be talking about 'cloud', 'domain' and 'project' admins | 17:07 |
| samueldmq | ayoung, which solves the global admin issue, and is a simple but good default | 17:07 |
| ayoung | samueldmq, I don't think, at this stage, we allow project admins to define new roles | 17:08 |
| ayoung | if we were to do that...it would almost make sense to expand the roles on the keystone side instead of in the policy engine | 17:08 |
| ayoung | what if.... | 17:09 |
| *** blewis has joined #openstack-keystone | 17:09 | |
| ayoung | I still like the idea of splitting the policy check up into a role check and a scope check. I think that is key | 17:10 |
| ayoung | only role checks are dynamic | 17:10 |
| samueldmq | ayoung, trhere is an user story for that | 17:10 |
| ayoung | scope checks should be coded by the project team | 17:10 |
| samueldmq | ayoung, exactly | 17:10 |
| ayoung | " As a dev, I want to split policy enforcement between Middleware and the services" | 17:10 |
| samueldmq | ayoung, yes, sounds good ? | 17:10 |
| ayoung | samueldmq, those are not usually user stories | 17:11 |
| ayoung | but...in this mcase ,sure | 17:11 |
| ayoung | why not | 17:11 |
| samueldmq | ayoung, :) | 17:11 |
| samueldmq | ayoung, that's why I put 'As a *dev*' | 17:11 |
| samueldmq | ayoung, since that isn't affecting external behavior | 17:11 |
| ayoung | "as an application developer I want to enforce the scope check separate from the role check" | 17:12 |
| ayoung | yep | 17:12 |
| ayoung | samueldmq, I get it...it allows us to treat the other openstack services as just other types of users. I like that | 17:12 |
| *** spandhe has joined #openstack-keystone | 17:12 | |
| samueldmq | ayoung, not sure I follow what you just got :) | 17:13 |
| ayoung | samueldmq, lets run with this approch:: what use cases do we need to support, Nova, glance, etc... | 17:13 |
| samueldmq | ayoung, get use cases from them ? | 17:13 |
| *** htruta_ has joined #openstack-keystone | 17:13 | |
| ayoung | "as an application deployer, I want to register my application with Keystone so it can manage policy for me?" | 17:13 |
| samueldmq | ayoung, the use cases, from lets say, nova, will be associated in one of those specs | 17:14 |
| ayoung | samueldmq, lets say that a deployer wants to add a new application to an existing cloud...something that Keystone didn't know about ahead of time | 17:14 |
| ayoung | if we solve that, we shoudl also solve what Keystone needs to do for Nova etc today | 17:14 |
| samueldmq | ayoung, 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 |
| ayoung | samueldmq, "from Code" I think means a couple different things | 17:15 |
| ayoung | 1. get decent defaults | 17:15 |
| ayoung | 2. making sure it extends as new APIs are added without each api developer having to be a policy expert | 17:15 |
| *** fangzhou has joined #openstack-keystone | 17:15 | |
| ayoung | 3. making sure it is enforces with a reasonable default prio to the service getting fully "integrate" into Keystone, whatever that may mean | 17:16 |
| ayoung | So...here is a new use case: | 17:16 |
| samueldmq | ayoung, 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 |
| samueldmq | ayoung, if there is a change from the default (we store that separetely on keystone), we should warn | 17:17 |
| samueldmq | ayoung, that covers their needs ^ | 17:17 |
| *** blewis` has joined #openstack-keystone | 17:17 | |
| *** neelabh has joined #openstack-keystone | 17:17 | |
| ayoung | samueldmq, are you editing the Wiki doc with these changes? | 17:18 |
| samueldmq | ayoung, yes | 17:18 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystoneauth: Add Keystone2KeystoneAuthPlugin for K2K federation https://review.openstack.org/188581 | 17:19 |
| samueldmq | ayoung, but .. 'as an application developer I want to add policy enforcement for a new API' | 17:19 |
| samueldmq | ayoung, this would be solved with the CMS uploading the policy for that endpoint to keystone | 17:19 |
| samueldmq | ayoung, wouldn't it ? | 17:19 |
| samueldmq | ayoung, let me show you how I see things: | 17:20 |
| *** blewis has quit IRC | 17:20 | |
| samueldmq | ayoung, i) cms create endpoint in keystone ii) upload default policy and associate to endpoint based on its URL | 17:20 |
| samueldmq | ayoung, do this ^ for each endpoint being added on the system | 17:21 |
| samueldmq | ayoung, if an endpoint was upgraded, do ii) ... updating its default | 17:21 |
| samueldmq | ayoung, if something is different from the default, warn (should be nova use case) | 17:22 |
| samueldmq | ayoung, (we should be storing 'default' and 'actual' policy, somehting like that) | 17:22 |
| samueldmq | that's how I see | 17:22 |
| ayoung | samueldmq, I think it would be something like an "upload-but-don't override" approach | 17:23 |
| ayoung | samueldmq, lets say nova ships with policy.json that has their defaults | 17:23 |
| ayoung | ehtn, they add a newe API. But, in the meantime, the deployment has customized the policy for the other APIS | 17:23 |
| samueldmq | ayoung, the 'actual' policy will be kept, only the default one will be updated | 17:24 |
| ayoung | when 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 ones | 17:24 |
| samueldmq | ayoung, 'actual' contains what you customized, based on default | 17:24 |
| *** gyee has quit IRC | 17:24 | |
| samueldmq | ayoung, and getting the policy is : GET 'default' + override what is in 'actual' | 17:25 |
| ayoung | but, if we associate an endpoint with an explicit policy, the new APIs would not get protected by the rules...or would get the default rule | 17:25 |
| *** pnavarro has quit IRC | 17:25 | |
| *** rushiagr is now known as rushiagr_away | 17:25 | |
| david8hu | ayoung, good idea. We don't want to override the policy that is already in the db. | 17:25 |
| *** Ephur has quit IRC | 17:25 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/oslo.policy: Updated from global requirements https://review.openstack.org/192310 | 17:26 |
| ayoung | david8hu, but we also want to cover existing endpoints with new and updated APIs...it is a tricky problem | 17:26 |
| samueldmq | ayoung, if you just upgraded ... you will get the defaults, unless you customize what comes from defualt | 17:26 |
| samueldmq | ayoung, and I think that makes sense | 17:26 |
| *** gyee has joined #openstack-keystone | 17:26 | |
| *** ChanServ sets mode: +v gyee | 17:26 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements https://review.openstack.org/192319 | 17:26 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-saml2: Updated from global requirements https://review.openstack.org/192320 | 17:26 |
| ayoung | samueldmq, did you read http://adam.younglogic.com/2015/06/dyn-policy-microversions/ | 17:28 |
| samueldmq | ayoung, http://paste.openstack.org/show/295858/ | 17:29 |
| samueldmq | ayoung, that covers the case where a new api is added | 17:29 |
| samueldmq | ayoung, yes I did, and following this approach solves that as well ^ | 17:29 |
| samueldmq | ayoung, considering 'compute:create_container:v3.14.15' | 17:29 |
| samueldmq | ayoung, since it would be like a new API added | 17:30 |
| ayoung | endpoint X {'a':'1', 'b':'2'} | 17:30 |
| samueldmq | yes | 17:30 |
| samueldmq | very basic example :) | 17:30 |
| ayoung | samueldmq, don't you mean APIs there? | 17:30 |
| samueldmq | ayoung, yes sure, I am just communicating about the way we work, not about the content right now | 17:30 |
| ayoung | are you thinking in terms of the database driven approach, and uploading a rule for a new API? | 17:30 |
| samueldmq | ayoung, those are APIs for sure | 17:31 |
| ayoung | OK...those are not endpoints | 17:31 |
| ayoung | targets, Ithink; is the term you want | 17:31 |
| samueldmq | ayoung, let me get you a more concrete example | 17:31 |
| ayoung | samueldmq, nah, I get it... | 17:31 |
| samueldmq | ayoung, nice :) | 17:32 |
| samueldmq | ayoung, does that make sense ? | 17:32 |
| samueldmq | ayoung, we solve what we want + what nova people want, and that is simple | 17:32 |
| ayoung | samueldmq, yeah, I was essentially saying the same thing, but assuming that you are uploading a whole policy file at once | 17:32 |
| samueldmq | ayoung, although that does not include unified policy, (what would be fine, at least for now imo) | 17:32 |
| ayoung | samueldmq, 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 policy | 17:33 |
| samueldmq | ayoung, for example ? | 17:34 |
| samueldmq | ayoung, let's ship individual policies that make sense in a whole, together | 17:35 |
| samueldmq | ayoung, with consistent common rules (is_admin ?), we should be able to put them together later if we want | 17:35 |
| *** lhcheng has joined #openstack-keystone | 17:37 | |
| *** ChanServ sets mode: +v lhcheng | 17:37 | |
| samueldmq | ayoung, this way we do a smaller set of changes, that already fits our needs + other people needs + fixes 968696 | 17:37 |
| david8hu | samueldmq, I like the idea. We can get the policy right without going unified first. | 17:37 |
| samueldmq | ayoung, yes, 968696 | 17:37 |
| *** aix has quit IRC | 17:37 | |
| samueldmq | ayoung, you'll be happy (everybody will) solving that 968696 :) | 17:37 |
| ayoung | samueldmq, one sec... | 17:38 |
| samueldmq | ayoung, and we attack that in a baby steps appraoch | 17:38 |
| samueldmq | ayoung, sure | 17:38 |
| *** lufix has quit IRC | 17:38 | |
| samueldmq | david8hu, yes I think that makes more sense, we change less and get what we want for now | 17:38 |
| david8hu | samueldmq, ayoung, all we need is a better default to solve 968696 from get go. | 17:38 |
| *** dguerri` is now known as dguerri | 17:38 | |
| samueldmq | david8hu, + more power when defining roles + dynamically management of policies | 17:39 |
| samueldmq | david8hu, I think you had said me people from your team were working on providing better defaults | 17:40 |
| samueldmq | david8hu, maybe it was not you, I am just confirming :) | 17:41 |
| david8hu | samueldmq, I was me :) | 17:41 |
| samueldmq | david8hu, nice ! | 17:41 |
| samueldmq | david8hu, I still have some working memory in my head | 17:42 |
| david8hu | samueldmq, Not corrupted at all;) | 17:43 |
| samueldmq | :-) | 17:45 |
| *** csoukup has quit IRC | 17:51 | |
| *** roxanaghe has joined #openstack-keystone | 17:51 | |
| stevemar | keystoners, reminder to populate the wiki with meeting topics: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting | 17:55 |
| samueldmq | stevemar, done ! : ) | 17:55 |
| stevemar | samueldmq, ty! | 17:55 |
| samueldmq | ayoung, just put a topic to let people know how things on dynamic policies are | 17:56 |
| marekd | stevemar: i just removed one topic. | 17:56 |
| stevemar | marekd, the idp deletion one? | 17:56 |
| marekd | stevemar: nope, i had one k2k in kmw, but i've dicussed it with jamie this morning. | 17:59 |
| stevemar | marekd, cool, if theres time we can chat about it | 17:59 |
| *** marzif_ has joined #openstack-keystone | 18:00 | |
| *** csoukup has joined #openstack-keystone | 18:01 | |
| *** marzif has quit IRC | 18:01 | |
| *** henrynash has joined #openstack-keystone | 18:02 | |
| *** ChanServ sets mode: +v henrynash | 18:02 | |
| *** henrynash_ has joined #openstack-keystone | 18:04 | |
| *** ChanServ sets mode: +v henrynash_ | 18:04 | |
| *** henrynash has quit IRC | 18:06 | |
| *** henrynash_ is now known as henrynash | 18:06 | |
| *** jasondotstar has joined #openstack-keystone | 18:07 | |
| *** Ctina_ has joined #openstack-keystone | 18:10 | |
| *** Ctina has quit IRC | 18:13 | |
| *** htruta_ has quit IRC | 18:25 | |
| *** esp has left #openstack-keystone | 18:29 | |
| *** lhcheng has quit IRC | 18:32 | |
| *** lhcheng has joined #openstack-keystone | 18:32 | |
| *** ChanServ sets mode: +v lhcheng | 18:32 | |
| *** blewis` has quit IRC | 18:33 | |
| *** lhcheng_ has joined #openstack-keystone | 18:34 | |
| *** gokrokve has joined #openstack-keystone | 18:34 | |
| *** marzif has joined #openstack-keystone | 18:36 | |
| *** lhcheng has quit IRC | 18:38 | |
| *** e0ne has joined #openstack-keystone | 18:47 | |
| *** lhcheng_ is now known as lhcheng | 18:52 | |
| *** ChanServ sets mode: +v lhcheng | 18:52 | |
| *** pauloewerton has joined #openstack-keystone | 18:53 | |
| *** tqtran is now known as tqtran_afk | 19:01 | |
| gyee | stevemar, nice job running the show! | 19:01 |
| stevemar | gyee, danke | 19:01 |
| ayoung | gyee, so, on endpoint binding, the endpoint does not know its own ID | 19:01 |
| *** tqtran_afk is now known as tqtran | 19:01 | |
| ayoung | what we were saying for policy is that we are going to enforce by endpoint URL | 19:01 |
| gyee | ayoung, you can :) | 19:01 |
| ayoung | is that what you have coded? | 19:01 |
| *** gokrokve has quit IRC | 19:01 | |
| gyee | token.catalog.endpoints.url:myhost.com | 19:02 |
| gyee | ayoung, its all determine by policy | 19:02 |
| *** gokrokve has joined #openstack-keystone | 19:02 | |
| ayoung | gyee, hmmm | 19:02 |
| gyee | ayoung, btw, your changes to oslo policy made it possible :) | 19:02 |
| ayoung | gyee, so there is something missing | 19:02 |
| ayoung | if we do dynamic poolicy, there will be no way of saying "this is what My hostname is" | 19:03 |
| ayoung | or something like that | 19:03 |
| ayoung | unless we rewrite rules upon fetch from Keystone...yuck | 19:03 |
| gyee | ayoung, %(host)s | 19:04 |
| ayoung | better to have something that pulls the URL out of the config file, yeah, like that | 19:04 |
| *** zzzeek has quit IRC | 19:04 | |
| gyee | right, its a few lines of chef/ansible/puppet/whatever | 19:04 |
| *** amakarov is now known as amakarov_away | 19:04 | |
| gyee | deployment-wise | 19:04 |
| ayoung | gyee, 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 policy | 19:05 |
| ayoung | so instead of {"global": "token.catalog.endpoints.id:%(endpoint_id)s"} | 19:05 |
| ayoung | is should be | 19:05 |
| *** zzzeek has joined #openstack-keystone | 19:05 | |
| ayoung | {"global": "token.catalog.endpoints.url:%(endpoint_url)s"} | 19:05 |
| gyee | ayoung, where do we get the params? | 19:06 |
| gyee | CONF? | 19:06 |
| ayoung | gyee, yes | 19:06 |
| ayoung | [auth_token] section | 19:06 |
| gyee | ayoung, yes, endpoint_id is already there | 19:06 |
| ayoung | CONF.auth_token.endpoint_url? samueldmq ? morganfainberg that works, right? | 19:06 |
| ayoung | gyee, not ID | 19:06 |
| gyee | why not? | 19:07 |
| ayoung | gyee, ID is assigned by keystone. Puppet will only know hostname | 19:07 |
| *** gokrokve has quit IRC | 19:07 | |
| ayoung | so it could precalculate the URL, but not the ID | 19:07 |
| gyee | ayoung, it could be a two step configuration | 19:07 |
| morganfainberg | ayoung: yes | 19:07 |
| ayoung | gyee, 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 config | 19:07 |
| morganfainberg | do not use a uuid, use a url | 19:07 |
| morganfainberg | please. | 19:07 |
| ayoung | gyee, ^^ | 19:07 |
| ayoung | we've already decvdied we are doing this for fetch of the policy | 19:08 |
| gyee | so you want both endpoint_id and endpoint_url or just endpoint_url? | 19:08 |
| morganfainberg | and it can even be a template if you need to handle project/domain replacement | 19:08 |
| *** Ephur has joined #openstack-keystone | 19:08 | |
| ayoung | gyee, just URL | 19:08 |
| morganfainberg | just the url that the endpoint knows it's own id. you need to know the url a priori anyway | 19:08 |
| gyee | ayoung, morganfainberg, how about I pass in whatever from the auth_token section? | 19:09 |
| *** neelabh has quit IRC | 19:09 | |
| morganfainberg | gyee: i have no idea what you're proposing | 19:09 |
| morganfainberg | there | 19:09 |
| ayoung | gyee, so long as the CONF is in the policy enforcement dictionary, I think we can support it | 19:09 |
| ayoung | so it would look like | 19:09 |
| gyee | morganfainberg, for policy enforcement | 19:09 |
| morganfainberg | but long and the short is the URL should be the id that is used for endpoint enforcement, etc | 19:09 |
| ayoung | {"global": "token.catalog.endpoints.url:%(CONF.auth_token.endpoint_url)s"} | 19:09 |
| gyee | enforce(global, CONF, cred) | 19:10 |
| morganfainberg | since a uuid becomes a 2+step setup and requires restarting after injecting things into keystone | 19:10 |
| morganfainberg | thats all. | 19:10 |
| morganfainberg | ayoung: you've got what i'm looking for. | 19:10 |
| gyee | k, easy change then | 19:10 |
| morganfainberg | thanks. | 19:10 |
| * morganfainberg ducks out again. | 19:10 | |
| gyee | so to summarize, support CONF.auth_token.endpoint_url | 19:11 |
| gyee | and keep the functionality in auth_token, no separate middleware | 19:11 |
| gyee | I'll have a patch ready after lunch | 19:11 |
| ayoung | gyee, do we need the check if not auth_ref.has_service_catalog(): | 19:11 |
| ayoung | or will the policy fail anyway? | 19:11 |
| gyee | ayoung, yes, there's a check there already | 19:11 |
| ayoung | morganfainberg, Ok, so here is my new thinking | 19:12 |
| ayoung | we get gyee ' | 19:12 |
| ayoung | s patch in | 19:12 |
| ayoung | then we use that as the start point for the next step of DYn Policy | 19:12 |
| gyee | ayoung, yeah, we can build the policy fetch on top of it | 19:13 |
| ayoung | we split the policy files into a static portion and a dynamic portion, and enforce the dynamic here, based on API, | 19:13 |
| ayoung | scope check stays where it is now, in the code embedded in the projects | 19:13 |
| ayoung | we keep the role check completely separate from the scope check. THis part would just do checks likeL | 19:13 |
| ayoung | like: | 19:13 |
| ayoung | "GET /v3/users/" : "role:member" | 19:14 |
| gyee | how do we split policy files? | 19:15 |
| ayoung | gyee, chainsaw! | 19:16 |
| gyee | hah | 19:16 |
| gyee | its one giant JSON right now | 19:16 |
| ayoung | gyee, seriously, though, we just remove the role check from the ones from the projects, and add in explicit scope checking | 19:16 |
| *** Rockyg has joined #openstack-keystone | 19:16 | |
| gyee | lemme think it over at lunch | 19:16 |
| ayoung | gyee, please do, | 19:16 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/190405 | 19:16 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/192375 | 19:16 |
| gyee | k, gotta run | 19:17 |
| ayoung | gyee, the idea is that matchins "where is the scope on this request" is not something we want end users to change | 19:17 |
| samueldmq | ayoung, gyee so we agreed on using the CONF.auth_token.endpoint_url for token endpoint binding ? | 19:18 |
| *** pnavarro has joined #openstack-keystone | 19:18 | |
| ayoung | samueldmq, I think we agreed to that. | 19:19 |
| samueldmq | ++++++++ | 19:19 |
| *** sbezverk has quit IRC | 19:19 | |
| samueldmq | ayoung, the issue with endpoint_url for fetchign the policy is that an URL can map to multiple endpoint ids, and consequently to multiple policies | 19:19 |
| samueldmq | ayoung, morganfainberg said me to rethink the policy CRUD as it didn't exist | 19:20 |
| samueldmq | ayoung, in sumary, we need to provide an explicity way to assign policy to URL | 19:20 |
| samueldmq | ayoung, Story 1 in https://wiki.openstack.org/wiki/DynamicPolicies#Dynamic_Policies | 19:20 |
| samueldmq | :0 | 19:20 |
| samueldmq | :) | 19:20 |
| ayoung | samueldmq, is that true> | 19:21 |
| *** mtecer has joined #openstack-keystone | 19:21 | |
| ayoung | I thought that an endpoint URL had to be unique | 19:21 |
| samueldmq | ayoung, it isn't :/ | 19:21 |
| samueldmq | ayoung, in devstac, glance has 3 enpoints with the same :9292 url | 19:21 |
| samueldmq | ayoung, differing on admin, public and internal interfaces | 19:22 |
| samueldmq | :/ | 19:22 |
| ayoung | samueldmq, I got ERROR: openstack More than one endpoint exists with the name 'http://10.10.10.40:5000/v2.0' | 19:22 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/192386 | 19:23 |
| samueldmq | ayoung, exactly ... but in this openstack client specifically, it is a bug (it should show the list) | 19:23 |
| samueldmq | ayoung, jamielennox was talking about this error earlier today ^ | 19:23 |
| ayoung | samueldmq, the thing is, we really don't care... | 19:23 |
| ayoung | the server is going to use the same policy file | 19:24 |
| samueldmq | ayoung, we allow people to define policy per endpoint id | 19:24 |
| ayoung | so, the fact that the endpoint has multiple IDs is irrelevant | 19:24 |
| samueldmq | ayoung, what do I do if I get multiple policies from /policies?endpoint_url=<encoded_url> | 19:24 |
| ayoung | samueldmq, let's propose a constraint in Keystone: if two endpoint IDs have the same URL they have the same policy association | 19:24 |
| samueldmq | ayoung, we need to fix that, we need an explicit way to associate a policy with an URL | 19:25 |
| samueldmq | ayoung, that might work, but how to migrate ? | 19:25 |
| ayoung | make it implicit, based on the existing API, and a new API to set it by URL, too | 19:25 |
| ayoung | samueldmq, I'll write up that spec | 19:25 |
| *** harlowja has quit IRC | 19:25 | |
| samueldmq | ayoung, ok but we need to sync up with morganfainberg on that point | 19:25 |
| samueldmq | ayoung, a spec should be good | 19:25 |
| ayoung | samueldmq, I will | 19:26 |
| ayoung | having the spec just gives us a place to record comments | 19:26 |
| samueldmq | ++ | 19:26 |
| samueldmq | ayoung, I will update that dynamic policy wiki with our ealier conversation | 19:26 |
| samueldmq | ayoung, and I will put a workflow on how things would work in general, as I was talking to you earlier | 19:26 |
| samueldmq | ayoung, if you agree on that, it would be amazing, since it fits nova requirements as well | 19:27 |
| morganfainberg | ayoung: why do we care about the uuid? | 19:28 |
| morganfainberg | really? | 19:28 |
| morganfainberg | it's useless as an identifier for the API in this case for the endpoint | 19:28 |
| ayoung | morganfainberg, only because that is how the existing API works | 19:28 |
| morganfainberg | so lose the current api | 19:28 |
| morganfainberg | no one is using it | 19:28 |
| morganfainberg | it is terrible. | 19:28 |
| morganfainberg | cargocult programming/APIs is a bad idea. | 19:29 |
| ayoung | morganfainberg, 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 ID | 19:29 |
| morganfainberg | i am against using the current API at all. fwiw | 19:29 |
| ayoung | the big thing is fetch by URL | 19:29 |
| morganfainberg | i don't want to wedge extra stuff on top of a poorly designed API here that no one uses. | 19:29 |
| ayoung | morganfainberg, agreed. We'll add 2 API calls | 19:29 |
| samueldmq | I think providing a way to associate by URL + fetch by URL would be great | 19:30 |
| ayoung | 1. Associate policy with endpoint_url | 19:30 |
| ayoung | 2. Fetch policy by endpoint URL | 19:30 |
| samueldmq | ayoung, ++++ | 19:30 |
| morganfainberg | you know what.. i don't care fine do that. | 19:30 |
| ayoung | in addition, we'll change the existing code to associate with the endpoint_url if it comes in via ID | 19:30 |
| morganfainberg | you're makin the UX beyond awful here. | 19:30 |
| ayoung | and we'll deprecate at the same time | 19:30 |
| morganfainberg | just direclty use the url | 19:30 |
| morganfainberg | don't bother with the current api at all | 19:30 |
| * morganfainberg doesn't see a need to layer things on something no one uses because it's unusable | 19:31 | |
| ayoung | morganfainberg, what do you mean by "just direclty use the url" | 19:31 |
| samueldmq | any endpoint containing that url, will map to the policy associated to that url | 19:31 |
| morganfainberg | the id is the url. | 19:31 |
| morganfainberg | no API with UUIDs | 19:31 |
| morganfainberg | or b64 url | 19:31 |
| ayoung | morganfainberg, please don't tease me | 19:31 |
| ayoung | I hate UUIDs as much as youi | 19:31 |
| ayoung | probably more | 19:31 |
| morganfainberg | ayoung: i'm serious, throw away the current API as useless. no one can use it. | 19:32 |
| samueldmq | hehe | 19:32 |
| * morganfainberg is needing food soon, so will not continue this. | 19:32 | |
| samueldmq | /policies/<policy_id>/endpoints/<encoded_url> ? | 19:32 |
| morganfainberg | if you need to keep the current API, fine. | 19:32 |
| ayoung | morganfainberg, I'm not the one that decided the rules here | 19:32 |
| morganfainberg | so i have no ide awhat policy_id is meant to represent | 19:32 |
| morganfainberg | ayoung: assume /policy is dead, use /rbac_policy :P | 19:33 |
| samueldmq | morganfainberg, you create a policy, then you associate it with an URL | 19:33 |
| ayoung | morganfainberg, um...different API | 19:33 |
| samueldmq | morganfainberg, or should endpoint_url be a prperty of policy ? | 19:33 |
| ayoung | morganfainberg, one sec.... | 19:33 |
| morganfainberg | ayoung: yep. just make a new API, assume policy was poorly thought out subsystem | 19:33 |
| morganfainberg | and should go away | 19:33 |
| morganfainberg | anyway | 19:33 |
| ayoung | morganfainberg, we are talking http://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3/identity-api-v3-os-endpoint-policy.rst | 19:33 |
| * morganfainberg should really be not on IRC. | 19:34 | |
| *** mtecer has quit IRC | 19:34 | |
| ayoung | we want most of that anyway | 19:34 |
| samueldmq | morganfainberg, go, enjoy o/ | 19:34 |
| ayoung | the only part that really needs to change is the fetch | 19:34 |
| * samueldmq is going afk for a bit ... he needs some food | 19:34 | |
| ayoung | http://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 URL | 19:34 |
| *** RichardRaseley has joined #openstack-keystone | 19:38 | |
| openstackgerrit | Doug Hellmann proposed openstack/keystone: Update version for Liberty https://review.openstack.org/192405 | 19:51 |
| *** csoukup has quit IRC | 20:00 | |
| openstackgerrit | ayoung proposed openstack/keystone-specs: Policy by URL https://review.openstack.org/192422 | 20:02 |
| *** kfox1111 has quit IRC | 20:03 | |
| ayoung | samueldmq, ^^ | 20:06 |
| *** gokrokve has joined #openstack-keystone | 20:08 | |
| *** henrynash has quit IRC | 20:09 | |
| *** Ctina_ has quit IRC | 20:15 | |
| samueldmq | ayoung, great, will add to the wiki | 20:22 |
| richm | stevemar: sorry, back now | 20:42 |
| stevemar | richm, that was a long lunch | 20:42 |
| richm | indeed | 20:42 |
| stevemar | richm, was gonna ask about your ML post | 20:42 |
| richm | ok | 20:42 |
| stevemar | richm, oh, just if you could give me more info on what's going on | 20:50 |
| stevemar | lol | 20:50 |
| *** tqtran is now known as tqtran_afk | 20:51 | |
| *** e0ne has quit IRC | 20:53 | |
| samueldmq | ayoung, morganfainberg dynamic policy workflow: http://paste.openstack.org/show/296334/ | 20:56 |
| samueldmq | this fits what we need + nova requirements | 20:56 |
| samueldmq | ayoung, let me know what you think about this | 20:56 |
| samueldmq | ayoung, I want your opinion before putting that on the wiki | 20:57 |
| richm | stevemar: 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 directly | 20:57 |
| ayoung | I have not looked at it yet and already know I like it | 20:57 |
| ayoung | samueldmq, step 3 is unnecssary | 20:57 |
| ayoung | default will be associated by....default. But I like that you called that out...maybe move it to the front of the flow | 20:58 |
| richm | stevemar: All I know is that with v2.0, openstack user create --project $project adds the new user to $project, and with v3, it doesn't | 20:58 |
| samueldmq | ayoung, step 3 is what allow us to cover nova case | 20:58 |
| richm | stevemar: If that is by design, ok, I'll work around it in puppet | 20:58 |
| samueldmq | ayoung, I was planning to have two "policies" by endpoint, the default uploaded by the CMS at bootstraping | 20:58 |
| ayoung | samueldmq, start with "CMS uploads default policy to Keystone" | 20:58 |
| samueldmq | ayoung, + the custom, defined by the user, who may get warnings when going away from the default | 20:59 |
| samueldmq | ayoung, that's for comparison | 20:59 |
| ayoung | then upload a second and associate it explicitly with the endpoint | 20:59 |
| ayoung | you are on the right track, though | 20:59 |
| ayoung | samueldmq, how'd you generate that diagram> | 20:59 |
| ayoung | ? | 20:59 |
| samueldmq | ayoung, so default policy is per service, njot per endpoint ? | 20:59 |
| samueldmq | ayoung, by hand ... 5 hours to do so | 21:00 |
| ayoung | samueldmq, default policy is for everything | 21:00 |
| samueldmq | ayoung, kidding ... http://asciiflow.com/ | 21:00 |
| ayoung | samueldmq, heh | 21:00 |
| ayoung | samueldmq, so...there is a better tool, let me find the link | 21:00 |
| samueldmq | ayoung, and when we do away from the defaults, we get the warnings nova people want | 21:00 |
| samueldmq | ayoung, so you agree with the direction I am following there .. | 21:01 |
| ayoung | samueldmq, http://interactive.blockdiag.com/seqdiag/ | 21:01 |
| samueldmq | ayoung, the single point of divergence between that representation and what you want is whether define the unified policy or not | 21:01 |
| ayoung | samueldmq, yes, very much so. | 21:01 |
| ayoung | samueldmq, 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 code | 21:02 |
| ayoung | unified is, I think, the right point, we just need to handle the microversions | 21:02 |
| ayoung | but, I think unified policy becomes much easier if we drop the scope portion and just do roles | 21:03 |
| samueldmq | ayoung, what if we do that without unified for now, should we fail ? | 21:03 |
| samueldmq | ayoung, I mean, as I described in that diagram | 21:03 |
| samueldmq | ayoung, I think that is a very good scope for L | 21:03 |
| samueldmq | ayoung, role hierarchies, per domain, unified, etc could come later | 21:04 |
| samueldmq | ayoung, that way we can bring the dynamic fetchign this cycle | 21:04 |
| *** pnavarro has quit IRC | 21:05 | |
| ayoung | samueldmq, without unified poliyc, at a minimum we ened to have one policy file defined per service. | 21:05 |
| ayoung | We can start with that | 21:06 |
| samueldmq | ayoung, one policy file per service is like what we have today | 21:06 |
| samueldmq | ayoung, I think that scope is very good for L | 21:06 |
| samueldmq | ayoung, and we can have better ideas/improve the existing ones as we go with this required base | 21:07 |
| samueldmq | ayoung, for the dynamic policy stuff | 21:07 |
| samueldmq | ayoung, <ayoung> We can start with that | 21:09 |
| samueldmq | ayoung, I am understanding you then agreed with that diagram :D | 21:09 |
| samueldmq | ayoung, I will talk to sdague and see what he thinks, since that fits nova requirements | 21:09 |
| samueldmq | ayoung, if we agree on that, or somehting based on that, we're good for L | 21:10 |
| samueldmq | ftw | 21:10 |
| *** csoukup has joined #openstack-keystone | 21:10 | |
| ayoung | Ok 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 up | 21:11 |
| ayoung | I think we are OK, though | 21:11 |
| samueldmq | ayoung, :) | 21:12 |
| * samueldmq is happy know | 21:12 | |
| openstackgerrit | ayoung proposed openstack/keystone-specs: Policy by URL https://review.openstack.org/192422 | 21:13 |
| *** harlowja has joined #openstack-keystone | 21:13 | |
| *** marzif has quit IRC | 21:13 | |
| *** tqtran_afk is now known as tqtran | 21:16 | |
| ayoung | samueldmq, http://interactive.blockdiag.com/seqdiag/image?compression=deflate&encoding=base64&src=eJzNUc1OwzAMvvcprN7XPkApHGDiMAYSPyc0IdO4xSJLSpKuqhDvTtIU1ILGGV8cJ9-P7Vh6E4wNvCcA59u7wicUe1bh0FkyIV_rAxYQwhcbGqzTiorEF3kOlvetJFDaoWOtogxAefqNhEeJzyShhLRrpUYBgmrspINWS66GdFdMLE8KXjPCBdXsFcbbtRKtZuXg4fYK0MGWhZDUoyGotKq5AVRB23sM4Fs_cEXp7u-GDDVsHZmlQ-wojA-rRUtlerm-h7wzMkK-YoT8dpjgccwzmtSfPL3MsmzmcrJautxs4uP4FUH49afwtElF_WKLxwlora4YHc040LN7 | 21:20 |
| ayoung | ic70v0ZPPj4BLAbRDw | 21:20 |
| ayoung | samueldmq, actually | 21:21 |
| ayoung | http://interactive.blockdiag.com/seqdiag/image?compression=deflate&encoding=base64&src=eJzNUUtPwzAMvvdXWL2v_QFd4QATh7Eh8TihCZnGLZaypCTpqgrx30maglrxOOOL4-R72I6lV8HYwFsCcLG7K3xCcWQVDp0lE_Jen7CAEL7Y0mCdVlQkvshzsHxsJYHSDh1rFWUAyrMvJDxKfCYJJaRdKzUKEFRjJx20WnI1pIdiYnlS8JoRLqlmrzDebpRoNSsHD7fXgA52LISkHg1BpVXNDaAK2t5jAN_6iStKD383ZKhh68gsHWJHYXxYLVoq06vNPeSdkRHyGSPku8MEj2Oe06T-5OlllmUzl_Vq6XKzjY_jV_woPG1SUb_Y4u8EtFZXjI5mHOjZvURn-l-jJ-8f9Zf | 21:21 |
| ayoung | Qzw | 21:21 |
| ayoung | gah | 21:21 |
| ayoung | samueldmq, http://tinyurl.com/oxwnmdc | 21:22 |
| *** Daviey has quit IRC | 21:30 | |
| *** gokrokve has quit IRC | 21:32 | |
| *** pballand has joined #openstack-keystone | 21:39 | |
| *** doug-fish has joined #openstack-keystone | 21:44 | |
| stevemar | richm, how are testing if the user has been added to the project? | 21:47 |
| stevemar | richm, also, to be pedantic, users are not "added" to a project, they must be assigned a role on a project | 21:47 |
| richm | stevemar: openstack user list --project $project and openstack project list --user $user | 21:49 |
| richm | one of those doesn't work with v2.0 | 21:49 |
| *** edmondsw has quit IRC | 21:52 | |
| *** pballand has quit IRC | 21:52 | |
| *** doug-fish has left #openstack-keystone | 21:55 | |
| stevemar | richm, what about if you add a role to the user on the project | 21:56 |
| stevemar | richm, $ openstack role add member --user $user --project $project | 21:56 |
| *** harlowja has quit IRC | 22:00 | |
| *** harlowja has joined #openstack-keystone | 22:02 | |
| richm | stevemar: yes, that works - then the user shows up as a member of the project | 22:11 |
| richm | stevemar: That's the workaround I'll use in puppet | 22:11 |
| *** mtecer has joined #openstack-keystone | 22:11 | |
| stevemar | richm, that's the way v3 is intended to work | 22:12 |
| richm | stevemar: ok - thanks | 22:12 |
| *** bknudson has quit IRC | 22:13 | |
| *** dguerri is now known as dguerri` | 22:22 | |
| *** pballand has joined #openstack-keystone | 22:25 | |
| *** pballand has quit IRC | 22:35 | |
| *** dguerri` is now known as dguerri | 22:36 | |
| *** ayoung has quit IRC | 22:37 | |
| *** openstackgerrit has quit IRC | 22:38 | |
| *** dguerri is now known as dguerri` | 22:39 | |
| *** openstackgerrit has joined #openstack-keystone | 22:39 | |
| *** dguerri` is now known as dguerri | 22:48 | |
| *** csoukup has quit IRC | 22:51 | |
| *** dguerri is now known as dguerri` | 23:00 | |
| *** obedmr has quit IRC | 23:03 | |
| *** lhcheng has quit IRC | 23:04 | |
| *** lhcheng has joined #openstack-keystone | 23:07 | |
| *** ChanServ sets mode: +v lhcheng | 23:07 | |
| *** chlong has quit IRC | 23:15 | |
| *** Rockyg has quit IRC | 23:26 | |
| *** browne has quit IRC | 23:27 | |
| *** tqtran has quit IRC | 23:27 | |
| *** roxanaghe has quit IRC | 23:27 | |
| *** tqtran has joined #openstack-keystone | 23:28 | |
| *** browne has joined #openstack-keystone | 23:28 | |
| *** kfox1111 has joined #openstack-keystone | 23:31 | |
| *** jaosorior has quit IRC | 23:35 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 23:42 | |
| *** stevemar has quit IRC | 23:44 | |
| *** stevemar has joined #openstack-keystone | 23:44 | |
| *** ChanServ sets mode: +v stevemar | 23:44 | |
| *** zzzeek has quit IRC | 23:48 | |
| *** Kennan2 is now known as Kennan | 23:51 | |
| jamielennox | stevemar: wow, fixed, released, done | 23:52 |
| jamielennox | that 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!