[openstack-dev] Avoiding regression in project governance

Georgy Okrokvertskhov gokrokvertskhov at mirantis.com
Wed Mar 11 17:55:48 UTC 2015

Some clarification about Murano:

>3. *Maybe*. Not sure about the scope, it is fairly broad and there may be
some open ended corners, >such as some references to billing. On the other
hand an application catalog sounds really useful >and like a measured
progression for OpenStack as a whole. Murano may overlap with glance's
>stated mission of  "To provide a service where users can upload and
discover data assets that are >meant to be used with other services, like
images for Nova and templates for Heat."

Glance mission was changed with active help from Murano team side as Murano
needs to have a storage for Applications definitions. That is why one of
the Murano engineers right now is working on landing Artifact repository
which was initially drafted in Murano team and then re-architected to be
useful for other projects like Heat and Nova. Once artifacts are landed in
Kilo release[all patches are on review] Murano will use Glance to store all
packages and related objects, so there will be no any overlap with Glance.

>Murano also relies heavily on the Mistral service which is still in
stackforge itself.
This is a wrong perception. Murano currently does not use Mistral at all.
It will use it once cross project initiative Congress-Murano-Mistral will
be implemented. Right now Murano works without Mistral installed. Murano
will use congress and Mistral to offload some of the logic outside of
Murano to have very simple life-cycle workflows controlled by policies and
Mistral flows.


On Wed, Mar 11, 2015 at 7:28 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2015-03-10 23:00:16 +0000 (+0000), Devananda van der Veen wrote:
> > Many of those requirements were subjective (well tested, well
> > documented, etc) and had to be evaluated by the TC. Are these the
> > sort of tags you're referring to? If so, and if the TC delegated
> > responsibility to manage the application of those tags (say, QA
> > team manages the 'well-tested' tag), would that be sufficient?
> [...]
> Yep, that's exactly what I'm hoping for. But without those in place
> yet I worry that we'll end up turning away lots of new requests for
> help from projects coming forward thinking they're suddenly entitled
> by virtue of "being OpenStack" and not really have any common
> criteria to point them at so that they can work toward getting more
> priority.
> --
> Jeremy Stanley
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Georgy Okrokvertskhov
OpenStack Platform Products,
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/20150311/4cc04c7c/attachment.html>

More information about the OpenStack-dev mailing list