<div dir="ltr">Hi Craig,<div><br></div><div>I was attempting to avoid haproxy-specific terminology here, but some of those attributes are on the listener (ie. keepalive = 0 would be equivalent to httpclose). Other options (like adding headers) are expressed through the layer-7 functionality.</div>
<div><br></div><div>So, we have yet to update the API to correspond with this object diagram, but if you recall the API I linked on the list a couple weeks ago ( <span style="background-color:transparent;color:rgb(0,0,0);font-family:Arial;font-size:15px;white-space:pre-wrap"><a href="https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing">https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing</a> ) look in the section on L7 policies and L7 rules. (Note also that we don't yet have group consensus on the specifics of implementing the L7 stuff-- but adding headers would definitely fall in that category, eh.)</span></div>
<div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 14, 2014 at 3:04 PM, Craig Tracey <span dir="ltr"><<a href="mailto:craig@craigtracey.com" target="_blank">craig@craigtracey.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Stephen,<div><br></div><div>One nit and one question....</div><div>- For each of the tables with status fields we will want to have status_description fields as well. This is already a part of the V2 models.</div>
<div>- How does this model handle things like implementation-specific options and/or things like additional headers? I'm thinking of some of those very common cases with http/https...X-Forwarded-For, httpclose, etc.</div>
<div><br></div><div>Best,</div><div>Craig</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Aah-- and here's a small error correction. :)<div><br></div><div>Please also note:</div><div>* We're not yet in consensus on the L7 or SSL related objects, but the Loadbalancer, Listener, Pool, and Member should probably not change at this point (unless there are major objections voiced in the very near term).</div>
<div>* I've tried to use color coordination to indicate different logical parts that can probably be implemented in different blueprints / by different engineering teams.</div><div>* The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.)</div>
<div>* The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.)</div>
<span><font color="#888888">
<div><br></div><div>Stephen</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb.<span><font color="#888888"><div>
<br></div><div>Stephen</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Craig,<div><br></div><div>I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is.</div>
<div><br></div><div>Also, I think the #openstack-lbaas channel is a great idea!</div><div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, May 14, 2014 at 9:05 AM, Craig Tracey <span dir="ltr"><<a href="mailto:craig@craigtracey.com" target="_blank">craig@craigtracey.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi all,<div><br></div><div>From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else?</div>
<div><br></div><div>On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts?</div>
<div><br></div><div>Best,</div><div>Craig</div></div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br><a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br><a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br><a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div>
</div></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>