Open Stack

Agenda items are numbered, and topics, as discussed, are described beneath in list format.


1) Revisit some basic features of loadbalancing as a service's object model and api.
   a) Brandon advocated Loadbalancer as only root object
      + The reason for root objects was for sharing.
   b) Will we allow sharing of pools in a listener?
      + Stephen suggests providing sharing to the customer for benefits
         - provides simplicity to the user
         - Example:  L7 rules all referencing the same pool: simpler for the user to handle it.
         - Without sharing there may also be a series of extra health checks that are unnecessary
      + German wants placement of the pool to be on the load balancer
         - This allows sharing pools between different listeners.
         - Counter argument by Stephen:  Sharing pools between HTTP/HTTPS load balancers would
               be really rare, where normally people would use a different port.  Adding another health
               check wouldn't be a big deal.  Proposed L7 policies where you have a complicated rule
               set causing duplication for a "or" set, would increase the health check requirement.
               (Refer to email in list)
   c) If we desire many to many, there will be more root objects than just load balancer.
      + Moving to many-to-many after establishing one root object would be difficult

2) Get consensus on initial project direction and implementation details
   a) One HA proxy instance per load balancer or one HA proxy instance per listener?
      + Per ML discussion:  Keeping listener on one HA Proxy instance increases performance on one
            Octavia VM
         - Desires benchmarks for this to support  (German has this included in his next sprint)
      + Suggested shelving this until benchmarks are researched.
      + Future discussions on the ML for this decision
      + A concern from Vijay:  with one HA Proxy instance per listener, would that affect scalability?
         - This was suggested to move to the mailing list

3) When decisions (like #2) have been made, where should this be stored, wiki or in code?
   a) Bad thing about wiki is if Openstack makes a documentation overhaul the decision information
         might get lost.
   b) Bad thing about code is its harder to find and read.
   c) Decision was to keep it in the Wiki.

4) Whose responsibility is it to update the wiki with these decisions?
   a) For now, Stephen has been updating the wiki
   b) In the future, people involved in the decision will decide someone to update the wiki at the time

5) What else is needed to change in the 0.5 design before it can be approved and implementation
      can begin?
   a) Action item for everyone:  Review this design before next week's meeting.  Keep in mind the
         document is supposed to be somewhat general.

6) Start going over action items (https://etherpad.openstack.org/p/Octavia_Action_Items)
   a) Action Item for everyone:  Review the migration information proposed by Brandon.
   b) Per link above, start from 1 and move the way down the list.
   c) How can we decide who is working on what?
      + Get launchpad set up for octavia to allow for blueprint additions and thus allow people to
            contribute to a specific effort
   d) We need a list of things that are required to do and what needs hooked up how (the glue
         between the different pieces)
   e) What kind of communication between different components?
      + XMLRPC?
      + A REST interface?
      + Something different?
   f) Brandon working on Data Models and SQL Alchemy Models.
   g) Stephen working on Octavia VM API interface, including what technology to use
   h) Doug working on Skeleton Structure
   i) Brandon working on launchpad and blueprints issue as well
   j) Stephen will also prioritize this list
   k) Topics that need discussed should be expressed and discussed in the mailing list
   l) Michael Johnson working on the base image scripts
      + Would we use an image we've built or set it up after creation of a VM
         - Start with a base image with pre-packaging of Octavia scripts and such instead of Cloud init
               doing all the work downloading and such.  Saves time/resources.
         - Ideally we would have a place in the Octavia repo with a script or something that when run
               would create an image.
      + The images will potentially change based on flavoring options.
         - This includes custom images via customer requirements

-- After meeting --
Q:  Are we going to be incubated?
A:  Yes, we are basically destined for incubation, period.  Note:  we will assuredly not be in Juno.

Q:  Why be part of Neutron?  Why not just be our own program?
A:  We want to distance ourselves from Neutron to some extent.  We will formalize this via a 
         networking driver in Octavia.  Note: we do not want to burn any bridges here, so we want to
         be appropriate in our spin-out process.




Sorry for the delay in sending this out.  Not sure if I missed anything here, but please feel free to add
anything necessary that I might have missed.  Thanks!


-Trevor