Thanks Lakmal,
From: Lakmal Warusawithana [mailto:lak...@wso2.com] Sent: Sunday, December 21, 2014 5:37 PM To: dev@stratos.apache.org Subject: Re: [Discuss] Kubernetes Work Flow for 4.1.0 Release On Mon, Dec 22, 2014 at 4:05 AM, Martin Eppel (meppel) <mep...@cisco.com<mailto:mep...@cisco.com>> wrote: Hi Imesh, As 4.1 will support grouping for VMs, will it also support docker containers and how will it integrate with (if at all) Kubernetes ? We have bring grouping and kubernetes into same work flow. Only deference is kubernetes does not have partitions. (in a network partition we only can have a single kub partition.) Kubernetes network partition is map to a kubernetes cluster. Other than that we can apply same work flow. And Cartridge run time map to a kubernetes pod. Same group scenarios can apply with kubernetes as well. Kubernetes APIs also changing very rapidly, we have not map all newly introduce kub features but will bring in eventually. Thanks Martin From: Imesh Gunaratne [mailto:im...@apache.org<mailto:im...@apache.org>] Sent: Sunday, December 21, 2014 10:06 AM To: dev Subject: Re: [Discuss] Kubernetes Work Flow for 4.1.0 Release Hi Devs, I have now completed the initial implementation of the KubernetesIaas and pushed changes to master branch. Functionality: - A member is mapped to a Kubernetes Pod. - A replication controller is created for each member. This is to avoid the following complications that may arise when a replication controller is mapped to a cluster: 1. Member specific payload parameters (member id, cluster instance id, etc) cannot be passed into the container. As a result instance status events and health statistics will not work properly. 2. If a container is healed by the replication controller on a failure, Stratos will not know about this event. As a result Stratos will not know the new pod id generated. 3. Since container failure handling is done by both Kubernetes and Autoscaler, migtht need to have proper logic to synchronize these actions. - At a later stage will do more research on the above concerns and try to map replication controller to a cluster to gain advantage of Kubernetes high availability, faulty member handling, etc features. - Dynamic member specific payload is passed to the container via environment variables. - Iaas interface startInstance(), terminateInstance(), setDynamicPayload() and getPartitionValidator() methods are implemented. Thanks On Sun, Dec 21, 2014 at 4:09 AM, Imesh Gunaratne <im...@apache.org<mailto:im...@apache.org>> wrote: 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<mailto:im...@apache.org>> wrote: Thanks for the feedback Lakmal! On Fri, Dec 19, 2014 at 7:54 PM, Lakmal Warusawithana <lak...@wso2.com<mailto: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<mailto: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<tel:%2B94714289692> 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 -- 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/
