Open Stack

I think there is significant value in having status on the listener object
even in the case of HAProxy. While HAProxy can support multiple listeners
in a single process, there is no reason it needs to be deployed that way.
Additionally in the case of updating a configuration with an additional
listener, the other listeners and the load balancer object are not in an
unavailable or down state before the configuration is applied, only the new
listener object is down or building. In the case of the HAProxy namespace
driver, one could map the namespace creation and HAProxy process to the
load balancer object status, but each listener can have its own status
based on the availability of members in its pools.

For the initial version of our new object model we be pragmatic and
minimize complexity and change, we can preform a reduction across all
listeners to generate an overall load balancer status.


-Dustin


On Tue, Jun 24, 2014 at 3:15 PM, Vijay B <os.vbvs at gmail.com> wrote:

> Hi Brandon, Eugene, Doug,
>
> During the hackathon, I remember that we had briefly discussed how
> listeners would manifest themselves on the LB VM/device, and it turned out
> that for some backends like HAProxy it simply meant creating a frontend
> entry in the cfg file whereas on other solutions it could mean spawning a
> process/equivalent. So we must have status fields to track the state of any
> such entities that are actually created. In the listener case, an ACTIVE
> state would mean that the appropriate backend processes have been created
> or that the required config file entries have been made.
>
> I like the idea of having relational objects and setting the status on
> them, and in our case we can use the status fields
> (pool/healthmonitor/listener) in each table to denote the state of the
> relationship (configuration/association on backend) to another object like
> LoadBalancer. So I think the status fields should stay.
>
> In this scenario, some entities' status could be updated in lbaas proper,
> and some in the driver implementation. I don't have a strict preference as
> to which among lbaas proper or the driver layer announces the status since
> we discussed on the IRC that we'd have helper functions in the driver to do
> these updates.
>
>
> Regards,
> Vijay
>
>
> On Tue, Jun 24, 2014 at 12:16 PM, Brandon Logan <
> brandon.logan at rackspace.com> wrote:
>
>> On Tue, 2014-06-24 at 18:53 +0000, Doug Wiegley wrote:
>> > Hi Brandon,
>> >
>> > I think just one status is overloading too much onto the LB object
>> (which
>> > is perhaps something that a UI should do for a user, but not something
>> an
>> > API should be doing.)
>>
>> That is a good point and perhaps its another discussion to just have
>> some way to show the status an entity has for each load balancer, which
>> is what mark suggested for the member status at the meet-up.
>>
>> >
>> > > 1) If an entity exists without a link to a load balancer it is purely
>> > > just a database entry, so it would always be ACTIVE, but not really
>> > > active in a technical sense.
>> >
>> > Depends on the driver.  I don¹t think this is a decision for lbaas
>> proper.
>>
>> Driver is linked to the flavor or provider.  Flavor or provider will/is
>> linked to load balancer.  We won't be able get a driver to send anything
>> to if there isn't a load balancer.  Without a driver it is a decision
>> for lbaas proper.  I'd be fine with setting the status of these
>> "orphaned" entities to just ACTIVE but I'm just worried about the status
>> management in the future.
>>
>> >
>> >
>> > > 2) If some of these entities become shareable then how does the status
>> > > reflect that the entity failed to create on one load balancer but was
>> > > successfully created on another.  That logic could get overly complex.
>> >
>> > That¹s a status on the join link, not the object, and I could argue
>> > multiple ways in which that should be one way or another based on the
>> > backend, which to me, again implies driver question (backend could queue
>> > for later, or error immediately, or let things run degraded, orŠ)
>>
>> Yeah that is definitely an argument.  I'm just trying to keep in mind
>> the complexities that could arise from decisions made now.  Perhaps it
>> is the wrong way to look at it to some, but I don't think thinking about
>> the future is a bad thing and should never be done.
>>
>> >
>> > Thanks,
>> > Doug
>> >
>> >
>> >
>> >
>> > On 6/24/14, 11:23 AM, "Brandon Logan" <brandon.logan at RACKSPACE.COM>
>> wrote:
>> >
>> > >I think we missed this discussion at the meet-up but I'd like to bring
>> > >it up here.  To me having a status on all entities doesn't make much
>> > >sense, and justing having a status on a load balancer (which would be a
>> > >provisioning status) and a status on a member (which would be an
>> > >operational status) are what makes sense because:
>> > >
>> > >1) If an entity exists without a link to a load balancer it is purely
>> > >just a database entry, so it would always be ACTIVE, but not really
>> > >active in a technical sense.
>> > >
>> > >2) If some of these entities become shareable then how does the status
>> > >reflect that the entity failed to create on one load balancer but was
>> > >successfully created on another.  That logic could get overly complex.
>> > >
>> > >I think the best thing to do is to have the load balancer status
>> reflect
>> > >the provisioning status of all of its children.  So if a health monitor
>> > >is updated then the load balancer that health monitor is linked to
>> would
>> > >have its status changed to PENDING_UPDATE.  Conversely, if a load
>> > >balancer or any entities linked to it are changed and the load
>> > >balancer's status is in a non-ACTIVE state then that update should not
>> > >be allowed.
>> > >
>> > >Thoughts?
>> > >
>> > >Thanks,
>> > >Brandon
>> > >
>> > >
>> > >_______________________________________________
>> > >OpenStack-dev mailing list
>> > >OpenStack-dev at lists.openstack.org
>> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140624/99a0a815/attachment.html>