[
https://issues.apache.org/jira/browse/LIBCLOUD-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13828227#comment-13828227
]
Tomaz Muraus commented on LIBCLOUD-444:
---------------------------------------
Usually the work-flow when creating / proposing a new API is something like
this:
1. Spent a good deal of time researching and understanding the existing APIs.
2. Determine a common set of functionalists.
2. Prepare a proposal for the base API, send it to the mailing list for
comments.
3. Write a prototype driver for at least two different providers (the more the
better). Two are the minimum because if you only write one it's really easy to
make it biased against a single provider.
> Support scaling APIs
> --------------------
>
> Key: LIBCLOUD-444
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-444
> Project: Libcloud
> Issue Type: New Feature
> Components: Core
> Reporter: Brian Curtin
> Labels: features
>
> I propose to kick off a new package in the libcloud namespace, e.g.,
> libcloud.scaling, to support the various automatic scaling APIs that some
> providers are offering.
> * Amazon has had Auto Scaling available for some time now.
> * Rackspace released its Autoscale product to general availability today.
> * Azure supports Autoscale via its Management API.
> * I've found some Google documentation around autoscaling, but it seems more
> tied to AppEngine than GCE, so maybe not applicable here.
> At least Amazon and Rackspace's offerings are built on or make use of their
> CloudWatch and Cloud Monitoring products, respectively, so we'd probably want
> to create a package, e.g., libcloud.monitoring, as well. Azure
> I have to imagine the first step is getting to understand the various APIs
> and boiling down a common set of goals and functionality. Before going down
> that path, is there anything I should know?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
