If to use that we currently have a path conflict with GET /cartridges/{filter}
This was added to remove the different methods we used to have earlier - /cartridges/multitenant , /cartridges/singletenant and cartridges/loadbalancer However now since we have also introduced a "category" field as well - we need to think how to retrieve cartridges of a specific category as well Means - we need to rethink the cartridge resource urls - Is there still a need to get cartridges based on the filtering of singletenant, multitenant and loadbalancer ? AFAIK this categorization is based on various fields in the cartridge - do we need to add another field to identify these - if we redo the cartridge urls as below GET /cartridges = gets all GET /cartridges/{cartridgeType} = gets a cartridge based on key GET /cartridges/category/{filter} = gets based on singletenant, mt, lb, provider and also the various categories (data, framework etc..} GET /cartridges/category/{filter}/{cartridgeType} = gets a specific within the above - this seems redundant with the specific cartridge method above would this cater to all required scenarios ? On Sun, Dec 14, 2014 at 10:49 PM, Imesh Gunaratne <im...@apache.org> wrote: > > The problem we have here is that cartridge type is the key of the > cartridge entity. IMO we should be able to retrieve the entity using the > key. > > Thanks > > On Sun, Dec 14, 2014 at 7:24 PM, Shiroshica Kulatilake <sh...@wso2.com> > wrote: >> >> >> The resource url supported now is >> >> GET /cartridges/{category}/{cartridgeType} >> >> On Sun, Dec 14, 2014 at 12:25 PM, Imesh Gunaratne <im...@apache.org> >> wrote: >>> >>> Hi Shiro, >>> >>> I found a problem with GET cartridges method: >>> Now it is not possible to get cartridges for a given cartridge type: >>> >>> GET /cartridges/{cartridgeType} >>> >>> Thanks >>> >>> On Thu, Dec 11, 2014 at 12:19 PM, Shiroshica Kulatilake <sh...@wso2.com> >>> wrote: >>>> >>>> This was actually an effort from many contributers - so should thank >>>> everyone ! :) >>>> >>>> We still have to do some more work to make this perfect >>>> 1. Make the responses also consistent - >>>> https://issues.apache.org/jira/browse/STRATOS-1028 >>>> 2. We also should consider what to do with the v4.0 REST api - most of >>>> the operations are not valid anymore >>>> 3. CLI needs to be updated >>>> >>>> On Thu, Dec 11, 2014 at 12:14 PM, Lakmal Warusawithana <lak...@wso2.com >>>> > wrote: >>>> >>>>> Yes, this is great, very clear now. Thanks Shiro. >>>>> >>>>> On Thu, Dec 11, 2014 at 11:54 AM, Reka Thirunavukkarasu <r...@wso2.com >>>>> > wrote: >>>>> >>>>>> 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 definition >>>>>>>>>> GET/groupsGet all created group definitionsGET >>>>>>>>>> /groups/{groupDefinitionName}Gets a specific group definition >>>>>>>>>> DELETE/groups/{groupDefinitionName}Delete a group definition >>>>>>>>>> >>>>>>>>>> *4. Applications* >>>>>>>>>> >>>>>>>>>> Resource pathDescriptionGET/applicationsGets all applications >>>>>>>>>> createdGET/applications/{applicationId}Gets a specific >>>>>>>>>> applicationPOST/applicationsCreate an application definition >>>>>>>>>> DELETE/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 created >>>>>>>>>> GET/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 >>>>>>>>>> usersPUT/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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Lakmal Warusawithana >>>>> Vice President, Apache Stratos >>>>> Director - Cloud Architecture; WSO2 Inc. >>>>> Mobile : +94714289692 >>>>> Blog : http://lakmalsview.blogspot.com/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> Shiroshica Kulatilake >>>> >>>> Architect, >>>> WSO2, Inc. http://wso2.com/ >>>> Phone: +94 776523867 >>>> >>> >>> >>> -- >>> Imesh Gunaratne >>> >>> Technical Lead, WSO2 >>> Committer & PMC Member, Apache Stratos >>> >> >> >> -- >> Shiroshica Kulatilake >> >> Architect, >> WSO2, Inc. http://wso2.com/ >> Phone: +94 776523867 >> > > > -- > Imesh Gunaratne > > Technical Lead, WSO2 > Committer & PMC Member, Apache Stratos > -- Shiroshica Kulatilake Architect, WSO2, Inc. http://wso2.com/ Phone: +94 776523867