Hi Supun, I scheduled an arch review for this on Coming friday.
Few Qs a) If two guys are editing the configurations and save it at the same time, what do we do? I guess that is way you asked for a master? b) What do we do if applying a update in a node failed due to some reason? c) What happen to the message in transits while changes to the config is being applied? I do not think we have to handle this in too much details. But we have to know what going on and it is a likely Q from customers when you mention this feature. Thanks Srinath On Mon, Dec 6, 2010 at 6:32 AM, Sanjiva Weerawarana <[email protected]> wrote: > +1 Supun but it seems to me we need to involve the load balancer in order to > achieve this. We have to sort this out for Stratos' load balancer anyway as > its critical to allow one tenant to upgrade something (for possibly just a > few users) instead of forcing a global update. > Sanjiva. > > On Sun, Dec 5, 2010 at 6:20 PM, Supun Kamburugamuva <[email protected]> wrote: >> >> I think we need a feature from registry based repo for doing this >> successfully in a real production scenario. >> In a production scenarion if there is a cluster of ESB's user don't want >> to take down all the ESB's or update all the ESB's at the same time. Usually >> when a change is made it is done in only one node. Then that node stays like >> that for few days to make sure that the change is ok. During this time the >> other nodes should act as previously. So for a production deployment we >> shouldn't do automatic repository syncs for all the nodes by default. >> User should be able to select when to sync with the registry repo. We can >> provide an UI for doing this. >> Here are the steps I think a user should follow to do a update in a >> cluster. >> 1. First user has to take the master node off the traffic and update the >> master node. >> 3. After he thinks that the configuration is ok, enable the registry sync >> in master node so that the registry is updated. >> 2. Now when user want to do the change for a another ESB he has to take >> that ESB out of traffic from load balancer and enable the registry sync. >> This will update the configuration of that node. >> Like wise user can do a successful configuration update without restarting >> any of the machines. >> Thanks, >> Supun.. >> >> On Sun, Dec 5, 2010 at 12:11 AM, Hiranya Jayathilaka <[email protected]> >> wrote: >>> >>> >>> On Sat, Dec 4, 2010 at 10:41 PM, Senaka Fernando <[email protected]> wrote: >>>> >>>> >>>> On Sat, Dec 4, 2010 at 10:09 PM, Ruwan Linton <[email protected]> wrote: >>>>> >>>>> On 12/4/10 8:54 PM, Supun Kamburugamuva wrote: >>>>> >>>>> On Sat, Dec 4, 2010 at 5:45 PM, Sanjiva Weerawarana <[email protected]> >>>>> wrote: >>>>>> >>>>>> On Sat, Dec 4, 2010 at 2:45 PM, Supun Kamburugamuva <[email protected]> >>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>> The registry based repo, when enabled syncs the >>>>>>> axis2 repository periodically. Basically it syncs what ever files that >>>>>>> are >>>>>>> in the axis2 repository of a cluster of servers that are connected to a >>>>>>> single configuration registry. It stores the files in to the registry >>>>>>> and >>>>>>> then sync the file from there. Now we have moved the synapse >>>>>>> configuration >>>>>>> to the axis2 repository as well. So when a synapse configuration file is >>>>>>> modified the changes will be synched across the cluster. Because we >>>>>>> have hot >>>>>>> update these changes will immediately taken in to account without >>>>>>> requiring >>>>>>> a restart of the read-only nodes. >>>>>> >>>>>> Are we going to allow any node's config to be edited and have that >>>>>> sync across all nodes or do we still have a master node concept? >>>>> >>>>> I think we should allow only the master node to be changed. There are >>>>> some part of the configuration that doesn't work without this mode. For >>>>> example we store things like security policy information about a service >>>>> in >>>>> the registry. So in-order for these things to work user has to always >>>>> change >>>>> the master node. >>>>> >>>>> Why? >>>> >>>> I see Master-node as a concept that we've introduced to overcome some of >>>> the limitations we had in the past. If this model works, and if this is >>>> expected to scale, we should not have a concept of a master-node in this >>>> sense, as Ruwan points out. Somebody, needs to be the source of control, so >>>> in that sense we could have a master. >>> >>> +1 and +1 to disabling registry persistence for Synapse configuration. >>> With the new model old registry persistence becomes obsolete really. >>> Thanks, >>> Hiranya >>> >>>> >>>> Thanks, >>>> Senaka. >>>> >>>>> >>>>> Any explanation why those changes has to be on the master node, what is >>>>> special about the master node apart from the fact that it controls the >>>>> configuration? >>>>> >>>>> Ruwan >>>>> >>>>> Thanks, >>>>> Supun.. >>>>> >>>>>> >>>>>> I think we have some issues in Stratos because the registry repo is >>>>>> synced on a timer. IIRC we discussed changing that to use registry >>>>>> eventing >>>>>> to notify the subscribers and they'll pull the changes in. Have we >>>>>> implemented that? >>>>>> We need to avoid getting into a change loop as a result too .. but >>>>>> we've dealt with that at a customer setup a while ago. >>>>>> Sanjiva. >>>>>> -- >>>>>> Sanjiva Weerawarana, Ph.D. >>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>>> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 >>>>>> | +1 650 265 8311 >>>>>> blog: http://sanjiva.weerawarana.org/ >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> _______________________________________________ >>>>>> Carbon-dev mailing list >>>>>> [email protected] >>>>>> https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Supun Kamburugamuva >>>>> Technical Lead >>>>> WSO2 Inc.; http://wso2.org >>>>> E-mail: [email protected]; Mobile: +94 77 431 3585 >>>>> Blog: http://supunk.blogspot.com >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> [email protected] >>>>> https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>>> >>>>> -- >>>>> Ruwan Linton >>>>> Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb >>>>> WSO2 Inc.; http://wso2.com >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>>> phone: +1 408 754 7388 ext 51789 >>>>> email: [email protected]; cell: +94 77 341 3097 >>>>> blog: http://blog.ruwan.org >>>>> linkedin: http://www.linkedin.com/in/ruwanlinton >>>>> tweet: http://twitter.com/ruwanlinton >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> [email protected] >>>>> https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Senaka Fernando >>>> Associate Technical Lead & Product Manager - WSO2 G-Reg; >>>> WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://apache.org >>>> >>>> E-mail: senaka AT wso2.com >>>> P: +1 408 754 7388; ext: 51736; >>>> M: +94 77 322 1818 >>>> Linked-In: http://www.linkedin.com/in/senakafernando >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> [email protected] >>>> https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>> >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Senior Software Engineer; >>> WSO2 Inc.; http://wso2.org >>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>> Blog: http://techfeast-hiranya.blogspot.com >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >> >> >> >> -- >> Supun Kamburugamuva >> Technical Lead >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 431 3585 >> Blog: http://supunk.blogspot.com >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ > email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 > 650 265 8311 > blog: http://sanjiva.weerawarana.org/ > > Lean . Enterprise . Middleware > > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- ============================ Srinath Perera, Ph.D. Senior Software Architect, WSO2 Inc. Visiting Lecturer, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ _______________________________________________ Carbon-dev mailing list [email protected] https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev
