Sergey, Great initiative, +1 from me. On May 31, 2016 7:24 PM, "Sergey Kraynev" <skray...@mirantis.com> wrote:
> Hi Infra, Murano and App Catalog teams. > > We discussed in some more details plan suggested below with App Catalog, > Murano and (partially) Infra team regarding moving repositories with source > code of Murano applications out of area of responsibility of Murano core > team. > > ***** *First part related with changes in existing Murano repository and* > important for Murano App developers ***** > > Decision was made to: > - create new gerrit groups for review/release/test repository, namely - > murano-apps-core > - don't rename murano-apps project and repository, just assign team above > as owners (murano-apps-core) > > Previous owner of this project (murano-core) will be part of new group to > continue sharing expertise in Murano with this new team and help them going > forward. > > There is patch on review for it: https://review.openstack.org/#/c/323340/3 > > Separation of murano-apps from Murano is the first step in separating work > with Murano applications from work with Murano core project. > > ***** *Second part related with changes with future repositories and* > important for Openstack Infra team ***** > JFYI, what we plan to do as next steps. > > Murano team will re-create some applications in their repositories using > name murano-examples, as reference implementation of some of the > applications which Murano team decides to keep in their project for > reference. This can be done by Murano team, no external help needed. > > Some of the applications (complicated and big applications like CI/CD > pipeline or Kubernetes cluster) will have their own repositories in the > future under openstack/. Actually CI/CD pipeline already lives in separated > repository, probably Kubernetes should be also moved to separated repo > going forward. Hopefully this shouldn't be a big deal for OpenStack Infra > team. > *However* we would like to get confirmation, that *Infra team* is ok with > it? > > Suggestion is to use common template for names of repositories with Murano > applications in the future, namely openstack/murano-app-... > (openstack/murano-app-kubernetes, openstack/murano-app-docker, ...). We'll > describe overall approach in more details using > https://launchpad.net/murano-apps as entry point. > > Simple applications or applications where there is no active development > will keep being stored in murano-apps until there is a demand to move some > of them to separated repository. At that point we'll ask OpenStack Infra > team to do it. > > We hope that this will help to clearly identify area of responsibility > around development of Murano applications, helping to onboard new > contributors/teams using mostly efforts of Murano Apps team. I.e. creation > of new application in murano-apps repository means in this model just > creation of new directory with new application, which can be done by > murano-apps team on their own. In this case we'll need to understand how to > organize CI for different applications being stored in the same repository > but I think we'll figure it out, it's not a blocker. > > This model allows us to ask for involvement of OpenStack Infra team only > in rare cases when there is a need to create separate repository for > especially big and complicated Murano Application which should be treated > as a dedicated project with its own development team and CI. > > > Any suggestions, questions are welcome!!!! > > On 25 May 2016 at 14:37, Igor Marnat <imar...@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 >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Regards, > Sergey. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
