<div dir="ltr">Hi Stephen,<div><br></div><div>Thanks for a good summary. Some comments inline.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 15, 2014 at 5:20 AM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</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><br></div><div>So! On this front:</div><div><br></div><div>1. Does is make sense to keep filling out use cases in Samuel's document above? I can think of several more use cases that our customers actually use on our current deployments which aren't considered in the 8 cases in Samuel's document thus far. Plus nobody has create any use cases from the cloud operator perspective yet.</div>
</div></blockquote><div><br></div><div>I treat Sam's doc as a source of use cases to triage API proposals. If you think you have use cases that don't fit into existing API or into proposed API, they should certainly be brought to attention.</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><br></div><div>2. It looks like we've started to get real-world data on Load Balancer features in use in the real world. If you've not added your organization's data, please be sure to do so soon so we can make informed decisions about product direction. On this front, when will we be making these decisions?</div>
</div></blockquote><div>I'd say we have two kinds of features - one kind is features that affect or even define the object model and API.</div><div>Other kind are features that are implementable within existing/proposed API or require slight changes/evolution.</div>
<div>First kind is the priority: while some of such features may or may not be implemented in some particular release, we need to implement proper infrastructure for them (API, obj model)</div><div><br></div><div>Oleg Bondarev (he's neutron core) and me are planning and mostly interested to work on implementing generic stuff like API/obj model and adopt haproxy driver to it. So our goal is to make implementation of particular features simpler for contributors and also make sure that proposed design fits in general lbaas architecture. I believe that everyone who wants to see certain feature may start working on it - propose design, participate in discussions and start actually writing the code.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>3. Jorge-- I know an action item from the last meeting was to draft a revision of the API (probably starting from something similar to the Atlas API). Have you had a chance to get started on this, and are you open for collaboration on this document at this time? Alternatively, I'd be happy to take a stab at it this week (though I'm not very familiar with the Atlas API-- so my proposal might not look all that similar).</div>
</div></blockquote><div> </div><div>+1, i'd like to see something as well. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>What format or template should we be following to create the API documentation?  (I see this here:  <a href="http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html" target="_blank">http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html</a>  but this seems like it might be a little heavy for an API draft that is likely to get altered significantly, especially given how this discussion has gone thus far. :/ )</div>
</div></blockquote><div><br></div><div>Agree, that's too heavy for API sketch. I think a set of resources with some attributes plus a few cli calls is what could show the picture.</div><div><br></div><div>Thanks,</div>
<div>Eugene.</div></div></div></div>