I too share the same thoughts as Amila.
Azeez
On Mon, Jul 1, 2013 at 2:54 PM, Amila Suriarachchi <am...@wso2.com> wrote:
>
>
>
> On Mon, Jul 1, 2013 at 2:38 PM, Prabath Siriwardena <prab...@wso2.com>wrote:
>
>> Not quite right..
>>
>> A given user sore cannot just exist on its own.. it has to maintain the
>> order with others.. That needs to be maintain at the user-mgt.xml..
>>
>> By breaking this in to separate user-store files only make things
>> complex..
>>
>
> I think keeping dynamic things in user-mgt.xml is the complex one.
>
> For an example in order to start the server you need to have a user
> realm which is given at the user manager xml. Then if you want to add a
> additional user stores you can use a separate user store file. There is no
> requirement to replicate whole user manager xml and re initialise user
> realm for that.
>
> thanks,
> Amila.
>
>
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Mon, Jul 1, 2013 at 2:27 PM, Pradeep Fernando <prad...@wso2.com>wrote:
>>
>>> Hi All,
>>>
>>>
>>> On Tue, Jun 25, 2013 at 4:00 PM, Amila Suriarachchi <am...@wso2.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jun 25, 2013 at 3:05 PM, Pushpalanka Jayawardhana <
>>>> la...@wso2.com> wrote:
>>>>
>>>>> Thanks all for the ideas.
>>>>> Will be moving forward with option 2.
>>>>>
>>>>> repository/conf/userstores/user-mgt.xml
>>>>> repositoty/conf/tenants/1/userstores/user-mgt.xml - configuration for
>>>>> tenant with tenant-id: 1
>>>>> repositoty/conf/tenants/2/userstores/user-mgt.xml - configuration for
>>>>> tenant with tenant-id: 2
>>>>>
>>>>
>>>> Technically speaking this is not correct. User-mgt.xml is used to
>>>> configure UserRealm not only the userstore. So it should be usermanager.
>>>>
>>>> But in this case what we want to dep-synch only the userstores. so my
>>>> suggestion is to put them under userstores folder with the store name.
>>>>
>>>> eg. repository/deployment/server/userstores/userstore1.xml
>>>> repository/deployment/server/userstores/userstore2.xml.
>>>>
>>>> For an example if we change one userstore there is not reason to
>>>> dep-sychn all user-mgt.xml and re initialise all user stores.
>>>>
>>>
>>> Azeez,Amila,me had a chat on the $subject. We have to follow the above
>>> approach it seems.
>>>
>>> Here the additional user-store configs are runtime artifacts and can be
>>> treated in the same way we do other runtime artifacts. User-mgt.xml is a
>>> static config file and it needs not to be dep-synched.
>>>
>>> @Prabath and Pushpalanka;
>>>
>>> Can we achieve the functionality using above method...
>>>
>>>
>>> On technical front, if we try to listen to more than one directory,
>>> things get bit complicated. Specially if you want to do dep-sync for those
>>> directories. Normally we maintain a one dep-sync thread per tenant. If we
>>> listen/dep-sync more than one directory - > two dep-sync thread per tenant.
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> thanks,
>>>> Amila.
>>>>
>>>>>
>>>>> So a product will have 2 locations, inside repository/conf to be
>>>>> synced with dep-sync as,
>>>>>
>>>>> - repositoty/conf/userstores ('userstores' just to avoid syncing
>>>>> all content in conf directory) and
>>>>> - repository/conf/tenants
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Pushpalanka Jayawardhana
>>>>>
>>>>> Software Engineer
>>>>>
>>>>> WSO2 Lanka (pvt) Ltd
>>>>> [image:
>>>>> Facebook]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.facebook.com%2Fpushpalanka>
>>>>> [image:
>>>>> Twitter]<http://s.wisestamp.com/links?url=http%3A%2F%2Ftwitter.com%2FPushpalanka>
>>>>> [image:
>>>>> LinkedIn]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.linkedin.com%2Fprofile%2Fview%3Fid%3D75175642%26trk%3Dtab_pro>
>>>>> [image:
>>>>> Blogger]<http://s.wisestamp.com/links?url=http%3A%2F%2Fpushpalankajaya.blogspot.com%2F>
>>>>> [image:
>>>>> SlideShare]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2FPushpalanka>
>>>>> Mobile: +94779716248
>>>>> <http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Dc984892c0c4ca423%26v%3D3.13.2%26t%3D1361257731639%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 25, 2013 at 11:46 AM, Dhanuka Ranasinghe <dhan...@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am not much aware about carbon architecture, but have few thoughts
>>>>>> to achieve above requirements.
>>>>>>
>>>>>> 1. Having a high available singleton (HA) service (through MBeans)
>>>>>> then make sure it is active only in master node.
>>>>>> 2. When the master node down one of other member in cluster become a
>>>>>> master node and it's HA service will be activated.
>>>>>> 3. All the configurations done and read through that HA service, by
>>>>>> doing this whether it's UI or local file system change it will be synch
>>>>>> with every time with every member.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Dhanuka
>>>>>>
>>>>>> *Dhanuka Ranasinghe*
>>>>>>
>>>>>> Senior Software Engineer
>>>>>> WSO2 Inc. ; http://wso2.com
>>>>>> lean . enterprise . middleware
>>>>>>
>>>>>> phone : +94 715381915
>>>>>>
>>>>>>
>>>>>> On Fri, May 31, 2013 at 2:41 PM, Srinath Perera <srin...@wso2.com>wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Azeez and myself was chatting, and following are some of the
>>>>>>> conflicting requirements.
>>>>>>>
>>>>>>> 1. like to edit configs from file system, and via UI avoiding two
>>>>>>> copies if possible (have to avoid case where we edit file, then we edit
>>>>>>> via
>>>>>>> UI where we lost the file updates).
>>>>>>> 2. Need a way to sync configs across the cluster
>>>>>>> 3. Make the sync model clear and consistent for both configs and
>>>>>>> artifacts (currently we use dep-sync only with artifacts)
>>>>>>> 4. Like to sync only one folder in the product with dep-sync
>>>>>>>
>>>>>> ^This will not be achieved, with the option.
>>>>>
>>>>>> 5. We should not do product folder structure before major release
>>>>>>> (C5?)
>>>>>>>
>>>>>>> We need to find the best solution out of that.
>>>>>>>
>>>>>>> --Srinath
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 30, 2013 at 9:20 PM, Senaka Fernando <sen...@wso2.com>wrote:
>>>>>>>
>>>>>>>> Hi Srinath,
>>>>>>>>
>>>>>>>> IMHO, relying on a dep-sync-based model sounds appropriate here. We
>>>>>>>> can have several strategies for dep-sync (i.e. registry, svn, manual
>>>>>>>> etc),
>>>>>>>> but the server will be driven by what's on the filesystem. IMHO, that's
>>>>>>>> very straightforward.
>>>>>>>>
>>>>>>>> And, I think we need to first of all figure out what and what's
>>>>>>>> going to be sync'ed and what's not. When it comes to some configuration
>>>>>>>> files it might make sense to sync portions and keep some static. In
>>>>>>>> that
>>>>>>>> case, do we need to split those files in two? Also, we need to focus
>>>>>>>> on the
>>>>>>>> "things that change across environments and things that don't" for the
>>>>>>>> sever configuration as in the "CAR-based Governance Story" for ESB
>>>>>>>> configurations.
>>>>>>>>
>>>>>>>> Also, the dep-sync's notification model should work like the
>>>>>>>> hierarchical cache invalidation model that Azeez proposed, making sure
>>>>>>>> that
>>>>>>>> things will scale.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Senaka.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 30, 2013 at 4:46 PM, Jeewantha Dharmaparakrama <
>>>>>>>> jeewan...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Srinath,
>>>>>>>>>
>>>>>>>>> If the node which detects the change in its config file redeploys
>>>>>>>>> the config in every other node explicitly, we can ensure that every
>>>>>>>>> node
>>>>>>>>> sees the change since there will always be one node which is
>>>>>>>>> responsible in
>>>>>>>>> informing the others. I guess thats what depsync does IINM.
>>>>>>>>>
>>>>>>>>> If the config is stored in a central place, every node will have
>>>>>>>>> to pull the change from that place. Here if one node fails to
>>>>>>>>> redeploy the
>>>>>>>>> change, other nodes will be unaware about it so that the system will
>>>>>>>>> be
>>>>>>>>> unstable. IMHO we should prefer the former.
>>>>>>>>>
>>>>>>>>> Jeewantha
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, May 30, 2013 at 3:44 PM, Srinath Perera
>>>>>>>>> <srin...@wso2.com>wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> We just finished a review on UI for user stores and figured we
>>>>>>>>>> are doing this in several ways. Pradeep, Prabath, and myself had a
>>>>>>>>>> chat,
>>>>>>>>>> and following are our thoughts.
>>>>>>>>>>
>>>>>>>>>> We have different types of configurations with carbon server
>>>>>>>>>>
>>>>>>>>>> 1) Some are only apply for one node (e.g. carbon.xml,
>>>>>>>>>> registry.xml ..)
>>>>>>>>>> 2) Some might be useful across a cluster, but we ask users to
>>>>>>>>>> copy it to all the nodes (e.g. data sources, xacml policies,
>>>>>>>>>> keystores ?? )
>>>>>>>>>> 3) It is proposed that we will automatically replicate user-store
>>>>>>>>>> configurations using deployment synchronizer when it is added to one
>>>>>>>>>> node.
>>>>>>>>>>
>>>>>>>>>> To share the same configurations across all nodes in the cluster,
>>>>>>>>>> we have several options.
>>>>>>>>>>
>>>>>>>>>> 1) We can have a config files, and use deployment sync to sync
>>>>>>>>>> them across the cluster (Then, I think we need to have a cluster
>>>>>>>>>> folder in
>>>>>>>>>> conf or make clear what configurations are replicated).
>>>>>>>>>>
>>>>>>>>>> 2) We have a config file, but once read, we store them in a DB or
>>>>>>>>>> in registry, since all nodes share same DB/ registry there is no
>>>>>>>>>> need to
>>>>>>>>>> replication (we can send a cluster message saying there is a
>>>>>>>>>> update). Risk
>>>>>>>>>> of this is after bring edited by UI and directly via the file, two
>>>>>>>>>> sources
>>>>>>>>>> might go out of sync and some updates can be lost when next update
>>>>>>>>>> happend.
>>>>>>>>>>
>>>>>>>>>> 3) Data sources can be added via UI (goes to registry) or via
>>>>>>>>>> file system (not replicated), which is a mix.
>>>>>>>>>>
>>>>>>>>>> I think we need to stick to one model out of #1 and #2. We
>>>>>>>>>> thought dep sync model is the best as it is clear. But then we have
>>>>>>>>>> to tell
>>>>>>>>>> which part of the configs get replicated.
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> --Srinath
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ============================
>>>>>>>>>> Srinath Perera, Ph.D.
>>>>>>>>>> Senior Software Architect, WSO2 Inc.
>>>>>>>>>> Visiting Faculty, University of Moratuwa
>>>>>>>>>> Member, Apache Software Foundation
>>>>>>>>>> Research Scientist, Lanka Software Foundation
>>>>>>>>>> Blog: http://srinathsview.blogspot.com/
>>>>>>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>>>>>>> Phone: 0772360902
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Architecture mailing list
>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jeewantha Dharmaparakrama
>>>>>>>>> Software Engineer; WSO2, Inc.; http://wso2.com/
>>>>>>>>> Phone : (+94) 774726790
>>>>>>>>> Skype : prasad.jeewantha
>>>>>>>>> LinkedIn : http://www.linkedin.com/in/jeewanthad
>>>>>>>>> Twitter: https://twitter.com/jeewamp
>>>>>>>>> Blog: http://jeewanthad.blogspot.com/
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Architecture mailing list
>>>>>>>>> Architecture@wso2.org
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Senaka Fernando*
>>>>>>>> Member - Integration Technologies Management Committee;
>>>>>>>> Technical Lead; WSO2 Inc.; http://wso2.com*
>>>>>>>> Member; Apache Software Foundation; http://apache.org
>>>>>>>>
>>>>>>>> E-mail: senaka AT wso2.com
>>>>>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>>>>>>>> Linked-In: http://linkedin.com/in/senakafernando
>>>>>>>>
>>>>>>>> *Lean . Enterprise . Middleware
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ============================
>>>>>>> Srinath Perera, Ph.D.
>>>>>>> Director, Research, WSO2 Inc.
>>>>>>>
>>>>>>> Visiting Faculty, University of Moratuwa
>>>>>>> Member, Apache Software Foundation
>>>>>>> Research Scientist, Lanka Software Foundation
>>>>>>> Blog: http://srinathsview.blogspot.com/
>>>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>>>> Phone: 0772360902
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Amila Suriarachchi*
>>>>
>>>> Software Architect
>>>>
>>>> WSO2 Inc. ; http://wso2.com
>>>> lean . enterprise . middleware
>>>>
>>>> phone : +94 71 3082805
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Pradeep Fernando*
>>> Associate Technical Lead;WSO2 Inc.; http://wso2.com
>>>
>>> blog: http://pradeepfernando.blogspot.com
>>> m: +94776603662
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>
>
>
> --
> *Amila Suriarachchi*
>
> Software Architect
> WSO2 Inc. ; http://wso2.com
> lean . enterprise . middleware
>
> phone : +94 71 3082805
>
--
*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*
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
