I have now committed the initial modifications to support this functionality:
This includes following changes: - Introduced KubernetesIaas class - Removed Cartridge.deployerType - Fixed Member.instanceId property conflict by introducing Member.clusterInstanceId - Now Member has two properties: instanceId -> id generated by the Iaas, clusterInstanceId -> cluster instance id of the application hierarchy - Updated all instance status and member events with the above change - Updated python cartridge agent with the above event change - Updated health statistics events, stream definitions, event publishers with instance_id -> cluster_instance_id attribute change - Updated CloudControllerService.createInstance() method by introducing a new parameter class "InstanceContext". Earlier this method accepted MemberContext as the incoming parameter so that it was difficult to identify which parameter values are required to create an instance. I'm currently working on functionality in KubernetesIaas class. Thanks On Sat, Dec 20, 2014 at 8:33 AM, Imesh Gunaratne <im...@apache.org> wrote: > Thanks for the feedback Lakmal! > > On Fri, Dec 19, 2014 at 7:54 PM, Lakmal Warusawithana <lak...@wso2.com> > wrote: > >> +1 Imesh, this is what in mind also. >> >> On Fri, Dec 19, 2014 at 7:35 PM, Imesh Gunaratne <im...@apache.org> >> wrote: >>> >>> Hi Devs, >>> >>> As we have now removed Kubernetes specific cluster monitoring logic in >>> Autoscaler we could now use standard Cloud Controller service methods for >>> managing VM instances and containers. This will make sure that Autoscaling >>> logic will work the same way for any type of a cartridge. >>> >>> The idea is to move Kubernetes specific logic to a new class called >>> KubernetesIaas and implement the Iaas interface. Consequently almost all >>> the features in the PaaS will work the same manner for MockIaas, Jclouds >>> Iasses and Kubernetes. This will give us an advantage of verifying >>> functionality with Mock Iaas and running against other Iaases without much >>> of a problem. >>> >>> This class can be defined in the Iaas Providers section in the cartridge >>> definition. The complete work flow of an application that uses Kubernetes >>> would be as follows: >>> >>> *Work Flow of an Application using Kubernetes:* >>> >>> 1. Register Kubernetes clusters. >>> 2. Define Kuberntes Iaas Provider in the cartridge, this will indicate >>> Stratos that the given cartridge needs Kubernetes support. >>> Cartridge -> Iaas Providers -> Kubernetes Iaas Provider >>> 3. Define Kuberntes clusters in the Network Partitions. All the >>> partitions in the above network partitions will use the same configuraiton. >>> Deployment Policy -> Network Partitions -> Kubernetes Cluster >>> 4. Define an application with the above cartrige >>> Application -> Cartridges >>> >>> According to the above configuration when Autoscaler asks Cloud >>> Controller to start an instance it will find the Iaas Provider in the >>> relevant partition and if it is Kubernetes it will find the Kubernetes >>> Cluster defined against the partition and use that information to start the >>> containers. Instance termination process would work the same way. >>> >>> I have now started implementing this logic, please add your thoughts. >>> >>> Thanks >>> >>> -- >>> Imesh Gunaratne >>> >>> Technical Lead, WSO2 >>> Committer & PMC Member, Apache Stratos >>> >> >> >> -- >> Lakmal Warusawithana >> Vice President, Apache Stratos >> Director - Cloud Architecture; WSO2 Inc. >> Mobile : +94714289692 >> Blog : http://lakmalsview.blogspot.com/ >> >> > > > -- > Imesh Gunaratne > > Technical Lead, WSO2 > Committer & PMC Member, Apache Stratos > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
