On Mon, Oct 27, 2008 at 8:00 PM, Sangeeta Misra <[EMAIL PROTECTED]> wrote:
> On 10/27/08 12:50, Peter Tribble wrote:
>
> On Fri, Oct 24, 2008 at 10:25 PM, Sangeeta Misra <[EMAIL PROTECTED]>
> wrote:
>
>
> Folks,
>
> We have  posted Rev 1.0 of  ILB  design doc at
> http://opensolaris.org/os/project/vnm/ILB . Although this is not the
> final version, I urge folks to take a look at it and provide their
> input. Also if you are interested in the project please subscibe to the
> project mail alias
>
>
>
>
> Peter
>
> 1. We use cookie based load-balancing, and find it far more useful than the
> LB
> algorithms mentioned. Any chance of adding it?
>
>
> 7. I would like to see smarter draining - normally in conjunction with
> cookie-based
> load balancing (see my comment on section 1). Basically we have lots
> of different
> sessions coming in from the same IP address (because lots of users sit
> behind
> the same proxy server).
>
>
>
> The Phase 1 delivery of ILB project is limited to Layer 3 and 4 load
> balancing. Thus we are not planning providing cookie based loadbalancing or
> connection draining techniques in this phase.

Thanks.

> 4. You say regular users can view configuration and statistics. I
> would expect to be
> able to restrict that, as I wouldn't always want all users to be able
> to view everything.
>
>
> Are you suggesting the the default could be regular users unless the admin
> customizes is otherwise? Can you explain why you would want to restrict
> viewing?

Michael asked the same question. It's a good one. But I have to confess that
I was taken aback by the idea that anyone on the machine could view
everything. I'm happy for that to be the default, but would like the
capability for tighter control. One case I have is where a machine provides
services to different units - different units shouldn't be able to see
each other's
data or configuration.

> 5. Can you expand the rules a little. I assume that ping just verifies
> that the address
> is reachable; tcp checks that the port will accept a connection? Given
> that a primary
> use case is for web servers, why not have HTTP as a builtin health
> check? I wouldn't
> expect evry user to have to write their own health checks.
>
>
>
>
> We will consider providing  HTTP as a builtin healthcheck as a RFE post
> Phase 1 delivery.

OK, thanks.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to