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
