Proposal: Create An Ecosystem Subgroup Under project-emco

Problem Statement

In the current organization of project-emco, we have 2 subgroups: core and ui. Underneath these are specific git repositories, such as emco-base and emco-gui. This organization has served well so far, but there are gaps which are exacerbated by newer developments. Here are some of those gaps:

• With the ongoing work to integrate Temporal workflows into EMCO, we need a place to put example/reference workflows.

  • The workflows are logically independent of core EMCO, so placing workflow documentation and code snippets inside the core/emco-base is not appropriate.

  • The workflows need to be compiled/built and deployed. The deployment may be via EMCO. IOW, a workflow is similar to an app in this context. This means each workflow needs its own build environment and deployment environment. This means it requires a repo of its own. (Intel is seeding this work with a reference workflow, and folks want it soon, so this has become rather urgent.)

  • A workflow may be useful to many organizations, so they may develop it collectively. This also necessitates the need for a separate repo for each workflow.

  • Apart from the need for a build environment, we want to enable developers to contribute back.

• In the future, we may have 3rd party EMCO controllers, which are not part of the core/emco-base: that is, they would not be built and released with the core, but would be collectively developed and used in the open. Similar to workflows, this scenario also requires separate repos outside the core.

• It would be great to have a 'Best of EMCO' kind of repo, similar to 'best-of' lists and 'awesome' lists in github. This could be a collection of EMCO resources, blogs, use cases etc. This also would not fit either under core or under ui. 

Solution (updated based on comments below):

Let us create a new subgroup under project-emco to keep non-core contributions from the EMCO ecosystem, whether they be workflows, 3rd party controllers or non-software resources. We could be wildly imaginative and place it under https://gitlab.com/project-emco/ecosystem.

Secondly, to serve the immediate need for housing Temporal workflows, let us create a second-level subgroup under ecosystem named temporal, i.e., at https://gitlab.com/project-emco/ecosystem/temporal. Under the temporal subgroup would be a git repository that houses the specific reference workflow that Intel is providing. Since that reference workflow's purpose is to migrate a composite application from one cluster to another, that repo would be called migrate-workflow. Putting it all together, the location of the repo would be https://gitlab.com/project-emco/ecosystem/temporal/migrate-workflow.

This proposal allows for more Temporal workflows to be added under the temporal subgroup. Outside the temporal subgroup, we could add workflows for other engines, 3rd party controllers, non-software resources such as awesome lists, and so on. The proposal intentionally does not specify those future possibilities: they can be taken up as the need arises. 

The ecosystem subgroup is proposed as a flat space under which the community-contributed repositories reside. For example, the reference workflow that Intel plans to provide would be under https://gitlab.com/project-emco/ecosystem/temporal-migrate-workflow.

There is no expected need for a PTL for the ecosystem subgroup at this point. A PTL usually sets roadmaps for releases, executes releases and oversees common architecture/API/coding standards. The ecosystem repos may not have regular releases and, even if they do, are not expected to be part of the emco-base releases. That is why we don't see the need for a community PTL.