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..
>
Why you need to keep an order? if you authenticate the users I think it
does not matter from which store you authenticate as far as users get
authenticated.
thanks,
Amila.
> That needs to be maintain at the user-mgt.xml..
>
> By breaking this in to separate user-store files only make things complex..
>
> 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
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
