e-create them. But I am
>curious how other operators feel.
>
>Thanks,
>German
>
>-Original Message-----
>From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
>Sent: Tuesday, June 24, 2014 8:46 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev
ators feel.
Thanks,
German
-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Tuesday, June 24, 2014 8:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status
Alright y'all have convinced me for now.
>
>
>
>
>
> From: Stephen Balukoff
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
> Date: Tuesday, June 24, 2014 at 6:02 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Su
enstack-dev@lists.openstack.org>>
Date: Tuesday, June 24, 2014 at 6:02 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status
Ultimately, as we
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
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
list
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
e questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, June 24, 2014 at 12:10 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status
Hi l
Eugene,
Thanks for the feedback. I have a feeling thats where we will end up
going anyway so perhaps status on all entities for now is the proper way
to build into that. I just want my objections to be heard.
Thanks,
Brandon
On Tue, 2014-06-24 at 23:10 +0400, Eugene Nikanorov wrote:
> Hi lbaas
the distinction between status and
operational status -- that should take care of that.
German
-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com]
Sent: Tuesday, June 24, 2014 11:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openst
On Tue, 2014-06-24 at 18:53 +, 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 discu
Hi lbaas folks,
IMO a status is really an important part of the API.
In some old email threads Sam has proposed the solution for lbaas objects:
we need to have several attributes that independently represent different
types of statuses:
- admin_state_up
- operational status
- provisioning state
N
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.)
> 1) If an entity exists without a link to a load balancer it is purely
> just a database entry, so it would always
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) ar
14 matches
Mail list logo
