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] Commented: (CAMP-11) Expression of Scaling Policy

    [ http://tools.oasis-open.org/issues/browse/CAMP-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35832#action_35832 ] 

Anish Karmarkar commented on CAMP-11:

I suggest we close w/ no action (CNA).
Issue 9, which is related, has been resolved.
I don't think we are going to standardize a portable scaling policy for version 1.1. The best we can do is to provide some examples of how it can possibly be done. Scaling, especially auto-scaling is going to be a big vendor value-add and there are variety of ways to do it. Issue 9 does address how one could use operations for user-initiated scaling. We have the right structure in place for discovery and metadata. I believe this is enough for v1.1. If examples are needed this should go in supporting documentation/implementation notes, not in the spec.

> 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
>            Assignee: Alex Heneveld
> 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]