<div dir="ltr">Hi Eugene!<div><br></div><div class="gmail_extra">Responses inline:<br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 3:33 AM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<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 class=""><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>I'm really not sure what Mark McClain on some other folks see as implementation details. To me the 'instance' concept is as logical as others (vips/pool/etc). But anyway, it looks like majority of those who discuss, sees it as redundant concept.</div>
</div></div></div></blockquote><div><br></div><div>Maybe we should have a discussion around what qualifies as a 'logical concept' or 'logical construct,' and why the 'loadbalancer' concept you've been championing either does or does not qualify, so we're all (closer to being) on the same page before we discuss model changes?</div>
<div><br></div><div> </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 class=""><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 class=""><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><br></div><div><br></div><div>Thanks,</div><div>Stephen</div><div> </div></div><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div></div>