Open Stack

Colleagues,
let me share an update with our progress with initiative I sent across in
late May about improving our collaboration around development of OpenStack
applications and Community App Catalog. Several teams have been busily
working on it, including App Catalog team, Glare/Glance, Murano and Murano
Apps.

You can also find suggested plan and status update quoted below in the
second part of this etherpad
https://etherpad.openstack.org/p/OpenStackAppsCommunity.

*Suggested plan and progress with it*

*1. Introduce label openstack-apps, put repositories with source code of
OpenStack Apps under it, i.e.:*
  * http://git.openstack.org/cgit/openstack-apps/murano-apps
  * http://git.openstack.org/cgit/openstack-apps/heat-templates
  * http://git.openstack.org/cgit/openstack-apps/tosca-workflows
* Status: *
  OpenStack Infra team suggested not to introduce yet another label. Thus
we just changed ownership of
http://git.openstack.org/cgit/openstack/murano-apps repository to
murano-apps-core team. Didn't make progress with other projects (Heat,
Tosca), TBD if they need/want it.

Besides we agreed with OpenStack Infra that for complicated Murano
Applications we'll be creating and maintaining separated repositories,
specific for application (
http://lists.openstack.org/pipermail/openstack-dev/2016-June/096471.html).
I.e. we use http://git.openstack.org/cgit/openstack/murano-apps for simple
applications and dedicated repositories for mostly complex apps (i.e.
http://git.openstack.org/cgit/openstack/ci-cd-pipeline-app-murano).

*2. Agree with OpenStack Community App Catalog team on how content of App
Catalog is managed and by whom*
*Status:*
To change an approach to managing content in Community App Catalog we need
first to switch its backend to Glare. Current implementation of backend
doesn't allow to make changes in apps management workflow, it's mostly
manual and has to be done by App Catalog Core team. ETA for switching -
mid/end Aug, 2016 (work in progress).

There is a test instance of App Catalog based on Glare V 1.0,
http://r-ci.tk:8100. It is a very early version under development, can be
updated/turned off w/o prior notification. App Catalog team works on
implementation of existing App Catalog functionality based on this backend.

App Catalog team is about to start discussions on what new upload workflows
look like. Please follow [app-catalog] mailing list on openstack-dev or
come to #openstack-app-catalog in IRC for more information.

*3. Describe workflow of how to add source code of new application to
repositories, who approves its addition*
*Status: *
App Catalog team is about to start discussing this/working on it once
switched to new backend. Please follow [app-catalog] mailing list on
openstack-dev or come to openstack-app-catalog in IRC for updates.

*4. Introduce simplified workflow of publishing new Application to the
catalog:*
  * register/login
  * push/update
  * done
*Status:*
See #2, #3

*5. Introduce teams (core reviewers) contributing to/maintaining Murano
apps, Heat templates, ...*
*Status:*
Done for Murano (introduced murano-apps-core team):
http://lists.openstack.org/pipermail/openstack-dev/2016-May/096268.html

*6. Establish channels of communications with potential contributors
(mailing list, meetings, IRC/slack channel, ... ?)*
*Status:*
Introduced murano-apps IRC channel, rest will be added working on #3.

*7. Agree with contributors on QA process for applications and how we track
it in Community App Catalog:*
7.1 Get from Heat, Murano and TOSCA team list of documentation resources,
tools and best practices on QA of templates, apps and workflows
7.2 Make this list structured and visible for apps developers and apps
users in app-catalog documentation
7.3 Implement automated checks of apps integrity using tests/checks already
available in Heat, Glance, Murano, TOSCA
7.4 Discuss with Heat, Murano and TOSCA teams additions to their roadmaps
for verification tools for their assets

*Status:*
    Good progress with 7.3. Most of the results described below are work in
progress, still needs to be polished and documented. However, they allow to
understand progress and approach
    - implemented yaml + bash syntax check for Murano Apps (
https://review.openstack.org/#/c/344922/ )
    - implemented third-party CI for Murano Apps for
http://git.openstack.org/cgit/openstack/ci-cd-pipeline-app-murano (see for
example feedback from murano-ci-cd-bot in
https://review.openstack.org/#/c/316209/).
    - validation of TOSCA blueprints on upload to Glare v 1.0 using
tosca-parser (https://review.openstack.org/#/c/337633/). If template
doesn't pass validation it can't be uploaded to the catalog. To be
elaborated in the future based on new upload workflows we agree with
community.
    - validation of Heat templates and Glance images is being discussed
with Heat and Glance teams correspondingly

    Next steps - improve 7.3, work on 7.1, 7.2, 7.4, and to discuss with
OpenStack Infra an approach to switch CIs from third-party CIs to OpenStack
Infra CIs.


Regards,
Igor Marnat

On Wed, May 25, 2016 at 2:37 PM, Igor Marnat <imarnat at mirantis.com> wrote:

> Colleagues,
> having attended many sessions and talked to many customers, partners
> and contributors in Austin I’d like to suggest several improvements to how
> we develop OpenStack apps and work with the Community App Catalog (
> https://apps.openstack.org/).
>
> Key goals to achieve are:
> - Provide contributors with an ability to collaborate on OpenStack
> apps development
> - Provide contributors and consumers with transparent workflow to
> manage their apps
> - Provide consumers with information about apps - how it was developed
> and tested
> - To summarize - introduce the way to build community working on
> OpenStack apps
>
> *What is OpenStack application*
> OpenStack is about 6 years young and all these years discussions about
> it are in progress. Variety of applications is huge, from LAMP stacks
> and legacy Java apps to telco workloads and VNF apps. There is working
> group which works on a definition of "What is OpenStack application",
> hopefully community will agree on definition soon.
>
> For the sake of our discussion below let us agree on a simple approach:
> an OpenStack application is any software asset which 1. can be executed on
> an OpenStack cloud, 2. lives in apps.openstack.org.  So far there are
> Murano applications, Heat templates, Glance images and TOSCA templates.
>
> There are many good OpenStack applications in the world which don't live
> in OpenStack App Catalog. However, let us for now concentrate on those
> which do, just for the sake of this discussion.
>
> *Introduction to OpenStack development ecosystem*
> OpenStack was introduced about 6 years ago. Over these years
> community grown significantly. There were 8 companies contributing to
> OpenStack in Austin (1-st release). In Mitaka (13-th release) there were 64
> companies contributing.
>
> One of the reasons for this growth is the set of sophisticated tools
> the OpenStack contributor ecosystem has chosen to use or build to
> enable collaboration:
> - software repositories: http://git.openstack.org/cgit/openstack/nova,
> http://git.openstack.org/cgit/openstack/neutron, ..
> - bug trackers: https://launchpad.net/nova, https://launchpad.net/neutron
> , ...
> - same instance of gerrit for all the projects for code review:
> https://review.openstack.org/
> - gating test infrastructure http://zuul.openstack.org/
> - common approach to release management, repositories management,
> naming, tons of other things managed by review in
> https://review.openstack.org/#/q/status:open+project:openstack/governance
> - IRC channels, etherpads, meetings and mailing lists
> - governance to manage all of the above
>
> All of the above is what we can call OpenStack collaboration ecosystem
> and it is a key factor for OpenStack community success.
>
> *Introduction to OpenStack apps development ecosystem*
> Now when OpenStack is mature and have it up and running is not a big
> deal, focus of community and customers shifts from "how do I get a running
> cloud" to "what do I do with running cloud".
>
> Use cases of different cloud users are very different, however one
> can identify and develop standard building blocks which can be reused by
> cloud users (service providers, DevTest teams, ...). Many cloud users want
> to contribute their homegrown apps upstream because:
> - it allows to other people to use it and improve it
> - community can implement missing parts
> - community can help with testing and maintaining an app
>
> Year ago we introduced Community App Catalog for OpenStack
> http://apps.openstack.org as an integration/distribution point of
> customer experience/apps. This initiative is successful, there are about
> 100 software assets of various kinds which can be run on OpenStack. For
> further growth we need to make several changes in a way we approach
> collaboration around OpenStack Apps. Namely, we need to provide an ability
> to apps developers to collaborate on application development.
>
> *OpenStack Community App Catalog is there, what else?*
> Community App Catalog http://apps.openstack.org allows to
> publish/consume apps to/from it.
>
> "The OpenStack Community App Catalog is designed to use the same tools
> for submission and review as other OpenStack projects. As such we follow
> the OpenStack development workflow" [0].
>
> To follow OpenStack development workflow, apps developers need to have:
> - dedicated repositories & code review system to collaborate on code
> - mailing lists, IRC channels, core reviewers teams
> - common approach to QA
> - governance model to manage all of the above
>
> Most of the above is missing for apps developers now.  App Catalog
> provides central place to store final artifacts (ready apps, like .exe
> files in Win world) but there is no centralized infrastructure to
> collaborate on development of source code of apps.
>
> Apps developers partially use infrastructure of OpenStack core
> projects (Heat & Murano) - repositories and bug trackers. Other than that
> they are on their own, there are no teams, no mailing lists, no IRC
> channels for apps developers - most of the items from the list above is
> missing.
>
> [0] https://wiki.openstack.org/wiki/App-Catalog#How_to_contribute
>
> *All right, we need to change something. What exactly?*
>
> 1.  We need to introduce a team which manages content of Community
> App Catalog, decides which new assets can be added, decides on a workflow
> for apps publishing, maintaining, consuming. This team could be a
> complimentary team working alongside the Community App Catalog
> implementation team (engine, backend, frontend); or within the team itself
>
> 2. There should be separated repositories for source code of apps
> from Community App Catalog. These repositories should not be stored
> under openstack label as they do not relate to core OpenStack projects.
> Core project teams are not responsible for maintaining apps.
>
> 3. Bug tracking for apps should be separated from bug tracking for
> core projects.
>
> 4. There should be teams working on apps with core reviewers, IRC
> channels and mailing lists. These teams should differ from core projects
> teams.
>
> 5. Given #1 - #4 it seems reasonable to develop governance model
> specific for OpenStack Apps Community, which differs (when it’s necessary)
> from governance model of OpenStack Community.
>
> Let us develop such a governance model, implement changes described
> above and build community of OpenStack apps developers.
>
> PS. There is representative discussion in comments to
> https://review.openstack.org/#/c/309383/. Some team wants to add new
> repository for CI/CD Murano app. Should it be part of Murano core project?
> Rather not. Should it be part of BigTent? Well, rather not as BigTent is
> for core OpenStack services, not for workloads on top of it. At the same
> time team wants to use some OpenStack infra resources (at least gerrit for
> now) as this project is obviously beneficial for OpenStack. We need to have
> an ability to resolve similar requests in a centralized manner - there are
> more teams who want to publish
> source code of their OpenStack apps and there is no established
> workflow for that.
>
> *Agree. What’s next?*
> Suggested plan:
> - Introduce label openstack-apps, put repositories with source code
> of OpenStack Apps under it, i.e.:
>   * http://git.openstack.org/cgit/openstack-apps/murano-apps
>   * http://git.openstack.org/cgit/openstack-apps/heat-templates
>   * http://git.openstack.org/cgit/openstack-apps/tosca-workflows
> - Agree with OpenStack Community App Catalog team on how content of
> App Catalog is managed and by whom
> - Describe workflow of how to add source code of new application
> to repositories, who approves its addition
> - Introduce simplified workflow of publishing new Application to
> the catalog:
>   * register/login
>   * push/update
>   * done
> - Introduce teams (core reviewers) contributing to/maintaining Murano
> apps, Heat templates, ...
> - Establish channels of communications with potential contributors
> (mailing list, meetings, IRC/slack channel, ... )
> - Agree with contributors on QA process for applications and how we
> track it in Community App Catalog
>
> To simplify commenting and tracking of the plan above I put last
> two sections with suggested steps to the etherpad
> https://etherpad.openstack.org/p/OpenStackAppsCommunity
>
> We're also discussing this topic with OpenStack Application Ecosystem
> Working Group and several members of OpenStack App Catalog team support
> this idea:
> http://lists.openstack.org/pipermail/user-committee/2016-May/000854.html
>
> Please share your thoughts and comments.
>
> Regards,
> Igor Marnat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/86a8b9be/attachment.html>