[openstack-dev] [heat] Heater Proposal
gokrokvertskhov at mirantis.com
Fri Dec 6 01:11:42 UTC 2013
Thank you for your feedback here.
Let me reply to your questions:
Q: Do you mean to imply that a repository of orchestration templates is a
bad fit for the orchestration program?
A: Yes. Its the same situation as we have with Glance. Glance is a
repository of images for Nova but it is a separate project slightly coupled
with nova. Here you are trying to build template storage service which is
reasonable but it not necessarily a part of orchestration program because
it stores something which might be used with Heat. I think that it will be
fair to say that Heater mission does not fit to Orchestrate program mission.
Q:Doesn't that same argument hold for Murano Metadata Repository as well?
A: Yes. With the current implementation of metadata service in Murano it
mostly falls to the same area as Glance and Swift. We plan to rewrite it
because we need more functionality that we have right now. If you take a
look to the etherpad with further roadmap you will see that we plan to move
from simple storing to transformation of metadata and related objects. And
this is driven by the goals of Application Catalog.
And I want to highlight that again, I like the idea of template storage,
but I just had some concerns about its specific implementation and some
implications which might appear when you put it as a part of existing Core
On Thu, Dec 5, 2013 at 3:04 PM, Randall Burt <randall.burt at rackspace.com>wrote:
> On Dec 5, 2013, at 4:08 PM, Georgy Okrokvertskhov <
> gokrokvertskhov at mirantis.com>
> 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
> 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
> 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 <robertc at robertcollins.net>
> > On 5 December 2013 15:55, Steve Baker <sbaker at 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
> > > 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
> > > 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 <rbtcollins at hp.com>
> > Distinguished Technologist
> > HP Converged Cloud
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
Technical Program Manager,
Cloud and Infrastructure Services,
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev