[[ added libcloud-list to the recipients ]]
> - if this API is not implemented by the targetted cloud this mean
> the
> API and service have to run on some hardware on the user side.
> If we succeed, we become their cloud abstraction with the same
> expectations of high availability, we can't just become the single
> point of access/failure that they tried to avoid by implementing
> on
> the cloud, especially worrying if our service becomes stateful.
If you mean "we" in terms of Red Hat, Inc, being the canoncial
libcloud service provider, I agree, and we should try to avoid that.
But if SomeCorp wants to play with clouds, that can stand up an
instance of the libcloud service for their own corporation's usage.
They start out pointing it to EC2. As they grow and decide they want
an internal cloud, they boot up a farm of VMware/Xen/KVM/RHEV(?) and
add the appropriate driver. Even if they stay purely EC2, having the
middleman service within their own firewall helps auditability/
accountability.
> - particulary if the cloud provider change their API without
> notice, we
> get stuck, until we reverse engineer the changes and push the
> fixes
> to the user (and we know this can take a lot of time !).
> I don't see how we can provide APIs to isolate from EC2 without
> some
> kind of agreement with them, I don't know if and how that could
> be negociated [1]. On the other hand, if we get there then we have
> a substancial value to propose to people who are all building
> interfaces
> based on EC2 APIs, it's better to fix things in a single place, we
> get back to what allowed libvirt to work.
RightScale and others who build against EC2 have this same problem.
If we're ultimately sending money-paying consumers to EC2, I can only
imagine we will get *some* cooperation out of Amazon. Plus, amazon
does keep the "old" API versions around for a while when they release
new ones. The version is encoded in the API URL itself. Like any
other software builder, they want to avoid breaking backwards
compatibility.
> - Use case, we really need those, and we should get them from those
> cloud users (and possibly implementors). We already have a good
> one
> with the work done to provide JBoss on the cloud. Bryan sent
> another good scenario on the libcloud list today, but we need
> more.
> I would like to see a scenario where the cloud builder provides
> our API too, i.e. how things should be build assuming cooperation
> of the cloud implementor, because ultimately that how we would
> like
> it to be in the end, right ?
I'd almost think if the cloud provider providers "libcloud" API
directly, running one locally, as basically a proxy/pass-through would
still be a reasonable use-case for larger orgs. Pointing the clients
straight at a libcloud-based provider would work, of course, but you'd
end up losing the benefits of a centralized control within your
organization. Sorta like now, where many folks within RHT have their
own EC2 credentials and expense $42 every month, separately.
-Bob
