On Dec 5, 2013, at 4:08 PM, Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com<mailto:gokrokvertsk...@mirantis.com>> wrote:
Hi, 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. 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 https://wiki.openstack.org/wiki/Murano/SimplifiedMetadataRepository. 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. For the future roadmap with more advanced functionality we have created etherpad: https://etherpad.openstack.org/p/MuranoMetadata My concerns around Heater lie in two areas: - Fit for OpenStack Orchestration program Do you mean to imply that a repository of orchestration templates is a bad fit for the orchestration program? - 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 That's what the discussion around using Glance is about though. The proposal started out as a separate service, but arguments are being made that the use cases fit into Glance. The use cases don't change as their focused on templates and not general object cataloging, but that's something to sort if/when we land on an implementation. 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. Doesn't that same argument hold for Murano Metadata Repository as well? And, as initially proposed, its not a generic metadata repository but a template cataloging system. The difference maybe academic, but I think its important. That being said, maybe there's a case for something even more generic (store some meta information about some consumable artifact and a pointer to where to get it), but IMO, the arguments for Glance then become more compelling (not that I've bought in to that completely yet). Murano as Application Catalog also could be a fit, but I don’t insist :) It sounds to me like conceptually it would suffer from the same scoping issues we're already discussing though. 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. I'm not sure where this impression comes from. The Heat orchestration api/engine would in no way be dependent on the repository. Heat would still accept and orchestrate any template you passed it. At best, Heat would be extended to be aware of catalog urls and template id's, but in no way was it ever meant to imply that Heat would ever be modified to *only* work with templates from a catalog or require any of the catalog metadata to function in its core role as an orchestration engine. 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. Or Murano could also extend Glance functionality to include these sorts of composite artifacts similar to how Vish described earlier in the thread. 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. While I agree that things related to specific UI strategies don't really belong in the template, I think you may have misconstrued the example cited. As I understood it as a "if this then wouldn't we have to do this unsightly thing"? Could be that I misunderstood though, and in that case, yes. Having template data structures to accommodate *specific* UI implementations sounds bad to me, but things that are generic like parameter ordering or extended documentation things aren't specific to any particular UI IMO. As a conclusion I propose: - Have a session between Heater and Murano teams to exchange ideas and brainstorm architecture to address common use cases I think that's part of what this ML discussion is for. - 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 I believe that's the crux of the discussion around using Glance. On Wed, Dec 4, 2013 at 7:40 PM, Robert Collins <robe...@robertcollins.net<mailto:robe...@robertcollins.net>> wrote: > > On 5 December 2013 15:55, Steve Baker > <sba...@redhat.com<mailto:sba...@redhat.com>> wrote: > > > Yes, point taken. > > > > heat-core does a reasonable job of keeping up with review load, so there is > > not yet a bottleneck. However the load is taken by a small team which would > > definitely need to grow if we were to take on a new project. > > Yup. > > > There are certainly some reviewers who will be ready for nomination soon if > > they continue increasing their review volume: > > http://russellbryant.net/openstack-stats/heat-reviewers-30.txt > > > > It may be appropriate to relax the core review approval to a single +2 on > > heatr in the early stages of the project. > > I think thats ultimately counterproductive. Folk can build on > in-progress patches when they really need to - gerrit supports that. > > http://russellbryant.net/openstack-stats/heat-openreviews.html > > > Stats since the last revision without -1 or -2 : > > Average wait time: 1 days, 11 hours, 41 minutes > 1rd quartile wait time: 0 days, 18 hours, 47 minutes > Median wait time: 1 days, 1 hours, 23 minutes > 3rd quartile wait time: 1 days, 16 hours, 6 minutes > > So, 75% of patches are sitting for more than a day before being looked > at at all : thats says to me that Heat could use more core reviewers > (many hands, light work) - ideally with a distributed project like us, > most things would be looked at in 9-12 hours or less; however these > figures are much happier than nova, and nova still achieves pretty > good velocity! > > -Rob > > > > -- > Robert Collins <rbtcoll...@hp.com<mailto:rbtcoll...@hp.com>> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Technical Program Manager, Cloud and Infrastructure Services, Mirantis http://www.mirantis.com<http://www.mirantis.com/> Tel. +1 650 963 9828 Mob. +1 650 996 3284 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
