Open Stack

Igor,
Yes. I sent the email to the two Murano’s representatives yesterday and will be driving the collaboration over the next few weeks.


From: Igor Marnat [mailto:imarnat at mirantis.com]
Sent: Wednesday, May 18, 2016 5:05 AM
To: Sun, Yih Leong <yih.leong.sun at intel.com>
Cc: user-committee at lists.openstack.org; product-wg at lists.openstack.org; enterprise-wg at lists.openstack.org
Subject: Re: [User-committee] [app] OpenStack Apps Community, several suggestions how to improve collaboration

Sun,
couple of comments from my side.

I'm extending this discussion to Enterprise/Product WG mail-list for the definition of "what is an OpenStack application".
An OpenStack application:
1. is an application that can be executed on an OpenStack cloud OR
2. is an application that utilize any of the OpenStack services

An example for (2), an application can be "decomposed" into multiple components where they are still "executed/deployed" on existing on-prem virtualization environment, however, one of the component can utilize an OpenStack service (e.g. Swift) by calling the swift api to read/write object storage.

It is not necessary that an OpenStack "must" lives in apps.openstack.org<http://apps.openstack.org>. This restricted definitions of an app.
However, an OpenStack App "can be" listed in apps.openstack.org<http://apps.openstack.org> for wider community to consume.

It is not necessary that an OpenStack "must" be either Murano, Heat, Glance, TOSCA template.
However, an OpenStack "can be" defined/orchestrated using Murano, Heat, Glance, TOSCA.
Agree with both.

And to those who are not aware, the Enterprise WG is currently working on a series of "workload reference architecture" for "application/workload" that can be executed on OpenStack Cloud (e.g. 3-tier, e-commerce, etc). I think this can be a good collaboration and to share/publish the Heat/Murano template of the reference architecture at the Community App catalog (apps.openstack.org<http://apps.openstack.org>).

AFAIK, Murano team's representatives attended Enterprise WG session in Austin, discussed this with WG and agreed to implement and publish in the Catalog reference implementation of "workload reference architecture" once it gets published by WG. Looking forward for that to happen.

The Community App Catalog need to have some extend of editorial control but without hindering the users from submission/contributing.
Do we have any validation environment that can "verify/test" the submitted app prior to publishing/listing on the catalog?
A commenting/rating system would definitely add value here.

We consider to implement validation environment as a third-party CI for some of the applications which we work for the Community App Catalog. Our final goal here is to provide application developer with an experience similar to what's there for OpenStack developers: review->CI/CD->publish.



-----Original Message-----
From: Stefano Maffulli [mailto:stefano at openstack.org<mailto:stefano at openstack.org>]
Sent: Tuesday, May 17, 2016 9:43 AM
To: user-committee at lists.openstack.org<mailto:user-committee at lists.openstack.org>
Subject: Re: [User-committee] [app] OpenStack Apps Community, several suggestions how to improve collaboration

On 05/17/2016 08:40 AM, Hart Hoover (hahoover) wrote:
> No, I do not agree. An OpenStack application does not need to live on
> apps.openstack.org<http://apps.openstack.org>. It can live anywhere. #1 (it runs on OpenStack) is
> all that matters.

Amen. This is one of those cases where OpenStack should go out of its boundaries, reach out to the existing communities and teach the way of doing things with openstack.

> Secondly, the last thing I want to deal with as a user of OpenStack is
> the Foundation's governance.

I agree here too. I would want the OpenStack community to help developers out there but stay very well out of the way in terms of governance and tools. Every application is unique, and OpenStack is unique too... any effort to put OpenStack models on top of others *will* fail.

I never thought of the Apps Catalog as anything more than a first attempt at a system to distribute a *curated* list of applications ready to be deployed on *some* OpenStack clouds. I put emphasis on curated (more below) and *some* because of Murano, Heat and TOSCA on one hand and Ceph+Nova on another... #interoperability-fail

The Application Developers community is in its infancy and Apps Catalog is only a tiny piece of it.

> Finally, who is responsible for the application once it's on
> apps.openstack? The original developer. OpenStack should continue to
> follow DockerHub's example (or if you prefer, the Chef Supermarket
> example) and link to source code elsewhere, and make it plain who
> wrote & maintains the app. Let anyone submit applications for the
> catalog with an OpenStackID - we should have less governance here, not
> more.

We can discuss about the details... It's not a good idea to trust the crowd without filtering (the crowd voted Barabbas :), I've heard many times that there is too much junk in DockerHub or the Supermarket, making them less valuable to the unexperienced users.

An OpenStack Apps Catalog without a strong editorial control would be even less valuable to many popular use cases than it is now.

Maybe you're thinking of something more lightweight than the Apps Catalog, like a simple aggregator of resources/apps with a lightweight commenting/rating system and links... I'd go with that.

/stef

_______________________________________________
User-committee mailing list
User-committee at lists.openstack.org<mailto:User-committee at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

_______________________________________________
User-committee mailing list
User-committee at lists.openstack.org<mailto:User-committee at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20160518/87a20fe0/attachment-0001.html>