<div dir="ltr">Hi,<br><br>I am really glad to see the line of thinking close to what we at Murano see as a right direction for OpenStack development. This is a good initiative which potentially will be useful for other projects.  We have very similar idea about repository in Murano project and we even implemented the first version of it. We are very open for collaboration and exchanging the ideas.<br>
<br><br>In terms of overlap with Murano, I can see the overlap in the area of Murano Metadata Repository. We already have done some work in this area and you can find the detailed description here <a href="https://wiki.openstack.org/wiki/Murano/SimplifiedMetadataRepository">https://wiki.openstack.org/wiki/Murano/SimplifiedMetadataRepository</a>. The implementation of the first version is already done and we plan to include the implementation in Murano 0.4 release which will go out in a week.<br>
<br><br>For the future roadmap with more advanced functionality we have created etherpad:  <a href="https://etherpad.openstack.org/p/MuranoMetadata">https://etherpad.openstack.org/p/MuranoMetadata</a><br><br><br>My concerns around Heater lie in two areas:<br>
<br>- Fit for OpenStack Orchestration program<br><br>- Too narrow focus as it formulated right now making hard for other projects like Murano take advantage of this services as general purpose metadata repository<br><br><br>
I am not sure how metadata repository related to orchestration program as it does not orchestrate anything. I would rather consider creating separate Service Catalog/Metadata Repository program or consider storage programs like Glance or Swift as Heater has the similar feature set. If you replace “template” with “object” you will actually propose a new swift implementation with replacing existing Swift’s versioning, acl, and metadata for objects.<br>
<br><br>Murano as Application Catalog also could be a fit, but I don’t insist :)<br><br><br>At the current moment Heat is not opinionated about template placement and this provides a lot of flexibility for other projects which use Heat under the hood. With your proposal, you are creating new metadata repository solution for specific use case of template storage making Heat much more prescriptive.<br>
<br><br>Combined with TC policy which enforces projects to use existing code, this could be a big problem because other projects might want to keep not only Heat template but other components and metadata. Murano is a good example for that. It has multiple objects associated with Application and Heat template is only one of them.  That would mean that other projects would either need to duplicate the functionality of the catalog or significantly restrict their own functionality.<br>
<br><br>The most scary thing for me is that you propose to add metadata information to the HOT template. In Murano we keep UI information in a separate file and this provides us a flexibility how to render UI for the same Heat template in different Applications. This is a question of separation of concerns as Heat as a deployment orchestration should not interfere to UI.<br>
<br><br>As a conclusion I propose:<br><br>- Have a session between Heater and Murano teams to exchange ideas and brainstorm architecture to address common use cases<br><br>- Consider to make the service a bit more independent from Heat and create more general purpose Metadata Repository/Catalogue service to be used by different projects as backend to store different type of metadata information, including but not limiting to Heat templates<br>
<br><br><br><br>On Wed, Dec 4, 2013 at 7:40 PM, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>><br>> On 5 December 2013 15:55, Steve Baker <<a href="mailto:sbaker@redhat.com">sbaker@redhat.com</a>> wrote:<br>
><br>> > Yes, point taken.<br>> ><br>> > heat-core does a reasonable job of keeping up with review load, so there is<br>> > not yet a bottleneck. However the load is taken by a small team which would<br>
> > definitely need to grow if we were to take on a new project.<br>><br>> Yup.<br>><br>> > There are certainly some reviewers who will be ready for nomination soon if<br>> > they continue increasing their review volume:<br>
> > <a href="http://russellbryant.net/openstack-stats/heat-reviewers-30.txt">http://russellbryant.net/openstack-stats/heat-reviewers-30.txt</a><br>> ><br>> > It may be appropriate to relax the core review approval to a single +2 on<br>
> > heatr in the early stages of the project.<br>><br>> I think thats ultimately counterproductive. Folk can build on<br>> in-progress patches when they really need to - gerrit supports that.<br>><br>> <a href="http://russellbryant.net/openstack-stats/heat-openreviews.html">http://russellbryant.net/openstack-stats/heat-openreviews.html</a><br>
><br>><br>> Stats since the last revision without -1 or -2 :<br>><br>> Average wait time: 1 days, 11 hours, 41 minutes<br>> 1rd quartile wait time: 0 days, 18 hours, 47 minutes<br>> Median wait time: 1 days, 1 hours, 23 minutes<br>
> 3rd quartile wait time: 1 days, 16 hours, 6 minutes<br>><br>> So, 75% of patches are sitting for more than a day before being looked<br>> at at all : thats says to me that Heat could use more core reviewers<br>
> (many hands, light work) - ideally with a distributed project like us,<br>> most things would be looked at in 9-12 hours or less; however these<br>> figures are much happier than nova, and nova still achieves pretty<br>
> good velocity!<br>><br>> -Rob<br>><br>><br>><br>> --<br>> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>> Distinguished Technologist<br>> HP Converged Cloud<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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br><br><br><br>--<br>Georgy Okrokvertskhov<br>Technical Program Manager,<br>Cloud and Infrastructure Services,<br>Mirantis<br><a href="http://www.mirantis.com">http://www.mirantis.com</a><br>Tel. +1 650 963 9828<br>Mob. +1 650 996 3284</div>