Update patch set 16

Patch Set 16:

(1 comment)

Patch-set: 16
CC: Gerrit User 14250 <14250@4a232e18-c5a9-48ee-94c0-e04e7cca6543>
Attention: {"person_ident":"Gerrit User 27900 \u003c27900@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_14250\u003e replied on the change"}

43559b813528604c247f67258e9f6daa81566bb8

@@ -105,6 +105,24 @@
       "parentUuid": "8e8310d2_2b4416c8",
       "revId": "43559b813528604c247f67258e9f6daa81566bb8",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "aa9138f2_faba1eec",
+        "filename": "specs/keystone/2024.1/federated-identity-mapping-support-project-json-definition.rst",
+        "patchSetId": 16
+      },
+      "lineNbr": 103,
+      "author": {
+        "id": 14250
+      },
+      "writtenOn": "2024-04-19T15:34:11Z",
+      "side": 1,
+      "message": "My thinking is, that when migrating to the new format, the procedure would look something like:\n1. introduce the new format, so you have both formats as input to keystone\n2. run an additional instance of keystone, with the new mapping\n3. test both old and new instances, comparing results\n4. if the new instance is working as expected, switch to it, updating the mapping configuration\n5. safely remove the old format, since it\u0027s no longer read by keystone\n\nFrom this perspective, having an enforced either/or choice would make things less ambiguous with just one transition path (like the one above). Having a mapping with both, and adding the resulting mapped projects seems more complicated and thus error prone. I don\u0027t see a use case for this additional in-between stage during the transition.",
+      "parentUuid": "dfe92991_859c9a04",
+      "revId": "43559b813528604c247f67258e9f6daa81566bb8",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
     }
   ]
 }