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. Are we planning to do this in C5?
On Fri, Mar 25, 2016 at 1:42 PM, KasunG Gajasinghe <[email protected]> wrote: > > > On Fri, Mar 25, 2016 at 12:30 PM, Nandika Jayawardana <[email protected]> > 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 <[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 >> >> > > > -- > > *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 > > -- 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
