On Thu, Apr 14, 2016 at 1:35 AM, Manuranga Perera <[email protected]> wrote:
> If an existing artifact needs to be updated or new artifacts needs to be >> added a new container image needs to be created. > > In this case, why can't we ask from Kub how many pods with new artifact > has been spun up? Why does this have to be updated at carbon kernel level > via JMS? > Carbon may not handle the rollout but it will need to inform an external entity the status of the deployed artifacts. K8S will only know about the container image that was used for the deployment, it will have no information on the artifacts deployed in the Carbon server. > > > On Thu, Apr 7, 2016 at 2:38 PM, Imesh Gunaratne <[email protected]> wrote: > >> >> >> On Thu, Apr 7, 2016 at 11:53 PM, Imesh Gunaratne <[email protected]> wrote: >> >>> >>> Hi Ruwan, >>> >>> On Thu, Mar 31, 2016 at 3:07 PM, Ruwan Abeykoon <[email protected]> wrote: >>> >>>> Hi All, >>>> Do we really want artifact deployment coordination in C5? >>>> What is preventing us to build the new image with the new version of >>>> artifacts and let the k8s take care of deployment? >>>> >>> >>> You are absolutely correct! We may not do artifact synchronization in C5 >>> rather artifacts will get packaged into the containers. >>> >> >> I'm sorry C5 will also support none containerized deployments (VM, >> physical machines), still artifact synchronization will not be handled by >> Carbon. >> >> On Wed, Apr 6, 2016 at 8:03 PM, Akila Ravihansa Perera < >> [email protected]> wrote: >>> >>> >>> I've few concerns regarding artifact deployment coordination >>> - Artifact versioning support. This is important to ensure consistency >>> across a cluster >>> >> >> Indded, but it may not relate to this feature I guess. >> >> >>> - REST API to query the status. I'd rather go ahead with a REST API >>> before a JMS based implementation. IMO it's much simpler and easy to use. >>> >> >> A REST API might be needed in a different context, may be in a central >> monitoring server. In this context the design is to let servers publish >> their status to a central server. Otherwise it might not be feasible for a >> client to talk to each and every server and prepare the aggregated view. >> >> >>> - Why don't we provide a REST API to deploy artifacts rather than >>> copying files (whenever applicable)? We can immediately notify the client >>> (via HTTP response status) whether artifact deployment was successful. >>> >> >> Might not be needed for container based deployments. >> >> Thanks >> >> >>> This feature is for monitoring the deployment status of the artifacts. >>> If an existing artifact needs to be updated or new artifacts needs to be >>> added a new container image needs to be created. Then a rollout should be >>> triggerred (depending on the container cluster management system used). >>> >>> Thanks >>> >>>> >>>> Cheers, >>>> Ruwan >>>> >>>> On Wed, Mar 30, 2016 at 2:54 PM, Isuru Haththotuwa <[email protected]> >>>> wrote: >>>> >>>>> Hi Kasun, >>>>> >>>>> 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. >>>>>> >>>>> Both are push mechanisms, IMHO we would need an API to check the >>>>> status of a deployed artifacts on demand, WDYT? >>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> >>>>> Isuru H. >>>>> +94 716 358 048* <http://wso2.com/>* >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Ruwan Abeykoon* >>>> *Architect,* >>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>> *lean.enterprise.middleware.* >>>> >>>> email: [email protected] >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Senior Technical Lead >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: http://imesh.io >>> Lean . Enterprise . Middleware >>> >>> >> >> >> -- >> *Imesh Gunaratne* >> Senior Technical Lead >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: http://imesh.io >> Lean . Enterprise . Middleware >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.io Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
