Re: [openstack-dev] [Neutron][LBaaS] Improvements to current reviews

[Avishay Balderman]

" 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 questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Improvements to current reviews

I think you should update the current reviews (new patch set, not additional 
review.)

Doug


> On Aug 9, 2014, at 3:34 PM, "Brandon Logan"  
> wrote:
> 
> So I've done some work on improving the code on the current pending 
> reviews.  And would like to get peoples' opinions on whether I should 
> add antoher patch set to those reviews, or add the changes as as 
> another review dependent on the pending ones.
> 
> To be clear, no matter what the first review in the chain will not
> change:
> https://review.openstack.org/#/c/105331/
> 
> However, if adding another patch set is preferrable then plugin and db 
> implementation review would get another patch set and then obviously 
> anything depending on that.
> 
> https://review.openstack.org/#/c/105609/
> 
> My opinion is that I'd like to get both of these in as a new patch set.
> Reason being that the reviews don't have any +2's and there is 
> uncertainty because of the GBP discussion.  So, I don't think it'd be 
> a major issue if a new patch set was created.  Speak up if you think 
> otherwise.  I'd like to get as many people's thoughts as possible.
> 
> The changes are:
> 
> 1) Added data models, which are just plain python object mimicking the 
> sql alchemy models, but don't have the overhead or dynamic nature of 
> being sql alchemy models.  These data models are now returned by the 
> database methods, instead of the sql alchemy objects.  Also, I moved 
> the definition of the sql alchemy models into its own module.  I've 
> been wanting to do this but since I thought I was running out of time 
> I left it for later.
> 
> These shouldn't cause many merge/rebase conflicts, but it probably 
> cause a few because the sql alchemy models were moved to a different module.
> 
> 
> 2) The LoadBalancerPluginv2 no longer inherits from the 
> LoadBalancerPluginDbv2.  The database is now a composite attribute of 
> the plugin (i.e. plugin.db.get_loadbalancer()).  This cleans up the 
> code a bit and removes the necessity for _delete_db_entity methods 
> that the drivers needed because now they can actually call the database 
> methods.
> Also, this makes testing more clear, though I have not added any tests 
> for this because the previous tests are sufficient for now.  Adding 
> the appropriate tests would add 1k or 2k lines most likely.
> 
> This will likely cause more conflicts because the _db_delete_entity 
> methods have been removed.  However, the new driver interface/mixins 
> defined a db_method for all drivers to use, so if that is being used 
> there shouldn't be any problems.
> 
> Thanks,
> Brandon
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver interface on every API request"

[Avishay Balderman]

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 validation 
code  in the lbaas plugin layer and in DB layer.

As far as I understand the REST engine of Neutron is about to be replaced (I 
hope before the Z version :) ) and I hope the new engine will be able to run 
entity level validations.

Avishay

From: Samuel Bercovici
Sent: Monday, August 11, 2014 4:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver 
interface on every API request"

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 [mailto:vijay.venkatacha...@citrix.com]
Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver 
interface on every API request"

Hi:

Continuing from last week's LBaaS meeting...

Currently an entity cannot be sent to driver unless it is linked to 
loadbalancer because loadbalancer is the root object and driver information is 
only available with loadbalancer.

The request to the driver is delayed because of which error propagation becomes 
tricky.

Let's say a monitor was configured with timeout > delay there would be no error 
then.
When a listener is configured there will be a monitor creation/deployment error 
like "timeout configured greater than delay".

Unless the error is very clearly crafted the user won't be able to understand 
the error.

I am half-heartedly OK with current approach.

But, I would prefer Brandon's Solution - make provider an attribute in each of 
the entities to get rid of this problem.

What do others think?

Thanks,
Vijay V.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas][octavia]

[Avishay Balderman]

+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 until it gets mature is the best 
solution.  I'm pretty sure we can all agree on that.  Whenever it is mature 
then, and only then, we should try to get it into openstack one way or another. 
 If Neutron LBaaS v2 is still incubated then it should be relatively easy to 
get it in that codebase.  If Neutron LBaaS has already spun out, even easier 
for us.  If we want Octavia to just become an openstack project all its own 
then that will be the difficult part.

I think the best course of action is to get Octavia itself into the same 
codebase as LBaaS (Neutron or spun out).  They do go together, and the 
maintainers will almost always be the same for both.  This makes even more 
sense when LBaaS is spun out into its own project.

I really think all of the answers to these questions will fall into place when 
we actually deliver a product that we are all wanting and talking about 
delivering with Octavia.  Once we prove that we can all come together as a 
community and manage a product from inception to maturity, we will then have 
the respect and trust to do what is best for an Openstack LBaaS product.

Thanks,
Brandon

On Mon, 2014-09-01 at 10:18 -0400, Susanne Balle wrote:
> Kyle, Adam,
> 
>  
> 
> Based on this thread Kyle is suggesting the follow moving forward
> plan: 
> 
>  
> 
> 1) We incubate Neutron LBaaS V2 in the “Neutron” incubator “and freeze 
> LBaas V1.0”
> 2) “Eventually” It graduates into a project under the networking 
> program.
> 3) “At that point” We deprecate Neutron LBaaS v1.
> 
>  
> 
> The words in “xx“ are works I added to make sure I/We understand the 
> whole picture.
> 
>  
> 
> And as Adam mentions: Octavia != LBaaS-v2. Octavia is a peer to F5 / 
> Radware / A10 / etc appliances which is a definition I agree with BTW.
> 
>  
> 
> What I am trying to now understand is how we will move Octavia into 
> the new LBaaS project?
> 
>  
> 
> If we do it later rather than develop Octavia in tree under the new 
> incubated LBaaS project when do we plan to bring it in-tree from 
> Stackforge? Kilo? Later? When LBaaS is a separate project under the 
> Networking program?

>  
> 
> What are the criteria to bring a driver into the LBaaS project and 
> what do we need to do to replace the existing reference driver? Maybe 
> adding a software driver to LBaaS source tree is less of a problem 
> than converting a whole project to an OpenStack project.

>  
> 
> Again I am open to both directions I just want to make sure we 
> understand why we are choosing to do one or the other and that our  
> decision is based on data and not emotions.
> 
>  
> 
> I am assuming that keeping Octavia in Stackforge will increase the 
> velocity of the project and allow us more freedom which is goodness.
> We just need to have a plan to make it part of the Openstack LBaaS 
> project.
> 
>  
> 
> Regards Susanne
> 
> 
> 
> 
> On Sat, Aug 30, 2014 at 2:09 PM, Adam Harwell 
>  wrote:
> Only really have comments on two of your related points:
> 
> 
> [Susanne] To me Octavia is a driver so it is very hard to me
> to think of it as a standalone project. It needs the new
> Neutron LBaaS v2 to function which is why I think of them
> together. This of course can change since we can add whatever
> layers we want to Octavia.
> 
> 
> [Adam] I guess I've always shared Stephen's
> viewpoint — Octavia != LBaaS-v2. Octavia is a peer to F5 /
> Radware / A10 / etcappliances, not to an Openstack API layer
> like Neutron-LBaaS. It's a little tricky to clearly define
> this difference in conversation, and I have noticed that quite
> a few people are having the same issue differentiating. In a
> small group, having quite a few people not on the same page is
> a bit scary, so maybe we need to really sit down and map this
> out so everyone is together one way or the other.
> 
> 
> [Susanne] Ok now I am confused… But I agree with you that it
> need to focus on our use cases. I remember us discussing
> Octavia being the refenece implementation for OpenStack LBaaS
> (whatever that is). Has that changed while I was on vacation?
> 
> 
> [Adam] I believe that having the Octavia "driver" (not the
> Octavia codebase itself, technically) become the reference
> implementation for Neutron-LBaaS is still the plan in my eyes.
> The Octavia Driver in Neutron-LBaaS is a separate bit of code
> from the actual Octavia project, similar to the way the A10
> driver is a separate bit of code from the A10 app

Re: [openstack-dev] [Neutron] - Vendor specific erros

[Avishay Balderman]

Hi
We need to take into account that the tenant is well aware to the LBaaS 
provider (driver) that he is working with.  After all when the tenant create 
Pool he needs to select a provider.
Can you please change the bug status? 
https://bugs.launchpad.net/neutron/+bug/1248423
The current status is "Incomplete" which is wrong. A much better status would 
be:
"Opinion"   OR "Confirmed"

Thanks
Avishay

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Tuesday, November 19, 2013 7:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] - Vendor specific erros

Thanks Avishay.

I think the status description error was introduced with this aim.
Whether vendor-specific error descriptions can make sense to a tenant, that's a 
good question.
Personally, I feel like as a tenant that information would not be a lot useful 
to me, as I would not be able to do any debug or maintenance on the appliance 
where the error was generated; on the other hand, as a deployer I might find 
that message very useful, but probably I would look for it in the logs rather 
than in API responses; furthermore, as a deployer I might find more convenient 
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 
mailto:avish...@radware.com>> wrote:
Hi Salvatore
I think you are mixing between the state machine (ACTIVE,PENDEING_XYZ,etc)  and 
the status description
All I want to do is to write a vendor specific error message when the state is 
ERROR.
I DO NOT want to touch the state machine.

See: https://bugs.launchpad.net/neutron/+bug/1248423

Thanks

Avishay

From: Salvatore Orlando [mailto:sorla...@nicira.com<mailto:sorla...@nicira.com>]
Sent: Thursday, November 14, 2013 1:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] - Vendor specific erros

In general, an error state make sense.
I think you might want to send more details about how this state plugs into the 
load balancer state machine, but I reckon it is a generally non-recoverable 
state which could be reached by any other state; in that case it would be a 
generic enough case which might be supported by all drivers.

It is good to point out that driver-specific state transitions however, in my 
opinion, are to avoid; application using the Neutron API will become 
non-portable, or at least users of the Neutron API would need to be aware that 
an entity might have a different state machine from driver to driver, which I 
reckon would 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 
mailto:avish...@radware.com>> wrote:

Hi
Some of the DB entities in the LBaaS domain inherit from 
HasStatusDescription<https://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 driver that the  driver needs to set the 
entity status to ERROR and it is able to set the description of the error -  
the description is Radware specific.
My question is:  Does it make sense to do that?
After all the tenant is aware to the fact that he works against Radware load 
balancer -  the tenant selected Radware as the lbaas provider in the UI.
Any reason not to do that?

This is a generic issue/question and does not relate  to a specific plugin or 
driver.

Thanks

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] L7 Switching

[Avishay Balderman]

Hi
I have created this wiki page: (WIP)
https://wiki.openstack.org/wiki/Neutron/LBaaS/l7

Comments / Questions are welcomed.

Thanks

Avishay 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] L7 rules design

[Avishay Balderman]

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 - CRUD operation should be supported as well for the policy and rules

Thanks

Avishay

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Friday, November 22, 2013 5:24 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][LBaaS] L7 rules design

Hi Avishay, lbaas folks,

I've reviewed the wiki and have some questions/suggestions:

1) Looks like L7Policy is lacking 'name' attribute in it's description. However 
i see little benefit of having a name for this object
2) lbaas-related neutron client commands start with lb-, please fix this.
3) How does L7Policy specifies relation of vip and pool?
4) How default pool will be associated with the vip? Will it be a l7 rule of 
special kind?
It is not quite clear what does mean associating vip with pool with policy if 
each rule in the policy contains 'SelectedPool' attribute.
5) what is 'action'? What other actions except SELECT_POOL can be?

In fact my suggestion will be slightly different:
- Instead of having L7Policy which i believe serves only to rules grouping, we 
introduce VipPoolAssociation as follows:

VipPoolAssociation
 id,
 vip_id,
 pool_id,
 default - boolean flag for default pool for the vip

L7Rule then will have vippoolassociation_id (it's better to shorten the attr 
name) just like it has policy_id in your proposal. L7Rule doesn't need 
SelectedPool attribute since once it attached to VipPoolAssociation, the rule 
then points to the pool with pool_id of that association.
In other words, VipPoolAssociation is almost the same as L7Policy but named 
closer to it's primary goal of associating vips and pools.

I would also suggest to add add/delete-rule operation for the association.

What do you think?

Thanks,
Eugene.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] L7 model - an alternative

[Avishay Balderman]

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 (optional) the Pool ID. When the action is redirection to 
a pool
See:
https://docs.google.com/drawings/d/119JV_dG_odWVVKTcn51qyRh3rW-253uUqfcg9CFQDtg/edit?usp=sharing

Please let me know what do you think about this model.

Thanks

Avishay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] L7 model - an alternative

[Avishay Balderman]

Sorry for the broken link
Here is a better one:

https://docs.google.com/drawings/d/119JV_dG_odWVVKTcn51qyRh3rW-253uUqfcg9CFQDtg/pub?w=960&h=720

Sent from my iPhone

On 8 בדצמ 2013, at 17:31, "Avishay Balderman" 
mailto:avish...@radware.com>> wrote:

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 (optional) the Pool ID. When the action is redirection to a 
pool
See:
https://docs.google.com/drawings/d/119JV_dG_odWVVKTcn51qyRh3rW-253uUqfcg9CFQDtg/edit?usp=sharing

