Implementation requirements | Validated Patterns

Technical requirements

Consider these requirements specific to the implementation of all Validated Patterns 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.

Must

Patterns must include one or more Git repositories in a publicly accessible location, containing configuration elements that can be consumed by the Red Hat OpenShift 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).
Validated Patterns 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 clustergroup Helm chart as the initial Red Hat OpenShift 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.

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 Operator to deploy patterns. However, anything that creates the OpenShift GitOps subscription and initial clustergroup application could be acceptable.
Patterns should embody the 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 Red Hat 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 Medical Diagnosis pattern that could be used for other solutions.
Patterns should use Red Hat Ansible Automation Platform to drive the declarative provisioning and management of managed hosts, for example, Red Hat Enterprise Linux (RHEL). See also Imperative elements.
Patterns should use Red Hat Advanced Cluster Management (RHACM) to manage policy and compliance on any managed clusters.
Patterns should use RHACM and a standardized RHACM chart to deploy and configure OpenShift GitOps to managed clusters.
Managed clusters should be loosely coupled to their hub, and use OpenShift GitOps 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 OpenShift GitOps.

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.