On Sat, Apr 21, 2012 at 1:05 PM, Afkham Azeez <[email protected]> wrote:
> Nice article, but I don't see anybody setting up a cluster which is not > fronted by an LB, and neither do I see sysadmins using the UI to configure > infrastructure level stuff. Our existing clustering model permits setting up a LB for service requests. It's just that admin console cannot be load balanced. In case of ESB this is quite easy and makes a lot of sense since the admin console and services run on different ports. You simply setup a LB for NIO transport. For other products the separation is sort of blurred but not impossible. In an enterprise setup this usually doesn't become a showstopper for load balancing. In that case most of the time services are exposed to external parties. Management console is exposed only to internal users (admins and developers). So it's fairly easy to setup load balancing only for requests coming from external clients. > The UI would be pretty impressive to tryout stuff but in production it > won't get used. I totally agree with you on that. I myself is not a fan of setting up this kind of low level stuff through a UI ;) It just adds more overhead to the admin check lists. Everytime you setup the cluster from scratch, you have to go and do the changes through the UI because you can't easily version control and persist the configuration changes you do. However from what I've seen some people use this UI in ESB clusters and AS clusters etc. I guess some people just need a UI for everything :) Also I agree with you on UI being very useful to tryout stuff. It can help people learn the principles, do demos and PoCs quite easily. Can also be quite useful in a clustered dev environment where developers may not have access to the OS or file system where the servers are setup (which unfortunately is the case in many enterprises). But once you have tested and verified the settings through the UI, it's best to move the configuration settings to carbon.xml when you're ready to go production. 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 >> > > > > -- > *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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
