On Sat, Jul 28, 2012 at 4:06 AM, Samisa Abeysinghe <[email protected]> wrote:

> Charitha - good catch!
>
> Isuru, thanks for the quick fix!!
>
> AS folks, can we please do a preliminary verification of the fix done by
> Isuru, before it hits the formal QA cycle?
>

On a separate thread, I've already asked Kicha to test this including all
possible scenarios..

Thanks,
~Isuru


>
>
> On Fri, Jul 27, 2012 at 10:55 AM, Isuru Suriarachchi <[email protected]>wrote:
>
>>
>>
>> On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez <[email protected]> wrote:
>>
>>>
>>>
>>> On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi <[email protected]>wrote:
>>>
>>>> Oh.. I was planning to create different directories for different
>>>> tenants inside repository/carbonapps. But looks like I've missed that. I'll
>>>> fix it and let you know..
>>>
>>>
>>> Tenants have their own temp directory right? If so, why can't we use
>>> those directories to store these?
>>>
>>
>> Yes, that's better than having another set of tenant spaces under
>> repository/carbonapps. So I fixed it that way and tested with ST and
>> tenants. I'm going to commit it now.
>>
>> Charitha, please test it with GD on/off as well on next pack.
>>
>> Thanks,
>> ~Isuru
>>
>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> ~Isuru
>>>>
>>>>
>>>> On Wed, Jul 25, 2012 at 10:31 PM, Charitha Kankanamge <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It seems we have not thought about MT aspects of this model. Now, the
>>>>> carbonapps directory is taken out from repository/deployment/server and 
>>>>> the
>>>>> all CApps will be stored in common carbonapps directory regardless of the
>>>>> tenant who deployed CApp. Because of this, any tenant can see others CApps
>>>>> :( I came across this [1] issue in latest AS probably because of this
>>>>> change.
>>>>>
>>>>>
>>>>> [1]https://wso2.org/jira/browse/CARBON-13691
>>>>>
>>>>>
>>>>> On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi <[email protected]>wrote:
>>>>>
>>>>>>  Hi all,
>>>>>>
>>>>>> I'm trying to fix [1]. Here's the root cause for this issue..
>>>>>>
>>>>>> Imagine a Carbon cluster with 2 nodes where the svn based deployment
>>>>>> synchronizer (DS) is configured. When a C-App is deployed to node1, it is
>>>>>> extracted and individual artifacts are copied into respective hot
>>>>>> directories. When the DS runs for the first time, it copies the C-App 
>>>>>> into
>>>>>> node2 and it will be deployed there. When the DS runs again in node1, it
>>>>>> will try to copy the individual artifacts to node2. But node2 already has
>>>>>> those artifacts as the C-App id already deployed in node2. Therefore an 
>>>>>> svn
>>>>>> conflict occurs.
>>>>>>
>>>>>> To resolve this issue, there are two possible options..
>>>>>>
>>>>>> 1. Keeping all artifacts coming from C-Apps out of the repository
>>>>>> (repository/deployment/server)
>>>>>> 2. Keeping the original C-App out of the repository
>>>>>>
>>>>>> Initially I tried option 1 above and programetically called the
>>>>>> relevant deployers for individual artifacts. But this creates lot of
>>>>>> problems with some artifacts (Ex: ESB stuff). Therefore, I'm trying to
>>>>>> solve the initial problem using option 2 above.
>>>>>>
>>>>>> I've taken the carbonapps directory out
>>>>>> of repository/deployment/server directory and kept it as
>>>>>> repository/carbonapps (we can change this if needed). Still the 
>>>>>> carbonapps
>>>>>> directory has hot deployment capabilities. But it won't be synchronized 
>>>>>> by
>>>>>> the DS. So when a C-App is deployed into node 1, it will be extracted and
>>>>>> only the individual artifacts will be copied into the repository. When 
>>>>>> the
>>>>>> DS runs, all needed artifacts will be synced to node 2. Therefore,
>>>>>> functionality wise, there won't be any issues on node 2.
>>>>>>
>>>>>> But if someone logs into the management console of node 2 and go to
>>>>>> the C-App list, nothing will be listed. Is this something we have to fix?
>>>>>> Because anyway in a RW/RO cluster, user can't use the management console 
>>>>>> of
>>>>>> the slave node.
>>>>>>
>>>>>> WDYT??
>>>>>>
>>>>>> Thanks,
>>>>>> ~Isuru
>>>>>>
>>>>>> [1] https://wso2.org/jira/browse/CARBON-13598
>>>>>>
>>>>>> --
>>>>>> Isuru Suriarachchi
>>>>>> Senior Technical Lead
>>>>>> WSO2 Inc. http://wso2.com
>>>>>> email : [email protected]
>>>>>> blog : http://isurues.wordpress.com/
>>>>>>
>>>>>> lean . enterprise . middleware
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [email protected]
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Isuru Suriarachchi
>>>> Senior Technical Lead
>>>> WSO2 Inc. http://wso2.com
>>>> email : [email protected]
>>>> blog : http://isurues.wordpress.com/
>>>>
>>>> lean . enterprise . middleware
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> *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*
>>>
>>>
>>
>>
>> --
>> Isuru Suriarachchi
>> Senior Technical Lead
>> WSO2 Inc. http://wso2.com
>> email : [email protected]
>> blog : http://isurues.wordpress.com/
>>
>> lean . enterprise . middleware
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
>


-- 
Isuru Suriarachchi
Senior Technical Lead
WSO2 Inc. http://wso2.com
email : [email protected]
blog : http://isurues.wordpress.com/

lean . enterprise . middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to