This story is still a work in progress. It is in refinement for collecting feedback and ideas with the team.

Owner: Architect:

Francesco Ilario

Story (Required)

As a Primaza Developer,
I would like Primaza to do not require Cluster-scoped resources other than CRDs
so that I can fully install it in a namespace

Background (Required)

As defined in the Primaza architecture document, we want to have Primaza just using namespace resources.
The only Cluster level resources we want to have are CRDs.

Unfortunately, ValidatingWebhooks are cluster-scoped resources and we should find a way of removing or making them optional.
Furthermore, designing kubernetes operators as if you do not have ValidatingWebhooks is considered good practice.

See epic for arch document link.

Glossary

See glossary in architecture document

Out of scope

• NA

In Scope

• ServiceClass validation
• ServiceClaim validation

Approach(Required)

Mutually exclusive properties

To take care of mutually exclusive properties we have the following two options.

Where applies we can introduce a new CRD.
As an example, ServiceClass has two fields that are mutually exclusive: Protocol and Resource.
We can avoid this by creating the ResourceServiceClass and ProtocolServiceClass CRDs.
As of now, this specific scenario is not needed, because we are not implementing the Protocol field.

Another approach is to have the two properties as children of the same parent and use the // +kubebuilder:validation:MinProperties:=1 and // +kubebuilder:validation:MaxProperties:=1 annotations.

Have also a look at the following PR

In the case of the ServiceClass it would something like the following:

apiVersion: primaza.io/v1alpha1
kind: ServiceClass
metadata: 
  name: myserviceclass
  namespace: mytenant
spec: 
  constraints: {}
  # // +kubebuilder:validation:MinProperties:=1
  # // +kubebuilder:validation:MaxProperties:=1
  discovery: 
    protocol: 
      port: 5432
    resource: 
      apiVersion: stable.example.com/v1
      kind: Backend
      serviceEndpointDefinitionMappings: 
        resourceFields: 
        - name: host
          jsonPath: .spec.host
          secret: false
  serviceClassIdentity: 
  - name: type
    value: backend

Immutable resources

For immutable resources, like ServiceClaim, we can take note of status generation and observedGeneration fields.
The controller could refuse to reconcile the CR if observedGeneration is not null and generation is not equal to observedGeneration.

This won't prevent resource from being updated. To keep track of the reconciled spec, we may want to save the spec in the status in a field named reconciledSpec.

Complex Validation

If complex validation on CRD is needed, we may do this at reconcile time and update the resource status accordingly.
In case of Immutable resources validation, we can allow reconciliation until the resource status is expressing a validation error.

For immutable fields, we can leverage on CRD Validation Expression Language.
This a Beta Feature available from Kubernetes 1.25.

As a PRO, it is very easy to implement.
If we are not considering Production for a while it may be an easy solution for now.
When we are going to consider Production we can re-evaluate this problem.
As a CON, it is in beta and clusters older than 1.25 are not supporting it.

Alternatively, we can take note of them, or their hash, in a field in the status, named for example immutable.fields.
When we reconcile the resource we first need to check for consistency of these fields.

Demo requirements(Required)

NA

Dependencies

NA

Edge Case

NA

BDD Tests

You can find BDD Test specification for this story in the "Testing Instruction" Field Tab or in the GitHub Issue linked to this story.
Click here for all BDD Tests Issues.

Acceptance Criteria

This story is still a work in progress. It is in refinement for collecting feedback and ideas with the team.

• Development
  

• QE
  There are test cases for ...

• Docs
  There is a page in our docs dedicated to explaining what a ...
  Update architecture document with any changes while implementing
  There is a link in our main readme to the .... page

INVEST Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Legend

Unknown
Verified
Unsatisfied