Re: [openstack-dev] [Openstack] How can we use Orchestration service efficiently

[Vijay Baskar]

A stack template defines a set of resources like VMs, networks, router..
and the relationship between them. You can create an entire cloud
 infrastructure using a template. When creating a stack these resources
will be created so that you dont need to create them individually. Suspend
means , the instances mentioned in the template will be suspended.
Similarly instances will be paused and resumed when stack is paused and
resumed respectively. Change stack template is for changing the
infrastructure created with the template, like upgrading the instances
flavour used in it.

I do not understand your second question about re running the stack.

Are you trying to create stacks using python API?

On May 14, 2017 6:02 PM, "Amit Uniyal"  wrote:

> `Hi all,
>
> I guess I understood how heat create works. and also the meaning of
> options [ suspend, resume, check stack, change stack template ].
>
> So now whole stack is a single object.
>
> I am trying to use os_client_config to create heat stack as:
>
> *heat = os_client_config.make_client('orchestration')*
>
> now heat object has a function create_stack(**kwargs)
>
>
> I tried to use it as:
>
> template = {
>
> 'description': 'network and instances',
>  'heat_template_version': '2015-10-15',
>  'resources': {'net-a': {'properties': {'name': 'network-a'},
>'type': 'OS::Neutron::Net'}}
>
> }
>
>
> *stack = heat.stacks.create(**template)*
>
> it throws error as  ERROR: No stack name specified
>
> so I added new key as *template.update({'stack_name': 'stack-a'})*
>
> and this time I got error as ERROR: No template specified
>
>
> what would be the proper procedure to launch stack by os_client_config.
>
>
>
>
> Regards
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, May 4, 2017 at 5:53 PM, Amit Uniyal  wrote:
>
>> Hi all,
>>
>> Please help with heat service, the only example I could find is to create
>> new stack. But how to use existing stack template which is already stored
>> by orchestration service.
>>
>> My understanding is we need to form/write a .yaml template and create new
>> stack by this template. It saves this template on orchestration and run the
>> template. According to template VMs will get launch (or other tasks) and it
>> should be finished. then whats the meaning of options [ suspend, resume,
>> check stack, change stack template ].
>>
>> How can we rerun the same template without form/creating new stack in
>> openstack.
>>
>>
>> Thanks and Regards
>>
>>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
__
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]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 migrat

[openstack-dev] openstack token issue CLI, error- openstack liberty

[vijay srinivasan]

hi
  i am in process of learning and applying openstack. i am
installing devstack ( in single machine mode) in my centos7 laptop.

   while running stack.sh command , install halts at this line.
2016-03-07 09:54:58.053 | ++

/home/vijay/devstack/lib/keystone:bootstrap_keystone:L651:   *openstack
token issue -c id -f value --os-username X --os-project-name 
--os-user-domain-id default --os-project-domain-id default
--os-identity-api-version 3 --os-auth-url http://192.168.1.11:35357
<http://192.168.1.11:35357> --os-password X*

*2016-03-07 09:55:02.219 | __init__() got an unexpected keyword argument
'token'*

i run the openstack token issue as CLI and get above error.

could someone tell me where i am making error. it really is blocking for me
now.

i try to login via horizon dashboard and credentials error comes up.

does this have to do with keystone service not coming up correctly?

thanks for patient hearing.

Vijay Srinivasan


https://in.linkedin.com/in/vijays1
__
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) 

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

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

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) 

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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 18, 2015 at 2:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
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) 
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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possi

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) 

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) 
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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
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) 
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]

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] [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) 

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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
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) 
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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
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>)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [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) 

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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
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) 
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]

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) 

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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
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>)" 
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) 

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

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

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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
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>)" 
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.com<mailto:kunalhgan...@gmail.com>; 
v.jain...@gmail.com<mailto:v.jain...@gmail.com>; 
do...@a10networks.com<mailto: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.ie<mailto: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" 
mailto: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 here<https://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.org<mailto: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 
mailto: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 Bercovici<mailto: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 
Fedoruk<mailto:evge...@radware.com>, Adam 
Harwell<mailto:adam.harw...@rackspace.com>, Kyle 
Mestery<mailto:mest...@mestery.com>, Brandon 
Logan<mailto:brandon.lo...@rackspace.com>, Johnson, Michael (HP Cloud - 
Corvallis)<mailto:michael.d.john...@hp.com>, Doug 
Wiegley<mailto:do...@a10networks.com>, Samuel 
Bercovici<mailto: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<mailto: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 
mailto: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 Bercovici<mailto: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 
Fedoruk<mailto:evge...@radware.com>, Adam 
Harwell<mailto:adam.harw...@rackspace.com>, Kyle 
Mestery<mailto:mest...@mestery.com>, Brandon 
Logan<mailto:brandon.lo...@rackspace.com>, Johnson, Michael (HP Cloud - 
Corvallis)<mailto:michael.d.john...@hp.com>, Doug 
Wiegley<mailto:do...@a10networks.com>, Samuel 
Bercovici<mailto: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<mailto: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 Bercovici<mailto: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 
Fedoruk<mailto:evge...@radware.com>, Adam 
Harwell<mailto:adam.harw...@rackspace.com>, Kyle 
Mestery<mailto:mest...@mestery.com>, Brandon 
Logan<mailto:brandon.lo...@rackspace.com>, Johnson, Michael (HP Cloud - 
Corvallis)<mailto:michael.d.john...@hp.com>, Doug 
Wiegley<mailto:do...@a10networks.com>, Samuel 
Bercovici<mailto: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  
> wrote:
> 
> It’s been a week, welcome Phil.
> 
> Thanks,
> doug
> 
> 
>> On Apr 13, 2015, at 2:39 PM, Doug Wiegley  
>> 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

[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] 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 Balle
Sent: ‎Friday‎, ‎20‎ ‎March‎ ‎2015 ‎20‎:‎20
To: OpenStack Development Mailing List (not for usage 
questions)

Make sense to me. Susanne

On Thu, Mar 19, 2015 at 5:49 PM, Doug Wiegley 
mailto: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: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] 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 
mailto: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:unsubscribe<http://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

[openstack-dev] [Neutron][LBaaS][SSL] Interim SSL API implementation for LBaaS

[Vijay Bhamidipati]

Hi,


A few months ago, as part of moving from legacy systems to Openstack, there
arose a requirement to support SSL APIs in our Openstack cloud
infrastructure at Ebay/Paypal. While the new v2 LBaaS API with its
considerable design improvements is in the process of addressing the SSL
requirements of LBaaS deployments, it is still under development and we had
to deploy a solution to address our immediate needs quicker.


There was a previous effort upstream [1] towards this, but that was
abandoned. Consequently, we came up with a different design for the LBaaS
SSL API that best suited our current requirements, and developed an interim
implementation that we currently have deployed on havana, but which can be
ported to later releases (icehouse/juno) with minimal changes since it’s
designed to be independent modularly and intersects existing code paths at
relatively few points.


We think that this API will be useful to the Openstack community and to
companies that are currently running Openstack clouds with LBaaS and need
SSL API support until LBaaS v2 comes out in Kilo or later, hence this mail
containing pointers to the code and instructions.


We have put up the code on github at:


Neutron:

——

https://github.com/vijayendrabvs/ssl-python-neutronclient.git

branch: stable/havana


LBaaS Driver:

——

https://github.com/vijayendrabvs/ssl-f5-neutron-lbaas.git

branch: havana


CLI:

——

https://github.com/vijayendrabvs/ssl-neutron.git

branch: master



The CLI and API documentation is at:


https://github.com/vijayendrabvs/ssl-neutron/blob/stable/havana/SSL-API-README



We worked with the F5 Openstack team who provided their F5 LBaaS driver to
work with our deployment of F5 LBs. We added the necessary modules in their
driver to plumb SSL entities on the LB, in the F5 plugin and agent driver.


F5 has currently released its drivers under the Mozilla license, and is in
the process of releasing the same under Apache License to align with the
rest of Openstack code.


We do not currently intend to commit this code to upstream stable havana,
unless the community thinks that doing so can be useful and pushes for it.


At the time we developed this solution, HAProxy hadn’t come out with
version 1.5 yet and thus didn’t support SSL, and lack of cycles meant we
weren’t able to implement a reference implementation for HAProxy as well.
That said, doing so would build on the same approach we use with F5, in
reconfiguring HAProxy from the HAProxy driver to setup SSL termination on
VIPs.


A point to note is that we have relied on using the neutron db to store our
certs/cert chains/cert keys. While this meets our current requirements, we
wish to emphasize that this may not suit all deployments. The new LBaaS v2
API is designed to integrate with Barbican and thus address such
requirements.


Finally, going forward, we will need to write migration scripts once the
LBaaS v2 API is ready, and deploying v1’s SSL API will get us started
towards that goal.


Please let us know if you have any questions regarding the code or
deploying it - we would be happy to help!


Thanks,

Regards,

Vijay B


[1] https://review.openstack.org/#/c/74031/5
___
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'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 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, October 15, 2014 9:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto:phillip.tooh...@rackspace.com>> wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, "Phillip Toohill" 
mailto: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=0B2r4apUP7uPwU1FWUjJBN0NMbWM&usp=sh
>a
>ring
>
>-diagrams are draw.io<http://draw.io> based and can be opened from within 
>Drive by
>selecting the appropriate application.
>
>On 10/7/14 2:25 PM, "Brandon Logan" 
>mailto: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

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 
mailto:phillip.tooh...@rackspace.com>> wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, "Phillip Toohill" 
mailto: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=0B2r4apUP7uPwU1FWUjJBN0NMbWM&usp=sh
>a
>ring
>
>-diagrams are draw.io<http://draw.io> based and can be opened from within 
>Drive by
>selecting the appropriate application.
>
>On 10/7/14 2:25 PM, "Brandon Logan" 
>mailto: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

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

[Vijay B]

o not attempt this, but like just noted, it isn’t
logically orderly to create the FLIP before creating the VIP successfully.
So let’s leave this op to the driver.


I am guilty of not following the proceedings on the Octavia controller
design due to internal work deadlines, but if I remember right, the design
specified a controller being built to spawn and configure virtual HAProxy
LB instances. If Octavia is not taking that route today, I think that the
best place to do this provisioning would be as described above for a) and
b).



4) If logic is in the drivers would we still return the port VIP to the
user then later overwrite it with the FLIP?


 >> As described in 2), we always return the VIP port along with the FLIP
info in API calls. Users like PaaS that sit on top of IaaS (Openstack) will
only use the FLIP when they commission endpoints for their users, who will
only be concerned with the FLIP.


5) Or would we have configuration to not return the port VIP initially, but
an additional query would show the associated FLIP.


 >> Not inclined to doing this :) It’s just another field associated with
the VIP - an API call for it would be overkill.


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


 >> Really depends on the core plugin you’re using - each plugin does this
differently, but all you need to do is to simply call
core_plugin.create_floatingip() and it should do everything for you - it
should correctly create the FLIP entry in the db, then go to its backend (a
controller or ovs or the L3 agent etc) which will correctly provision the
necessary interfaces and/or program the required flow rules or iptables
rules or equivalent and return success or failure.



All said and done, the fact is that in LBaaS, as with many other
components, we can always override the default plugin and driver layers and
write our own and do whatever we want in them :) This allows vendors to
rewrite implementations if they need to. Hopefully we’ll get the design
well enough that they don’t have to do that in more than a few modules.


Hope this helps! Please do let me know if you have any questions or need
more pointers with the extensions/neutron/etc.



Cheers!

Regards,

Vijay




On Mon, Oct 13, 2014 at 1:18 PM, Phillip Toohill <
phillip.tooh...@rackspace.com> wrote:

> Diagrams in jpeg format..
>
> On 10/12/14 10:06 PM, "Phillip Toohill" 
> 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=0B2r4apUP7uPwU1FWUjJBN0NMbWM&usp=sh
> >a
> >ring
> >
> >-diagrams are draw.io based and can be opened from within Drive by
> >selecting the appropriate application.
> >
> >On 10/7/14 2:25 PM, "Brandon Logan"  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
> >>

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 
mailto:phillip.tooh...@rackspace.com>> wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, "Phillip Toohill" 
mailto: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=0B2r4apUP7uPwU1FWUjJBN0NMbWM&usp=sh
>a
>ring
>
>-diagrams are draw.io based and can be opened from within 
>Drive by
>selecting the appropriate application.
>
>On 10/7/14 2:25 PM, "Brandon Logan" 
>mailto: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.org
>>> http://lists.openstack.org/cgi-bin/m

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

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

[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] 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  
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"
 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

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 
git commit -a --amend
git review 


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

[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] 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"  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"  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.
>

[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] 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 
mailto: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"  
> 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] 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 
CloudMagic

On Thu, Aug 07, 2014 at 3:54 AM, Jorge Miramontes 
mailto: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

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 
CloudMagic<https://cloudmagic.com/k/d/mailapp?ct=pa&cv=5.0.32&pv=4.2.2>

On Wed, Aug 06, 2014 at 2:46 AM, Stephen Balukoff 
mailto: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 
mailto: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.com<mailto:brandon.lo...@rackspace.com>]
> Sent: Tuesday, August 05, 2014 8:27 AM
> To: 
> openstack-dev@lists.openstack.org<mailto: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.org<mailto:OpenStack-dev@lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
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 - 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 
mailto:carlos.ga...@rackspace.com>> wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
mailto: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.com<mailto: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.com<mailto: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
>

[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.com<http://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 
mailto:carlos.ga...@rackspace.com>> wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
mailto: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.com<mailto: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.com<mailto: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 capabi

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 
mailto:carlos.ga...@rackspace.com>> wrote:

On Jul 15, 2014, at 10:55 AM, Samuel Bercovici 
mailto: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.com<mailto: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.com<mailto: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 c

[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 
CloudMagic<https://cloudmagic.com/k/d/mailapp?ct=pa&cv=1.0.21.3&pv=4.2.2>

On Fri, Jul 11, 2014 at 9:27 PM, Kyle Mestery 
mailto: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

Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

[Vijay B]

Hi Brandon, Eugene, Doug,

During the hackathon, I remember that we had briefly discussed how
listeners would manifest themselves on the LB VM/device, and it turned out
that for some backends like HAProxy it simply meant creating a frontend
entry in the cfg file whereas on other solutions it could mean spawning a
process/equivalent. So we must have status fields to track the state of any
such entities that are actually created. In the listener case, an ACTIVE
state would mean that the appropriate backend processes have been created
or that the required config file entries have been made.

I like the idea of having relational objects and setting the status on
them, and in our case we can use the status fields
(pool/healthmonitor/listener) in each table to denote the state of the
relationship (configuration/association on backend) to another object like
LoadBalancer. So I think the status fields should stay.

In this scenario, some entities' status could be updated in lbaas proper,
and some in the driver implementation. I don't have a strict preference as
to which among lbaas proper or the driver layer announces the status since
we discussed on the IRC that we'd have helper functions in the driver to do
these updates.


Regards,
Vijay


On Tue, Jun 24, 2014 at 12:16 PM, Brandon Logan  wrote:

> On Tue, 2014-06-24 at 18:53 +, Doug Wiegley wrote:
> > Hi Brandon,
> >
> > I think just one status is overloading too much onto the LB object (which
> > is perhaps something that a UI should do for a user, but not something an
> > API should be doing.)
>
> That is a good point and perhaps its another discussion to just have
> some way to show the status an entity has for each load balancer, which
> is what mark suggested for the member status at the meet-up.
>
> >
> > > 1) If an entity exists without a link to a load balancer it is purely
> > > just a database entry, so it would always be ACTIVE, but not really
> > > active in a technical sense.
> >
> > Depends on the driver.  I don¹t think this is a decision for lbaas
> proper.
>
> Driver is linked to the flavor or provider.  Flavor or provider will/is
> linked to load balancer.  We won't be able get a driver to send anything
> to if there isn't a load balancer.  Without a driver it is a decision
> for lbaas proper.  I'd be fine with setting the status of these
> "orphaned" entities to just ACTIVE but I'm just worried about the status
> management in the future.
>
> >
> >
> > > 2) If some of these entities become shareable then how does the status
> > > reflect that the entity failed to create on one load balancer but was
> > > successfully created on another.  That logic could get overly complex.
> >
> > That¹s a status on the join link, not the object, and I could argue
> > multiple ways in which that should be one way or another based on the
> > backend, which to me, again implies driver question (backend could queue
> > for later, or error immediately, or let things run degraded, orŠ)
>
> Yeah that is definitely an argument.  I'm just trying to keep in mind
> the complexities that could arise from decisions made now.  Perhaps it
> is the wrong way to look at it to some, but I don't think thinking about
> the future is a bad thing and should never be done.
>
> >
> > Thanks,
> > Doug
> >
> >
> >
> >
> > On 6/24/14, 11:23 AM, "Brandon Logan" 
> wrote:
> >
> > >I think we missed this discussion at the meet-up but I'd like to bring
> > >it up here.  To me having a status on all entities doesn't make much
> > >sense, and justing having a status on a load balancer (which would be a
> > >provisioning status) and a status on a member (which would be an
> > >operational status) are what makes sense because:
> > >
> > >1) If an entity exists without a link to a load balancer it is purely
> > >just a database entry, so it would always be ACTIVE, but not really
> > >active in a technical sense.
> > >
> > >2) If some of these entities become shareable then how does the status
> > >reflect that the entity failed to create on one load balancer but was
> > >successfully created on another.  That logic could get overly complex.
> > >
> > >I think the best thing to do is to have the load balancer status reflect
> > >the provisioning status of all of its children.  So if a health monitor
> > >is updated then the load balancer that health monitor is linked to would
> > >have its status changed to PENDING_UPDATE.  Conversely, if a load
> > >balancer or any entities linked to

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

[Vijay Venkatachalam]

>>SNI list is managed by separate entity
What is this entity?

From: Evgeny Fedoruk [mailto:evge...@radware.com]
Sent: Tuesday, June 24, 2014 12:25 PM
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?

+1 for option 1. SNI list is managed by separate entity, default TLS container 
is part of a listener object. It will have None value when listener does not 
offloads TLS.
Managing another entity for 1:0-1 relationship just for future use seems not 
right to me. Breaking TLS settings apart from listener can be done when needed, 
if needed.

Thanks,
Evg


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, June 24, 2014 4:26 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?

Ok, so we've got opinions on both sides of the argument here. I'm actually 
pretty ambivalent about it. Do others have strong opinions on this?

On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley 
mailto:do...@a10networks.com>> wrote:
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 mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, June 23, 2014 at 5:25 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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
> >
> >
> >
> >
> >
>

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 mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, June 23, 2014 at 5:25 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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
> > mailto: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 ce

[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

[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

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

[Vijay Venkatachalam]

> -Original Message-
> From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
> Sent: Thursday, June 12, 2014 1:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
> Integration Ideas
> 
> 
> On Jun 11, 2014, at 9:31 AM, Evgeny Fedoruk 
> wrote:
> 
> > Regarding the case when back-end system tries to retrieve secret from
> > deleted Barbican TLS container, Is this a real use case? I mean, is there a
> back-end system which will get container ID from somewhere, try to retrieve
> secrets from Barbican by itself and hope for good?
> 
> I'm of the opinion that the backend systems should not be talking to
> barbican and that any key passing should happen from the API to the back
> end.
> I see it being very complex trying to code the backend so that its 
> configurable
> with barbican since I would have assumed the backend won't even have
> knowledge of open stack.
> 
> 
> > In my understanding, there is a plugin and a driver who can always check
> TLS container existence before even start configuring the back-end system.
> In case of a problem tenant will receive a clear error message and back-end
> system will remain up and running.
> 
> This is the case when the API is spinning up the back end system. The
> concern is when a backend tries to be HA by duplicating a loadbalancer for
> redundancy. But I would argue that the front end as its being treated now
> would not be managing details for HA so that the back end providing HA
> would duplicate the keys between backend loadbalancers. Example F5 must
> store the private key on its side and if its providing HA it would have 
> access to
> the key already.

This assumption is right. For ex. in NetScaler case, when a certificate is sent
to a HA setup of LoadBalancers, the certificate is maintained by the backend.
The cert is replicated in both the LoadBalancers by its private mechanisms 
(no need to contact Barbican).

> 
> > In case when back-end system itself triggers secret retrieval (outside of
> OpenStack scope)  - first it should check container existence and only after
> that destroy previous TLS setup and perform a new setup.
> > LBaaS back-end system may not get a container ID at all,  but get its 
> > content
> and not interact with Barbican by itself.
> > In case when new LBaaS back-end system is created (HA event, for
> example), whoever created an instance and gave it container ID, should
> check its existence.
> >
> > Is there a specific use case when:
> > back-end system, having container ID, up and running, offloading
> > encrypted traffic with a certificate from that container (by this time 
> > deleted
> from Barbican), at some time, goes and tries to retrieve the secret, fails,
> loses its previous TLS settings and causing downtime?
> >
> > Regards,
> > Evgeny
> >
> >
> >
> > From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
> > Sent: Wednesday, June 11, 2014 4:14 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [Caution: Message contains Suspicious URL content] Re:
> > [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration
> > Ideas
> >
> > +1 - Warning on a deletion of certificate in use can be considered as a
> "nice-to-have" feature and not "must-have"!
> >
> > From: Samuel Bercovici [mailto:samu...@radware.com]
> > Sent: Wednesday, June 11, 2014 4:16 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
> > Integration Ideas
> >
> > Hi,
> >
> > For Juno -
> > I think that the existing capabilities in Barbican should be enough to start
> with.
> > A good detection and error message in LBaaS should also be sufficient to
> start with.
> >
> > After Juno -
> > We can consider a fix enhancement to Barbican later, IF deleting a
> certificate in use and expressing an explicit error, will be common and
> become an issue.
> >
> > Regards,
> > -Sam.
> >
> >
> >
> > From: Doug Wiegley [mailto:do...@a10networks.com]
> > Sent: Wednesday, June 11, 2014 12:41 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [Caution: Message contains Suspicious URL content] Re:
> > [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration
> > Ideas
> >
> > Of what use is a database that randomly delete rows?  That is, in effect,
> what you're a

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

[Vijay Venkatachalam]

>>>the backend it what's responsible for handling it from that point
Right! For ex. NetScaler handles cert sync across HA nodes via its proprietary  
mechanisms.

Since shadow copying is not required for every driver, the functionality can be 
implemented by the driver that needs it.

Thanks,
Vijay V.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: Wednesday, June 11, 2014 2:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

Doug: Right, we actually have a blueprint draft for EXACTLY this, but the 
Barbican team gave us a flat "not happening, we reject this change" on causing 
a delete to fail. The shadow-copy solution I proposed only came about because 
the option you are proposing is not possible. :(

I also realized that really, this whole thing is an issue for the backend, not 
really for the API itself - the LBaaS API will be retrieving the key/cert from 
Barbican and passing it to the backend, and the backend it what's responsible 
for handling it from that point (F5, Stingray etc would never actually call 
back to Barbican). So, really, the Service-VM solution we're architecting is 
where the shadow-copy solution needs to live, at which point it no longer is 
really an issue we'd need to discuss on this mailing list, I think. Stephen, 
does that make sense to you?
--Adam

https://keybase.io/rm_you


From: Doug Wiegley mailto:do...@a10networks.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, June 10, 2014 4:10 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

A third option, that is neither shadow copying nor policy enforcement:

Ask the Barbican team to put in a small api that is effectively, "hey, I'm 
using this container" and "hey, I'm done with this container", and the have 
their delete fail if someone is still using it.  This isn't calling into other 
services, it's simply getting informed of who's using what, and not stomping 
it.  That seems pretty core to me, and the workarounds if we can't trust the 
store to store things are pretty hacky.

Doug


From: Adam Harwell 
mailto:adam.harw...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, June 10, 2014 at 3:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

Right, service VMs are the biggest case for this, because then we WILL need to 
be tracking the barbicanID even in the backend. I also agree that it would be 
more useful for OpenStack as a whole if it were managed by a central service 
(i.e., Barbican handles this issue) rather than having to duplicate all of this 
logic in every service that utilizes the containers (VPN/FW would have to use 
essentially the same strategy, or else fragment and do something entirely 
different - the first of which is a lot of duplicated effort, and the second is 
just generally bad, already way too much fragmentation going on). On the other 
hand, the Barbican team is very opposed to doing policy enforcement within 
Barbican, and I can't say I fault them for that opinion (Barbican was never 
designed to include a policy enforcement engine). The shadow-copy strategy is 
the best alternative I can think of given the current project/political 
landscape. :(

--Adam

https://keybase.io/rm_you


From: Doug Wiegley mailto:do...@a10networks.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, June 10, 2014 3:42 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

> Doug: The reasons a LB might be reprovisioned are fairly important - mostly 
> around HA, for fail overs or capacity - exactly the times we're trying avoid 
> a failure.

Certainly the ticking time bomb is a bad idea, but HA seems cleaner to do in 
the backend, rather than at the openstack API level (the dangling reference 
doesn't kick in until the lbaas api is used to accomplish that failover.)  And 
the lbaas api also doesn't have any provisions for helping to shuffle for 
capacity, so that also becomes a backend issue.  And the backend won't be 
natively dealing with a barbi

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



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

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

[Vijay B]

Hi Brandon!

Please see inline..




On Wed, May 28, 2014 at 12:01 PM, Brandon Logan  wrote:

> Hi Vijay,
>
> On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote:
> > Hi Brandon,
> >
> >
> > The current reviews of the schema itself are absolutely valid and
> > necessary, and must go on. However, the place of implementation of
> > this schema needs to be clarified. Rather than make any changes
> > whatsoever to the existing neutron db schema for LBaaS, this new db
> > schema outlined needs to be implemented for a separate LBaaS core
> > service.
> >
> Are you suggesting a separate lbaas database from the neutron database?
> If not, then I could use some clarification. If so, I'd advocate against
> that right now because there's just too many things that would need to
> be changed.  Later, when LBaaS becomes its own service then yeah that
> will need to happen.
>

v> Ok, so as I understand it, in this scheme, there is no new schema or db,
there will be a new set of tables resident in neutron_db schema itself,
alongside legacy lbaas tables. Let's consider a rough view of the
implementation.

Layer 1 - We'll have a new lbaas v3.0 api in neutron, with the current
lbaas service plugin having to support it in addition to the legacy lbaas
extensions that it already supports. We'll need to put in new code anyway
that will process the v3.0 lbaas api no matter what our approach is.
Layer 2 - Management code that will take care of updating the db with
entities in pending_create, then invoking the right provider driver,
choosing/scheduling the plugin drivers or the agent drivers, invoking them,
getting the results, and updating the db.
Layer 3 - The drivers themselves (either plugin drivers (like the HAProxy
namespace driver/Netscaler) or plugin drivers + agent drivers).

While having the new tables sit alongside the legacy tables is one way to
implement the changes, I don't see how this approach leads to a lesser
amount of changes overall. Layer 2 above will be the major place where
changes can be complicated. Also, it will be confusing to have two sets of
lbaas tables in the same schema.

I don't want a separate lbaas database under neutron, and neither do I want
it within neutron. I'm not suggesting that we create a db schema alone, I'm
saying we must build it with the new LBaaS service (just like neutron
itself when it got created). If we don't do this now, we'll end up
reimplementing the logic implemented in neutron for the new lbaas v3.0 API
all over again for the new core LBaaS service. We'd rather do it in the new
one in one effort.

I could be missing some constraints that drive taking the former approach -
please help me understand those - I don't want to be discounting any one
approach without thorough consideration. Right now, it looks to me like
this approach is being taken only to accommodate the HAProxy namespace
driver. Really that is the only driver which seems to be very intertwined
with neutron in the way it uses namespaces.


>
> > What we should be providing in neutron is a switch (a global conf)
> > that can be set to instruct neutron to do one of two things:
> >
> >
> > 1. Use the existing neutron LBaaS API, with the backend being the
> > existing neutron LBaaS db schema. This is the status quo.
> > 2. Use the existing neutron LBaaS API, with the backend being the new
> > LBaaS service. This will invoke calls not to neutron's current LBaaS
> > code at all, rather, it will call into a new set of proxy "backend"
> > code in neutron that will translate the older LBaaS API calls into the
> > newer REST calls serviced by the new LBaaS service, which will write
> > down these details accordingly in its new db schema. As long as the
> > request and response objects to legacy neutron LBaaS calls are
> > preserved as is, there should be no issues. Writing unit tests should
> > also be comparatively more straightforward, and old functional tests
> > can be retained, and newer ones will not clash with legacy code.
> > Legacy code itself will work, having not been touched at all. The
> > blueprint for the db schema that you have referenced
> > (
> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst)
> should be implemented for this new LBaaS service, post reviews.
> >
> I think the point of this blueprint is to get the API and object model
> less confusing for the Neutron LBaaS service plugin.  I think it's too
> early to create an LBaaS service because we have not yet cleaned up the
> tight integration points between Neutron LBaaS and LBaaS.  Creating a
> new service would require only API interactions between Neutron and this
> LBaaS service, which c

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

[Vijay B]

Hi Brandon,

The current reviews of the schema itself are absolutely valid and
necessary, and must go on. However, the place of implementation of this
schema needs to be clarified. Rather than make any changes whatsoever to
the existing neutron db schema for LBaaS, this new db schema outlined needs
to be implemented for a separate LBaaS core service.

What we should be providing in neutron is a switch (a global conf) that can
be set to instruct neutron to do one of two things:

1. Use the existing neutron LBaaS API, with the backend being the existing
neutron LBaaS db schema. This is the status quo.
2. Use the existing neutron LBaaS API, with the backend being the new LBaaS
service. This will invoke calls not to neutron's current LBaaS code at all,
rather, it will call into a new set of proxy "backend" code in neutron that
will translate the older LBaaS API calls into the newer REST calls serviced
by the new LBaaS service, which will write down these details accordingly
in its new db schema. As long as the request and response objects to legacy
neutron LBaaS calls are preserved as is, there should be no issues. Writing
unit tests should also be comparatively more straightforward, and old
functional tests can be retained, and newer ones will not clash with legacy
code. Legacy code itself will work, having not been touched at all. The
blueprint for the db schema that you have referenced (
https://review.openstack.org/#/c/89903/5/specs/juno/lbaas
-api-and-objmodel-improvement.rst) should be implemented for this new LBaaS
service, post reviews.

The third option would be to turn off neutron LBaaS API, and use the new
LBaaS core service directly, but for this we can simply disable neutron
lbaas, and don't need a config parameter in neutron.

Implementing this db schema within neutron instead will be not just
complicated, but a huge effort that will go waste in future once the new
LBaaS service is implemented. Also, migration will unnecessarily retain the
same steps needed to go from legacy neutron LBaaS to the new core LBaaS
service in this approach (twice, in succession) in case for any reason the
version goes from legacy neutron LBaaS -> new neutron LBaaS -> new LBaaS
core service.

Going forward, the legacy neutron LBaaS API can be deprecated, and the new
API that directly contacts the new LBaaS core service can be used.

We have discussed the above architecture previously, but outside of the ML,
and a draft of the blueprint for this new LBaaS core service is underway,
and is a collation of all the discussions among a large number of LBaaS
engineers including yourself during the summit - I will be posting it for
review within a couple of days, as planned.


Regards,
Vijay


On Tue, May 27, 2014 at 12:32 PM, Brandon Logan  wrote:

> Referencing this blueprint:
>
> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst
>
> Anyone who has suggestions to possible issues or can answer some of
> these questions please respond.
>
>
> 1. LoadBalancer to Listener relationship M:N vs 1:N
> The main reason we went with the M:N was so IPv6 could use the same
> listener as IPv4.  However this can be accomplished by the user just
> creating a second listener and pool with the same configuration.  This
> will end up being a bad user experience when the listener and pool
> configuration starts getting complex (adding in TLS, health monitors,
> SNI, etc). A good reason to not do the M:N is because the logic on might
> get complex when dealing with status.  I'd like to get people's opinions
> on this on whether we should do M:N or just 1:N.  Another option, is to
> just implement 1:N right now and later implement the M:N in another
> blueprint if it is decided that the user experience suffers greatly.
>
> My opinion: I like the idea of leaving it to another blueprint to
> implement.  However, we would need to watch out for any major
> architecture changes in the time itis not implemented that could make
> this more difficult than what it needs to be.
>
> 2. Pool to Health Monitor relationship 1:N vs 1:1
> Currently, I believe this is 1:N however it was suggested to deprecate
> this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
> objections to channging to 1:1?
>
> My opinion: I'm for 1:1 as long as there aren't any major reasons why
> there needs to be 1:N.
>
> 3. Does the Pool object need a status field now that it is a pure
> logical object?
>
> My opinion: I don't think it needs the status field.  I think the
> LoadBalancer object may be the only thing that needs a status, other
> than the pool members for health monitoring.  I might be corrected on
> this though.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org

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

[Vijay Venkatachalam]

Thanks for the clarification. Eugene.

A tangential point since you brought healthmon and pool.

There will be an additional entity called ‘PoolMonitorAssociation’ which 
results in a many to many relationship between pool and monitors. Right?

Now, the model is indicating a pool can have only one monitor. So a minor 
correction is required to indicate the many to many relationship via 
PoolMonitorAssociation.

Thanks,
Vijay V.


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Thursday, May 15, 2014 7:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?

Hi Vijay,


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?
Right, that's the same as health monitors and pools work right now: there are 
separate REST action to associate healthmon to a pool


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



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



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



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

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

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Vijay B]

Hi Carlos,

It looks like only the gerrit review has been marked abandoned because of a
week of inactivity.

Regards,
Vijay


On Tue, Apr 29, 2014 at 4:51 PM, Carlos Garza wrote:

> This blueprint was marked abandoned.
>
>  On Apr 29, 2014, at 3:55 PM, Vijay B 
>  wrote:
>
>  Hi Sam, Evgeny,
>
>  I've reviewed https://review.openstack.org/#/c/74031 with my comments. I
> am not sure if there is a request with code newer than this link - please
> do let me know if that is the case.
>
>  Thanks,
> Regards,
> Vijay
>
>
> On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German <
> german.eichber...@hp.com> wrote:
>
>> Sam,
>>
>> The use cases where pretty complete the last time I checked so let's move
>> them to gerrit so we can all vote.
>>
>> Echoing Kyle I would love to see us focusing on getting things ready for
>> the summit.
>>
>> German
>>
>> -Original Message-
>> From: Samuel Bercovici [mailto:samu...@radware.com]
>> Sent: Monday, April 28, 2014 11:44 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>>
>> Hi,
>>
>> I was just working to push the use cases into the new format .rst but I
>> agree that using google doc would be more intuitive.
>> Let me know what you prefer to do with the use cases document:
>> 1. leave it at google docs at -
>> https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
>> 2. Move it to the new format under -
>> http://git.openstack.org/cgit/openstack/neutron-specs, I have already
>> files a blue print
>> https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and can
>> complete the .rst process by tomorrow.
>>
>> Regards,
>> -Sam.
>>
>>
>>
>>
>>
>>
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@noironetworks.com]
>> Sent: Monday, April 28, 2014 4:33 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>>
>> Folks, sorry for the top post here, but I wanted to make sure to gather
>> people's attention in this thread.
>>
>> I'm very happy to see all the passion around LBaaS in Neutron for this
>> cycle. As I've told a few people, seeing all the interest from operators
>> and providers is fantastic, as it gives us valuable input from that side of
>> things before we embark on designing and coding.
>> I've also attended the last few LBaaS IRC meetings, and I've been
>> catching up on the LBaaS documents and emails. There is a lot of great work
>> and passion by many people. However, the downside of what I've seen is that
>> there is a logjam around progress here. Given we're two weeks out from the
>> Summit, I'm going to start running the LBaaS meetings with Eugene to try
>> and help provide some focus there.
>> Hopefully we can use this week and next week's meetings to drive to a
>> consistent Summit agenda and lay the groundwork for LBaaS in Juno and
>> beyond.
>>
>> Also, while our new neutron-specs BP repository has been great so far for
>> developers, based on feedback from operators, it may not be ideal for those
>> who are not used to contributing using gerrit. I don't want to lose the
>> voice of those people, so I'm pondering what to do. This is really
>> affecting the LBaaS discussion at the moment. I'm thinking that we should
>> ideally try to use Google Docs for these initial discussions and then move
>> the result of that into a BP on neutron-specs. What do people think of that?
>>
>> If we go down this path, we need to decide on a single Google Doc for
>> people to collaborate on. I don't want to put Stephen on the spot, but his
>> document may be a good starting point.
>>
>> I'd like to hear what others think on this plan as well.
>>
>> Thanks,
>> Kyle
>>
>>
>> On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov <
>> enikano...@mirantis.com> wrote:
>> > Hi,
>> >
>> >>
>> >> You knew from the action items that came out of the IRC meeting of
>> >> April
>> >> 17 that my team would be working on an API revision proposal. You
>> >> also knew that this proposal was to be accompanied by an object model
>> >> diagram and glossary, in order to clear up confusion. You were in
>> >> th

[openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for LBaaS and VPN

[Vijay B]

Hi,

It looks like there are areas of common effort in multiple efforts that are
proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in
neutron.

Two relevant efforts are listed below:


https://review.openstack.org/#/c/74031/   (
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)

https://review.openstack.org/#/c/58897/   (
https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)



Both VPN and LBaaS will use SSL certificates and keys, and this makes it
better to implement SSL entities as first class citizens in the OS world.
So, three points need to be discussed here:

1. The VPN SSL implementation above is putting the SSL cert content in a
mapping table, instead of maintaining certs separately and referencing them
using IDs. The LBaaS implementation stores certificates in a separate
table, but implements the necessary extensions and logic under LBaaS. We
propose that both these implementations move away from this and refer to
SSL entities using IDs, and that the SSL entities themselves are
implemented as their own resources, serviced either by a core plugin or a
new SSL plugin (assuming neutron; please also see point 3 below).

2. The actual data store where the certs and keys are stored should be
configurable at least globally, such that the SSL plugin code will
singularly refer to that store alone when working with the SSL entities.
The data store candidates currently are Barbican and a sql db. Each should
have a separate backend driver, along with the required config values. If
further evaluation of Barbican shows that it fits all SSL needs, we should
make it a priority over a sqldb driver.

3. Where should the primary entries for the SSL entities be stored? While
the actual certs themselves will reside on Barbican or SQLdb, the entities
themselves are currently being implemented in Neutron since they are being
used/referenced there. However, we feel that implementing them in keystone
would be most appropriate. We could also follow a federated model where a
subset of keys can reside on another service such as Neutron. We are fine
with starting an initial implementation in neutron, in a modular manner,
and move it later to keystone.


Please provide your inputs on this.


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] BBG edit of new API proposal

[Vijay B]

Hi German,

Thanks for bringing up the VPN SSL implementation - we just took a look at
the blueprint:

https://docs.google.com/file/d/0B4kh-7VVPWlPOWlTM0QzNDJucjg/edit

and it matches the design we would take with the SSL entity portion of the
effort, in that we would like to make them first class citizens as opposed
to being defined by the LBaaS plugin.

I think that these two threads/efforts (SSL VPN and SSL LBaaS) should be
merged - I will start a new thread to this effect, since the current thread
deals with way too many things.

I concur with you regarding using Barbican to store the actual certs and
keys. I am yet to use it though, and plan to do so within this week to
evaluate its current state of maturity. Since Sam has already put in effort
towards the sql implementation of storage, and there are use cases that
prefer using sql vs barbican, I am of the view that making it configurable
to use either would be optimal. Other than that, my review comments were to
do about how to treat entities in the actual implementation - keeping the
SSL entities separate from LBaaS would help us move them later to keystone,
for I think that is where they should reside. I would like to have the ML's
views on this. BTW I haven't actually proposed a new API implementation yet
- for now, I'm just highlighting that the specification at
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL doesn't define it at all,
even though it lists the CLIs (which haven't been implemented yet in the
gerrit request at https://review.openstack.org/#/c/74031). We'd need at
least the API spec to test out the patch fully. We can figure the APIs out
by looking at the code, but it would be simpler to just have the API spec
listed out like in the OS API reference guides.

Sam's patch basically defines the new extensions for the SSL entities
inside the loadbalancer plugin. I prefer that they be implemented outside
of it. REST API wise, the only difference would be that today when I invoke
Sam's patch's SSL extension to list the ssl_certificates, it would look
thus:

stack@sslds1:~/devstack$ curl -i -X GET http://192.168.45.55:9696/
*v2.0/lb/ssl_certificates* -H "User-Agent: python-keystoneclient" -H
"X-Auth-Token: $TOKEN"

HTTP/1.1 200 OK

Content-Type: application/json; charset=UTF-8

Content-Length: 24

Date: Sat, 26 Apr 2014 04:42:48 GMT


{"ssl_certificates": []}

stack@sslds1:~/devstack$



and if implemented outside, it would be GET http://192.168.45.55:9696/
*v2.0/ssl_certificates *or similar. However, code wise, it would make a
difference during any refactoring effort.



Regards,
Vijay





On Tue, Apr 29, 2014 at 3:04 PM, Eichberger, German <
german.eichber...@hp.com> wrote:

>  Vijay,
>
>
>
> SSL and certificate management is a major requirement from a cloud
> operator perspective. The VPN part of Neutron is looking into using
> Barbican and I am surprised that LB is going a different way/implementing
> their own store. Just for the record I prefer Barbican J
>
>
>
> Furthermore, we are still discussing the API and have several proposals so
> I am not sure how the SSL API/implementation you are proposing fits into
> that.
>
>
>
> German
>
>
>
> *From:* Vijay B [mailto:os.v...@gmail.com]
> *Sent:* Tuesday, April 29, 2014 2:30 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API
> proposal
>
>
>
> Also, a section for the API specification for the newly created SSL
> extensions needs to be added to
> https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.
>
>
>
> Regards,
>
> Vijay
>
>
>
> On Tue, Apr 29, 2014 at 1:55 PM, Vijay B  wrote:
>
> Hi Sam, Evgeny,
>
>
>
> I've reviewed https://review.openstack.org/#/c/74031 with my comments. I
> am not sure if there is a request with code newer than this link - please
> do let me know if that is the case.
>
>
>
> Thanks,
>
> Regards,
>
> Vijay
>
>
>
> On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German <
> german.eichber...@hp.com> wrote:
>
> Sam,
>
> The use cases where pretty complete the last time I checked so let's move
> them to gerrit so we can all vote.
>
> Echoing Kyle I would love to see us focusing on getting things ready for
> the summit.
>
> German
>
>
> -Original Message-
> From: Samuel Bercovici [mailto:samu...@radware.com]
> Sent: Monday, April 28, 2014 11:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>
> Hi,
>
> I was just working to push the use cases into the new format .rst but I
> agree that using google doc w

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Vijay B]

Also, a section for the API specification for the newly created SSL
extensions needs to be added to
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.

Regards,
Vijay


On Tue, Apr 29, 2014 at 1:55 PM, Vijay B  wrote:

> Hi Sam, Evgeny,
>
> I've reviewed https://review.openstack.org/#/c/74031 with my comments. I
> am not sure if there is a request with code newer than this link - please
> do let me know if that is the case.
>
> Thanks,
> Regards,
> Vijay
>
>
> On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German <
> german.eichber...@hp.com> wrote:
>
>> Sam,
>>
>> The use cases where pretty complete the last time I checked so let's move
>> them to gerrit so we can all vote.
>>
>> Echoing Kyle I would love to see us focusing on getting things ready for
>> the summit.
>>
>> German
>>
>> -Original Message-
>> From: Samuel Bercovici [mailto:samu...@radware.com]
>> Sent: Monday, April 28, 2014 11:44 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>>
>> Hi,
>>
>> I was just working to push the use cases into the new format .rst but I
>> agree that using google doc would be more intuitive.
>> Let me know what you prefer to do with the use cases document:
>> 1. leave it at google docs at -
>> https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
>> 2. Move it to the new format under -
>> http://git.openstack.org/cgit/openstack/neutron-specs, I have already
>> files a blue print
>> https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and can
>> complete the .rst process by tomorrow.
>>
>> Regards,
>> -Sam.
>>
>>
>>
>>
>>
>>
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@noironetworks.com]
>> Sent: Monday, April 28, 2014 4:33 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>>
>> Folks, sorry for the top post here, but I wanted to make sure to gather
>> people's attention in this thread.
>>
>> I'm very happy to see all the passion around LBaaS in Neutron for this
>> cycle. As I've told a few people, seeing all the interest from operators
>> and providers is fantastic, as it gives us valuable input from that side of
>> things before we embark on designing and coding.
>> I've also attended the last few LBaaS IRC meetings, and I've been
>> catching up on the LBaaS documents and emails. There is a lot of great work
>> and passion by many people. However, the downside of what I've seen is that
>> there is a logjam around progress here. Given we're two weeks out from the
>> Summit, I'm going to start running the LBaaS meetings with Eugene to try
>> and help provide some focus there.
>> Hopefully we can use this week and next week's meetings to drive to a
>> consistent Summit agenda and lay the groundwork for LBaaS in Juno and
>> beyond.
>>
>> Also, while our new neutron-specs BP repository has been great so far for
>> developers, based on feedback from operators, it may not be ideal for those
>> who are not used to contributing using gerrit. I don't want to lose the
>> voice of those people, so I'm pondering what to do. This is really
>> affecting the LBaaS discussion at the moment. I'm thinking that we should
>> ideally try to use Google Docs for these initial discussions and then move
>> the result of that into a BP on neutron-specs. What do people think of that?
>>
>> If we go down this path, we need to decide on a single Google Doc for
>> people to collaborate on. I don't want to put Stephen on the spot, but his
>> document may be a good starting point.
>>
>> I'd like to hear what others think on this plan as well.
>>
>> Thanks,
>> Kyle
>>
>>
>> On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov <
>> enikano...@mirantis.com> wrote:
>> > Hi,
>> >
>> >>
>> >> You knew from the action items that came out of the IRC meeting of
>> >> April
>> >> 17 that my team would be working on an API revision proposal. You
>> >> also knew that this proposal was to be accompanied by an object model
>> >> diagram and glossary, in order to clear up confusion. You were in
>> >> that meeting, you saw the action items being created. Heck, you even
>> >

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

[Vijay B]

Hi Sam, Evgeny,

I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am
not sure if there is a request with code newer than this link - please do
let me know if that is the case.

Thanks,
Regards,
Vijay


On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German <
german.eichber...@hp.com> wrote:

> Sam,
>
> The use cases where pretty complete the last time I checked so let's move
> them to gerrit so we can all vote.
>
> Echoing Kyle I would love to see us focusing on getting things ready for
> the summit.
>
> German
>
> -Original Message-
> From: Samuel Bercovici [mailto:samu...@radware.com]
> Sent: Monday, April 28, 2014 11:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>
> Hi,
>
> I was just working to push the use cases into the new format .rst but I
> agree that using google doc would be more intuitive.
> Let me know what you prefer to do with the use cases document:
> 1. leave it at google docs at -
> https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
> 2. Move it to the new format under -
> http://git.openstack.org/cgit/openstack/neutron-specs, I have already
> files a blue print
> https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and can
> complete the .rst process by tomorrow.
>
> Regards,
> -Sam.
>
>
>
>
>
>
> -Original Message-
> From: Kyle Mestery [mailto:mest...@noironetworks.com]
> Sent: Monday, April 28, 2014 4:33 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>
> Folks, sorry for the top post here, but I wanted to make sure to gather
> people's attention in this thread.
>
> I'm very happy to see all the passion around LBaaS in Neutron for this
> cycle. As I've told a few people, seeing all the interest from operators
> and providers is fantastic, as it gives us valuable input from that side of
> things before we embark on designing and coding.
> I've also attended the last few LBaaS IRC meetings, and I've been catching
> up on the LBaaS documents and emails. There is a lot of great work and
> passion by many people. However, the downside of what I've seen is that
> there is a logjam around progress here. Given we're two weeks out from the
> Summit, I'm going to start running the LBaaS meetings with Eugene to try
> and help provide some focus there.
> Hopefully we can use this week and next week's meetings to drive to a
> consistent Summit agenda and lay the groundwork for LBaaS in Juno and
> beyond.
>
> Also, while our new neutron-specs BP repository has been great so far for
> developers, based on feedback from operators, it may not be ideal for those
> who are not used to contributing using gerrit. I don't want to lose the
> voice of those people, so I'm pondering what to do. This is really
> affecting the LBaaS discussion at the moment. I'm thinking that we should
> ideally try to use Google Docs for these initial discussions and then move
> the result of that into a BP on neutron-specs. What do people think of that?
>
> If we go down this path, we need to decide on a single Google Doc for
> people to collaborate on. I don't want to put Stephen on the spot, but his
> document may be a good starting point.
>
> I'd like to hear what others think on this plan as well.
>
> Thanks,
> Kyle
>
>
> On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov 
> wrote:
> > Hi,
> >
> >>
> >> You knew from the action items that came out of the IRC meeting of
> >> April
> >> 17 that my team would be working on an API revision proposal. You
> >> also knew that this proposal was to be accompanied by an object model
> >> diagram and glossary, in order to clear up confusion. You were in
> >> that meeting, you saw the action items being created. Heck, you even
> >> added the "to prepare API for SSL and L7" directive for my team
> yourself!
> >>
> >> The implied but not stated assumption about this work was that it
> >> would be fairly evaluated once done, and that we would be given a short
> window (ie.
> >> about a week) in which to fully prepare and state our proposal.
> >>
> >> Your actions, though, were apparently to produce your own version of
> >> the same in blueprint form without notifying anyone in the group that
> >> you were going to be doing this, let alone my team. How could you
> >> have given my API proposal a fai

Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?

[Vijay B]

Hi Tianhua, Jay,

A blueprint has already been submitted in this regard:

https://docs.google.com/document/d/1ZqW7qeyHTm9AQt28GUdfv46ui9mz09UQNvjXiewOAys/edit#

We've been working to implement a generic tagging framework where tags are
a first class resource and other resources can be associated with tags. Our
first implementation focuses on neutron. For us at Ebay, this forms an
important foundational framework to support flexible/customizable VPC
architectures. A detailed design with extension/db/other changes has been
drawn up and will be submitted for review to the group in the near future.
Please do add your thoughts/reviews to it.

Regards,
Vijay


On Mon, Apr 21, 2014 at 12:46 PM, Jay Pipes  wrote:

> Absolutely. Feel free.
>
>
> On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua wrote:
>
>> I plan to register a blueprints in nova for record this. Can I?
>>
>>
>> -邮件原件-
>> 发件人: Jay Pipes [mailto:jaypi...@gmail.com]
>> 发送时间: 2014年4月20日 21:06
>> 收件人: openstack-dev@lists.openstack.org
>> 主题: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support
>> tags for os resources?
>>
>> On Sun, 2014-04-20 at 08:35 +, Huangtianhua wrote:
>> > Hi all:
>> >
>> > Currently, the EC2 API of OpenStack only has tags support (metadata)
>> > for instances. And there has already a blueprint about to add support
>> > for volumes and volume snapshots using “metadata”.
>> >
>> > There are a lot of resources such as
>> > image/subnet/securityGroup/networkInterface(port) are supported add
>> > tags for AWS.
>> >
>> > I think we should support tags for these resources. There may be no
>> > property “metadata" for these resources, so we should to add
>> > “metadata” to support the resource tags, the change related API.
>>
>> Hi Tianhua,
>>
>> In OpenStack, generally, the choice was made to use maps of key/value
>> pairs instead of lists of strings (tags) to annotate objects exposed in the
>> REST APIs. OpenStack REST APIs inconsistently call these maps of key/value
>> pairs:
>>
>>  * "properties" (Glance, Cinder Image, Volume respectively)
>>  * "extra_specs" (Nova InstanceType)
>>  * "metadata" (Nova Instance, Aggregate and InstanceGroup, Neutron)
>>  * "metadetails" (Nova Aggregate and InstanceGroup)
>>  * "system_metadata" (Nova Instance -- differs from "normal" metadata in
>> that the key/value pairs are 'owned' by Nova, not a user...)
>>
>> Personally, I think tags are a cleaner way of annotating objects when the
>> annotation is coming from a normal user. Tags represent by far the most
>> common way for REST APIs to enable user-facing annotation of objects in a
>> way that is easy to search on. I'd love to see support for tags added to
>> any searchable/queryable object in all of the OpenStack APIs.
>>
>> I'd also like to see cleanup of the aforementioned inconsistencies in how
>> maps of key/value pairs are both implemented and named throughout the
>> OpenStack APIs. Specifically, I'd like to see this implemented in the next
>> major version of the Compute API:
>>
>>  * Removal of the "metadetails" term
>>  * All key/value pairs can only be changed by users with elevated
>> privileged system-controlled (normal users should use tags)
>>  * Call all these key/value pair combinations "properties" --
>> technically, "metadata" is "data about data", like the size of an integer.
>> These key/value pairs are just data, not data about data.
>>  * Identify key/value pairs that are relied on by all of Nova to be a
>> specific key and value combination, and make these things actual real
>> attributes on some object model -- since that is a much greater guard for
>> the schema of an object and enables greater performance by allowing both
>> type safety of the underlying data and removes the need to search by both a
>> key and a value.
>>
>> Best,
>> -jay
>>
>>
>>
>> ___
>> 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] 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 
mailto: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.net<mailto: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 x807

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



--
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=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing

Thanks,
Eugene.

On Thu, Apr 3, 2014 at 5:34 AM, Prashanth Hari 
mailto: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 
mailto: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 
mailto: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 mailto:sleipnir...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 1, 2014 4:09 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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.com<mailto: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 

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

[Vijay B]

Hi VijayV, Oleg!

Thanks for the pointers! It turns out I had to put in an __init__.py in the
dummy/ directory, else the driver wouldn't get loaded. Now I see newer
issues, and am trying to fix those. I'll ping back on how that goes and if
I have any questions..

Cheers!
Regards,
Vijay


On Wed, Apr 2, 2014 at 1:34 AM, Oleg Bondarev wrote:

> Hi Vijay,
>
> Currently you may follow two ways in writing an LBaaS driver:
> 1) write it from scratch (like Radware, Netscaler, Embrane drivers) -
> in this case your driver should inherit 
> abstract_driver.LoadBalancerAbstractDriver
> and
> will be running on Neutron service process, LBaaS agent won't be used.
> So you should restart not q-lbaas but q-svc process in order for new
> driver to be used and it should work with the steps you've described.
>
> 2) leverage
> neutron/services/loadbalancer/drivers/common/agent_drive_base.py framework
> and in fact write only device driver which inheritits
>
> neutron.services.loadbalancer.agent.agent_device_driver.AgentDeviceDriver.
> This is how HAProxy driver is implemented, please see
> neutron/services/loadbalancer/drivers/haproxy/plugin_driver.py
> and namespace_driver.py (this is device driver).
> Along with updating service_provider in neutron.conf you should also
> add your device driver to lbaas_agent.ini file (again please check how it
> is done for haproxy)
> In this case your driver will be running on LBaaS agent and you should
> restart both q-svc and q-lbaas.
>
> Generally, the second approach is preferable as it's better scalable and
> provides you a built-in async mechanism.
>
> Thanks,
> Oleg
>
>
> On Wed, Apr 2, 2014 at 5:44 AM, Vijay B  wrote:
>
>> 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.LoadBalancerAbstractDriver):
>>
>> and has empty __init__(), create_vip(), delete_vip() etc functions.
>>
>>
>> 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
>>
>>
>>
>> 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
>>
>>
>>
>> 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,
>

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

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

[Vijay B]

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.LoadBalancerAbstractDriver):

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


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



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



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)


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]

[Vijay B]

Hi Oleg!

Thanks for the confirmation, and for the link to the services in service VM
blueprint link. I went through it and while the concept of using service
VMs is one way to go (cloudstack uses the approach, for example), I am not
inclined to take that approach for some reasons. Having a service image
essentially means forcing customers/deployers to either go with a specific
OS version or to maintain multiple formats (qcow/ova/vhd etc) for different
hypervisors. It will mean putting in packaging code into openstack to build
these VMs with every build. Upgradation from one Openstack release to the
next will sometime eventually force upgradation of these service VMs as
well. We will need to track service VM versions in glance or elsewhere and
prevent deployment across versions if required. Since we're talking about
VMs and not just modules, downtime also increases during upgrades. It adds
a whole level of complexity to handle all these scenarios, and we will need
to do that in Openstack code. I am very averse to doing that. Also as an
aside, when service VMs come into picture, deployment (depending on the
hypervisor) can take quite a long time (and scalability issues can be hit).
Take VMWare for example. We can create full or linked clones on it. Full
clone creation is quite costly in it. Storage migration is another area.
The issues will add up with time. From a developer's pov, debugging can get
tricky at times with service VMs.

The issues brought up in the blueprint are definitely valid and must be
addressed, but we'll need to have a discussion on what the optimal and
cleanest approach would be.

There is another interesting discussion going on regarding LBaaS APIs for
Libra and HAProxy between Susanne Balle/Eugene and others - I'll chip in
with my 2 cents on that..

Thanks a lot again!
Regards,
Vijay


On Tue, Mar 25, 2014 at 1:02 AM, Oleg Bondarev wrote:

> Hi Vijay,
> Currently Neutron LBaaS supports only namespace based implementation for
> HAProxy.
> You can however run LBaaS agent on the host other than network controller
> node - in that
> case HAProxy processes will be running on that host but still in
> namespaces.
>
> Also there is an effort in Neutron regarding adding support of advanced
> services in VMs [1].
> After it is completed I hope it will be possible to adopt it in LBaaS and
> run HAProxy in such a service VM.
>
> [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
>
> Thanks,
> Oleg
>
>
> On Tue, Mar 25, 2014 at 1:39 AM, Vijay B  wrote:
>
>> Hi Eugene,
>>
>> Thanks for the reply! How/where is the agent configuration done for
>> HAProxy? If I don't want to go with a network namespace based HAProxy
>> process, but want to deploy my own HAProxy instance on a host outside of
>> the network controller node, and make neutron deploy pools/VIPs on that
>> HAProxy instance, does neutron currently support this scenario? If so, what
>> are the configuration steps I will need to carry out to deploy HAProxy on a
>> separate host (for example, where do I specify the ip address of the
>> haproxy host, etc)?
>>
>> Regards,
>> Vijay
>>
>>
>> On Mon, Mar 24, 2014 at 2:04 PM, Eugene Nikanorov <
>> enikano...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> HAProxy driver has not removed from the trunk, instead it became a base
>>> for agent-based driver, so the only haproxy-specific thing in the plugin
>>> driver is device driver name. Namespace driver is a device driver on the
>>> agent side and it was there from the beginning.
>>> The reason for the change is mere refactoring: it seems that solutions
>>> that employ agents could share the same code with only device driver being
>>> specific.
>>>
>>> So, everything is in place, HAProxy continues to be the default
>>> implementation of Neutron LBaaS service. It supports spawning haproxy
>>> processes on any host that runs lbaas agent.
>>>
>>> Thanks,
>>> Eugene.
>>>
>>>
>>>
>>> On Tue, Mar 25, 2014 at 12:33 AM, Vijay B  wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm looking at HAProxy support in Neutron, and I observe that the
>>>> drivers/haproxy/plugin_driver.py file in the stable/havana release has been
>>>> effectively removed from trunk (master), in that the plugin driver in the
>>>> master simply points to the namespace driver. What was the reason to do
>>>> this? Was the plugin driver in havana tested and documented? I can't seem
>>>> to get hold of any relevant documentation that describes how to configur

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

[Vijay B]

Hi Eugene,

Thanks for the reply! How/where is the agent configuration done for
HAProxy? If I don't want to go with a network namespace based HAProxy
process, but want to deploy my own HAProxy instance on a host outside of
the network controller node, and make neutron deploy pools/VIPs on that
HAProxy instance, does neutron currently support this scenario? If so, what
are the configuration steps I will need to carry out to deploy HAProxy on a
separate host (for example, where do I specify the ip address of the
haproxy host, etc)?

Regards,
Vijay


On Mon, Mar 24, 2014 at 2:04 PM, Eugene Nikanorov
wrote:

> Hi,
>
> HAProxy driver has not removed from the trunk, instead it became a base
> for agent-based driver, so the only haproxy-specific thing in the plugin
> driver is device driver name. Namespace driver is a device driver on the
> agent side and it was there from the beginning.
> The reason for the change is mere refactoring: it seems that solutions
> that employ agents could share the same code with only device driver being
> specific.
>
> So, everything is in place, HAProxy continues to be the default
> implementation of Neutron LBaaS service. It supports spawning haproxy
> processes on any host that runs lbaas agent.
>
> Thanks,
> Eugene.
>
>
>
> On Tue, Mar 25, 2014 at 12:33 AM, Vijay B  wrote:
>
>> Hi,
>>
>> I'm looking at HAProxy support in Neutron, and I observe that the
>> drivers/haproxy/plugin_driver.py file in the stable/havana release has been
>> effectively removed from trunk (master), in that the plugin driver in the
>> master simply points to the namespace driver. What was the reason to do
>> this? Was the plugin driver in havana tested and documented? I can't seem
>> to get hold of any relevant documentation that describes how to configure
>> HAProxy LBs installed on separate boxes (and not brought up in network
>> namespaces) - can anyone please point me to the same?
>>
>> Also, are there any plans to bring back the HAProxy plugin driver to talk
>> to remote HAProxy instances?
>>
>> Thanks,
>> Regards,
>> Vijay
>>
>> ___
>> 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]

[Vijay B]

Hi,

I'm looking at HAProxy support in Neutron, and I observe that the
drivers/haproxy/plugin_driver.py file in the stable/havana release has been
effectively removed from trunk (master), in that the plugin driver in the
master simply points to the namespace driver. What was the reason to do
this? Was the plugin driver in havana tested and documented? I can't seem
to get hold of any relevant documentation that describes how to configure
HAProxy LBs installed on separate boxes (and not brought up in network
namespaces) - can anyone please point me to the same?

Also, are there any plans to bring back the HAProxy plugin driver to talk
to remote HAProxy instances?

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] No route matched for POST

[Vijay B]

Hi Aaron!

I was able to get over the route issue - to begin with, turns out there was
a nasty single space rogue indent in the file (peril of not using a good
IDE). Apart from that, stepping through the api/extensions.py code showed
that I shouldn't be overriding the get_plugin_interface() method in tag.py
- because I don't have a plugin associated with this, and would use the
current plugin. Also, there was an attributes variable I was using wrongly
- had imported it as attr and had to use that..

So the next steps for me would be to go ahead in implementing the logic to
check/write to the db. Hopefully I'll get that to work quicker.

Thanks a lot again!

Regards,
Vijay


On Tue, Mar 11, 2014 at 9:42 AM, Vijay B  wrote:

> Hi Aaron!
>
> Yes, attaching the code diffs of the client and server. The diff
> 0001-Frist-commit-to-add-tag-create-CLI.patch needs to be applied on
> python-neutronclient's master branch, and the diff
> 0001-Adding-a-tag-extension.patch needs to be applied on neutron's
> stable/havana branch. After restarting q-svc, please run the CLI `neutron
> tag-create --name tag1 --key key1 --value val1` to test it out.  Thanks for
> offering to take a look at this!
>
> Regards,
> Vijay
>
>
> On Mon, Mar 10, 2014 at 10:10 PM, Aaron Rosen wrote:
>
>> Hi Vijay,
>>
>> I think you'd have to post you're code for anyone to really help you.
>> Otherwise we'll just be taking shots in the dark.
>>
>> Best,
>>
>> Aaron
>>
>>
>> On Mon, Mar 10, 2014 at 7:22 PM, Vijay B  wrote:
>>
>>> Hi,
>>>
>>> I'm trying to implement a new extension API in neutron, but am running
>>> into a "No route matched for POST" on the neutron service.
>>>
>>> I have followed the instructions in the link
>>> https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions when
>>> trying to implement this extension.
>>>
>>> The extension doesn't depend on any plug in per se, akin to security
>>> groups.
>>>
>>> I have defined a new file in neutron/extensions/, called Tag.py, with a
>>> class Tag extending class extensions.ExtensionDescriptor, like the
>>> documentation requires. Much like many of the other extensions already
>>> implemented, I define my new extension as a dictionary, with fields like
>>> allow_post/allow_put etc, and then pass this to the controller. I still
>>> however run into a no route matched for POST error when I attempt to fire
>>> my CLI to create a tag. I also edited the ml2 plugin file
>>> neutron/plugins/ml2/plugin.py to add "tags" to
>>> _supported_extension_aliases, but that didn't resolve the issue.
>>>
>>> It looks like I'm missing something quite minor, causing the the new
>>> extension to not get registered, but I'm not sure what.
>>>
>>> I can provide more info/patches if anyone would like to take a look, and
>>> it would be very much appreciated if someone could help me out with this.
>>>
>>> Thanks!
>>> Regards,
>>> Vijay
>>>
>>> ___
>>> 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] No route matched for POST

[Vijay B]

Hi Aaron!

Yes, attaching the code diffs of the client and server. The diff
0001-Frist-commit-to-add-tag-create-CLI.patch needs to be applied on
python-neutronclient's master branch, and the diff
0001-Adding-a-tag-extension.patch needs to be applied on neutron's
stable/havana branch. After restarting q-svc, please run the CLI `neutron
tag-create --name tag1 --key key1 --value val1` to test it out.  Thanks for
offering to take a look at this!

Regards,
Vijay


On Mon, Mar 10, 2014 at 10:10 PM, Aaron Rosen  wrote:

> Hi Vijay,
>
> I think you'd have to post you're code for anyone to really help you.
> Otherwise we'll just be taking shots in the dark.
>
> Best,
>
> Aaron
>
>
> On Mon, Mar 10, 2014 at 7:22 PM, Vijay B  wrote:
>
>> Hi,
>>
>> I'm trying to implement a new extension API in neutron, but am running
>> into a "No route matched for POST" on the neutron service.
>>
>> I have followed the instructions in the link
>> https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions when
>> trying to implement this extension.
>>
>> The extension doesn't depend on any plug in per se, akin to security
>> groups.
>>
>> I have defined a new file in neutron/extensions/, called Tag.py, with a
>> class Tag extending class extensions.ExtensionDescriptor, like the
>> documentation requires. Much like many of the other extensions already
>> implemented, I define my new extension as a dictionary, with fields like
>> allow_post/allow_put etc, and then pass this to the controller. I still
>> however run into a no route matched for POST error when I attempt to fire
>> my CLI to create a tag. I also edited the ml2 plugin file
>> neutron/plugins/ml2/plugin.py to add "tags" to
>> _supported_extension_aliases, but that didn't resolve the issue.
>>
>> It looks like I'm missing something quite minor, causing the the new
>> extension to not get registered, but I'm not sure what.
>>
>> I can provide more info/patches if anyone would like to take a look, and
>> it would be very much appreciated if someone could help me out with this.
>>
>> Thanks!
>> Regards,
>> Vijay
>>
>> ___
>> 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
>
>


0001-Adding-a-tag-extension.patch
Description: Binary data


0001-Frist-commit-to-add-tag-create-CLI.patch
Description: Binary data
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] No route matched for POST

[Vijay B]

Hi,

I'm trying to implement a new extension API in neutron, but am running into
a "No route matched for POST" on the neutron service.

I have followed the instructions in the link
https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions when
trying to implement this extension.

The extension doesn't depend on any plug in per se, akin to security groups.

I have defined a new file in neutron/extensions/, called Tag.py, with a
class Tag extending class extensions.ExtensionDescriptor, like the
documentation requires. Much like many of the other extensions already
implemented, I define my new extension as a dictionary, with fields like
allow_post/allow_put etc, and then pass this to the controller. I still
however run into a no route matched for POST error when I attempt to fire
my CLI to create a tag. I also edited the ml2 plugin file
neutron/plugins/ml2/plugin.py to add "tags" to
_supported_extension_aliases, but that didn't resolve the issue.

It looks like I'm missing something quite minor, causing the the new
extension to not get registered, but I'm not sure what.

I can provide more info/patches if anyone would like to take a look, and it
would be very much appreciated if someone could help me out with this.

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

Re: [openstack-dev] [Openstack][Cinder] No IRC channel #openstack-cinder !!!

[Vijay Bellur]

On 01/02/2014 12:25 PM, Swapnil Kulkarni wrote:





Have you tried joining this channel on irc.freenode.net?


Regards,
Vijay


___
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

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

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

[openstack-dev] [Nova] Is there a way for the VM to identify that it is getting booted in OpenStack

[Vijay Venkatachalam]

Hi,
Is there a way for the VM to identify that it is getting booted 
in OpenStack?
As said in the below mail, once the VM knows it is booting in 
OpenStack it will alter the boot sequence.

AWS provides signatures in the BIOS strings.

PS:
Changed the title to be more friendly.

Thanks,
Vijay V.


From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Tuesday, November 26, 2013 8:58 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 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.org<mailto: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] [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.org<mailto: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

[openstack-dev] [Nova] Are BIOS strings configured in Hyper-V & ESX similar to KVM instantiated VMs?

[Vijay Venkatachalam]

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]

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

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]

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

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

[Vijay Venkatachalam]

Hi Eugene,

The proposal is simple, create a separate resource called 
certificate (which will also be handled by Neutron+LBaaS plugin) rather than 
having them in the VIP. It will maintain the original thought of security, the 
certificate confidential parameters will  be transient and the certificate will 
be directly sent to the device/driver and will not be stored. This is done by 
having VIP as a property in certificate.

Thanks,
Vijay V.

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, November 20, 2013 1:59 AM
To: Vijay Venkatachalam
Cc: Samuel Bercovici; Avishay Balderman; openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

Hi Vijay,

Thanks for working on this. As was discussed at the summit, immediate solution 
seems to be passing certificates via transient fields in Vip object, which will 
avoid the need for certificate management (incl. storing them).
If certificate management is concerned then I agree that it needs to be a 
separate specialized service.

> 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.
I think it's a little bit forward looking at this moment, also I think that 
certificates are not specific for load balancing.
Transient fields could help here too: client could pass certificate Id and 
driver of corresponding device will communicate with external service fetching 
corresponding certificate.

Thanks,
Eugene.

On Tue, Nov 19, 2013 at 5:48 PM, Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>> wrote:
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] [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] [Nova][Baremetal]: pxe image on hard disk

[Vijay]

Using baremetal provisioning, I was able to provision a physical server with an 
image. However, after I disconnected the server from openstack cluster and 
tried to boot the physical server with hard disk, it could not find the image. 
Is there a way to persist the pxe image on to the hard disk so that it could be 
used later by the server to boot from its hard disk?
Thanks,
-vj___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to skip certain unit tests?

[Vijay B]

Hi John, Rob,

Thanks for the pointers - I used skipTest() within the specific tests I
wanted to skip to get over the failing ones. Just an fyi, I'm working with
my own internal quantum staging gate on an older release, so I haven't
checked on the latest neutron master yet. In case I do find failures there,
will attempt to fix them and/or let the community know.

Cheers!
Regards,
Vijay


On Wed, Oct 30, 2013 at 7:46 PM, Robert Collins
wrote:

> On 31 October 2013 15:20, John Griffith 
> wrote:
>
> > Hi Vijay,
> >
> > Theoretically there should never be broken tests in master, that's
> > what the gates are for and if there are they should be fixed very
> > quickly.
> >
> > Back to your question, I don't know of a way to skip from
> > run_tests.sh, but there is a skip decorator that can be added to tests
> > in the code.  You can also specify specific tests to run.  Using
> > run_tests.sh (you can also do more sophisticated things with testr or
> > tox directly) you could do something like:
> > 'run_tests.sh cinder.tests.test_volumes' or more granular:
> > 'run_tests.sh
> cinder.tests.test_volume:VolumeTestCase.test_create_delete_volume
>
> For any project that has switched to testr, it should be simple - pass
> --  in.
>
> e.g. run_tests.sh -- (?!testnametoskip)
>
> Cheers,
> Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> 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