<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 2:27 PM, Thomas Herve <span dir="ltr"><<a href="mailto:thomas.herve@enovance.com" target="_blank">thomas.herve@enovance.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br>
>> What I can say is that I'm not convinced. The only use-case for a DSL would<br>
>> be if you have to upload user-written code, but what you mentioned is a Web<br>
>> interface, where the user doesn't use the DSL, and the cloud provider is the<br>
>> developer. There is no reason in this case to have a secure environment for<br>
>> the code.<br>
><br>
> I didn't say that. There are at least 2 different roles application<br>
> developers/publishers and application users. Application developer is not<br>
> necessary cloud provider. The whole point of AppCatalog is to support<br>
> scenario when anyone can create and package some application and that<br>
> package can be uploaded by user alone. Think Apple AppStore or Google Play.<br>
> Some cloud providers may configure ACLs so that user be allowed to consume<br>
> applications they decided while others may permit to upload applications to<br>
> some configurable scope (e.g. apps that would be visible to all cloud users,<br>
> to particular tenant or be private to the user). We also think to have some<br>
> of peer relations so that it would be possible to have application upload in<br>
> one catalog to become automatically available in all connected catalogs.<br>
><br>
> This is similar to how Linux software repos work - AppCatalog is repo, Murano<br>
> package is what DEB/RPMs are to repo and DSL is what DEB/RPMs manifests are<br>
> to packages. Just that is run on cloud and designed to handle complex<br>
> multi-node apps as well as trivial ones in which case this may be narrowed<br>
> to actual installation of DEB/RPM<br>
<br>
</div>I'm glad that you bring packages up. This is a really good example of why you don't need a new programming language. Packages uses whatever technology they prefer to handle their scripting needs. They then have an declarative interface which hides the imperative parts behind.<br>
<br></blockquote><div><br><div>The same is true for Murano. MuranoPL is not used to express what
should be deployed. In Murano there is object model that describes view
of the word. It serves for the same purpose as HOT in Heat but it is
simpler because it says just what need to be deployed but not how it
should be accomplished as this information is already contained in application definitions. There is REST API to edit/submit Object
Model which is again has nothing to do with MuranoPL. UI dashboard talks
to AppCatalog to see what applications/classes are available and
AppCatalog also knows what are the properties of those classes. This is
needed for UI so that it can ask user for appropriate input. This is
similar to how Horizon asks user to input parameters that are declared
in HOT template. But all the imperative stuff is hidden inside Murano
packages and is not used for anything outside Murano engine. MuranoPL is
not a replacement for scripting languages. You still use bash/puppet/PowerShell/whatever you like for actual deployment. No MuranoPL code is executed on VM side. So the analogy with RPMs manifests is valid. <br><br></div>
<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You trust OpenStack developers with their code, you trust package developers with their code, why not trust catalog developers?<br></blockquote><div><br></div><div>They do trust catalog developers (hopefully). But catalog developers have nothing to do with catalog contents. Anyone can create and upload application to App Catalog the same way how anyone can upload his application to Google Play. The fact that I trust Google doesn't mean that I trust all applications in Google Play. The fact that I trust catalog developers doesn't mean that I (as a cloud operator) is going to allow execution of untrusted code in that catalog. Unless that code is sandboxed by design. Similar to that I can navigate to any web site google points me out and let it execute any JavaScript it wants unless it it JavaScript and not browser plugin or desktop application.<br>
</div><div><br></div><br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
--<br>
Thomas<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>
</div></div></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:10pt;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></div>