Open Stack

Hi Sam,

I've looked over the document, couple of notes:

1) In order to allow real multiple 'vips' per pool feature, we need the
listener concept.
It's not just a different tcp port, but also a protocol, so session
persistence and all ssl-related parameters should move to listener.

2) ProviderResourceAssociation - remains on the instance object (our
instance object is VIP) as a relation attribute.
Though it is removed from public API, so it could not be specified on
creation.
Remember provider is needed for REST call dispatching. The value of
provider attribute (e.g. ProviderResourceAssociation) is result of
scheduling.

3) As we discussed before, pool->vip relation will be removed, but pool
reuse by different vips (e.g. different backends) will be forbidden for
implementation simplicity, because this is definitely not a priority right
now.
I think it's a fair limitation that can be removed later.

On workflows:
WFs #2 and #3 are problematic. First off, sharing the same IP is not
possible for other vip for the following reason:
vip is created (with new model) with flavor (or provider) and scheduled to
a provider (and then to a particular backend), doing so for 2 vips makes
address reuse impossible if we want to maintain logical API, or otherwise
we would need to expose implementation details that will allow us to
connect two vips to the same backend.

On the open discussion questions:
I think most of them are resolved by following existing API expectations
about status fields, etc.
Main thing that allows to go with existing API expectations is the notion
of 'root object'.
Root object is the object which status and admin_state show real
operability of the configuration. While from implementation perspective it
is a mounting point between logical config and the backend.

The real challenge of model #3 is ability to share pools between different
VIPs, e.g. between different flavors/providers/backends.
User may be unaware of it, but it requires really complex logic to handle
statistics, healthchecks, etc.
I think while me may leave this ability at object model and API level, we
will limit it, as I said previously.

Thanks,
Eugene.



On Wed, Feb 26, 2014 at 9:06 PM, Samuel Bercovici <SamuelB at radware.com>wrote:

>  Hi,
>
>
>
> I have added to the wiki page:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_modelthat 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:mmcclain at yahoo-inc.com<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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/7267f6b8/attachment.html>