This needs to be ordered by the primary user store first and then others
need to chained only.. (yes, order won't matter in most of the cases).
But - order also matters - people want to oder user store based on the
expected access frequency..
Thanks & regards,
-Prabath
On Mon, Jul 1, 2013 at 3:16 PM, Amila Suriarachchi <am...@wso2.com> wrote:
>
>
>
> On Mon, Jul 1, 2013 at 3:02 PM, Prabath Siriwardena <prab...@wso2.com>wrote:
>
>> It has to maintain a order - you will authenticate a users in a chain -
>> if the first fails it will go to the other.
>
>
> why order matters? Idea of authenticating is to check whether the user is
> the one who claims. If the user is valid it does not matter against which
> store it matches.
>
> Lets say you have two user stores u1 and u2. Now user foo can be in both
> or one store. if that user in at least one store it will return true
> irrespective of order to going to check.
>
> thanks,
> Amila.
>
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Mon, Jul 1, 2013 at 3:01 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..
>>>>
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>
--
Thanks & Regards,
Prabath
Mobile : +94 71 809 6732
http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
