I am developing a new Operator to manage CRDs of my business logic objects. My business objects are stored in Mongo, and thus, we need this BSON ID (12 letter length GUID) to make subsequent changes to this object.

The question is, how do I link the CR that the operator needs to create to this upstream object? Where can I store this unique BSON ID the K8S way so that I can use it for further lookups.

Example, here is a CRD for one of my upstream objects:

apiVersion: my.custom.object/v1alpha1
kind: ApiDefinition
metadata:
  name: httpbin
spec:
  description: my first api
  use_keyless: true
  protocol: http

When I do a kubectl apply -f to this CRD, it gets created.

kubectl apply -f "the_above_yaml.yaml"
ApiDefinition created!

Then my operator picks it up in the reconcile loop, where it then creates this object in my server. The server generates a BSON ID. I need to use this BSON ID to do further lookups.

How can I store the server specific BSON ID, so that developers just need to use the unique metadata name in the spec, whilst under the hood my operator takes care of linking the two?

1

There are 1 answers

0
Dominik On

If every custom resource object correlates to one MongoDB document, you could store the document ID as a string in the status field of your custom resource.

// +kubebuilder:subresource:status
type MyOwnCR struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   MyOwnCRSpec   `json:"spec,omitempty"`
    Status MyOwnCRStatus `json:"status,omitempty"`
}

// MyOwnCRStatus defines the observed state of MyOwnCR
type MyOwnCRStatus struct {
    //+optional
    DocumentID string `json:"documentID,omitempty"`
}

Please note the //+optional and omitempty keywords, marking this status field as optional. This way, a K8s api user can create the resources without specifying a document id. Your operator can then interact with your MongoDB on reconcile requests and update/patch status.documentID once the ID is known.