)]}'
{"id":"openstack%2Fkeystone~687990","triplet_id":"openstack%2Fkeystone~master~I2ac6e90f24b94dc5c0d9c0758f008a388597036c","project":"openstack/keystone","branch":"master","topic":"bug/1848342","hashtags":[],"change_id":"I2ac6e90f24b94dc5c0d9c0758f008a388597036c","subject":"Stop adding entry in local_user while updating ephemerals","status":"MERGED","created":"2019-10-10 21:54:07.000000000","updated":"2020-07-15 13:49:26.000000000","submitted":"2020-04-20 20:34:42.000000000","submitter":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"total_comment_count":13,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"687990-1587414882976-602cea05","meta_rev_id":"e6f006af8b2c6e63405edf5fb52e5f3203e7e627","_number":687990,"virtual_id_number":687990,"owner":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"value":0,"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},{"value":0,"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},{"value":0,"_account_id":27621,"name":"Vishakha Agarwal","email":"agarwalvishakha18@gmail.com","username":"Vishakha"},{"value":0,"date":"2019-12-11 20:48:18.000000000","_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},{"tag":"autogenerated:zuul:gate","value":2,"date":"2020-04-20 20:34:42.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","default_value":0,"optional":true},"Code-Review":{"approved":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"all":[{"value":2,"date":"2019-12-11 23:06:37.000000000","_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},{"value":0,"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},{"value":0,"_account_id":27621,"name":"Vishakha Agarwal","email":"agarwalvishakha18@gmail.com","username":"Vishakha"},{"value":0,"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":2,"date":"2019-12-17 08:53:41.000000000","_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","default_value":0,"optional":true},"Workflow":{"approved":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"all":[{"value":1,"date":"2020-04-20 18:54:49.000000000","_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},{"value":0,"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},{"value":0,"_account_id":27621,"name":"Vishakha Agarwal","email":"agarwalvishakha18@gmail.com","username":"Vishakha"},{"value":0,"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},{"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":27621,"name":"Vishakha Agarwal","email":"agarwalvishakha18@gmail.com","username":"Vishakha"},{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2019-10-11 07:03:37.000000000","updated_by":{"_account_id":27621,"name":"Vishakha Agarwal","email":"agarwalvishakha18@gmail.com","username":"Vishakha"},"reviewer":{"_account_id":27621,"name":"Vishakha Agarwal","email":"agarwalvishakha18@gmail.com","username":"Vishakha"},"state":"REVIEWER"},{"updated":"2019-12-04 19:41:57.000000000","updated_by":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"reviewer":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"state":"REVIEWER"},{"updated":"2019-12-17 08:53:41.000000000","updated_by":{"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"},"reviewer":{"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"},"state":"REVIEWER"},{"updated":"2020-04-20 18:54:49.000000000","updated_by":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"reviewer":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"state":"REVIEWER"},{"updated":"2020-04-20 20:34:42.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"}],"messages":[{"id":"f996a3196e0296eb6b38bac1d73f839b9d00e475","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-10 21:54:07.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"c6bce98537bc2d9e41feb60d62753e8ff465dd93","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-10-10 22:53:05.000000000","message":"Patch Set 1: Code-Review+1\n\nIt looks like a reasonable change. Currently, this is kind of a bug, when we use the update command in OpenStack CLI, federated users are written to the local_users table.","accounts_in_message":[],"_revision_number":1},{"id":"cab018f1cf8190611b53f88d620ea9ae3440a668","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-10 23:31:29.000000000","message":"Patch Set 1: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/2ea61a2cd6c3459baa061ae293e8c1d1 : SUCCESS in 13m 38s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/05bc15df78634d94b34eaad714b85314 : SUCCESS in 20m 46s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/9894b517234d444e88f23decdf6a0cc2 : FAILURE in 5m 02s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/96a21383ff3a4d6faa9a8b95494ac04e : SUCCESS in 20m 32s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/2f79b0879a4d45c681cb46caa1f93ce5 : SUCCESS in 11m 44s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/afead138327741e5ad811e8026c6d268 : SUCCESS in 19m 42s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/7048aafb731d421ca8320149eab2d8cb : SUCCESS in 14m 15s\n- tempest-full https://zuul.opendev.org/t/openstack/build/1c813505812e44bdbc66c29f7a888ce4 : SUCCESS in 1h 35m 25s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/fb8f86d7be71477383da0eaf211153cc : SUCCESS in 58m 08s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/24d7e1cd2dd243ad871fb2d7c2bcdf8d : SUCCESS in 56m 48s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/dfb6708adcf846e8a738495208cee643 : SUCCESS in 1h 22m 33s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/4cd9092b71b345c994314952a5bcc884 : SUCCESS in 30m 52s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/75e4660ce8cf40e7b237fa2d4b659f52 : SUCCESS in 40m 57s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/5cbfe0a5c2d742d7a2422e1972b9c278 : SUCCESS in 34m 31s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/9442a8f364e04027a18a0963f504c9ac : SUCCESS in 38m 28s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/46cbd2067bae4d6fb1775923a0d29bda : SUCCESS in 14m 28s (non-voting)\n- legacy-tempest-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/537a071bafc94b209e462d0dab1c4e7f : SUCCESS in 1h 25m 20s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/0e8f16e369f94f4dab5b9b02dbee1564 : SUCCESS in 1h 01m 49s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/8d394c9cd19241dda3ae6b72a5639e74 : SUCCESS in 43m 07s","accounts_in_message":[],"_revision_number":1},{"id":"5df2bbb52dbd0811f1911499a4cb59be79f5643f","author":{"_account_id":27621,"name":"Vishakha Agarwal","email":"agarwalvishakha18@gmail.com","username":"Vishakha"},"date":"2019-10-11 07:03:37.000000000","message":"Patch Set 1: Code-Review-1\n\nHi Pedro. In k2k federation, when the federated user tries to access the SP keystone a shadow user is being created in the local user table so that the federated user can be given some access over the SP keystone. You can read more about the shadow user [1]\n\n[1] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/shadow-users.html;\n\nAFAIK this error isn\u0027t coming due to the entry in local user. Please register a bug with all the logs and tables so that we can look for the problem.","accounts_in_message":[],"_revision_number":1},{"id":"2cbb0fbee0cf9bf797a11b723a03c8fcbcf964ff","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-11 12:08:37.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"5c3a77f34a3c81844d792e4cb1d39c93a99db033","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-11 13:56:20.000000000","message":"Patch Set 2: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/fd70c34e70cc4a348f5f89816feaa81e : SUCCESS in 47m 54s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/94e8b86b833043708bd97078ccf2af05 : SUCCESS in 32m 24s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/7e9a88ada2164210948c979c51b5e748 : SUCCESS in 6m 04s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/ea132d918df4476dbbb16ae025608e24 : SUCCESS in 17m 18s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/18c11cf3131f44a2a14ecf75be9568c6 : TIMED_OUT in 41m 06s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/2bb3b33d22e543a8ba454df42ec3369b : SUCCESS in 12m 09s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/58ee8871069943b794f7d94c1b93634e : SUCCESS in 12m 03s\n- tempest-full https://zuul.opendev.org/t/openstack/build/ab501f313b4d4076afea92ef6edb7a47 : SUCCESS in 1h 45m 49s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/a9160af88735489e84fc595ddd47e836 : SUCCESS in 1h 12m 32s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/f8fe5a0b164147fc8d96ba667fee2d0f : SUCCESS in 1h 02m 19s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/146282cf6e6d4644aa36c6e00468c995 : SUCCESS in 1h 17m 11s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/8362e35b1f344adfb8b286e699f3adb4 : SUCCESS in 34m 58s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/b24402e5ca49478489e520e8221da488 : SUCCESS in 27m 24s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/be08304a810e4c468e72e5c81fc415ed : SUCCESS in 42m 18s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/6c8bd6d0aabc4f7ca34890116609be88 : SUCCESS in 39m 43s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/8a2e877910e94f8a8b9ab0b668c534aa : SUCCESS in 13m 04s (non-voting)\n- legacy-tempest-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/a152201d93944186b3c262cdd54282db : SUCCESS in 1h 43m 20s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/17255940946749d5b6e065902825e125 : SUCCESS in 1h 05m 28s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/e1f02864bcb540eb83745697ba0746c8 : SUCCESS in 34m 38s","accounts_in_message":[],"_revision_number":2},{"id":"9dd8649e186b511b1469222c1485502f248ff96e","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-11 14:18:14.000000000","message":"Patch Set 2:\n\nrecheck","accounts_in_message":[],"_revision_number":2},{"id":"71fbf0013a6ab52fff606906cce2beb62c948095","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-11 16:10:38.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/bef8ee78644245f2a3dd7a9a252b754f : SUCCESS in 29m 29s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/e663ee545c09471687dc94a0432fd641 : SUCCESS in 16m 09s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/cc86916d8d244172bd749bad978226ca : SUCCESS in 5m 56s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/db17f4acea7848e4844f97282d99267e : SUCCESS in 13m 32s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/38ce6b65f20f453487df6f554460127c : SUCCESS in 12m 38s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/1ef5f913dc804d4b9c6e155e9db0186d : SUCCESS in 15m 33s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/1e73ab27e3d54d07b4f1d6d19df499cf : SUCCESS in 11m 06s\n- tempest-full https://zuul.opendev.org/t/openstack/build/05f3d7cec686489297d5e70fe74315d3 : SUCCESS in 1h 36m 43s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/89313670c0dc4fc1ade73897af1f3a91 : SUCCESS in 1h 01m 26s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/c062f42fac3c49088dcdfc5e014cb1eb : SUCCESS in 1h 00m 15s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/ae5fe29027b84ef795a2b77927436189 : SUCCESS in 1h 38m 18s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/20963a5435e04253b55cdf2fce17c166 : SUCCESS in 34m 08s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/5d836d7e5aac4c32a261e995e1e10bdf : SUCCESS in 39m 05s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/bb3dad4d0e9944df839617eda6dfb1ea : SUCCESS in 36m 16s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/fc45de5d95cd4ae9a50657744c49a4cf : SUCCESS in 44m 14s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/62adf2c670c74db4aa0aa8b74757c9e0 : SUCCESS in 18m 18s (non-voting)\n- legacy-tempest-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/e2db9fed4085403c94564d13933d76ff : SUCCESS in 1h 36m 27s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/3386fd7278774adcabaf136f035724dc : SUCCESS in 1h 16m 31s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/da7cfef996c441648482902dc3f5e21e : SUCCESS in 41m 15s","accounts_in_message":[],"_revision_number":2},{"id":"684cdccf36f2e30d317facc55b5ef911282bd6b2","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-11 19:29:03.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"eee9157d20deac8a7ee0e1676bf8d3da207f99df","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-11 19:34:37.000000000","message":"Patch Set 3:\n\n\u003e Hi Pedro. In k2k federation, when the federated user tries to\n \u003e access the SP keystone a shadow user is being created in the local\n \u003e user table so that the federated user can be given some access over\n \u003e the SP keystone. You can read more about the shadow user [1]\n \u003e \n \u003e [1] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/shadow-users.html;\n \u003e \n \u003e AFAIK this error isn\u0027t coming due to the entry in local user.\n \u003e Please register a bug with all the logs and tables so that we can\n \u003e look for the problem.\n\nHi Vishakha, I agree with your concerns and changed the proposal, can you take another look?","accounts_in_message":[],"_revision_number":3},{"id":"45e5b12e8227f53a459b8c15646adb0df208c9cd","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-11 23:00:37.000000000","message":"Patch Set 3: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/73baeafa5b954aefa1542c4f85e4db44 : SUCCESS in 19m 56s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/1f46289de02543b3b73ddab0694dad57 : SUCCESS in 16m 34s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/f8184720a05b4f65a0bc1a31f129d134 : SUCCESS in 7m 07s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/bbd0f5ab03cf4042ba0757c1e240dbf4 : FAILURE in 17m 32s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/84b9ead05bc14bc3aac294b704cc7777 : SUCCESS in 15m 41s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/127c9930f4cc4c8db61f31022580df8d : SUCCESS in 23m 53s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/b11a663f94ab4af8bc2e8b4243432f00 : SUCCESS in 14m 32s\n- tempest-full https://zuul.opendev.org/t/openstack/build/0fa83f7a393c4da697ab4e72db9f1a98 : SUCCESS in 1h 35m 41s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/f68c8ce4f4384852868bae8831e59672 : SUCCESS in 52m 40s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/1d21c100944c40159d10cf828590d0a5 : SUCCESS in 1h 06m 26s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/9eb066a4077542eab0a690c279b74d9a : SUCCESS in 1h 28m 29s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/24b2ef69db09467189b946463f1543c5 : SUCCESS in 30m 40s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/01b2588ab89a4501ae84229b5cedcd96 : SUCCESS in 31m 10s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/0070c6f508ad4b5ab0e747409ca5d505 : SUCCESS in 48m 03s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/36e12953be9c4a1c83c7e9b5961a8ef8 : SUCCESS in 42m 43s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/96ea8cebdaae4e9999533f70940a7c02 : SUCCESS in 17m 03s (non-voting)\n- legacy-tempest-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/74bde7b32b68456e9f1fab84fe05908f : SUCCESS in 1h 39m 34s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/7c2a779eea2f478893b91d45d10e4942 : SUCCESS in 1h 00m 02s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/40f5c676a685427e800431b2929b298f : SUCCESS in 34m 47s","accounts_in_message":[],"_revision_number":3},{"id":"e8460d0c4ed669b59d8395bfda3ea2fa480d22be","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-13 00:20:14.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"de98a7c893ba23b23adf0e2adc1ea1fcb2ff1068","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-13 01:47:42.000000000","message":"Patch Set 4: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/2a77a3c334444bcc8f254d9c59698e69 : SUCCESS in 30m 30s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/99b5583510774fe388101c41203a6f68 : SUCCESS in 12m 48s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/97c8a0104d5b42b9928ac0ae313db6b4 : SUCCESS in 6m 24s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/20524f3aefa142a8afc8cf1a1d0161e7 : SUCCESS in 28m 17s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/d2cf19083eb34ca4a57dd636a89f46a9 : SUCCESS in 28m 55s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/ee1ddaa4974544438baebbf4838e653c : SUCCESS in 14m 46s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/21ab48d62f0c4cc182d5878e15516c47 : SUCCESS in 15m 23s\n- tempest-full https://zuul.opendev.org/t/openstack/build/bc1c234cd324426793c3bd5698f283c0 : SUCCESS in 1h 19m 11s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/abb050c207b0407babd59d3506789822 : SUCCESS in 59m 58s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/c5222355c8cf42bb98665eacb9d8ae19 : SUCCESS in 59m 50s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/c662cbb2ce4a403888065fa5b64a7fe4 : SUCCESS in 1h 26m 06s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/5f6c259dc62848d69ac27f18243e847e : SUCCESS in 39m 34s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/3a34c792efbc49888e319872d5826431 : SUCCESS in 34m 50s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/7389e12c2faa41e3a1460c5d184ec907 : SUCCESS in 38m 59s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/c810eac5f16b409298ad5f4f7dd7c9cf : SUCCESS in 38m 27s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/b41a97d308194f0cafc8de4ef4b2089f : SUCCESS in 20m 24s (non-voting)\n- legacy-tempest-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/e93b760d2f814b8a9d19f8b8c0d5d83a : SUCCESS in 1h 24m 16s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/dcd70db9357a4bbbb7a684e86e175fe0 : SUCCESS in 1h 00m 52s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/89e8bb165ee74e91a25c69ac0935c0b7 : SUCCESS in 40m 52s","accounts_in_message":[],"_revision_number":4},{"id":"e4b1243230f0e7a6408407da5dc8c4b2b83ba523","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-10-13 19:06:17.000000000","message":"Patch Set 4: Code-Review+1","accounts_in_message":[],"_revision_number":4},{"id":"c07d85f4b68f560be4c60fd3c1b01fd1f2bed605","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-10-14 22:21:25.000000000","message":"Patch Set 4: Code-Review-1\n\nI am unable to recreate the problem described. Could you create a bug report and include examples of the output you are seeing from curl, the entries in the local_user and federated_user tables, your mapping rules, and any relevant logs? https://bugs.launchpad.net/keystone/+filebug\n\nDoes your mapping use the \"local\" user type or the \"ephemeral\" user type? When I try this using the \"local\" type, the federated user is never entered into the federated_user table and only the local_user is used. When I try with the \"ephemeral\" type, it only appears in the federated_user table.\n\nWhat version of keystone are you using?","accounts_in_message":[],"_revision_number":4},{"id":"987b8670c1245de5952c0e33d8b6e8d16ba0c69e","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-16 13:26:59.000000000","message":"Uploaded patch set 5: Commit message was updated.","accounts_in_message":[],"_revision_number":5},{"id":"97735fdd5ba95918cd0c0a50e95408aae200438e","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-16 13:29:36.000000000","message":"Patch Set 5:\n\n\u003e I am unable to recreate the problem described. Could you create a\n \u003e bug report and include examples of the output you are seeing from\n \u003e curl, the entries in the local_user and federated_user tables, your\n \u003e mapping rules, and any relevant logs? https://bugs.launchpad.net/keystone/+filebug\n \u003e \n \u003e Does your mapping use the \"local\" user type or the \"ephemeral\" user\n \u003e type? When I try this using the \"local\" type, the federated user is\n \u003e never entered into the federated_user table and only the local_user\n \u003e is used. When I try with the \"ephemeral\" type, it only appears in\n \u003e the federated_user table.\n \u003e \n \u003e What version of keystone are you using?\n\n\nHello Colleen, the version of keystone is the 14.0.1 (Rocky),\nhere is the link to the issue: https://bugs.launchpad.net/keystone/+bug/1848342\n\nThanks for the review","accounts_in_message":[],"_revision_number":5},{"id":"98af52dbd8765a3ae2cf9a3370b217cac0e83740","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-16 15:48:55.000000000","message":"Patch Set 5: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/cb5d5a6019934345900ed8c0ea7709cb : SUCCESS in 18m 49s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/be4e701da94442deb1559ff3f972998a : SUCCESS in 17m 12s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/0954dabf3c354e41b9d9a08ab1472947 : SUCCESS in 6m 48s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/3e48639cdd64479d94961af3f01c2556 : SUCCESS in 22m 12s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/9d222c45f342489d8d46e7a1716e7c7c : SUCCESS in 15m 08s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/003fa5fcdf1946f7b573b9b8eddb129b : SUCCESS in 17m 00s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/ae7e46eb018f4448849f7c1b484c041f : SUCCESS in 15m 12s\n- tempest-full https://zuul.opendev.org/t/openstack/build/9d44182600294853b186b13a15ba1a25 : SUCCESS in 1h 37m 01s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/3c513341e5b249ba8e6e379a45dc59ce : SUCCESS in 1h 01m 42s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/14f5b331c02d4e5d91d20c1d4887dfd0 : SUCCESS in 1h 00m 34s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/50683d3f9e2f47c0a77ebe2bc5f729de : SUCCESS in 1h 48m 14s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/9294e19767fd4e03ab576693550c619a : SUCCESS in 36m 07s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/57b5986194094b00a0a057aa2465fa32 : SUCCESS in 33m 53s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/8ac945b5d95f412c9829f6cc6dcb18f0 : SUCCESS in 43m 52s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/7006fdc7cc844b779d893e3c9d70dc3b : SUCCESS in 45m 04s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/48e90b27bc22447981ecf0ae004dd7e9 : SUCCESS in 20m 23s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/71b256de6ccb4c0c95c9c73aad7bb01f : SUCCESS in 46m 34s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/c76b81ef2f9f4aa391f776491aa2fbee : SUCCESS in 1h 14m 51s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/0dc8d758be944d1ca32499a77ae756e1 : SUCCESS in 40m 28s","accounts_in_message":[],"_revision_number":5},{"id":"99705a911cf1119a5631eb0c1f296584c3248bf4","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-10-16 20:46:33.000000000","message":"Patch Set 5: Code-Review-1\n\nThanks for the bug report, I now agree this is a bug but filtering isn\u0027t the right approach, see my comment in the bug report.","accounts_in_message":[],"_revision_number":5},{"id":"a70e32d907e287144014d37a9e0d1a1a05dbf068","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-17 21:36:04.000000000","message":"Uploaded patch set 6.","accounts_in_message":[],"_revision_number":6},{"id":"fcb29fbb61e0e28db2ad83dc5ef1d14646b21894","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-17 23:36:08.000000000","message":"Patch Set 6: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/70acd1e8ee704a5496e2523930952caa : SUCCESS in 26m 10s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/d0b8e9f0f7b54b4d938e56c54a858042 : SUCCESS in 21m 54s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/ec493b6126334fa983e152fa4043d182 : FAILURE in 5m 59s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/4917b4c283b94a76a668f16e5414a11c : SUCCESS in 24m 33s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/ef2c42dfba1d4f9aa753cc8f358c1b44 : SUCCESS in 30m 20s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/6736a69ed5d142fc8992e7e0ad3fb38f : SUCCESS in 21m 10s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/1a9cdc3c62584f73bc1319254b1461af : SUCCESS in 11m 54s\n- tempest-full https://zuul.opendev.org/t/openstack/build/04246d4b1df444248a95d9d8f073ebb2 : SUCCESS in 1h 57m 48s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/e9b3dd93152746d7b5dbfa8a277e3c35 : SUCCESS in 50m 51s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/34b432d88f264f19843e84b6d3b3202a : SUCCESS in 59m 01s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/185de886b8b94f2fbf26371e67246324 : SUCCESS in 1h 28m 03s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/9ff27f03277b4d7f9437cc9cf440495f : SUCCESS in 28m 59s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/1cd34a43eb5545d8b4b77e8eeca48a5b : SUCCESS in 36m 05s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/33580869d5b741a283597e6d26baf8d4 : SUCCESS in 38m 48s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/51567539c82743acb4a129487fc8566f : SUCCESS in 42m 24s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/e08a561f92b347bfbaa887e70f8246bf : SUCCESS in 13m 23s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/c7c2edf28182486691c9b0509a882c42 : SUCCESS in 39m 10s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/1b9f10f82f144dd6a456f9b9375a87f9 : SUCCESS in 1h 00m 30s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/c18ee8f8ace746cd95c685f530630bbb : SUCCESS in 34m 55s","accounts_in_message":[],"_revision_number":6},{"id":"c5314b9b90900f556f8796637804f80185ae431f","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-18 02:01:41.000000000","message":"Uploaded patch set 7.","accounts_in_message":[],"_revision_number":7},{"id":"a9a1c26834caf254c99aae965710fc1c6a466f40","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-18 03:43:46.000000000","message":"Patch Set 7: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/4240351e084249ed93f56902a600c042 : SUCCESS in 24m 36s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/eef37a6cd66647ecb908352e92bb938f : SUCCESS in 23m 16s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/7229a3d0ec264645816030ba6c37236a : SUCCESS in 6m 10s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/15b60b5e607149a2a261ff18ccd99173 : SUCCESS in 17m 13s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/cd382422e14f4a789f887658a8a62e9f : SUCCESS in 19m 29s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/18538772f7c84b258db8d88ed3f771bc : SUCCESS in 14m 57s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/1d3a0460f8a247a691cbf4aebfc6272a : SUCCESS in 14m 13s\n- tempest-full https://zuul.opendev.org/t/openstack/build/096436dedd2545c1825b0a3771c3102a : SUCCESS in 1h 40m 30s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/eb4c8ba8b65949289d70a05dc8bbb98e : SUCCESS in 1h 00m 33s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/20f48d66b87d4fef84f2b4b26626e759 : SUCCESS in 53m 26s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/113b898d8140420e98c441361b36a09e : SUCCESS in 1h 38m 45s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/30e1b7dd6bd94294bd0ad2a9e1c94679 : SUCCESS in 32m 57s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/577d73ea487a4b1ba71fed38a887dd66 : SUCCESS in 33m 12s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/c42f47ab117247b29b8c55d6cc453252 : SUCCESS in 35m 06s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/7ccdc86fc613497caf64c09539c67057 : SUCCESS in 39m 25s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/bca18fbe27fd47e797b6ca1436c3681e : SUCCESS in 19m 13s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/b2b683c60f334cbda677a10044f85f90 : SUCCESS in 36m 25s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/32755e21536a4caca116bdad839404c2 : SUCCESS in 1h 06m 32s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/aa5f2678d2ba419a81b07f260d27b65e : SUCCESS in 40m 36s","accounts_in_message":[],"_revision_number":7},{"id":"d07129c011275eb155f4b9ed8de253ddb8c5e7a9","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-10-18 10:29:27.000000000","message":"Patch Set 7: Code-Review+1","accounts_in_message":[],"_revision_number":7},{"id":"01fd79b85fe16de04b857756e633dc246aa1a076","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-18 12:30:38.000000000","message":"Patch Set 7:\n\n\u003e Thanks for the bug report, I now agree this is a bug but filtering\n \u003e isn\u0027t the right approach, see my comment in the bug report.\n\nHi Colleen, I did some changes in the approach, could you take a look?","accounts_in_message":[],"_revision_number":7},{"id":"0de8fd1ffc7d5396433653bf2a7d7ad4c5fa52f0","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-22 19:46:05.000000000","message":"Uploaded patch set 8.","accounts_in_message":[],"_revision_number":8},{"id":"c1aaa0e005a60501aebf4dccb2ee47c2c0d0811d","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-22 21:29:29.000000000","message":"Patch Set 8: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/28756025b86d4a0ca1023f735ab23c69 : SUCCESS in 15m 22s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/946b2842430b432f879a2f6d20ef354d : SUCCESS in 17m 07s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/5c4b8f41db614d90a0aa6f88bf016803 : SUCCESS in 6m 02s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/6afbdfb3597f427dba188c4e29ed1fea : SUCCESS in 12m 12s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/805ee8c92f3c446d86b4e48979e8ae56 : SUCCESS in 12m 48s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/72612d319cce4a298d7d7ace173faa8b : SUCCESS in 15m 25s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/44015d7e85bd4442b3055b2a85419dfb : SUCCESS in 11m 34s\n- tempest-full https://zuul.opendev.org/t/openstack/build/79cfe22fc3784c90a9a1aca1765336b1 : SUCCESS in 1h 37m 34s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/af8aece422be45e98ad6f13c4c4b2716 : SUCCESS in 57m 17s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/6555314d3c7641408ee381794844bfc3 : SUCCESS in 1h 00m 40s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/ebd0db7eb7054305abda9b279e051001 : SUCCESS in 1h 22m 19s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/c98dc5c1ec0c4487a47248eea9cd4050 : SUCCESS in 17m 04s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/667ed39aa9ce4f26abaf8253a83d5422 : SUCCESS in 33m 15s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/cf8b2d7122514ee48a389e0428f598de : SUCCESS in 38m 04s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/0c1708de7fc14587a29f8e7589b0af90 : SUCCESS in 37m 06s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/75547da61b91431f87c44b854524d7d2 : FAILURE in 14m 30s (non-voting)\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/cc12f127244a4c9990d54d43c2b47358 : SUCCESS in 17m 43s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/95ce204889de45f2a2be23ffc0c0b178 : SUCCESS in 46m 15s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/f0bd6f1542d04a2bafb0e7ace8c853ea : SUCCESS in 1h 03m 38s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/4679c58e3fac40c89266511d0e630ad2 : SUCCESS in 45m 27s","accounts_in_message":[],"_revision_number":8},{"id":"2487f476e5abcaae5d68c991fa12f513ef1760ea","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-28 14:30:34.000000000","message":"Patch Set 8:\n\nrecheck","accounts_in_message":[],"_revision_number":8},{"id":"77691b1769e3e6aaf7d00f824c81a9234a5c866a","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-28 16:16:13.000000000","message":"Patch Set 8: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/96272bafca984db9aa0b642f79013567 : SUCCESS in 16m 29s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/3e58c69a06174ff0be22114592c34d29 : SUCCESS in 14m 52s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/84f8deab9cda4f958240f73faf5b4223 : FAILURE in 6m 15s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/ccdd5de22e3b4f4999223fe91ad3480f : SUCCESS in 15m 26s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/d950a70a25014e8b88a691d02c722ec1 : SUCCESS in 12m 18s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/ff9b02ac156743219d0dad58a3bf3741 : SUCCESS in 13m 29s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/e2387ac7278f46f2a9c89caeff352f4a : SUCCESS in 13m 13s\n- tempest-full https://zuul.opendev.org/t/openstack/build/6af58c16b2734b58b73251ea878500c9 : SUCCESS in 1h 40m 16s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/645466f578ec46ed91a571f043413c0f : SUCCESS in 1h 01m 30s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/c6bee6a0014e4a52b621a849693b9e62 : SUCCESS in 1h 08m 26s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/a1f3ca5d32df4fc083f0f35418808abe : SUCCESS in 1h 23m 01s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/e8e42d512a64418da5c8fbacefdf7c69 : SUCCESS in 16m 24s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/e0f8505aae1946fab7dbde0875125e6f : SUCCESS in 35m 14s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/6c2f5cb02b6b4ad7b637e76cd0a28efc : SUCCESS in 45m 03s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/cfb41f6a71d04247bbec4a35a6f4bd5d : SUCCESS in 41m 02s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/08ed3e830d3a485cb23e6f7c1bfe4081 : SUCCESS in 50m 06s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/f8610709c1b84c13bf7b0680ddd2d45b : SUCCESS in 39m 27s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/75853deb3ae84c18a981be304d53068d : SUCCESS in 16m 34s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/175aaa24f48747a6b6e1c011983359cb : SUCCESS in 38m 50s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/9c0de3357b564a60a3412522f64c2f5c : SUCCESS in 1h 01m 37s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/a3ceacaa0b3d467799e67c604570ea50 : SUCCESS in 38m 07s","accounts_in_message":[],"_revision_number":8},{"id":"416374847afaf151026d55eea63f018076f01f53","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-28 17:51:37.000000000","message":"Uploaded patch set 9.","accounts_in_message":[],"_revision_number":9},{"id":"70a96c014e9c5bc19b42a830b60a0d92abf54198","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-28 19:42:13.000000000","message":"Patch Set 9: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/5d030fbf46144d00aa7b19c35cc8df90 : FAILURE in 17m 27s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/6ca0bdaa8e2b48e1aa14a7d94fe0f59e : SUCCESS in 15m 35s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/b29f5e2f4a2e417d8ed0db1c691e92d8 : SUCCESS in 6m 26s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/d55ea3de68864f42a8d24a279361d482 : SUCCESS in 21m 32s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/d736aee79c2a45c5bff8a1cbaa8d20a1 : SUCCESS in 25m 51s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/6ce79a7984f84069b60263831055d058 : SUCCESS in 21m 42s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/08e8b17679124113ba03c10ae44360ed : SUCCESS in 13m 37s\n- tempest-full https://zuul.opendev.org/t/openstack/build/7fe8b34165724dea9ead3032b833c85b : SUCCESS in 1h 28m 54s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/27288d5790d9481ab4748d03cecbf7b7 : SUCCESS in 1h 09m 19s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/66df7f7972b148aab6ac986bf580c89d : SUCCESS in 55m 04s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/ffacfc97a45e497fb7c6243d1a7731c7 : SUCCESS in 1h 48m 40s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/ccad722918514d90babf0b9dae1f5826 : SUCCESS in 15m 59s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/ad8603184bca417ebce558074b50f382 : SUCCESS in 46m 13s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/8cae782db53249abace83922167566e3 : SUCCESS in 30m 20s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/5d283f52aecc471bba0617b11de59002 : SUCCESS in 39m 02s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/ac739d863cf142b5a557b78b94775d12 : SUCCESS in 36m 20s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/4a968e66eca54277be229d03d07dbbd2 : SUCCESS in 45m 55s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/17272368001b4c6fa72279443d1f6a2d : SUCCESS in 15m 35s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/71f481f6275c4a18892d20edaa98912f : SUCCESS in 40m 07s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/124f080c590d44ff9e9066543ed44a0d : SUCCESS in 59m 47s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/8da9a129db584c488e3386e51305f3ef : SUCCESS in 44m 27s","accounts_in_message":[],"_revision_number":9},{"id":"9b6b079c1e9d8550e2bd1720c4e2c29db6119d4a","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-28 21:49:31.000000000","message":"Patch Set 9:\n\nrecheck","accounts_in_message":[],"_revision_number":9},{"id":"f9ab8015b35b5b7df8d30ac7adc0cd2c5578860e","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-10-28 23:39:22.000000000","message":"Patch Set 9: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/2624ba7925af4edb82cd95f181740519 : SUCCESS in 42m 21s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/ae731240eb124fae84d11150db3d62c2 : SUCCESS in 13m 46s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/2c0f683940ff446abc6c813554fee61c : SUCCESS in 5m 34s\n- openstack-tox-py27 https://zuul.opendev.org/t/openstack/build/06dc66446f5747dca31417cb7c601737 : SUCCESS in 14m 32s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/7aa7bac9e61a4342b6707a7c4a46dfa7 : SUCCESS in 11m 46s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/45c31823db5e43988b9fbea023ed641b : SUCCESS in 12m 38s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/3763b4b253184f43a90e1c7ec5041ae1 : SUCCESS in 12m 50s\n- tempest-full https://zuul.opendev.org/t/openstack/build/8099c076e2a4401bbcffdd0ae78456cf : SUCCESS in 1h 48m 12s\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/212c60db0b9a41d9b4164b7df555c533 : SUCCESS in 1h 01m 15s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/c6c2afce0c5349feb3ce753857d0cd3a : SUCCESS in 55m 47s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/92634f5091524573b478ce1d4f110218 : SUCCESS in 1h 13m 41s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/14a6997615a14664862af52c0776a069 : SUCCESS in 17m 46s\n- keystone-dsvm-functional https://zuul.opendev.org/t/openstack/build/b1b6af7b603b478ba0938edc8ac11887 : SUCCESS in 35m 31s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/b8137cc4e8914d34a5bed8010a7bc775 : SUCCESS in 30m 16s\n- keystone-dsvm-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/f63b02b87f194bdaab9b317df5c3409e : SUCCESS in 40m 47s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/ff60af8883dc4c3b9bd21e90259a53b4 : SUCCESS in 41m 24s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/f71a97ab9c1c41a990ae75160360acab : SUCCESS in 38m 07s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/d61dc57f098248edae94248f9cd59cf2 : SUCCESS in 16m 14s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/8bebe10d68ca4a359ed16b2cf5ff617c : SUCCESS in 38m 06s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/b2e2c896737e46fab629732b3423137c : SUCCESS in 1h 00m 43s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/af5ce4048858417a8508d9030bfa91f1 : SUCCESS in 31m 40s","accounts_in_message":[],"_revision_number":9},{"id":"7a14520ad84bdcb1bf759a1703db9d9d7c1f70a5","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-10-29 00:15:10.000000000","message":"Patch Set 9:\n\nHi guys, everything looks good to be merged. Would you guys mind to review it? Do I need to change something else?","accounts_in_message":[],"_revision_number":9},{"id":"7597739accd4040b578508c9b75156170298beb8","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-10-31 18:39:51.000000000","message":"Patch Set 9: Code-Review+1","accounts_in_message":[],"_revision_number":9},{"id":"a5ab8b4c0a5d731f660f57e6bdd1855873f6e73b","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-11-21 19:09:53.000000000","message":"Patch Set 9:\n\nHi folks, could someone check this PR? Do I need to change something else?","accounts_in_message":[],"_revision_number":9},{"id":"21955854ed4ffa9b3b6483c37135efc8cb9d0845","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-01 22:06:05.000000000","message":"Patch Set 9: Code-Review-1\n\nThis approach is too broad. The problem is not that the user-facing API allows updating federated users, it\u0027s simply a bug in the implementation of the shadow_federated_user method (which purposefully does a user update to ensure the shadow users attributes are in sync with the IdP) and/or the underlying sqlalchemy driver code which is wrongly creating a record in the local_user table.","accounts_in_message":[],"_revision_number":9},{"id":"050f0746343ad679c09c34e40a0e04662a0b04c6","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-12-02 01:01:42.000000000","message":"Patch Set 9:\n\n\u003e This approach is too broad. The problem is not that the user-facing\n \u003e API allows updating federated users, it\u0027s simply a bug in the\n \u003e implementation of the shadow_federated_user method (which\n \u003e purposefully does a user update to ensure the shadow users\n \u003e attributes are in sync with the IdP) and/or the underlying\n \u003e sqlalchemy driver code which is wrongly creating a record in the\n \u003e local_user table.\n\nColleen Murphy, can you be more specific/clear? Your comment looks very similar to what you said in (a long time ago) https://bugs.launchpad.net/keystone/+bug/1848342. However, if you take a look into the code, we are not just blocking the update from the user side in the API. The proposal here is actually fixing the update of the shadow_federated_user, which was the solution we seemed to have discussed already. Can you provide a more clear feedback on what you dislike here in this solution?","accounts_in_message":[],"_revision_number":9},{"id":"9f2ccf54902fe018ad324f2eb64c0b94adb8a592","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-02 02:18:18.000000000","message":"Patch Set 9:\n\n\u003e \u003e This approach is too broad. The problem is not that the\n \u003e user-facing\n \u003e \u003e API allows updating federated users, it\u0027s simply a bug in the\n \u003e \u003e implementation of the shadow_federated_user method (which\n \u003e \u003e purposefully does a user update to ensure the shadow users\n \u003e \u003e attributes are in sync with the IdP) and/or the underlying\n \u003e \u003e sqlalchemy driver code which is wrongly creating a record in the\n \u003e \u003e local_user table.\n \u003e \n \u003e Colleen Murphy, can you be more specific/clear? Your comment looks\n \u003e very similar to what you said in (a long time ago)\n \u003e https://bugs.launchpad.net/keystone/+bug/1848342. However, if you\n \u003e take a look into the code, we are not just blocking the update from\n \u003e the user side in the API. The proposal here is actually fixing the\n \u003e update of the shadow_federated_user, which was the solution we\n \u003e seemed to have discussed already. Can you provide a more clear\n \u003e feedback on what you dislike here in this solution?\n\nThe change that introduced this bug is here: https://review.opendev.org/549723\n\nThe change was made for good reason, email is a valid attribute in the shadow user mapping, and so we don\u0027t want to block updating it. Changing the PATCH API for /v3/users to disallow it would also be an API-breaking change which we need to avoid.\n\nMy suggestion is not to change the patch method in keystone/api/users.py, but instead to just change either shadow_federated_user in keystone/identity/core.py to avoid using update_user which seems to be doing the wrong thing, or fix the SQL driver\u0027s update_user method to ensure it doesn\u0027t touch the local_user table but only touches the user table.","accounts_in_message":[],"_revision_number":9},{"id":"f1b42280401c975cd2dd547bab2e8d787497fb31","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-12-04 12:43:58.000000000","message":"Patch Set 9: -Code-Review\n\n\u003e \u003e \u003e This approach is too broad. The problem is not that the\n \u003e \u003e user-facing\n \u003e \u003e \u003e API allows updating federated users, it\u0027s simply a bug in the\n \u003e \u003e \u003e implementation of the shadow_federated_user method (which\n \u003e \u003e \u003e purposefully does a user update to ensure the shadow users\n \u003e \u003e \u003e attributes are in sync with the IdP) and/or the underlying\n \u003e \u003e \u003e sqlalchemy driver code which is wrongly creating a record in\n \u003e the\n \u003e \u003e \u003e local_user table.\n \u003e \u003e\n \u003e \u003e Colleen Murphy, can you be more specific/clear? Your comment\n \u003e looks\n \u003e \u003e very similar to what you said in (a long time ago)\n \u003e \u003e https://bugs.launchpad.net/keystone/+bug/1848342. However, if you\n \u003e \u003e take a look into the code, we are not just blocking the update\n \u003e from\n \u003e \u003e the user side in the API. The proposal here is actually fixing\n \u003e the\n \u003e \u003e update of the shadow_federated_user, which was the solution we\n \u003e \u003e seemed to have discussed already. Can you provide a more clear\n \u003e \u003e feedback on what you dislike here in this solution?\n \u003e \n \u003e The change that introduced this bug is here: https://review.opendev.org/549723\n \u003e \n \u003e The change was made for good reason, email is a valid attribute in\n \u003e the shadow user mapping, and so we don\u0027t want to block updating it.\n \u003e Changing the PATCH API for /v3/users to disallow it would also be\n \u003e an API-breaking change which we need to avoid.\n \u003e \n \u003e My suggestion is not to change the patch method in\n \u003e keystone/api/users.py, but instead to just change either\n \u003e shadow_federated_user in keystone/identity/core.py to avoid using\n \u003e update_user which seems to be doing the wrong thing, or fix the SQL\n \u003e driver\u0027s update_user method to ensure it doesn\u0027t touch the\n \u003e local_user table but only touches the user table.\n\nThat is the point, I do understand that the first proposal was to simply block the ability to update the value from the API. However, if you look into the changes now, Pedro is actually fixing the update process as you suggested.\n\nMoreover, Pedro fixed the inconsistency with the getter and setter of the name property that was generating the bug, and the setter of the password property (federated users should not have password in OpenStack). Then, we blocked federated users (true federated users, do not confuse with the local users that are authenticating in the IdP) to update attributes directly in OpenStack, they should instead execute the update in the IdP, and then during the login process the updated attributes are gathered and updated by Keystone.","accounts_in_message":[],"_revision_number":9},{"id":"a7a293b0c6267aa80ea06886304f28b39833a629","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-04 17:42:54.000000000","message":"Patch Set 9:\n\n\u003e \u003e \u003e \u003e This approach is too broad. The problem is not that the\n \u003e \u003e \u003e user-facing\n \u003e \u003e \u003e \u003e API allows updating federated users, it\u0027s simply a bug in the\n \u003e \u003e \u003e \u003e implementation of the shadow_federated_user method (which\n \u003e \u003e \u003e \u003e purposefully does a user update to ensure the shadow users\n \u003e \u003e \u003e \u003e attributes are in sync with the IdP) and/or the underlying\n \u003e \u003e \u003e \u003e sqlalchemy driver code which is wrongly creating a record in\n \u003e \u003e the\n \u003e \u003e \u003e \u003e local_user table.\n \u003e \u003e \u003e\n \u003e \u003e \u003e Colleen Murphy, can you be more specific/clear? Your comment\n \u003e \u003e looks\n \u003e \u003e \u003e very similar to what you said in (a long time ago)\n \u003e \u003e \u003e https://bugs.launchpad.net/keystone/+bug/1848342. However, if\n \u003e you\n \u003e \u003e \u003e take a look into the code, we are not just blocking the update\n \u003e \u003e from\n \u003e \u003e \u003e the user side in the API. The proposal here is actually fixing\n \u003e \u003e the\n \u003e \u003e \u003e update of the shadow_federated_user, which was the solution we\n \u003e \u003e \u003e seemed to have discussed already. Can you provide a more clear\n \u003e \u003e \u003e feedback on what you dislike here in this solution?\n \u003e \u003e\n \u003e \u003e The change that introduced this bug is here: https://review.opendev.org/549723\n \u003e \u003e\n \u003e \u003e The change was made for good reason, email is a valid attribute\n \u003e in\n \u003e \u003e the shadow user mapping, and so we don\u0027t want to block updating\n \u003e it.\n \u003e \u003e Changing the PATCH API for /v3/users to disallow it would also be\n \u003e \u003e an API-breaking change which we need to avoid.\n \u003e \u003e\n \u003e \u003e My suggestion is not to change the patch method in\n \u003e \u003e keystone/api/users.py, but instead to just change either\n \u003e \u003e shadow_federated_user in keystone/identity/core.py to avoid using\n \u003e \u003e update_user which seems to be doing the wrong thing, or fix the\n \u003e SQL\n \u003e \u003e driver\u0027s update_user method to ensure it doesn\u0027t touch the\n \u003e \u003e local_user table but only touches the user table.\n \u003e \n \u003e That is the point, I do understand that the first proposal was to\n \u003e simply block the ability to update the value from the API. However,\n \u003e if you look into the changes now, Pedro is actually fixing the\n \u003e update process as you suggested.\n\nThe current proposal blocks the update from the API: https://review.opendev.org/#/c/687990/9/keystone/api/users.py\n\n \u003e \n \u003e Moreover, Pedro fixed the inconsistency with the getter and setter\n \u003e of the name property that was generating the bug, and the setter of\n \u003e the password property (federated users should not have password in\n \u003e OpenStack). Then, we blocked federated users (true federated users,\n \u003e do not confuse with the local users that are authenticating in the\n \u003e IdP) to update attributes directly in OpenStack, they should\n \u003e instead execute the update in the IdP, and then during the login\n \u003e process the updated attributes are gathered and updated by\n \u003e Keystone.\n\nNone of that is part of the bug. The bug is the duplicated entry due to the extra shadowed user that happens when the user logs in, not when the user\u0027s password is changed or anything else about the user is changed by the administrator.","accounts_in_message":[],"_revision_number":9},{"id":"990268f6a5b7bbb91542237ef95c28533e96d8a4","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-12-04 17:49:47.000000000","message":"Patch Set 9:\n\n\u003e \u003e \u003e \u003e \u003e This approach is too broad. The problem is not that the\n \u003e \u003e \u003e \u003e user-facing\n \u003e \u003e \u003e \u003e \u003e API allows updating federated users, it\u0027s simply a bug in\n \u003e the\n \u003e \u003e \u003e \u003e \u003e implementation of the shadow_federated_user method (which\n \u003e \u003e \u003e \u003e \u003e purposefully does a user update to ensure the shadow users\n \u003e \u003e \u003e \u003e \u003e attributes are in sync with the IdP) and/or the underlying\n \u003e \u003e \u003e \u003e \u003e sqlalchemy driver code which is wrongly creating a record\n \u003e in\n \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e local_user table.\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e Colleen Murphy, can you be more specific/clear? Your comment\n \u003e \u003e \u003e looks\n \u003e \u003e \u003e \u003e very similar to what you said in (a long time ago)\n \u003e \u003e \u003e \u003e https://bugs.launchpad.net/keystone/+bug/1848342. However, if\n \u003e \u003e you\n \u003e \u003e \u003e \u003e take a look into the code, we are not just blocking the\n \u003e update\n \u003e \u003e \u003e from\n \u003e \u003e \u003e \u003e the user side in the API. The proposal here is actually\n \u003e fixing\n \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e update of the shadow_federated_user, which was the solution\n \u003e we\n \u003e \u003e \u003e \u003e seemed to have discussed already. Can you provide a more\n \u003e clear\n \u003e \u003e \u003e \u003e feedback on what you dislike here in this solution?\n \u003e \u003e \u003e\n \u003e \u003e \u003e The change that introduced this bug is here: https://review.opendev.org/549723\n \u003e \u003e \u003e\n \u003e \u003e \u003e The change was made for good reason, email is a valid attribute\n \u003e \u003e in\n \u003e \u003e \u003e the shadow user mapping, and so we don\u0027t want to block updating\n \u003e \u003e it.\n \u003e \u003e \u003e Changing the PATCH API for /v3/users to disallow it would also\n \u003e be\n \u003e \u003e \u003e an API-breaking change which we need to avoid.\n \u003e \u003e \u003e\n \u003e \u003e \u003e My suggestion is not to change the patch method in\n \u003e \u003e \u003e keystone/api/users.py, but instead to just change either\n \u003e \u003e \u003e shadow_federated_user in keystone/identity/core.py to avoid\n \u003e using\n \u003e \u003e \u003e update_user which seems to be doing the wrong thing, or fix the\n \u003e \u003e SQL\n \u003e \u003e \u003e driver\u0027s update_user method to ensure it doesn\u0027t touch the\n \u003e \u003e \u003e local_user table but only touches the user table.\n \u003e \u003e\n \u003e \u003e That is the point, I do understand that the first proposal was to\n \u003e \u003e simply block the ability to update the value from the API.\n \u003e However,\n \u003e \u003e if you look into the changes now, Pedro is actually fixing the\n \u003e \u003e update process as you suggested.\n \u003e \n \u003e The current proposal blocks the update from the API:\n \u003e https://review.opendev.org/#/c/687990/9/keystone/api/users.py\n \u003e \n \u003e \u003e\n \u003e \u003e Moreover, Pedro fixed the inconsistency with the getter and\n \u003e setter\n \u003e \u003e of the name property that was generating the bug, and the setter\n \u003e of\n \u003e \u003e the password property (federated users should not have password\n \u003e in\n \u003e \u003e OpenStack). Then, we blocked federated users (true federated\n \u003e users,\n \u003e \u003e do not confuse with the local users that are authenticating in\n \u003e the\n \u003e \u003e IdP) to update attributes directly in OpenStack, they should\n \u003e \u003e instead execute the update in the IdP, and then during the login\n \u003e \u003e process the updated attributes are gathered and updated by\n \u003e \u003e Keystone.\n \u003e \n \u003e None of that is part of the bug. The bug is the duplicated entry\n \u003e due to the extra shadowed user that happens when the user logs in,\n \u003e not when the user\u0027s password is changed or anything else about the\n \u003e user is changed by the administrator.\n\nI think I am not expressing myself properly. The user is being created in the local user table because of that \"name\" setter there (did you see the changes?). It was not properly coded before. Can you please get the PR and test it yourself? Then, you will see that it fix the reported problem.\n\nNow, with respect of blocking attribute updates, that was only to make the solution comprehensive. Federated users (the true federated users) should not have their attributed updated in OpenStack, but rather in the IdP. However, if that it the only reason for you to block this fix, we can have that validation, and allow attributes to be updated for federated users as well. This can create quite a good mess though, and that is why we proposed to fix this as well.","accounts_in_message":[],"_revision_number":9},{"id":"0192cdf59e0831432b631ff78b9618802961ca5b","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-04 19:32:24.000000000","message":"Patch Set 9:\n\n\u003e \u003e \u003e \u003e \u003e \u003e This approach is too broad. The problem is not that the\n \u003e \u003e \u003e \u003e \u003e user-facing\n \u003e \u003e \u003e \u003e \u003e \u003e API allows updating federated users, it\u0027s simply a bug in\n \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e implementation of the shadow_federated_user method (which\n \u003e \u003e \u003e \u003e \u003e \u003e purposefully does a user update to ensure the shadow\n \u003e users\n \u003e \u003e \u003e \u003e \u003e \u003e attributes are in sync with the IdP) and/or the\n \u003e underlying\n \u003e \u003e \u003e \u003e \u003e \u003e sqlalchemy driver code which is wrongly creating a record\n \u003e \u003e in\n \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e local_user table.\n \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e Colleen Murphy, can you be more specific/clear? Your\n \u003e comment\n \u003e \u003e \u003e \u003e looks\n \u003e \u003e \u003e \u003e \u003e very similar to what you said in (a long time ago)\n \u003e \u003e \u003e \u003e \u003e https://bugs.launchpad.net/keystone/+bug/1848342. However,\n \u003e if\n \u003e \u003e \u003e you\n \u003e \u003e \u003e \u003e \u003e take a look into the code, we are not just blocking the\n \u003e \u003e update\n \u003e \u003e \u003e \u003e from\n \u003e \u003e \u003e \u003e \u003e the user side in the API. The proposal here is actually\n \u003e \u003e fixing\n \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e update of the shadow_federated_user, which was the solution\n \u003e \u003e we\n \u003e \u003e \u003e \u003e \u003e seemed to have discussed already. Can you provide a more\n \u003e \u003e clear\n \u003e \u003e \u003e \u003e \u003e feedback on what you dislike here in this solution?\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e The change that introduced this bug is here:\n \u003e https://review.opendev.org/549723\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e The change was made for good reason, email is a valid\n \u003e attribute\n \u003e \u003e \u003e in\n \u003e \u003e \u003e \u003e the shadow user mapping, and so we don\u0027t want to block\n \u003e updating\n \u003e \u003e \u003e it.\n \u003e \u003e \u003e \u003e Changing the PATCH API for /v3/users to disallow it would\n \u003e also\n \u003e \u003e be\n \u003e \u003e \u003e \u003e an API-breaking change which we need to avoid.\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e My suggestion is not to change the patch method in\n \u003e \u003e \u003e \u003e keystone/api/users.py, but instead to just change either\n \u003e \u003e \u003e \u003e shadow_federated_user in keystone/identity/core.py to avoid\n \u003e \u003e using\n \u003e \u003e \u003e \u003e update_user which seems to be doing the wrong thing, or fix\n \u003e the\n \u003e \u003e \u003e SQL\n \u003e \u003e \u003e \u003e driver\u0027s update_user method to ensure it doesn\u0027t touch the\n \u003e \u003e \u003e \u003e local_user table but only touches the user table.\n \u003e \u003e \u003e\n \u003e \u003e \u003e That is the point, I do understand that the first proposal was\n \u003e to\n \u003e \u003e \u003e simply block the ability to update the value from the API.\n \u003e \u003e However,\n \u003e \u003e \u003e if you look into the changes now, Pedro is actually fixing the\n \u003e \u003e \u003e update process as you suggested.\n \u003e \u003e\n \u003e \u003e The current proposal blocks the update from the API:\n \u003e \u003e https://review.opendev.org/#/c/687990/9/keystone/api/users.py\n \u003e \u003e\n \u003e \u003e \u003e\n \u003e \u003e \u003e Moreover, Pedro fixed the inconsistency with the getter and\n \u003e \u003e setter\n \u003e \u003e \u003e of the name property that was generating the bug, and the\n \u003e setter\n \u003e \u003e of\n \u003e \u003e \u003e the password property (federated users should not have password\n \u003e \u003e in\n \u003e \u003e \u003e OpenStack). Then, we blocked federated users (true federated\n \u003e \u003e users,\n \u003e \u003e \u003e do not confuse with the local users that are authenticating in\n \u003e \u003e the\n \u003e \u003e \u003e IdP) to update attributes directly in OpenStack, they should\n \u003e \u003e \u003e instead execute the update in the IdP, and then during the\n \u003e login\n \u003e \u003e \u003e process the updated attributes are gathered and updated by\n \u003e \u003e \u003e Keystone.\n \u003e \u003e\n \u003e \u003e None of that is part of the bug. The bug is the duplicated entry\n \u003e \u003e due to the extra shadowed user that happens when the user logs\n \u003e in,\n \u003e \u003e not when the user\u0027s password is changed or anything else about\n \u003e the\n \u003e \u003e user is changed by the administrator.\n \u003e \n \u003e I think I am not expressing myself properly. The user is being\n \u003e created in the local user table because of that \"name\" setter there\n \u003e (did you see the changes?). It was not properly coded before. Can\n \u003e you please get the PR and test it yourself? Then, you will see that\n \u003e it fix the reported problem.\n\nThanks - I looked closer at the sql_model.py change and tested it and you\u0027re correct, the fix to the name setter fixes the issue. This should have its own unit test to verify the user isn\u0027t duplicated when shadow_federated_user is called.\n\n \u003e \n \u003e Now, with respect of blocking attribute updates, that was only to\n \u003e make the solution comprehensive. Federated users (the true\n \u003e federated users) should not have their attributed updated in\n \u003e OpenStack, but rather in the IdP. However, if that it the only\n \u003e reason for you to block this fix, we can have that validation, and\n \u003e allow attributes to be updated for federated users as well. This\n \u003e can create quite a good mess though, and that is why we proposed to\n \u003e fix this as well.\n\nThis is what I\u0027ve been trying to express, making changes to the API is too broad of a change. If anything, it should be split into its own change so that this one can simply be limited to fixing the bug in question. The change here breaks the API, I don\u0027t think we can accept that but in any case it should be considered separately from the bugfix.","accounts_in_message":[],"_revision_number":9},{"id":"155f140fd1db203204c027a56037461f867fe4a6","author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"date":"2019-12-04 19:41:57.000000000","message":"Patch Set 9:\n\n\u003e \u003e \u003e \u003e \u003e \u003e \u003e This approach is too broad. The problem is not that the\n \u003e \u003e \u003e \u003e \u003e \u003e user-facing\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e API allows updating federated users, it\u0027s simply a bug\n \u003e in\n \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e implementation of the shadow_federated_user method\n \u003e (which\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e purposefully does a user update to ensure the shadow\n \u003e \u003e users\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e attributes are in sync with the IdP) and/or the\n \u003e \u003e underlying\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e sqlalchemy driver code which is wrongly creating a\n \u003e record\n \u003e \u003e \u003e in\n \u003e \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e local_user table.\n \u003e \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e \u003e Colleen Murphy, can you be more specific/clear? Your\n \u003e \u003e comment\n \u003e \u003e \u003e \u003e \u003e looks\n \u003e \u003e \u003e \u003e \u003e \u003e very similar to what you said in (a long time ago)\n \u003e \u003e \u003e \u003e \u003e \u003e https://bugs.launchpad.net/keystone/+bug/1848342.\n \u003e However,\n \u003e \u003e if\n \u003e \u003e \u003e \u003e you\n \u003e \u003e \u003e \u003e \u003e \u003e take a look into the code, we are not just blocking the\n \u003e \u003e \u003e update\n \u003e \u003e \u003e \u003e \u003e from\n \u003e \u003e \u003e \u003e \u003e \u003e the user side in the API. The proposal here is actually\n \u003e \u003e \u003e fixing\n \u003e \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e update of the shadow_federated_user, which was the\n \u003e solution\n \u003e \u003e \u003e we\n \u003e \u003e \u003e \u003e \u003e \u003e seemed to have discussed already. Can you provide a more\n \u003e \u003e \u003e clear\n \u003e \u003e \u003e \u003e \u003e \u003e feedback on what you dislike here in this solution?\n \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e The change that introduced this bug is here:\n \u003e \u003e https://review.opendev.org/549723\n \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e The change was made for good reason, email is a valid\n \u003e \u003e attribute\n \u003e \u003e \u003e \u003e in\n \u003e \u003e \u003e \u003e \u003e the shadow user mapping, and so we don\u0027t want to block\n \u003e \u003e updating\n \u003e \u003e \u003e \u003e it.\n \u003e \u003e \u003e \u003e \u003e Changing the PATCH API for /v3/users to disallow it would\n \u003e \u003e also\n \u003e \u003e \u003e be\n \u003e \u003e \u003e \u003e \u003e an API-breaking change which we need to avoid.\n \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e My suggestion is not to change the patch method in\n \u003e \u003e \u003e \u003e \u003e keystone/api/users.py, but instead to just change either\n \u003e \u003e \u003e \u003e \u003e shadow_federated_user in keystone/identity/core.py to avoid\n \u003e \u003e \u003e using\n \u003e \u003e \u003e \u003e \u003e update_user which seems to be doing the wrong thing, or fix\n \u003e \u003e the\n \u003e \u003e \u003e \u003e SQL\n \u003e \u003e \u003e \u003e \u003e driver\u0027s update_user method to ensure it doesn\u0027t touch the\n \u003e \u003e \u003e \u003e \u003e local_user table but only touches the user table.\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e That is the point, I do understand that the first proposal\n \u003e was\n \u003e \u003e to\n \u003e \u003e \u003e \u003e simply block the ability to update the value from the API.\n \u003e \u003e \u003e However,\n \u003e \u003e \u003e \u003e if you look into the changes now, Pedro is actually fixing\n \u003e the\n \u003e \u003e \u003e \u003e update process as you suggested.\n \u003e \u003e \u003e\n \u003e \u003e \u003e The current proposal blocks the update from the API:\n \u003e \u003e \u003e https://review.opendev.org/#/c/687990/9/keystone/api/users.py\n \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e Moreover, Pedro fixed the inconsistency with the getter and\n \u003e \u003e \u003e setter\n \u003e \u003e \u003e \u003e of the name property that was generating the bug, and the\n \u003e \u003e setter\n \u003e \u003e \u003e of\n \u003e \u003e \u003e \u003e the password property (federated users should not have\n \u003e password\n \u003e \u003e \u003e in\n \u003e \u003e \u003e \u003e OpenStack). Then, we blocked federated users (true federated\n \u003e \u003e \u003e users,\n \u003e \u003e \u003e \u003e do not confuse with the local users that are authenticating\n \u003e in\n \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e IdP) to update attributes directly in OpenStack, they should\n \u003e \u003e \u003e \u003e instead execute the update in the IdP, and then during the\n \u003e \u003e login\n \u003e \u003e \u003e \u003e process the updated attributes are gathered and updated by\n \u003e \u003e \u003e \u003e Keystone.\n \u003e \u003e \u003e\n \u003e \u003e \u003e None of that is part of the bug. The bug is the duplicated\n \u003e entry\n \u003e \u003e \u003e due to the extra shadowed user that happens when the user logs\n \u003e \u003e in,\n \u003e \u003e \u003e not when the user\u0027s password is changed or anything else about\n \u003e \u003e the\n \u003e \u003e \u003e user is changed by the administrator.\n \u003e \u003e\n \u003e \u003e I think I am not expressing myself properly. The user is being\n \u003e \u003e created in the local user table because of that \"name\" setter\n \u003e there\n \u003e \u003e (did you see the changes?). It was not properly coded before. Can\n \u003e \u003e you please get the PR and test it yourself? Then, you will see\n \u003e that\n \u003e \u003e it fix the reported problem.\n \u003e \n \u003e Thanks - I looked closer at the sql_model.py change and tested it\n \u003e and you\u0027re correct, the fix to the name setter fixes the issue.\n \u003e This should have its own unit test to verify the user isn\u0027t\n \u003e duplicated when shadow_federated_user is called.\n \u003e \n \u003e \u003e\n \u003e \u003e Now, with respect of blocking attribute updates, that was only to\n \u003e \u003e make the solution comprehensive. Federated users (the true\n \u003e \u003e federated users) should not have their attributed updated in\n \u003e \u003e OpenStack, but rather in the IdP. However, if that it the only\n \u003e \u003e reason for you to block this fix, we can have that validation,\n \u003e and\n \u003e \u003e allow attributes to be updated for federated users as well. This\n \u003e \u003e can create quite a good mess though, and that is why we proposed\n \u003e to\n \u003e \u003e fix this as well.\n \u003e \n \u003e This is what I\u0027ve been trying to express, making changes to the API\n \u003e is too broad of a change. If anything, it should be split into its\n \u003e own change so that this one can simply be limited to fixing the bug\n \u003e in question. The change here breaks the API, I don\u0027t think we can\n \u003e accept that but in any case it should be considered separately from\n \u003e the bugfix.\n\nCool, we converged to a common ground. I will talk with Pedro to remove the \"blocking\" in the API. Then, we open an issue to address that on its own. Therefore, this PR will only address the entries in local and federated user tables. How does that sound to you?","accounts_in_message":[],"_revision_number":9},{"id":"15178df104212d072a1b6b21ffed2399dc7d6e47","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-04 19:47:01.000000000","message":"Patch Set 9:\n\n\u003e \u003e \u003e \u003e \u003e \u003e \u003e \u003e This approach is too broad. The problem is not that\n \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e user-facing\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e \u003e API allows updating federated users, it\u0027s simply a\n \u003e bug\n \u003e \u003e in\n \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e \u003e implementation of the shadow_federated_user method\n \u003e \u003e (which\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e \u003e purposefully does a user update to ensure the shadow\n \u003e \u003e \u003e users\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e \u003e attributes are in sync with the IdP) and/or the\n \u003e \u003e \u003e underlying\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e \u003e sqlalchemy driver code which is wrongly creating a\n \u003e \u003e record\n \u003e \u003e \u003e \u003e in\n \u003e \u003e \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e \u003e local_user table.\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e Colleen Murphy, can you be more specific/clear? Your\n \u003e \u003e \u003e comment\n \u003e \u003e \u003e \u003e \u003e \u003e looks\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e very similar to what you said in (a long time ago)\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e https://bugs.launchpad.net/keystone/+bug/1848342.\n \u003e \u003e However,\n \u003e \u003e \u003e if\n \u003e \u003e \u003e \u003e \u003e you\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e take a look into the code, we are not just blocking the\n \u003e \u003e \u003e \u003e update\n \u003e \u003e \u003e \u003e \u003e \u003e from\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e the user side in the API. The proposal here is actually\n \u003e \u003e \u003e \u003e fixing\n \u003e \u003e \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e update of the shadow_federated_user, which was the\n \u003e \u003e solution\n \u003e \u003e \u003e \u003e we\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e seemed to have discussed already. Can you provide a\n \u003e more\n \u003e \u003e \u003e \u003e clear\n \u003e \u003e \u003e \u003e \u003e \u003e \u003e feedback on what you dislike here in this solution?\n \u003e \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e \u003e The change that introduced this bug is here:\n \u003e \u003e \u003e https://review.opendev.org/549723\n \u003e \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e \u003e The change was made for good reason, email is a valid\n \u003e \u003e \u003e attribute\n \u003e \u003e \u003e \u003e \u003e in\n \u003e \u003e \u003e \u003e \u003e \u003e the shadow user mapping, and so we don\u0027t want to block\n \u003e \u003e \u003e updating\n \u003e \u003e \u003e \u003e \u003e it.\n \u003e \u003e \u003e \u003e \u003e \u003e Changing the PATCH API for /v3/users to disallow it would\n \u003e \u003e \u003e also\n \u003e \u003e \u003e \u003e be\n \u003e \u003e \u003e \u003e \u003e \u003e an API-breaking change which we need to avoid.\n \u003e \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e \u003e My suggestion is not to change the patch method in\n \u003e \u003e \u003e \u003e \u003e \u003e keystone/api/users.py, but instead to just change either\n \u003e \u003e \u003e \u003e \u003e \u003e shadow_federated_user in keystone/identity/core.py to\n \u003e avoid\n \u003e \u003e \u003e \u003e using\n \u003e \u003e \u003e \u003e \u003e \u003e update_user which seems to be doing the wrong thing, or\n \u003e fix\n \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e SQL\n \u003e \u003e \u003e \u003e \u003e \u003e driver\u0027s update_user method to ensure it doesn\u0027t touch\n \u003e the\n \u003e \u003e \u003e \u003e \u003e \u003e local_user table but only touches the user table.\n \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e That is the point, I do understand that the first proposal\n \u003e \u003e was\n \u003e \u003e \u003e to\n \u003e \u003e \u003e \u003e \u003e simply block the ability to update the value from the API.\n \u003e \u003e \u003e \u003e However,\n \u003e \u003e \u003e \u003e \u003e if you look into the changes now, Pedro is actually fixing\n \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e update process as you suggested.\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e The current proposal blocks the update from the API:\n \u003e \u003e \u003e \u003e https://review.opendev.org/#/c/687990/9/keystone/api/users.py\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e Moreover, Pedro fixed the inconsistency with the getter and\n \u003e \u003e \u003e \u003e setter\n \u003e \u003e \u003e \u003e \u003e of the name property that was generating the bug, and the\n \u003e \u003e \u003e setter\n \u003e \u003e \u003e \u003e of\n \u003e \u003e \u003e \u003e \u003e the password property (federated users should not have\n \u003e \u003e password\n \u003e \u003e \u003e \u003e in\n \u003e \u003e \u003e \u003e \u003e OpenStack). Then, we blocked federated users (true\n \u003e federated\n \u003e \u003e \u003e \u003e users,\n \u003e \u003e \u003e \u003e \u003e do not confuse with the local users that are authenticating\n \u003e \u003e in\n \u003e \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e \u003e IdP) to update attributes directly in OpenStack, they\n \u003e should\n \u003e \u003e \u003e \u003e \u003e instead execute the update in the IdP, and then during the\n \u003e \u003e \u003e login\n \u003e \u003e \u003e \u003e \u003e process the updated attributes are gathered and updated by\n \u003e \u003e \u003e \u003e \u003e Keystone.\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e None of that is part of the bug. The bug is the duplicated\n \u003e \u003e entry\n \u003e \u003e \u003e \u003e due to the extra shadowed user that happens when the user\n \u003e logs\n \u003e \u003e \u003e in,\n \u003e \u003e \u003e \u003e not when the user\u0027s password is changed or anything else\n \u003e about\n \u003e \u003e \u003e the\n \u003e \u003e \u003e \u003e user is changed by the administrator.\n \u003e \u003e \u003e\n \u003e \u003e \u003e I think I am not expressing myself properly. The user is being\n \u003e \u003e \u003e created in the local user table because of that \"name\" setter\n \u003e \u003e there\n \u003e \u003e \u003e (did you see the changes?). It was not properly coded before.\n \u003e Can\n \u003e \u003e \u003e you please get the PR and test it yourself? Then, you will see\n \u003e \u003e that\n \u003e \u003e \u003e it fix the reported problem.\n \u003e \u003e\n \u003e \u003e Thanks - I looked closer at the sql_model.py change and tested it\n \u003e \u003e and you\u0027re correct, the fix to the name setter fixes the issue.\n \u003e \u003e This should have its own unit test to verify the user isn\u0027t\n \u003e \u003e duplicated when shadow_federated_user is called.\n \u003e \u003e\n \u003e \u003e \u003e\n \u003e \u003e \u003e Now, with respect of blocking attribute updates, that was only\n \u003e to\n \u003e \u003e \u003e make the solution comprehensive. Federated users (the true\n \u003e \u003e \u003e federated users) should not have their attributed updated in\n \u003e \u003e \u003e OpenStack, but rather in the IdP. However, if that it the only\n \u003e \u003e \u003e reason for you to block this fix, we can have that validation,\n \u003e \u003e and\n \u003e \u003e \u003e allow attributes to be updated for federated users as well.\n \u003e This\n \u003e \u003e \u003e can create quite a good mess though, and that is why we\n \u003e proposed\n \u003e \u003e to\n \u003e \u003e \u003e fix this as well.\n \u003e \u003e\n \u003e \u003e This is what I\u0027ve been trying to express, making changes to the\n \u003e API\n \u003e \u003e is too broad of a change. If anything, it should be split into\n \u003e its\n \u003e \u003e own change so that this one can simply be limited to fixing the\n \u003e bug\n \u003e \u003e in question. The change here breaks the API, I don\u0027t think we can\n \u003e \u003e accept that but in any case it should be considered separately\n \u003e from\n \u003e \u003e the bugfix.\n \u003e \n \u003e Cool, we converged to a common ground. I will talk with Pedro to\n \u003e remove the \"blocking\" in the API. Then, we open an issue to address\n \u003e that on its own. Therefore, this PR will only address the entries\n \u003e in local and federated user tables. How does that sound to you?\n\nSounds great, thanks!","accounts_in_message":[],"_revision_number":9},{"id":"956088666804dcbe745ac0ba8b42a70a800dbe58","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-05 13:22:44.000000000","message":"Uploaded patch set 10.","accounts_in_message":[],"_revision_number":10},{"id":"76a02e0dec74a77fc9629ebb34120cded0bd3f3d","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-12-05 15:03:37.000000000","message":"Patch Set 10: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/ec54706b66bf42298b016a5f7983727c : SUCCESS in 15m 58s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/55cf4bdb88694860b822d01b58b92a0a : SUCCESS in 14m 47s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/de5a34296eb44df9bfc7c754e6b6255a : SUCCESS in 5m 20s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/331018d48e41482190773084c7a79ab7 : SUCCESS in 13m 47s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/d600792e17db4248ad847a1cf3183a04 : SUCCESS in 14m 50s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/94e5499490a84b00a694cb2e15f3e456 : SUCCESS in 11m 45s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/7b251ec5e6bb466badbf2d166c77e88d : SUCCESS in 1h 02m 55s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/000ce549b371404483db29d8421812c0 : SUCCESS in 1h 36m 42s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/0640dc98e175460b9f951e9b38d11b1b : SUCCESS in 20m 09s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/fc3bc4cb506247469c66866d69156e23 : SUCCESS in 34m 55s\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/670ea570bd844f7c9cd98d180a03df66 : SUCCESS in 39m 21s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/730e4331dcd34e288d7bd514e465402f : SUCCESS in 38m 21s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/269ba198533d43b6a6440444f8c378c8 : SUCCESS in 15m 56s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/4b01072c47b24a658bd369c74d2bb5e4 : SUCCESS in 46m 05s (non-voting)\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/6a551a3a1b3a403db488a264b7a46e19 : SUCCESS in 1h 01m 08s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/16aec8ba315f4c35b8e7809764c22fa6 : SUCCESS in 1h 00m 32s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/828f57afc022474eb58f682f579c07f6 : SUCCESS in 42m 57s","accounts_in_message":[],"_revision_number":10},{"id":"5dfedcc20a710f370a10f0f9cf37e8c0426f3d9b","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-05 17:50:46.000000000","message":"Patch Set 10: Code-Review-1\n\n(4 comments)\n\nThere is still no unit test covering the regression described in the bug report. A test should be added to keystone/tests/unit/identity/shadow_users/test_core.py that runs PROVIDERS.identity_api.shadow_federated_user twice and then ensures that the user only appears once in the list output.","accounts_in_message":[],"_revision_number":10},{"id":"0216ee2756c0cb0d0dbce6610a8ee9c8ca76576b","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-06 14:09:56.000000000","message":"Uploaded patch set 11.","accounts_in_message":[],"_revision_number":11},{"id":"f3b80a06cf3e95b0707c9fb368ab2ce1cca98b52","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-06 14:25:29.000000000","message":"Uploaded patch set 12.","accounts_in_message":[],"_revision_number":12},{"id":"0490cb75c02c8d038c6562a6c27f4f1950ffd904","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-06 14:32:09.000000000","message":"Patch Set 12:\n\n(4 comments)\n\n\u003e (4 comments)\n \u003e \n \u003e There is still no unit test covering the regression described in\n \u003e the bug report. A test should be added to keystone/tests/unit/identity/shadow_users/test_core.py\n \u003e that runs PROVIDERS.identity_api.shadow_federated_user twice and\n \u003e then ensures that the user only appears once in the list output.\n\nHi Colleen, I did the test as you suggested, could you take a look?","accounts_in_message":[],"_revision_number":12},{"id":"742c3bd303a2f9274c4a30e03d25b328d1e039d6","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-12-06 15:57:35.000000000","message":"Patch Set 12: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/e4516590bcb341e3a10b3e495f37b714 : SUCCESS in 27m 02s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/a22273bd51de42beaac032e2419647a5 : SUCCESS in 25m 35s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/0671e997dfbf459db69ec837fab110c8 : SUCCESS in 6m 41s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/b530e45878d84174ac08ab84cd7474a3 : SUCCESS in 25m 23s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/ab4050ceaec84c33b511671889c97aaa : SUCCESS in 17m 17s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/33d337782a634062af56ec2ddf6219c9 : SUCCESS in 11m 23s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/4c1a948c892b4c7ba70fde144e36a5d2 : FAILURE in 49m 57s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/8f81d4f13e6d43c38cea4afb3d7aeefd : SUCCESS in 1h 18m 28s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/1c0b6318d48e42419bd35d87d32a16e8 : SUCCESS in 16m 28s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/5a887898e12a4f498e4f28a445a5a8af : SUCCESS in 32m 53s\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/3abdfc7263154bd28919d11b9cc10424 : SUCCESS in 44m 14s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/392246ca1b964ffeaabbc59836dd08a0 : SUCCESS in 36m 35s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/a45481817b7547599b99ce7d6f4a1aa4 : SUCCESS in 16m 49s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/02a4b4b1570d430b9beb155266e943e8 : SUCCESS in 43m 58s (non-voting)\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/c1188aee8c5844e8bda1010af047434b : FAILURE in 1h 24m 00s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/2a5f7953f8914dc69a65b32dfb5ca0d8 : SUCCESS in 1h 03m 01s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/b9cd62cb2af44cafa8ff4c8f997fbf02 : SUCCESS in 39m 22s","accounts_in_message":[],"_revision_number":12},{"id":"5cd90123b7437dfcbf423a0c6d3a4e0bdf987c81","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-06 16:33:51.000000000","message":"Patch Set 12:\n\nrecheck","accounts_in_message":[],"_revision_number":12},{"id":"f1e11f9ed35ab01c2dc1eaeb56ee11d6555b3230","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-12-06 17:52:31.000000000","message":"Patch Set 12:\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/52f9c6356c3849409310860be1b8d5f4 : SUCCESS in 18m 54s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/ec4c9cecee2b4c48b64fd0dfed767475 : SUCCESS in 24m 27s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/7421356d572b4336932d455d0fcc2cf2 : SUCCESS in 6m 23s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/86f3f2236210420fbae691ce38b5cffd : SUCCESS in 23m 45s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/63eda8de21a749198c637964ec81dfb7 : SUCCESS in 13m 58s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/a9c8be4d497d424ca18389027f9f824f : SUCCESS in 12m 14s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/f1df29ceb05d485db9cfea95c76dd0ae : SUCCESS in 1h 01m 07s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/e28cc3136dbf414ba0d1e81cec04fd44 : SUCCESS in 1h 17m 31s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/6391b03ffaa546ffabb94e83158eb96e : SUCCESS in 17m 30s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/f0b61b9dc50842f3ab515f53b07d581c : SUCCESS in 33m 44s\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/54c706495eb54030a7d3366588ddd3fe : SUCCESS in 44m 23s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/6d17d0f2047a4f42b4c342e2b3b70317 : SUCCESS in 37m 13s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/4b5d6f3a5b6c4081aae8a10c4e11e2e4 : SUCCESS in 17m 34s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/bf5db77a56254d018fd195d55bf4a85a : SUCCESS in 40m 27s (non-voting)\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/20594d48a7744b31aa9d2282361f8fc9 : FAILURE in 1h 09m 32s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/2a914829694c4910be28d45406efd946 : SUCCESS in 56m 27s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/558b12cdf5404da5b2ed8b3ad1679adc : SUCCESS in 46m 16s","accounts_in_message":[],"_revision_number":12},{"id":"21703dc861cd4ef95a649485b5d917ba965b8501","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-09 12:03:35.000000000","message":"Patch Set 12:\n\nrecheck","accounts_in_message":[],"_revision_number":12},{"id":"1b511803921ba3faf1c68da818861fa03973a057","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-12-09 13:27:29.000000000","message":"Patch Set 12:\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/b4f79ece65884894aef21047277ca831 : SUCCESS in 28m 49s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/20f0be95185e471d8fb83ca488ff656c : SUCCESS in 14m 43s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/fff95a617b974504bde292b5225b313a : SUCCESS in 6m 25s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/40d95b429b39474fa566ecdd08d9bd7a : SUCCESS in 13m 39s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/f8d2f37d17724f5f8c1f4246e0837b21 : SUCCESS in 12m 52s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/3d29e0540be54309a821ae9b50e4b6e2 : SUCCESS in 12m 56s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/e70d8535ae514e14ae26cdde80bd6992 : SUCCESS in 1h 08m 54s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/cbcc301c47e14d34aead01cffff34d4e : SUCCESS in 1h 17m 57s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/fced9068af8046c9b1438126f0894f8e : SUCCESS in 17m 03s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/89c3763a3da04fca82e16955272771e9 : SUCCESS in 39m 11s\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/26d0d9538e3b4ae4ab51687a06d428e9 : SUCCESS in 38m 16s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/286f2b67fbfb430e8950abc81ad94a4d : SUCCESS in 39m 07s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/7905db1230c247d483f170f5b8af8255 : SUCCESS in 19m 43s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/b6ddac26ed544e8ebda147b92eff0bec : SUCCESS in 43m 05s (non-voting)\n- neutron-grenade https://zuul.opendev.org/t/openstack/build/2c4c60aa6d894aceba23e573f641ee04 : FAILURE in 1h 01m 53s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/e65f784ae1f8469cba542c2182f8b90c : SUCCESS in 1h 01m 38s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/79fb7b0f493b42de96645453fb706802 : SUCCESS in 39m 57s","accounts_in_message":[],"_revision_number":12},{"id":"b8ffd6a743542e3a2cfac0c626a8c8fa41db3ec6","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-10 18:52:06.000000000","message":"Patch Set 12:\n\n(3 comments)\n\nrecheck","accounts_in_message":[],"_revision_number":12},{"id":"db3d23de62d8a364238acc3940731b17ea3a9bee","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-11 19:08:02.000000000","message":"Uploaded patch set 13.","accounts_in_message":[],"_revision_number":13},{"id":"c11bf0ad484257c72a3f4a347740d238b50790d3","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-11 19:08:24.000000000","message":"Patch Set 13:\n\n(2 comments)","accounts_in_message":[],"_revision_number":13},{"id":"d8e456d9861506ed29746bbff30b1381f1c3c517","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-12-11 20:46:47.000000000","message":"Patch Set 13: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/5b5aaeba50614cd8bc251f9750c36500 : SUCCESS in 15m 38s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/693bc90b03f340fa9c102e7b920ecffe : SUCCESS in 14m 44s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/67347c01dfc748c4818ac2a3abbb89dd : SUCCESS in 5m 55s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/89d9bbcd64ab48478afffdafaa45d977 : SUCCESS in 13m 20s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/664bfe253dfe4133aae2385875cafdb2 : SUCCESS in 12m 03s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/67f15ac865014de98be59496343d24c4 : SUCCESS in 11m 51s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/52464634a67b4ff2a9e021974047930c : SUCCESS in 1h 06m 33s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/a425064cc1654163af228aa4414f16b0 : SUCCESS in 1h 32m 23s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/44159017a3c642b4aed39dad91e00035 : SUCCESS in 18m 18s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/baf17678894e411485c74bebc94fce6a : SUCCESS in 37m 11s\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/9b7f778519124cee857b7129ea58996d : SUCCESS in 38m 09s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/c636f50ac207415da6939a8be56fda9d : SUCCESS in 43m 05s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/aefffa8107a94049b3c131b008f0569a : SUCCESS in 17m 12s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/5ae6bebf10e140179c4c523e0774eed3 : SUCCESS in 46m 54s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/00264b4ef8cc484699e14eb8da82c1cc : SUCCESS in 1h 01m 49s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/4804a6a5870d4bb09a201b57565f19c6 : TIMED_OUT in 1h 01m 44s","accounts_in_message":[],"_revision_number":13},{"id":"22a6a48750199c273e331d7687ce61a7d879ba9f","author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"date":"2019-12-11 20:48:18.000000000","message":"Patch Set 13:\n\nrecheck","accounts_in_message":[],"_revision_number":13},{"id":"74a1dd41dd851e63d35aaf87e6a2e01ea0edbb57","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-12-11 22:15:36.000000000","message":"Patch Set 13: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/8e95cc3cc03a4ed1a966953905588227 : SUCCESS in 21m 11s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/04e11094414542d7af23cd525d0b8534 : SUCCESS in 19m 57s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/ac4179dbc74247a1a8d1d1f6c2632577 : SUCCESS in 7m 27s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/09460bbae4074466bb662747281d8b5d : SUCCESS in 17m 48s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/25a8f2039d7d42f1b6fa4416310a8de3 : SUCCESS in 23m 02s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/97879c7ab848460eae5db0c21f54d342 : SUCCESS in 12m 45s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/a757604157d748a3ad80604265266eb8 : SUCCESS in 1h 00m 13s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/41bc42edc6724d77b4684a359ef8eb3e : SUCCESS in 1h 24m 50s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/209512f4cf2a413ca5bdb1db61e161f5 : SUCCESS in 15m 36s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/c26851e3c2ba46e8af77db84628ee399 : SUCCESS in 32m 31s\n- keystone-dsvm-py3-functional-federation-opensuse15 https://zuul.opendev.org/t/openstack/build/1b4fffb3002746df9ffb9e394b28a643 : SUCCESS in 38m 11s (non-voting)\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/f0f80c8c2cc44422ab4c0307f7d1c972 : SUCCESS in 43m 18s\n- keystoneclient-devstack-functional https://zuul.opendev.org/t/openstack/build/f0071332dfe2442093ebe2733ca08566 : SUCCESS in 15m 31s (non-voting)\n- keystone-dsvm-ldap-domain-specific-driver https://zuul.opendev.org/t/openstack/build/0bfe59776fff4d1dabd6bd2db35fad81 : SUCCESS in 43m 24s (non-voting)\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/063163dc2c3e4eaba63f99105c98389e : SUCCESS in 1h 07m 30s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/dffed01398ad452db09587a144050983 : SUCCESS in 38m 11s","accounts_in_message":[],"_revision_number":13},{"id":"6023c632704d677942fee42ac5306230af665269","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-11 23:06:37.000000000","message":"Patch Set 13: Code-Review+2","accounts_in_message":[],"_revision_number":13},{"id":"21117578bcbb6b16eb952c72c7a10c9f163cf8c2","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2019-12-11 23:06:43.000000000","message":"Patch Set 13:\n\nThanks!","accounts_in_message":[],"_revision_number":13},{"id":"88eab7464360cc9df8667a8cdb0547b4d80e9b21","author":{"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"},"date":"2019-12-17 08:53:41.000000000","message":"Patch Set 13: Code-Review+2","accounts_in_message":[],"_revision_number":13},{"id":"5ff1854b82a436ab9f78b3165303f4ce9469b483","author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"date":"2020-04-20 18:54:49.000000000","message":"Patch Set 13: Workflow+1","accounts_in_message":[],"_revision_number":13},{"id":"e47d74123e196eab24cf47f43591796aec76fd62","tag":"autogenerated:zuul:gate","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-20 18:55:34.000000000","message":"Patch Set 13: -Verified\n\nStarting gate jobs.","accounts_in_message":[],"_revision_number":13},{"id":"ce354d78a67fcf6faf8bedb54fee63a62353ebb0","tag":"autogenerated:zuul:gate","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-20 20:34:42.000000000","message":"Patch Set 13: Verified+2\n\nBuild succeeded (gate pipeline).\n\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/12f0bcc4e8f1476fa3f39ff3a97777d5 : SUCCESS in 41m 00s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/adbd27cf28a84d5e8530ff08d5297a2f : SUCCESS in 6m 15s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/015cceb6bad64c3ab13fb0a13846e777 : SUCCESS in 14m 25s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/acd1f7a709df4e02ac5753ef98aea542 : SUCCESS in 13m 51s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/b626f0b89e024443b043d6f6362f6db5 : SUCCESS in 16m 41s\n- grenade-py3 https://zuul.opendev.org/t/openstack/build/63bca79f611549828823ae0d89cc8634 : SUCCESS in 1h 13m 06s\n- tempest-full-py3 https://zuul.opendev.org/t/openstack/build/ff0e2a5e6f10436d806cb8764a06b92d : SUCCESS in 1h 32m 37s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/9458c6d873434c7c8fd5eedb56397089 : SUCCESS in 17m 44s\n- keystone-dsvm-py3-functional https://zuul.opendev.org/t/openstack/build/5786f7c920ea4f6fb38a1b3560a12da2 : SUCCESS in 39m 15s\n- keystone-dsvm-py3-functional-federation-opensuse15-k2k https://zuul.opendev.org/t/openstack/build/d6777b2264954aeeb360c725c0d13271 : SUCCESS in 35m 31s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/5c0d019f417548bca3627a81c1a9e9e5 : SUCCESS in 1h 01m 55s\n- keystone-tox-protection https://zuul.opendev.org/t/openstack/build/6abde71198f14a26a9461002a80f74c7 : SUCCESS in 49m 48s","accounts_in_message":[],"_revision_number":13},{"id":"d218958101d7740e92ff8ab6f72f132c5ae24a81","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-20 20:34:42.000000000","message":"Change has been successfully merged by Zuul","accounts_in_message":[],"_revision_number":13},{"id":"b32e0fdb9d62317072702368ef90b304856e88ae","tag":"autogenerated:zuul:promote","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-20 20:37:05.000000000","message":"Patch Set 13:\n\nBuild succeeded (promote pipeline).\n\n- promote-openstack-tox-docs https://zuul.opendev.org/t/openstack/build/559acc8a899a47e6ac55f00249a67304 : SUCCESS in 1m 55s\n- promote-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/4770afee64c44fac8e547cafe04dd578 : SUCCESS in 1m 28s","accounts_in_message":[],"_revision_number":13},{"id":"9c79c76d77291ddc7a1605c865c0cf1ec54ed3ff","author":{"_account_id":31750,"name":"Daniel Meloy","email":"danny.meloy@bbc.co.uk","username":"meloyd01"},"date":"2020-07-15 13:49:26.000000000","message":"Patch Set 13: Cherry Picked\n\nThis patchset was cherry picked to branch stable/train as commit 84a6f60e5c172925984f1fe74e603509a2e07caa","accounts_in_message":[],"_revision_number":13}],"current_revision_number":13,"current_revision":"7597ecc1350eb6918c09585e4116911102acb54a","revisions":{"f426eefb8f2ad6b24ffb1976b75a07a06fe595dd":{"kind":"REWORK","_number":1,"created":"2019-10-10 21:54:07.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/1"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 21:43:55.000000000","tz":-180},"subject":"Validate federated users when updating attributes.","message":"Validate federated users when updating attributes.\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a federated user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nTo fix the persistence in the local_user table for federated\nusers when doing updates is not ideal. I think that the update\nfor federated user\u0027s attributes must not be allowed via\nOpenStack.In a federated environment, the responsibility for\nmanaging the user attributes must be delegated to the Identity\nProvider. Therefore, there is no reason to allow updating\nfederated users\u0027 attributes directly via OpenStack as if they\nwere local users. If users need to change something in their\nattributes, they must do that in the Identity Provider.\nIf some admin desires to change some federated user\u0027s\nattribute, then he/she needs to ask for the user to change that\nin the Idp or request the Idp to do that for her/him. It is the\nresponsibility of the Identity Provider to maintain the\nfederated user\u0027s attributes updated, not OpenStack\u0027s.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to validate users while updating users\u0027 attributes;\nif the user is federated, then we throw an error, otherwise,\nmaintain the current behavior (which means, allowing the\nupdate of local users data).\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/f426eefb8f2ad6b24ffb1976b75a07a06fe595dd"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/f426eefb8f2ad6b24ffb1976b75a07a06fe595dd"}]},"branch":"refs/heads/master"},"9674d78f7703070b18a3d8c84482e734dc125f5e":{"kind":"REWORK","_number":2,"created":"2019-10-11 12:08:37.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/2"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-11 12:07:43.000000000","tz":-180},"subject":"Validate federated users when updating attributes.","message":"Validate federated users when updating attributes.\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a federated user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nTo fix the persistence in the local_user table for federated\nusers when doing updates is not ideal. I think that the update\nfor federated user\u0027s attributes must not be allowed via\nOpenStack.In a federated environment, the responsibility for\nmanaging the user attributes must be delegated to the Identity\nProvider. Therefore, there is no reason to allow updating\nfederated users\u0027 attributes directly via OpenStack as if they\nwere local users. If users need to change something in their\nattributes, they must do that in the Identity Provider.\nIf some admin desires to change some federated user\u0027s\nattribute, then he/she needs to ask for the user to change that\nin the Idp or request the Idp to do that for her/him. It is the\nresponsibility of the Identity Provider to maintain the\nfederated user\u0027s attributes updated, not OpenStack\u0027s.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to validate users while updating users\u0027 attributes;\nif the user is federated, then we throw an error, otherwise,\nmaintain the current behavior (which means, allowing the\nupdate of local users data).\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/9674d78f7703070b18a3d8c84482e734dc125f5e"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/9674d78f7703070b18a3d8c84482e734dc125f5e"}]},"branch":"refs/heads/master"},"6a1029d1fef99cbfd8fa0becba4941b67b85829d":{"kind":"REWORK","_number":3,"created":"2019-10-11 19:29:03.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/3"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-11 19:28:23.000000000","tz":-180},"subject":"Remove duplicated entries from users API","message":"Remove duplicated entries from users API\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nWhen I use the Keystone `users` API, if I add the filter `name`\nin the request, and the name passed in the request is from a\nfederated user, I get duplicated entries for the same users, one\nthat comes from the local_user table and another from\nfederated_user, both with the same user_id and data.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to filter duplicated users by id from the shadow_user\nhandler returned list.\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/6a1029d1fef99cbfd8fa0becba4941b67b85829d"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/6a1029d1fef99cbfd8fa0becba4941b67b85829d"}]},"branch":"refs/heads/master"},"f121ed852214c27c1ec6d0221617b0cb827c00a9":{"kind":"REWORK","_number":4,"created":"2019-10-13 00:20:14.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/4","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/4","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/4"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-13 00:19:16.000000000","tz":-180},"subject":"Remove duplicated entries from users API","message":"Remove duplicated entries from users API\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nWhen I use the Keystone `users` API, if I add the filter `name`\nin the request, and the name passed in the request is from a\nfederated user, I get duplicated entries for the same users, one\nthat comes from the local_user table and another from\nfederated_user, both with the same user_id and data.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to filter duplicated users by id from the shadow_user\nhandler returned list.\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/f121ed852214c27c1ec6d0221617b0cb827c00a9"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/f121ed852214c27c1ec6d0221617b0cb827c00a9"}]},"branch":"refs/heads/master"},"308ca242436f9eac86ac6e4b42e4c7fd690b6ef6":{"kind":"NO_CODE_CHANGE","_number":5,"created":"2019-10-16 13:26:59.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/5","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/5","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/5"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-16 13:25:35.000000000","tz":-180},"subject":"Remove duplicated entries from users API","message":"Remove duplicated entries from users API\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nWhen I use the Keystone `users` API, if I add the filter `name`\nin the request, and the name passed in the request is from a\nfederated user, I get duplicated entries for the same users, one\nthat comes from the local_user table and another from\nfederated_user, both with the same user_id and data.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to filter duplicated users by id from the shadow_user\nhandler returned list.\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/308ca242436f9eac86ac6e4b42e4c7fd690b6ef6"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/308ca242436f9eac86ac6e4b42e4c7fd690b6ef6"}]},"branch":"refs/heads/master"},"f5ad3cc14a9f85de34e30abe5e089bac83f0f9f5":{"kind":"REWORK","_number":6,"created":"2019-10-17 21:36:04.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/6","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/6","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/6"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-17 21:35:06.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates. Also, I think that the update\nfor ephemeral user\u0027s attributes must not be allowed via\nOpenStack.In a federated environment, the responsibility for\nmanaging the user attributes must be delegated to the Identity\nProvider. Therefore, there is no reason to allow updating\nephemeral users\u0027 attributes directly via OpenStack as if they\nwere local users. If users need to change something in their\nattributes, they must do that in the Identity Provider.\nIf some admin desires to change some ephemeral user\u0027s\nattribute, then he/she needs to ask for the user to change that\nin the Idp or request the Idp to do that for her/him. It is the\nresponsibility of the Identity Provider to maintain the\nfederated user\u0027s attributes updated, not OpenStack\u0027s.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to validate users while updating users\u0027 attributes;\nif the user is ephemeral, then we throw an error, otherwise,\nmaintain the current behavior (which means, allowing the\nupdate of local users data).\n\nAlso I fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/f5ad3cc14a9f85de34e30abe5e089bac83f0f9f5"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/f5ad3cc14a9f85de34e30abe5e089bac83f0f9f5"}]},"branch":"refs/heads/master"},"8c4d50d1b715028066b74fc5edacfd0c124195f2":{"kind":"REWORK","_number":7,"created":"2019-10-18 02:01:41.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/7","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/7","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/7"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-18 02:00:15.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates. Also, I think that the update\nfor ephemeral user\u0027s attributes must not be allowed via\nOpenStack.In a federated environment, the responsibility for\nmanaging the user attributes must be delegated to the Identity\nProvider. Therefore, there is no reason to allow updating\nephemeral users\u0027 attributes directly via OpenStack as if they\nwere local users. If users need to change something in their\nattributes, they must do that in the Identity Provider.\nIf some admin desires to change some ephemeral user\u0027s\nattribute, then he/she needs to ask for the user to change that\nin the Idp or request the Idp to do that for her/him. It is the\nresponsibility of the Identity Provider to maintain the\nfederated user\u0027s attributes updated, not OpenStack\u0027s.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to validate users while updating users\u0027 attributes;\nif the user is ephemeral, then we throw an error, otherwise,\nmaintain the current behavior (which means, allowing the\nupdate of local users data).\n\nAlso I fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/8c4d50d1b715028066b74fc5edacfd0c124195f2"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/8c4d50d1b715028066b74fc5edacfd0c124195f2"}]},"branch":"refs/heads/master"},"a443361ba6358cdfd228b8083176474b53c010e5":{"kind":"REWORK","_number":8,"created":"2019-10-22 19:46:05.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/8","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/8","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/8"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"pedro","email":"phpm13@gmail.com","date":"2019-10-22 19:45:18.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates. Also, I think that the update\nfor ephemeral user\u0027s attributes must not be allowed via\nOpenStack.In a federated environment, the responsibility for\nmanaging the user attributes must be delegated to the Identity\nProvider. Therefore, there is no reason to allow updating\nephemeral users\u0027 attributes directly via OpenStack as if they\nwere local users. If users need to change something in their\nattributes, they must do that in the Identity Provider.\nIf some admin desires to change some ephemeral user\u0027s\nattribute, then he/she needs to ask for the user to change that\nin the Idp or request the Idp to do that for her/him. It is the\nresponsibility of the Identity Provider to maintain the\nfederated user\u0027s attributes updated, not OpenStack\u0027s.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to validate users while updating users\u0027 attributes;\nif the user is ephemeral, then we throw an error, otherwise,\nmaintain the current behavior (which means, allowing the\nupdate of local users data).\n\nAlso I fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/a443361ba6358cdfd228b8083176474b53c010e5"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/a443361ba6358cdfd228b8083176474b53c010e5"}]},"branch":"refs/heads/master"},"db8a72a8f74869054fc9957dfa0d4c99b5ca52fc":{"kind":"REWORK","_number":9,"created":"2019-10-28 17:51:37.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/9","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/9","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/9"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"pedro","email":"phpm13@gmail.com","date":"2019-10-28 17:49:11.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates. Also, I think that the update\nfor ephemeral user\u0027s attributes must not be allowed via\nOpenStack.In a federated environment, the responsibility for\nmanaging the user attributes must be delegated to the Identity\nProvider. Therefore, there is no reason to allow updating\nephemeral users\u0027 attributes directly via OpenStack as if they\nwere local users. If users need to change something in their\nattributes, they must do that in the Identity Provider.\nIf some admin desires to change some ephemeral user\u0027s\nattribute, then he/she needs to ask for the user to change that\nin the Idp or request the Idp to do that for her/him. It is the\nresponsibility of the Identity Provider to maintain the\nfederated user\u0027s attributes updated, not OpenStack\u0027s.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI propose to validate users while updating users\u0027 attributes;\nif the user is ephemeral, then we throw an error, otherwise,\nmaintain the current behavior (which means, allowing the\nupdate of local users data).\n\nAlso I fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/db8a72a8f74869054fc9957dfa0d4c99b5ca52fc"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/db8a72a8f74869054fc9957dfa0d4c99b5ca52fc"}]},"branch":"refs/heads/master"},"104b925e67d0fea610939c4ecef1c663c6025939":{"kind":"REWORK","_number":10,"created":"2019-12-05 13:22:44.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/10","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/10","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/10"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"pedro","email":"phpm13@gmail.com","date":"2019-12-05 13:22:14.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/104b925e67d0fea610939c4ecef1c663c6025939"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/104b925e67d0fea610939c4ecef1c663c6025939"}]},"branch":"refs/heads/master"},"72c9d9abcfde2153609d60ba9a72c1c5d9c03a66":{"kind":"REWORK","_number":11,"created":"2019-12-06 14:09:56.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/11","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/11","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/11"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"pedro","email":"phpm13@gmail.com","date":"2019-12-06 14:08:11.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/72c9d9abcfde2153609d60ba9a72c1c5d9c03a66"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/72c9d9abcfde2153609d60ba9a72c1c5d9c03a66"}]},"branch":"refs/heads/master"},"5ba6f1e82da5653bb2e2458a102ad2f914e9e267":{"kind":"REWORK","_number":12,"created":"2019-12-06 14:25:29.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/12","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/12","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/12"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"pedro","email":"phpm13@gmail.com","date":"2019-12-06 14:24:42.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/5ba6f1e82da5653bb2e2458a102ad2f914e9e267"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/5ba6f1e82da5653bb2e2458a102ad2f914e9e267"}]},"branch":"refs/heads/master"},"7597ecc1350eb6918c09585e4116911102acb54a":{"kind":"REWORK","_number":13,"created":"2019-12-11 19:08:02.000000000","uploader":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"ref":"refs/changes/90/687990/13","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/keystone","ref":"refs/changes/90/687990/13","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/keystone refs/changes/90/687990/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/keystone refs/changes/90/687990/13"}}},"commit":{"parents":[{"commit":"ccb080867bddfeb744f97076d44d4e47b67ffe08","subject":"Merge \"Add schema placeholders for Train\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/ccb080867bddfeb744f97076d44d4e47b67ffe08"}]}],"author":{"name":"Pedro Martins","email":"phpm13@gmail.com","date":"2019-10-10 11:51:32.000000000","tz":-180},"committer":{"name":"pedro","email":"phpm13@gmail.com","date":"2019-12-11 19:07:06.000000000","tz":-180},"subject":"Stop adding entry in local_user while updating ephemerals","message":"Stop adding entry in local_user while updating ephemerals\n\nProblem description\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nToday we have a consistency problem when updating federated\nusers via OpenStack. When I update a ephemeral user via OpenStack,\na registry in the local_user table is created, making this user\nhaving entries in user, local_user and federated_user tables in\nthe database.\n\nFurthermore, if I try to do some operations using this user\n(that has entries in all three tables), I get a \"More than one\nuser exists with the name ...\" error from the OpenStack\nKeystone API. It happens because the user has an entry in both\nlocal_user and federated_user tables.\n\nI fix the persistence in the local_user table for ephemeral\nusers when doing updates.\n\nProposal\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nI fix the problem with creating an entry in the\nlocal_user table while updating an ephemeral user\n\nCloses-Bug: #1848342\n\nChange-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/7597ecc1350eb6918c09585e4116911102acb54a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/keystone/commit/7597ecc1350eb6918c09585e4116911102acb54a"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}