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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
