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 ?.
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. Regards Nandika On Fri, Mar 25, 2016 at 10:58 AM, KasunG Gajasinghe <[email protected]> wrote: > Hi Nandika, > > On Thu, Mar 24, 2016 at 7:43 PM, Nandika Jayawardana <[email protected]> > 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 <[email protected]> >> wrote: >> >>> >>> >>> On Thu, Mar 24, 2016 at 3:23 PM, Sameera Jayasoma <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 >>>>>>> [email protected] >>>>>>> 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: [email protected] >>>>> 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: [email protected] >>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nandika Jayawardana >> WSO2 Inc ; http://wso2.com >> lean.enterprise.middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Nandika Jayawardana WSO2 Inc ; http://wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
