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