<div dir="ltr"><div><div><div><div><div><div>Steve, thank you for very valuable suggestions. Your block post is really great - I've read about environments in Heat documentation but didn't really understood them until now.<br>
<br></div>Usage of nested stacks may or may not solve my problem depending on what is possible to do within those stacks.<br></div>Let me explain with simple example.<br><br></div>As you probably know Murano uses Heat for all infrastructure-related operations. This means if some application from Catalog needs VM instance or any other type of OpenStack resource it creates it by inserting a snippet into user's Heat stack template and executes UPDATE STACK command.<br>
<br></div>Now suppose there is WordPress application published in App Catalog. WordPress app manifest says that it requires installation of MySql. There is also another application in AppCatalog called GaleraMySql that is known to be compatible with MySql. In Murano Dashboard user creates new environment (this corresponds to Heat stack and is not related to what is called environment in Heat)<br>
</div>and puts WordPress and GaleraMySql on it. Then he connects them so that GaleraMySql instance would be used in WordPress for MySql requirement.<br><br></div>WordPress and GaleraMySql were developed by different vendors that are not aware of each others presence. But because of unfortunate combination of circumstances both vendors chose to merge exactly the same snippet into user's stack:<br>
<div><br> "Resources": {<br> "myHost": {<br> "Type": "AWS::EC2::Instance",<br> "Properties": {<br> "InstanceType": "large",<br>
"ImageId": "someImage"<br> }<br> }<br> }<br><br><div><div><div>Then instead of 2 different VMs there would be only one. Things would be even worse if there was already resource "myHost" in user's stack.<br>
</div><div>It is more than a name-collision problem as incorrectly written application manifest can cause any imaginable harm to the stack.<br><br></div><div>The obvious solution would be to give each app dedicated nested stack and restrict it to that nested stack only. This would be a best solution. All I need is to have the same level of control on nested stack I have on outer stack - get stack template, modify and update them, access output attributes. Is it possible to retrieve nested stack template, modify it and populate it back to Heat?<br>
<br></div><div>Another option would be create separate top-level stacks for each app. But in Murano applications themselves composed of smaller parts and in practice this would lead to creation of dozen stacks with most of them containing single resource. And then we would have to implement transaction update between several stacks, coordinated deletion etc. This would also be bad from a user's point of view at he doesn't expect to find long list of stacks he has no idea where they came from.<br>
<br></div><div>My other options were on how nested stacks can be emulated on top of single stack by controlling which app created which resource and dynamically adjust resource names back and forth ("myHost" in example above) to some unique values in a way that is opaque to application<br>
</div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 21, 2014 at 8:20 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, Feb 21, 2014 at 06:37:27PM +0400, Stan Lagun wrote:<br>
> Hi Everyone,<br>
><br>
> While looking through Heat templates generation code in Murano I've<br>
> realized it has a major design flaw: there is no isolation between Heat<br>
> resources generated by different apps.<br>
<br>
</div>Can you define the requirement for "isolation" in more detail? Are you<br>
referring simply to namespace isolation, or do you need auth level<br>
isolation, e.g something enforced via keystone?<br>
<div class=""><br>
> Every app manifest can access and modify its environment stack in any way.<br>
> For example it can delete instances and other resources belonging to other<br>
> applications. This may be not so bad for Murano 0.4 but it becomes critical<br>
> for AppCatalog (0.5) as there is no trust relations between applications<br>
> and it may be unacceptable that untrusted application can gain complete<br>
> write access over the whole stack.<br>
<br>
</div>All requests to Heat are scoped by tenant/project, so unless you enforce<br>
resource-level access policy (which we sort-of started looking at with<br>
OS::Heat::AccessPolicy), this is expected behavior.<br>
<div class=""><br>
> There is also a problem of name collisions - resources generated by<br>
> different applications may have the same names. This is especially probable<br>
> between resources generated by different instances of the same app. This<br>
> also affects Parameters/Output of Heat templates as each application<br>
> instance must generate unique names for them (and do not forget them later<br>
> as they are needed to read output results).<br>
<br>
</div>A heirarchy of nested stacks, with each application defined as a separate<br>
stack seems the obvious solution here.<br>
<div class=""><br>
> I think we need at least to know how we going to solve it before 0.5<br>
><br>
> Here is possible directions i can think of:<br>
><br>
> 1. Use nested Heat stacks. I'm not sure it solves naming collisions and<br>
> that nested stacks can have their own Output<br>
<br>
</div>I think it does, and yes all stacks can have their own outputs, including<br>
nested stacks.<br>
<br>
Of particular interest to you may be the provider resource interface to<br>
nested stacks, which will allow you to define (via a series of nested stack<br>
templates) custom resource types defining each of your applications.<br>
<br>
See this old blog post, which will give you the providers/environments 101,<br>
and contains links to most of the related heat docs:<br>
<br>
<a href="http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html" target="_blank">http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html</a><br>
<div class=""><br>
> 2. Control all stack template modifications and track which resource was<br>
> created by which app. Give applications read-only access to resources they<br>
> don't own<br>
<br>
</div>I think we need more info on the use-case here, but perhaps you can either<br>
use the AccessPolicy resource, or we can work on defining an enhanced<br>
version which meets your requirements.<br>
<div class=""><br>
> 3. Auto-generate resource names. Auto-add prefixes/suffixes to<br>
> resource/output etc names indicating owning app instance ID and remove them<br>
> upon read access from workflow so that generated names would be invisible<br>
> to workflow. That would also mean all VMs would have generated names<br>
<br>
</div>Heat already does this internally, we create unique names for all your<br>
instances, unless you explicitly provide a name via the OS::Nova::Server<br>
"name" property.<br>
<br>
It might help if you could provide a really simplified example of the<br>
problem you are facing, or links to the real templates which we could<br>
review and make suggestions?<br>
<br>
Steve<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours<br>
Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"" lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>Moscow, Russia<br>Skype: stanlagun<br><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br><a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>
</div>