Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Vijay Venkatachalam]

Hi German,

>> So if you have some 3rd party hardware you only need to change the database 
>> (your steps 1-5) since the 3rd party hardware will just keep load balancing…

This is not the case with NetScaler it has to go through a Delete of V1 
followed by Create in V2 if a smooth migration is required. 

Thanks,
Vijay V.
-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com] 
Sent: 08 March 2016 00:00
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format file into 
some scripts which recreate the load balancers with your provider of choice — 

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs… 

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici"  wrote:

>As for a migration tool.
>Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I 
>am in favor for the following process:
>
>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
>Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
>over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to 
>make room to some custom modification for mapping between v1 and v2 
>models)
>
>What do you think?
>
>-Sam.
>
>
>
>
>-Original Message-
>From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>Sent: Friday, March 04, 2016 2:06 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Ok. Thanks for the info.
>
>Kevin
>
>From: Brandon Logan [brandon.lo...@rackspace.com]
>Sent: Thursday, March 03, 2016 2:42 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Just for clarity, V2 did not reuse tables, all the tables it uses are only for 
>it.  The main problem is that v1 and v2 both have a pools resource, but v1 and 
>v2's pool resource have different attributes.  With the way neutron wsgi 
>works, if both v1 and v2 are enabled, it will combine both sets of attributes 
>into the same validation schema.
>
>The other problem with v1 and v2 running together was only occurring when the 
>v1 agent driver and v2 agent driver were both in use at the same time.  This 
>may actually have been fixed with some agent updates in neutron, since that is 
>common code.  It needs to be tested out though.
>
>Thanks,
>Brandon
>
>On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
>> Just because you had thought no one was using it outside of a PoC doesn't 
>> mean folks aren''t using it in production.
>>
>> We would be happy to migrate to Octavia. We were planning on doing just that 
>> by running both v1 with haproxy namespace, and v2 with Octavia and then pick 
>> off upgrading lb's one at a time, but the reuse of the v1 tables really was 
>> an unfortunate decision that blocked that activity.
>>
>> We're still trying to figure out a path forward.
>>
>> We have an outage window next month. after that, it could be about 6 
>> months before we could try a migration due to production load picking 
>> up for a while. I may just have to burn out all the lb's switch to 
>> v2, then rebuild them by hand in a marathon outage :/
>>
>> And then there's this thingy that also critically needs fixing:
>> https://bugs.launchpad.net/neutron/+bug/1457556
>>
>> Thanks,
>> Kevin
>> 
>> From: Eichberger, German [german.eichber...@hpe.com]
>> Sent: Thursday, March 03, 2016 12:47 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>> Kevin,
>>
>>  If we are offering a migration tool it would be namespace -> 
>> namespace (or maybe Octavia since [1]) - given the limitations nobody 
>> should be using the namespace driver outside a PoC so I am a bit 
>> confused why customers can't self migrate. With 3rd party Lbs I would 
>> assume vendors proving those scripts to make sure their particular 
>> 

[openstack-dev] [Neutron] Integrating physical appliance into virtual infrastructure

[Vijay Venkatachalam]

Hi ,

How to integrate a physical appliance into the virtual OpenStack infrastructure 
(with L2 population)? Can you please point me to any relevant material.

We want to add the capability to "properly" schedule the port on the physical 
appliance, so that the rest of the virtual infrastructure knows that a new port 
is scheduled in the physical appliance.  How to do this?

We manage the appliance through a middleware. Today, when it creates a neutron 
port, that is to be hosted on the physical appliance, the port is dangling.  
Meaning, the virtual infrastructure does not know where this port is 
hosted/implemented. How to fix this?

Also, we want the physical appliance plugged into L2 population mechanism. 
Looks like the L2 population driver is distributing L2 info to all virtual 
infrastructure nodes where a neutron agent is running. Can we leverage this 
framework? We don't want to run the neutron agent in the physical appliance, 
can it run in the middle ware?

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Integrating physical appliance into virtual infrastructure

[Vijay Venkatachalam]

L2GW seems like a good option for bridging/linking /integrating physical 
appliances which does not support overlay technology (say VXLAN) natively.

In my case the physical appliance supports VXLAN natively, meaning it can act 
as a VTEP. The appliance is capable of decapsulating packets that are received 
and encapsulating packets that are sent (looking at the forwarding table).

Now we want to add the capability in the  middleware/controller so that 
forwarding tables in the appliance can be populated and also let the rest of 
infrastructure know about the physical appliance (VTEP) and its L2 info?

Is it possible to achieve this?

Thanks,
Vijay V.



From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: 01 February 2016 19:38
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Integrating physical appliance into 
virtual infrastructure

There is a project that aims at solving your use cases (at least from a general 
view)
Its called L2GW and uses OVSDB Hardware VTEP schema (which is supported by many 
physical appliances for switching capabilities)

Some information: https://wiki.openstack.org/wiki/Neutron/L2-GW

There are also other possible solutions, depending what you are trying to do 
and what is the physical applicance job.



On Mon, Feb 1, 2016 at 3:44 PM, Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>> wrote:
Hi ,

How to integrate a physical appliance into the virtual OpenStack infrastructure 
(with L2 population)? Can you please point me to any relevant material.

We want to add the capability to “properly” schedule the port on the physical 
appliance, so that the rest of the virtual infrastructure knows that a new port 
is scheduled in the physical appliance.  How to do this?

We manage the appliance through a middleware. Today, when it creates a neutron 
port, that is to be hosted on the physical appliance, the port is dangling.  
Meaning, the virtual infrastructure does not know where this port is 
hosted/implemented. How to fix this?

Also, we want the physical appliance plugged into L2 population mechanism. 
Looks like the L2 population driver is distributing L2 info to all virtual 
infrastructure nodes where a neutron agent is running. Can we leverage this 
framework? We don’t want to run the neutron agent in the physical appliance, 
can it run in the middle ware?

Thanks,
Vijay V.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best Regards ,

The G.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] Enabling GET of secrets to work irrespective of Tenant name in login

[Vijay Venkatachalam]

Hi,

Can we enable GET of secrets to work irrespective of Tenant name in the login?

Consider there is an "admin" with "admin" role in "demo" tenant. I tried to 
query the "demo" tenant's secret using  a login token which was generated from 
"admin" user  & "admin" tenant. And I am getting a Forbidden error. Could we 
make this scenario work?

UseCase:
 
LBaaS extension has admin credentials and generates a token and uses it to 
contact services like nova, barbican etc. It is currently using  the same token 
to get the tenant's secret/certificates with the href and it is not working.

Thanks,
Vijay V.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

[Vijay Venkatachalam]

>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
It did not work. Please read on.
>> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user 
>> (right now using whatever user-id we publish in our docs) to read their data.
I did perform the above step to give read access for the container and secrets 
to “admin”, but it did not work.

Root Cause
==
The certmanager in lbaas which connects to barbican uses the keystone session 
gathered from
neutron_lbaas.common.keystone.get_session()
Since the keystone session is marked for tenant “admin” lbaas is not able to 
get the tenant’s container/certificate.

I have filed a bug for the same.

https://bugs.launchpad.net/neutron/+bug/1497410

This is an important fix required since tenants wont be able to use SSL 
Offload. Will try to upload a fix for this next week.


Thanks,
Vijay V.

From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the 
user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own 
secrets/containers, we won’t do it for them. So, workflow is like:


  *   User creates Secrets in Barbican.
  *   User creates CertificateContainer in Barbican.
  *   User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS 
user (right now using whatever user-id we publish in our docs) to read their 
data.
  *   User creates a LoadBalancer in Neutron-LBaaS.
  *   LBaaS hits Barbican using its standard configured service-account to 
retrieve the Container/Secrets from the user’s Barbican account.
This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The 
question is whether right now in devstack the admin user is allowed to read all 
user secrets just because it is the admin user (which I think might be the 
case), in which case we won’t actually know if ACLs are working as intended 
(but I think we assume that Barbican has tested that feature and we can just 
rely on it working).

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

Is there a documentation which records step by step?

What is Neutron-LBaaS tenant?

Is it the tenant who is configuring the listener? *OR* is it some tenant which 
is created for lbaas plugin that is the having all secrets for all tenants 
configuring lbaas.

>>You need to set up ACLs on the Barbican side for that container, to make it 
>>readable to the Neutron-LBaaS tenant.
I checked the ACL docs
http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

The ACL API is to allow “users”(not “Tenants”) access to secrets/containers. 
What is the API or CLI that the admin will use to allow access of the tenant’s 
secret+container to Neutron-LBaaS tenant.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 15 September 2015 03:00
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

You need to set up ACLs on the Barbican side for that container, to make it 
readable to the Neutron-LBaaS tenant. For now, the tenant-id should just be 
documented, but we are looking into making an API call that would expose the 
admin tenant-id to the user so they can make an API call to discover it.

Once the user has the neutron-lbaas tenant ID, they use the Barbican ACL system 
to add that ID as a readable user of the container and all of the secrets. Then 
Neutron-LBaaS hits barbican with the credentials of the admin tenant, and is 
granted access to the user’s container.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

[Vijay Venkatachalam]

Typos corrected.

From: Vijay Venkatachalam
Sent: 18 September 2015 00:36
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: RE: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Yes Dave, that is what is happening today.

But that approach looks a little untidy, because tenant admin has to do some 
infrastructure work.

It will be good from the user/tenant admin's perspective to just do 2 things

1.  Upload certificates info

2.  Create LBaaS Configuration with certificates already uploaded

Now because barbican and LBaaS does *not* work nicely with each other, every 
tenant admin has to do the following


1.  Upload certificates info

2.  Read a document or finds out there is a LBaaS service user and somehow 
gets hold of LBaaS service user's userid. Assigns read rights to that 
certificate to LBaaS service user.

3.  Creates LBaaS Configuration with certificates already uploaded

This does not fit the "As a service" model of OpenStack where tenant's just 
configure whatever they want and the infrastructure takes care of automating 
the rest.

Thanks,
Vijay V.

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 17 September 2015 18:20
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


The tenant admin from Step 1, should also do Step 2.

From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

[Vijay Venkatachalam]

Sure Adam. Pleasure is mine ☺.

Also, I don’t see any wrong doing by LBaaS (infact it is the right thing to do) 
if LBaaS plugin is specifying the tenant containers unique URL and also correct 
tenant context in the keystone session to fetch the container.
Although, if barbican fixes to ignore the tenant value in keystone session and 
only authenticates the user for verification, it is a bonus and LBaaS current 
code will work.

LongTerm, We need to eliminate the step of assigning access by tenant’s admin 
and automate it.

I had initiated a thread 3 days  earlier with Barbican on the same issue. Here 
is the link.
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg63476.html

Thanks,
Vijay V.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 19 September 2015 01:17
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

That sounds like the Barbican ACLs are not working properly. The whole point of 
using Barbican ACLs is that the keystone session marked for tenant "admin" 
should be able to get access to ANY tenant’s container/secrets if the ACLs are 
set. I am still not convinced this is an issue on the LBaaS side. 
Unfortunately, I don’t have a lot of time to test this right now as we’re up 
against the clock for the gate, so your help in debugging and fixing this issue 
is greatly appreciated! I just want to make sure the expected workflow is fully 
understood.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 18, 2015 at 2:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?


>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
It did not work. Please read on.
>> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user 
>> (right now using whatever user-id we publish in our docs) to read their data.
I did perform the above step to give read access for the container and secrets 
to “admin”, but it did not work.

Root Cause
==
The certmanager in lbaas which connects to barbican uses the keystone session 
gathered from
neutron_lbaas.common.keystone.get_session()
Since the keystone session is marked for tenant “admin” lbaas is not able to 
get the tenant’s container/certificate.

I have filed a bug for the same.

https://bugs.launchpad.net/neutron/+bug/1497410

This is an important fix required since tenants wont be able to use SSL 
Offload. Will try to upload a fix for this next week.


Thanks,
Vijay V.

From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the 
user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own 
secrets/containers, we won’t do it for them. So, workflow is like:


  *   User creates Secrets in Barbican.
  *   User creates CertificateContainer in Barbican.
  *   User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS 
user (right now using whatever user-id we publish in our docs) to read their 
data.
  *   User creates a LoadBalancer in Neutron-LBaaS.
  *   LBaaS hits Barbican using its standard configured service-account to 
retrieve the Container/Secrets from the user’s Barbican account.
This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The 
question is whether right now in devstack the admin user is allowed to read all 
user secrets just because it is the admin user (which I think might be the 
case), in which case we won’t actually know if ACLs are working as intended 
(but I think we assume that Barbican has tested that feature and we can just 
rely on it working).

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:op

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

[Vijay Venkatachalam]

I would think OpenStack as Self Service portal.
Anyway, tenant’s admin need not play cloud admin’s role.
Only the cloud admin who sets up and manages openstack infrastructure (like 
controller Nodes etc) could know about the LBaaS service user. As much as 
possible the tenant admin should not be mandated to learn about the LBaaS 
service user.

From: Nathan Reller [mailto:nathan.s.rel...@gmail.com]
Sent: 18 September 2015 18:32
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

> But that approach looks a little untidy, because tenant admin has to do some 
> infrastructure work.

I would think infrastructure work would be part of the admin role. They are 
doing other things such as creating LBaaS, which seems like an infrastructure 
job to me. I would think configuring LBaaS and key management are similar. It 
seems like you think they are not similar. Can you explain more?

-Nate
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

[Vijay Venkatachalam]

Yes Dave, that is what is happening today.

But that approach looks a little untidy, because tenant admin has to do some 
infrastructure work.

It will be good from the user/tenant admin's perspective to just do 2 things

1.  Upload certificates info

2.  Create LBaaS Configuration with certificates already uploaded

Now because barbican and LBaaS does work nicely with each other, every tenant 
admin has to do like the following


1.  Upload certificates info

2.  Read a document or finds out there is a LBaaS service user and somehow 
gets hold of LBaaS service user's userid. Assigns read rights to that 
certificate to LBaaS service user.

3.  Creates LBaaS Configuration with certificates already uploaded

If feel this does not fit the "As a service" model where tenant's just care 
about what they have to.

Thanks,
Vijay V.

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 17 September 2015 18:20
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


The tenant admin from Step 1, should also do Step 2.

From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

[Vijay Venkatachalam]

How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

[Vijay Venkatachalam]

The user here is the LBaaS service user which needs read access. This service 
user does play any role in the config creator's project. The service user might 
be playing a different role is in a common project.
For ex. "admin" user with "admin" role in "admin" project is the service user 
in devstack for LBaaS.

--Vijay



From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 16 September 2015 18:36
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

A user with the role "observer" in a project will have read access to all 
secrets and containers for that project, using the default settings in the 
policy.json file.

--Dave McCowan

From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, September 15, 2015 at 10:06 PM
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates

Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

[Vijay Venkatachalam]

Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

[Vijay Venkatachalam]

Is there a documentation which records step by step?

What is Neutron-LBaaS tenant?

Is it the tenant who is configuring the listener? *OR* is it some tenant which 
is created for lbaas plugin that is the having all secrets for all tenants 
configuring lbaas.

>>You need to set up ACLs on the Barbican side for that container, to make it 
>>readable to the Neutron-LBaaS tenant.
I checked the ACL docs
http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

The ACL API is to allow “users”(not “Tenants”) access to secrets/containers. 
What is the API or CLI that the admin will use to allow access of the tenant’s 
secret+container to Neutron-LBaaS tenant.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 15 September 2015 03:00
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

You need to set up ACLs on the Barbican side for that container, to make it 
readable to the Neutron-LBaaS tenant. For now, the tenant-id should just be 
documented, but we are looking into making an API call that would expose the 
admin tenant-id to the user so they can make an API call to discover it.

Once the user has the neutron-lbaas tenant ID, they use the Barbican ACL system 
to add that ID as a readable user of the container and all of the secrets. Then 
Neutron-LBaaS hits barbican with the credentials of the admin tenant, and is 
granted access to the user’s container.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
<vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 11, 2015 at 2:35 PM
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using 
non "admin" tenant?

Hi,
  Has anyone tried configuring SSL Offload as a tenant?
  During listener creation there is an error thrown saying ‘could 
not locate/find container’.
  The lbaas plugin is not able to fetch the tenant’s certificate.

  From the code it looks like the lbaas plugin is tyring to connect 
to barbican with keystone details provided in neutron.conf
  Which is by default username = “admin” and tenant_name =”admin”.
  This means lbaas plugin is looking for tenant’s ceritifcate in 
“admin” tenant, which it will never be able to find.

  What is the procedure for the lbaas plugin to get hold of the 
tenant’s certificate?

  Assuming “admin” user has access to all tenant’s certificates. 
Should the lbaas plugin connect to barbican with username=’admin’ and 
tenant_name =  listener’s tenant_name?

Is this, the way forward ? *OR* Am I missing something?


Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

[Vijay Venkatachalam]

Hi,
  Has anyone tried configuring SSL Offload as a tenant?
  During listener creation there is an error thrown saying 'could 
not locate/find container'.
  The lbaas plugin is not able to fetch the tenant's certificate.

  From the code it looks like the lbaas plugin is tyring to connect 
to barbican with keystone details provided in neutron.conf
  Which is by default username = "admin" and tenant_name ="admin".
  This means lbaas plugin is looking for tenant's ceritifcate in 
"admin" tenant, which it will never be able to find.

  What is the procedure for the lbaas plugin to get hold of the 
tenant's certificate?

  Assuming "admin" user has access to all tenant's certificates. 
Should the lbaas plugin connect to barbican with username='admin' and 
tenant_name =  listener's tenant_name?

Is this, the way forward ? *OR* Am I missing something?


Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Vijay Venkatachalam]

We would like to participate as well.

Monday-Friday Morning US time works for me..

Thanks,
Vijay V.

From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: 26 May 2015 21:39
To: OpenStack Development Mailing List (not for usage questions)
Cc: kunalhgan...@gmail.com; v.jain...@gmail.com; do...@a10networks.com
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Hi,

I would also like to participate.
Friday is a non-working day in Israel (same as Saturday for most of you).
So Monday- Thursday works best for me.

-Sam.


From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Saturday, May 23, 2015 8:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: kunalhgan...@gmail.commailto:kunalhgan...@gmail.com; 
v.jain...@gmail.commailto:v.jain...@gmail.com; 
do...@a10networks.commailto:do...@a10networks.com
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support

Of those two options, Friday would work better for me.

Thanks,
doug

On May 22, 2015, at 9:33 PM, ki...@macinnes.iemailto:ki...@macinnes.ie wrote:

Hi Kunal,
Thursday/Friday works for me - early morning PT works best, as I'm based in 
Ireland.
I'll find some specific times the Designate folks are available over the next 
day or two and provide some options..
Thanks,
Kiall
On 22 May 2015 7:24 pm, Gandhi, Kunal 
kunalhgan...@gmail.commailto:kunalhgan...@gmail.com wrote:
Hi All

I wanted to start a discussion about adding support for GSLB to neutron-lbaas 
and designate. To be brief for folks who are new to GLB, GLB stands for Global 
Load Balancing and we use it for load balancing traffic across various 
geographical regions. A more detail description of GLB can be found at my talk 
at the summit this week herehttps://www.youtube.com/watch?v=fNR0SW3vj_s.

To my understanding, there are two sides to a GSLB - DNS side and LB side.

DNS side
Most of the GSLB’s provided by various vendors are DNS servers and 
are authoritative for the GLB domains. The global fqdn’s that belong the GLB 
domains resolve to multiple public VIP’s across various regions based on 
various configurations on the global fqdn on the GLB.

LBaaS side
A few of the common functionalities provided by a standard GSLB 
provides are health monitoring on the public VIP’s and the local LB’s on which 
these public VIP’s sit on. Some additional features that a GSLB can provide are 
configuring admin status and weights on your public VIP’s. Based on these 
configurations and settings, the GLB returns the appropriate number of public 
VIP’s to any DNS resolve queries for the global fqdn’s.

I would like to have the designate and lbaas to start a discussion on GSLB and 
discuss the following topics:


  *   What parts of GSLB belongs to Designate and LBaaS ?
  *   Once we have an understanding of the above, my team at eBay/PayPal would 
like work with the community on submitting a blueprint for this.


To kick start this conversation, I would like to schedule an irc meeting 
regarding this with folks from designate and neutron-lbaas. Please let me know 
a time and day that works for you guys. I am available on Thursday and Friday 
next week.


Regards
Kunal


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

[Vijay Venkatachalam]

Here is the NetScaler video.

https://citrix.sharefile.com/d-s5476bbd39a643d48

Hope you will be able to accommodate.
Apologies for the late arrival.

Thanks,
Vijay V.

From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Friday, May 15, 2015 10:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Vijay Venkatachalam; Evgeny Fedoruk; Adam Harwell; Kyle Mestery; Brandon 
Logan; Johnson, Michael (HP Cloud - Corvallis); Doug Wiegley
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

I would say: 1-2 minutes, no audio, mp4, must highlight lbaas v2 or v2/v1. 
Anyone is welcome, even encouraged, to submit, likely up until about Sunday I’m 
guessing.

Thanks,
doug


On May 15, 2015, at 10:05 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:

Was thinking 1-2 minutes. Tomorrow would be fine.

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Friday, May 15, 2015 6:03 PM
To: OpenStack Development Mailing List (not for usage questions); Evgeny 
Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; Johnson, Michael (HP Cloud 
- Corvallis); Doug Wiegley; Samuel Bercovici
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Hi Sam,
Thanks for probing. How many seconds/mins you have thought per vendor? By when 
do you need this? Will tomorrow work fine?


Thanks,
Vijay V.

Sent from Surface

From: Samuel Bercovicimailto:samu...@radware.com
Sent: ‎Friday‎, ‎15‎ ‎May‎ ‎2015 ‎00‎:‎30
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org, Evgeny 
Fedorukmailto:evge...@radware.com, Adam 
Harwellmailto:adam.harw...@rackspace.com, Kyle 
Mesterymailto:mest...@mestery.com, Brandon 
Loganmailto:brandon.lo...@rackspace.com, Johnson, Michael (HP Cloud - 
Corvallis)mailto:michael.d.john...@hp.com, Doug 
Wiegleymailto:do...@a10networks.com, Samuel 
Bercovicimailto:samu...@radware.com

Hi Everyone,

As you may be aware, we have a speaking slot on the Vancouver summit to discuss 
“LBaaS v2, Kilo and beyond” on Monday 
https://openstacksummitmay2015vancouver.sched.org/event/3f1e9e24f36238152749afea9c21a264#.VVTwCPmqqko

We are considering to show vendors demos or list/link such movies.
Please let us know if you have such so we can list/include in the talk.

Regards,
-Sam.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

[Vijay Venkatachalam]

Here is the NetScaler video.

https://citrix.sharefile.com/d-s5476bbd39a643d48

Hope you will be able to accommodate.
Apologies for the late arrival.

Thanks,
Vijay V.

From: Doug Wiegley [doug...@parksidesoftware.com]
Sent: Friday, May 15, 2015 10:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Vijay Venkatachalam; Evgeny Fedoruk; Adam Harwell; Kyle Mestery; Brandon 
Logan; Johnson, Michael (HP Cloud - Corvallis); Doug Wiegley
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

I would say: 1-2 minutes, no audio, mp4, must highlight lbaas v2 or v2/v1. 
Anyone is welcome, even encouraged, to submit, likely up until about Sunday I’m 
guessing.

Thanks,
doug


On May 15, 2015, at 10:05 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com wrote:

Was thinking 1-2 minutes. Tomorrow would be fine.

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Friday, May 15, 2015 6:03 PM
To: OpenStack Development Mailing List (not for usage questions); Evgeny 
Fedoruk; Adam Harwell; Kyle Mestery; Brandon Logan; Johnson, Michael (HP Cloud 
- Corvallis); Doug Wiegley; Samuel Bercovici
Subject: Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

Hi Sam,
Thanks for probing. How many seconds/mins you have thought per vendor? By when 
do you need this? Will tomorrow work fine?


Thanks,
Vijay V.

Sent from Surface

From: Samuel Bercovicimailto:samu...@radware.com
Sent: ‎Friday‎, ‎15‎ ‎May‎ ‎2015 ‎00‎:‎30
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org, Evgeny 
Fedorukmailto:evge...@radware.com, Adam 
Harwellmailto:adam.harw...@rackspace.com, Kyle 
Mesterymailto:mest...@mestery.com, Brandon 
Loganmailto:brandon.lo...@rackspace.com, Johnson, Michael (HP Cloud - 
Corvallis)mailto:michael.d.john...@hp.com, Doug 
Wiegleymailto:do...@a10networks.com, Samuel 
Bercovicimailto:samu...@radware.com

Hi Everyone,

As you may be aware, we have a speaking slot on the Vancouver summit to discuss 
“LBaaS v2, Kilo and beyond” on Monday 
https://openstacksummitmay2015vancouver.sched.org/event/3f1e9e24f36238152749afea9c21a264#.VVTwCPmqqko

We are considering to show vendors demos or list/link such movies.
Please let us know if you have such so we can list/include in the talk.

Regards,
-Sam.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas]LBaaSv2 movies / links

[Vijay Venkatachalam]

Hi Sam,
Thanks for probing. How many seconds/mins you have thought per vendor? By when 
do you need this? Will tomorrow work fine?


Thanks,
Vijay V.

Sent from Surface

From: Samuel Bercovicimailto:samu...@radware.com
Sent: ‎Friday‎, ‎15‎ ‎May‎ ‎2015 ‎00‎:‎30
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org, Evgeny 
Fedorukmailto:evge...@radware.com, Adam 
Harwellmailto:adam.harw...@rackspace.com, Kyle 
Mesterymailto:mest...@mestery.com, Brandon 
Loganmailto:brandon.lo...@rackspace.com, Johnson, Michael (HP Cloud - 
Corvallis)mailto:michael.d.john...@hp.com, Doug 
Wiegleymailto:do...@a10networks.com, Samuel 
Bercovicimailto:samu...@radware.com

Hi Everyone,

As you may be aware, we have a speaking slot on the Vancouver summit to discuss 
“LBaaS v2, Kilo and beyond” on Monday 
https://openstacksummitmay2015vancouver.sched.org/event/3f1e9e24f36238152749afea9c21a264#.VVTwCPmqqko

We are considering to show vendors demos or list/link such movies.
Please let us know if you have such so we can list/include in the talk.

Regards,
-Sam.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

[Vijay Venkatachalam]

Congratulations Phil!


-Original Message-
From: Tom Creighton [mailto:tom.creigh...@rackspace.com] 
Sent: Wednesday, 22 April 2015 12:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core

Congratulations Phil!



 On Apr 21, 2015, at 11:54 AM, Doug Wiegley doug...@parksidesoftware.com 
 wrote:
 
 It’s been a week, welcome Phil.
 
 Thanks,
 doug
 
 
 On Apr 13, 2015, at 2:39 PM, Doug Wiegley doug...@parksidesoftware.com 
 wrote:
 
 Hi all,
 
 I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
 bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
 speak for themselves.
 
 Existing lbaas cores, please vote.  All three of us.  :-)
 
 [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
 
 Thanks,
 doug
 
 
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] canceling meeting

[Vijay Venkatachalam]

+1 For on demand meeting.

On demand lbaas meetings will happen in neutron meeting and not in Octavia 
meetings, right?

Sent from Surface

From: Susanne Ballemailto:sleipnir...@gmail.com
Sent: ‎Friday‎, ‎20‎ ‎March‎ ‎2015 ‎20‎:‎20
To: OpenStack Development Mailing List (not for usage 
questions)mailto:openstack-dev@lists.openstack.org

Make sense to me. Susanne

On Thu, Mar 19, 2015 at 5:49 PM, Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote:
Hi lbaas'ers,

Now that lbaasv2 has shipped, the need for a regular weekly meeting is 
greatly reduced. I propose that we cancel the regular meeting, and discuss 
neutron-y things during the neutron on-demand agenda, and octavia things in the 
already existing octavia meetings.

Any objections/alternatives?

Thanks,
doug



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][lbaas] Invalid import in tempest v2 api tests

[Vijay Venkatachalam]

Hi:

The LBaaS API tests are failing to run because test_pools.py(and other tests as 
well) are importing data_utils  from tempest.common.utils.

Looks like data_utils is moved to tempest_lib now and the API tests need to 
change to import from tempest_lib.

Is someone tracking this?

We are blocked in bringing up a CI for netscaler.

Also, we are thinking of running lbaas CLI tests as part of the CI.

Any suggestions/comments?


Thanks
Vijay


Sent from Surface

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Vijay Venkatachalam]

Thanks Doug.

My apologies for the delayed reply.

The change is merged, so replying here.

It is a welcome change in one way, there is always a root entity now in 
perspective while creating any entity.
Listener is created with loadbalancer and pool is created with listener.
The problem itself is eliminated because there is no DEFERRED stage.

But, this restricts pool in one listener. Basically reusing of a pools across 
listeners and loadbalancers is not possible now.

The use case of creating both a HTTPS vip and HTTP vip for the same pool is 
lost.

Basically, a user who will need that, should create 2 pools with the same 
members and manage them. Is that right?

Thanks,
Vijay V.


From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Tuesday, February 3, 2015 10:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
driver when entities get associated/disassociated with root entity?

I’d recommend taking a look at Brandon’s review: 
https://review.openstack.org/#/c/144834/

which aims to simplify exactly what you’re describing. Please leave feedback 
there.

Thanks,
doug


On Tue, Feb 3, 2015 at 7:13 AM, Vijay Venkatachalam 
vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote:
Hi:

In OpenStack neutron lbaas implementation, when entities are created/updated by 
the user, they might not be associated with the root entity, which is 
loadbalancer.
Since root entity has the driver information, the driver cannot be called by 
lbaas plugin during these operations by user.
Such entities are set in DEFFERED status until the entity is associated with 
root entity.
During this association operation (listener created with pool), the driver api 
is called for the current operation (listener create); and the driver is 
expected to perform the original operation (pool create) along with the current 
operation (listener create).
This leads to complex handling at the driver, I think it will be better for the 
lbaas plugin to call the original operation (pool create) driver API in 
addition to the current operation (listener create) API during the association 
operation.

That is the summary, please read on to understand the situation in detail.

Let’s take the example of pool create in driver.


a.   A pool create operation will not translate to a pool create api in the 
driver. There is a pool create in the driver API but that is never called today.

b.  When a listener is created with loadbalancer and pool, the driver’s 
listener create api is called and the driver is expected to create both pool 
and listener.

c.   When a listener is first created without loadbalancer but with a pool, 
the call does not reach driver. Later when the listener is updated with 
loadbalancer id,  the drivers listener update  API is called and the driver is 
expected to create both pool and listener.

d.  When a listener configured with pool and loadbalancer is updated with new 
pool id,  the driver’s listener update api is called. The driver is expected to 
delete the original pool that was associated, create the new pool and  also 
update the listener

As you can see this is leading to a quite a bit of handling in the driver code. 
This makes driver code complex.

How about handling this logic in lbaas plugin and it can call the “natural” 
functions that were deferred.

Whenever an entity is going from a DEFERRED to ACTIVE/CREATE status (through 
whichever workflow) the plugin can call the CREATE pool function of the driver.
Whenever an entity is going from an ACTIVE/CREATED to DEFERRED status (through 
whichever workflow) the plugin can call the DELETE pool function of the driver.

Thanks,
Vijay V.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Vijay Venkatachalam]

Hi:

In OpenStack neutron lbaas implementation, when entities are created/updated by 
the user, they might not be associated with the root entity, which is 
loadbalancer.
Since root entity has the driver information, the driver cannot be called by 
lbaas plugin during these operations by user.
Such entities are set in DEFFERED status until the entity is associated with 
root entity.
During this association operation (listener created with pool), the driver api 
is called for the current operation (listener create); and the driver is 
expected to perform the original operation (pool create) along with the current 
operation (listener create).
This leads to complex handling at the driver, I think it will be better for the 
lbaas plugin to call the original operation (pool create) driver API in 
addition to the current operation (listener create) API during the association 
operation.

That is the summary, please read on to understand the situation in detail.

Let's take the example of pool create in driver.


a.   A pool create operation will not translate to a pool create api in the 
driver. There is a pool create in the driver API but that is never called today.

b.  When a listener is created with loadbalancer and pool, the driver's 
listener create api is called and the driver is expected to create both pool 
and listener.

c.   When a listener is first created without loadbalancer but with a pool, 
the call does not reach driver. Later when the listener is updated with 
loadbalancer id,  the drivers listener update  API is called and the driver is 
expected to create both pool and listener.

d.  When a listener configured with pool and loadbalancer is updated with new 
pool id,  the driver's listener update api is called. The driver is expected to 
delete the original pool that was associated, create the new pool and  also 
update the listener

As you can see this is leading to a quite a bit of handling in the driver code. 
This makes driver code complex.

How about handling this logic in lbaas plugin and it can call the natural 
functions that were deferred.

Whenever an entity is going from a DEFERRED to ACTIVE/CREATE status (through 
whichever workflow) the plugin can call the CREATE pool function of the driver.
Whenever an entity is going from an ACTIVE/CREATED to DEFERRED status (through 
whichever workflow) the plugin can call the DELETE pool function of the driver.

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] rescheduling meeting

[Vijay Venkatachalam]

Any day 16:00 UTC is fine with me.
17:00 UTC+ is quite late in India.


-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: 04 November 2014 08:42
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] rescheduling meeting

Hi LBaaS (and others),

We’ve been talking about possibly re-schedulng the LBaaS meeting to a time to 
is less crazy early for those in the US.  Alternately, we could also start 
alternating times.  For now, let’s see if we can find a slot that works every 
week.  Please respond with any time slots that you can NOT
attend:

Monday, 1600UTC
Monday, 1700UTC
Tuesday, 1600UTC (US pacific, 8am)
Tuesday, 1700UTC
Tuesday, 1800UTC
Wednesday, 1600UTC (US pacific, 8am)
Wednesday, 1700UTC
Wednesday, 1800UTC
Thursday, 1400UTC (US pacific, 6am)


Note that many of these slots will require the approval of the
#openstack-meeting-4 channel:

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

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


Thanks,
Doug

___
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][Octavia] Floating IP management

[Vijay Venkatachalam]

I felt guilty after reading Vijay B. ’s reply ☺.
My apologies to have replied in brief, here are my thoughts in detail.

Currently LB configuration exposed via floating IP is a 2 step operation.
User has to first “create a VIP with a private IP” and then “creates a FLIP and 
assigns FLIP to private VIP” which would result in a DNAT in the gateway.
The proposal is to combine these 2 steps, meaning make DNATing operation as 
part of VIP creation process.

While this seems to be a simple proposal I think we should consider finer 
details.
The proposal assumes that the FLIP is implemented by the gateway through a DNAT.
We should also be open to creating a VIP with a FLIP rather than a private IP.
Meaning FLIP will be hosted directly by the LB appliance.

In essence, LBaaS plugin will create the FLIP for the VIP and let the driver 
know about the FLIP that should get implemented.
The drivers should have a choice of implementing in its own way.
It could choose to

1.   Implement via the traditional route. Driver creates a private IP, 
implements VIP as a private IP in the lb appliance and calls Neutron to 
implement DNAT (FLIP to private VIP )

2.   Implement VIP as a FLIP directly on the LB appliance. Here there is no 
private IP involved.

Pros:
Not much changes in the LBaaS API, there is only one IP as part of the VIP.
We can ensure backward compatibility with the driver as well by having Step (1) 
implemented in abstract driver.

Thanks,
Vjay

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 15 October 2014 05:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Thanks for the doc.

The floating IP could be hosted directly by the lb backend/lb appliance as well?
It depends on the appliance deployment.

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: 14 October 2014 21:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Nice diagrams. :-) Thanks. Susanne

On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
wrote:

Hello all,

Heres some additional diagrams and docs. Not incredibly detailed, but
should get the point across.

Feel free to edit if needed.

Once we come to some kind of agreement and understanding I can rewrite
these more to be thorough and get them in a more official place. Also, I
understand theres other use cases not shown in the initial docs, so this
is a good time to collaborate to make this more thought out.

Please feel free to ping me with any questions,

Thank you


Google DOCS link for FLIP folder:
https://drive.google.com/folderview?id=0B2r4apUP7uPwU1FWUjJBN0NMbWMusp=sh
a
ring

-diagrams are draw.iohttp://draw.io based and can be opened from within 
Drive by
selecting the appropriate application.

On 10/7/14 2:25 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:

I'll add some more info to this as well:

Neutron LBaaS creates the neutron port for the VIP in the plugin layer
before drivers ever have any control.  In the case of an async driver,
it will then call the driver's create method, and then return to the
user the vip info.  This means the user will know the VIP before the
driver even finishes creating the load balancer.

So if Octavia is just going to create a floating IP and then associate
that floating IP to the neutron port, there is the problem of the user
not ever seeing the correct VIP (which would be the floating iP).

So really, we need to have a very detailed discussion on what the
options are for us to get this to work for those of us intending to use
floating ips as VIPs while also working for those only requiring a
neutron port.  I'm pretty sure this will require changing the way V2
behaves, but there's more discussion points needed on that.  Luckily, V2
is in a feature branch and not merged into Neutron master, so we can
change it pretty easily.  Phil and I will bring this up in the meeting
tomorrow, which may lead to a meeting topic in the neutron lbaas
meeting.

Thanks,
Brandon


On Mon, 2014-10-06 at 17:40 +, Phillip Toohill wrote:
 Hello All,

 I wanted to start a discussion on floating IP management and ultimately
 decide how the LBaaS group wants to handle the association.

 There is a need to utilize floating IPs(FLIP) and its API calls to
 associate a FLIP to the neutron port that we currently spin up.

 See DOCS here:

 
http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_c
r
eate.html

 Currently, LBaaS will make internal service calls (clean interface :/)
to create and attach a Neutron port.
 The VIP from this port is added to the Loadbalancer object of the Load
balancer

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

[Vijay Venkatachalam]

 I'm unsure the meaning of hosting FLIP directly on the LB.

There can be LB appliances (usually physical appliance) that sit at the edge 
and is connected to receive floating IP traffic .

In such a case, the VIP/Virtual Server with FLIP  can be configured in the LB 
appliance.
Meaning, LB appliance is now the owner of the FLIP and will be responding to 
ARPs.


Thanks,
Vijay V.

From: Phillip Toohill [mailto:phillip.tooh...@rackspace.com]
Sent: 15 October 2014 23:16
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

No worries :)

Could you possibly clarify what you mean by the FLIP hosted directly on the LB?

Im currently assuming the FLIP pools are designated in Neutron at this point 
and we would simply be associating with the VIP port, I'm unsure the meaning of 
hosting FLIP directly on the LB.

Thank you for responses! There is definitely a more thought out discussion to 
be had, and glad these ideas are being brought up now rather than later.

From: Vijay Venkatachalam 
vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, October 15, 2014 9:38 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

I felt guilty after reading Vijay B. 's reply :).
My apologies to have replied in brief, here are my thoughts in detail.

Currently LB configuration exposed via floating IP is a 2 step operation.
User has to first create a VIP with a private IP and then creates a FLIP and 
assigns FLIP to private VIP which would result in a DNAT in the gateway.
The proposal is to combine these 2 steps, meaning make DNATing operation as 
part of VIP creation process.

While this seems to be a simple proposal I think we should consider finer 
details.
The proposal assumes that the FLIP is implemented by the gateway through a DNAT.
We should also be open to creating a VIP with a FLIP rather than a private IP.
Meaning FLIP will be hosted directly by the LB appliance.

In essence, LBaaS plugin will create the FLIP for the VIP and let the driver 
know about the FLIP that should get implemented.
The drivers should have a choice of implementing in its own way.
It could choose to

1.  Implement via the traditional route. Driver creates a private IP, 
implements VIP as a private IP in the lb appliance and calls Neutron to 
implement DNAT (FLIP to private VIP )

2.  Implement VIP as a FLIP directly on the LB appliance. Here there is no 
private IP involved.

Pros:
Not much changes in the LBaaS API, there is only one IP as part of the VIP.
We can ensure backward compatibility with the driver as well by having Step (1) 
implemented in abstract driver.

Thanks,
Vjay

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 15 October 2014 05:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Thanks for the doc.

The floating IP could be hosted directly by the lb backend/lb appliance as well?
It depends on the appliance deployment.

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: 14 October 2014 21:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Nice diagrams. :-) Thanks. Susanne

On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
wrote:

Hello all,

Heres some additional diagrams and docs. Not incredibly detailed, but
should get the point across.

Feel free to edit if needed.

Once we come to some kind of agreement and understanding I can rewrite
these more to be thorough and get them in a more official place. Also, I
understand theres other use cases not shown in the initial docs, so this
is a good time to collaborate to make this more thought out.

Please feel free to ping me with any questions,

Thank you


Google DOCS link for FLIP folder:
https://drive.google.com/folderview?id=0B2r4apUP7uPwU1FWUjJBN0NMbWMusp=sh
a
ring

-diagrams are draw.iohttp://draw.io based and can be opened from within 
Drive by
selecting the appropriate application.

On 10/7/14 2:25 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:

I'll add some more info to this as well:

Neutron LBaaS creates the neutron port for the VIP in the plugin layer
before drivers ever have any control.  In the case of an async driver,
it will then call the driver's create method

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

[Vijay Venkatachalam]

Thanks for the doc.

The floating IP could be hosted directly by the lb backend/lb appliance as well?
It depends on the appliance deployment.

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: 14 October 2014 21:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Nice diagrams. :-) Thanks. Susanne

On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, Phillip Toohill 
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
wrote:

Hello all,

Heres some additional diagrams and docs. Not incredibly detailed, but
should get the point across.

Feel free to edit if needed.

Once we come to some kind of agreement and understanding I can rewrite
these more to be thorough and get them in a more official place. Also, I
understand theres other use cases not shown in the initial docs, so this
is a good time to collaborate to make this more thought out.

Please feel free to ping me with any questions,

Thank you


Google DOCS link for FLIP folder:
https://drive.google.com/folderview?id=0B2r4apUP7uPwU1FWUjJBN0NMbWMusp=sh
a
ring

-diagrams are draw.iohttp://draw.io based and can be opened from within 
Drive by
selecting the appropriate application.

On 10/7/14 2:25 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:

I'll add some more info to this as well:

Neutron LBaaS creates the neutron port for the VIP in the plugin layer
before drivers ever have any control.  In the case of an async driver,
it will then call the driver's create method, and then return to the
user the vip info.  This means the user will know the VIP before the
driver even finishes creating the load balancer.

So if Octavia is just going to create a floating IP and then associate
that floating IP to the neutron port, there is the problem of the user
not ever seeing the correct VIP (which would be the floating iP).

So really, we need to have a very detailed discussion on what the
options are for us to get this to work for those of us intending to use
floating ips as VIPs while also working for those only requiring a
neutron port.  I'm pretty sure this will require changing the way V2
behaves, but there's more discussion points needed on that.  Luckily, V2
is in a feature branch and not merged into Neutron master, so we can
change it pretty easily.  Phil and I will bring this up in the meeting
tomorrow, which may lead to a meeting topic in the neutron lbaas
meeting.

Thanks,
Brandon


On Mon, 2014-10-06 at 17:40 +, Phillip Toohill wrote:
 Hello All,

 I wanted to start a discussion on floating IP management and ultimately
 decide how the LBaaS group wants to handle the association.

 There is a need to utilize floating IPs(FLIP) and its API calls to
 associate a FLIP to the neutron port that we currently spin up.

 See DOCS here:

 
http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_c
r
eate.html

 Currently, LBaaS will make internal service calls (clean interface :/)
to create and attach a Neutron port.
 The VIP from this port is added to the Loadbalancer object of the Load
balancer configuration and returned to the user.

 This creates a bit of a problem if we want to associate a FLIP with the
port and display the FLIP to the user instead of
 the ports VIP because the port is currently created and attached in the
plugin and there is no code anywhere to handle the FLIP
 association.

 To keep this short and to the point:

 We need to discuss where and how we want to handle this association. I
have a few questions to start it off.

 Do we want to add logic in the plugin to call the FLIP association API?

 If we have logic in the plugin should we have configuration that
identifies weather to use/return the FLIP instead the port VIP?

 Would we rather have logic for FLIP association in the drivers?

 If logic is in the drivers would we still return the port VIP to the
user then later overwrite it with the FLIP?
 Or would we have configuration to not return the port VIP initially,
but an additional query would show the associated FLIP.


 Is there an internal service call for this, and if so would we use it
instead of API calls?


 Theres plenty of other thoughts and questions to be asked and discussed
in regards to FLIP handling,
 hopefully this will get us going. I'm certain I may not be completely
understanding this and
 is the hopes of this email to clarify any uncertainties.





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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org

[openstack-dev] [Neutron][LBaaS] Error at context exit for subnet in unit test case

[Vijay Venkatachalam]

Hi,

I am writing a unit testcase with context as subnet, code here [1]. 
When the context exits a delete of subnet is attempted and 
I am getting a MismatchError . Traceback posted here [2]. 

What could be going wrong here?

Testcase is written like the following
--
with self.subnet() as subnet:
blah1
blah2
blah3
--

I am getting a MismatchError: 409 != 204 error at blah3 when context exits.

[1] UnitTestCase Snippet - http://pastebin.com/rMtf2dQX
[2] Traceback  - http://pastebin.com/2sPcZ8Jk


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] Error at context exit for subnet in unit test case

[Vijay Venkatachalam]

I observed the following text as well One or more ports have an IP allocation 
from this subnet.
Looks like loadbalancer context exit at blah2 is not cleaning up the port 
that was created. 
This ultimately resulted in failure of delete subnet at blah3.

--
with self.subnet() as subnet:
blah1
with self.loadbalancer() as lb:
blah2
blah3
--

-Original Message-
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] 
Sent: 20 August 2014 19:12
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Error at context exit for subnet in 
unit test case

Hi,

I am writing a unit testcase with context as subnet, code here [1]. 
When the context exits a delete of subnet is attempted and I am getting a 
MismatchError . Traceback posted here [2]. 

What could be going wrong here?

Testcase is written like the following
--
with self.subnet() as subnet:
blah1
blah2
blah3
--

I am getting a MismatchError: 409 != 204 error at blah3 when context exits.

[1] UnitTestCase Snippet - http://pastebin.com/rMtf2dQX [2] Traceback  - 
http://pastebin.com/2sPcZ8Jk


Thanks,
Vijay V.

___
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] Error at context exit for subnet in unit test case

[Vijay Venkatachalam]

Hey Brandon,

Thanks for looking into it. Yes I figured this out too and passed the 
pre-created subnet to loadbalancer method.
Issue here is  slightly different, please have a look at the review 
https://review.openstack.org/#/c/114173/
Inorder to make it work; I have made network, subnet and loadbalancer with 
delete=False.

The original problem creating snippet code is 

with self.subnet() as subnet:
with self.loadbalancer(subnet=subnet, no_delete=True,
   provider=LBAAS_PROVIDER_NAME) as testlb:
print error after this statement

The original problem creating full code is here http://pastebin.com/jWmrpiG1

Thanks,
Vijay V.

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: 20 August 2014 21:24
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Error at context exit for subnet 
in unit test case

Hey Vijay,
Figured out the issue you are having.  In that particular test you are creating 
the same subnet twice.  The first time you create it is in the 
contextlib.nested, the second time is the self.loadbalancer method that will 
create a subnet if you do not pass it.  So you should pass subnet=subnet in the 
self.loadbalancer method.

After that there are other minor issues in the driver, mainly accessing the obj 
passed in as a dictionary and not an object (obj[id] vs obj.id).

Let me know if you need more information.

Thanks,
Brandon
On Wed, 2014-08-20 at 14:27 +, Vijay Venkatachalam wrote:
 I observed the following text as well One or more ports have an IP 
 allocation from this subnet.
 Looks like loadbalancer context exit at blah2 is not cleaning up the port 
 that was created. 
 This ultimately resulted in failure of delete subnet at blah3.
 
 --
 with self.subnet() as subnet:
 blah1
 with self.loadbalancer() as lb:
 blah2
 blah3
 --
 
 -Original Message-
 From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
 Sent: 20 August 2014 19:12
 To: OpenStack Development Mailing List 
 (openstack-dev@lists.openstack.org)
 Subject: [openstack-dev] [Neutron][LBaaS] Error at context exit for 
 subnet in unit test case
 
 Hi,
 
 I am writing a unit testcase with context as subnet, code here [1]. 
 When the context exits a delete of subnet is attempted and I am getting a 
 MismatchError . Traceback posted here [2]. 
 
 What could be going wrong here?
 
 Testcase is written like the following
 --
 with self.subnet() as subnet:
 blah1
 blah2
 blah3
 --
 
 I am getting a MismatchError: 409 != 204 error at blah3 when context exits.
 
 [1] UnitTestCase Snippet - http://pastebin.com/rMtf2dQX [2] Traceback  
 - http://pastebin.com/2sPcZ8Jk
 
 
 Thanks,
 Vijay V.
 
 ___
 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

[openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches

[Vijay Venkatachalam]

Hi Brandon,

I am trying to rebase Netscaler driver to the latest v2 patches as mentioned in 
https://wiki.openstack.org/wiki/GerritWorkflow
But it failed during review submit

It failed with the following error

remote: Processing changes: refs: 1, done
To ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git
 ! [remote rejected] HEAD - refs/publish/master/bp/netscaler-lbass-v2-driver 
(squash commits first)
error: failed to push some refs to 
'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git'


Any clues on how to proceed?

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] Failure when trying to rebase to latest v2 patches

[Vijay Venkatachalam]

Hi Brandon,

Thanks for the quick reply.
I don't use a UI. 

This is what I did to rebase to the latest dependent patches, without doing any 
changes to my patchset files.

git checkout netscaler-lbaas-driver-v2 # netscaler-lbaas-driver-v2  == the 
topic branch where I had my original changes. 
git review -d 105610  # this pulls the latest changes you have made for v2 into 
the branch review/brandon_logan/bp/lbaas-api-and-objmodel-improvement
git checkout netscaler-lbaas-driver-v2
git rebase -i review/brandon_logan/bp/lbaas-api-and-objmodel-improvement
# At this point the rebase didn't succeed, I resolved the conflict 
git add files_that_are_resolved
git commit -a --amend
git review 
errors

Thanks,
Vijay V.


-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: 18 August 2014 08:53
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to 
latest v2 patches

Hi Vijay,
Are you trying to rebase by pulling down the new changes and rebasing your 
branch on top of that?  That'll usually end up wrong because of commit hashes.  
Have you tried using the rebase button gerrit provides?  Let me know how 
exactly you're trying to rebase if you've already tried the gerrit rebase 
button or if you'd like to know how to do it by rebasing locally. 
I'm going to add more details to that GerritWorkflow wiki page.  It's lacking 
on dependency chains and how to do rebases, cherry-picks, etc without 
accidentally pushing more patch sets to dependent reviews.  I've been meaning 
to do I've just been lazy about doing that.

Thanks,
Brandon

From: Vijay Venkatachalam [vijay.venkatacha...@citrix.com]
Sent: Sunday, August 17, 2014 9:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to 
latest v2 patches

Hi Brandon,

I am trying to rebase Netscaler driver to the latest v2 patches as mentioned in 
https://wiki.openstack.org/wiki/GerritWorkflow
But it failed during review submit

It failed with the following error

remote: Processing changes: refs: 1, done To 
ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git
 ! [remote rejected] HEAD - refs/publish/master/bp/netscaler-lbass-v2-driver 
(squash commits first)
error: failed to push some refs to 
'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git'


Any clues on how to proceed?

Thanks,
Vijay V.
___
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] Failure when trying to rebase to latest v2 patches

[Vijay Venkatachalam]

This worked. Thanks!

But this procedure requires to clone again.

I wonder why rebase didn’t work and cherry pick worked. May be I should tried 
the gerrit UI.

As said in the earlier mail to Brandon, this is what I did.

# netscaler-lbaas-driver-v2  == the topic branch where I had my original 
changes.
git checkout netscaler-lbaas-driver-v2 
git review -d 105610  
# the above command pulls the latest dependent changes into 
review/brandon_logan/bp/lbaas-api-and-objmodel-improvement
git checkout netscaler-lbaas-driver-v2
git rebase -i review/brandon_logan/bp/lbaas-api-and-objmodel-improvement
# At this point the rebase didn’t succeed, I resolved the conflicts
git add files_that_are_resolved 
git commit -a --amend 
git review 
#At this point I got the errors. 

Thanks,
Vijay V.
-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: 18 August 2014 08:54
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to 
latest v2 patches

From the looks of your error, you at least have a problem with more than one 
commit in your topic branch.

Here¹s the process that I use.  I¹m not claiming it¹s the best, but it works 
without rewriting Brandon¹s commits.  Watch the git log at the end, and make 
sure the dependent hashes match what¹s in gerrit, before the Œgit
review¹:

git clone https://review.openstack.org/openstack/neutron
neutron-juno-update1
cd neutron-juno-update1/
git review -d 105610
git checkout -b bp/a10-lbaas-driver
*cherry-pick your commit from gerrit* (e.g. git fetch 
https://review.openstack.org/openstack/neutron refs/changes/37/106937/26  git 
cherry-pick FETCH_HEAD) *resolve conflicts* git cherry-pick ‹continue *make 
changes* git commit -a --amend git log -n5 --decorate --pretty=oneline git 
review

If you¹re not making any changes, then you can just hit the Œrebase¹ button in 
the gerrit ui.

Thanks,
doug



On 8/17/14, 8:19 PM, Vijay Venkatachalam
vijay.venkatacha...@citrix.com wrote:

Hi Brandon,

I am trying to rebase Netscaler driver to the latest v2 patches as 
mentioned in https://wiki.openstack.org/wiki/GerritWorkflow
But it failed during review submit

It failed with the following error

remote: Processing changes: refs: 1, done To 
ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.g
it
 ! [remote rejected] HEAD -
refs/publish/master/bp/netscaler-lbass-v2-driver (squash commits first)
error: failed to push some refs to
'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.
git
'


Any clues on how to proceed?

Thanks,
Vijay V.
___
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] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

[Vijay Venkatachalam]

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] Continuing on Calling driver interface on every API request

[Vijay Venkatachalam]

Yes, the point was to say the plugin need not restrict and let driver decide 
what to do with the API.

Even if the call was made to driver instantaneously, I understand, the driver 
might decide to ignore 
first and schedule later. But, if the call is present, there is scope for 
validation. 
Also, the driver might be scheduling an async-api to backend, in which case  
deployment error 
cannot be shown to the user instantaneously.

W.r.t. identifying a provider/driver, how would it be to make tenant the 
default root object? 
tenantid is already associated with each of these entities, so no additional 
pain. 
For the tenant who wants to override let him specify provider in each of the 
entities.
If you think of this in terms of the UI, let's say if the loadbalancer 
configuration is exposed 
as a single wizard (which has loadbalancer, listener, pool, monitor properties) 
then provider
 is chosen only once. 

Curious question, is flavour framework expected to address this problem?

Thanks,
Vijay V.

-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: 11 August 2014 22:02
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 Sam,

Very true.  I think that Vijay’s objection is that we are currently imposing a 
logical structure on the driver, when it should be a driver decision.  
Certainly, it goes both ways.

And I also agree that the mechanism for returning multiple errors, and the 
ability to specify whether those errors are fatal or not, individually, is 
currently weak.

Doug


On 8/11/14, 10:21 AM, Samuel Bercovici samu...@radware.com wrote:

Hi Doug,

In some implementations Driver !== Device. I think this is also true 
for HA Proxy.
This might mean that there is a difference between creating a logical 
object and when there is enough information to actually schedule/place 
this into a device.
The ability to express such errors (detecting an error on a logical 
object after it was created but when it actually get scheduled) should 
be discussed and addressed anyway.

-Sam.


-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com]
Sent: Monday, August 11, 2014 6:55 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 all,

 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.

You¹re right, but I think the point of Vijay¹s example was to highlight 
the combo error problem with populating all of the driver objects at 
once (in short, the driver interface isn¹t well suited to that model.)  
That his one example can be covered by API validators is irrelevant.  
Consider a backend that does not support APP_COOKIE¹s, or 
HTTPS_TERMINATED (but has multiple listeners) instead.  Should the 
entire load balancer create fail, or should it offer degraded service?  
Do all drivers have to implement a transaction rollback; wait, the 
interface makes that very hard.  That¹s his point.  The driver is no 
longer just glue code between interfaces; it¹s now a mini-object error handler.


 Having provider defined in multiple places does not make sense.

Channeling Brandon, who can yell if I get this wrong, the point is not 
to have a potentially different provider on each object.  It¹s to allow 
a provider to be assigned when the first object in the tree is created, 
so that future related objects will always get routed to the same provider.
Not knowing which provider should get all the objects is why we have to 
wait until we see a LoadBalancer object.


All of this sort of edge case nonsense is because we (the royal we, the 
community), wanted all load balancer objects to be ³root² objects, even 
though only one of them is an actual root today, to support 
many-to-many relationships among all of them, 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 samu...@radware.com wrote:

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

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

[Vijay Venkatachalam]

Thanks Brandon for constant  improvisation.

I agree with Doug. Please update current one. We already hv  more number of 
reviews :-). It will be difficult to manage if we add more.

Thanks,
Vijay

Sent using CloudMagic

On Sun, Aug 10, 2014 at 3:23 AM, Doug Wiegley 
do...@a10networks.commailto:do...@a10networks.com wrote:


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 brandon.lo...@rackspace.com 
 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] status in entities

[Vijay Venkatachalam]

I agree. the current status can reflect the deployment status and we can add a 
new attribute to reflect operational status.

I also agree that adminstate_up should definitely affect operational status. 
But driver could choose to unprovision when admin state is set to false. In 
which case status will also change.

If agenda permits,  can we discuss this in the upcoming weekly meeting?

Sent using 
CloudMagichttps://cloudmagic.com/k/d/mailapp?ct=pacv=5.0.32pv=4.2.2

On Wed, Aug 06, 2014 at 2:46 AM, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:

Hi guys,

I understood that admin_state_up was a manipulable field which (when working 
correctly) should change the entity to an operational status of ADMIN_DOWN or 
something similar to that. In any case, +1 on the deeper discussion of status.

How urgent is it to resolve the discussion around status? We could potentially 
bring the interested parties together via google hangout or webex (to 
facilitate the high bandwidth).

Stephen


On Tue, Aug 5, 2014 at 9:05 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Isn't that what admin_state_up is for?

But yes we do need a deeper discussion on this and many other things.

On Tue, 2014-08-05 at 15:42 +, Eichberger, German wrote:
 There was also talk about a third administrative status like ON/OFF...

 We really need a deeper status discussion - likely high bandwith to work all 
 of that out.

 German

 -Original Message-
 From: Brandon Logan 
 [mailto:brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com]
 Sent: Tuesday, August 05, 2014 8:27 AM
 To: 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS] status in entities


 Hello Vijay!

 Well this is a hold over from v1, but the status is a provisioning status.  
 So yes, when something is deployed successfully it should be ACTIVE.  The 
 exception to this is the member status, in that it's status can be INACTIVE 
 if a health check fails.  Now this will probably cause edge cases when health 
 checks and updates are happening to the same member.  It's been talked about 
 before, but we need to really have two types of status fields, provisioning 
 and operational.  IMHO, that should be something we try to get into K.

 Thanks,
 Brandon

 On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote:
  Hi:
 
 I think we had some discussions around ‘status’
  attribute earlier, I don’t recollect the conclusion.
 
  Does it reflect the deployment status?
 
 Meaning, if the status of an entity is ACTIVE, the user
  has to infer that the entity is deployed successfully in the
  backend/loadbalancer.
 
  Thanks,
 
  Vijay V.
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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

Re: [openstack-dev] [Neutron][LBaaS] Weekly IRC Agenda

[Vijay Venkatachalam]

I couldn't edit the wiki. Want to add 2 items

1. Separating deployment and operational status.
2. Can  driver interface be called for every API request?
  Ex. It is not called for create pool.

Sent using 
CloudMagichttps://cloudmagic.com/k/d/mailapp?ct=pacv=5.0.32pv=4.2.2

On Thu, Aug 07, 2014 at 3:54 AM, Jorge Miramontes 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote:

Hey LBaaS folks,

This is you friendly reminder to provide any agenda items for tomorrow's weekly 
IRC meeting. Please add them to the agenda wiki == 
https://wiki.openstack.org/wiki/Network/LBaaS#Agenda. The agenda currently has 
these items:

  *   Review Updates

Cheers,
--Jorge

P.S. Also, please don't forget to update the weekly standup == 
https://etherpad.openstack.org/p/neutron-lbaas-weekly-standup
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] status in entities

[Vijay Venkatachalam]

Hi:
   I think we had some discussions around 'status' attribute 
earlier, I don't recollect the conclusion.
Does it reflect the deployment status?
   Meaning, if the status of an entity is ACTIVE, the user has to 
infer that the entity is deployed successfully in the backend/loadbalancer.
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] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

[Vijay Venkatachalam]

Apologies for the delayed response.

I am OK with displaying the certificates contents as part of the API, that 
should not harm.

I think the discussion has to be split into 2 topics.


1.   Certificate conflict resolution. Meaning what is expected when 2 or 
more certificates become eligible during SSL negotiation

2.   SAN support

I will send out 2 separate mails on this.


From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Tuesday, July 15, 2014 11:52 PM
To: OpenStack Development Mailing List (not for usage questions); Vijay 
Venkatachalam
Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

OK.

Let me be more precise, extracting the information for view sake / validation 
would be good.
Providing values that are different than what is in the x509 is what I am 
opposed to.

+1 for Carlos on the library and that it should be ubiquitously used.

I will wait for Vijay to speak for himself in this regard…

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 15, 2014 8:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

+1 to German's and  Carlos' comments.

It's also worth pointing out that some UIs will definitely want to show SAN 
information and the like, so either having this available as part of the API, 
or as a standard library we write which then gets used by multiple drivers is 
going to be necessary.

If we're extracting the Subject Common Name in any place in the code then we 
also need to be extracting the Subject Alternative Names at the same place. 
From the perspective of the SNI standard, there's no difference in how these 
fields should be treated, 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 
carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com
 wrote:

 Hi,


 Obtaining the domain name from the x509 is probably more of a 
 driver/backend/device capability, it would make sense to have a library that 
 could be used by anyone wishing to do so in their driver code.
You can do what ever you want in *your* driver. The code to extract this 
information will be apart of the API and needs to be mentioned in the spec now. 
PyOpenSSL with PyASN1 are the most likely candidates.

Carlos D. Garza

 -Sam.



 From: Eichberger, German 
 [mailto:german.eichber...@hp.commailto:german.eichber...@hp.com]
 Sent: Tuesday, July 15, 2014 6:43 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - 
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi,

 My impression was that the frontend would extract the names and hand them to 
 the driver.  This has the following advantages:

 · We can be sure all drivers can extract the same names
 · No duplicate code to maintain
 · If we ever allow the user to specify the names on UI rather in the 
 certificate the driver doesn’t need to change.

 I think I saw Adam say something similar in a comment to the code.

 Thanks,
 German

 From: Evgeny Fedoruk [mailto:evge...@radware.commailto:evge...@radware.com]
 Sent: Tuesday, July 15, 2014 7:24 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
 SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi All,

 Since this issue came up from TLS capabilities RST doc review, I opened a ML 
 thread for it to make the decision.
 Currently, the document says:

 “
 For SNI functionality, tenant will supply list of TLS containers in specific
 Order.
 In case when specific back-end is not able to support SNI capabilities,
 its driver should throw an exception. The exception message should state
 that this specific back-end (provider) does not support SNI capability.
 The clear sign of listener's requirement for SNI capability is
 a none empty SNI container ids list.
 However, reference implementation must support SNI capability.

 Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames
 from the certificate which will determine the hostname(s) the certificate
 is associated with.

 The order of SNI containers list may be used by specific back-end code,
 like Radware's, for specifying priorities among certificates.
 In case when two or more uploaded certificates are valid for the same DNS name
 and the tenant has specific requirements around which one wins this collision,
 certificate ordering provides a mechanism to define which cert wins in the
 event of a collision

[openstack-dev] [Neutron][LBaaS] TLS capability - Certificate conflict resolution

[Vijay Venkatachalam]

Do you know if the SSL/SNI IETF spec details about conflict resolution. I am 
assuming not.

Because of this ambiguity each backend employs its own mechanism to resolve 
conflicts.

There are 3 choices now
1.   The LBaaS extension does not allow conflicting certificates to be 
bound using validation
2.   Allow each backend conflict resolution mechanism to get into the spec
3.   Does not specify anything in the spec, no mechanism introduced and let 
the driver deal with it.

Both HA proxy and Radware uses configuration as a mechanism to resolve. Radware 
uses order while HA Proxy uses externally specified DNS names.
NetScaler implementation uses the best possible match algorithm

For ex, let’s say 3 certs are bound to the same endpoint with the following SNs
www.finance.abc.comhttp://www.finance.abc.com
*.finance.abc.com
*.*.abc.com

If the host request is  payroll.finance.abc.com  we shall  use  
*.finance.abc.com
If it is  payroll.engg.abc.com  we shall use  *.*.abc.com

NetScaler won’t not allow 2 certs to have the same SN.

From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Tuesday, July 15, 2014 11:52 PM
To: OpenStack Development Mailing List (not for usage questions); Vijay 
Venkatachalam
Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

OK.

Let me be more precise, extracting the information for view sake / validation 
would be good.
Providing values that are different than what is in the x509 is what I am 
opposed to.

+1 for Carlos on the library and that it should be ubiquitously used.

I will wait for Vijay to speak for himself in this regard…

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 15, 2014 8:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

+1 to German's and  Carlos' comments.

It's also worth pointing out that some UIs will definitely want to show SAN 
information and the like, so either having this available as part of the API, 
or as a standard library we write which then gets used by multiple drivers is 
going to be necessary.

If we're extracting the Subject Common Name in any place in the code then we 
also need to be extracting the Subject Alternative Names at the same place. 
From the perspective of the SNI standard, there's no difference in how these 
fields should be treated, 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 
carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com
 wrote:

 Hi,


 Obtaining the domain name from the x509 is probably more of a 
 driver/backend/device capability, it would make sense to have a library that 
 could be used by anyone wishing to do so in their driver code.
You can do what ever you want in *your* driver. The code to extract this 
information will be apart of the API and needs to be mentioned in the spec now. 
PyOpenSSL with PyASN1 are the most likely candidates.

Carlos D. Garza

 -Sam.



 From: Eichberger, German 
 [mailto:german.eichber...@hp.commailto:german.eichber...@hp.com]
 Sent: Tuesday, July 15, 2014 6:43 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - 
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi,

 My impression was that the frontend would extract the names and hand them to 
 the driver.  This has the following advantages:

 · We can be sure all drivers can extract the same names
 · No duplicate code to maintain
 · If we ever allow the user to specify the names on UI rather in the 
 certificate the driver doesn’t need to change.

 I think I saw Adam say something similar in a comment to the code.

 Thanks,
 German

 From: Evgeny Fedoruk [mailto:evge...@radware.commailto:evge...@radware.com]
 Sent: Tuesday, July 15, 2014 7:24 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
 SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi All,

 Since this issue came up from TLS capabilities RST doc review, I opened a ML 
 thread for it to make the decision.
 Currently, the document says:

 “
 For SNI functionality, tenant will supply list of TLS containers in specific
 Order.
 In case when specific back-end is not able to support SNI capabilities,
 its driver should throw an exception. The exception message should state
 that this specific back-end (provider) does not support SNI capability.
 The clear sign of listener's requirement for SNI capability

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)

[Vijay Venkatachalam]

I think it is best not to mention about SAN in the OpenStack 
TLS spec. It is expected that the backend should implement according to the 
SSL/SNI IETF spec.
Let’s leave the implementation/validation part to the driver.  For ex. 
NetScaler does not support SAN and the NetScaler driver could either throw an 
error if certs with SAN are used or ignore it.

Does anyone see a requirement for detailing?


Thanks,
Vijay V.


From: Vijay Venkatachalam
Sent: Wednesday, July 16, 2014 8:54 AM
To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for usage 
questions)'
Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

Apologies for the delayed response.

I am OK with displaying the certificates contents as part of the API, that 
should not harm.

I think the discussion has to be split into 2 topics.


1.   Certificate conflict resolution. Meaning what is expected when 2 or 
more certificates become eligible during SSL negotiation

2.   SAN support

I will send out 2 separate mails on this.


From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Tuesday, July 15, 2014 11:52 PM
To: OpenStack Development Mailing List (not for usage questions); Vijay 
Venkatachalam
Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

OK.

Let me be more precise, extracting the information for view sake / validation 
would be good.
Providing values that are different than what is in the x509 is what I am 
opposed to.

+1 for Carlos on the library and that it should be ubiquitously used.

I will wait for Vijay to speak for himself in this regard…

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 15, 2014 8:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
SubjectCommonName and/or SubjectAlternativeNames from X509

+1 to German's and  Carlos' comments.

It's also worth pointing out that some UIs will definitely want to show SAN 
information and the like, so either having this available as part of the API, 
or as a standard library we write which then gets used by multiple drivers is 
going to be necessary.

If we're extracting the Subject Common Name in any place in the code then we 
also need to be extracting the Subject Alternative Names at the same place. 
From the perspective of the SNI standard, there's no difference in how these 
fields should be treated, 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 
carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
samu...@radware.commailto:samu...@radware.com
 wrote:

 Hi,


 Obtaining the domain name from the x509 is probably more of a 
 driver/backend/device capability, it would make sense to have a library that 
 could be used by anyone wishing to do so in their driver code.
You can do what ever you want in *your* driver. The code to extract this 
information will be apart of the API and needs to be mentioned in the spec now. 
PyOpenSSL with PyASN1 are the most likely candidates.

Carlos D. Garza

 -Sam.



 From: Eichberger, German 
 [mailto:german.eichber...@hp.commailto:german.eichber...@hp.com]
 Sent: Tuesday, July 15, 2014 6:43 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - 
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi,

 My impression was that the frontend would extract the names and hand them to 
 the driver.  This has the following advantages:

 · We can be sure all drivers can extract the same names
 · No duplicate code to maintain
 · If we ever allow the user to specify the names on UI rather in the 
 certificate the driver doesn’t need to change.

 I think I saw Adam say something similar in a comment to the code.

 Thanks,
 German

 From: Evgeny Fedoruk [mailto:evge...@radware.commailto:evge...@radware.com]
 Sent: Tuesday, July 15, 2014 7:24 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting 
 SubjectCommonName and/or SubjectAlternativeNames from X509

 Hi All,

 Since this issue came up from TLS capabilities RST doc review, I opened a ML 
 thread for it to make the decision.
 Currently, the document says:

 “
 For SNI functionality, tenant will supply list of TLS containers in specific
 Order.
 In case when specific back-end is not able to support SNI capabilities,
 its driver should throw an exception. The exception message should state
 that this specific back-end (provider) does not support SNI capability

[openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

[Vijay Venkatachalam]

Hi Kyle,

There is indeed a NetScaler CI and is currently running API and scenario tests 
on  LBAAS changes + driver changes. It also votes. What time is the  Monday 3rd 
party meeting?

Thanks,
Vijay.

Sent using 
CloudMagichttps://cloudmagic.com/k/d/mailapp?ct=pacv=1.0.21.3pv=4.2.2

On Fri, Jul 11, 2014 at 9:27 PM, Kyle Mestery 
mest...@noironetworks.commailto:mest...@noironetworks.com wrote:

Since Juno-2 is quickly approaching, I wanted to update everyone on where
we're at with regards to third party testing in Neutron. The etherpad here [1]
was the original link with status. The link here [2] shows what is expected of
Neutron third party CI systems.

On the CI status side, I'd like to ask the owners of the following CI systems
to attend Monday's third party meeting [3] to discuss the status of their CI
systems. These are the ones which appear to be in trouble, aren't running,
or have some issues.


  1.  Cisco
 *   Not enough logs being saved.
 *   Log retention issues.
  2.  Citrix Netscaler LBaaS driver
 *   I don't think this has a third party CI system running.
  3.  Embrane (both plugin and LBaaS driver)
 *   Logs are tarred up and not viewable in web browser.
 *   Inconsistent runs at times.
  4.  IBM SDN-VE
 *   Currently inactive, moving to a new system.
  5.  One Convergence
 *   Very high failure rate for patch runs.
  6.  OpenDaylight
 *   Logs are tarred up and not viewable in web browser
  7.  PLUMgrid
 *   Not saving enough logs
  8.  Radware
 *   Logs are not viewable in browser
  9.  Tail-F
 *   Inconsistent past runs, need updates on status.
  10. vArmour FWaaS driver
 *   Can't view logs.
 *   Inconsistent runs against patches.

I'd like to take some time in the Monday meeting to go over the issues these
CI systems are having and give the maintainers a chance to discuss this with
us. The third party team is hopeful we can spend the energy in the meeting
working with CI maintainers who are actively interested in making progress
on improving their CI systems.

Per my email to the list in June [4], the expectation is that third party CI
systems in Neutron are running and following the guidelines set forth by
both Neutron and Infra. The weekly meeting is a place to seek help, and
we're happy that a large number of third party CI owners and maintainers
are using this resource.

I'd also like to encourange anyone with a patch for a plugin or driver in 
Neutron
to participate in the third-party meetings going forward as well. This will help
to ensure your CI system is running while your patch is being reviewed, and you
actively work to sort out issues during the review process to ensure smooth
merging of your plugin or driver.

Thank you!
Kyle

[1] https://etherpad.openstack.org/p/ZLp9Ow3tNq
[2] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
[3] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[4] http://lists.openstack.org/pipermail/openstack-dev/2014-June/037665.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Flavor meeting log captured?

[Vijay Venkatachalam]

Hi,

   I didn't attend the flavor framework meeting that was scheduled on irc 
#openstack-meeting-3  last Friday. Will be interested to see the meeting 
log/minutes. Was it captured?

Thanks,
Vijay V

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

[openstack-dev] Should TLS settings for listener be set through separate API/model?

[Vijay Venkatachalam]

Hi:



In the LBaaS TLS termination capability specification proposal



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



TLS settings like default certificate container id and SNI cert list are part 
of the listener properties.



I think it is better to have this as a separate entity so that the listener 
properties are clean and is not corrupted with TLS settings.



I liked the original SSL proposal better where TLS settings was a separate 
entity.



It is just 2 properties now but in future the TLS settings would grow and if we 
are going to introduce a TLS profile/params/settings entity later, it is better 
to do it now (albeit with min properties).



Thanks,

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

[openstack-dev] [Neutron][LBaaS]Should TLS settings for listener be set through separate API/model?

[Vijay Venkatachalam]

Hi:



In the LBaaS TLS termination capability specification proposal



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



TLS settings like default certificate container id and SNI cert list are part 
of the listener properties.



I think it is better to have this as a separate entity so that the listener 
properties are clean and is not corrupted with TLS settings.



I liked the original SSL proposal better where TLS settings was a separate 
entity.



It is just 2 properties now but in future the TLS settings would grow and if we 
are going to introduce a TLS profile/params/settings entity later, it is better 
to do it now (albeit with min properties).



Thanks,

Vijay V.



PS:

Adding with the right subject
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

[Vijay Venkatachalam]

Even though it might look like an over kill now, the model should pave way for 
the future.
So, +1 for Option 2.


From: Doug Wiegley [mailto:do...@a10networks.com]
Sent: Tuesday, June 24, 2014 6:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener 
be set through separate API/model?

Put me down for being in favor of option 1.

A single attribute in a 1:1 relationship?  Putting that in a new table sounds 
like premature optimization to me; design the database change for the future 
feature when you can see the spec for it.

Thanks,
Doug


From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, June 23, 2014 at 5:25 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener 
be set through separate API/model?

Also to add to pros for 2:

* Keeping the TLS stuff contained to its own objects means we can have separate 
development resources on each and not worry as much about overlapping domains. 
(TLS-related knowledge and knowledge of dealing with TCP / UDP listeners are 
separate knowledge domains. Or at least, the former is a more specialized 
subset of the latter.)

Note that what we're proposing means there's essentially a 1:0-1 relationship 
between Listener and this new yet-to-be-named object. (0 in case the Listener 
is not terminating TLS.)

Stephen

On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Whoops, [Neutron][LBaaS] got taken out of the subject line here.
Putting it back in.

On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
 Okay so we've talked a bit about this in IRC and now I'm sending this
 out as an update.  Here are the options with pros and cons that have
 come from that discussion.

 1) default_certificate_id is an attribute of the Listener object.

 Pros:
 -No extra entity needed

 Cons:
 -May bloat Listener object when more attributes are needed for only TLS
 termination.  Sounds like TLS version and cipher selection will be
 needed attributes in the future.


 2) A separate TLS Entity is created that is referenced by the Listener
 object.  This entity at first may only contain a certificate_id that
 references barbican.  Name and description can be allowed as well.

 Pros:
 -TLS domain specific attributes contained in its own entity
 -Future attributes would just be added to this entity and not bloat the
 Listener object.

 Cons:
 -It's another entity

 In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
 go.  Anyone agree or disagree?

 Thanks,
 Brandon

 On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
  The separate entity makes sense for certificates participating in an
  SNI configuration, but probably not so much for the 'default'
  certificate used when TLS is being terminated.
 
 
  Vijay: You're also right that other TLS-related attributes will
  probably get added to the Listener object. This probably makes sense
  if they apply to the Listener object as a whole. (This includes things
  like TLS version and cipher selection.)
 
 
  I don't see much of a point in creating a separate object to contain
  these fields, since it would have a 1:1 relationship with the
  Listener. It's true that for non-TLS-terminated Listeners, these
  fields wouldn't be used, but isn't that already the case in many other
  objects (not just in the Neutron LBaaS sub project)?
 
 
  Thanks,
  Stephen
 
 
 
 
 
 
  On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
  brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
  Vijay,
  I think the separate entity is still going to happen.  I don't
  think it
  has remvoed.  Or that is may just be my assumption.
 
  Thanks,
  Brandon
 
  On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
   Hi:
  
  
   In the LBaaS TLS termination capability specification
  proposal
  
   https://review.openstack.org/#/c/98640/
  
   TLS settings like default certificate container id and SNI
  cert list are part of the listener properties.
  
   I think it is better to have this as a separate entity so
  that the listener properties are clean and is not corrupted
  with TLS settings.
  
   I liked the original SSL proposal better where TLS settings
  was a separate entity.
  
   It is just 2 properties now but in future the TLS settings
  would grow and if we are going to introduce a TLS

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[Vijay Venkatachalam]

 TLS Container ID to the LBaaS create call,
get the container from Barbican, and store a shadow-copy of the
container again in Barbican, this time on the LBaaS service account.
The secret will now be duplicated (it still exists on the original tenant,
but also exists on the LBaaS tenant), but we're not talking about a huge
amount of data here -- just a few kilobytes. With this approach, we retain
most of the advantages we wanted to get from using Barbican -- we don't
need to worry about taking secret data through the LBaaS API (we still
just take a barbicanID from the user), and the user can still use a single
barbicanID (the original one they created -- the copies are invisible to
them) when passing their TLS info to other services. We gain the
additional advantage that it no longer matters what happens to the
original TLS container -- it could be deleted and it would not impact our
service.

What do you guys think of that option?



As an addendum (not saying we necessarily want to do this, but it's an
option), we COULD retain both the original and the copied barbicanID in
our database and attempt to fetch them in that order when we need the TLS
info again, which would allow us to do some alerting if the user does
delete their key. For example: the user has deleted their key because it
was compromised, but they forgot they used it on their loadbalancer - a
failover event occurs and we attempt to fetch the info from Barbican -
the first fetch fails, but the second fetch to our copy succeeds - the
failover of the LB is successful, and we send an alert to notify the user
that their LB is using TLS info that has been deleted from Barbican.


--Adam


https://keybase.io/rm_you





On 6/10/14 6:21 AM, Clark, Robert Graham 
robert.cl...@hp.commailto:robert.cl...@hp.com wrote:

It looks like this has come full circle and we are back at the simplest
case.

# Containers are immutable
# Changing a cert means creating a new container and, when ready,
pointing LBaaS at the new container

This makes a lot of sense to me, it removes a lot of handholding and
keeps Barbican and LBaaS nicely decoupled. It also keeps certificate
lifecycle management firmly in the hands of the user, which imho is a
good thing. With this model it¹s fairly trivial to provide guidance /
additional tooling for lifecycle management if required but at the same
time the simplest case (I want a cert and I want LBaaS) is met without
massive code overhead for edge-cases.


From: Vijay Venkatachalam
vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
g
Date: Tuesday, 10 June 2014 05:48
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.ormailto:openstack-...@lists.openstack.or
g
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas


My vote is for option #2 (without the registration). It is simpler to
start with this approach. How is delete handled though?

Ex. What is the expectation when user attempts to delete a
certificate/container which is referred by an entity like LBaaS listener?


1.   Will there be validation in Barbican to prevent this? *OR*

2.   LBaaS listener will have a dangling reference/pointer to
certificate?

Thanks,
Vijay V.

From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net]
Sent: Tuesday, June 10, 2014 7:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
Integration Ideas

Weighing in here:

I'm all for option #2 as well.

Stephen

On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum
cl...@fewbar.commailto:cl...@fewbar.commailto:cl...@fewbar.commailto:cl...@fewbar.com
 wrote:
Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700:
 Hi all,

 I¹m strongly in favor of having immutable TLS-typed containers, and very
 much opposed to storing every revision of changes done to a container.
I
 think that storing versioned containers would add too much complexity to
 Barbican, where immutable containers would work well.

Agree completely. Create a new one for new values. Keep the old ones
while they're still active.


 I¹m still not sold on the idea of registering services with Barbican,
even
 though (or maybe especially because) Barbican would not be using this
data
 for anything.  I understand the problem that we¹re trying to solve by
 associating different resources across projects, but I don¹t feel like
 Barbican is the right place to do this.

Agreed also, this is simply not Barbican or Neutron's role. Be a REST
API for secrets and networking, not all dancing all singing nannies that
prevent any possibly dangerous

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[Vijay Venkatachalam]

My vote is for option #2 (without the registration). It is simpler to start 
with this approach. How is delete handled though?

Ex. What is the expectation when user attempts to delete a 
certificate/container which is referred by an entity like LBaaS listener?


1.   Will there be validation in Barbican to prevent this? *OR*

2.   LBaaS listener will have a dangling reference/pointer to certificate?

Thanks,
Vijay V.

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, June 10, 2014 7:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

Weighing in here:

I'm all for option #2 as well.

Stephen

On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum 
cl...@fewbar.commailto:cl...@fewbar.com wrote:
Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700:
 Hi all,

 I’m strongly in favor of having immutable TLS-typed containers, and very
 much opposed to storing every revision of changes done to a container.  I
 think that storing versioned containers would add too much complexity to
 Barbican, where immutable containers would work well.

Agree completely. Create a new one for new values. Keep the old ones
while they're still active.


 I’m still not sold on the idea of registering services with Barbican, even
 though (or maybe especially because) Barbican would not be using this data
 for anything.  I understand the problem that we’re trying to solve by
 associating different resources across projects, but I don’t feel like
 Barbican is the right place to do this.

Agreed also, this is simply not Barbican or Neutron's role. Be a REST
API for secrets and networking, not all dancing all singing nannies that
prevent any possibly dangerous behavior with said API's.

 It seems we’re leaning towards option #2, but I would argue that
 orchestration of services is outside the scope of Barbican’s role as a
 secret-store.  I think this is a problem that may need to be solved at a
 higher level.  Maybe an openstack-wide registry of dependend entities
 across services?
An optional openstack-wide registry of depended entities is called
Heat.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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

Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

[Vijay Venkatachalam]

Ok, thanks.

So Listeners are indeed created independent of Loadbalancers and then 
associated to Loadbalancers.

-Vijay

From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Thursday, May 15, 2014 10:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

Hi,

If a tenant wishes to expose his application (listener, pool(s), etc.) via 
multiple different virtual IP addresses you can do so.

-Sam.

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Thursday, May 15, 2014 12:21 AM
To: OpenStack Development Mailing List (not for 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 Bercovici [mailto:samu...@radware.com]
Sent: Thursday, May 15, 2014 9:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

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

Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

[Vijay Venkatachalam]

Hi Stephen:


* The LBtoListener object is grayed out because it will need to exist in the 
database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use 
case), but should not be directly addressable via the user API. (This is also 
the reason it's got no tenant_id.)

When you say API is not available, it means this should not be considered like 
a resource/entity. Correct?

But then, there would be API like a bind API, that accepts loadbalancer_id  
listener_id,  which creates this object.
And also, there would be an API that will be used to list the listeners of a 
LoadBalancer.

Right?

* The vip group and vip anti group stuff is meant to solve the vip colocation / 
apolocation problem. These are optional objects that don't need to be created 
unless a user has colocation / apolocation needs.  (I'd be happy to run anyone 
through the logic on how these work, as it's probably not immediately 
intuitive.)
Yes please, could you explain on the ML!

Thanks,
Vijay V.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Wednesday, May 14, 2014 11:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

Aah--  and here's a small error correction. :)

Please also note:
* We're not yet in consensus on the L7 or SSL related objects, but the 
Loadbalancer, Listener, Pool, and Member should probably not change at this 
point (unless there are major objections voiced in the very near term).
* I've tried to use color coordination to indicate different logical parts that 
can probably be implemented in different blueprints / by different engineering 
teams.
* The LBtoListener object is grayed out because it will need to exist in the 
database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use 
case), but should not be directly addressable via the user API. (This is also 
the reason it's got no tenant_id.)
* The vip group and vip anti group stuff is meant to solve the vip colocation / 
apolocation problem. These are optional objects that don't need to be created 
unless a user has colocation / apolocation needs.  (I'd be happy to run anyone 
through the logic on how these work, as it's probably not immediately 
intuitive.)

Stephen


On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:
Also, apologies for the crappy formatting. I like gv files as they're easily 
tracked in a text-based revision control system (like git) that depends on 
useful diffs to do code reviews. But sometimes the layout it chooses is a 
little dumb.

Stephen

On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:
Hi Craig,

I'm attaching the latest object model diagram as discussed with the RAX team 
last night, Samuel and Eugene. Note that we don't necessarily have HP's 
blessing on this model yet, nor do we have Neutron core developer buy in.  But 
in any case, here it is.

Also, I think the #openstack-lbaas channel is a great idea!

Stephen

On Wed, May 14, 2014 at 9:05 AM, Craig Tracey 
cr...@craigtracey.commailto:cr...@craigtracey.com wrote:
Hi all,

From what I heard last night, it sounds like there has been some consensus 
achieved around the LBaaS object model.  Unfortunately, I missed this ad-hoc 
conversation.  Is someone capturing this information and/or perhaps posting to 
the list? someplace else?

On a related note, does it make sense to create an lbaas IRC topic channel?  
#openstack-lbaas?  Just thinking that a dedicated channel might help to make 
the weekly meetings more productive with less crosstalk.  Thoughts?

Best,
Craig

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



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807tel:%28800%29613-4305%20x807



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807tel:%28800%29613-4305%20x807



--
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

Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

[Vijay Venkatachalam]

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 Bercovici [mailto:samu...@radware.com]
Sent: Thursday, May 15, 2014 9:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad

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

Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 05/08 14-00 UTC

[Vijay Venkatachalam]

Excellent documentation. Thanks once again!

I see the VIP creation is documented as a POST to the following URL
http://client.url.com/v2.0/neutron/lbaas/vips

I think the VIP should be outside the purview of LBaaS and remain in general 
neutron. Today an IP gets reserved as part of creation of a neutron port.

Are you proposing to give an indirection for IP reservation? For ex. the  above 
API will ultimately create a neutron port in the background?

Thanks,
Vijay V.

 -Original Message-
 From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
 Sent: Thursday, May 8, 2014 1:40 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday,
 05/08 14-00 UTC
 
 All of our relevant material is in this Google Drive folder ==
 https://drive.google.com/#folders/0B_x8_4x6DRLad1NZMjgyVFhqakU
 
 Cheers,
 --Jorge
 
 
 
 
 On 5/7/14 1:19 PM, Kyle Mestery mest...@noironetworks.com wrote:
 
 Lets go over the Rackspace portion of the API comparison tomorrow then,
 and we can cover Stephen's on the ML when it's complete.
 
 On Wed, May 7, 2014 at 4:55 AM, Stephen Balukoff
 sbaluk...@bluebox.net
 wrote:
  Howdy, y'all!
 
  I just wanted to give you a quick update: It looks like the Rackspace
 team  is mostly done with their half of the API comparison, however,
 it is  extremely unlikely I'll be able to finish my half of this in
 time for the  team meeting this Thursday. I apologize for this.
 
  Stephen
 
 
  On Tue, May 6, 2014 at 1:27 PM, Eugene Nikanorov
 enikano...@mirantis.com
  wrote:
 
  Hi folks,
 
  This will be the last meeting before the summit, so I suggest we
  will focus on the agenda for two design track slots we have.
 
  Per my experience design tracks are not very good for in-depth
 discussion,  so it only make sense to present a road map and some
 other items that might  need core team attention like interaction
 with Barbican and such.
 
  Another item for the meeting will be comparison of API proposals
 which as  an action item from the last meeting.
 
  Thanks,
  Eugene.
 
  ___
  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 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] RackSpace API review (multi-call)

[Vijay Venkatachalam]

I am expecting to be more active on community on the LBaaS front. 

May be reviewing and picking-up a few items to  work as well.

I had a look at the proposal. Seeing Single  Multi-Call approach for each 
workflow 
makes it easy to understand. 

Thanks for the clear documentation, it is welcoming to review :-). I was not 
allowed to comment on WorkFlow doc, can you enable comments?

The single-call approach essentially creates the global pool/VIP. Once VIP/Pool 
is created using single call, are they reusable in multi-call?
For example: Can a pool created for HTTP endpoint/loadbalancer be used in HTTPS 
endpoint LB where termination occurs as well?

Also, would it be useful to include PUT as a single call? I see PUT only for 
POOL not for LB.
A user who started with single-call  POST, might like to continue to use the 
same approach for PUT/update as well.

Thanks,
Vijay V.

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] 
Sent: Thursday, May 1, 2014 3:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as you 
initials so I got confused. :)

Cheers,
--Jorge




On 4/30/14 5:17 PM, Jorge Miramontes jorge.miramon...@rackspace.com
wrote:

Hey everyone,

I agree that we need to be preparing for the summit. Using Google docs 
mixed with Openstack wiki works for me right now. I need to become more 
familiar the gerrit process and I agree with Samuel that it is not 
conducive to large design discussions. That being said I'd like to 
add my thoughts on how I think we can most effectively get stuff done.

As everyone knows there are many new players from across the industry 
that have an interest in Neutron LBaaS. Companies I currently see 
involved/interested are Mirantis, Blue Box Group, HP, PNNL, Citrix, 
eBay/Paypal and Rackspace. We also have individuals involved as well. I 
echo Kyle's sentiment on the passion everyone is bringing to the project!
Coming into this project a few months ago I saw that a few things 
needed to be done. Most notably, I realized that gathering everyone's 
expectations on what they wanted Neutron LBaaS to be was going to be 
crucial. Hence, I created the requirements document. Written 
requirements are important within a single organization. They are even 
more important when multiple organizations are working together because 
everyone is spread out across the world and every organization has a 
different development process. Again, my goal with the requirements 
document is to make sure that everyone's voice in the community is 
taken into consideration. The benefit I've seen from this document is 
that we ask Why? to each other, iterate on the document and in the 
end have a clear understanding of everyone's motives. We also learn 
from each other by doing this which is one of the great benefits of open 
source.

Now that we have a set of requirements the next question to ask is, 
How doe we prioritize requirements so that we can start designing and 
implementing them? If this project were a completely new piece of 
software I would argue that we iterate on individual features based on 
anecdotal information. In essence I would argue an agile approach.
However, most of the companies involved have been operating LBaaS for a 
while now. Rackspace, for example, has been operating LBaaS for the 
better part of 4 years. We have a clear understanding of what features 
our customers want and how to operate at scale. I believe other 
operators of LBaaS have the same understanding of their customers and 
their operational needs. I guess my main point is that, collectively, 
we have data to back up which requirements we should be working on. 
That doesn't mean we preclude requirements based on anecdotal 
information (i.e. Our customers are saying they want new shiny feature 
X). At the end of the day I want to prioritize the community's 
requirements based on factual data and anecdotal information.

Assuming requirements are prioritized (which as of today we have a 
pretty good idea of these priorities) the next step is to design before 
laying down any actual code. I agree with Samuel that pushing the cart 
before the horse is a bad idea in this case (and it usually is the case 
in software development), especially since we have a pretty clear idea 
on what we need to be designing for. I understand that the current code 
base has been worked on by many individuals and the work done thus far 
is the reason why so many new faces are getting involved. However, we 
now have a completely updated set of requirements that the community 
has put together and trying to fit the requirements to existing code 
may or may not work. In my experience, I would argue that 99% of the 
time duct-taping existing code to fit in new requirements results in 
buggy software. That being said, I usually 

Re: [openstack-dev] [Neutron][LBaaS] RackSpace API review (multi-call)

[Vijay Venkatachalam]

Thanks Trevor. Replies inline!

 -Original Message-
 From: Trevor Vardeman [mailto:trevor.varde...@rackspace.com]
 Sent: Thursday, May 1, 2014 7:30 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS] RackSpace API review (multi-
 call)
 
 Vijay,
 
 Comments in-line, hope I can clear some of this up for you :)
 
 -Trevor
 
 On Thu, 2014-05-01 at 13:16 +, Vijay Venkatachalam wrote:
  I am expecting to be more active on community on the LBaaS front.
 
  May be reviewing and picking-up a few items to  work as well.
 
  I had a look at the proposal. Seeing Single  Multi-Call approach for
  each workflow makes it easy to understand.
 
  Thanks for the clear documentation, it is welcoming to review :-). I was not
 allowed to comment on WorkFlow doc, can you enable comments?
 
  The single-call approach essentially creates the global pool/VIP. Once
 VIP/Pool is created using single call, are they reusable in multi-call?
  For example: Can a pool created for HTTP endpoint/loadbalancer be used
 in HTTPS endpoint LB where termination occurs as well?
 
 From what I remember discussing with my team (being a developer under
 Jorge's umbrella) There is a 1-M relationship between load balancer and
 pool.  Also, the protocol is specified on the Load Balancer, not the pool,
 meaning you could expose TCP traffic via one Load Balancer to a pool, and
 HTTP traffic via another Load Balancer to that same pool.
 This is easily modified such
 

Ok. Thanks! Should there be a separate use case for covering this (If it is not 
already present)?

 
  Also, would it be useful to include PUT as a single call? I see PUT only for
 POOL not for LB.
  A user who started with single-call  POST, might like to continue to use the
 same approach for PUT/update as well.
 
 On the fifth page of the document found here:
 https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZ
 DULjG9bTmWyXe-zo/edit
 There is a PUT detailed for a Load Balancer.  There should be support for PUT
 on any parent object assuming the fields one would update are not read-
 only.
 

My mistake, didn't explain properly.
I see PUT of loadbalancer containing only loadbalancer properties. 
I was wondering if it makes sense for PUT of LOADBALANCER to contain 
pool+members also. Similar to the POST payload.

Also, will delete of loadbalancer  DELETE the pool/vip, if they are no more 
referenced by another loadbalancer.

Or, they have to be cleaned up separately?

 
  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] SSL re-encryption scenario question

[Vijay Venkatachalam]

There is no reasoning mentioned in AWS, but they do allow re-encryption.

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-backend-auth.html

For reasons I don’t understand, the workflow allows to configure backend-server 
certificates to be trusted and it doesn’t accept client certificates or CA 
certificates.

Thanks,
Vijay V.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, April 18, 2014 11:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario 
question

Dang.  I was hoping this wasn't the case.  (I personally think it's a little 
silly not to trust your service provider to secure a network when they have 
root access to all the machines powering your cloud... but I digress.)

Part of the reason I was hoping this wasn't the case, isn't just because it 
consumes a lot more CPU on the load balancers, but because now we potentially 
have to manage client certificates and CA certificates (for authenticating from 
the proxy to back-end app servers). And we also have to decide whether we allow 
the proxy to use a different client cert / CA per pool, or per member.

Yes, I realize one could potentially use no client cert or CA (ie. encryption 
but no auth)...  but that actually provides almost no extra security over the 
unencrypted case:  If you can sniff the traffic between proxy and back-end 
server, it's not much more of a stretch to assume you can figure out how to be 
a man-in-the-middle.

Do any of you have a use case where some back-end members require SSL 
authentication from the proxy and some don't? (Again, deciding whether client 
cert / CA usage should attach to a pool or to a member.)

It's a bit of a rabbit hole, eh.

Stephen


On Fri, Apr 18, 2014 at 10:21 AM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Hi Stephen,

The use case is that the Load Balancer needs to look at the HTTP requests be it 
to add an X-Forward field or change the timeout – but the network between the 
load balancer and the nodes is not completely private and the sensitive 
information needs to be again transmitted encrypted. This is admittedly an edge 
case but we had to implement a similar scheme for HP Cloud’s swift storage.

German

From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net]
Sent: Friday, April 18, 2014 8:22 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

Howdy, folks!

Could someone explain to me the SSL usage scenario where it makes sense to 
re-encrypt traffic traffic destined for members of a back-end pool?  SSL 
termination on the load balancer makes sense to me, but I'm having trouble 
understanding why one would be concerned about then re-encrypting the traffic 
headed toward a back-end app server. (Why not just use straight TCP load 
balancing in this case, and save the CPU cycles on the load balancer?)

We terminate a lot of SSL connections on our load balancers, but have yet to 
have a customer use this kind of functionality.  (We've had a few ask about it, 
usually because they didn't understand what a load balancer is supposed to do-- 
and with a bit of explanation they went either with SSL termination on the load 
balancer + clear text on the back-end, or just straight TCP load balancing.)

Thanks,
Stephen


--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807tel:%28800%29613-4305%20x807

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

[Vijay Venkatachalam]

The document has Vendor  column, it should be from Cloud 
Operator?

Thanks,
Vijay V.


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Thursday, April 3, 2014 11:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data 
from Operators needed.

Stephen,

Agree with you. Basically the page starts looking as requirements page.
I think we need to move to google spreadsheet, where table is organized easily.
Here's the doc that may do a better job for us:
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing

Thanks,
Eugene.

On Thu, Apr 3, 2014 at 5:34 AM, Prashanth Hari 
hvpr...@gmail.commailto:hvpr...@gmail.com wrote:
More additions to the use cases 
(https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases).
I have updated some of the features we are interested in.



Thanks,
Prashanth


On Wed, Apr 2, 2014 at 8:12 PM, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:
Hi y'all--

Looking at the data in the page already, it looks more like a feature wishlist 
than actual usage data. I thought we agreed to provide data based on percentage 
usage of a given feature, the end result of the data collection being that it 
would become more obvious which features are the most relevant to the most 
users, and therefore are more worthwhile targets for software development.

Specifically, I was expecting to see something like the following (using 
hypothetical numbers of course, and where technical people from Company A  
etc. fill out the data for their organization):

== L7 features ==

Company A (Cloud operator serving external customers): 56% of load-balancer 
instances use
Company B (Cloud operator serving external customers): 92% of load-balancer 
instances use
Company C (Fortune 100 company serving internal customers): 0% of 
load-balancer instances use

== SSL termination ==

Company A (Cloud operator serving external customers): 95% of load-balancer 
instances use
Company B (Cloud operator serving external customers): 20% of load-balancer 
instances use
Company C (Fortune 100 company serving internal customers): 50% of 
load-balancer instances use.

== Racing stripes ==

Company A (Cloud operator serving external customers): 100% of load-balancer 
instances use
Company B (Cloud operator serving external customers): 100% of load-balancer 
instances use
Company C (Fortune 100 company serving internal customers): 100% of 
load-balancer instances use


In my mind, a wish-list of features is only going to be relevant to this 
discussion if (after we agree on what the items under consideration ought to 
be) each technical representative presents a prioritized list for their 
organization. :/ A wish-list is great for brain-storming what ought to be 
added, but is less relevant for prioritization.

In light of last week's meeting, it seems useful to list the features most 
recently discussed in that meeting and on the mailing list as being points on 
which we want to gather actual usage data (ie. from what people are actually 
using on the load balancers in their organization right now). Should we start a 
new page that lists actual usage percentages, or just re-vamp the one above?  
(After all, wish-list can be useful for discovering things we're missing, 
especially if we get people new to the discussion to add their $0.02.)

Thanks,
Stephen



On Wed, Apr 2, 2014 at 3:46 PM, Jorge Miramontes 
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote:
Thanks Eugene,

I added our data onto the requirements page since I was hoping to prioritize 
requirements based on the operator data that gets provided. We can move it over 
to the other page if you think that makes sense. See everyone on the weekly 
meeting tomorrow!

Cheers,
--Jorge

From: Susanne Balle sleipnir...@gmail.commailto:sleipnir...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 1, 2014 4:09 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data 
from Operators needed.

I added two more. I am still working on our HA use cases. Susanne

On Tue, Apr 1, 2014 at 4:16 PM, Fox, Kevin M 
kevin@pnnl.govmailto:kevin@pnnl.gov wrote:
I added our priorities. I hope its formatted well enough. I just took a stab in 
the dark.

Thanks,
Kevin

From: Eugene Nikanorov [enikano...@mirantis.commailto:enikano...@mirantis.com]
Sent: Tuesday, April 01, 2014 3:02 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from 
Operators needed.
Hi folks,

On the last meeting we decided to 

Re: [openstack-dev] [Neutron LBaaS] Need help with LBaaS drivers

[Vijay Venkatachalam]

Answered Inline!

From: Vijay B [mailto:os.v...@gmail.com]
Sent: Wednesday, April 2, 2014 7:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron LBaaS] Need help with LBaaS drivers


Hi,



I'm trying to understand how LBaaS drivers work and so am attempting to write a 
dummy driver that does nothing for now, but instead of loading my dummy driver, 
neutron always loads the HAProxy namespace driver. These are the steps I 
followed:



1) I created a new directory neutron/services/loadbalancer/drivers/dummy/, and 
in that directory I put in a new file dummy_driver.py, which basically has a 
class class DummyPluginDriver(abstract_driver.   ):

and has empty __init__(), create_vip(), delete_vip() etc functions.



 Fine



2) I'm testing using a devstack setup, so I also edited the 
/etc/neutron/neutron.conf file, commenting out the default loadbalancer driver 
entry for HAProxy, and added a line for my dummy driver as follows:



service_provider=LOADBALANCER:Dummy:neutron.services.loadbalancer.drivers.dummy.dummy_driver.DummyPluginDriver:default

 Fine. You should see you driver getting loaded when the neutron service is 
 started.



3) I created a /etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini 
directory/file

I simply copied over the haproxy's lbaas_agent.ini file and changed [haproxy] 
to [dummy]

and then I restarted the q-lbaas service using cd /opt/stack/neutron  python 
/usr/local/bin/neutron-lbaas-agent --config-file /etc/neutron/neutron.conf 
--config-file=/etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini



  You have to do this only if you are planning on an Agent for your driver.



 If you plan to run an agent, create a device_driver entry in the .ini file.



 Like 
 device_driver=neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver



However, I see that the default HAProxyNS driver is still being loaded

When I put a breakpoint in loadbalancer/agent/agent_manager.py:86, I see this 
(relevant text marked in red):





2014-03-31 13:47:16.998 DEBUG neutron.common.utils [-] Reloading cached file 
/etc/neutron/policy.json from (pid=28405) read_cached_file 
/opt/stack/neutron/neutron/common/utils.py:53

2014-03-31 13:47:16.998 DEBUG neutron.policy [-] Loading policies from file: 
/etc/neutron/policy.json from (pid=28405) _set_rules 
/opt/stack/neutron/neutron/policy.py:89

 /opt/stack/neutron/neutron/services/loadbalancer/agent/agent_manager.py(86)_load_drivers()

- self.device_drivers = {}

(Pdb) l

 81 # pool_id-device_driver_name mapping used to store known 
instances

 82 self.instance_mapping = {}

 83

 84 def _load_drivers(self):

 85 import pdb; pdb.set_trace()

 86  - self.device_drivers = {}

 87 for driver in self.conf.device_driver:

 88 try:

 89 driver_inst = importutils.import_object(

 90 driver,

 91 self.conf,

(Pdb) self.conf.device_driver

['neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver']

(Pdb)


 HaproxyNSDriver is default entry. You could check in 
 ./neutron/neutron/services/loadbalancer/agent/agent_manager.py



I'm not sure what I'm doing wrong - am I missing something that needs to be 
done within the dummy driver itself? (in dummy_driver.py?). Should I register 
some opts or similar?



Any help would be much appreciated!





Thanks,

Regards,

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

Re: [openstack-dev] [Neutron][LBaaS] Weekly meeting Thursday 09.01.2014

[Vijay Venkatachalam]

Can you include the following in the agenda?

1.   External/3rd Party testing

2.   Common code for collecting status/statistics


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, January 08, 2014 7:58 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][LBaaS] Weekly meeting Thursday 09.01.2014

Hi neutrons,

Lets continue keeping our regular lbaas meetings. Let's gather on 
#openstack-meeting at 14-00 UTC on this Thursday, 09.01.2014.

We'll discuss our progress and future plans.

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] Member status update mangled with pool stats API

[Vijay Venkatachalam]

Hi Eugene et al,

As of today, during a stats API query, a pool member's status 
is gathered along with the pool stats and stored in the db.  Subsequent GETs to 
the members will have the correct member status. In this approach, only when a 
North Bound API call for stats  is performed the member's status would get 
refreshed. This is not desirable and the status should be up-to-date any point 
of time.

My suggestion: We can introduce a new API as part of the driver interface like 
get_poolmember_statuses(poolid). The LBaaS plugin will call this on a periodic 
basis to collect member statuses and stores it in the db.

HAProxy has taken a back door route to keep the status 
up-to-date. Here the HAProxy agent starts a periodic task that collects all 
pool stats + member status and updates the collected data in the db through 
a plugin driver callback.

This approach is not suitable for agent less models.

One could argue that a periodic task could be started by the plugin driver 
instead of the agent, to collect the member statuses. But since this is a 
requirement from many drivers, it is better to be implemented as part of the 
LBaaS plugin.

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] Vote required for certificate as first-class citizen - SSL Termination (Revised)

[Vijay Venkatachalam]

Replies Inline!



 -Original Message-
 From: Evgeny Fedoruk [mailto:evge...@radware.com]
 Sent: Thursday, December 12, 2013 5:56 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate
 as first-class citizen - SSL Termination (Revised)
 
 Thanks for your review Vijay
 
 1. Pass-Info is for the backend. Used for informing the Back-End regarding
 SSL termination details.

Will SSL Termination details be passed through HTTP headers? If so, what will 
be the http header names? 
Also ssl_policy.pass_info  is a string, how does it work?

Do you see a strong use case? Otherwise this can be skipped for phase-1.

 2. Added cipher-suites groups
 3. Added default policy
 4. Added SNI support. I think our model should support it, since EC2 supports
 it.
 5. Renamed Trusted Key to Trusted Certificate. I thought CA is obvious,
 Back-End Certificate is an option too, What do you think?


Trusted Certificate seems fine. 

ssl_trusted_key (new) datamodel and its properties are still not changed. You 
might want to rename ssl_trusted_key* = ssl_trusted_certificate*
ssl_trusted_key_id  also can be renamed

 6. Renamed Certificate's public key to certificate.
 
There are still keys used in place of certificate

public_key : PEM-formatted string

 Regards,
 Evg
 
 -Original Message-
 From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
 Sent: Wednesday, December 11, 2013 2:05 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Abhishek Gautam
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate
 as first-class citizen - SSL Termination (Revised)
 
 Thanks for the detailed write-up Evg.
 
 What is the use of SSLPolicy.PassInfo?
 Managing as individual ciphers is a pain, Can we introduce an entity called
 cipher groups? This enables to provide built-in cipher groups (HIGH, LOW,
 DES etc) as well. At the least we can provide this in the UI+CLI layer.
 Also, it will be good to have a built-in DEFAULT ssl policy, which contains
 default set of SSL protocols, ciphers etc. which is to be used when sslpolicy 
 is
 not provided.
 Is there a need for binding multiple certificates for a VIP, because SNI is 
 not
 modeled now? We could have vip_id as the key in vip_ssl_certificate_assoc.
 
 Also, it will be good to have the following nomenclature corrected:
 TrustedKey: This entity refers to a CA certificate, usage key can be avoided.
 My suggestion is to call it CA or cacert.
 SSLCertificate.PublicKey: The property contains a server certificate (actually
 PublicKey + more info). My suggestion is to call the property as certificate
 
 Thanks,
 Vijay V.
 
 
  -Original Message-
  From: Evgeny Fedoruk [mailto:evge...@radware.com]
  Sent: Sunday, December 08, 2013 10:24 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for
  certificate as first-class citizen - SSL Termination (Revised)
 
  Hi All.
  The wiki page for LBaaS SSL support was updated.
  Please see and comment
  https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Vip_SSL_Association
 
  Thank you!
  Evg
 
  -Original Message-
  From: Samuel Bercovici
  Sent: Thursday, December 05, 2013 9:14 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Cc: Evgeny Fedoruk; Samuel Bercovici
  Subject: RE: [openstack-dev] [Neutron][LBaaS] Vote required for
  certificate as first-class citizen - SSL Termination (Revised)
 
  Correct.
 
  Evgeny will update the WIKI accordingly.
  We will add a flag in the SSL Certificate to allow specifying that the
  private key can't be persisted. And in this case, the private key
  could be passed when associating the cert_id with the VIP.
 
  Regards,
  -Sam.
 
  -Original Message-
  From: Nachi Ueno [mailto:na...@ntti3.com]
  Sent: Thursday, December 05, 2013 8:21 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for
  certificate as first-class citizen - SSL Termination (Revised)
 
  Hi folks
 
  OK, It looks like we get consensus on
  separate resource way.
 
  Best
  Nachi
 
  2013/12/5 Eugene Nikanorov enikano...@mirantis.com:
   Hi,
  
   My vote is for separate resource (e.g. 'New Model'). Also I'd like
   to see certificate handling as a separate extension/db mixing(in
   fact, persistence
   driver) similar to service_type extension.
  
   Thanks,
   Eugene.
  
  
   On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran
   stephen.g...@theguardian.com
   wrote:
  
   Hi,
  
   Right, sorry, I see that wasn't clear - I blame lack of coffee :)
  
   I would prefer the Revised New Model.  I much prefer the ability
   to restore a loadbalancer from config in the event of node failure,
   and the ability to do basic sharing of certificates between VIPs.
  
   I think that a longer

Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)

[Vijay Venkatachalam]

Thanks for the detailed write-up Evg. 

What is the use of SSLPolicy.PassInfo?
Managing as individual ciphers is a pain, Can we introduce an entity called 
cipher groups? This enables to provide built-in cipher groups (HIGH, LOW, DES 
etc) as well. At the least we can provide this in the UI+CLI layer.
Also, it will be good to have a built-in DEFAULT ssl policy, which contains 
default set of SSL protocols, ciphers etc. which is to be used when sslpolicy 
is not provided.
Is there a need for binding multiple certificates for a VIP, because SNI is not 
modeled now? We could have vip_id as the key in vip_ssl_certificate_assoc.

Also, it will be good to have the following nomenclature corrected:
TrustedKey: This entity refers to a CA certificate, usage key can be avoided. 
My suggestion is to call it CA or cacert.
SSLCertificate.PublicKey: The property contains a server certificate (actually 
PublicKey + more info). My suggestion is to call the property as certificate

Thanks,
Vijay V.


 -Original Message-
 From: Evgeny Fedoruk [mailto:evge...@radware.com]
 Sent: Sunday, December 08, 2013 10:24 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate
 as first-class citizen - SSL Termination (Revised)
 
 Hi All.
 The wiki page for LBaaS SSL support was updated.
 Please see and comment
 https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Vip_SSL_Association
 
 Thank you!
 Evg
 
 -Original Message-
 From: Samuel Bercovici
 Sent: Thursday, December 05, 2013 9:14 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Evgeny Fedoruk; Samuel Bercovici
 Subject: RE: [openstack-dev] [Neutron][LBaaS] Vote required for certificate
 as first-class citizen - SSL Termination (Revised)
 
 Correct.
 
 Evgeny will update the WIKI accordingly.
 We will add a flag in the SSL Certificate to allow specifying that the 
 private key
 can't be persisted. And in this case, the private key could be passed when
 associating the cert_id with the VIP.
 
 Regards,
   -Sam.
 
 -Original Message-
 From: Nachi Ueno [mailto:na...@ntti3.com]
 Sent: Thursday, December 05, 2013 8:21 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate
 as first-class citizen - SSL Termination (Revised)
 
 Hi folks
 
 OK, It looks like we get consensus on
 separate resource way.
 
 Best
 Nachi
 
 2013/12/5 Eugene Nikanorov enikano...@mirantis.com:
  Hi,
 
  My vote is for separate resource (e.g. 'New Model'). Also I'd like to
  see certificate handling as a separate extension/db mixing(in fact,
  persistence
  driver) similar to service_type extension.
 
  Thanks,
  Eugene.
 
 
  On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran
  stephen.g...@theguardian.com
  wrote:
 
  Hi,
 
  Right, sorry, I see that wasn't clear - I blame lack of coffee :)
 
  I would prefer the Revised New Model.  I much prefer the ability to
  restore a loadbalancer from config in the event of node failure, and
  the ability to do basic sharing of certificates between VIPs.
 
  I think that a longer term plan may involve putting the certificates
  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, Samuel Bercovici wrote:
 
  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-dev] [Neutron][LBaaS] Vote required for
  certificate as first-class citizen - SSL Termination (Revised)
 
  Hi,
 
  I would be happy with this model.  Yes, longer term it might be nice
  to have an independent certificate store so that when you need to be
  able to validate ssl you can, but this is a good intermediate step.
 
  Cheers,
 
  On 02/12/13 09:16, Vijay Venkatachalam wrote:
 
 
  LBaaS enthusiasts: Your vote on the revised model for SSL Termination?
 
  Here is a comparison between the original and revised model for SSL
  Termination:
 
  ***
  Original Basic Model that was proposed in summit
  ***
  * Certificate parameters introduced as part of VIP resource.
  * This model is for basic config and there will be a model
  introduced in future for detailed use case.
  * Each certificate is created for one and only one VIP.
  * Certificate params not stored in DB and sent directly to loadbalancer.
  * In case of failures, there is no way to restart the operation
  from details stored in DB.
  ***
  Revised New Model
  ***
  * Certificate parameters will be part of an independent certificate
  resource

Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)

[Vijay Venkatachalam]

LBaaS enthusiasts: Your vote on the revised model for SSL Termination?

Here is a comparison between the original and revised model for SSL Termination:

***
Original Basic Model that was proposed in summit
***
* Certificate parameters introduced as part of VIP resource.
* This model is for basic config and there will be a model introduced in future 
for detailed use case.
* Each certificate is created for one and only one VIP.
* Certificate params not stored in DB and sent directly to loadbalancer. 
* In case of failures, there is no way to restart the operation from details 
stored in DB.
***
Revised New Model
***
* Certificate parameters will be part of an independent certificate resource. A 
first-class citizen handled by LBaaS plugin.
* It is a forwarding looking model and aligns with AWS for uploading server 
certificates.
* A certificate can be reused in many VIPs.
* Certificate params stored in DB. 
* In case of failures, parameters stored in DB will be used to restore the 
system.

A more detailed comparison can be viewed in the following link
 
https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVeZISh07iGs/edit?usp=sharing

