Open Stack

Thierry,


	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.


Best,



--Randy

Founder & CEO, Cloudscaling
Board of Directors, OpenStack Foundation
+1 (415) 787-2253 [SMS or voice] 
TWITTER: twitter.com/randybias
LINKEDIN: linkedin.com/in/randybias
CALENDAR: doodle.com/randybias









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.
> 
> Cheers,
> 
> -- 
> Thierry Carrez (ttx)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140210/a1792a4b/attachment.html>