<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 4, 2016 at 1:54 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Given these constraints it was as much of an ask as anything else. Can<br>
OSC handle this? Should it handle it from a best practices perspective?<br>
How are commands exposed / hidden based on user permissions? The fact<br>
that we're going to need a service library mean that a dedicated admin<br>
API might be appropriate?<br></blockquote><div><br></div><div>The only hiding/exposing of commands that OSC does is based on API versions.  We have no plans to ever get into attempting to evaluate policy even if/when that information becomes available via API.</div><div><br></div><div>That said, I think this belongs in a plugin in the client lib.  We do have plans to extract the common shell bits of OSC into a library (osc-lib) that could be used to also make stand-alone CLIs that look and act like OSC, with only the plugin commands present.  Even assuming only the additional dependency of the new lib, adding it to the OSC repo would also work, I just think it makes more sense for these commands to not be present in the default installation non-cloud-ops users would see.</div><div><br></div><div>dt</div></div><div><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>