Thanks,
Vijay V.


 -Original Message-
 From: Vijay Venkatachalam
 Sent: Friday, November 29, 2013 2:18 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as
 first level citizen - SSL Termination
 
 
 To summarize:
 Certificate will be a first level citizen which can be reused and For 
 certificate
 management nothing sophisticated is required.
 
 Can you please Vote (+1, -1)?
 
 We can move on if there is consensus around this.
 
  -Original Message-
  From: Stephen Gran [mailto:stephen.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-11-20 at 08:24 +, Samuel Bercovici wrote:
   Hi,
  
  
  
   Evgeny has outlined the wiki for the proposed change at:
   https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line
   with what was discussed during the summit.
  
   The
  
 
 https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n
  YTvMkMJ_inbo/edit discuss in addition Certificate Chains.
  
  
  
   What would be the benefit of having a certificate that must be
   connected to VIP vs. embedding it in the VIP?
 
  You could reuse the same certificate for multiple loadbalancer VIPs.
  This is a fairly common pattern - we have a dev wildcard cert that is
  self- signed, and is used for lots of VIPs.
 
   When we get a system that can store certificates (ex: Barbican), we
   will add support to it in the LBaaS model.
 
  It probably doesn't need anything that complicated, does it?
 
  Cheers,
  --
  Stephen Gran
  Senior Systems Integrator - The Guardian
 
  Please consider the environment before printing this email.
  --
  Visit theguardian.com
 
  On your mobile, download the Guardian iPhone app
  theguardian.com/iphone and our iPad edition theguardian.com/iPad Save
  up to 33% by subscribing to the Guardian and Observer - choose the
  papers you want and get full digital access.
  Visit subscribe.theguardian.com
 
  This e-mail and all attachments are confidential and may also be
  privileged. If you are not the named recipient, please notify the
  sender and delete the e- mail and all attachments immediately.
  Do not disclose the contents to another person. You may not use the
  information for any purpose, or store, or copy, it in any way.
 
  Guardian News  Media Limited is not liable for any computer viruses
  or other material transmitted with or as part of this e-mail. You
  should employ virus checking software.
 
  Guardian News  Media Limited
 
  A member of Guardian Media Group plc
  Registered Office
  PO Box 68164
  Kings Place
  90 York Way
  London
  N1P 2AP
 
  Registered in England Number 908396
 
  --
  
 
 
  ___
  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] Vote required for certificate as first level citizen - SSL Termination

[Vijay Venkatachalam]

To summarize:
Certificate will be a first level citizen which can be reused and 
For certificate management nothing sophisticated is required.

Can you please Vote (+1, -1)?

We can move on if there is consensus around this.

 -Original Message-
 From: Stephen Gran [mailto:stephen.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-11-20 at 08:24 +, Samuel Bercovici wrote:
  Hi,
 
 
 
  Evgeny has outlined the wiki for the proposed change at:
  https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line
  with what was discussed during the summit.
 
  The
 
 https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n
 YTvMkMJ_inbo/edit discuss in addition Certificate Chains.
 
 
 
  What would be the benefit of having a certificate that must be
  connected to VIP vs. embedding it in the VIP?
 
 You could reuse the same certificate for multiple loadbalancer VIPs.
 This is a fairly common pattern - we have a dev wildcard cert that is self-
 signed, and is used for lots of VIPs.
 
  When we get a system that can store certificates (ex: Barbican), we
  will add support to it in the LBaaS model.
 
 It probably doesn't need anything that complicated, does it?
 
 Cheers,
 --
 Stephen Gran
 Senior Systems Integrator - The Guardian
 
 Please consider the environment before printing this email.
 --
 Visit theguardian.com
 
 On your mobile, download the Guardian iPhone app
 theguardian.com/iphone and our iPad edition theguardian.com/iPad
 Save up to 33% by subscribing to the Guardian and Observer - choose the
 papers you want and get full digital access.
 Visit subscribe.theguardian.com
 
 This e-mail and all attachments are confidential and may also be privileged. 
 If
 you are not the named recipient, please notify the sender and delete the e-
 mail and all attachments immediately.
 Do not disclose the contents to another person. You may not use the
 information for any purpose, or store, or copy, it in any way.
 
 Guardian News  Media Limited is not liable for any computer viruses or
 other material transmitted with or as part of this e-mail. You should employ
 virus checking software.
 
 Guardian News  Media Limited
 
 A member of Guardian Media Group plc
 Registered Office
 PO Box 68164
 Kings Place
 90 York Way
 London
 N1P 2AP
 
 Registered in England Number 908396
 
 --
 
 
 ___
 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] [Nova] Are BIOS strings configured in Hyper-V ESX similar to KVM instantiated VMs?

[Vijay Venkatachalam]

It is basically used to tailor the boot sequence if the VM gets booted in 
OpenStack. For ex. it could do the following


1.   Get IP through DHCP if booted in OpenStack

2.   Read config drive or contact metadata service and init the system if 
booted in OpenStack


Thanks,
Vijay V.

From: Bob Ball [mailto:bob.b...@citrix.com]
Sent: Tuesday, November 26, 2013 7:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V  
ESX similar to KVM instantiated VMs?

It's not certain that this will be implemented for the XenAPI driver.

Our view is that the BIOS strings shouldn't be relied upon - the hypervisor can 
clearly set them to anything so it's not really a reliable way to configure the 
application.  Also note that in some scenarios, such as PV guests in Xen 
clouds, you will not have any BIOS to query.  Finally we're not clear on the 
use case here - What's the use case for needing to know whether you VM is 
running under OpenStack or not?

Bob

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 26 November 2013 01:44
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V  ESX 
similar to KVM instantiated VMs?

Hi,

In a KVM instantiated VM the following signature is present in the BIOS of the 
VM
The 'Manufacturer ' field in 'System Information' group is set to OpenStack 
Foundation



This helps the VM to identify that it is getting used in an OpenStack 
environment.



As far as I know XenServer is planning to set the BIOS Strings in IceHouse 
release.



Is this functionality available in other Hypervisors, especially Hyper-V  ESX?



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] L7 Switching

[Vijay Venkatachalam]

Hi,

The CLI example is capturing the requirement concisely. Thanks. 
One suggestion, you could bring the --policy policy1 to the beginning of 
create-lb-l7rule command.

Also, could rename associate-lb-pool-vip to associate-lb-vip-pool

It will be best to define the db model to reflect the cli.

For ex.:
   class L7Rule {
 .
  String SelectedPool # This should have been String L7Policy
   }

 neutron associate-lb-pool-vip --pool pool1 --vip vip1 --l7policy policy1
There should be a new collection/table to reflect the association of vip, pool, 
policy

Thanks,
Vijay V.


 -Original Message-
 From: Avishay Balderman [mailto:avish...@radware.com]
 Sent: Wednesday, November 20, 2013 9:06 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Neutron][LBaaS] L7 Switching
 
 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

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

Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

[Vijay Venkatachalam]

Hi,

Replies Inline!

 -Original Message-
 From: Stephen Gran [mailto:stephen.g...@guardian.co.uk]
 Sent: Wednesday, November 20, 2013 2:59 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
 
 Hi,
 
 Yes, definitely yes.
 
 It's just a bootstrap problem - you can't both have a reliable, resilient
 loadbalancer that can be respawned, and not store all the data necessary to
 respawn it.
 

Not necessarily. Devices can be in HA or clustering mode. Any configuration 
that is 
sent to one device will be synced with other paired devices securely and would 
also
failover at the right time.

 I agree there are privacy concerns, just as there are with any hoster.
 But if you don't trust your hoster with your SSL certs, you probably shouldn't
 host any content that matters with them.
 

I am no way expert in this area, but I think it is not a question of trust but 
it is a fear that 
a security loophole in the controller could be exploited to read the 
certificates. 

I don't know of any concerns though.

 Cheers,
 
 On Wed, 2013-11-20 at 08:43 +, Samuel Bercovici wrote:
  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.
 
 
  -Original Message-
  From: Stephen Gran [mailto:stephen.g...@theguardian.com]
  Sent: Wednesday, November 20, 2013 10:15 AM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
 
  On 19/11/13 16:33, Clint Byrum wrote:
   Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -
 0800:
   Hi Sam, Eugene,  Avishay, etal,
  
Today I spent some time to create a write-up for SSL
 Termination not exactly design doc. Please share your comments!
  
  
 https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n
   YT
   vMkMJ_inbo/edit
  
   Would like comments/discussion especially on the following note:
  
   SSL Termination requires certificate management. The ideal way is to
 handle this via an independent IAM service. This would take time to
 implement so the thought was to add the certificate details in VIP resource
 and send them directly to device. Basically don't store the certificate key in
 the DB there by avoiding security concerns of maintaining certificates in
 controller.
 
  I don't see why it does.  Nothing in openstack needs to trust user-uploaded
 certs.  Just storing them as independent certificate objects that can be
 referenced by N VIPs makes sense to me.
 
  If the backend is SSL, I would think you could do one of:
  a) upload client certs
  b) upload CA that has signed backend certs
  c) opt to disable cert checking for backends
 
  With the default being c).
 
  Cheers,
  --
  Stephen Gran
  Senior Systems Integrator - theguardian.com Please consider the
 environment before printing this email.
  --
  Visit theguardian.com
 
  On your mobile, download the Guardian iPhone app
 theguardian.com/iphone and our iPad edition theguardian.com/iPad
  Save up to 33% by subscribing to the Guardian and Observer - choose the
 papers you want and get full digital access.
  Visit subscribe.theguardian.com
 
  This e-mail and all attachments are confidential and may also be privileged.
 If you are not the named recipient, please notify the sender and delete the
 e-mail and all attachments immediately.
  Do not disclose the contents to another person. You may not use the
 information for any purpose, or store, or copy, it in any way.
 
  Guardian News  Media Limited is not liable for any computer viruses or
 other material transmitted with or as part of this e-mail. You should employ
 virus checking software.
 
  Guardian News  Media Limited
 
  A member of Guardian Media Group plc
  Registered Office
  PO Box 68164
  Kings Place
  90 York Way
  London
  N1P 2AP
 
  Registered in England Number 908396
 
  --
  
 
 
  ___
  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
 
 --
 Stephen Gran
 Senior Systems Integrator - The Guardian
 
 Please consider the environment before printing this email.
 --
 Visit theguardian.com
 
 On your mobile, download the Guardian iPhone app
 theguardian.com/iphone and our iPad edition 

Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

[Vijay Venkatachalam]

 -Original Message-
 From: Stephen Gran [mailto:stephen.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-11-20 at 08:24 +, Samuel Bercovici wrote:
  Hi,
 
 
 
  Evgeny has outlined the wiki for the proposed change at:
  https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line
  with what was discussed during the summit.
 
  The
 
 https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n
 YTvMkMJ_inbo/edit discuss in addition Certificate Chains.
 
 
 
  What would be the benefit of having a certificate that must be
  connected to VIP vs. embedding it in the VIP?
 
 You could reuse the same certificate for multiple loadbalancer VIPs.
 This is a fairly common pattern - we have a dev wildcard cert that is self-
 signed, and is used for lots of VIPs.
 
If certificates can be totally independent and can be reused, it will be 
awesome.
But even otherwise, certificate connected to VIP is just better modeling and 
provides an easier migration path towards an independent certificate resource.

  When we get a system that can store certificates (ex: Barbican), we
  will add support to it in the LBaaS model.
 
 It probably doesn't need anything that complicated, does it?
 
 Cheers,
 --
 Stephen Gran
 Senior Systems Integrator - The Guardian
 
 Please consider the environment before printing this email.
 --
 Visit theguardian.com
 
 On your mobile, download the Guardian iPhone app
 theguardian.com/iphone and our iPad edition theguardian.com/iPad
 Save up to 33% by subscribing to the Guardian and Observer - choose the
 papers you want and get full digital access.
 Visit subscribe.theguardian.com
 
 This e-mail and all attachments are confidential and may also be privileged. 
 If
 you are not the named recipient, please notify the sender and delete the e-
 mail and all attachments immediately.
 Do not disclose the contents to another person. You may not use the
 information for any purpose, or store, or copy, it in any way.
 
 Guardian News  Media Limited is not liable for any computer viruses or
 other material transmitted with or as part of this e-mail. You should employ
 virus checking software.
 
 Guardian News  Media Limited
 
 A member of Guardian Media Group plc
 Registered Office
 PO Box 68164
 Kings Place
 90 York Way
 London
 N1P 2AP
 
 Registered in England Number 908396
 
 --
 
 
 ___
 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] SSL Termination write-up

[Vijay Venkatachalam]

Yes. The following can be added

1. Certificate Chain as you already observed
2. Backend certificates for trust, basically CA certs.
  These certificates will be used by loadbalancer to validate the 
certificate presented by the backend services.

Thanks,
Vijay V.


 -Original Message-
 From: Samuel Bercovici [mailto:samu...@radware.com]
 Sent: Wednesday, November 20, 2013 5:40 PM
 To: OpenStack Development Mailing List (not for usage questions);
 stephen.g...@guardian.co.uk; Vijay Venkatachalam
 Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
 
 HI,
 
 Besides a forward looking model do you see other differences?
 
 -Sam.
 
 -Original Message-
 From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
 Sent: Wednesday, November 20, 2013 1:22 PM
 To: stephen.g...@guardian.co.uk; OpenStack Development Mailing List (not
 for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
 
 
 
  -Original Message-
  From: Stephen Gran [mailto:stephen.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-11-20 at 08:24 +, Samuel Bercovici wrote:
   Hi,
  
  
  
   Evgeny has outlined the wiki for the proposed change at:
   https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line
   with what was discussed during the summit.
  
   The
  
 
 https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n
  YTvMkMJ_inbo/edit discuss in addition Certificate Chains.
  
  
  
   What would be the benefit of having a certificate that must be
   connected to VIP vs. embedding it in the VIP?
 
  You could reuse the same certificate for multiple loadbalancer VIPs.
  This is a fairly common pattern - we have a dev wildcard cert that is
  self- signed, and is used for lots of VIPs.
 
 If certificates can be totally independent and can be reused, it will be
 awesome.
 But even otherwise, certificate connected to VIP is just better modeling and
 provides an easier migration path towards an independent certificate
 resource.
 
   When we get a system that can store certificates (ex: Barbican), we
   will add support to it in the LBaaS model.
 
  It probably doesn't need anything that complicated, does it?
 
  Cheers,
  --
  Stephen Gran
  Senior Systems Integrator - The Guardian
 
  Please consider the environment before printing this email.
  --
  Visit theguardian.com
 
  On your mobile, download the Guardian iPhone app
  theguardian.com/iphone and our iPad edition theguardian.com/iPad Save
  up to 33% by subscribing to the Guardian and Observer - choose the
  papers you want and get full digital access.
  Visit subscribe.theguardian.com
 
  This e-mail and all attachments are confidential and may also be
  privileged. If you are not the named recipient, please notify the
  sender and delete the e- mail and all attachments immediately.
  Do not disclose the contents to another person. You may not use the
  information for any purpose, or store, or copy, it in any way.
 
  Guardian News  Media Limited is not liable for any computer viruses
  or other material transmitted with or as part of this e-mail. You
  should employ virus checking software.
 
  Guardian News  Media Limited
 
  A member of Guardian Media Group plc
  Registered Office
  PO Box 68164
  Kings Place
  90 York Way
  London
  N1P 2AP
 
  Registered in England Number 908396
 
  --
  
 
 
  ___
  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] [Neutron][LBaaS] SSL Termination write-up

[Vijay Venkatachalam]

Hi Sam, Eugene,  Avishay, etal,

Today I spent some time to create a write-up for SSL 
Termination not exactly design doc. Please share your comments!

https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit

Would like comments/discussion especially on the following note:

SSL Termination requires certificate management. The ideal way is to handle 
this via an independent IAM service. This would take time to implement so the 
thought was to add the certificate details in VIP resource and send them 
directly to device. Basically don't store the certificate key in the DB there 
by avoiding security concerns of maintaining certificates in controller.

I would expect the certificates to become an independent resource in future 
thereby causing backward compatibility issues.

Any ideas how to achieve this?

My thought was to have independent certificate resource with VIP uuid as one of 
the properties. VIP is already created and will help to identify the 
driver/device. The VIP property can be depreciated in the long term.
Thanks,
Vijay V.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Is python setup.py intsall recommended way to install Neutron Server in dev environment?

[Vijay Venkatachalam]

Hi,
I am new to openstack, please pardon if the questions are dumb.

Attempting to run a neutron dev setup with openvswitch plugin with VLAN 
isolation and 2 hosts.

DISCLAIMER: I am not using devstack. Attempting to install the services in a 
controller node  - Ubuntu12.04 VM.


1.   In the controller node

a)  Services horizon/keystone/glance are installed using apt-get. Yet to 
install nova.

b)  Also in addition, for development needs, we have cloned neutron from 
github

c)   ran python setup.py install
# Is this the recommended way? This seems to have installed all agents  
/usr/local/bin/neutron-*-agents as well in  Controller Node.
Thanks,
Vijay V.




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