I think you should update the current reviews (new patch set, not additional
review.)
+1
I like those changes: +2
-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com]
Sent: Sunday, August 10, 2014 12:51 AM
To: OpenStack Development Mailing List (not for usage
Hi
The right layer for this validation is the Neutron REST layer.
Since the current validation engine in this layer can only do attribute level
validation (e.g make sure timeout is int and timeout 5) but can't do entity
level validation (e.g timeout delay), you can find entity level
+1
-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Tuesday, September 02, 2014 8:13 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas][octavia]
Hi Susanne and everyone,
My opinions are that keeping it in stackforge
Sorry for the broken link
Here is a better one:
https://docs.google.com/drawings/d/119JV_dG_odWVVKTcn51qyRh3rW-253uUqfcg9CFQDtg/pub?w=960h=720
Sent from my iPhone
On 8 בדצמ 2013, at 17:31, Avishay Balderman
avish...@radware.commailto:avish...@radware.com wrote:
Hi
I was thinking about
Hi
Looking at
https://github.com/openstack/neutron/tree/master/neutron/tests/unit/db I see
that the way we currently test the DB layer is via the REST API layer.
Why do we mix those 2 layers in one UT?
Those 2 layers are not related to each other and the DB UT should run directly
against the
Hi
There are 2 fields in the L7 model that are candidates for being a closed set
(Enum).
I would like to hear your opinion.
Entity: L7Rule
Field : type
Description: this field holds the part of the request where we should look for
a value
Possible values: URL,HEADER,BODY,(?)
Entity: L7Rule
(removing extra space from the subject - let email clients apply their filters)
From: Avishay Balderman
Sent: Sunday, February 16, 2014 9:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] L7 data types
Hi
There are 2 fields in the L7
Hi
Question:
Do we want to block the deletion of L7Policy if it is associated with a Vip
already?
In my eyes we can do that, it will drop the L7PolicyVip assoc from DB. All we
have to do is invoke the driver and let him know that a L7Policy was removed.
At the end of the day it will be the
, Avishay Balderman
avish...@radware.commailto:avish...@radware.com wrote:
Hi
L7Policy holds a list of L7rules plus 1 attribute: name .
Questions:
1) Do we need to have this name attribute?
2) Do we want to allow update operation of the name attribute? Do we need
to invoke the driver when
at the moment).
Thanks,
Stephen
On Tue, Feb 18, 2014 at 3:58 AM, Avishay Balderman
avish...@radware.commailto:avish...@radware.com wrote:
Here are the suggested values for the attributes below:
• Entity: L7Rule
o Attribute: type
• Possible values:
• HOST_NAME
• PATH
Anyone else is facing this bug? https://bugs.launchpad.net/nova/+bug/1296808
Thanks
Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi
It feels like a driver specific topic.
So I am not sure we can come to a generic solution in the lbaas core code.
Thanks
Avishay
From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Tuesday, October 29, 2013 11:19 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev]
Hi
Some of the DB entities in the LBaaS domain inherit from
HasStatusDescriptionhttps://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L40
With this we can set the entity status (ACTIVE, PENDING_CREATE,etc) and a
description for the status.
There are flows in the Radware LBaaS
be bad enough for a developer to decide to switch over to
Cloudstack or AWS APIs!
Salvatore
PS: On the last point I am obviously joking, but not so much.
On 12 November 2013 08:00, Avishay Balderman
avish...@radware.commailto:avish...@radware.com wrote:
Hi
Some of the DB entities
to not provide tenants any detail about the peculiar driver being used.
On this note however, this is just my personal opinion. I'm sure there are
plenty of valid use cases for giving tenants vendor-specific error messages.
Salvatore
On 19 November 2013 13:00, Avishay Balderman
avish
1) Done
2) Done
3) Attaching a pool to a vip is a private use case. The 'action' can also
'reject the traffic' or something else. So the 'Action' ,ay tell that we need
to attach Vip X to Pool Y
4) Not sure .. It is an open discussion for now.
5) See #4
Yes -
Hi
I was thinking about a different way for L7 modeling.
The key points are:
- The Rule has no action attribute
- A Policy is a collection of rules
- Association keep a reference to a Vip and to a Policy
- Association holds the action (what to do if the Policy return True)
- Association holds
Hi
Please review.
https://review.openstack.org/#/c/99709/
Thanks
Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
of validation should perhaps be
performed in the DB layer. I think this already happens for several API
resources.
Salvatore
On 5 June 2014 13:01, Avishay Balderman
avish...@radware.commailto:avish...@radware.com wrote:
Hi
With the current REST API engine in neutron we can declare attributes
validations
Hi
As the lbass mid cycle sprint starts today, is there any way to track and
understand the progress (without flying to Texas... )
Thanks
Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Hi
One of L7 Rule attributes is ‘compare_type’.
This field is the match operator that the rule should activate against the
value found in the request.
Below is list of the possible values:
- Regexp
- StartsWith
- EndsWith
- Contains
- EqualTo (*)
- GreaterThan (*)
- LessThan (*)
The last 3
identifying the unsupported
feature.
-Dustin
On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman
avish...@radware.commailto:avish...@radware.com wrote:
Hi
One of L7 Rule attributes is ‘compare_type’.
This field is the match operator that the rule should activate against the
value found in the request
Hi
Can you please review: https://review.openstack.org/#/c/99709/10
Thanks
Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi
Please review: https://review.openstack.org/#/c/105669/
Thanks
Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Adding Radware v2 driver design doc:
https://review.openstack.org/#/c/105669/
-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Sunday, July 20, 2014 2:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev]
We still need another core to approve L7
https://review.openstack.org/#/c/99709
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 22, 2014 3:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Update on specs
Hi
In the LBaaS DB layer there is a utility method (‘_get_resource’) that takes
entity type and the entity id and fetch it from DB.
If the entity can’t be found in DB the method throws a specific exception.
Example:
If we were looking for a Pool and it was not found in DB -- throw PoolNotFound
The same applies for the ‘XInUse’ exception – we have specific exception for
each entity that is ‘inUse’
Examples:
HealthMonitorInUse
PoolInUse
etc
I think that EnityInUse exception is good enough
Avishay
From: Avishay Balderman
Sent: Thursday, July 24, 2014 10:20 AM
To: OpenStack Development
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: OpenStack Development Mailing List;
29 matches
Mail list logo
