Weighing in here: I'm all for option #2 as well.
Stephen On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum <cl...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
