Topology and Orchestration Specification for Cloud Applications (TOSCA) and Juju

[Johannes Wettinger]

Hi Gustavo,

thanks for your reply.

On Thu, Aug 23, 2012 at 10:30 AM, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
>> I'm currently doing some research and prototype implementation in the
>> field of Cloud standards. In particular, my work is strongly related
>> to an upcoming standard called "Topology and Orchestration
>> Specification for Cloud Applications" (TOSCA):
>> http://www.tosca-open.org
>
> Nice, thanks for reaching out. What's your involvement there, out of curiosity?

Currently, I'm doing my Master's thesis. The topic of my thesis is
about integrating DevOps methodologies into model-driven Cloud
management. TOSCA defines itself as being a means to enable
model-driven management of Cloud application whereas Juju is more
focused on the concerns of the DevOps movement. So, TOSCA and Juju
have a different background, but in the end they own similar meta
models. This is why I think integrating the two of them could make
sense.

>> Of course, TOSCA is much more complex
>> because of its highly generic approach to describe service models.
>> Just wondering if anyone here is familiar with TOSCA, too?
>
> I'd argue that the complexity doesn't come from the generality.

What do you think is the reason for the complexity of TOSCA's meta
model? As an example, let's take a look at the structure of node
types:

- NodeType "MySQL"
   - Interface "Lifecycle"
      - Operation "install"
         - ImplementationArtifact (type = "ScriptArtifact for Windows")
         - ImplementationArtifact (type = "ScriptArtifact for Linux")
      - Operation "configure"
      - Operation ...
   - Interface "Maintenance"
      - Operation "backup-database"
      - ...

First, there can be several implementation artifacts assigned to a
single operation, e.g. offering installation scripts for Windows,
Linux, etc. This makes a node type portable. How would you implement
this in Juju? You may have to implement two separate charms such as
"mysql-server-windows" and "mysql-server-linux", right? Thus, the
portability of a single charm is quite limited or did I miss
something?

Second, you can define arbitrary interfaces and operations in a node
type beside the default lifecycle operations (install, start, stop,
etc.). Hooks in Juju are basically limited to those lifecycle
operations. But what if you would like to implement maintenance
operations such as doing a backup of the database?

I think most of TOSCA's complexity is there because of its goal to be
general and highly portable.

>> What is your opinion of bringing these two worlds (TOSCA and Juju)
>> together? I mean wouldn't it make a lot of sense to support TOSCA
>> service templates in Juju? As an example, node types in TOSCA are
>> basically very similar to Juju's charms and lifecycle operations
>> including their implementation artifacts in TOSCA are quite similar to
>> hooks in Juju. :-)
>
> What an amazing coincidence. :-)
>
> I'd love to see people collaborating, but considering that there's a
> committee writing down a 40+ page specification that arbitrates how a
> system that looks a lot like juju might work in theory, I don't see a
> good path to do that. We can't simply stop producing working software
> to make it speak a language that nothing else does.

I completely agree! The goal cannot be to stop the development of
Juju. ;-) But wouldn't it make sense for Juju to be able to import
TOSCA node types as charms? Another use case could be to load a TOSCA
topology template as "Juju environment snapshot" or export a running
Juju environment as TOSCA topology template.

Of course there have to be made some assumptions regarding the TOSCA
node types and topology templates that are supported by Juju (e.g.,
only default lifecycle operations are supported). But I think this
would be completely valid, because a TOSCA engine doesn't have to
support any arbitrary node type. As a result, Juju would become a
TOSCA engine (supporting several TOSCA features) without changing its
internal meta model.

Johannes