On Thu, Apr 14, 2016 at 10:54 PM, Manuranga Perera <m...@wso2.com> 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)? > We know that, but I don't think we can assume that all the artifacts found in the image will get deployed properly. We may need to expose the actual status of the artifacts via an API. On Fri, Apr 15, 2016 at 1:44 AM, Susankha Nirmala <susan...@wso2.com> wrote: > Why we can't copy new artifacts (or updated artifacts) to the deployment > directory of the carbon servers, running on the containers? > > That's exactly what we do. > On Thu, Apr 14, 2016 at 1:18 PM, Frank Leymann <fr...@wso2.com> 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 <im...@wso2.com>: >> >>> >>> >>> On Thu, Apr 14, 2016 at 1:35 AM, Manuranga Perera <m...@wso2.com> 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 <im...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Apr 7, 2016 at 11:53 PM, Imesh Gunaratne <im...@wso2.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Hi Ruwan, >>>>>> >>>>>> On Thu, Mar 31, 2016 at 3:07 PM, Ruwan Abeykoon <ruw...@wso2.com> >>>>>> 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 < >>>>> raviha...@wso2.com> 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 <isu...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Kasun, >>>>>>>> >>>>>>>> On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe < >>>>>>>> kas...@wso2.com> 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 >>>>>>>>> Architecture@wso2.org >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks and Regards, >>>>>>>> >>>>>>>> Isuru H. >>>>>>>> +94 716 358 048* <http://wso2.com/>* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Ruwan Abeykoon* >>>>>>> *Architect,* >>>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>>>> *lean.enterprise.middleware.* >>>>>>> >>>>>>> email: ruw...@wso2.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> 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 >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> With regards, >>>> *Manu*ranga Perera. >>>> >>>> phone : 071 7 70 20 50 >>>> mail : m...@wso2.com >>>> >>> >>> >>> >>> -- >>> *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 >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > -- *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
