Open Stack

Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700:
> > 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!²  :-)
> 

Not at all, though I understand that, clipped as so, it may look a bit
ironic.

I was using shorthand of "database" to mean a general purpose database. I
should have qualified it to avoid any confusion. It is a narrow purpose
storage service with strong access controls. We can call that a database
if you like, but I think it has one very tiny role, and that is to audit
and control access to secrets.

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

Why would you need to make copies outside of the in-RAM copy that is
kept while the service runs? You're trying to do too much instead of
operating in a nice loosely coupled fashion.

> 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 accidental pain thing makes no sense to me. I'm a user and I take
responsibility for my data. If I don't want to have that responsibility,
I will use less privileged users and delegate the higher amount of
privilege to a system that does manage those relationships for me.

Do we have mandatory file locking in Unix? No we don't. Why? Because some
users want the power to remove files _no matter what_. We build in the
expectation that things may disappear no matter what you do to prevent
it. I think your LBaaS should be written with the same assumption. It
will be more resilient and useful to more people if they do not have to
play complicated games to remove a secret.

Anyway, nobody has answered this. What user would indiscriminately delete
their own data and expect that things depending on that data will continue
to work indefinitely?