csviri/kubernetes-glue-operator

Meta-operator to compose Kubernetes resources and define resource workflows

kubernetes-glue-operator's Issues

Sonar

add sonar checks to PR-s

Support Managing of Bulk Resources

This is the case when dynamic number of managed / child resources needs to be created.
For example based on an input from a custom resource, there needs to be n number of Pods created.

See in JOSDK:https://javaoperatorsdk.io/docs/dependent-resources#bulk-dependent-resources

MVP Scope

• Workflow
• Workflow Operator
• Templating the resources
• Substitute variables in plain resources
• Javascript conditions
• Conditions
• Workflow / Workflow Operator mutability - deleting not present resource definitions
• #20
• Samples
• Docs
• Pure K8S Resource for deployment
• Rename to resource-workflow-operator?

Utilizing Label Selectors

Label selectors could be utilized for different purposes. But one reason is to do sharding for deployment of the operator, so by certain running instances, only selected Glue and GlueOperator resources would be selected.
To achieve this, we can add a label selector field in spec for both resources. GlueOperator would also propagate the label selector to Glue.

It is a question whether we should propagate labels and label selectors automatically for dependent resources. This would be a little problematic if there is a dependent resource and a related resource for the same type, in this case, we create only one informer, and label selectors don't support or.

All Integration Tests Should do all CRUD operations within a test

In other words we should always test also Update

OLM Support

Optimization of JS Condition

JS Conditions are relative time consuming.

Some optimizations might be tried, like:

• caching the serialized resources (if resource version did not change we are fine)
• passing the resources differently (not ser/deser)

Execute parent related resource special logic only if `Glue` is created by the `GlueOperator`

Possibility to specify Service Account for reconciliation

This is because of security requirements

Migrate to QOSDK

This includes moving to Qute templating engine.

Glues in Operator Namespace if `glueMetadata` not specified.

Related Resources

Capability set resources which are not managed for a Workflow but serves as an input for it.

Should be a related resource name or selector always mandatory?
That would be nice in first version at least.

If namespace not set, it is defaulted to namespace of the workflow.

Sample:

apiVersion: io.csviri.operator.workflow/v1beta1
kind: Workflow
metadata:
  name: wf-to-change
spec:
  resources:
    - name: configMap1
      resource:
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: configmap1
        data:
          key: "{{secret1.data.value}}"
  relatedResources:
    - name: secret1
      resource:
        apiVersion: v1
        kind: Secret
        name: my-secret
        namespace: optional-namespace        

Handling K8S Garbage Collection Optimally

A resource can be garbage collected only if there is no resource depending on it. Thus the leaf resources in the DAG.

Related Resources Triggers Primary Resource

Related currently can be read but not triggering the reconciliation

Related Resource and Child Resource of same Type

• Currently only distinct is supported to child resources.

Other Features / Ideas

Ideas that will be eventually selected and issues created from them if decided to implement in upcoming release

• Related Resources handling
• Handling custom status updates
• Openshift client -> support for client. Feature flag
• Watch resources - event source registration (input only, not triggering?)
• Webhook conditions?
• Condition reference (if multiple resources has the same condition)
• Label Selectors
• Delete flag on workflow operator to delete Workflows
• Bulk resource handling

Automatically add ready condition for a ready-able resource (?)

Add E2E tests

Should Operator Child Resources add Owner Reference for the Parent?

Now they reference the Glue. Normally their owner should be the parent. Might be good to have both owners the parent and the glue too, just for better obervability.

(The Glue owner now is the parent)

Default glueMetadata for cluster scoped parent

Currently there is only one, where the parents are the namespaces, what is quite specific.
Also we should consider defaulting to put the Glue into the GlueOperator namespace if the if glueMetadata is not specified for the cluster scoped parent

Flag to use SSA matcher or not for a Dependent

Optimization for Templating

Templating now serializes GenericKubernetesResource to map/list structure, this can be time and resource intensive and we should take a look how could be optimized (in worst case cached by resource version)

Support Cluster Scoped Parent

Related Resource Templating

Related resources are not managed, but referencing the workflow metadata would be very useful.

Label Selector for GlueOperator parent resources

Label selectors are supported for Glue and GlueOperator: #86

It would also nice to have label selector for GlueOperator parent resources, this will allow to do canary testing, this only to process some resources with this operator and some with other operator or different deployment of this operator

Create Proper Website

Enhanced Micrometer Integration

• measure reconciliation of workflow, conditions, dependents.

Support Watching only one type of Custome Resource

This will allow the operator to be deployed as a dedicated operator for one type of resources. This supports sharding, but also define RBAC very nicely.

Support multiple related same type from different namespace.

Helm Chart

Updating Status of a Custom Resource

This could be done just by simple templating, which would than do a status patch based on the template at the end of glue reconciliation

If the resource is for a different namespace the reference should be handled by annotation not by owner reference

Resource removed from Glue while controller was down

• this might result in a non-cleaned-up resource since the informer is not registered for the secondary.

Shall we mark created resource somewhere in metadata/status what resource types were created?

Handling Cluster Scoped Resources

Owner References are not working for resources which are cluster scoped (by design in k8s). Those needs to be explicitly deleted.
This is already supported in DependentResources, just it needs to be detected which resource is cluster scoped and which is not.

Check name uniqueness of resources (also related resources)