Open Stack

Weighing in here:

I'm all for option #2 as well.

Stephen


On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700:
> > Hi all,
> >
> > I’m strongly in favor of having immutable TLS-typed containers, and very
> > much opposed to storing every revision of changes done to a container.  I
> > think that storing versioned containers would add too much complexity to
> > Barbican, where immutable containers would work well.
> >
>
> Agree completely. Create a new one for new values. Keep the old ones
> while they're still active.
>
> >
> > I’m still not sold on the idea of registering services with Barbican,
> even
> > though (or maybe especially because) Barbican would not be using this
> data
> > for anything.  I understand the problem that we’re trying to solve by
> > associating different resources across projects, but I don’t feel like
> > Barbican is the right place to do this.
> >
>
> Agreed also, this is simply not Barbican or Neutron's role. Be a REST
> API for secrets and networking, not all dancing all singing nannies that
> prevent any possibly dangerous behavior with said API's.
>
> > It seems we’re leaning towards option #2, but I would argue that
> > orchestration of services is outside the scope of Barbican’s role as a
> > secret-store.  I think this is a problem that may need to be solved at a
> > higher level.  Maybe an openstack-wide registry of dependend entities
> > across services?
>
> An optional openstack-wide registry of depended entities is called
> "Heat".
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140609/8c1db457/attachment.html>