On Sat, Apr 21, 2012 at 12:42 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:
> > > On Sat, Apr 21, 2012 at 12:22 PM, Afkham Azeez <az...@wso2.com> wrote: > >> >> >> On Sat, Apr 21, 2012 at 12:13 PM, Hiranya Jayathilaka >> <hira...@wso2.com>wrote: >> >>> >>> >>> On Fri, Apr 20, 2012 at 7:34 PM, Afkham Azeez <az...@wso2.com> 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. 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. > And in the future if we plan to change our clustering model and how registry sharing is used, then this component should be accordingly updated. Right now it's modeled after our current registry sharing and master-slave model of clustering. Thanks, Hiranya > > Thanks, > Hiranya > > >> >>> >>> Thanks, >>> Hiranya >>> >>> >>>> >>>> >>>> On Fri, Apr 20, 2012 at 6:53 PM, Afkham Azeez <az...@wso2.com> 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: **az...@wso2.com* <az...@wso2.com>* 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: **az...@wso2.com* <az...@wso2.com>* 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 >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Associate Technical Lead; >>> WSO2 Inc.; http://wso2.org >>> E-mail: hira...@wso2.com; 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: **az...@wso2.com* <az...@wso2.com>* 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: hira...@wso2.com; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > -- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
