---
menu:
  contribute:
    parent: Contributing and managing patterns
title: Implementation requirements
weight: 52
aliases: /contribute/implementation/
---

:toc:
:imagesdir: /images
:_content-type: ASSEMBLY
include::modules/comm-attributes.adoc[]

[id="technical-requirements"]
== Technical requirements

Consider these requirements specific to the implementation of all {solution-name-upstream} and their tiers.

The requirements are categorized as follows:

Must::
These are nonnegotiable, core requirements that must be implemented.
Should::
These are important but not critical; their implementation enhances the pattern.
Can::
These are optional or desirable features, but their absence does not hinder the implementation of a pattern.

[id="must-implementation-requirements"]
=== Must

. Patterns must include one or more Git repositories in a publicly accessible location, containing configuration elements that can be consumed by the {rh-gitops} Operator without supplying custom Argo CD images.
. Patterns must be useful without all content stored in private Git repositories.
. Patterns must include a list of names and versions of all the products and projects that the pattern consumes.
. Patterns must be useful without any sample applications that are private or that lack public sources.
. Patterns must *not* degrade due to lack of updates or opaque incompatibilities in closed source applications.
. Patterns must *not* store sensitive data elements including, but not limited to, passwords in Git repositories.
. Patterns must be possible to deploy on any installer-provisioned infrastructure OpenShift cluster (BYO).
+
{solution-name-upstream} distinguish between the provisioning and configuration requirements of the initial cluster (`Patterns`) and of clusters or machines that are managed by the initial cluster (`Managed clusters`).
. Patterns must use a standardized https://github.com/validatedpatterns/common/tree/v1/clustergroup[clustergroup] Helm chart as the initial {rh-gitops} application that describes all namespaces, subscriptions, and any other GitOps applications which contain the configuration elements that make up the solution.
. Managed clusters must operate on the premise of `eventual consistency` (automatic retries, and an expectation of idempotence), which is one of the essential benefits of the GitOps model.
. Imperative elements must be implemented as idempotent code stored in Git repository.

[id="should-implementation-requirements"]
=== Should

. Patterns should include sample applications to demonstrate the business problems addressed by the pattern.
. Patterns should try to indicate which parts are foundational as opposed to being for demonstration purposes.
. Patterns should use the {validated-patterns-op} to deploy patterns. However, anything that creates the {rh-gitops-short} subscription and initial clustergroup application could be acceptable.
. Patterns should embody the link:https://www.redhat.com/en/products/open-hybrid-cloud[Open Hybrid Cloud model] unless there is a compelling reason to limit the availability of functionality to a specific platform or topology.
. Patterns should use industry standards and {redhat} products for all required tooling.
+
Patterns require current best practices at the time of pattern development. Solutions that do not conform to best practices should expect to justify non-conformance or expend engineering effort to conform.
. Patterns should *not* make use of upstream or community Operators and images except, depending on the market segment, where it is critical to the overall solution.
+
Such Operators are forbidden to be deployed into an increasing number of customer environments, which limits the pattern reuse. Alternatively, consider to productize the Operator, and build it in-cluster from trusted sources as part of the pattern.
. Patterns should be decomposed into modules that perform a specific function, so that they can be reused in other patterns.
+
For example, Bucket Notification is a capability in the {med-pattern} that could be used for other solutions.
. Patterns should use {rh-ansible} to drive the declarative provisioning and management of managed hosts, for example, {rhel-first}. See also `Imperative elements`.
. Patterns should use {rh-rhacm-first} to manage policy and compliance on any managed clusters.
. Patterns should use {rh-rhacm} and a https://github.com/validatedpatterns/common/tree/v1/acm[standardized RHACM chart] to deploy and configure {rh-gitops-short} to managed clusters.
. Managed clusters should be loosely coupled to their hub, and use {rh-gitops-short} to consume applications and configuration directly from Git as opposed to having hard dependencies on a centralized cluster.
. Managed clusters should use the `pull` deployment model for obtaining their configuration.
. Imperative elements should be implemented as Ansible playbooks.
. Imperative elements should be driven declaratively implying that the playbooks should be triggered by Jobs or CronJobs stored in Git and delivered by {rh-gitops-short}.

[id="can-implementation-requirements"]
=== Can

. Patterns can include additional configuration and/or demo elements located in one or more additional private Git repositories.
. Patterns can include automation that deploys a known set of clusters and/or machines in a specific topology.
. Patterns can limit functionality/testing claims to specific platforms, topologies, and cluster/node sizes.
. Patterns can consume Operators from established partners (for example, Hashicorp Vault, and Seldon)
. Patterns can include managed clusters.
. Patterns can include details or automation for provisioning managed clusters, or rely on the admin to pre-provision them out-of-band.
. Patterns can also choose to model multi-cluster solutions as an uncoordinated collection of initial hub clusters.
. Imperative elements can interact with cluster state or external influences.