[openstack-dev] [Neutron][LBaaS] Which entities need status
Jorge Miramontes
jorge.miramontes at RACKSPACE.COM
Thu Jul 3 18:50:41 UTC 2014
Hey German,
We have similar statuses. I have been wanting to add a 'QUEUED' status
however. The reason is that we currently use 'BUILD' which indicates
active provisioning when in reality it is actually queued first and then
provisioned. Thus, there are potential issues when trying to determine
average provisioning times. Furthermore, customers are accustomed to
certain provisioning times and if those times seems longer than usual they
tend to complain. If we had a 'QUEUED' status then customers would most
likely not get upset (or as upset). I would also like the ability to move
from 'ERROR' back to an 'ACTIVE' state. And error status for us means
something didn't happen correctly during provisioning and updating.
However, most of the time the load balancer is still servicing traffic.
Forcing a customer to re-create a load balancer that is serving web
traffic is a bad thing, especially in our case since we have static ip
addresses. We have monitoring on load balancers that go into an 'ERROR'
status and take action to correct the issue.
Cheers,
--Jorge
On 6/24/14 11:30 PM, "Eichberger, German" <german.eichberger at hp.com> wrote:
>Hi,
>
>I second Stephen's suggestion with the status matrix. I have heard of
>(provisional) status, operational status, admin status -- I am curious
>what states exists and how an object would transition between them.
>
>Libra uses only one status field and it transitions as follows:
>
>BUILDING -> ACTIVE|ERROR
>ACTIVE -> DEGARDED|ERROR|DELETED
>DEGRADED -> ACTIVE|ERROR|DELETED
>ERROR -> DELETED
>
>That said I don't think admin status is that important for me as an
>operator since my user's usually delete lbs and re-create them. But I am
>curious how other operators feel.
>
>Thanks,
>German
>
>-----Original Message-----
>From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]
>Sent: Tuesday, June 24, 2014 8:46 PM
>To: openstack-dev at lists.openstack.org
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status
>
>Alright y'all have convinced me for now. How the status is show on
>shared entities is still yet to be determined. However, we don't have
>any shared entities (unless we really want health monitors shareable
>right now) at this point so the status won't get complicated for this
>first iteration.
>
>Thanks,
>Brandon
>
>On Wed, 2014-06-25 at 01:10 +0000, Doug Wiegley wrote:
>> Hi Stephen,
>>
>>
>> > Ultimately, as we will have several objects which have many-to-many
>> relationships with other objects, the 'status' of an object that is
>> shared between what will ultimately be two separate physical entities
>> on the back-end should be represented by a dictionary, and any
>> 'reduction' of this on behalf of the user should happen within the UI.
>> It does make things more complex to deal with in certain kinds of
>> failure scenarios, but we don't help ourselves at all by trying to
>> hide, say, when a member of a pool referenced by one listener is 'UP'
>> and the same member of the same pool referenced by a different
>> listener is 'DOWN'. :/
>>
>>
>> For M:N, that’s actually an additional status field that rightly
>> belongs as another column in the join table, if at all (allow me to
>> queue up all of my normal M:N objections here in this case, I’m just
>> talking normal db representation.) The bare object itself still has
>> status of its own.
>>
>>
>> Doug
>>
>>
>>
>>
>>
>>
>> From: Stephen Balukoff <sbalukoff at bluebox.net>
>> Reply-To: "OpenStack Development Mailing List (not for usage
>> questions)" <openstack-dev at lists.openstack.org>
>> Date: Tuesday, June 24, 2014 at 6:02 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need
>> status
>>
>>
>>
>> Ultimately, as we will have several objects which have many-to-many
>> relationships with other objects, the 'status' of an object that is
>> shared between what will ultimately be two separate physical entities
>> on the back-end should be represented by a dictionary, and any
>> 'reduction' of this on behalf of the user should happen within the UI.
>> It does make things more complex to deal with in certain kinds of
>> failure scenarios, but we don't help ourselves at all by trying to
>> hide, say, when a member of a pool referenced by one listener is 'UP'
>> and the same member of the same pool referenced by a different
>> listener is 'DOWN'. :/
>>
>>
>> Granted, our version 1 implementation of these objects is going to be
>> simplified, but it doesn't hurt to think about where we're headed with
>> this API and object model.
>>
>>
>> I think it would be worthwhile for someone to produce a status matrix
>> showing which kinds of status are available for each object type, and
>> what the possible values of those statuses are, and what they mean.
>> Given the question of what 'status' means is very complicated indeed,
>> I think this is the only way we're going to actually make forward
>> progress in this discussion.
>>
>>
>> Stephen
>>
>>
>>
>>
>> On Tue, Jun 24, 2014 at 4:02 PM, Dustin Lundquist
>> <dustin at null-ptr.net> wrote:
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
More information about the OpenStack-dev
mailing list