[[ 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
deltacloud-devel@lists.fedorahosted.org