One thought, which may or may not be directly related for you to consider…
We often encounter the need for “related” VMs to exchange some data, and some kind of service like this might be very handy for that. One problematic area we have seen, but for which we have struggled to come up with a simple-but-generic model, is the idea of “ownership”. For example, a common pattern is for VMs to exist in pairs such that as they come up, they first find, and then negotiate with each other to decide on roles (e.g. Active/Standby). We have seen this done multiple way including: · Ad-hoc logic · Pacemaker/corosync/heartbeat Essentially, it boils down to having a distributed lock database where the resources being locked are essentially rows in a database. The point is that having an application-addressable (e.g. REST) distributed lock manager would be a novel but potentially very powerful thing, and would be a superset of what is being discussed here. OTOH, it could be complete overkill… ☺ From: Gayan Gunarathne [mailto:gay...@wso2.com] Sent: 22 July 2014 09:42 To: dev@stratos.apache.org Subject: Re: Grouping of services with dependency cartridges how do we store meta data - IMO if we go with the registry (G-Reg) rather than a DB or other implementation we can acquire following benefits. 1. Activity log and monitoring support 2. Development effect and maintainable effect will be less 3. We can use in-build notifications functionality of the G-Reg if we want 4. We can use as a separate service(loosely coupled) 5. Dependency management - Maintain the relationship with dependence cartridges What do you think? On Tue, Jul 22, 2014 at 1:06 PM, Pradeep Fernando <pradee...@gmail.com<mailto:pradee...@gmail.com>> wrote: Hi, - metadata should be independent from topology. Otherwise one has to tamper topology to introduce application specific metadata. (if we go in that path, we dont need metadata service at all i guess) - so udaras' idea might not work. - we need a rest api - > means packaging type would be a webapp. - how you store your data depends. (registry or your own thing) - webapp can listen to topology to keep track of terminated members or else some other component can (CC) can feed that info in. - i like the idea of webapp listening to topology. Then the only operations would be data push/pull with given compoiste app id. thanks, --Pradeep On Tue, Jul 22, 2014 at 12:57 PM, Gayan Gunarathne <gay...@wso2.com<mailto:gay...@wso2.com>> wrote: Hi Imesh, Thanks for the clarification. With this approach how we add the Cartridge meta data to the registry/web -app? AFAIK the all the meta data related to the cartridges are not available in the topology.As a example credential details of the MySQL cartridge not available in the topology. +1 to have a loosely coupled meta data service.How about that following approach? We will provide rest API which can be packed in a standalone server or single JVM instance which provide the REST API for meta data add,remove,get. (So then topology don't need to contain the meta data of the cartridges.) Thanks, Gayan On Mon, Jul 21, 2014 at 11:44 PM, Imesh Gunaratne <im...@apache.org<mailto:im...@apache.org>> wrote: Hi Gayan, Few weeks back I had a discussion on this with Lakmal and the idea was to use a metadata service web-app. Shall we discuss pros and cons on using the Registry vs a Web-app. Regarding Pradeep's question, IMO the metadata-service (either the registry/web-app) can listen to the topology and remove any entries created by a terminated member. Which means the metadata service could act without having any dependencies to other Stratos components. How do we package this? IMO we should be able to run the Metadata service separately (as a standalone server/cluster) and at the same time have it in the single JVM distribution. Thanks On Mon, Jul 21, 2014 at 8:33 AM, Udara Liyanage <ud...@wso2.com<mailto:ud...@wso2.com>> wrote: Hi, Could n't this be achieved by using the existing topology? Add some REST APIs to SM which get necessary details from CC. Agent can get the IP by calling the API. However mysql credentials are not in topology. Touched, not typed. Erroneous words are a feature, not a typo. -- Imesh Gunaratne Technical Lead, WSO2 Committer & PPMC Member, Apache Stratos -- Best Regards, Gayan Gunarathne Technical Lead WSO2 Inc. (http://wso2.com<http://wso2.com/>) email : gay...@wso2.com<mailto:gay...@wso2.com> | mobile : +94 766819985<tel:%2B94%20766819985> -- Pradeep Fernando. http://pradeepfernando.blogspot.com/ -- Best Regards, Gayan Gunarathne Technical Lead WSO2 Inc. (http://wso2.com<http://wso2.com/>) email : gay...@wso2.com<mailto:gay...@wso2.com> | mobile : +94 766819985
