Do we support the graceful restart and graceful shutdown capabilities we had with C4 in C5 ?
Regards Nandika On Tue, Mar 29, 2016 at 5:19 PM, KasunG Gajasinghe <kas...@wso2.com> wrote: > > On Mon, Mar 28, 2016 at 10:32 AM, Malaka Silva <mal...@wso2.com> wrote: > >> Hi All, >> >> I think we have to think a way to manage the deployments in a round robin >> passion. >> So that we can make sure only single worker unavailable at a given time >> rather than the whole cluster. >> > > With the new Lifecycle listener support, we can achieve this functionality > if needed. In there, you can write a lifecycle listener to remove itself > from a loadbalancer before doing the artifact deployment/undeployment. > After the deployment/undeployment is completed, it can join back again. > Then, there won't be any downtime since other nodes in the cluster will > continue to serve requests. > But, users need to do the artifact distribution themselves in a strategy > such as round-robin as they see fit since the artifact synchronization > across a cluster is not handled at Carbon level,. > > With docker based architecture, doing a new deployment means you just > create a new docker image and spin it up, and then shutdown the older > instance. > > >> Are we planning to do this in C5? >> >> On Fri, Mar 25, 2016 at 1:42 PM, KasunG Gajasinghe <kas...@wso2.com> >> wrote: >> >>> >>> >>> On Fri, Mar 25, 2016 at 12:30 PM, Nandika Jayawardana <nand...@wso2.com> >>> wrote: >>> >>>> Hi Kasun, >>>> >>>> Since the end goal of making this information available at a central >>>> location is to be able to monitor the deployment for consistency and >>>> correctness, So we should look at from the tooling perspective. Any plans >>>> for providing a JMS based cluster monitoring tool ?. >>>> >>> >>> The monitoring aspect need to be think-through further. Sameera's >>> suggestion of an alerting system based on real-time analytics with CEP is >>> an option that we can provide by default. We could also provide a simple >>> dashboard to view the deployment status. >>> >>> >>>> >>>> Also, since we are asking users to do the synchronization , there would >>>> be other scenarios in addition to failed deployments such an not >>>> synchronizing with a particular node. >>>> >>>> >>> Yes, we will take this into account. The number of nodes should be >>> pre-defined before hand in the consumer side. Or, may be we can send a >>> server startup/shutdown message mentioning a new node has joined/left the >>> cluster. >>> >>> Thanks, >>> KasunG >>> >>> >>>> Regards >>>> Nandika >>>> >>>> >>>> >>>> On Fri, Mar 25, 2016 at 10:58 AM, KasunG Gajasinghe <kas...@wso2.com> >>>> wrote: >>>> >>>>> Hi Nandika, >>>>> >>>>> On Thu, Mar 24, 2016 at 7:43 PM, Nandika Jayawardana <nand...@wso2.com >>>>> > wrote: >>>>> >>>>>> What about providing a REST API from each node of the cluster which >>>>>> can be used to query deployed artifact information in addition to JMS >>>>>> publishing. >>>>>> >>>>> >>>>> There will be admin services later on that will provide artifact >>>>> information, but we need to see how usable that is to understand failed >>>>> artifact deployments. Because users will need to poll and pull data from >>>>> each node periodically to find out whether the artifact deployment is >>>>> successful at that moment. >>>>> >>>>> Here, what we are proposing is a push model where all the nodes will >>>>> push its whenever an artifact is deployed. An interested consumer can >>>>> listen for these events and take actions as required. >>>>> >>>>> Thanks, >>>>> KasunG >>>>> >>>>> >>>>>> Regards >>>>>> Nandika >>>>>> >>>>>> On Thu, Mar 24, 2016 at 3:45 PM, KasunG Gajasinghe <kas...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 24, 2016 at 3:23 PM, Sameera Jayasoma <same...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Btw, who are the consumers of these messages? User can develop >>>>>>>> their own tools to monitor artifact deployment. >>>>>>>> >>>>>>>> We also can come with CEP query to analyze whether the artifact >>>>>>>> deployment happened successfully in a cluster and display this >>>>>>>> information >>>>>>>> in a dashboard. We can come up with a DAS C-App. >>>>>>>> >>>>>>> >>>>>>> +1 for the idea. >>>>>>> >>>>>>> The initial phase that is described in this thread is to provide the >>>>>>> deployment status notifications. Coordination will be the next step on >>>>>>> top >>>>>>> of this. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sameera. >>>>>>>> >>>>>>>> On Wed, Mar 23, 2016 at 2:24 PM, Sameera Jayasoma <same...@wso2.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> I believe we need both here. >>>>>>>>> >>>>>>>>> In JMS case, we need to publish events to a topic rather than a >>>>>>>>> queue. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sameera. >>>>>>>>> >>>>>>>>> On Wed, Mar 23, 2016 at 2:02 PM, Srinath Perera <srin...@wso2.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Kasun, I would go with JMS as it gives event persistence and you >>>>>>>>>> will not loose the events even if listener is restarted. >>>>>>>>>> >>>>>>>>>> --Srinath. >>>>>>>>>> >>>>>>>>>> On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe < >>>>>>>>>> kas...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Given several issues we discovered with automatic artifact >>>>>>>>>>> synchronization with DepSync in C4, we have discussed how to >>>>>>>>>>> approach this >>>>>>>>>>> problem in C5. >>>>>>>>>>> >>>>>>>>>>> We are thinking of not doing the automated artifact >>>>>>>>>>> synchronization in C5. Rather, users should use their own mechanism >>>>>>>>>>> to >>>>>>>>>>> synchronize the artifacts across a cluster. Common approaches are >>>>>>>>>>> RSync as >>>>>>>>>>> a cron job and shell scripts. >>>>>>>>>>> >>>>>>>>>>> But, it is vital to know the artifact deployment status of the >>>>>>>>>>> nodes in the entire cluster from a central place. For that, we are >>>>>>>>>>> providing this deployment coordination feature. There will be two >>>>>>>>>>> ways to >>>>>>>>>>> use this. >>>>>>>>>>> >>>>>>>>>>> 1. JMS based publishing - the deployment status will be >>>>>>>>>>> published by each node to a jms topic/queue >>>>>>>>>>> >>>>>>>>>>> 2. Log based publishing - publish the logs by using a syslog >>>>>>>>>>> appender [1] or our own custom appender to a central location. >>>>>>>>>>> >>>>>>>>>>> The log publishing may not be limited to just the deployment >>>>>>>>>>> coordination. In a containerized deployment, the carbon products >>>>>>>>>>> will run >>>>>>>>>>> in disposable containers. But sometimes, the logs need to be backed >>>>>>>>>>> up for >>>>>>>>>>> later reference. This will help with that. >>>>>>>>>>> >>>>>>>>>>> Any thoughts on this matter? >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> KasunG >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ~~--~~ >>>>>>>>>>> Sending this mail via my phone. Do excuse any typo >>>>>>>>>>> or short replies >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ============================ >>>>>>>>>> Srinath Perera, Ph.D. >>>>>>>>>> http://people.apache.org/~hemapani/ >>>>>>>>>> http://srinathsview.blogspot.com/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sameera Jayasoma, >>>>>>>>> Software Architect, >>>>>>>>> >>>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>>> email: same...@wso2.com >>>>>>>>> blog: http://blog.sameera.org >>>>>>>>> twitter: https://twitter.com/sameerajayasoma >>>>>>>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>>>>>>> Mobile: 0094776364456 >>>>>>>>> >>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sameera Jayasoma, >>>>>>>> Software Architect, >>>>>>>> >>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>> email: same...@wso2.com >>>>>>>> blog: http://blog.sameera.org >>>>>>>> twitter: https://twitter.com/sameerajayasoma >>>>>>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>>>>>> Mobile: 0094776364456 >>>>>>>> >>>>>>>> Lean . Enterprise . Middleware >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. >>>>>>> email: kasung AT spamfree wso2.com >>>>>>> linked-in: http://lk.linkedin.com/in/gajasinghe >>>>>>> blog: http://kasunbg.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nandika Jayawardana >>>>>> WSO2 Inc ; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. >>>>> email: kasung AT spamfree wso2.com >>>>> linked-in: http://lk.linkedin.com/in/gajasinghe >>>>> blog: http://kasunbg.org >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nandika Jayawardana >>>> WSO2 Inc ; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. >>> email: kasung AT spamfree wso2.com >>> linked-in: http://lk.linkedin.com/in/gajasinghe >>> blog: http://kasunbg.org >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> https://store.wso2.com/store/ >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. > email: kasung AT spamfree wso2.com > linked-in: http://lk.linkedin.com/in/gajasinghe > blog: http://kasunbg.org > > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Nandika Jayawardana WSO2 Inc ; http://wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
