[OpenStack Foundation] The two types of interoperability
randyb at cloudscaling.com
Mon Feb 10 19:44:30 UTC 2014
I’m in violent agreement on this one. Interoperability can’t be perfect and looking somewhere other than OpenStack’s infrastructure components has real value. I have felt for a while that Heat should become the lingua franca for how applications are bootstrapped onto a cloud. Can a tool like Heat help us with creating applications that “run anywhere” either by being able to interrogate an OpenStack cloud for capabilities (e.g. how many NICs does a VM get?) and pass that data on to tools like Chef/Puppet or RightScale/Dell Cloud Manager?
I think it can. I remember Dell Cloud Manager (née enStratius) would interrogate a cloud for capabilities, but perhaps presenting cloud capabilities (starting with the “POSIX” type baseline that Defcore is driving towards + additional changes specific to that cloud) is a better approach. Better yet, having something like Heat being able to push the cloud capabilities information into whatever framework they are bootstrapping (Chef/Puppet, Cloud Foundry / Apprenda / Stackato / PaaS of whatever kind, etc.) would be ideal.
There will still be challenges in terms of QoS/SLAs being different, but at least you could always load an app written in this manner. It might also allow automated continuous integration with a variety of OpenStack reference architectures.
Founder & CEO, Cloudscaling
Board of Directors, OpenStack Foundation
+1 (415) 787-2253 [SMS or voice]
On Feb 7, 2014, at 1:27 AM, Thierry Carrez <thierry at openstack.org> wrote:
> Randy Bias wrote:
>> I see it as a simple issue: we either stifle choice OR we facilitate
>> choice and compromise on interoperability.
> Yes, that's another way to frame the question. My point in the original
> email is that I know there are, in OpenStack, strong proponents of both
> end goals. We shouldn't delay anymore that necessary discussion on what
> should be our common long-term goal.
> That said, I like Nicolas's point about the various types of trademark
> usage (project names, distributions, deployments) and that slightly
> different rules could be used for each of those. I also agree with Boris
> that trademark usage is not the only weapon we could use to encourage
> portability of workloads. And I like your point that even in the case of
> "total interoperability", specific deployment choices will affect
> portability, so unless you build architectural clones (which I think
> nobody actually wants), interoperability will never be perfect.
> To come back to your point, IMHO there is value in maximizing the
> *feature set* that is common between deployments, even if deployment
> architectures differ. You might need to adjust your workload to go from
> a flat to a multi_host deployment, or have your app support both cases.
> But if you rely on Heat API on the first one and the other one doesn't
> propose Heat at all, you just have to rewrite your workload completely.
> Thierry Carrez (ttx)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Foundation