Please let me know what do you think about this model.

Thanks

Avishay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Unit Test - mixing DB UT with extension API

[Avishay Balderman]

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 relevant DB plugin.

Thanks

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] L7 data types

[Avishay Balderman]

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
Field : compare_type
Description: The way we compare the value against a given value
Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
Note: With REG_EXP we can cover the rest of the values.

In general In the L7rule one can express the following (Example):
"check if in the value of header named 'Jack'  starts with X" - if this is true 
- this rule "returns" true


Thanks

Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] L7 data types

[Avishay Balderman]

(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 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
Field : compare_type
Description: The way we compare the value against a given value
Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
Note: With REG_EXP we can cover the rest of the values.

In general In the L7rule one can express the following (Example):
"check if in the value of header named 'Jack'  starts with X" - if this is true 
- this rule "returns" true


Thanks

Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

[Avishay Balderman]

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 such update occurred?

Thanks

Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] L7Policy deletion

[Avishay Balderman]

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 driver that will do the real deletion 
from DB. The plugin will mark the record as PENDEING_DELETE

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

[Avishay Balderman]

I agree with #1
I am not sure I understand #2...
Let's assume that the user created a policy named "static-images".
The policy was associated with a vip and it contains rules.
When we have created the VipL7PolicyAssoc the driver used the L7Policy name 
attribute in its backend.
Now we modify this name to be "static-images1" - why not to tell the driver 
about it?

Thanks

Avishay

From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: Monday, February 17, 2014 11:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

Hi,

On Mon, Feb 17, 2014 at 1:23 PM, Eugene Nikanorov 
mailto:enikano...@mirantis.com>> wrote:
Hi Avishay,

1) I think name might be useful. Consider user forms a list of rules which 
route requests to a pool with static images or static pages, it may make sense 
to give those policy a name 'static-iamges', 'static-pages', rather then 
operate on ids.
+1


2) I think updating the name is useful as well, but just on DB level, so there 
is no point in calling the driver and communicating with the backend.
+1

Thanks,
Eugene.

On Mon, Feb 17, 2014 at 12:58 PM, Avishay Balderman 
mailto: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 such update occurred?

Thanks

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] L7 data types

[Avishay Balderman]

Here are the suggested values for the attributes below:

· Entity: L7Rule

o   Attribute: type

§  Possible values:

· HOST_NAME

· PATH

· FILE_NAME

· FILE_TYPE

· HEADER

· COOKIE

o   Attribute: compare_type

§  Possible values:

· EQUAL

· CONTAINS

· REGEX

· STARTS_WITH

· ENDS_WITH

· Entity:L7VipPolicyAssociation

o   Attribute:action

§  Possible values:

· POOL (must have pool id)

· REDIRECT(must have a url to be used as redirect destination)

· REJECT


From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: Monday, February 17, 2014 9:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 data types

Hi,

I would add another candidate for being a closed set: 
L7VipPolicyAssociation.action (use_backend, block, etc.)

Thanks,
Oleg

On Sun, Feb 16, 2014 at 3:53 PM, Avishay Balderman 
mailto:avish...@radware.com>> wrote:
(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 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
Field : compare_type
Description: The way we compare the value against a given value
Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
Note: With REG_EXP we can cover the rest of the values.

In general In the L7rule one can express the following (Example):
“check if in the value of header named ‘Jack’  starts with X” – if this is true 
– this rule “returns” true


Thanks

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] L7 data types

[Avishay Balderman]

Hi

· I will add HTTP_METHOD to the ‘type’ enum of L7Rule

· GT,LT,GE,LE – at this phase I prefer to keep string based 
‘compare_type’ and I prefer not to add those number based compare types

· FILE_NAME,FILE_TYPE – Those two are a result of the URL 
fragmentation. Example: http://myserver/something/images/mypic.png . FILE_NAME 
= mypic FILE_TYPE = png

thanks

Avishay

From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: Wednesday, February 19, 2014 9:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 data types

Hi folks,
please see a few comments inline.

On Wed, Feb 19, 2014 at 12:51 AM, Stephen Balukoff 
mailto:sbaluk...@bluebox.net>> wrote:
A couple quick suggestions (additions):


 Entity: L7Rule

o   Attribute: type

•  Possible values:

  *   HTTP_METHOD

o   Attribute: compare_type

•  Possible values:

  *   GT (greater than)
  *   LT (less than)
  *   GE (greater than or equal to)
  *   LE (less than or equal to)
Will we be doing syntax checking based on the L7Rule type being presented?  
(eg. if w'ere going to check that HEADER X has a value that is greater than Y, 
are we going to make sure that "Y" is an integer? Or if we're going to check 
that the PATH STARTS_WITH Z, are we going to make sure that Z is a 
non-zero-length string? )
I think we should do these checks on the plugin level (API level doesn't 
support such checks at the moment).

Thanks,
Stephen

On Tue, Feb 18, 2014 at 3:58 AM, Avishay Balderman 
mailto:avish...@radware.com>> wrote:
Here are the suggested values for the attributes below:

• Entity: L7Rule

o   Attribute: type

•  Possible values:

• HOST_NAME

• PATH

• FILE_NAME

• FILE_TYPE
Can somebody please clarify what FILE_NAME and FILE_TYPE mean? Just can't find 
corresponding matching criterias in haproxy.

• HEADER

• COOKIE

o   Attribute: compare_type

•  Possible values:

• EQUAL

• CONTAINS

• REGEX

• STARTS_WITH

• ENDS_WITH

• Entity:L7VipPolicyAssociation

o   Attribute:action

•  Possible values:

• POOL (must have pool id)

• REDIRECT(must have a url to be used as redirect destination)

• REJECT


From: Oleg Bondarev 
[mailto:obonda...@mirantis.com<mailto:obonda...@mirantis.com>]
Sent: Monday, February 17, 2014 9:17 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 data types

Hi,

I would add another candidate for being a closed set: 
L7VipPolicyAssociation.action (use_backend, block, etc.)

Thanks,
Oleg

On Sun, Feb 16, 2014 at 3:53 PM, Avishay Balderman 
mailto:avish...@radware.com>> wrote:
(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 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
Field : compare_type
Description: The way we compare the value against a given value
Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
Note: With REG_EXP we can cover the rest of the values.

In general In the L7rule one can express the following (Example):
“check if in the value of header named ‘Jack’  starts with X” – if this is true 
– this rule “returns” true


Thanks

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] REST API - entity level validation

[Avishay Balderman]

Hi
With the current REST API engine in neutron we can declare attributes 
validations.
We have a rich set of validation functions 
https://github.com/openstack/neutron/blob/master/neutron/api/v2/attributes.py
However we do not have the concept of entity level validation.

Example:
I have an API ‘create-something’ and Something is an entity having 2 attributes:
Something {
  Attribute A
 Attribute B
}
And according to the business logic A must be greater than B


As for today our framework cannot handle  this kind of validation and the call 
is going inside a lower layer of neutron and must be validated there.
Example: https://review.openstack.org/#/c/93871/9

With this we have the validations implemented across multi layers. I think we 
better have the validations in one layer.

Thanks

Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Layer 7 switching RST document on Gerrit

[Avishay Balderman]

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

Re: [openstack-dev] [Neutron] REST API - entity level validation

[Avishay Balderman]

Salvatore
Will Neutron is going to follow Nova?
https://blueprints.launchpad.net/nova/+spec/nova-api-validation-fw

Avishay

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Monday, June 16, 2014 12:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] REST API - entity level validation

Avishay,

what you say here is correct.
However, as we are in the process of moving to Pecan as REST API framework I 
would probably refrain from adding new features to it at this stage.

Therefore, even if far from ideal, this kind 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 
mailto:avish...@radware.com>> wrote:
Hi
With the current REST API engine in neutron we can declare attributes 
validations.
We have a rich set of validation functions 
https://github.com/openstack/neutron/blob/master/neutron/api/v2/attributes.py
However we do not have the concept of entity level validation.

Example:
I have an API ‘create-something’ and Something is an entity having 2 attributes:
Something {
  Attribute A
 Attribute B
}
And according to the business logic A must be greater than B


As for today our framework cannot handle  this kind of validation and the call 
is going inside a lower layer of neutron and must be validated there.
Example: https://review.openstack.org/#/c/93871/9

With this we have the validations implemented across multi layers. I think we 
better have the validations in one layer.

Thanks

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] LBaaS Mid Cycle Sprint

[Avishay Balderman]

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Devstack. Fail to boot an instance if more than 1 network is defined

[Avishay Balderman]

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

[openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values

[Avishay Balderman]

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 operators (*) in the list are used in numerical matches.
Radware load balancing backend does not support those operators   “out of the 
box” and a significant development effort should be done in order to support it.
We are afraid to miss the Junu timeframe if we will have to focus in supporting 
the numerical operators.
Therefore we ask to support the non-numerical operators for Junu and add the 
numerical operators support post Junu.

See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst

Thanks
Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values

[Avishay Balderman]

Hi Dustin
I agree with the concept you described but as far as I understand it is not 
currently supported in Neutron.
So a driver should be fully compatible with the interface it implements.

Avishay

From: Dustin Lundquist [mailto:dus...@null-ptr.net]
Sent: Tuesday, June 24, 2014 5:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - 
comapre_type values

I think the API should provide an richly featured interface, and individual 
drivers should indicate if they support the provided configuration. For example 
there is a spec for a Linux LVS LBaaS driver, this driver would not support TLS 
termination or any layer 7 features, but would still be valuable for some 
deployments. The user experience of such a solution could be improved if the 
driver to propagate up a message specifically identifying the unsupported 
feature.


-Dustin

On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman 
mailto: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.
Below is list of the possible values:
- Regexp
- StartsWith
- EndsWith
- Contains
- EqualTo (*)
- GreaterThan (*)
- LessThan (*)

The last 3 operators (*) in the list are used in numerical matches.
Radware load balancing backend does not support those operators   “out of the 
box” and a significant development effort should be done in order to support it.
We are afraid to miss the Junu timeframe if we will have to focus in supporting 
the numerical operators.
Therefore we ask to support the non-numerical operators for Junu and add the 
numerical operators support post Junu.

See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst

Thanks
Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] LBaaS API Version 2 WIP in gerrit

[Avishay Balderman]

Hi Brandon
I think the patch should be broken into few standalone sub patches.
As for now it is huge and review is a challenge :)
Thanks
Avishay


-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Tuesday, July 08, 2014 5:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] LBaaS API Version 2 WIP in gerrit

https://review.openstack.org/#/c/105331

It's a WIP and the shim layer still needs to be completed.  Its a lot of code, 
I know.  Please review it thoroughly and point out what needs to change.

Thanks,
Brandon


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] LBaaS L7 Switching - design document

[Avishay Balderman]

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

[openstack-dev] [Neutron][LBaaS] Radware LBaaS v2 driver design doc

[Avishay Balderman]

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

Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates

[Avishay Balderman]

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] [Neutron][LBaaS] Milestone and Due Dates
Importance: High

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 is anything really critical at this stage that can't be 
commented later during the code review. 
Otherwise, please review and +1 so we can get final approval from Neutron cores.

Thanks,
-Sam.




-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Saturday, July 19, 2014 5:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Milestone and Due Dates

On Fri, Jul 18, 2014 at 4:40 PM, Jorge Miramontes 
 wrote:
> Hey Kyle (and anyone else that may know the answers to my questions),
>
> There are several blueprints that don't have Juno milestones attached 
> to them and was wondering if we could assign them so the broader 
> community is aware of the work the LBaaS folks are working on. These 
> are the blueprints that are currently being worked on but do not have an 
> assigned milestone:
>
> https://blueprints.launchpad.net/neutron/+spec/lbaas-ref-impl-tls-supp
> ort
> (no milestone)
> https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination ('next'
> milestone. Not sure if this means juno-2 or juno-3) 
> https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no
> milestone)
> https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framewor
> k (no
> milestone)
> https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules (no
> milestone)
>
These do not have a milestone set in LP yet because the specs are not approved. 
It's unclear if all of these will be approved for Juno-3 at this point, though 
I suspect at least a few will be. I'm actively reviewing final specs for 
approval before Spec Approval Deadline on Sunday, 7-20.

> Also, please let me know if I left something out everyone.
>
> Lastly, what are the definitive spec/implementation dates that the 
> LBaaS community should be aware of? A lot of us are confused on exact 
> dates and I wanted to make sure we were all on the same page so that 
> we can put resources on items that are more time sensitive.
>
Per above, SAD is this Sunday. The Juno release schedule is on the wiki here 
[1].

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Juno_Release_Schedule

> Cheers,
> --Jorge
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Update on specs we needed approved

[Avishay Balderman]

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 we needed approved

Yes, thanks guys! These are really important for features we want to get into 
Neutron LBaaS in Juno! :D

On Mon, Jul 21, 2014 at 2:42 PM, Brandon Logan 
mailto:brandon.lo...@rackspace.com>> wrote:
In reference to these 3 specs:

TLS Termination - https://review.openstack.org/#/c/98640/
L7 Switching - https://review.openstack.org/#/c/99709/
Implementing TLS in reference Impl -
https://review.openstack.org/#/c/100931/

Kyle has +2'ed all three and once Mark Mcclain +2's them then one of
them will +A them.

Thanks again Kyle and Mark!


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] DB layer - Specific exceptions when resource cant be found. Do they have any added value?

[Avishay Balderman]

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
If we were looking for a HealthMonitor and it was not found in DB --> throw 
HealthMonitorNotFound
etc…

I can see very little value (if any…) in having those specific exceptions.

Why not have a base “NotFound” exception that gets the entity type and its id.
This exception will tell the method caller what is the  entity type and its id. 
Isnt that good enough?

On the other hand this code should be mainlined and reviewed… So not only it 
has no value, the dev. team  should maintain it.

Here is the code (v1) 
https://github.com/openstack/neutron/blob/master/neutron/db/loadbalancer/loadbalancer_db.py#L210
I prefer not to have it in v2

Thanks

Avishay







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] DB layer - Specific exceptions when resource cant be found. Do they have any added value?

[Avishay Balderman]

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 Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] DB layer - Specific exceptions when 
resource cant be found. Do they have any added value?

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
If we were looking for a HealthMonitor and it was not found in DB --> throw 
HealthMonitorNotFound
etc…

I can see very little value (if any…) in having those specific exceptions.
Why not have a base “NotFound” exception that gets the entity type and its id.
This exception will tell the method caller what is the  entity type and its id. 
Isnt that good enough?

On the other hand this code should be mainlined and reviewed… So not only it 
has no value, the dev. team  should maintain it.

Here is the code (v1) 
https://github.com/openstack/neutron/blob/master/neutron/db/loadbalancer/loadbalancer_db.py#L210
I prefer not to have it in v2

Thanks

Avishay







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Object status and admin_state_up

[Avishay Balderman]

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] [Neutron][LBaaS] Object status and admin_state_up

Hi folks,

Currently there are two attributes of vips/pools/members that represent a 
status: 'status' and 'admin_state_up'.

The first one is used to represent deployment status and can be PENDING_CREATE, 
ACTIVE, PENDING_DELETE, ERROR.
We also have admin_state_up which could be True or False.

I'd like to know your opinion on how to change 'status' attribute based on 
admin_state_up changes.
For instance. If admin_state_up is updated to be False, how do you think 
'status' should change?

Also, speaking of reference implementation (HAProxy), changing vip or pool 
admin_state_up to False effectively destroys the balancer (undeploys it), while 
the objects remain in ACTIVE state.
There are two options to fix this discrepancy:
1) Change status of vip/pool to PENDING_CREATE if admin_state_up changes to 
False
2) Don't destroy the loadbalancer and use HAProxy capability to disable 
frontend and backend while leave vip/pool in ACTIVE state

Please share your opinion.

Thanks,
Eugene.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] - Vendor specific erros

[Avishay Balderman]

Hi
Some of the DB entities in the LBaaS domain inherit from 
HasStatusDescription
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 driver that the  driver needs to set the 
entity status to ERROR and it is able to set the description of the error -  
the description is Radware specific.
My question is:  Does it make sense to do that?
After all the tenant is aware to the fact that he works against Radware load 
balancer -  the tenant selected Radware as the lbaas provider in the UI.
Any reason not to do that?

This is a generic issue/question and does not relate  to a specific plugin or 
driver.

Thanks

Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] - Vendor specific erros

[Avishay Balderman]

Hi
Some of the DB entities in the LBaaS domain inherit from 
HasStatusDescription
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 driver that the  driver needs to set the 
entity status to ERROR and it is able to set the description of the error -  
the description is Radware specific.
My question is:  Does it make sense to do that?
After all the tenant is aware to the fact that he works against Radware load 
balancer -  the tenant selected Radware as the lbaas provider in the UI.
Any reason not to do that?

This is a generic issue/question and does not relate  to a specific plugin or 
driver.

Thanks

Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] - Vendor specific erros

[Avishay Balderman]

Hi Salvatore
I think you are mixing between the state machine (ACTIVE,PENDEING_XYZ,etc)  and 
the status description
All I want to do is to write a vendor specific error message when the state is 
ERROR.
I DO NOT want to touch the state machine.

See: https://bugs.launchpad.net/neutron/+bug/1248423

Thanks

