Great notes! thanks it helped me catch up after vacation. :)
On Thu, Aug 7, 2014 at 4:33 AM, Stephen Balukoff <sbaluk...@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 <sbaluk...@bluebox.net> > wrote: > >> Wow, Trevor! Thanks for capturing all that! >> >> >> On Wed, Aug 6, 2014 at 9:47 PM, Trevor Vardeman < >> trevor.varde...@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@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev