<div dir="ltr">Hi Ed,<div><br></div><div>That sounds good to me, actually:  As long as 'cloud admin' API functions are represented as well as 'simple user workflows', then I'm all for a unified API that simply exposes more depending on permissions.</div>
<div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 12:15 PM, Ed Hall <span dir="ltr"><<a href="mailto:edhall@yahoo-inc.com" target="_blank">edhall@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<br>
<div>
<div>On Feb 25, 2014, at 10:10 AM, Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>> wrote:</div><div class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> On Feb 25, 2014 at 3:39 AM, <a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a> wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"></div>
</blockquote>
</div>
<div>Agree, however actual hardware is beyond logical LBaaS API but could be a part of admin LBaaS API.</div>
<div>
<div></div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Aah yes--  In my opinion, users should almost never be exposed to anything that represents a specific piece of hardware, but cloud administrators must be. The logical constructs the user is exposed to can "come close" to what an actual piece of hardware
 is, but again, we should be abstract enough that a cloud admin can swap out one piece of hardware for another without affecting the user's workflow, application configuration, (hopefully) availability, etc.</div>
<div><br>
</div>
<div>I recall you said previously that the concept of having an 'admin API' had been discussed earlier, but I forget the resolution behind this (if there was one). Maybe we should revisit this discussion?</div>
<div><br>
</div>
<div>I tend to think that if we acknowledge the need for an admin API, as well as some of the core features it's going to need, and contrast this with the user API (which I think is mostly what Jay and Mark McClain are rightly concerned about), it'll start
 to become obvious which features belong where, and what kind of data model will emerge which supports both APIs.</div>
</div>
</div>
</div>
</blockquote>
</div></div>
<div><br>
</div>
[I’m new to this discussion; my role at my employer has been shifted from an internal to a community focus and I’m madly
<div>attempting to come up to speed. I’m a software developer with an operations focus; I’ve worked with OpenStack since Diablo</div>
<div>as Yahoo’s team lead for network integration.]</div>
<div><br>
<div>Two levels (user and admin) would be the minimum. But our experience over time is that even administrators occasionally</div>
<div>need to be saved from themselves. This suggests that, rather than two or more separate APIs, a single API with multiple</div>
<div>roles is needed. Certain operations and attributes would only be accessible to someone acting in an appropriate role.</div>
<div><br>
</div>
<div>This might seem over-elaborate at first glance, but there are other dividends: a single API is more likely to be consistent,</div>
<div>and maintained consistently as it evolves. By taking a role-wise view the hierarchy of concerns is clarified. If you focus on</div>
<div>the data model first you are more likely to produce an arrangement that mirrors the hardware but presents difficulties in</div>
<div>representing and implementing user and operator intent.</div>
</div>
<div><br>
</div>
<div>Just some general insights/opinions — take for what they’re worth.</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>                 -Ed</div>
<div><br>
</div>
</font></span></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div>