On Sat, Jul 28, 2012 at 8:33 PM, Harshana Martin <[email protected]> wrote:
> Hi Isuru, > > I believe this new C-App deploymement location can be derived using tenant? > Yes.. It's CARBON_HOME/tmp/tenants/<tenant_id>/carbonapps/ Thanks, ~Isuru > Otherwise the Dev Studio C-App deployment feature will be broken. > > Thanks and Regards, > Harshana > On Jul 28, 2012 8:14 PM, "Isuru Suriarachchi" <[email protected]> wrote: > >> >> >> 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 >> >> -- 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
