Open Stack

Folks,

So far everyone agrees that the model should be pure logical, but no one
came up with the API and meaningful implementation details (at least at
idea level) of such obj model.
As I've pointed out, 'pure logical' object model has some API and user
experience inconsistencies that we need to sort out before we implement it.
I'd like to see real details proposed for such 'pure logical' object model.

Let's also consider the cost of the change - it's easier to do it gradually
than rewrite it from scratch.

Thanks,
Eugene.



On Mon, Feb 24, 2014 at 9:36 PM, Samuel Bercovici <SamuelB at radware.com>wrote:

>  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:mmcclain at 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 <jaypipes at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140224/b9a8279f/attachment.html>