Open Stack

On Wed, May 18, 2016 at 4:54 AM, Igor Marnat <imarnat at mirantis.com> wrote:
> 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.
>

I think this is helping make it clear that you are not proposing
catalog content will be kept out if some committee does not deem it
worthwhile - only that "official/supports" assets would face more
scrutiny.  I agree with this, and it matches what we've been talking
about in the Community App Catalog for such things.

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

I think the issue here is that the apps do not have a defined testing
framework.  The existing OpenStack Infra could support checks for
things like Murano apps, we would just need to work out how to test
these applications.

I am really glad you started this thread and am in full support of the
initiative, but there's a huge piece lacking here around the testing.
Providing a CI/CD pipeline to app developers would be great, and we
already have an amazing pipeline available to us.  The issue is that
writing tests are hard, and coming up with a generic approach that
works for anything in the app catalog is impossible (i.e. murano tests
would look very different from glance tests).

Are there some great documentation resources we can point Murano
developers to for how to test Murano packages/apps?  That seems like
the place to start from my perspective, and that would better inform
the conversation around creating this CI/CD environment.

-Christopher

>
> 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
>
>
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>