[openstack-dev] [Octavia] Minutes from 8/6/2014 meeting

Stephen Balukoff sbalukoff at bluebox.net
Thu Aug 7 08:33:33 UTC 2014


On where to capture notes like this long-term:  I would say the wiki is
more searchable for now. When we make the transition to IRC meetings, then
the meeting bots will capture minutes and transcripts in the usual way and
we can link to these from the wiki.


On Thu, Aug 7, 2014 at 1:29 AM, Stephen Balukoff <sbalukoff at bluebox.net>
wrote:

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



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140807/80adf4f1/attachment.html>


More information about the OpenStack-dev mailing list