Open Stack

Great notes! thanks it helped me catch up after vacation. :)


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

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140811/9ba58841/attachment.html>