Avishay

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Thursday, November 14, 2013 1:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] - Vendor specific erros

In general, an error state make sense.
I think you might want to send more details about how this state plugs into the 
load balancer state machine, but I reckon it is a generally non-recoverable 
state which could be reached by any other state; in that case it would be a 
generic enough case which might be supported by all drivers.

It is good to point out that driver-specific state transitions however, in my 
opinion, are to avoid; application using the Neutron API will become 
non-portable, or at least users of the Neutron API would need to be aware that 
an entity might have a different state machine from driver to driver, which I 
reckon would 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 
mailto:avish...@radware.com>> wrote:

Hi
Some of the DB entities in the LBaaS domain inherit from 
HasStatusDescription<https://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 driver that the  driver needs to set the 
entity status to ERROR and it is able to set the description of the error -  
the description is Radware specific.
My question is:  Does it make sense to do that?
After all the tenant is aware to the fact that he works against Radware load 
balancer -  the tenant selected Radware as the lbaas provider in the UI.
Any reason not to do that?

This is a generic issue/question and does not relate  to a specific plugin or 
driver.

Thanks

Avishay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a non-shared network in another tenant

[Avishay Balderman]

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; gong...@unitedstack.com
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a 
non-shared network in another tenant

Hi Yong,

Garry has recommended that I will you the following:

In: /opt/stack/nova/nova/network/neutronv2/api.py
In the def _get_available_networks function, the developer has added a specific 
line of code filtering networks by the tenant_id.
Around line 123: search_opts = {"tenant_id": project_id, 'shared': False}

As far as I understand, Neutron already filters non-shared networks by the 
tenant ID, so why do we need this explicit filter, even more, I think that the 
behavior of neutron will also return the shared network in addition to the 
private ones by default so instead of the code doing two calls it could only do 
one call to Neutron with if needed filtering by net_ids.

Do you see a reason why the code should remain as is?

Thanks,
-Sam.



From: Samuel Bercovici
Sent: Thursday, August 01, 2013 10:58 AM
To: OpenStack Development Mailing List; 
sorla...@nicira.com
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a 
non-shared network in another tenant

There was another patch needed:
In: /opt/stack/nova/nova/network/neutronv2/api.py
In the def _get_available_networks function, the developer has added a specific 
line of code filtering networks by the tenant_id.
In general as far as I understand, this might be unneeded as quantum will 
already filter the networks based on the tenant_id in the context while if 
is_admin, will elevate and return all networks which I belive is the behavior 
we want.

Do you think this can somehow be solved only on neutron side or must it also be 
done by rmoving the tenant_id filter in the nova side?

When removing the filter of tenant_id + the pathc bellow, I get the behavior 
that as admin, I can createVMs connected to another tenants private network but 
as non-admin I am not able to do so.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Wednesday, July 31, 2013 7:32 PM
To: OpenStack Development Mailing List; 
sorla...@nicira.com
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a 
non-shared network in another tenant

Hi Slavatore,

I thought that creating a qport  would be enough but it looks like I still 
missing something else.
I have commented in /opt/stack/quantum/neutron/api/v2/base.py in the create 
function the ._validate_network_tenant_ownership call.
I can now as an Admin user, can create a qport from tenant-a that is mapped to 
a private network in tenant-b.

The following still fails with ERROR: The resource could not be found. (HTTP 
404) ...
nova boot --flavor 1 --image  --nic port-id=
Where  is the one I got from the port-create

Any ideas where I should look next?

Regards,
-Sam.


From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Wednesday, July 31, 2013 5:42 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a 
non-shared network in another tenant

Hi Sam,

is what you're trying to do tantamount to creating a port on a network whose 
tenant_id is different from the network's tenant_id?
We have at the moment a fairly strict ownership check - which does not allow 
even admin users to do this operation.

I do not have a strong opinion against relaxing the check, and allowing admin 
users to create ports on any network - I don't think this would constitute a 
potential vulnerability, as in neutron is someone's manages to impersonate an 
admin user, he/she can make much more damage.

Salvatore

On 31 July 2013 16:11, Samuel Bercovici 
mailto:samu...@radware.com>> wrote:
Hi All,

We are providing load balancing services via virtual machines running under an 
admin tenant that needs to be connected to VMs attached to a non-shared/private 
tenant network.
The virtual machine fails to be provisioned connected to the private tenant 
network event if it is provisioned using the admin user which has admin role on 
both tenants.
Please advise?

Best Regards,
-Sam.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev