On Sat, Apr 21, 2012 at 1:05 PM, Hiranya Jayathilaka <[email protected]>wrote:
> 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. > Yes, that aspect has never been thought through before. It is after running SLive for the past couple of years, and managing that deployment, we have understood the intricacies of running a Carbon cluster in production, how configuration is managed, patching is managed, how software upgrades are done, backups are maintained etc. It is with this experience that I'm telling you that a UI for configuring infrastructure level stuff which is done by a sysadmin is not the correct way of doing things. Sanjaya, Chamith & the folks who run SLive will agree with me. > > 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 > -- *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
