I'd say it depends on how much we need to expose from those APIs to make
the feature usable at a portable level.
For me, it would make sense to expose a separate API (or an extension like
the Image or SecurityGroup ones) to manage the scale groups/whatever, and
have portable template options to al
An interesting thing regarding something like a common scale set API, would
it be a separate API or more like a parameter in “builder” — for instance
if creating more than one VM?
I’m planning on looking at the Rackspace implementation of this and help
Julio flesh things out.
-jim
On September
Features start at the provider level and percolate into the portable
abstraction when enough providers support them. We generally use a
"rule of three" to ensure that the abstraction exposes the correct
feature set.
jclouds is a community project and does not have a road map like
corporate-sponso
Hi Julio
Is this email address been monitored?
These emails have ended up in our moderation queue but should have been
released successfully - at least, I've seen the previous one and your
follow-up come through, and they also appear in the list history.
You may wish to subscribe to the li
Hi Jcloud Devs...
Is this email address been monitored?
Julio
From: Julio Colon
Sent: Friday, August 25, 2017 10:15 AM
To: 'dev@jclouds.apache.org'
Subject: Common Scale Set API
Hi,
I am extending the Azure provider in jclouds to include Azure Virtual Machine
Scale Sets. There are other pro
