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

[Johannes Wettinger]

On Thu, Aug 23, 2012 at 8:04 PM, Clint Byrum <clint at ubuntu.com> wrote:
> You're seeking to bring a development methodology (modeling) to
> operations. Seeing as DevOps is a movement to bring development and
> operations closer, it would seem that you could also say "TOSCA is
> focused on the concerns of the DevOps movement".

I agree, the goals of TOSCA are definitely linked to those of the
DevOps movement. But at the moment, TOSCA seems to focus more on
creating and consuming templates "as is". A typical use case for TOSCA
would be: vendor A provides a service template (including node types
and a topology template). Customer B takes the whole template and
deploys it to the cloud (public or private) using a TOSCA engine. The
instance model of a deployed topology template is not in the scope of
TOSCA.

Juju is a framework to dynamically create the topology at runtime
(instance model) by deploying charms and connecting them by adding
relations. Imho this is an important aspect of DevOps, namely to
dynamically modify the topology without having to modify the template
before and deploying the whole template again. But TOSCA does not have
this topic in its scope.

By the way, in contrast to Juju, TOSCA is not designed to create
service templates manually, i.e., writing XML or JSON in a simple text
editor. Of course, this could be done, but the complexity makes it a
tough task. Same vendors are working on tools providing a GUI to
create and modify such templates. From what I see in Juju, the
creation process for charms is designed in a way that charms are
usually being created manually by writing the manifest, scripts, etc.,
right?

> Charms are tied to a "series". Each series is developed and
> tested together as a whole to ensure that the various charms work
> together. Currently we are targetting releases of Ubuntu with each
> series of charms because we have not been presented with a compelling
> reason to do otherwise. (actually I haven't even been presented with
> any non-compelling reasons. I'm sure users are interested, but nobody
> is campaigning for other platforms.)

I see, this is similar to how packages are managed in Ubuntu itself. ;-)

> However, there is no reason we could not create a "portable" series of
> juju charms which do offer conditional logic based on platform. Because
> charms are only declarative at a very high level, they are quite flexible.

But how should this be implemented in practice? Assuming we have a
series of charms such as

- mysql-server (requires "mysql-server-implementation")
- mysql-server-ubuntu (provides "mysql-server-implementation")
- mysql-server-fedora (provides "mysql-server-implementation")
- mysql-server-windows (provides "mysql-server-implementation")

Is that what you meant by a "series of juju charms which do offer
conditional logic based on platform"? Because from what I understood,
a hook inside a charm is a binary, i.e. a shell script, a python file
or anything else which can be executed. As a result, a hook of a
particular charm cannot be a platform-independent artifact (e.g., a
binary that runs on both Windows and Linux). The consequence is that
we cannot have any conditional logic based on platform inside a hook,
can we?

Wouldn't it make sense to put the type of the hook into the
manifest.yaml? Example:

hooks:
  install: puppet-manifest
  start: puppet-manifest
  stop: puppet-manifest

By doing this, a single charm could get portable. Juju would have to
run puppet using the puppet manifests delivered as hooks in a
particular charm.

> https://bugs.launchpad.net/juju/+bug/809070
>
> It has been on the list for a while. There is a simple workaround which
> is to do arbitrary operations in the config-changed hook.

Makes sense. Another aspect that is covered by TOSCA for which I
couldn't find an equivalent in Juju so far is the following: hooks
inside charms are always "script operations" (in the language of
TOSCA), i.e., an executable binary. But in TOSCA it's also possible to
define a REST operation. In Juju this would be a hook (a
platform-dependent binary) that implements a REST call.

By introducing hook types as outlined before this could be also
implemented in a portable manner:

hooks:
  register: rest-call
    method: get
    uri: #{register_uri}
    header: #{register_header}
    body:  #{register_body}

Then Juju would be responsible to perform the call.

> It does seem like our two groups will do well to stay in contact with
> one another, as we'll probably both have great ideas for how multi-host
> cloud systems can be managed. Just like we have charms which use existing
> puppet modules to implement system configuration, I could see us have
> charms that effectively just import a TOSCA node description and run the
> actions defined within as part of the hooks of the charm. That might be
> an interesting exercise as the library of TOSCA node descriptions grows.

The approach you outlined here would be to embed a TOSCA node type
into a Juju charm like embedding Puppet/Chef artifacts as hooks into a
charm, right? From an architectural point of view it might be also
interesting to convert a node type definition into a charm because
they are conceptually quite on the same level. For Puppet/Chef
artifacts it makes much more sense to embed them, no doubt.

Johannes