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 Mon, May 23, 2016 at 2:02 PM, Igor Marnat <imarnat at mirantis.com> wrote:

> Chris, Kevin,
> thank you for your support! I left several comments below. Let us now
> start working with App Catalog team and openstack-dev community and discuss
> next steps to implement the plan described in [0].
>
> I also added couple of steps to [0] inspired by comments from Chris on QA
> and CI/CD process for apps.
>
>
>> > 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.
>>
>
> Exactly. We can pursue two goals here.
>
> One is to help to apps developers who want to invest some time and effort
> into QA, CI/CD, documentation process, helping their users to get support
> from apps developers should users have any questions/issues about these
> apps. This is somewhat more time/effort consuming process, but as a result
> users will get apps of more transparent and predictable quality.
>
> Second is to help to apps developers who has some useful apps to share but
> don't have time/dedicated resources to follow official approach. Providing
> them an ability to share their apps using lightweight approach would allow
> to interested users to use these apps and hopefully to help developers to
> elaborate/improve them.
>
> General idea is not to limit anyone with new frameworks/tools/guidance,
> but to have these tools in place for those in OpenStack community, apps
> developers and apps users who wants to use them.
>
> Having a feedback loop between these three parts (OpenStack community,
> OpenStack apps developers and apps users) seems to be a benefit for all
> parts involved.
>
>
>> >
>> > 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.
>>
>
> Chris,
> good point, QA process for apps is a very important and complicated topic.
> I added several items to [0] about it. It'll require more discussions and
> work not only for N cycle but rather for O as well.
>
> However, very generic and high level description of what we can start with
> could be split in five parts:
>
> 1. Documentation. Put together documentation and best practices of how to
> check the quality of software asset for Heat, Murano, Glance and TOSCA apps
> together with their teams. Each of the projects should have some
> internal/embedded ways of checking integrity of the image, syntax checks,
> unit tests, ... We can at least provide to apps users and apps developers
> information about these ways.
>
> 2. Internal/existing checks. Each of the Heat, Glance, Murano and
> TOSCA should already provide some internal/embedded checks allowing to
> verify integrity and quality of their apps. Checksums, syntax checks,
> package/image integrity, etc. - something should already exist in each of
> the projects. We can start with this, documenting these steps as a part of
> CI/CD pipeline for each kind of apps separately.
>
> 3. HW to run CI/CD (for now - #2) on. We in Murano have a team working on
> Murano apps for Community App Catalog. This team works now not only on apps
> but also on creation of CI/CD for Murano apps. As a first step we'll use
> our own HW as third-party CI. Next steps are to be discussed with involved
> parts, including core teams (Heat, Murano, Glance, TOSCA, ...) and apps
> developers.
>
> 4. Having discussed with core teams #1 and #2 we'll probably identify
> missing parts. We'll need to discuss with them addition of these missing
> parts to their roadmaps (integration tests, some tools for verification of
> software assets, ...)
>
> 5. Verification of functionality provided by workloads automated by
> corresponding apps in the catalog (databases, operating systems, k8s,
> gerrit, jenkins, web servers, ....). This is the most complicated part. I
> think that for apps which are developed in partnership with workloads
> providers such a verification could be developed together with their dev
> teams as it requires a lot of expertise in corresponding domain. To be
> discussed.
>
> BTW, does App Catalog team have some HW resources available to add some
> jobs checking #2 or we need to start looking for such a hardware?
>
> Let's start working on #1-#4 with App Catalog team, openstack-dev
> community and core teams of Heat, Murano, Glance and TOSCA. Meanwhile on a
> background we'll be figuring out how to approach #5, it seems it'll require
> a lot of time and discussions.
>
> Does it make sense?
>
> [0]  https://etherpad.openstack.org/p/OpenStackAppsCommunity
>
>
>
>>
>> -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
>> >
>>
>> _______________________________________________
>> 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/20160726/722d8a6b/attachment-0001.html>