Open Stack

On Fri, Oct 11, 2013 at 8:40 PM, Clint Byrum <clint at fewbar.com> wrote:


> > 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.
>
>
Yes, that's what I meant - metadata attached to configs rather than
instances.



>  > 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.
>
>
Murano's execution plans that are sent to Murano Agent are similar to
Python functions in that they have input and output. The output may be a
script exit code, captured stdout/stderr, value returned from
PowerShell/Python function etc. Although it is rare case where output from
one execution plan is required as an input for another plan but it happens.
For example execution plan 1 did created network interface on VM with DHCP
enabled and execution plan (that may be executed on another machine)
requires IP address obtained on that interface. In this case IP address
would be the returned value


> > 4. Ability to provide config body that is an input to Murano Agent of
> > arbitrary size
>
> Isn't this the same as 2?
>

Not exactly the same, but config body can be an attribute of config's
metadata with a special reserved name



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

This is indeed very promising. If Murano can do all the orchestration via
HOT templates and Heat doesn't deal with service metadata that is out of
scope of HOT we can eliminate most of the overlapping between projects and
actually complement each other. The only thing I concerned about in this
context is
https://wiki.openstack.org/wiki/Heat/DSL2 and
https://wiki.openstack.org/wiki/Heat/Open_API as this is very similar to
what Murano does


-- 
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131012/7e6a529a/attachment.html>