<div dir="ltr">Hi Trevor!<div><br></div><div>Thanks for this, I've also transcribed these onto the wiki here: <a href="https://wiki.openstack.org/wiki/Octavia/Meeting_Minutes#2014-08-20_Weekly_meeting">https://wiki.openstack.org/wiki/Octavia/Meeting_Minutes#2014-08-20_Weekly_meeting</a>:</div>
<div><br></div><div>Obviously, y'all should feel free to fix any error you find appropriately!</div><div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 2:52 PM, Trevor Vardeman <span dir="ltr"><<a href="mailto:trevor.vardeman@rackspace.com" target="_blank">trevor.vardeman@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Agenda items are numbered, and topics, as discussed, are described beneath in list format.<br>
<br>
<br>
1) Revisit some basic features of loadbalancing as a service's object model and api.<br>
a) Brandon advocated Loadbalancer as only root object<br>
+ The reason for root objects was for sharing.<br>
b) Will we allow sharing of pools in a listener?<br>
+ Stephen suggests providing sharing to the customer for benefits<br>
- provides simplicity to the user<br>
- Example: L7 rules all referencing the same pool: simpler for the user to handle it.<br>
- Without sharing there may also be a series of extra health checks that are unnecessary<br>
+ German wants placement of the pool to be on the load balancer<br>
- This allows sharing pools between different listeners.<br>
- Counter argument by Stephen: Sharing pools between HTTP/HTTPS load balancers would<br>
be really rare, where normally people would use a different port. Adding another health<br>
check wouldn't be a big deal. Proposed L7 policies where you have a complicated rule<br>
set causing duplication for a "or" set, would increase the health check requirement.<br>
(Refer to email in list)<br>
c) If we desire many to many, there will be more root objects than just load balancer.<br>
+ Moving to many-to-many after establishing one root object would be difficult<br>
<br>
2) Get consensus on initial project direction and implementation details<br>
a) One HA proxy instance per load balancer or one HA proxy instance per listener?<br>
+ Per ML discussion: Keeping listener on one HA Proxy instance increases performance on one<br>
Octavia VM<br>
- Desires benchmarks for this to support (German has this included in his next sprint)<br>
+ Suggested shelving this until benchmarks are researched.<br>
+ Future discussions on the ML for this decision<br>
+ A concern from Vijay: with one HA Proxy instance per listener, would that affect scalability?<br>
- This was suggested to move to the mailing list<br>
<br>
3) When decisions (like #2) have been made, where should this be stored, wiki or in code?<br>
a) Bad thing about wiki is if Openstack makes a documentation overhaul the decision information<br>
might get lost.<br>
b) Bad thing about code is its harder to find and read.<br>
c) Decision was to keep it in the Wiki.<br>
<br>
4) Whose responsibility is it to update the wiki with these decisions?<br>
a) For now, Stephen has been updating the wiki<br>
b) In the future, people involved in the decision will decide someone to update the wiki at the time<br>
<br>
5) What else is needed to change in the 0.5 design before it can be approved and implementation<br>
can begin?<br>
a) Action item for everyone: Review this design before next week's meeting. Keep in mind the<br>
document is supposed to be somewhat general.<br>
<br>
6) Start going over action items (<a href="https://etherpad.openstack.org/p/Octavia_Action_Items" target="_blank">https://etherpad.openstack.org/p/Octavia_Action_Items</a>)<br>
a) Action Item for everyone: Review the migration information proposed by Brandon.<br>
b) Per link above, start from 1 and move the way down the list.<br>
c) How can we decide who is working on what?<br>
+ Get launchpad set up for octavia to allow for blueprint additions and thus allow people to<br>
contribute to a specific effort<br>
d) We need a list of things that are required to do and what needs hooked up how (the glue<br>
between the different pieces)<br>
e) What kind of communication between different components?<br>
+ XMLRPC?<br>
+ A REST interface?<br>
+ Something different?<br>
f) Brandon working on Data Models and SQL Alchemy Models.<br>
g) Stephen working on Octavia VM API interface, including what technology to use<br>
h) Doug working on Skeleton Structure<br>
i) Brandon working on launchpad and blueprints issue as well<br>
j) Stephen will also prioritize this list<br>
k) Topics that need discussed should be expressed and discussed in the mailing list<br>
l) Michael Johnson working on the base image scripts<br>
+ Would we use an image we've built or set it up after creation of a VM<br>
- Start with a base image with pre-packaging of Octavia scripts and such instead of Cloud init<br>
doing all the work downloading and such. Saves time/resources.<br>
- Ideally we would have a place in the Octavia repo with a script or something that when run<br>
would create an image.<br>
+ The images will potentially change based on flavoring options.<br>
- This includes custom images via customer requirements<br>
<br>
-- After meeting --<br>
Q: Are we going to be incubated?<br>
A: Yes, we are basically destined for incubation, period. Note: we will assuredly not be in Juno.<br>
<br>
Q: Why be part of Neutron? Why not just be our own program?<br>
A: We want to distance ourselves from Neutron to some extent. We will formalize this via a<br>
networking driver in Octavia. Note: we do not want to burn any bridges here, so we want to<br>
be appropriate in our spin-out process.<br>
<br>
<br>
<br>
<br>
Sorry for the delay in sending this out. Not sure if I missed anything here, but please feel free to add<br>
anything necessary that I might have missed. Thanks!<br>
<br>
<br>
-Trevor<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>