<div dir="ltr">I think we need to ask who we are lowering the barrier of entry for. Are we going down this path because we want developers to have less things to do to stand up a development environment? Or do we want to make it easy for people to realistically test? If you're going to realistically vet magnum, why not make that PoC as realistic as possible, as in deploying with barbican. As an operator, I think it would be better to have an honest assessment of the work required to deploy magnum, even if it costs a little extra time. I'd rather hit roadblocks with the realistic approach early than reassure my team everything will work correctly when we didn't test what we planned to offer to our customers. In my experience, having roadblocks pop up later after commitment has been made is expensive and stressful.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 9:37 AM, Clayton O'Neill <span dir="ltr"><<a href="mailto:clayton@oneill.net" target="_blank">clayton@oneill.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Apr 13, 2016 at 10:26 AM, rezroo <<a href="mailto:openstack@roodsari.us">openstack@roodsari.us</a>> wrote:<br>
> Hi Kevin,<br>
><br>
> I understand that this is how it is now. My question is how bad would it be<br>
> to wrap the Barbican client library calls in another class and claim, for<br>
> all practical purposes, that Magnum has no direct dependency on Barbican?<br>
> What is the negative of doing that?<br>
><br>
> Anyone who wants to use another mechanism should be able to do that with a<br>
> simple change to the Magnum conf file. Nothing more complicated. That's the<br>
> essence of my question.<br>
<br>
</span>For us, the main reason we’d want to be able to deploy without<br>
Barbican is mostly to lower the initial barrier of entry.  We’re not<br>
running anything else that would require Barbican for a multi-node<br>
deployment, so for us to do a realistic evaluation of Magnum, we’d<br>
have to get two “new to us” services up and running in a development<br>
environment.  Since we’re not running Barbican or Magnum, that’s a big<br>
time commitment for something we don’t really know if we’d end up<br>
using.  From that perspective, something that’s less secure might be<br>
just fine in the short term.  For example, I’d be completely fine with<br>
storing certificates in the Magnum database as part of an evaluation,<br>
knowing I had to switch from that before going to production.<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>