Vijay, I'm following suit: Replies in line :D On Thu, 2014-05-01 at 16:11 +0000, Vijay Venkatachalam wrote: > Thanks Trevor. Replies inline! > > > -----Original Message----- > > From: Trevor Vardeman [mailto:[email protected]] > > Sent: Thursday, May 1, 2014 7:30 PM > > To: [email protected] > > 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 +0000, 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)?
This is already reflected in at least one use-case. I've been documenting the "solutions" so to speak to many of the use cases with regards to the Rackspace API proposal, if you'd like to see some of those examples (keep in mind they are a WIP) I'll provide a link to them for you: https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0 > > > > > > > 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. For this API proposal, we wanted to enforce the updating of properties as single requests to the resource, where the POST context includes creations/attachments of resources to one another. To update a pool/its members you would use the "/pools" or "/pools/{pool_id}/members" endpoints accordingly. Also a POST to "/loadbalancers/{loadbalancer_id}/pools" will create/attach a pool to the Load Balancer, however PUT would not be supported at this endpoint. > > 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? Following the concept of the "Neutron port" in essence "detaching" rather than removing the references has us leaving the extra pieces intact but disconnected from a Load Balancer. One would delete the Load Balancer, and still be able to retrieve the VIP or Pool from their root-resource references. This would allow someone the ability to delete a specific Load Balancer, and then create an entirely new one while referencing the original pool and VIP. > > > > > > > Thanks, > > > Vijay V. > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
