Why we can't copy new artifacts (or updated artifacts) to the deployment directory of the carbon servers, running on the containers?
Thanks. /Susankha. On Thu, Apr 14, 2016 at 10:24 AM, Manuranga Perera <[email protected]> wrote: > K8S will only know about the container image that was used for the >> deployment > > Ok, But form the image, don't we know what are the artifacts (since > immutable servers)? > > On Thu, Apr 14, 2016 at 1:18 PM, Frank Leymann <[email protected]> wrote: > >> Sorry for jumping in so late in the thread: is technology like HEAT/HOT >> (OpenStack) or TOSCA (OASIS) too encompassing? I am happy to provide on >> overview of their features... >> >> I am not suggesting to use the corresponding implementations (they have >> their pros/cons) but we may learn from the concepts behind them. >> >> >> Best regards, >> Frank >> >> 2016-04-14 12:06 GMT+02:00 Imesh Gunaratne <[email protected]>: >> >>> >>> >>> 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 >>> >>> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Susankha Nirmala Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware Mobile : +94 77 593 2146
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
