Open Stack

On Jun 16, 2014, at 3:22 PM, Doug Wiegley <dougw at a10networks.com> wrote:

>> 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.
> 

    The force flag is not an option and should no longer be considered.
I'm thinking we should leave it to the user to properly delete their secrets
and not try to open a can of behavioral worms by enforcing policy on the
barbican side. :(



> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev