[openstack-dev] [neutron][lbaas] Health Monitor association with pool

2015-01-19 Thread Shreshtha Joshi
Hi,

The openstack documentation for LBaaS Neutron v2 APIs does not clearly define 
way to associate a HealthMonitor with a pool.
Will it be done via pool update - put method at "/v2.0/pools/{pool_id}".
Or it will be done via post method at "/v2.0/lb/pools/{pool_id}/health_monitors"
Any other link detailing LBaaS v2 APIs will be great help.
Thanks in advance. 

Regards
Shreshtha Joshi

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
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] Querries Regarding Blueprint for LBaaS API and Object Model improvement

2014-12-16 Thread Shreshtha Joshi
Thanks Doug.

Regards
Shreshtha Joshi

-Doug Wiegley  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: Doug Wiegley 
Date: 12/17/2014 11:15AM
Cc: "johnbrandonlo...@gmail.com" , Deepankar Gupta 
, Partha Datta 
Subject: Re: [openstack-dev] [neutron][lbaas] Querries Regarding Blueprint for 
LBaaS API and Object Model improvement

Adding tags for [neutron][lbaas]

Juno lbaas (v1) has pool as the root model, with VIP.

Kilo lbaas (v2), you are correct, vip is splitting into loadbalancer and 
listener, and loadbalancer is the root object. And yes, the new objects get new 
URIs.

Both v1 and v2 plugins will be available in Kilo.

Thanks,
doug

From: Shreshtha Joshi 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, December 16, 2014 at 9:36 PM
To: "openstack-dev@lists.openstack.org" 
Cc: Partha Datta , Deepankar Gupta 
, "johnbrandonlo...@gmail.com" 

Subject: [openstack-dev] Querries Regarding Blueprint for LBaaS API and Object 
Model improvement

Hi All,

I wanted to know the approach has been followed for LBaaS implementation in 
Openstack (juno) out of the following in the 
link(https://etherpad.openstack.org/p/neutron-lbaas-api-proposals). Is it-
Existing Core Resource Model
LoadBalancer Instance Model
Vip-Centric Model
Currently I find Pool as the root object that has a VIP associated with it 
rather than Listeners and LoadBalancers in various openstack documents.

But while investigating the same, I came across a blueprint 
(https://blueprints.launchpad.net/neutron/+spec/lbaas-api-and-objmodel-improvement)
 for LBaaS Api and object model improvement. It talks about moving the current 
VIP object to Listener and Listener will be linked to a LoadBalancer in the 
upcoming releases,

I wanted to know the current approach followed for openstack-juno and if in the 
upcoming releases(Kilo)-
 Are we planning to have new APIs for /Listener and /Loader and there will be 
no VIP object and its corresponding API.
 Or we will be having VIP object and its corresponding API, creation of which 
will result in creation of Loadbalancer and /Listener at the backend itself.
If you find the above investigation incorrect, please feel free to point to the 
right direction.


Thanks & Regards
Shreshtha Joshi
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

___
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] Querries Regarding Blueprint for LBaaS API and Object Model improvement

2014-12-16 Thread Shreshtha Joshi
Hi All,

I wanted to know the approach has been followed for LBaaS implementation in 
Openstack (juno) out of the following in the 
link(https://etherpad.openstack.org/p/neutron-lbaas-api-proposals). Is it-
Existing Core Resource Model
LoadBalancer Instance Model
Vip-Centric Model
Currently I find Pool as the root object that has a VIP associated with it 
rather than Listeners and LoadBalancers in various openstack documents.

But while investigating the same, I came across a blueprint 
(https://blueprints.launchpad.net/neutron/+spec/lbaas-api-and-objmodel-improvement)
 for LBaaS Api and object model improvement. It talks about moving the current 
VIP object to Listener and Listener will be linked to a LoadBalancer in the 
upcoming releases,

I wanted to know the current approach followed for openstack-juno and if in the 
upcoming releases(Kilo)-
 Are we planning to have new APIs for /Listener and /Loader and there will be 
no VIP object and its corresponding API.
 Or we will be having VIP object and its corresponding API, creation of which 
will result in creation of Loadbalancer and /Listener at the backend itself.
If you find the above investigation incorrect, please feel free to point to the 
right direction.


Thanks & Regards
Shreshtha Joshi
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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