On Fri, May 10, 2013 at 1:21 PM, Paul Fremantle <[email protected]> wrote:
> This brings up a challenge with hot-deploy.... which is in a truly > distributed environment, I don't want to start all the deployed app on all > the servers until its successfully deployed on all servers. > > I see two approaches for this: > > Suppose there is Capp v1.0 deployed > > 1. I deploy CApp v1.1. We could simply not route any requests to v1.1 > until its all there. Then if it fails to deploy, we just have to undeploy > the successful components. > > 2. I deploy CApp v1.1 but don't start it. Then if all the components > deploy correctly, I start it. > > In general option 1 seems more flexible and simple, though we might want > to support both. > > In AF we have given every single app a version and we enforce that. I > think this is the time to revisit how this fits into the AS, ESB, etc. I > think option 1 is simpler.... basically we need a way in each server (or > globally) of saying which version is routed to. Even better would be to > specify a %age. > > Once the CApp v1.1 is successfully deployed, I could then say I want 5% of > traffic to go to v1.1 and the other 95% to go to v1.0. Then I can see how > its going and shift all traffic over to 1.1 over time. > I think we can do this with the operation center. In normal dep sync mode, first manager node commit the new CApp to svn. Then manager sends a cluster message to every node to update from the .svn. We can use operation center to send this cluster message selectively to some nodes. Then only that nodes get updated to next version. If the LB randomly select nodes then we can say x% of messages are process with new version. If that successful we can update all nodes. thanks, Amila. > > Paul > > > On 10 May 2013 08:23, Supun Malinga <[email protected]> wrote: > >> >> >> >> On Fri, May 10, 2013 at 12:43 PM, Kishanthan Thangarajah < >> [email protected]> wrote: >> >>> >>> >>> >>> On Fri, May 10, 2013 at 12:05 PM, Supun Malinga <[email protected]> wrote: >>> >>>> Hi Kishanthan, >>>> >>>> On Fri, May 10, 2013 at 11:26 AM, Kishanthan Thangarajah < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, May 10, 2013 at 9:09 AM, Ananda Manoj Kumara >>>>> <[email protected]>wrote: >>>>> >>>>>> Hi Supun, >>>>>> >>>>>> Yes now we can, the design is as Kishanthan mentioned on previously >>>>>> >>>>>> During CApp deployment, >>>>>> >>>>>> - Artifacts inside CApp get extracted to temp location >>>>>> >>>>>> Actually I was in the idea that now we don't extract the CApp. Why we >>>> didn't go with that model?. >>>> >>> >>> When calling the relevant deployers to deploy/undeploy, they expect the >>> individual artifacts to be available in the file system. This cannot >>> be achieved if we don't extract the CApp. >>> >> >> I see.. >> >>> >>>>>> - >>>>>> - CApp deployer then call the relevant deployers and deploy the >>>>>> artifacts >>>>>> >>>>>> This is fine. >>>> >>>>> >>>>>> - >>>>>> - Finally when the CApp get deployed all its artifacts are up and >>>>>> running >>>>>> >>>>>> We can easily detect the deployment status from the log. >>>>>> >>>>> >>>>> Yes, and you also can query the CApp Admin service (ApplicationAdmin) >>>>> to get the deployment status of artifacts in a CApp as-well. >>>>> >>>> >>>> How does the ApplicationAdmin keeps track of the deployment status of >>>> each artifact?. This was my initial question. >>>> >>> >>> There is another thread for this : "Tracking deployment status of >>> artifacts in CApp". Please refer that for more info. >>> >> >> thanks, will have a look. >> >>> >>> >>> Thanks, >>> Kishanthan. >>> >>> >>>> >>>> thanks, >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Manoj >>>>>> >>>>>> >>>>>> Best Regards.. >>>>>> >>>>>> >>>>>> Manoj Kumara >>>>>> Software Engineer >>>>>> WSO2, Inc.; http://wso2.com >>>>>> >>>>>> Twitter: http://twitter.com/ManKuma >>>>>> Mobile: +94713448188 >>>>>> >>>>>> >>>>>> On Fri, May 10, 2013 at 8:49 AM, Supun Malinga <[email protected]>wrote: >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> So now do we have the necessary hooks to detect the deployment >>>>>>> status of the capp?. What's the design? >>>>>>> Sorry if I have missed something. >>>>>>> >>>>>>> Thanks, >>>>>>> Supun >>>>>>> >>>>>>> Sent from my phone >>>>>>> On Apr 20, 2013 9:51 PM, "Afkham Azeez" <[email protected]> wrote: >>>>>>> >>>>>>>> Yes, we should not have unnecessary options >>>>>>>> >>>>>>>> -- >>>>>>>> Afkham Azeez >>>>>>>> Sent from my phone >>>>>>>> On Apr 20, 2013 8:53 PM, "Pradeep Fernando" <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Apr 20, 2013 at 8:27 PM, Kishanthan Thangarajah < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I agree with "CApp should be considered as an >>>>>>>>>> atomic deployment unit". >>>>>>>>>> >>>>>>>>>> But based on the above feedback, How about having two options as >>>>>>>>>> below? >>>>>>>>>> >>>>>>>>>> 1. Atomic deployment, i.e. either deploy all artifacts or none >>>>>>>>>> (this will be the default option) >>>>>>>>>> 2. Skip failing and deploy the rest. >>>>>>>>>> >>>>>>>>>> The choice we leave it to the user. However, the second option is >>>>>>>>>> useful only in a dev environment. The option can be changed via the >>>>>>>>>> root >>>>>>>>>> artifacts.xml file of CApp. >>>>>>>>>> >>>>>>>>> >>>>>>>>> if possible we should avoid giving options to users. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Kishanthan. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Apr 19, 2013 at 8:47 PM, Harshana Martin < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Pradeep, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Friday, April 19, 2013, Pradeep Fernando wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> CApp is the deployment unit. Either it should deploy >>>>>>>>>>>> successfully or not at all. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It's just not a deployment unit but a composite deployment unit >>>>>>>>>>> something similar to EAR. Thus the behavior of CAR should be >>>>>>>>>>> analogues to >>>>>>>>>>> behavior of EAR. >>>>>>>>>>> >>>>>>>>>>> Thanks and Regards, >>>>>>>>>>> Harshana >>>>>>>>>>> >>>>>>>>>>>> --Pradeep >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Apr 19, 2013 at 4:54 PM, Harshana Martin < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Azeez, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Apr 19, 2013 at 4:37 PM, Afkham Azeez >>>>>>>>>>>> <[email protected]>wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Apr 19, 2013 at 4:04 PM, Kishanthan Thangarajah < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> The following question came up during the review today. >>>>>>>>>>>> >>>>>>>>>>>> Say that my CApp has 5 artifacts and during the deployment >>>>>>>>>>>> of third artifact, an error occurred. Currently when this happens, >>>>>>>>>>>> the rest >>>>>>>>>>>> of the artifacts deployment is skipped and the CApp will be >>>>>>>>>>>> treated as >>>>>>>>>>>> faulty. But the issue is, the first and second artifact got >>>>>>>>>>>> deployed successfully and they are ready for operation too. >>>>>>>>>>>> >>>>>>>>>>>> The question is should we >>>>>>>>>>>> also rollback/undeploy these successful artifacts, if an error >>>>>>>>>>>> occurs? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yes, that what means by "a CApp is treated as an atomic >>>>>>>>>>>> deployment unit" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Well.. We say CAR is the composite unit consists of many sub >>>>>>>>>>>> components, C-App artifacts. >>>>>>>>>>>> >>>>>>>>>>>> There could be dependencies among these C-App artifacts but >>>>>>>>>>>> does it matter at the deployment time whether the dependencies are >>>>>>>>>>>> already >>>>>>>>>>>> available? >>>>>>>>>>>> >>>>>>>>>>>> If we are going to consider that at the deployment time, it >>>>>>>>>>>> could cause lot more issues in a distributed environment because >>>>>>>>>>>> we cannot >>>>>>>>>>>> assume about the timing of these artifact deployment. >>>>>>>>>>>> >>>>>>>>>>>> Thanks and Regards, >>>>>>>>>>>> Harshana >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Kishanthan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Apr 5, 2013 at 12:58 PM, Amila Suriarachchi < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Apr 5, 2013 at 12:55 PM, Kishanthan Thangarajah < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> We could get this work for ESB artifacts :). >>>>>>>>>>>> >>>>>>>>>>>> This is the flow of CApp deployment. >>>>>>>>>>>> >>>>>>>>>>>> CApp gets deployed --> CApp artifacts extracted it to temp >>>>>>>>>>>> location --> CApp deployer calls the relevant deployers of >>>>>>>>>>>> artifacts to >>>>>>>>>>>> deploy >>>>>>>>>>>> >>>>>>>>>>>> The problem was, ESB (Synapse) deployers gets >>>>>>>>>>>> registered with the axisConfiguration after some time. This is >>>>>>>>>>>> because >>>>>>>>>>>> Synapse configuration initialization happens after the axisConfig >>>>>>>>>>>> gets >>>>>>>>>>>> initialized. >>>>>>>>>>>> >>>>>>>>>>>> Since CApp deployer initialization also happens during the >>>>>>>>>>>> axisconfig initialization, when it tries to call the relevant >>>>>>>>>>>> synapse >>>>>>>>>>>> deployers, it will not find them as none of them are registered >>>>>>>>>>>> with >>>>>>>>>>>> axisConfig at that time. >>>>>>>>>>>> >>>>>>>>>>>> The solution was to delay the CApp >>>>>>>>>>>> Deployer initialization after Synapse config is initialized and >>>>>>>>>>>> ready. We >>>>>>>>>>>> have moved this part to StartUpFinalizer component. This will not >>>>>>>>>>>> affect >>>>>>>>>>>> any other servers (e.g. AS), since only the CappDeplyer >>>>>>>>>>>> initialization >>>>>>>>>>>> time is been changed. >>>>>>>>>>>> >>>>>>>>>>>> I will add these fixes to trunk. Manoj will continue to work on >>>>>>>>>>>> other artifacts types. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cool :). Then we add to getting status of caps. >>>>>>>>>>>> >>>>>>>>>>>> With this model now we can dep-synch caps. >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> Amila. >>>>>>>>>>>> >>>>>>>>>>>> *Pradeep Fernando* >>>>>>>>>>>> >>>>>>>>>>>> Member, Management Committee - Platform & Cloud Technologies >>>>>>>>>>>> Senior Software Engineer;WSO2 Inc.; http://wso2.com >>>>>>>>>>>> >>>>>>>>>>>> blog: http://pradeepfernando.blogspot.com >>>>>>>>>>>> m: +94776603662 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Harshana Martin >>>>>>>>>>> Senior Software Engineer >>>>>>>>>>> Member, Management Committee - Development Technologies >>>>>>>>>>> WSO2 Inc. : http://wso2.com >>>>>>>>>>> >>>>>>>>>>> Mobile: +94 775 998 115 >>>>>>>>>>> Profile: https://www.google.com/profiles/harshana05 >>>>>>>>>>> Blog: http://harshana05.blogspot.com >>>>>>>>>>> Twitter: http://twitter.com/harshana05 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Kishanthan Thangarajah* >>>>>>>>>> Software Engineer, >>>>>>>>>> Development Technologies Team, >>>>>>>>>> WSO2, Inc. >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> Mobile - +94773426635 >>>>>>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Pradeep Fernando* >>>>>>>>> Member, Management Committee - Platform & Cloud Technologies >>>>>>>>> Senior Software Engineer;WSO2 Inc.; http://wso2.com >>>>>>>>> >>>>>>>>> blog: http://pradeepfernando.blogspot.com >>>>>>>>> m: +94776603662 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Kishanthan Thangarajah* >>>>> Software Engineer, >>>>> Development Technologies Team, >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - +94773426635 >>>>> Blog - *http://kishanthan.wordpress.com* >>>>> Twitter - *http://twitter.com/kishanthan* >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Supun Malinga, >>>> >>>> Software Engineer, >>>> WSO2 Inc. >>>> http://wso2.com >>>> http://wso2.org >>>> email - [email protected] <[email protected]> >>>> mobile - 071 56 91 321 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Kishanthan Thangarajah* >>> Software Engineer, >>> Development Technologies Team, >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - +94773426635 >>> Blog - *http://kishanthan.wordpress.com* >>> Twitter - *http://twitter.com/kishanthan* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Supun Malinga, >> >> Software Engineer, >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> email - [email protected] <[email protected]> >> mobile - 071 56 91 321 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Paul Fremantle > CTO and Co-Founder, WSO2 > OASIS WS-RX TC Co-chair, VP, Apache Synapse > > UK: +44 207 096 0336 > US: +1 646 595 7614 > > blog: http://pzf.fremantle.org > twitter.com/pzfreo > [email protected] > > wso2.com Lean Enterprise Middleware > > Disclaimer: This communication may contain privileged or other > confidential information and is intended exclusively for the addressee/s. > If you are not the intended recipient/s, or believe that you may have > received this communication in error, please reply to the sender indicating > that fact and delete the copy you received and in addition, you should not > print, copy, retransmit, disseminate, or otherwise use the information > contained in this communication. Internet communications cannot be > guaranteed to be timely, secure, error or virus-free. The sender does not > accept liability for any errors or omissions. > > _______________________________________________ > Architecture mailing list > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
