Hi,
Validations such as "timeout > delay" should be performed on the API level
before it reaches the driver.
For a configuration tree (lb, listeners, pools, etc.), there should be one
provider.
Having provider defined in multiple places does not make sense.
-San.
From: Vijay Venkatachalam [
m, at some future date, without an interface change. If my
bias is showing that I¹m not a fan of adding this complexity for that, I¹m not
surprised.
Thanks,
doug
On 8/11/14, 7:57 AM, "Samuel Bercovici" wrote:
>Hi,
>
>Validations such as ³timeout > delay² should be perfor
...@citrix.com]
Sent: Wednesday, November 20, 2013 8:06 AM
To: Eugene Nikanorov
Cc: Samuel Bercovici; Avishay Balderman; openstack-dev@lists.openstack.org
Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi Eugene,
The proposal is simple, create a separate resource
Hi Stephen,
When this was discussed in the past, customer were not happy about storing
their SSL certificates in the OpenStack database as plain fields as they felt
that this is not secured enough.
Do you say, that you are OK with storing SSL certificates in the OpenStack
database?
-Sam.
--
gt; Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
>
> Hi,
>
> On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote:
> > Hi,
> >
> >
> >
> > Evgeny has outlined the wiki for the proposed change at:
> > https://wiki.openstack
en.g...@guardian.co.uk]
> > Sent: Wednesday, November 20, 2013 3:01 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination
> > write-up
> >
> > Hi,
> >
> > On Wed, 2013-
Hi Eugene,
We currently support out-of-the-box VIP and Nodes on the same network.
The VIP can be associated with a floating IP if need to access from the
"external" network.
We are considering other options but will address as we get to this.
Regards,
-Sam.
From: Eugene Nikanor
Hi Stephen,
To make sure I understand, which model is fine "Basic/Simple" or "New".
Thanks,
-Sam.
-Original Message-
From: Stephen Gran [mailto:stephen.g...@theguardian.com]
Sent: Thursday, December 05, 2013 8:22 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-
icates
>> in a smarter system if we decide we want to do things like evaluate
>> trust models, but just storing them locally for now will do most of
>> what I think people want to do with SSL termination.
>>
>> Cheers,
>>
>>
>> On 05/12/13 09:57, S
Hi,
We plan to address LBaaS in ceilometer for Juno.
A blue print was registered
https://blueprints.launchpad.net/neutron/+spec/lbaas-ceilometer-integration
Please use the following google document to add include requirements and
thoughts at:
https://docs.google.com/document/d/1mrrn6DEQkiySwx4
to do syntax checking without choosing one particular
configuration format in which rules can be specified (in our case, haproxy). I
suppose we could invent our own pseudo rule language-- but why bother when
haproxy has already done this, eh?
I'll take a look at the SSL stuff next, then th
model change - Layer
7 support
Howdy, Sam!
Thanks also for your speedy response. Comments / additional questions are
in-line below:
On Wed, Feb 12, 2014 at 2:51 AM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
We have reviewed this based on capabilities that we belive co
Have modified the document access, let me know if you still have issues.
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, February 13, 2014 4:02 AM
To: Samuel Bercovici
Cc: OpenStack Development Mailing List (not for usage questions);
rw3...@att.com; David Patterson; Eugene
Hi,
My concern is that if from some reason the driver implementer would like to
reflect the name also in the backend device, than an update should also be
calling the driver.
Using readable names also makes sense on the back-end device.
-Sam.
From: Oleg Bondarev [mailto:obonda...@mirantis.com
etween name and the id.
Thanks,
Eugene.
On Mon, Feb 17, 2014 at 1:57 PM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
Hi,
My concern is that if from some reason the driver implementer would like to
reflect the name also in the backend device, than an update should also be
call
means that all those vips will be placed on the same place as
the pool they are pointing to as their default pool.
Regards,
-Sam.
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Tuesday, February 18, 2014 9:35 PM
To: OpenStack Development Mailing List
Cc:
Hi,
I also agree that the model should be pure logical.
I think that the existing model is almost correct but the pool should be made
pure logical. This means that the vip <>pool relationships needs also to
become any to any.
Eugene, has rightfully pointed that the current "state" management
Bercovici
Sent: Monday, February 24, 2014 7:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion
Hi,
I also agree that the model should be pure logical.
I think that the existing model is almost
_PORT, default_pool=$POOL-1... --> $VIP-1
lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... --> $VIP-2
Youcef
From: Eugene Nikanorov
[mailto:enikano...@mirantis.com<mailto:enikano...@mirantis.com>]
Sent: Wednesday, February 26, 2014 1:26 PM
To: Samuel Bercovici
Cc:
-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... --> $VIP-2
Youcef
From: Eugene Nikanorov
[mailto:enikano...@mirantis.com<mailto:enikano...@mirantis.com>]
Sent: Wednesday, February 26, 2014 1:26 PM
To: Samuel Bercovici
Cc: OpenStack Development Mailing List (not f
Rabi,
This is correct.
The API does allow you to do so.
-Sam.
-Original Message-
From: Rabi Mishra [mailto:ramis...@redhat.com]
Sent: Wednesday, February 26, 2014 1:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Sign
Hi,
The discussion about advanced services and scheduling was primarily around
choosing backbends based on capabilities.
AFAIK, the Nova flavor specify capacity.
So I think that using the term "flavor" might not match what is intended.
A better word might be "capability" or "group of capabilities
Hi,
Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would
like to remind everyone why we choose to follow a model where pools and
listeners are shared (many to many relationships).
Use Cases:
1. The same application is being exposed via different LB objects.
For example
ugh, I feel like we should walk before we run: Implementing 1:1
initially is a good idea to get us rolling. Whether we then implement 1:N or
M:N after that is another question entirely. But in any case, it seems like a
bad idea to try to start with M:N.
Stephen
On Thu, Nov 20, 2014 at 4:52 AM, Samuel
ght be too general to, for
> example, represent the UP/DOWN status of members of a given pool.)
>
>
> Also, from an haproxy perspective, sharing pools within a single
> listener actually isn't a problem. That is to say, having the same
> L7Policy pointing at the same pool is OK, s
lly isn't a problem. That is to say, having the same
> L7Policy pointing at the same pool is OK, so I personally don't have a
> problem allowing sharing of objects within the scope of parent
> objects. What do the rest of y'all think?
>
>
> Stephen
>
>
>
el for statuses. Showing these in the body of load
balancer details can get quite large.
I hope this makes sense because my brain is ready to explode.
Thanks,
Brandon
On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
> Brandon, can you please explain further (1) bellow?
>
t response, allowing too many many to many
relationships feels like a solution to a problem that doesn't really exist, and
introduces a lot of unnecessary complexity.
Stephen
On Sun, Dec 7, 2014 at 11:43 PM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
+1
From: Stephen Bal
+1
I also prefer option 2 in general with slight inclination to 2-B
-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Friday, January 23, 2015 9:21 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][lbaas] Object statuses
So I am
s all week as I've been
working on the API revision proposal, and I'd like to get them recorded and /
or discussed.)
Stephen
On Tue, Apr 22, 2014 at 1:26 AM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
Hi,
I have seen a few addition to
https://docs.google.com/document/
Hi,
The work to design the APIs concerning L7 content switching and SSL termination
has started a bit before the Icehouse summit, it involved the ML in a very
active fashion.
The ML was silent on this because we have completed the discussion and moved to
implementation.
We got to a very advance
Hi,
I was just working to push the use cases into the new format .rst but I agree
that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at -
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-m
t;
Getting the admin/operator use cases in there would be good as well Stephen.
Thanks,
Kyle
> Thanks,
> Stephen
>
>
>
>
> On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German
> wrote:
>>
>> Sam,
>>
>> The use cases where pretty complete the last
tion between them.
L7 Policies have an ordered list of L7 Rules, L7 Rules are processed by this
order and also form an ‘or’ condition.
Regards,
-Avishay, Evgeny and Sam
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Sunday, April 27, 2014 1:53 PM
To: OpenStack Dev
ready for the
summit.
German
-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Monday, April 28, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
Hi,
I was
Hi,
As stated, this could either be handled by SSL session ID persistency or by SSL
termination and using cookie based persistency options.
If there is no need to inspect the content hence to terminate the SSL
connection on the load balancer for this sake, than using SSL session ID based
persis
Hi Everyone,
During the last few days I have looked into the different LBaaS API proposals.
I have also looked on the API style used in Neutron. I wanted to see how
Neutron APIs addressed "tree" like object models.
Follows my observation:
1. Security groups -
http://docs.openstack.org/ap
Hi Everyone!
To assist in evaluating the use cases that matter and since we now have ~45 use
cases, I would like to propose to conduct a survey using something like
surveymonkey.
The idea is to have a non-anonymous survey listing the use cases and ask you
identify and vote.
Then we will publish
Hi Vijay,
I have looked at the Barbican APIs –
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
I was no able to see a “native” API that will accept an SSL certificate
(private key, public key, CSR, etc.) and will store it.
We can either store the whole certificate as
I think that associating a VIP subnet and list of member subnets is a good
choice.
This is declaratively saying to where is the configuration expecting layer 2
proximity.
The minimal would be the VIP subnet which in essence means the VIP and members
are expected on the same subnet.
Any member o
s or do anything else that
has to do with L7).
Stephen
On Wed, Apr 30, 2014 at 9:39 AM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
Hi,
As stated, this could either be handled by SSL session ID persistency or by SSL
termination and using cookie based persistency options.
If there
ions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs
Hi Samuel,
We talked a bit in chat about this, but I wanted to reiterate a few things here
for the rest of the group. Comments in-line:
On Wed, Apr 30, 2014 at 6:10 A
crazy jumps of logic, and that's not how you intended
it? That said, even if that wasn't your intention, could it work that way? It
seems like that allows a decent amount of options… :)
--Adam
On Fri, May 2, 2014 at 4:59 AM, Samuel Bercovici
mailto:samu...@radware.com>
facing use
cases and hope to send it to ML ASAP.
Regards,
-Sam.
From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
Subject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey
Hi
week so we can have enough information to
base decisions next week.
Regards,
-Sam.
From: Samuel Bercovici
Sent: Monday, May 05, 2014 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey
Hi,
I
The survey is not anonymous and I plan to publish it with its raw data we can
then discuss how to interpret.
Each use case has an accompanying text field so that you can add any comments
you wish.
At least I did add comments to most use cases when I responded :-)
-Sam.
-Original Message--
least I'd hope!
Cheers,
--Jorge
From: Samuel Bercovici mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, May 6, 2014 2:56 AM
To: "OpenStack De
Hi,
I have added to https://etherpad.openstack.org/p/AdvancedServices_and_Neutron a
note recalling two technical challenges that do not exists when LBaaS runs as
a Neutron extension.
-Sam.
From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: Wednesday, May 07, 2014 2:45 PM
To: OpenStack De
coding in earnest for
Juno.
The Container resource is intended to capture/store the final certificate
details.
Thanks,
John
From: Samuel Bercovici [samu...@radware.com]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage
6 people have completed the survey so far.
From: Samuel Bercovici
Sent: Tuesday, May 06, 2014 10:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey
Hi Everyone,
The survey is now live via: http://eSurv.org
List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN
On May 7, 2014, at 10:53 AM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
Hi John,
If the user already has an SSL certificate that was acquir
e by which we should have
filled out the survey to get our voices heard?
Thanks,
Stephen
On Wed, May 7, 2014 at 2:16 PM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
6 people have completed the survey so far.
From: Samuel Bercovici
Sent: Tuesday, May 06, 2014 10:56 AM
To: OpenS
Brandon,
Can you please provide statistics on the distribution between the relationships
between load balancer and VIPs in your environment?
-Sam.
-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Friday, May 09, 2014 6:40 PM
To: openstack-dev@lists.ope
It boils down to two aspects:
1. How common is it for tenant to care about affinity or have more than a
single VIP used in a way that adding an additional (mandatory) construct makes
sense for them to handle?
For example if 99% of users do not care about affinity or will only use a
singl
During our brief meeting today, we tentatively scheduled to meet today at 5:30
PM.
Is this still on?
Where should we meet?
Regards,
-Sam.
On May 12, 2014, at 1:10 PM, "Adam Harwell"
mailto:adam.harw...@rackspace.com>> wrote:
Some of us are at a table towards the back by the B3b d
ote:
Sam,
That deadline seems reasonable to me. I should have time later today or later
this weekend to fill it out.
Thanks,
Stephen
On Fri, May 9, 2014 at 9:21 AM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
Hi,
9 people have filled the survey so far.
See attached pdf.
Regards
Hi Everyone,
https://etherpad.openstack.org/p/juno-lbaas-design-session
Feel free to modify and update, please make sure you use your name so we will
know who have added the modification.
Regards,
-Sam.
___
OpenStack-dev mailing list
usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad
Hi,
I see the following statement in the doc.
>>multiple loadbalancers may referenece the same listener
Does this mean listeners are independent of loadbalancer?
Thanks,
Vijay V.
From: Samuel Ber
Hi Everyone,
https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7
Feel free to modify and update, please make sure you use your name so we will
know who have added the modification.
Regards,
-Sam.
___
OpenStack-dev mailing list
OpenS
Hi Everone,
I would like to defer addressing client authentication and back-end-server
authentication for a 2nd phase - after Juno.
This means that from looking on
https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7 , under the "SSL/TLS
Termination capabilities", not addressing 2.2 and 3.
I t
This very good news.
Please point to the code review in gerrit.
-Sam.
-Original Message-
From: Eichberger, German [mailto:german.eichber...@hp.com]
Sent: Saturday, May 24, 2014 12:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutro
+1 to Carlos.
In addition, there should be possible for LBaaS (It might only be just the
LBaaS drivers) to get the information including the private key back so that
the backend can use it.
This means that a "trusted" communication channel between the driver and
Barbican needs to be established
Before solving everything, I would like first to itemize the things we should
solve/consider.
So pleas focus first on what is it that we need to pay attention for and less
on how to solve such issues.
Follows the list of items:
· Provisioning status/state
o Should it only be on the l
lbaas" extension that has the "old
API" but redirect to the "new API"
Doing 2, can allow "co-existence" of old code with old drivers until new code
with new drivers can take its place.
Regards,
-Sam.
-Original Message-
From: Brandon Logan [m
-Original Message-
From: Samuel Bercovici
Sent: Sunday, June 01, 2014 10:19 AM
To: 'Brandon Logan'; OpenStack Development Mailing List (not for usage
questions); Eugene Nikanorov (enikano...@mirantis.com)
Subject: RE: Your suggestions in the BP
Hi Brandon Eugene and Everyon
Hi,
I think that option 2 should be preferred at this stage.
I also think that certificate should be immutable, if you want a new one,
create a new one and update the listener to use it.
This removes any chance of mistakes, need for versioning etc.
-Sam.
-Original Message-
From: Jorge
: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas
+1 for the idea of making certificate immutable.
However, if Barbican allows updating certs/containers then versioning is a must.
Thanks,
Vivek
On 6/8/14, 11:48 PM, "Samuel Bercovici" wrote:
>Hi,
&g
To elaborate on the case where containers get deleted while LBaaS still
references it.
We think that the following approach will do:
* The end user can delete a container and leave a "dangling" reference
in LBaaS.
* It would be nice to allow adding meta data on the container so
Thank you for this. I think it can stream line the meeting!
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Thursday, June 12, 2014 1:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Weekly Standup Trial
Hey Neut
Hi,
In
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=sharing
referenced by the Wiki, I have added the section that address the items raised
on the last irc meeting.
Regards,
-Sam.
From: Samuel Bercovici
Sent: Wednesday, February 26
Hi,
The wiki is updated to reflect the APIs.
Regards,
-Sam.
From: Palanisamy, Anand [mailto:apalanis...@paypal.com]
Sent: Thursday, March 06, 2014 3:26 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [LBaaS] API spec for SSL Support
Hi All,
Please let us kn
Hi,
As an example you can look at
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=sharing
Under the “Logical Model + Provisioning Status + Operation Status + Statistics”
there are some details on thoughts on how to implement this.
Regards,
Hi Eugene,
I am with Evgeny on a business trip so we will not be able to join this time.
I have not seen any progress on the model side. Did I miss anything?
Will look for the meeting summary
Regards,
-Sam.
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday,
Discussing some "radical" concepts...
I also agree that there should be different attribute to reflect the
administrator state, operation state and the "provisioning" state.
This is already reflected in
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=shar
+1
-Original Message-
From: Ryan O'Hara [mailto:roh...@redhat.com]
Sent: Wednesday, March 19, 2014 2:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki
On Tue, Mar 18, 2014 at 10:57:15PM +, Jorge Mira
Per the last LBaaS meeting.
1. Please find a list of use cases.
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
a) Please review and see if you have additional ones for the project-user
b) We can then chose 2-3 use cases to play
scalability.
On 6 April 2014 07:51, Samuel Bercovici wrote:
> Per the last LBaaS meeting.
>
>
>
> 1. Please find a list of use cases.
>
> https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1
> -mXuSINis/edit?usp=sharing
>
>
>
> a) Please r
f the above,
is this something being considered?
On 7 April 2014 05:27, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
> Please elaborate, do you mean that the nodes could be on different
> zones/cells or something else?
>
>
> -Original Message-
> From:
Hi,
I have looked at
https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1
and have a few questions:
1. Monitoring Tab:
a. Are there users that use load balancing who do not monitor members?
Can you share the use cases where
Hi,
I have seen a few addition to
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
I think that it would make sense to keep this document with uses cases that
were discussed in ML.
A use case that I have seen and is missing is related to availability zon
Hi,
The work on SSL termination has started and is very near completion.
the blue print is in
https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination and wiki
is in https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
Do you see anything missing there?
Regards,
-Sam.
For us in Israel, the earlier the better.
The current meeting time is very good for us, although I understand it too
early for some.
-Sam.
From: Gregory Lebovitz [mailto:gregory.i...@gmail.com]
Sent: Wednesday, November 05, 2014 1:10 PM
To: OpenStack Development Mailing List (not for usage quest
to:carlos.ga...@rackspace.com<mailto:carlos.ga...@rackspace.com>]
>>> Sent: Tuesday, June 10, 2014 12:18 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
>>> document on Gerr
To reiterate the Juno release plan from:
https://wiki.openstack.org/wiki/Juno_Release_Schedule
Feature freeze is at: 21st August.
I am listing tasks which we should consider to be done for Juno and who should
handle them.
The following might be considered as critical path to get anything for Ju
Hi,
For logical objects that were deleted but the backend did not execute on, there
is a PENDING_DELETE state.
So currently there is PENDING_CREATE --> CREATE, PENDING_UPDATE-->UPDATE and
PENDING_DELETE-->object is removed from the database.
If an error occurred that the object is in ERROR state
I prefer IRC only.
As I am located in Israel and so are other Radware people, it is easier for us
to use IRC which is also more available from more devices and locations.
OpenStack has chosen IRC as a way to allow different people from different
places and different speaking capabilities to work
This is also my understanding.
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, July 10, 2014 6:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor
Per the IRC discussion this morning, I
parallel if we had
extra resources. This shim will have odd corner cases (a second listener on a
vip, e.g.), which will chuck errors.
The ref haproxy driver is highest priority, and thus the v2 agent, as lbaas v2
goes nowhere without it.
Doug
From: Samuel Bercovici mailto:samu...@radware.com
used without the agent, if so
could you explain how?
Thanks,
Dustin Lundquist
On Thursday, July 10, 2014, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
New/updated v2 driver could be done without an agent (same as was possible in
v1).
From: Doug Wiegley
[mailto:do...@a10network
Hi,
I think that the discussion have asked that obtaining information out of the
x509 via the SAN field will not be defined as mandatory.
For example Radware's backend extracts this information from the x509 in the
(virtual) device itself, specifying dns values different than what exists in
th
reated, and if we were to treat SANs differently then we're
both breaking the standard and setting a bad precedent.
Stephen
On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza
mailto:carlos.ga...@rackspace.com>> wrote:
On Jul 15, 2014, at 10:55 AM, Samuel Bercovici
mailto:samu...@radware.
Hi,
Please note that if the following will not get approved this week they will not
be done in Juno which is a pity considering their almost final state.
https://review.openstack.org/#/c/98640/ - TLS termination
https://review.openstack.org/#/c/99709/ - L7 Content Switching
Please see if there i
Stephen,
This will increase the complexity of the code since it will add managing the
cache lifecycle in tandem with the barbican back end and the fact that
containers may be shared by multiple listeners.
At this stage, I think that it serves us all to keep the code at this stage as
small and s
one tenant to a
non-shared network in another tenant
Hi
I have opened two bugs that are related to the topic below:
https://bugs.launchpad.net/neutron/+bug/1221315
https://bugs.launchpad.net/nova/+bug/1221320
Thanks
Avishay
From: Samuel Bercovici
Sent: Wednesday, August 07, 2013 1:05 PM
To
Hi,
Although not a voting member, I would like to thank Mark for a phenomenal job
on Neutron and LBaaS and would like to see him continue to lead Neutron forward.
Regards,
-Sam.
-Original Message-
From: Mark McClain [mailto:mark.mccl...@dreamhost.com]
Sent: Friday, September 2
Hi,
I assume you are proposing 8:00AM and not 8:00PM PDT.
I will not be able to attend on this time.
Better time for me is between 10:00AM PDT - 12:00AM PDT
Thanks,
-Sam.
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, October 23, 2013 11:51 AM
To:
Hi,
Please find a summary of talks and discussion related to LBaaS for the summit
at:
https://docs.google.com/document/d/1Vjm57lh7PnXDelOy-VxsJkzc8QRiNN368sS11ePs_vA/edit?pli=1#heading=h.6doqijxd389j
I have also added the list bellow to it.
We can review in the meeting today.
Regards,
Hi,
I think that the current implementation is fine.
This are two different aspects.
The status describes whether the last a-sync activity is active or whether it
is not.
The admin status describes what the user wishes for the object status to be.
Follows an example: If I update the VIP with adm
Hi,
I have created two document to discuss SSL termination and L7 Rules at:
SSL termination :
https://docs.google.com/document/d/1qnoJLD1txY5wnjx4k480AtEGCOEtkPMvTzxPo3_DPcs/edit?usp=sharing
SSL BP: https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination
L7 Rules:
https://docs.goog
Hi,
I will not be able to join the meeting this time.
For item 1. We are starting to work on SSL termination and L7 based routing.
Regards,
-Sam.
On Nov 12, 2013, at 9:30 PM, "Eugene Nikanorov"
mailto:enikano...@mirantis.com>> wrote:
Hi folks,
LBaaS subteam meeting will be held o
1 - 100 of 139 matches
Mail list logo
