<div dir="ltr">Hi folks,<div><br></div><div>I'm OK with going with no shareable child entities (Listeners, Pools, Members, TLS-related objects, L7-related objects, etc.). This will simplify a lot of things (like status reporting), and we can probably safely work under the assumption that any user who has a use case in which a shared entity is useful is probably also technically savvy enough to not only be able to manage consistency problems themselves, but is also likely to want to have that level of control.</div>
<div><br></div><div>Also, an haproxy instance should map to a single listener. This makes management of the configuration template simpler and the behavior of a single haproxy instance more predictable. Also, when it comes to configuration updates (as will happen, say, when a new member gets added to a pool), it's less risky and error prone to restart the haproxy instance for just the affected listener, and not for all listeners on the Octavia VM. The only down-sides I see are that we consume slightly more memory, we don't have the advantage of a shared SSL session cache (probably doesn't matter for 99.99% of sites using TLS anyway), and certain types of persistence wouldn't carry over between different listeners if they're implemented poorly by the user. :/  (In other words, negligible down-sides to this.)</div>
<div><br></div><div>Other upsides: This allows us to set different "global" haproxy settings differently per listener as appropriate. (ex. It might make sense to have one of the several forms of keepalive enabled for the TERMINATED_HTTPS listener for performance reasons, but disable keepalive for the HTTP listener for different performance reasons.)</div>
<div><br></div><div>I do want to note though, that this also affects the discussion on statuses:</div><div><br></div><div>On the statuses:  If we're using a separate haproxy instance per listener, I think that probably both the loadbalancer and listener objects have different needs here that are appropriate. Specifically, this is what I'm thinking, regarding the statuses and what they mean:</div>
<div><br></div><div>Loadbalancer:</div><div>  PENDING_CREATE: VIP address is being assigned (reserved, or put on a port) in Neutron, or is being allocated on Octavia VMs.</div><div>  ACTIVE: VIP address is up and running on at least one Octavia VM (ex. a ping check would succeed, assuming no blocking firewall rules)</div>
<div>  PENDING_DELETE: VIP address is being removed from Octavia VM(s) and reservation in Neutron released</div><div> (Is there any need for a PENDING_UPDATE status for a loadbalancer? Shouldn't the vip_address be immutable after it's created?)</div>
<div><br></div><div>Listener:</div><div> PENDING_CREATE: A new Listener haproxy configuration is being created on Octavia VM(s)</div><div> PENDING_UPDATE: An existing Listener haproxy configuration is being updated on Octavia VM(s)</div>
<div> PENDING_DELETE: Listener haproxy configuration is about to be deleted off associated Octavia VM(s)</div><div> ACTIVE: haproxy Listener is up and running (ex. responds to TCP SYN check).</div><div><br></div><div>I don't think that these kinds of status are useful / appropriate for Pool, Member, Healthmonitor, TLS certificate id, or L7 Policy / Rule objects, as ultimately this boils down to configuration lines in an haproxy config somewhere, and really the Listener status is what will be affected when things are changed.</div>
<div><br></div><div>I'm basically in agreement with Brandon on his points with operational status, though I would like to see these broken out into their various meanings for the different object types. I also think some object types won't need an operational status (eg. L7 Policies, healthmonitors, etc.) since these essentially boil down to lines in an haproxy configuration file.</div>
<div><br></div><div>Does this make sense?</div><div><br></div><div>Stephen</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 3:10 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yeah, need details on that.  Maybe he's talking about having haproxy<br>
listen on many ips and ports, each one being a separate front end<br>
section and in the haproxy config with each mapped to its own<br>
default_backend.<br>
<br>
Even if that is the case, the load balancer + listener woudl still make<br>
up one of those frontends so the mapping would still be correct.<br>
Though, maybe a different structure would make more sense if that is the<br>
case.<br>
<br>
Also, I've created a WIP review of the initial database structure:<br>
<a href="https://review.openstack.org/#/c/114671/" target="_blank">https://review.openstack.org/#/c/114671/</a><br>
<br>
Added my own comments so everyone please look at that.  Stephen, if you<br>
could comment on what German mentioned that'd be great.<br>
<br>
Have a good weekend!<br>
<span class="HOEnZb"><font color="#888888"><br>
-Brandon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, 2014-08-15 at 20:34 +0000, Eichberger, German wrote:<br>
> --Basically no shareable entities.<br>
> +1<br>
><br>
> That will make me insanely happy :-)<br>
><br>
> Regarding Listeners: I was assuming that a LoadBalancer would map to an haproxy instance - and a listener would be part of that haproxy. But I heard Stephen say that this so not so clear cut. So maybe listeners map to haproxy instances...<br>

><br>
> German<br>
><br>
> -----Original Message-----<br>
> From: Brandon Logan [mailto:<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>]<br>
> Sent: Thursday, August 14, 2014 10:17 PM<br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Subject: [openstack-dev] [Octavia] Object Model and DB Structure<br>
><br>
> So I've been assuming that the Octavia object model would be an exact copy of the neutron lbaas one with additional information for Octavia.<br>
> However, after thinking about it I'm not sure this is the right way to go because the object model in neutron lbaas may change in the future, and Octavia can't just change it's object model when neutron lbaas/openstack lbaas changes it's object model.  So if there are any lessons learned we would like to apply to Octavia's object model now is the time.<br>

><br>
> Entity name changes are also on the table if people don't really like some of the names.  Even adding new entities or removing entities if there are good reasons isn't out of the question.<br>
><br>
> Anyway here are a few of my suggestions.  Please add on to this if you want.  Also, just flat out tell me I'm wrong on some of htese suggestions if you feel as such.<br>
><br>
> A few improvements I'd suggest (using the current entity names):<br>
> -A real root object that is the only top level object (loadbalancer).<br>
> --This would be 1:M relationship with Listeners, but Listeners would only be children of loadbalancers.<br>
> --Pools, Members, and Health Monitors would follow the same workflow.<br>
> --Basically no shareable entities.<br>
><br>
> -Provisioning status only on the root object (loadbalancer).<br>
> --PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a DEFEERRED status! YAY!) --Also maybe a DELETED status.<br>
><br>
> -Operating status on other entities<br>
> --ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE --Pools and Members --Listeners have been mentioned but I'd like to hear more details on that.<br>
><br>
> -Adding status_description field in, or something similar.  Would only eixst on loadbalancer entity if loadbalancer is the only top level object.<br>
><br>
> Thanks,<br>
> Brandon<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>
><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>
<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>
</div></div></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>