<div dir="ltr"><div class="gmail_extra">Stefano, Hart,</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> No, I do not agree. An OpenStack application does not need to live on<br>
> <a href="http://apps.openstack.org" rel="noreferrer" target="_blank">apps.openstack.org</a>. It can live anywhere. #1 (it runs on OpenStack)<br>
> is all that matters.<br>
<br>
</span>Amen. This is one of those cases where OpenStack should go out of its<br>
boundaries, reach out to the existing communities and teach the way of<br>
doing things with openstack.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>It would be beneficial for apps developers and apps consumers if they have:</div><div>- single point to contribute to and to consume from (app catalog)</div><div>- some rules around who's responsible for application once it's in the catalog, who maintains it, links to autotests and source code</div><div>- ability to collaborate on apps development (i.e. code review) (which is the reason to organize repositories in a similar manner)</div><div>- editorial control (as both of you mentioned) on content of App Catalog</div><div><br></div><div>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.</div><div><br></div><div>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.  </div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Secondly, the last thing I want to deal with as a user of OpenStack<br>
> is the Foundation’s governance.<br>
<br>
</span>I agree here too. I would want the OpenStack community to help<br>
developers out there but stay very well out of the way in terms of<br>
governance and tools. Every application is unique, and OpenStack is<br>
unique too... any effort to put OpenStack models on top of others *will*<br>
fail.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Finally, who is responsible for the application once it’s on<br>
> apps.openstack? The original developer. OpenStack should continue to<br>
> follow DockerHub’s example (or if you prefer, the Chef Supermarket<br>
> example) and link to source code elsewhere, and make it plain who<br>
> wrote & maintains the app. Let anyone submit applications for the<br>
> catalog with an OpenStackID – we should have less governance here,<br>
> not more.<br>
<br>
</span>We can discuss about the details... It's not a good idea to trust the<br>
crowd without filtering (the crowd voted Barabbas :), I've heard many<br>
times that there is too much junk in DockerHub or the Supermarket,<br>
making them less valuable to the unexperienced users.<br>
<br>
An OpenStack Apps Catalog without a strong editorial control would be<br>
even less valuable to many popular use cases than it is now.<br>
<br>
Maybe you're thinking of something more lightweight than the Apps<br>
Catalog, like a simple aggregator of resources/apps with a lightweight<br>
commenting/rating system and links... I'd go with that.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>We can move from here incrementally, elaborating approach step by step, namely:</div><div>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, ...) </div><div><br></div><div>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:)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/stef<br>
<br>
_______________________________________________<br>
User-committee mailing list<br>
<a href="mailto:User-committee@lists.openstack.org">User-committee@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee</a><br>
</blockquote></div><br></div></div>