)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"2f4d4528c30f47f8a1e854ebf116c0c86f6a5c2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"40131e8d_9034573a","updated":"2026-08-24 16:23:30.000000000","message":"Before going into the details, lets talk about the motivation behind this spec and the behavior we are trying to achieve.\n\nThe case I\u0027m envisioning is one where someone has accidentally deleted a secret - lets say, an encryption key generated\nby cinder or glance, for instance.  In this case, the secret has likely been deleted from the backend, and, unless a purge operation\nhas been executed on the barbican database, the secret record exists as a tombstone.  Moreover, unless they have been purged, many of\nthe objects associated with the secret - metadata, container secrets, consumers - still exist in the database in tombstone\nform.\n\nIt is therefore possible, if we implement this correctly, to revive all the relevant tombstones along with the secret itself.\nIf we are lucky, then services using the secret will be able to continue to do so without having to recreate consumers, containers etc.\nPurging and then re-inserting the record, on the other hand, will remove all of the consumers, container membership etc. and will\nrequire all the services to recreate these to use them as before.\n\nSo, I\u0027m imagining all of the following scenarios.\n\n1. POST id\u003dX recover\u003dtrue - if tombstone exists, revive the tombstone and all the associate object tombstones.\n2. POST id-X recover\u003dtrue - no tombstone - nothing to revive, throw error (409)\n3. POST id\u003dX recover\u003dfalse - if tombstone exist, don\u0027t try to recover.  purge and re-insert.\n4. POST id\u003dX recover\u003dfalse - no tombstone, go ahead and create a new secret with id\u003dX\n \nScenarios 3 and 4 are what you described in your original spec.  Scenarios 1 and 2 are new - but I would argue, could be \ncloser to what an admin might want when doing a DR.","commit_id":"00b5564c4cd801177b5152102e32d8beb9d03373"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"70f35787bd0986a87417dfb9f5c37efe37fa949c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"77b91eee_e71d0415","updated":"2026-08-19 21:58:45.000000000","message":"Thanks for the spec.  It looks pretty good mostly.  I\u0027m very interested in getting this landed soon,","commit_id":"00b5564c4cd801177b5152102e32d8beb9d03373"},{"author":{"_account_id":32624,"name":"Rajiv Mucheli","email":"rajiv.mucheli@gmail.com","username":"rajivmucheli"},"change_message_id":"d9ce96c1189140cab7702e0dd5627540c53912e7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"45c2f622_3cd831e9","in_reply_to":"40131e8d_9034573a","updated":"2026-08-27 16:27:31.000000000","message":"Hi Ade,\n\nIndeed, my usecase is to allow to restore a secret when its accidentally deleted.\n\nI am fine with scenaior 3 \u0026 4 as well, should i update the spec ?","commit_id":"00b5564c4cd801177b5152102e32d8beb9d03373"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"358fbfc42e6a265f361bed72f1eb932917bf9e78","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"7cb3c300_b044f0f3","updated":"2026-09-15 20:33:17.000000000","message":"Looks good, Rajiv.  Just a couple points as noted.\n\nAlso, this should probably be 2026.2 at this point.","commit_id":"fb45c7d3113a69ad445ee91a6a892e47b4e7d6ac"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"c480968ba21716ff449e1c87213ecb47e78d550a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"ac745cea_a7fb67ec","updated":"2026-09-17 16:53:50.000000000","message":"Looking pretty good.\n\nI\u0027m not +2 yet because I think we need to bump the microversion.  Barbican\u0027s docs - doc/source/contributor/microversions.txt explicitly say that a change in the contract between clients and servers should add a microversion.\n\nEven though we don\u0027t need one for backward compatibility (as we\u0027re adding new fields), the new microversion allows clients to determine whether the functionality is available in the server or not.","commit_id":"b5a9292e5e71c426cfa646fa4488087e88101424"}],"specs/2026.1/allow-custom-secret-uuid.rst":[{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"70f35787bd0986a87417dfb9f5c37efe37fa949c","unresolved":true,"context_lines":[{"line_number":94,"context_line":"3. If an *active* row with ``id \u003d U`` already exists in *P*\u0027s scope, the"},{"line_number":95,"context_line":"   request is rejected with **409 Conflict** and a precise error body"},{"line_number":96,"context_line":"   (``SecretIdConflict``).  The pre-existing row is untouched."},{"line_number":97,"context_line":"4. If a *soft-deleted* row with ``id \u003d U`` exists in *P*\u0027s scope, the"},{"line_number":98,"context_line":"   soft-deleted row is hard-purged inside a nested transaction"},{"line_number":99,"context_line":"   (``SAVEPOINT``) as a prerequisite for the insert, an audit entry is"},{"line_number":100,"context_line":"   emitted at WARNING level, and the insert proceeds."},{"line_number":101,"context_line":"5. If ``U`` collides with a row belonging to *a different project*, the"},{"line_number":102,"context_line":"   request is rejected with **409 Conflict** and a *generic* error body"},{"line_number":103,"context_line":"   (``SecretIdNotAvailable``) that leaks neither the owning project nor"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b9758299_5feac1c8","line":100,"range":{"start_line":97,"start_character":3,"end_line":100,"end_character":53},"updated":"2026-08-19 21:58:45.000000000","message":"This operation is essentially the equivalent of a hard-delete and a create of a new secret.  Thats OK if the user requesting this has the permissions to delete the secret.\n\nIn general, secrets are \"owned\" by the project and any member of the project can read and delete a secret owned by the project.  But we also have the ability to set a secret as private - which makes that secret readable and deletable only by the user that created the secret.\n\nAllowing this hard purge by any member of the project would break private secrets if that member did not initially create the secret.\n\nWhile this is a nice convenience, it also makes the audit trail more confusing.\n\nOne way to avoid this scenario is simply to return a 409.  That will force the user to explicitly delete the existing secret (if they can) before moving forward, and make the audit trail easier to follow.","commit_id":"00b5564c4cd801177b5152102e32d8beb9d03373"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"1c0069390fa70e985e149a3548cae4b40c777d81","unresolved":true,"context_lines":[{"line_number":94,"context_line":"3. If an *active* row with ``id \u003d U`` already exists in *P*\u0027s scope, the"},{"line_number":95,"context_line":"   request is rejected with **409 Conflict** and a precise error body"},{"line_number":96,"context_line":"   (``SecretIdConflict``).  The pre-existing row is untouched."},{"line_number":97,"context_line":"4. If a *soft-deleted* row with ``id \u003d U`` exists in *P*\u0027s scope, the"},{"line_number":98,"context_line":"   soft-deleted row is hard-purged inside a nested transaction"},{"line_number":99,"context_line":"   (``SAVEPOINT``) as a prerequisite for the insert, an audit entry is"},{"line_number":100,"context_line":"   emitted at WARNING level, and the insert proceeds."},{"line_number":101,"context_line":"5. If ``U`` collides with a row belonging to *a different project*, the"},{"line_number":102,"context_line":"   request is rejected with **409 Conflict** and a *generic* error body"},{"line_number":103,"context_line":"   (``SecretIdNotAvailable``) that leaks neither the owning project nor"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1b982df7_87765925","line":100,"range":{"start_line":97,"start_character":3,"end_line":100,"end_character":53},"in_reply_to":"b9758299_5feac1c8","updated":"2026-08-20 21:33:26.000000000","message":"Actually, that won\u0027t work and there are issues with handling consumers and container secrets.  But I\u0027ll post more later today.","commit_id":"00b5564c4cd801177b5152102e32d8beb9d03373"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"358fbfc42e6a265f361bed72f1eb932917bf9e78","unresolved":true,"context_lines":[{"line_number":76,"context_line":"that the consumer already recorded is the minimum-blast-radius recovery"},{"line_number":77,"context_line":"path."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"The goal is to restore not just the UUID, but the *full set of associations*"},{"line_number":80,"context_line":"-- consumers, container-secret memberships, ACLs, user metadata -- so that"},{"line_number":81,"context_line":"services like Cinder, Glance, and Octavia can continue to use the secret"},{"line_number":82,"context_line":"without any change to their state."},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"6af3bbc6_60ff0888","line":80,"range":{"start_line":79,"start_character":0,"end_line":80,"end_character":64},"updated":"2026-09-15 20:33:17.000000000","message":"I\u0027m not sure I quite understand the use case here.  In this case, the DB restore has no record of any secrets past the restore point.  So there are no tombstones -either of the secret or of any associations that might have been created.\n\nRecovering the secrets by the old UUID will help in cases where there were no other associations, but it will be incomplete for those that had associations.  That said, its probably the best we can do.\n\nFunctionally, its equivalent to a recovery after a hard purge of the tombstones.","commit_id":"fb45c7d3113a69ad445ee91a6a892e47b4e7d6ac"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"358fbfc42e6a265f361bed72f1eb932917bf9e78","unresolved":true,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"* ``id`` (string) -- a canonical lowercase RFC 4122 v4 UUID to use as the"},{"line_number":91,"context_line":"  new row\u0027s primary key instead of one generated server-side."},{"line_number":92,"context_line":"* ``recover`` (boolean, default ``false``) -- when ``true`` and ``id`` names"},{"line_number":93,"context_line":"  a soft-deleted tombstone in the caller\u0027s project, revive that tombstone"},{"line_number":94,"context_line":"  instead of inserting a fresh row.  Only meaningful when ``id`` is also"},{"line_number":95,"context_line":"  supplied; ignored otherwise."}],"source_content_type":"text/x-rst","patch_set":2,"id":"e6ed9fdd_350f4aac","line":92,"range":{"start_line":92,"start_character":32,"end_line":92,"end_character":40},"updated":"2026-09-15 20:33:17.000000000","message":"I wonder whether we should default recover to true.  The reason is that if there is a tombstone, then setting recover\u003dfalse as the default means that we are selecting the destructive (\"purge\") option by default.\n\nrecover\u003dfalse on the other hand, basically says \"I don\u0027t care what was there before - purge and replace the contents\".  That seems like something that you should explicitly opt into.","commit_id":"fb45c7d3113a69ad445ee91a6a892e47b4e7d6ac"}]}