Open Stack

Hi Peter,

The "HTTPS" protocol described is end-to-end, the load balancer is not doing any SSL-offload here. So there still no need for cert management as we agreed in San Diego.

On adding "GET /protocols" , "GET /lb_methods" and "GET /algorithms" APIs, they were in the spec in the initial version :) I removed them after I revised the spec to include feedback, because to be complete we would also need to list the session persistence modes supported, the types of health monitors supported, etc. Where would we stop? I felt that is what the spec doc is for: to specify what the core API supports. If extensions support additional protocols, algorithms, session persistence modes, new type of health monitors, etc. then they would need to document these.

This goes back to your initial point about a schema for the API. How do I discover the extensions supported by an API without reading some doc. I feel the solution is not to add calls like /protocols to compensate for the lack of schemas. I don't know how other OpenStack APIs deal with this.

Youcef

From: Mellquist, Peter [mailto:peter.mellquist at hp.com]
Sent: Friday, November 09, 2012 2:51 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Quantum LBaaS API HTTPS support

In the current LBaaS API spec, http://wiki.openstack.org/Quantum/LBaaS/API_1.0, I noticed that there are examples of vips with HTTPS specified as the protocol.

{
  "vips":[
         {
           "id": "02b1fef7-16f5-4917-bf19-c40a9af805ed",
           "tenant_id": "310df60f-2a10-4ee5-9554-98393092194c",
           "name": "web_vip",
           "network_id": "96a4386a-f8c3-42ed-afce-d7954eee77b3",
           "address" : "10.30.176.47",
           "protocol": "HTTPS",
           "port": 443,
           "pool_id" : "cfc6589d-f949-4c66-99d2-c2da56ef3764",
           "session_persistence" : {"type":"APP_COOKIE", "cookie_name":"jsessionid"},
           "admin_state_up": true,
           "status": "PENDING_CREATE"
         }
      ]
}


Is the plan to add certificate management APIs to support this?  In San Diego, I recall hearing we would only go after HTTP and TCP to begin with and hold on HTTPS and cert mgmt but perhaps this is no longer the case ?

What about adding a /protocols resource to advertise all supported protocols ( HTTP, TCP, etc )? This would help tenants to  see what is supported and only use these in the vip creation. To think of it,  /lb_methods ( a.k.a. /algorithms ) would also make sense.

Peter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121109/13084d27/attachment.html>