appuio / appuio-io-docs Goto Github PK

Test some jira integration.

Summary

Add exo commands to configure the following CNAME records in the cluster's DNS zone when setting up an Exoscale APPUiO Cloud zone:

cname IN CNAME cname.apps
api IN CNAME cname.apps
console IN CNAME cname.apps
registry IN CNAME cname.apps

Context

We use Exoscale's managed DNS offering to manage the cluster DNS zone on Exoscale. However, the Terraform only sets up DNS records according to the APPUiO Managed OpenShift 4 DNS scheme (cf. https://kb.vshn.ch/oc4/explanations/dns_scheme.html). This is not sufficient for APPUiO Cloud zones, but instead of adding custom logic for APPUiO Cloud in the Terraform module (https://github.com/appuio/terraform-openshift4-exoscale), we add a set of exo CLI commands to configure the required CNAME records for an APPUiO Cloud Zone on Exoscale.

Links

• appuio/terraform-openshift4-exoscale#44
• https://kb.vshn.ch/appuio-cloud/references/dns-naming-scheme.html
• https://kb.vshn.ch/appuio-cloud/how-to/zone-cluster-install.html

Acceptance criteria

• When following the APPUiO Cloud zone setup how-to (https://kb.vshn.ch/appuio-cloud/how-to/zone-cluster-install.html), all DNS CNAME records which are required to match https://kb.vshn.ch/appuio-cloud/references/dns-naming-scheme.html are created.

This issue provides visibility into Renovate updates and their statuses. Learn more

This repository currently has no open or pending branches.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/checkout action to v4
• Update mikepenz/release-changelog-builder-action action to v4

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Links to #94 (review)

It would be nice to also have some yq commands to configure the storage cluster for Exoscale zones (4 nodes, 680GB storage disk each).

We currently have a standardized format for defining quality requirements. A format that makes them SMART (see #10 )

We yet lack a format for functional requirements (= features). Currently, features are in our internal ticketing system using the Gherkin language e.g.

Proposal 1

User Story sentence + free-form text, e.g.
"
As a Developer I want to create a Namespace so that I can deploy workload
additional text lorem ipsum
"

Proposal 2

User Story sentence + acceptance criteria
Use the Gherkin language to define use cases. Example
As a Developer I want to create a Namespace so that I can deploy workload

Scenario: Create project
  Given the user "jane.doe"
  And an organization named "silver-stag"
  And the user "jane.doe" belongs to organization "silver-stag"
  And the user "jane.doe" has set "silver-stag" set as default organization
  And I am logged in as user "jane.doe"
  When I create a project named "winter-shape"
  Then there is a namespace named "winter-shape"
  And the namespace has the attribute "appuio.ch/organization" with value "silver-stag"

Proposal 3