+1 for option 2.
In addition as an additional safeguard, the LBaaS service could check with
Barbican when failing to use an existing secret to see if the secret has
changed (lazy detection).
Youcef
-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Thanks Susanne, and was great meeting many of you. Actually I was trying to
find an updated version of the object model that was presented at the summit
but couldn’t find it. Is there a link online?
Youcef
From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: Monday, May 19, 2014 2:07 PM
Sam,
I think it's important to keep the Neutron API style consistent. It would be
odd if LBaaS uses a different style than the rest of the Neutron APIs.
Youcef
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Wednesday, April 30, 2014 10:59 AM
To: openstack-dev@lists.openstack.org
Stephen,
I don’t think the active/passive pools feature is referring to the HA of
loadbalancers. This is about the ability to divide the list of members
servicing load-balanced requests into 2 groups: The first one is active and the
second one is passive (or a backup pool). If all the members
, Youcef Laribi
youcef.lar...@citrix.commailto:youcef.lar...@citrix.com wrote:
Jorge,
Thanks for taking the time to put up a requirements list. Some comments below:
* Static IP Addresses
* Our current Cloud Load Balancing (CLB) offering utilizes static IP
addresses which is something our
Jorge,
Thanks for taking the time to put up a requirements list. Some comments below:
* Static IP Addresses
* Our current Cloud Load Balancing (CLB) offering utilizes static IP
addresses which is something our customers really like, especially when setting
up DNS. AWS for example,
+1
I think if we can have it before the Juno summit, we can take concrete, well
thought-out proposals to the community at the summit.
Cheers,
Youcef
From: Stephen Wong [mailto:s3w...@midokura.com]
Sent: Thursday, March 06, 2014 11:57 AM
To: OpenStack Development Mailing List (not for usage
] Mini-summit Interest?
On Thu, 2014-03-06 at 21:14 +, Youcef Laribi wrote:
+1
I think if we can have it before the Juno summit, we can take
concrete, well thought-out proposals to the community at the summit.
Unless something has changed starting at the Hong Kong design summit (which
Hi Eugene,
Having an aggregate call to get all of the stats and statuses is good, but we
should also keep the ability to retrieve statistics or the status of individual
resources IMHO.
Thanks
Youcef
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, March 05, 2014 12:42
Hi Anand,
I don't think it's fully documented in the API spec yet, but there is a
patchset being reviewed in gerrit that shows how the API would look like
(LbaasSSLDBMixin class):
https://review.openstack.org/#/c/74031/5/neutron/db/loadbalancer/lbaas_ssl_db.py
Thanks,
Youcef
From:
that whole LB configuration. Another driver
though, might be able to perform the configuration on its backend
straight-away on each API call, and still be able to comply with the object
model.
Youcef
On Thu, Feb 27, 2014 at 5:20 AM, Youcef Laribi
youcef.lar...@citrix.commailto:youcef.lar
Hi Eugene,
1) In order to allow real multiple 'vips' per pool feature, we need the
listener concept.
It's not just a different tcp port, but also a protocol, so session persistence
and all ssl-related parameters should move to listener.
Why do we need a new 'listener' concept? Since as Sam
be
free to achieve that goal in any way they see fit.
Youcef
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, February 19, 2014 8:23 AM
To: Samuel Bercovici
Cc: OpenStack Development Mailing List; Mark McClain; Salvatore Orlando;
sbaluk...@bluebox.net; Youcef Laribi; Avishay
13 matches
Mail list logo
