Some objects are not deleted after functional test
Bug #1638018 reported by
Jeremy Liu
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
castellan |
In Progress
|
Undecided
|
Pavlo Shchelokovskyy |
Bug Description
When running functional test, the generated orders and containers are not deleted.
Changed in castellan: | |
assignee: | nobody → Pavlo Shchelokovskyy (pshchelo) |
To post a comment you must log in.
I'd like to bump this very old issue with some comments and ideas.
What is happening is the following:
- the castellan Python API consumer calls 'create_key' or 'create_key_pair'
- castellan creates an order, in case of key pair also a container is being created
- castellan returns to the caller only the IDs of created secrets
As a result, the API consumer is not aware that any intermediate entities were created (orders, containers) and thus is not aware that when time comes to delete those secrets, those orders and containers should be deleted as well.
This results in orders and containers piling up, and what's more, even those deleted (soft-deleted) secrets can not be purged from the Barbican DB during maintenance as they are still referenced by the not yet deleted orders and containers. Also, possible existing quotas for orders and containers are being exhausted and cause unexpected problems when trying to 'create a secret'. This sutuation is most pronounced when castellan API callers are themselves automated systems like Nova or Cinder,
where the end user may not even be aware about any interaction with Barbican at all, user is just creating an encrypted volume, or an instance that happens to use encrypted local ephemeral storage in Nova.
So my idea would be the following:
if we assume that user is only ever interested in the secrets themselves, castellan should itself delete results of any intermediate steps taken to create those secrets, properly hiding any gory details of implementation from the user.