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

[Kapil Thangavelu]

On Thu, Aug 23, 2012 at 2:04 PM, Clint Byrum <clint at ubuntu.com> wrote:

> Excerpts from Johannes Wettinger's message of 2012-08-23 08:56:48 -0700:
> > 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.
> >
>
> 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".
>
> > >> 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?
> >
>
> 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.)
>
> 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.
>
> > 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?
> >
>
> 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.
>


Some of this is possible already in a more adhoc fashion, via juju ssh unit
command. I've seen a few charms use this already to expose additional
service specific commands. Its definitely an open area for more development
imo to orchestra this execution (round robin, parallel, etc) and make it
accessible more readily from the core.

cheers,
Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20120824/f7ec24c6/attachment.html>