Open Stack

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

- 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


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.


Murano as Application Catalog also could be a fit, but I don’t insist :)


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.


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.


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.


As a conclusion I propose:

- Have a session between Heater and Murano teams to exchange ideas and
brainstorm architecture to address common use cases

- 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




On Wed, Dec 4, 2013 at 7:40 PM, Robert Collins <robertc at robertcollins.net>
wrote:
>
> 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
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 <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,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131205/45f250e2/attachment.html>