Mailing-List: contact dev-help@stratos.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stratos.incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sanjiva@wso2.com designates
 209.85.223.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+-yGgmA+PVuMgsBo=wMP+6js5-KW=j5T7hzuTC5fvkRMfuhyQ@mail.gmail.com>
References: 
 <CAKyVFMGmLmXabr38_9VLN92qPP4BMAACRACELHPp+5Q0rJDoPg@mail.gmail.com>
 <CA+-yGgmA+PVuMgsBo=wMP+6js5-KW=j5T7hzuTC5fvkRMfuhyQ@mail.gmail.com>
From: Sanjiva Weerawarana <sanjiva@wso2.com>
Date: Fri, 11 Oct 2013 11:27:01 +0530
Message-ID: 
 <CAKyVFMH3Fj5NzzJOMUrwopV5POVRpispip3uWK_L9y1CoO2hmA@mail.gmail.com>
Subject: Re: proposed architectural changes to Stratos
To: dev <dev@stratos.incubator.apache.org>
Content-Type: multipart/alternative; boundary=089e013c6e4ab8a41504e870ca04

--089e013c6e4ab8a41504e870ca04
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 11, 2013 at 10:23 AM, Nirmal Fernando <nirmal070125@gmail.com>wrote:

> +1 for the new design.
>
> A question:
>
> How can we handle multiple load balancer scenario where one load balancer
> would not interested in all the clusters but a set of selected ones? I
> suggest we go for a hierarchical topic concept, instead of one single
> topology topic.
>

Are you suggesting some topic hierarchy which recognizes the actual LB
type? I don't like that because that couples the CC to LB types. My
preference is a model where all LBs get all updates and they decide what
they care about and do something about those.

>
>>    - Traffic comes in thru any load balancer (e.g. HAProxy for non-HTTP
>>    traffic and our LB for HTTP traffic). LB routes based on its configuration
>>    which is periodically updated by the Cloud Controller via topology update
>>    messages.
>>
>> IMO we should send topology messages periodically (even there's no
> change), so that LB can get the current status of the system, even after a
> restart.
>

Yeah to handle fresh LBs we either need to have a periodic update going out
or have a way for the LB to contact the CC and get the latest config. I
prefer the latter because that's a bit like ADC being used to config a
fresh instance. In fact, going forward we could even auto scale LBs .. but
that's a bit far fetched as it requires possibly doing DNS updates too. But
its not that hard.

Sanjiva.
-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
email: sanjiva@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/

Lean . Enterprise . Middleware

--089e013c6e4ab8a41504e870ca04
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Oct 11, 2013 at 10:23 AM, Nirmal Fernando <span di=
r=3D"ltr">&lt;<a href=3D"mailto:nirmal070125@gmail.com" target=3D"_blank">n=
irmal070125@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>+1 for the new design.=
 <br><br>A question:<br><br></div>How can we handle multiple load balancer =
scenario where one load balancer would not interested in all the clusters b=
ut a set of selected ones? I suggest we go for a hierarchical topic concept=
, instead of one single topology topic.<br>

</div></blockquote><div><br></div><div>Are you suggesting some topic hierar=
chy which recognizes the actual LB type? I don&#39;t like that because that=
 couples the CC to LB types. My preference is a model where all LBs get all=
 updates and they decide what they care about and do something about those.=
=A0</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

<div dir=3D"ltr">


<div><ul><li>Traffic comes in thru any load balancer (e.g. HAProxy for non-=
HTTP traffic and our LB for HTTP traffic). LB routes based on its configura=
tion which is periodically updated by the Cloud Controller via topology upd=
ate messages.</li>


</ul></div></div></blockquote></div><div>IMO we should send topology messag=
es periodically (even there&#39;s no change), so that LB can get the curren=
t status of the system, even after a restart. <br></div></div></div></div>

</blockquote><div><br></div><div>Yeah to handle fresh LBs we either need to=
 have a periodic update going out or have a way for the LB to contact the C=
C and get the latest config. I prefer the latter because that&#39;s a bit l=
ike ADC being used to config a fresh instance. In fact, going forward we co=
uld even auto scale LBs .. but that&#39;s a bit far fetched as it requires =
possibly doing DNS updates too. But its not that hard.</div>

<div><br></div><div>Sanjiva.</div></div>-- <br><div dir=3D"ltr">Sanjiva Wee=
rawarana, Ph.D.<br>Founder, Chairman &amp; CEO; WSO2, Inc.;=A0 <a href=3D"h=
ttp://wso2.com/" target=3D"_blank">http://wso2.com/</a><br>email: <a href=
=3D"mailto:sanjiva@wso2.com" target=3D"_blank">sanjiva@wso2.com</a><span>; =
phone: +94 11 763 9614; cell: +94 77 787 6880 | <span id=3D"gc-number-30" c=
lass=3D"gc-cs-link" title=3D"Call with Google Voice">+1 650 265 8311</span>=
</span><br>

blog: <a href=3D"http://sanjiva.weerawarana.org/" target=3D"_blank">http://=
sanjiva.weerawarana.org/</a><br><br>Lean . Enterprise . Middleware</div>
</div></div>

--089e013c6e4ab8a41504e870ca04--