Open Stack

Stefano, Hart,

>
> > No, I do not agree. An OpenStack application does not need to live on
> > 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.
>

I agree with you here. What I meant by trying to define OpenStack
application for this particular conversation is that apps which "#1. can be
run on OpenStack and #2. live in Community App Catalog" are OpenStack
applications for sure. No doubt there are more useful OpenStack
Applications in the world. My intention though is to discuss those which
are/will be in the catalog.

It would be beneficial for apps developers and apps consumers if they have:
- single point to contribute to and to consume from (app catalog)
- some rules around who's responsible for application once it's in the
catalog, who maintains it, links to autotests and source code
- ability to collaborate on apps development (i.e. code review) (which is
the reason to organize repositories in a similar manner)
- editorial control (as both of you mentioned) on content of App Catalog

Speaking of editorial control, we'll need to find a balance between two
poles: 1. lightweight approach when everything at all is accepted, making
it very easy to contribute and share apps and 2. rigorous approach when
everything is reviewed, considered whether it's needed in catalog at all,
passes tests, have documentation, etc.

Each of the approaches has pros and cons and I personally think we need to
leverage both of them, similar to what's there in DockerHub.

We can have two workflows, one for Official/Supported/Curated apps which
are contributed using approach #2. At the same time for another category of
applications #1 will work just fine, ensuring that there are many
applications in the catalog and there are customers/consumers who'll
benefit from it.


>
> > 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 agree here as well. We can leverage existing experience of OpenStack
community on how to enable community around applications development,
enabling collaboration by means of code review, mailing lists, third party
CI for applications, IRC channels for collaboration. This would be a good
starting point.

By the way, one of the open questions where Foundation can potentially help
here is HW infra for CI/CD for apps development. None of the apps published
in the catalog so far has CI/CD associated with it.

The way we can proceed with some of the applications can be that publisher
of the application builds CI/CD system on their own HW as a third party CI.
However, for some of the apps it can be beneficial to have some HW pool
managed by Apps Community, not by Apps Publishers.


> > 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.
>

I agree again. As we discussed above, two approaches are possible here, #1
lightweight approach (register/login, push/update, done) and #2 official
(what we have now in Catalog actually) when an app is submitted for review,
reviewed by catalog team and finally gets accepted and published in the
catalog.

We can move from here incrementally, elaborating approach step by step,
namely:
1. Elaborate existing official approach - formulating requirements to
official apps (how they are QA'd, documented, whether source code needs to
be published, where it should be published, ...)

2. Start working on implementation of lightweight approach, keeping in mind
that we'll need a way to structure/rate applications for consumers so that
they don't get lost when there are too many of them. This is good to have
problem though, we are not yet there:)


>
> /stef
>
> _______________________________________________
> User-committee mailing list
> 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/243fccb2/attachment-0001.html>