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
