Open Stack

> nobody is calling Barbican "a database". It is a place to store

Š did you at least feel a heavy sense of irony as you typed those two
statements?  ³It¹s not a database, it just stores things!²  :-)

The real irony here is that in this rather firm stand of keeping the user
in control of their secrets, you are actually making the user LESS in
control of their secrets.  Copies of secrets will have to be made, whether
stored under another tenant, or shadow copied somewhere.  And the user
will have no way to delete them, or even know that they exist.

The force flag would eliminate the common mistake cases enough that I¹d
wager lbaas and most others would cease to worry, not duplicate, and just
reference barbican id¹s and nothing else.  (Not including backends that
will already make a copy of the secret, but things like servicevm will not
need to dup it.)  The earlier assertion that we have to deal with the
missing secrets case even with a force flag is, I think, false, because
once the common errors have been eliminated, the potential window of
accidental pain is reduced to those that really ask for it.

Thanks,
Doug






On 6/16/14, 1:56 PM, "Clint Byrum" <clint at fewbar.com> wrote:

>Excerpts from Doug Wiegley's message of 2014-06-10 14:41:29 -0700:
>> Of what use is a database that randomly delete rows?  That is, in
>>effect, what you¹re allowing.
>> 
>> The secrets are only useful when paired with a service.  And unless I¹m
>>mistaken, there¹s no undo.  So you¹re letting users shoot themselves in
>>the foot, for what reason, exactly?  How do you expect openstack to rely
>>on a data store that is fundamentally random at the whim of users?
>>Every single service that uses Barbican will now have to hack in a
>>defense mechanism of some kind, because they can¹t trust that the secret
>>they rely on will still be there later.  Which defeats the purpose of
>>this mission statement:  "Barbican is a ReST API designed for the secure
>>storage, provisioning and management of secrets.²
>> 
>> (And I don¹t think anyone is suggesting that blind refcounts are the
>>answer.  At least, I hope not.)
>> 
>> Anyway, I hear this has already been decided, so, so be it.  Sounds
>>like we¹ll hack around it.
>> 
>
>
>Doug, nobody is calling Barbican "a database". It is a place to store
>secrets.
>
>The idea is to loosely couple things, and if you need more assurances,
>use something like Heat to manage the relationships.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev