And the article from Senaka which serves as the almanac of registry sharing :) - http://wso2.org/library/tutorials/2010/04/sharing-registry-space-across-multiple-product-instances
Setting up a cluster of same products is discussed under strategy-B. Again it speaks of the master-slave model. No mention of LB for UIs. Thanks, Hiranya On Sat, Apr 21, 2012 at 1:01 PM, Hiranya Jayathilaka <[email protected]>wrote: > Charitha has written a good blog post about Carbon clustering model and > how the synchronizer UI is used in that context - > http://charithaka.blogspot.com/2011/11/wso2-deployment-synchronizer-sharing.html > > This is the use case we have modeled the UI after. UI level LB and the > possibility of admin requests getting dispatched any of the available nodes > are not a part of that. > > Thanks, > Hiranya > > > On Sat, Apr 21, 2012 at 12:56 PM, Hiranya Jayathilaka <[email protected]>wrote: > >> >> >> On Sat, Apr 21, 2012 at 12:48 PM, Afkham Azeez <[email protected]> wrote: >> >>> >>> >>> On Sat, Apr 21, 2012 at 12:42 PM, Hiranya Jayathilaka >>> <[email protected]>wrote: >>> >>>> >>>> >>>> On Sat, Apr 21, 2012 at 12:22 PM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Apr 21, 2012 at 12:13 PM, Hiranya Jayathilaka < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 20, 2012 at 7:34 PM, Afkham Azeez <[email protected]> wrote: >>>>>> >>>>>>> Some problems. >>>>>>> >>>>>>> 1. org.wso2.carbon.deployment.synchronizer.subversion bundle is >>>>>>> missing >>>>>>> 2. svnclient bundle is missing >>>>>>> 3. If you configure once using the UI, all your subsequent changes >>>>>>> to carbon.xml will be ignored >>>>>>> >>>>>> >>>>>> Right. You should use one way of configuring this feature. We don't >>>>>> sync configurations from file system to the registry due to the 2-way >>>>>> sync >>>>>> problem.Settings in the registry have priority. >>>>>> >>>>>> >>>>>>> 4. UI configurations are stored in local repository. So, if your >>>>>>> cluster has several nodes, you will have to make changes to all nodes >>>>>>> one >>>>>>> by one.\ >>>>>>> >>>>>> >>>>>> That's right. This is because within a single cluster some nodes will >>>>>> be in auto checkout mode and some nodes (usually one) will be in auto >>>>>> commit mode. We used to store these settings in config registry about a >>>>>> year ago, but with that we cannot use this component to actually >>>>>> configure >>>>>> a useful clustered setup. That way either everyone will be in auto commit >>>>>> mode or everyone will be in auto checkout mode. So we moved the settings >>>>>> to >>>>>> the local repo. It's a per node setting. >>>>>> >>>>> >>>>> Which make this configuration useless because, in a proper clustered >>>>> deployment, we will not be able to control to which node the admin logs >>>>> in. >>>>> >>>> In addition, in the future, the plan is to have a couple of management >>>>> nodes, which will have the management console, and then a set of worker >>>>> nodes. The management nodes are used for configuring the worker cluster. >>>>> So, if this configuration only gets saved into the local registry of the >>>>> management node, things won't work as expected. >>>>> >>>> >>>> Your argument is valid in case of a cloud deployment. But for a small >>>> in-house deployment that doesn't make any >>>> >>> sense. In an in-house clustered deployment we designate one node as the >>>> master read-write node. >>>> >>> >>> We are not planning to have one solution for Stratos deployments while >>> making different recommendations to the customer. In the future, we plan to >>> promote having management nodes & worker nodes separated, just like we plan >>> to do in StratosLive. >>> >>> Also when a set of nodes is backed by an LB, and all accesses are >>> through that LB, how do you control to which node the request is forwarded >>> to, when you are configuring the synchronizer? On the read-write node the >>> synchronizer has to be configured to commit, while in the read-only node it >>> has to be configured to update only. How do you do that when the entire >>> cluster is fronted by an LB? >>> >> >> Azeez, our current clustering model does not say anything about fronting >> all the UIs from a single LB. We simply ask to setup one node as the master >> (read-write) and everything else as slaves (read-only). All configuration >> changes should be performed through the read-write node only. This has been >> our documented clustering model for enterprise users since Carbon 1.5 >> days (Charitha, correct me if I'm wrong). The deployment sync UI is modeled >> after that. That makes it easier for someone who's setting up a cluster >> according to our guidelines, to setup cluster-wide automatic replication of >> artifacts. >> >> Now if we change our clustering model to front all the admin consoles >> from a single LB then obviously the current UI component won't work. In >> that scenario I don't think we can use our existing documented master-slave >> model anymore. So the UI needs to be redesigned for that case. >> >> Thanks, >> Hiranya >> >> >>> >>> >>>> That's where admins login and make all the config changes. The >>>> synchronizer replicates them to other slave (read-only) nodes. This is how >>>> our enterprise users use this feature. We have documentation explaining the >>>> process too - >>>> http://wso2.org/project/esb/java/4.0.3/docs/deployment_guide.html >>>> >>>> In case of a Stratos, we don't ship the UI component. It's not made to >>>> be used in a scenario like that. >>>> >>>> Thanks, >>>> Hiranya >>>> >>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Hiranya >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 20, 2012 at 6:53 PM, Afkham Azeez <[email protected]>wrote: >>>>>>> >>>>>>>> Folks, >>>>>>>> Has anybody tested this with the new packs? >>>>>>>> >>>>>>>> -- >>>>>>>> *Afkham Azeez* >>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>> * <http://www.apache.org/>** >>>>>>>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>>>>>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>>>>>>> twitter: >>>>>>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>>>>>>> * >>>>>>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>>>>>>> * >>>>>>>> * >>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Afkham Azeez* >>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>> * <http://www.apache.org/>** >>>>>>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>>>>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>>>>>> twitter: >>>>>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>>>>>> * >>>>>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>>>>>> * >>>>>>> * >>>>>>> *Lean . Enterprise . Middleware* >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Hiranya Jayathilaka >>>>>> Associate Technical Lead; >>>>>> WSO2 Inc.; http://wso2.org >>>>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Afkham Azeez* >>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>> * <http://www.apache.org/>** >>>>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>>>> twitter: >>>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>>>> * >>>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>>>> * >>>>> * >>>>> *Lean . Enterprise . Middleware* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Hiranya Jayathilaka >>>> Associate Technical Lead; >>>> WSO2 Inc.; http://wso2.org >>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>> Blog: http://techfeast-hiranya.blogspot.com >>>> >>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>** >>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>> * >>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>> * >>> * >>> *Lean . Enterprise . Middleware* >>> >>> >> >> >> -- >> Hiranya Jayathilaka >> Associate Technical Lead; >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 633 3491 >> Blog: http://techfeast-hiranya.blogspot.com >> > > > > -- > Hiranya Jayathilaka > Associate Technical Lead; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > -- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
