<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 December 2015 at 14:33, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Indeed, this is one paradigm where it actually creates a hardened core,<br>
not a squisy one, so I think it's not a terrible idea.<br>
<span class=""><br></span></blockquote><div><br></div><div>I tend to agree, just wish we were already there :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
</span>What I mean is, you'd just have two completely separate _services_,<br>
instead of one service, with two separate endpoint "interface" entries:<br>
<br><div class="HOEnZb"><div class="h5"><snip example><br></div></div></blockquote><div><br></div><div>I guess if the clients already have mechanisms to determine whether to use the public url or the admin url, they can determine which service to look up just the same.  However, that brings me back to wondering if there's any real difference?   I'm missing something.  But like you say, if we don't have Keystone running such that we trust it enough to call it hardened, then that's a much more pressing issue.</div><div><br></div><div>What are other public cloud ops doing wrt public facing API services that can expose admin type operations?</div></div></div></div>