[Container-tools] Fwd: OpenStack keynotes (Tuesday)

[Nick Coghlan]

On 28 May 2015 at 01:37, Dave Neary <dneary at redhat.com> wrote:
> Hi Nick,
>
> On 05/27/2015 02:48 AM, Nick Coghlan wrote:
>> My initial impression is that they seem to be targeting completely
>> different problems, with the only point of overlap being the
>> underlying need to describe complex multi-service applications.
>
> Yes - that point of overlap is what the user cares about, I think.

If portability of the description format is specifically what a user
cares about, they're more likely to go with the OASIS TOSCA spec
(which has a YAML based format at
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html)
than they are to go with either Nulecule *or* Murano.

>> Nulecule is aimed at delivering application deployment instructions
>> *as containers*. So if you're using containers to deploy something,
>> you pull the deployment instructions down the same way you would pull
>> the service itself. It's a pluggable specification, so your image
>> needs to support your orchestration and container providers, but you
>> aren't coupled to any particular infrastructure-as-a-service layer.
>>
>> Looking at Murano (specifically
>> https://murano.readthedocs.org/en/latest/draft/appdev-guide/step_by_step.html),
>> it seems to instead be aimed specifically at OpenStack environments,
>> including being able to plug in to the Horizon Dashboard for
>> provisioning purposes.
>
> I think that's exactly right. The messaging for Murano may end up as:
> "if you're managing hybrid infrastructure (bare metal, containers, VM
> instances) then you can use the same tool across all of them, using
> OpenStack, with Murano as your application definition tool".

A pure OpenStack environment isn't really a hybrid cloud. Most
non-trivial hybrid infrastructure is going to include a public cloud
component that *isn't* based on OpenStack (i.e. AWS, GCE, Azure), and
a lot is going to end up including private IaaS components that aren't
based on OpenStack either (e.g. vSphere, RHEV).

That's why Nulecule *isn't* OpenStack specific (nor even Kubernetes
and Docker specific, although those are the initial providers in the
AtomicApp implementation). You don't want your management layer to be
coupled directly to one specific IaaS layer, you want something that
can be used across multiple IaaS providers.

> That seems like a powerful message if we see containers as an additional
> instance type for OpenStack, whereas the "pure container" method of
> CoreOS & Atomic Platform may make more sense if it's entirely green
> field.

It's the other way around - you can run Kubernetes and other container
management systems on any IaaS, so an IaaS independent approach to
container management is a better fit for a hybrid cloud than saying
"you must be using OpenStack as your IaaS layer".

> I'm not sure which of those is true, but if I'm moving
> infrastructure to OpenStack and I have the opportunity to embrace Docker
> without changing my management tooling, I think I'd like that option.

Sure, but this is the standard situation for any general purpose
abstraction layer vs niche specific tooling. If someone is going "all
in" on OpenStack based infrastructure, then OpenStack specific tools
are going to be appealing, just as lots of folks choose Windows
specific tools or Linux specific tools after first standardising their
choice of OS.

If folks want to keep their options open, then a more technology
neutral format like Nulecule is likely to be appealing.

>> It seems to me that being able to automatically derive a Murano app
>> definition from a Nulecule file would be a useful capability when
>> using OpenStack based infrastructure, but that Murano isn't even
>> trying to match Nulecule's IaaS independence.
>
> Yes, I think that would be awesome.

Rather than offering conversion directly to Murano, it potentially
makes sense to use TOSCA as a pivot point, by supporting
Nulecule->TOSCA conversion, with a subsequent conversion from
TOSCA->Murano (perhaps provided by the Murano folks).

However, I don't know how lossy that path would be (I'm not
sufficiently familiar with the 3 formats to know the representational
limits of each). If going via the OASIS standard format as an
intermediate step loses too much information, then a direct conversion
may be necessary until the OASIS TC catch up (and that's assuming
Murano itself doesn't gain the capacity to consume both the TOSCA and
Nulecule formats).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia