Microcks operator reboot: new implementation and new CRDs

[lbroudoux]

Hey community!

For some time now, the existing microcks-ansible-operator is showing some limitations:

• It is damn slow as Ansible fact-gathering and operations take hour,
• It is hard to maintain as flat structure and Jinja templates are a nightmare,
• It is based on an old version of operator-sdk and would need a big refresh.

However, the need for a top-notch operator is there as there is also a demand for new features like populating a whole new Microcks instance for all its configuration (secrets, hub connections, etc..) and its content (API definitions, importers) as well as maybe triggering new actions (tests?) through the creation of a simple new Kubernetes CR. We'd like full GitOps behavior for Microcks in order to provide API/Services mock sandboxes as a service!

For all these above reasons, we can hardly imagine building on the existing operator! We started new explorations on re-writing an operator using the Java Operator SDK that presents idioms that totally align with Go SDK for operators and that are common to our existing code base. New base for our next operator is located here: microcks-operator

With this discussion, I'd like to introduce the design for new CRDs that we have in mind, and like to collect as much feedback as possible. Please share your thoughts on features, CRD schemas, attribute naming, extension capabilities, status tracking, expected behavior, and whatever you feel is important to have for a top-notch operator.

Microcks install

The Microcks CR replaces the previous MicrocksInstall. apiVersion has changed but the structure remains quite similar. We pay attention though to provide more extensions points (via extraAnnotations or direct spec).

For startup, we plan to have a namespace scoped operator but may change it to support both namespace and cluster-wide scopes.

apiVersion: microcks.io/v1alpha1
kind: Microcks
metadata:
  name: my-microcks
  namespace: microcks
spec:
  version: '1.9.0'
  microcks:
    replicas: 1
    extraAnnotations: # Service, Deployment, Template<Pod>
    ingress:
      expose: true    # Default
      class: nginx    # Optional
      annotations:    # Optional 
        - my-annotation: value    # Optional
      generateSecret: false     # Optional
      secretRef: my-tls-secret  # Optional
      spec: |-
        # Full feature Ingress Spec
  postman:
    replicas: 1
    extraAnnotations: # Service, Deployment, Template<Pod>
  mongodb:
    install: false
    uri: mongodb.acme.com
    uriParameters: "?tls=true"
  keycloak:
    install: true
    url: keycloak.acme.com
    privateUrl: https://kecyloak.internal
    serviceAccount: microcks-service-account
    serviceAccountCredentials: <guid>
  features:
    async:
      enabled: true
      extraAnnotations: # Service, Deployment, Template<Pod>
      kafka:
        install: true
        url: kafka.acme.com  # Optional on OpenShift
      mqtt: # MQTT configuration section
      amqp: # AMQP configuration section
      nats: # NATS configuration section
status:
  microcksUrl:
  keycloakUrl: 

API definition source

One of the first new CR we'd like to introduce is the APISource (or directly Source?) that will allow the operator to feed a Microcks instance content with importers or artifacts (preferably related to the same API definition but nothing would prevent to put unrelated API defs here).

APISource may contain either raw artifacts references (just read once during the import) or informations to create importers (that are then created and activated as scheduled imports). The conditions allow tracking the status of each and every artifact or importer. A global status flag should also be defined to globally know if the CR application is a success or not.

apiVersion: microcks.io/v1alpha1
kind: APISource
metadata:
  name: my-microcks-artifacts
  namespace: <same-namespace-than-microcks-instance>
  annotations:
    microcks.io/instance: my-microcks
spec:
  artifacts:
    - url: https://raw1
      mainArtifact: true
      secretRef: my-secret
  importers:
    - name: User-signed Up API Jobs
      repositoryUrl: https://raw2
      repositoryDisableSSLValidation: false
      # OR
      repository:
        url: https://raw2
        disableSSLValidation: false
      mainArtifact: true
      active: true
      secretRef: my-secret
status:
  conditions:
    - type: https://raw1
      ready: True
    - type: https://raw2
      ready: False

As APISource may need to access protected/private repository, it will rely on exiting secrets in Microcks instance. As a consequence, secrets might also be automatically created/imported/synched by the Microcks operator in the last CR.

Secret source

A SecretSource allows the operator to create Secrets within a Microcks instance. Secrets can be either directly created from a definition in the CR or created by sychronization with an already existing Kubernetes Secret.

apiVersion: microcks.io/v1alpha1
kind: SecretSource
metadata:
  name: my-microcks-secrets
  namespace: <same-namespace-than-microcks-instance>
  annotations:
    microcks.io/instance: my-microcks  # What Strimzi is doing
spec:
  interval: 30m
  secrets:
    - name: my-microcks-secret
      description: "Microcks secret description here"
      username: username
      password: password  # Encrypted? Base64 encoded at a minimum
      token: token
      tokenHeader: tokenHeader  # Encrypted? Base64 encoded at a minimum
      caCertPem: |
        ----BEGIN CERTIFICATE-----
        ----END CERTIFICATE-----
    - name: my-synced-secret
      description: "Microcks secret created from Kubernetes secret"
      valuesFrom:
        secretRef: my-kubernetes-secret
        username: secret-username-key
        password: secret-password-key
        token: secret-token-key
        tokenHeader: secret-token-header-key
        caCertPem: ca-cert-pem-key     
status:
  conditions:
    - type: my-microcks-secret
      ready: True
    - type: my-synced-secret
      ready: False
      syncedGeneration: 25

Join the discussion!

Please comment on what you think, what you'd like to see, and what you'd like to have in this new operator! Join the discussion!

[lbroudoux]

Bumping this one as I started implementing some of those ideas in microcks-operator. Let me know if someone is interested in sharing/collaborating on this.