On Mon, Mar 28, 2016 at 10:32 AM, Malaka Silva <[email protected]> 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 <[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 > > -- *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
<?xml version="1.0" encoding="UTF-8"?>
<deploymentNotificationMessage>
<artifactKey>sample1.txt</artifactKey>
<artifactType>txt</artifactType>
<host>example.com</host>
<timestamp>2016-03-29T15:52:38.474+05:30</timestamp>
<deploymentState>FAILED</deploymentState>
<properties>
<entry>
<key>serverId</key>
<value>a32v41-d124c</value>
</entry>
<entry>
<key>productCode</key>
<value>AS</value>
</entry>
</properties>
<message>Error while deploying artifact.
org.wso2.carbon.kernel.deployment.exception.CarbonDeploymentException: Deployed artifact key is null for : sample1.txt
at org.wso2.carbon.kernel.internal.deployment.DeploymentEngine.lambda$deployArtifacts$2(DeploymentEngine.java:273)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at org.wso2.carbon.kernel.internal.deployment.DeploymentEngine.deployArtifacts(DeploymentEngine.java:259)
at org.wso2.carbon.kernel.deployment.DeploymentEngineTest.testFaultyDeployArtifacts2(DeploymentEngineTest.java:222)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)</message>
</deploymentNotificationMessage>
deployment.yml
Description: Binary data
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
