get_secret and delete_secret in key_manager always fail with 404

[Douglas Mendizábal]

The key_manager methods to retrieve a secret, and to delete a secret always fail with 404 for existing secrets. Consider the following sample code:

    from openstack import profile
    from openstack import connection

    prof = profile.Profile()
    prof.set_region('key-manager', 'IAD')

    conn = connection.Connection(auth_url='https://identity.api.rackspacecloud.com/v2.0',
                                 username='my_username',
                                 password='PA$$W0rD',
                                 profile=prof)

    my_secret = conn.key_manager.create_secret(secret_type='passphrase',
                                              payload='foobar',
                                              payload_content_type='text/plain')

    # my_secret has been successfully created in the service at this point

    retrieved_secret = conn.key_manager.get_secret(my_secret) # raises ResourceNotFound

    conn.key_manager.delete_secret(my_secret, ignore_missing=True) # also raises ResourceNotFound

The expected behavior is that get_secret and delete_secret should succeed since the secret is successfully created with create_secret.

[Douglas Mendizábal (dougmendizabal)]

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.

[Brian Curtin (brian.curtin)]

Yeah this is something I was looking around with before but hadn't finished it. Barbican mostly needs its own Resource subclass due to how differently it works.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/379594

[Douglas Mendizábal (dougmendizabal)]

Brian,

I wrote a unit test for _alternate_id() that shows the issue that is causing this bug. [1] The current implementation of key_manager.v1.secret.Secret assumes this unit test would pass, but I'm not sure if that's how alternate ids are supposed to work because of the comment on the 'secret_id' property. [2]

[1] https://review.openstack.org/#/c/379594
[2] http://git.openstack.org/cgit/openstack/deb-python-openstacksdk/tree/openstack/key_manager/v1/secret.py#n58

[Brian Curtin (brian.curtin)]

Yeah we need a bunch of work here, and I'll probably get to it after what I'm wrapping up now. That secret_ref not being an actual ID ruins everything so the temporary fix is probably not right. I don't really care to work on it as-is though, since we probably need to implement something that intercepts the setting/getting of an id-related attribute to convert it from a URI into just an ID so that we can use it when constructing other calls.

[Douglas Mendizábal (dougmendizabal)]

Brian, I understand you have other priorities, which is why I assigned this bug to myself as I would like to contribute a patch to fix this bug. I apologize if that was unclear. What I would like to know is if the unit test I submitted in the above patch is what you were expecting when you wrote the workaround. If so, then I don't think the fix is going to require much work at all.

I also sense some frustration on your part because of the way the current Barbican API handles IDs (or doesn't have the usual UUID IDs rather). I think it would make sense for Barbican to have an API that is more in-line with the rest of OpenStack so I've added a note to fix this in a future /v2 api. [1]

[1] https://wiki.openstack.org/wiki/Barbican/v2

[Douglas Mendizábal (dougmendizabal)]

WORKAROUND:

For now you can retrieve secrets by using the secret.secret_id property.

    retrieved_secret = conn.key_manager.get_secret(my_secret.secret_id)

works as expected.