Thanks for these details Melijn, So you want to be able to describe a topology without deploying it, and you also want to be able to record that topology so that it can be reused.
Both of these are good ideas, and the juju concept that supports both of these at once is called "stacks". It's not yet implemented, but it's being debated for a long time (since the first sprint, to be honest) and will come eventually. Bundles are a weak form of stack that was introduced organically into the project while the full fledged concept isn't in place. If it depended just on me bundles wouldn't exist, to be honest, but they solved a few real problems while stacks aren't available. Unfortunately they also took away some of the urge to have the proper implementation in place, but we know what to do and it will come. On Fri, Aug 7, 2015 at 5:41 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Gustavo > > > Thank you for your response. I'll explain two TOSCA concepts I find very > interesting and would like to use in Juju. > > > # Separation of Topology VS Plans. > > In TOSCA, you can define a topology (what services you want and how to > connect them) independent from Plans (How to implement these services, what > Charms to use). This enables the provider (Juju) to decide what > implementation to use. So for example, say your infrastructure needs a > MySQL database, and you can define this need without saying how to setup > the database. In this example, Juju has two possibilities: either it > deploys a MySQL Charm, or it puts the database in an existing MySQL Charm. > This flexibility isn't possible because making a topology and choosing the > implementation of that topology is the same in Juju: You connect Charms. > > This concept could be used to automate a lot of tasks an administrator > currently has to do himself. > > > # Composition of service templates > > In TOSCA, a service can consist of a collection of services and relations. > In Juju you only have two layers: Charms and bundles. It would be great if > you could make a Charm that consists of a bundle. Other Charms can have > relations with that Charm bundle as if it was a single Charm. The bundle > itself decides how these relations translate into relations with individual > Charms of that bundle. > > An example of this would be the data analytics bundle: > https://jujucharms.com/data-analytics-with-sql-like/6 > When using this bundle as part of a setup, you have to have certain > knowledge about what the individual Charms do. This is because you have to > decide yourself how to plug it into the other infrastructure. This isn't > that complex with a bundle consisting of 4 Charms, but bundles are bound to > become more complex, with the Openstack Telemetry (19 Charms) as an > example: https://jujucharms.com/openstack-telemetry/31 > > > > I'm looking forward to reading your thoughts on this. > Merlijn > > > 2015-08-06 18:05 GMT+02:00 Gustavo Niemeyer < > gustavo.nieme...@canonical.com>: > >> Hi Merlijn, >> >> On Thu, Aug 6, 2015 at 12:00 PM, Merlijn Sebrechts < >> merlijn.sebrec...@gmail.com> wrote: >>> >>> I've been using Juju for a while now and I came across TOSCA. TOSCA is >>> an OASIS open standard that can be used to model the full life-cycle of >>> cloud applications. >>> >>> As stated before, the TOSCA concepts are very similar to Juju. >>> >> >> The initial tosca gatherings happened shortly after we released working >> juju code, so that's not too surprising. >> >> >>> I'm wondering if there are any plans surrounding Juju and TOSCA. I see >>> that Canonical is part of the TOSCA TC. Are there any plans to bring TOSCA >>> and Juju closer together? TOSCA's move to yaml is already a big leap in the >>> right direction... >>> >>> I see that a TOSCA-Juju translator project >>> <https://github.com/juju/juju-tosca> exists, however I do not know what >>> the state of that project is. I am also more interested in a native >>> implementation of some of the TOSCA concepts since there are big advantages >>> in having a tosca-like representation of a running cloud, beyond what Juju >>> already offers. >>> >> >> What real advantages do you perceive in that sense? >> >> We're constantly designing and improving juju, so that sort of feedback >> is very welcome. Our last planning sprint happened just last week. >> >> >> gustavo @ http://niemeyer.net >> > > -- gustavo @ http://niemeyer.net
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
