| Table of Contents |
|---|
Introduction
Before you beginning the process of submitting your Item, make note of the following prerequisites:
- A basic understanding about how to structure text in YAML file format (checkout this introductory article)
- A hosting location for your Item, which supports versioning and is accessible from the public internet. Valid locations include, but are not limited to:
- Git repository
- Package repository
- Container registry
- Artifact registry
- Object storage
- Wiki site
Once you have taken care of these basic prerequisites, you can turn your attention to the Item itself. Whether your idea is in an early conceptualization state or fully implemented, take a moment to think about its purpose, the customization options that would improve reusability, the level of support you can offer, and the open-source license you wish to grant.
Choosing a License
Unless your Item has dependencies linked to GPL terms of use, or on the contrary, they are constrained by a proprietary license, you, as the Item owner, are free to choose a suitable open-source license under which to feature Items. For reference, EWC-supported Items typically release under MIT or Apache 2.0 license.
...
Deciding on a Support Level
| Info |
|---|
If you wish to change the support level of Item currently featured on the dashboard, bump its semantic version up from |
The Community Hub recognizes four different support levels, one of which is reserved for Items featured by the EWC and its close partners (e.g. EWC-Supported). You, as the Item owner, are free to choose, from any of the remaining support levels, the one that best fits your availability and commitment:
| Name | Summary | Audience |
|---|
| Service Level Agreement (SLA) | Example | |
|---|---|---|
| Community-Shared | Best-Effort / No SLA | For typical users or research groups sharing useful work |
| None. No guaranteed response, or issue acknowledgement. Contributions and fixes depend entirely on community goodwill. | A GitHub repository with a permissive license but no maintainer commitment |
| Community-Updated | Active / No SLA | For small teams or labs actively using the Item themselves | None. Maintainers monitor issues and PRs. Best-effort responses. Updates are featured occasionally (aligned with their internal usage) | An enriched dataset with pre-calculated metrics on atmospheric phenomena, updated at irregular interval and/or subject to data availability, without any formal commitment |
| Community-Supported | Well-defined SLAs | For organizations willing to stand behind their Items | Documented response channels (email, ticket system, GitHub issues). Defined response time (within hours or up to 7 business days). Regular security patches. Changelog publishing. | A data pipeline template for various streaming analysis algorithms, regularly updated to support new datasets and increase throughput capabilities |
| EWC-Supported | Well-defined SLAs, Partner-Backed | For Items featured by EWC partners (ECMWF, EUMETSAT, etc.) or trusted collaborators |
| Same as Community-Supported, plus guaranteed compatibility with the EWC hardware and clear escalation path in case of security sensitive issues. | A one-click deployable software stack for self-managed identity/policy/audit (IPA), hardened SSH access point and remote desktop environment hosting |
Defining Deployability
...
Wether an Item is deployable or not depends mainly on the Item Technology
...
(find the full list of currently supported ones
...
on the EWC Community Hub page).
Item is not Deployable
No additional action required.
Item is Deployable
If your Item is indeed deployable and you wish to feature it as such, please make sure to assess whether or not it works out-of-the-box in both of the EWC providers, namely:
- EUMETSAT site
- EWCMWF site
In the event deployments are only intended to work on one of the sites, or requires additional setup on one of them, please clearly disclaim as part of the Item metadata you submit. An statement on the Item's description is sufficient.
(Optional) Adding Compatibility with the ewccli
| Warning |
|---|
Before attempting to feature your Item as EWCCLI- compatible, please ensure you test and validate by carrying out a deployment via the ewccli. EWC review reviewers may refuse your submission if it is unclear if deployment via |
| Info |
|---|
If you are convinced featuring your Item as compatible can greatly improve its reception among community members, but you are unsure how to conduct the necessary deployment tests, you can place a support ticket to request assistance. |
If you meet all the criteria listed below, you might want to consider the benefits of adding compatibility for the ewccli:
- Your Item is Deployable
- Your Item is an Ansible Playbook
- You lack expertise/resource/business-cases to turn your contribution into
HybridItem (by combining it with Terraform to achieve self-provisioning, such as in
...
The ewccli is a Linux-native Python-based tool which allows you to interact with deployable Items directly into a EWC tenancy, with minimal setup required on your local working environment. See Deploying new instances and applying Ansible Playbooks on them with the ewccli.
On paper, adding compatibility with the ewclid does not require additional development effort on your side, as the business logic is built into the tool itself.
...
From your side, all that is required is additional Item metadata to be prepared, namely:
...
- Item input specification: If any available. May also include default values for each input.
...
- Item output specification: If any available.
...
- Item annotations:
...
| language | yaml |
|---|
...
- Set as
category: EWCCLI-compatible,Deployable
...
You can find references to the metadata schema in the Submit your Item page. For a complete Item Metadata example including full compatibility with the ewccli checkout
...
this entry in the live catalog.
Following Implementation
Putting it all Together
| Tip |
|---|
If you are unfamiliar with YAML, or needed additional guidance to correctly annotate your Item, feel free to place a support ticket on the EWC Support Portal. |
Besides the information highlighted in the previous sections, including a description (i.e. the features and usage), contact and a version for your Item is required, to increase the quality of submissions.
To help both contributor and reviewers to categorize this information, we kindly ask you to fit in your Item details into the Item Metadata structured used by the EWC Community Hub (YAML format). Take as example metadata of the "ECMWF Data Flavour" Item, published on GitHub. When preparing metadata for your own Item, we recommend you copy the content of said example YAML and adapt values accordingly.
("EWCWF Data Flavour" Item, published on GitHub)
Detailed information on all the supported metadata attributes, both the required as well as the optional ones, is also publicly available; the current version of the Items schema definition is hosted on GitHub, at https://github.com/ewcloud/ewc-community-hub/blob/main/schemas/items/v1alpha1.json.
Best-Practices
Best-practices are not always well documented, and they tend to change. If you are not sure what is currently considered a best-practice, at least within the EWC community, we recommend you start here:
- Best-Practices of Community Hub Item Implementation: examples of EWC
...
- -supported Item implementation, ranging from basic documentation format to CI/CD automation, all details broken down per Item Technology.
Related Articles
...