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

[Johannes Wettinger]

Hi Clint,

On Fri, Aug 24, 2012 at 12:51 AM, Clint Byrum <clint at ubuntu.com> wrote:
> 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'.

Thanks for this hint. I think I'll have a deeper look into juju-jitsu.

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

This is in complete contrast to TOSCA. The design of TOSCA doesn't
consider that fact at all. It's nearly impossible to write and keep
TOSCA service templates consistent "manually."

> No, a series is
>
> charms/precise/mysql
> charms/precise/wordpress
> charms/precise/haproxy
>
> The "precise" series are charms related by their underlying OS.

Ok, but what is the consequence for creating charms? Is a particular
charm always dependent on the OS that is represented by the series it
belongs to? That means, as maintainer of a charm I would have to
provide a separate charm for each series (Ubuntu "precise", Windows 7,
Fedora "beefy", etc.).

Wouldn't it make more sense to try to make charms as portable and
re-usable as possible?

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

I see the intention of Juju. But for some use cases it might be more
appropriate to deliver a number of implementations for a single hook
in a charm. Here's again the example I outlined before:

mainfest.yaml
  hooks:
    install:
      install-windows.bat: windows
      install-ubuntu.sh: ubuntu
      install-centos.sh: centos, redhat

Of course this should be optional. So it is still possible to put all
the conditional logic into a single hook implementation.

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

Right, but as I said before, if there are a number of hook
implementations delivered inside a charm, Juju can automatically
decide which one to take (based on the platform and if a configuration
management tool like Chef or Puppet is available).

>> 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}
>
> I don't see a concrete use case there.

Just one example: I already mentioned the need for custom hooks. This
is already addressed here: https://bugs.launchpad.net/juju/+bug/809070

Let's say we have a "backup-database" hook and the underlying
infrastructure is managed by Chef. To do the backup we have to assign
a "backup" recipe to a particular node. This can be done by a REST
call to the Chef server as outlined above.

Johannes