<div dir="ltr">Wow, Trevor! Thanks for capturing all that!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 9:47 PM, Trevor Vardeman <span dir="ltr"><<a href="mailto:trevor.vardeman@rackspace.com" target="_blank">trevor.vardeman@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Agenda items are numbered, and topics, as discussed, are described beneath in list format.<br>
<br>
1) Octavia Constitution and Project Direction Documents (Road map)<br>
    a) Constitution and Road map will potentially be adopted after another couple days; providing those who were busy more time to review the information<br>
<br>
2) Octavia Design Proposals<br>
    a) Difference between version 0.5 and 1.0 isn't huge<br>
    b) Version 2 has many network topology changes and Layer 4 routing<br>
        + This includes N node Active-Active<br>
        + Would like to avoid Layer 2 connectivity with Load Balancers (included in version 1 however)<br>
        + Layer router driver<br>
        + Layer router controller<br>
        + Long term solution<br>
    c) After refining Version 1 document (with some scrutiny) all changes will be propagated to the Version 2 document<br>
    d) Version 0.5 is unpublished<br>
    e) All control layer, anything connected to the intermediate message bus in version 1, will be collapsed down to 1 daemon.<br>
        + No scale-able control, but scale-able service delivery<br>
        + Version 1 will be the first large operator compatible version, that will have both scale-able control and scale-able service delivery<br>
        + 0.5 will be a good start<br>
            - laying out ground work<br>
            - rough topology for the end users<br>
            - must be approved by the networking teams for each contributing company<br>
    f) The portions under control of neutron lbaas is the User API and the driver (for neutron lbaas)<br>
    g) If neutron LBaaS is a sufficient front-end (user API doesn't suck), then Octavia will be kept as a vendor driver<br>
    h) Potentially including a REST API on top of Octavia<br>
        + Octavia is initially just a vendor driver, no real desire for another API in front of Octavia<br>
        + If someone wants it, the work is "trivial" and can be done in another project at another time<br>
    i) Octavia should have a loose coupling with Neutron; use a shim for network connectivity (one specifically for Neutron communication in the start)<br>
        + This is going to hold any "dirty hacks" that would be required to get something done, keeping Octavia clean<br>
            - Example: changing the mac address on a port<br>
<br>
3) Operator Network Topology Requirements<br>
    a) One requirement is floating IPs.<br>
    b) IPv6 is in demand, but is currently not supported reliably on Neutron<br>
        + IPv6 would be represented as a different load balancer entity, and possibly include co-location with another Load Balancer<br>
    c) Network interface plug-ability (potentially)<br>
    d) Sections concerning front-end connectivity should be forwarded to each company's network specialists for review<br>
        + Share findings in the mailing list, and dissect the proposals with the information and comment what requirements are needing added etc.<br>
<br>
4) HA/Failover Options/Solutions<br>
    a) Rackspace may have a solution to this, but the conversation will be pushed off to the next meeting (at least)<br>
        + Will gather more information from another member in Rackspace to provide to the ML for initial discussions<br>
    b) One option for HA:  Spare pool option (similar to Libra)<br>
        + Poor recovery time is a big problem<br>
    c) Another option for HA:  Active/Passive<br>
        + Bluebox uses one active and one passive configuration, and has sub-second fail over.  However is not resource-sufficient<br>
<br>
Questions:<br>
Q:  What is the expectation for a release time-frame<br>
A:  Wishful thinking; Octavia version 0.5 beta for Juno (probably not, but would be awesome to push for that)<br>
<br>
Notes:<br>
 + We need to pressure the Neutron core reviewers to review the Neutron LBaaS changes to get merges.<br>
 + Version 2 front-end topology is different than the Version 1.  Please review them individually, and thoroughly<br>
<br>
<br>
PS.  I re-wrote most of the information from the recording (thanks again Doug).  I have one question for everyone: should I just email this out after each meeting to the Octavia mailing list, or should I also add it to a page in an Octavia wiki for Meeting Notes/Minutes or something for review by anyone?  What are your thoughts?<br>

<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>
</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>