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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
