Open Stack

> I would like the Murano project to evaluate the upcoming heat
> software-config resources to represent app configuration.

Yes, we are closely watching progress being made in Heat in that area and
evaluating how all new great features can be used in Murano

> Inferring from the above, it sounds like Murano is transforming an app
> definition into a single flat heat template.

It is just not that simple. Murano by itself neither generates any
templates nor deploys applications. Murano is just App Catalog.

Application definitions that Catalog consists of are more then just a
declarations. They also contains imperative executable parts written in
Murano DSL language.
Murano itself can be viewed as a runtime for application manifests.

Murano engine provides carefully designed APIs for DSL code to access Heat
and other OpenStack services. Those APIs are more restrictive and safe than
native OpenStack APIs (provided by various python-clients) and DSL cannot
access OpenStack services by any means other than those APIs. Heat API is
one of them. With this API DSL can access Heat stack and make some changes
in it.

It is up to Murano users (software publishers) who fill AppCatalog to
decide how and if to use Heat. They are free to use Heat just for
infrastructure-level management and do software config by some external
tools or use new software-config in Heat or even directly talk to Nova,
Trove etc.
But no matter how application decides to implement it, Murano must
guarantee that DSL code of one app cannot damage or compromise OpenStack
resources that belongs to another app. So even if new Heat feature makes
life easier we still need to guarantee safe behavior of DSL when using old
Heat template syntax or older Heat version that doesn't have that feature.




On Sun, Feb 23, 2014 at 11:50 PM, Steve Baker <sbaker at redhat.com> wrote:

> On 22/02/14 03:37, Stan Lagun wrote:
> > Hi Everyone,
> >
> > While looking through Heat templates generation code in Murano I've
> > realized it has a major design flaw: there is no isolation between
> > Heat resources generated by different apps.
> >
> > Every app manifest can access and modify its environment stack in any
> > way. For example it can delete instances and other resources belonging
> > to other applications. This may be not so bad for Murano 0.4 but it
> > becomes critical for AppCatalog (0.5) as there is no trust relations
> > between applications and it may be unacceptable that untrusted
> > application can gain complete write access over the whole stack.
> >
> > There is also a problem of name collisions - resources generated by
> > different applications may have the same names. This is especially
> > probable between resources generated by different instances of the
> > same app. This also affects Parameters/Output of Heat templates as
> > each application instance must generate unique names for them (and do
> > not forget them later as they are needed to read output results).
> >
> > I think we need at least to know how we going to solve it before 0.5
> >
> > Here is possible directions i can think of:
> >
> > 1. Use nested Heat stacks. I'm not sure it solves naming collisions
> > and that nested stacks can have their own Output
> >
> > 2. Control all stack template modifications and track which resource
> > was created by which app. Give applications read-only access to
> > resources they don't own
> >
> > 3. Auto-generate resource names. Auto-add prefixes/suffixes to
> > resource/output etc names indicating owning app instance ID and remove
> > them upon read access from workflow so that generated names would be
> > invisible to workflow. That would also mean all VMs  would have
> > generated names
> >
> > Hope to see better ideas and suggestions in this thread
> >
> I would like the Murano project to evaluate the upcoming heat
> software-config resources to represent app configuration.
> Some patches are still in review [1][2] and I expect more changes before
> feature freeze, but now would be a good time for Murano to get involved
> to validate that software-config meets your needs.
>
> The current implementation of the SoftwareDeployment resource actually
> has the same issue mentioned above; any authenticated user can currently
> create a deployment which results in software being deployed to any
> server in that tenant/project. There may be times where this is useful,
> but there will soon be a default policy enforced which ensures that the
> deployment resource and the server resource belong to the same stack.
>
> Inferring from the above, it sounds like Murano is transforming an app
> definition into a single flat heat template. Using a combination of
> resource providers and software config should give you a significantly
> cleaner model, and you may even find that some of the problems you're
> solving in Murano are now solved in the Heat layer.
>
> [1]
>
> https://review.openstack.org/#/q/status:open+topic:bp/hot-software-config-rest,n,z
> [2]
>
> https://review.openstack.org/#/q/status:open+topic:bp/hot-software-config,n,z
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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/20140224/b6fe6f07/attachment.html>