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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to