Comment 1 for bug 1628957

I dug around the source tree for a bit, and these failures are due to an error when preparing the URL used in the GET /v1/secrets/UUID and DELETE /v1/secrets/UUID requests. Since Barbican objects don't have an 'id' property, the current implementation uses a workaround that sets a new 'secret_id' property on the Secret class that is set to be an alternate_id.

However, there is a subtle detail in the logic that uses alternate_id properties that makes the 'secret_id' property not work as intended. This results in the prepared URLs being set to /v1/secrets/SECRET_REF_URL which results in a 404.