OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (CAMP-11) Expression of Scaling Policy


     [ http://tools.oasis-open.org/issues/browse/CAMP-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Chapman  updated CAMP-11:
--------------------------------

    Description: 
Annex A leaves scaling largely as a vendor specific definition. However, more detail would be useful for those interested in building a basic level of a scale-out model that will work regardless of platform vendor selection. It should be worthwhile to define how a scaling policy could be expressed in a portable format, and perhaps a basic extension mechanism to allow service providers to implement scaling models of varying sophistication.

The specification could define a way to express a scaling policy in the PDP so that an auto-scaling application can still be portable between service providers. The exact implementation of the scaling may vary considerably, but the basic concepts for a policy, a scale-up event trigger, a scale-down event trigger, and some form of a callback that relates to each of the events.

For maximum portability, some standard meanings for the contents of the policy would also be useful.

This issue is related to https://tools.oasis-open.org/issues/browse/CAMP-9

This issue was raised by Adrian Otto and was drupal issue 1065.
-------
When the issues was opened the following clarifications of the issues was added:

Service providers implementing a CAMP platform would like to be able to offer auto-scale as a feature. Provide some facilities that allow a policy to be expressed within the platform, perhaps when an application assembly is instantiated, that will describe which policy should be used for managing that assembly.
Furthermore, we would like to be able to allow CAMP to manage an auto-scale policy so that those service providers can offer the service in a way that allows that policy to be portable between CAMP platforms.

  was:
Annex A leaves scaling largely as a vendor specific definition. However, more detail would be useful for those interested in building a basic level of a scale-out model that will work regardless of platform vendor selection. It should be worthwhile to define how a scaling policy could be expressed in a portable format, and perhaps a basic extension mechanism to allow service providers to implement scaling models of varying sophistication.

The specification could define a way to express a scaling policy in the PDP so that an auto-scaling application can still be portable between service providers. The exact implementation of the scaling may vary considerably, but the basic concepts for a policy, a scale-up event trigger, a scale-down event trigger, and some form of a callback that relates to each of the events.

For maximum portability, some standard meanings for the contents of the policy would also be useful.

This issue is related to https://tools.oasis-open.org/issues/browse/CAMP-9

This issue was raised by Adrian Otto and was drupal issue 1065.
-------
When the issues was opened the following clarifications of the issues was added:

Service providers implementing a CAMP platform would like to be able to offer auto-scale as a feature. Provide some facilities that allow a policy to be expressed within the platform, perhaps when an application assembly is instantiated, that will describe which policy should be used for managing that assembly.


> Expression of Scaling Policy
> ----------------------------
>
>                 Key: CAMP-11
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-11
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: New Feature
>          Components: Spec
>            Reporter: Anish Karmarkar
>
> Annex A leaves scaling largely as a vendor specific definition. However, more detail would be useful for those interested in building a basic level of a scale-out model that will work regardless of platform vendor selection. It should be worthwhile to define how a scaling policy could be expressed in a portable format, and perhaps a basic extension mechanism to allow service providers to implement scaling models of varying sophistication.
> The specification could define a way to express a scaling policy in the PDP so that an auto-scaling application can still be portable between service providers. The exact implementation of the scaling may vary considerably, but the basic concepts for a policy, a scale-up event trigger, a scale-down event trigger, and some form of a callback that relates to each of the events.
> For maximum portability, some standard meanings for the contents of the policy would also be useful.
> This issue is related to https://tools.oasis-open.org/issues/browse/CAMP-9
> This issue was raised by Adrian Otto and was drupal issue 1065.
> -------
> When the issues was opened the following clarifications of the issues was added:
> Service providers implementing a CAMP platform would like to be able to offer auto-scale as a feature. Provide some facilities that allow a policy to be expressed within the platform, perhaps when an application assembly is instantiated, that will describe which policy should be used for managing that assembly.
> Furthermore, we would like to be able to allow CAMP to manage an auto-scale policy so that those service providers can offer the service in a way that allows that policy to be portable between CAMP platforms.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]