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

[Clint Byrum]

Excerpts from Johannes Wettinger's message of 2012-08-23 13:44:04 -0700:
> 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.
> 

It sounds to me like TOSCA wants to encapsulate multiple services in one
template. Juju wants to encapsulate a single service description as a
charm. There is definitely a desire to have whole topologies of running
services. In fact, there's a side project, juju-jitsu, which has a proof
of concept way to do this with 'jitsu export' and 'jitsu import'.

> 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?
> 

There's no helper IDE to write charms, no. A big part of Juju's design
is to make these very easy to write.

> > 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,

No, a series is

charms/precise/mysql
charms/precise/wordpress
charms/precise/haproxy

The "precise" series are charms related by their underlying OS.

> 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?
> 

Any unix platform can take advantage of the "shebang" on script executables.
Those executables can definitely do

if $platform == 'Ubuntu':
  ...
elif $platform == 'NetBSD':
 ...

>From there the scripts can download and execute binaries for the necessary
platform, in exactly the same way the current scripts download a .deb for
amd64 or i386 based on the local architecture.

Windows could be handled in a number of ways, including a compat layer to
do the shebang running/translation on the fly.

The point is, there's nothing in Juju's *model* that prevents this. Its
more that the current user base is focused on configuring and defining
services. What OS runs underneath isn't really all that interesting in
most cases.

Anyway, we keep track of how juju works in various ways on other OS's here:

https://juju.ubuntu.com/docs/operating-systems.html

> 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.

Yeah thats an interesting approach too, but then we have to make juju
puppet aware, whereas right now, one can simply put that into 2 lines
of bash.

> 
> > 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.
> 

I don't see a concrete use case there.