...@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. How the status is show on
shared entities is still yet to be determined. However, we don't have
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
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
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: [openstack-dev] [Neutron][LBaaS
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
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
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
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
, June 24, 2014 at 6:02 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status
Ultimately, as we will have several objects which have many
@lists.openstack.org
Date: Tuesday, June 24, 2014 at 6:02 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@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
10 matches
Mail list logo
