Hi,
In
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=sharing
referenced by the Wiki, I have added the section that address the items raised
on the last irc meeting.
Regards,
-Sam.
From: Samuel Bercovici
Sent: Wednesday, February 26, 2014 7:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici; Eugene Nikanorov (enikano...@mirantis.com); Evgeny
Fedoruk; Avishay Balderman
Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion
Hi,
I have added to the wiki page:
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_model
that points to a document that includes the current model + L7 + SSL.
Please review.
Regards,
-Sam.
From: Samuel Bercovici
Sent: Monday, February 24, 2014 7:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion
Hi,
I also agree that the model should be pure logical.
I think that the existing model is almost correct but the pool should be made
pure logical. This means that the vip <---->pool relationships needs also to
become any to any.
Eugene, has rightfully pointed that the current "state" management will not
handle such relationship well.
To me this means that the "state" management is broken and not the model.
I will propose an update to the state management in the next few days.
Regards,
-Sam.
From: Mark McClain [mailto:mmccl...@yahoo-inc.com]
Sent: Monday, February 24, 2014 6:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion
On Feb 21, 2014, at 1:29 PM, Jay Pipes
<jaypi...@gmail.com<mailto:jaypi...@gmail.com>> wrote:
I disagree on this point. I believe that the more implementation details
bleed into the API, the harder the API is to evolve and improve, and the
less flexible the API becomes.
I'd personally love to see the next version of the LBaaS API be a
complete breakaway from any implementation specifics and refocus itself
to be a control plane API that is written from the perspective of the
*user* of a load balancing service, not the perspective of developers of
load balancer products.
I agree with Jay. We the API needs to be user centric and free of
implementation details. One of my concerns I've voiced in some of the IRC
discussions is that too many implementation details are exposed to the user.
mark
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
