Excerpts from Stan Lagun's message of 2013-10-11 07:22:37 -0700:
> Hello,
> Thanks Angus, Clint, I've got your design.
> It seems that Murano can built on top of that. With service metadata
> knowledge Murano can generate HOT templates with set of interdependent
> configs.
> Here is what will be needed:
> 1. Ability to implement support for custom software configuration tool
> (type: OS::SoftwareConfig::MuranoAgent)

These are really syntactic sugar, but you can implement them as resource
plugins for users who want Murano resources. In the absence of this,
just putting things in the free form metadata area of the resource that
the MuranoAgent can interpret would suffice.

> 2. Ability to provide arbitrary input values for the config

We already have that, there's a free-form json document called "metadata"
attached to every resource. Or maybe I missed what you mean here. The
new capability that is in the works that will make that better is to
have multiple reusable metadata blocks referenced on one instance.

> 3. Ability to return arbitrary (JSON-compatible) data structure from config
> application and use attributes of that structure as an input for other
> configs

Note that I'd like to see more use cases specified for this ability. The
random string generator that Steve Baker has put up should handle most
cases where you just need passwords. Generated key sharing might best
be deferred to something like Barbican which does a lot more than Heat
to try and keep your secrets safe.

> 4. Ability to provide config body that is an input to Murano Agent of
> arbitrary size

Isn't this the same as 2?

> 5. Work well with large graph of configs with a lot of dependencies.
> Independent configs on different VMs should be applied in parallel.

Yes this does look good. For dependent configs, the exsiting wait
condition can be used.

> Does it confirm to your plans?

I think it confirms that we're heading toward consensus on where to draw
the software config vs. infrastructure orchestration line. That is very
exciting. :)

OpenStack-dev mailing list

Reply via email to