Open Stack

Hi Stephen,

My comments inline:


On Tue, Feb 25, 2014 at 6:07 AM, Stephen Balukoff <sbalukoff at bluebox.net>wrote:

> Hi y'all,
>
> Jay, in the L7 example you give, it looks like you're setting SSL
> parameters for a given load balancer front-end. Do you have an example you
> can share where where certain traffic is sent to one set of back-end nodes,
> and other traffic is sent to a different set of back-end nodes based on the
> URL in the client request? (I'm trying to understand how this can work
> without the concept of 'pools'.)  Also, what if the first group of nodes
> needs a different health check run against it than the second group of
> nodes?
>
Obviously any kind of loadbalancer API need to have a concept of 'pool' if
we want to go beyond single group of nodes.
So the API that is convenient at first glance will need to introduce all
those concepts that we already have.


> As far as hiding implementation details from the user:  To a certain
> degree I agree with this, and to a certain degree I do not: OpenStack is a
> cloud OS fulfilling the needs of supplying IaaS. It is not a PaaS. As such,
> the objects that users deal with largely are analogous to physical pieces
> of hardware that make up a cluster, albeit these are virtualized or
> conceptualized. Users can then use these conceptual components of a cluster
> to build the (virtual) infrastructure they need to support whatever
> application they want. These objects have attributes and are expected to
> act in a certain way, which again, are usually analogous to actual hardware.
>
I'm really not sure what Mark McClain on some other folks see as
implementation details. To me the 'instance' concept is as logical as
others (vips/pool/etc). But anyway, it looks like majority of those who
discuss, sees it as redundant concept.


> If we were building a PaaS, the story would be a lot different--  but what
> we are building is a cloud OS that provides Infrastructure (as a service).
>
> I think the concept of a 'load balancer' or 'load balancer service' is one
> of these building blocks that has attributes and is expected to act in a
> certain way. (Much the same way cinder provides "block devices" or swift
> provides an "object store.") And yes, while you can do away with a lot of
> the implementation details and use a very simple model for the simplest use
> case, there are a whole lot of load balancer use cases more complicated
> than that which don't work with the current model (or even a small
> alteration to the current model). If you don't allow for these more
> complicated use cases, you end up with users stacking home-built software
> load balancers behind the cloud OS load balancers in order to get the
> features they actually need. (I understand this is a very common topology
> with ELB, because ELB simply isn't capable of doing advanced things, from
> the user's perspective.) In my opinion, we should be looking well beyond
> what ELB can do.
>
Agree on ELB. Existing public APIs (ELB/Libra) are not much better in terms
of feature coverage, than what we have already.


> :P Ideally, almost all users should not have to hack together their own
> load balancer because the cloud OS load balancer can't do what they need it
> to do.
>
Totally agree.


>
> Also, from a cloud administrator's point of view, the cloud OS needs to be
> aware of all the actual hardware components, virtual components, and other
> logical constructs that make up the cloud in order to be able to
> effectively maintain it.
>
Agree, however actual hardware is beyond logical LBaaS API but could be a
part of admin LBaaS API.


> Again, almost all the details of this should be hidden from the user. But
> these details must not be hidden from the cloud administrator. This means
> implementation details will be represented somehow, and will be visible to
> the cloud administrator.
> Yes, the focus needs to be on making the user's experience as simple as
> possible. But we shouldn't sacrifice powerful capabilities for a simpler
> experience. And if we ignore the needs of the cloud administrator, then we
> end up with a cloud that is next to impossible to practically administer.
>
> Do y'all disagree with this, and if so, could you please share your
> reasoning?
>
Personally I agree, that was always a priority to accommodate API for
simple and advanced scenarios.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/41b6daab/attachment.html>