Great work Shiro..!!! The paths are very consistent now.. Thanks, Reka
On Thu, Dec 11, 2014 at 11:37 AM, Mariangela Hills <mariang...@wso2.com> wrote: > I will update the wiki! > > Regards, > Mariangela > > > > > *--* > Mariangela Hills > Senior Technical Writer > > *WSO2, Inc.*lean.enterprise.middleware. > m: +94 773 500185 > w: http://wso2.com > <http://wso2.com/events/> > > On Thu, Dec 11, 2014 at 10:59 AM, Imesh Gunaratne <im...@apache.org> > wrote: > >> Great work Shiro! We might need to update the Wiki with this. >> >> Thanks >> >> On Wed, Dec 10, 2014 at 4:29 PM, Nirmal Fernando <nirmal070...@gmail.com> >> wrote: >> >>> Great work Shiro on seeing this through !! >>> >>> On Wed, Dec 10, 2014 at 3:14 PM, Shiroshica Kulatilake <sh...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> >>>> The Stratos REST api has been modified as follows. >>>> >>>> *1. Autoscaling Policies* >>>> >>>> Resource pathDescriptionPOST/autoscalingPoliciesCreates a new >>>> autoscaling policyGET/autoscalingPoliciesGets all created autoscaling >>>> policiesGET/autoscalingPolicies/{autoscalePolicyId}Gets a specific >>>> autoscaling policyPUT/autoscalingPoliciesUpdates an existing >>>> autoscaling policy >>>> >>>> *2. Cartridges* >>>> >>>> Resource pathDescriptionPOST/cartridgesCreate a new cartridge >>>> definitionGET/cartridgesGet all available cartridgesGET >>>> /cartridges/{filter}?criteria=criteriaGet all available cartridges for >>>> a particular filter valueGET/cartridges/{filter}/{cartrdigeType}Get a >>>> specific cartridge within a filter valueDELETE >>>> /cartridges/{cartridgeType}Delete a specific cartridge definition >>>> - The filter methods in cartridge are to filter cartridges by specifc >>>> values. >>>> e.g. /cartridges/multiTenant would give a list of all multitenant >>>> cartridges >>>> Similar values which can be used are - "singleTenant", >>>> "loadBalancer" and "provider" >>>> - In the case of filtering cartridges by provider it is also needed to >>>> specify the provider name - so in this case you would need to specify that >>>> using the query parameter criteria >>>> e.g. /cartridges/provider?criteria=<value> >>>> >>>> *3. Groups* >>>> >>>> Resource pathDescriptionPOST/groupsCreate a new group definitionGET >>>> /groupsGet all created group definitionsGET >>>> /groups/{groupDefinitionName}Gets a specific group definitionDELETE >>>> /groups/{groupDefinitionName}Delete a group definition >>>> >>>> *4. Applications* >>>> >>>> Resource pathDescriptionGET/applicationsGets all applications created >>>> GET/applications/{applicationId}Gets a specific applicationPOST >>>> /applicationsCreate an application definitionDELETE >>>> /applications/{applicationId}Delete an application definition >>>> >>>> *5. Application Deployments* >>>> >>>> Resource pathDescriptionPOST/applicationDeploymentsDeploys an >>>> application for a deployment policyDELETE >>>> /applicationDeployments/{applicationId}Undeploys a specific >>>> application based on application id >>>> - The resource ApplicationDeployments were introduced to identify the >>>> deployment of a particular application according to a deployment policy >>>> - The deplolyment policy json is sent with the POST command >>>> >>>> *6. Deployment Policies* >>>> >>>> Resource pathDescriptionGET/deploymentPoliciesGet all deployment >>>> policiesGET/deploymentPolicies/{deploymentPolicyId}Gets a specific >>>> deployment policyGET >>>> /deploymentPolicies/{deploymentPolicyId}/partitionGroupGets partition >>>> groups for a specific deployment policy >>>> - Deployment policies are not created separately - instead when a POST >>>> /applicationDepoyment with the deployment policy json is sent that >>>> deployment policy is created. >>>> >>>> *7. Subscriptions* >>>> >>>> Resource pathDescriptionGET/subscriptions/{applicationId}Gets >>>> subscriptions for an applicationGET >>>> /subscriptions/cartridges/groups/{serviceGroupId}Gets subscribed >>>> cartridges for a service group >>>> >>>> *8. Clusters * >>>> >>>> Resource pathDescriptionGET/clustersGet Clusters for a tenantGET >>>> /clusters/{cartridgeType}Get clusters for a specific cartridge typeGET >>>> /clusters/{clusterId}Get a specifc cluster >>>> >>>> *9. Kubernetes clusters* >>>> >>>> Resource pathDescriptionPOST/kubernetesClustersDeploy a Kubernetes >>>> cluster groupPUT/kubernetesClusters/{kubernetesClusterId}/minionDeploy >>>> a Kubernetes Host within a cluster groupPUT >>>> /kubernetesClusters/{kubernetesClusterId}/masterDeploy a Kubernetes >>>> Master within a cluster groupPATCH >>>> /kubernetesClusters/{kubernetesClusterId}/minion/{minionId} >>>> GET/kubernetesClustersGets all Kubernetes cluster groups createdGET >>>> /kubernetesClusters/{kubernetesClusterId}Gets a specific Kubernetes >>>> clusterGET/kubernetesClusters/{kubernetesClusterId}/hostsGets hosts of >>>> a specific Kubernetes clusterGET >>>> /kubernetesClusters/{kubernetesClusterId}/masterGet master of a >>>> specific Kubernetes clusterDELETE >>>> /kubernetesClusters/{kubernetesClusterId}Undeploy a kubernetes cluster >>>> groupDELETE/kubernetesClusters/{kubernetesClusterId}/hosts/{hostId}Undeploy >>>> a specific host within a Kubernetes cluster group >>>> - the PATCH command is still in discussion hence it has not been >>>> changed yet. It is still the old path "/kubernetes/update/host" - a TODO. >>>> >>>> *10. Tenants* >>>> >>>> Resource pathDescriptionPOST/tenantsAdd a new tenantGET/tenantsGet all >>>> tenantsGET/tenants/{tenantDomain}Get a specific tenantGET >>>> /tenants/search/{tenantDomain}Search for a tenantsPUT/tenantsUpdate a >>>> tenantPUT/tenants/activate/{tenantDomain}Activate a tenantPUT >>>> /tenants/deactivate/{tenantDomain}Deactivate a tenantDELETE >>>> /tenants/{tenantDomain}Delete a tenant >>>> >>>> *11. Users* >>>> >>>> Resource pathDescriptionPOST/usersAdd a new userGET/usersGet all users >>>> PUT/usersUpdate a userDELETE/users/{userName}Delete a user >>>> >>>> >>>> *Example* : To create a single group application where the cartridges >>>> are vms (I'm reusing the script used to test grouping) using the rest api >>>> is as follows. >>>> >>>> 1. Create an autoscaling policy >>>> - curl -X POST -H "Content-Type: application/json" -d @<AS policy >>>> json file> -k -v -u admin:admin >>>> https://localhost:9443/api/autoscalingPolicies >>>> 2. Create cartridges >>>> - curl -X POST -H "Content-Type: application/json" -d @<cartridge >>>> json file> -k -v -u admin:admin https://localhost:9443/api/cartridges >>>> 3. Create group >>>> - curl -X POST -H "Content-Type: application/json" -d @<group json >>>> file> -k -v -u admin:admin https://localhost:9443/api/groups >>>> 4. Create application >>>> - curl -X POST -H "Content-Type: application/json" -d @<application >>>> json file> -k -v -u admin:admin https://localhost:9443/api/applications >>>> 5. Deploy the application >>>> - curl -X POST -H "Content-Type: application/json" -d@<deployment >>>> policy json file> -k -v -u admin:admin >>>> https://localhost:9443/api/applicationDeployments >>>> >>>> *Please note :-* Referring to the above email The separation between >>>> creation of a deployment policy and deployment of an application is not >>>> available in the alpha version of Stratos 4.1.0. >>>> >>>> >>>> Thank you, >>>> Shiro >>>> >>>> On Tue, Dec 9, 2014 at 1:29 AM, Shiroshica Kulatilake <sh...@wso2.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> In order to create a flow and to figure out the required minimal set >>>>> of REST apis for application handling thought of breaking down the actions >>>>> up to deploying and undeploying an application in Stratos as follows. >>>>> >>>>> 1. Create cartridges needed >>>>> - POST /cartridges with cartridgeDefinition.json >>>>> 2. View created cartridges or a specific cartridge >>>>> - GET /cartridges, /cartridges/{category}/{criteria}, >>>>> /cartridges/{category}/{cartrdigeType} >>>>> 3. Create an autoscaling policy >>>>> - POST /autoscalingPolicies with autoscalingPolicyDefinition.json >>>>> 4. Viewing created Autoscaling policies >>>>> - GET /autoscalingPolicies, /autoscalingPolicies/{autoscalePolicyId} >>>>> 5. Create a service group definition >>>>> - POST /groups with groupDefinition.json >>>>> 6. View created groups >>>>> - GET /groups, /groups/{groupDefinitionName} >>>>> 7. Create an application >>>>> - POST /applications >>>>> 8. Viewing created application >>>>> - GET /applications/, /applications/{applicationId} >>>>> 9. Create a deployment policy for an application >>>>> 10. View deployment policy >>>>> - GET /deploymentPolicies/{deploymentPolicyId} >>>>> 11. Deploy an application with the deployment policy >>>>> 12. Undeploy an application >>>>> 13. Delete deploymentPolicyDefinition >>>>> 14. Delete an applicationDefinition >>>>> >>>>> >>>>> Currently what's missing from the above is another entity which >>>>> depicts an applicationDeployment. >>>>> >>>>> Then /applications will simply handle the definitions and >>>>> /applicationDeployments should handle the actual deploy and undeployment >>>>> of >>>>> an application based on a deployment policy. >>>>> >>>>> Since a deployment policy is directly linked to an application it >>>>> should be possible to get all deployment policies defined for a specific >>>>> application and then pick one of these for the actual application >>>>> deployment. >>>>> >>>>> Most of this is already there in the current rest api with different >>>>> naming. I am working on getting the terminology correct and also add the >>>>> few missing bits. >>>>> >>>>> Thank you, >>>>> Shiro >>>>> >>>>> >>>>> >>>>> On Mon, Dec 8, 2014 at 7:08 PM, Imesh Gunaratne <im...@apache.org> >>>>> wrote: >>>>> >>>>>> +1 We might need to clarify how we connect a deployment policy to an >>>>>> application according to this model. >>>>>> >>>>>> On Mon, Dec 8, 2014 at 5:40 PM, Lakmal Warusawithana <lak...@wso2.com >>>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Dec 8, 2014 at 4:55 PM, Shiroshica Kulatilake < >>>>>>> sh...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> While cleaning up the REST API I noticed that we have used the word >>>>>>>> "deploy" instead of 'create' in some places. >>>>>>>> >>>>>>>> We need to use these terms consistently IMO >>>>>>>> >>>>>>>> As a first start thought of renaming the api methods in the rest >>>>>>>> api to reflect this. >>>>>>>> >>>>>>>> e.g. >>>>>>>> Policies = create/delete instead of deploy/undelpoy >>>>>>>> Cartridges = create/delete instead of deploy /undeploy >>>>>>>> Groups = create/delete instead of deploy/undelpoy >>>>>>>> Applications = create, deploy, undeploy and delete >>>>>>>> >>>>>>>> WDYT ? >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Shiro >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Shiroshica Kulatilake >>>>> >>>>> Architect, >>>>> WSO2, Inc. http://wso2.com/ >>>>> Phone: +94 776523867 >>>>> >>>> >>>> >>>> >>>> -- >>>> Shiroshica Kulatilake >>>> >>>> Architect, >>>> WSO2, Inc. http://wso2.com/ >>>> Phone: +94 776523867 >>>> >>> >>> >>> >>> -- >>> Best Regards, >>> Nirmal >>> >>> Nirmal Fernando. >>> PPMC Member & Committer of Apache Stratos, >>> Senior Software Engineer, WSO2 Inc. >>> >>> Blog: http://nirmalfdo.blogspot.com/ >>> >> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007
