Uploaded image for project: 'Kogito'
  1. Kogito
  2. KOGITO-3039

Agnostic infrastructure layer configuration on Operator

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Major Major
    • 0.17.0
    • 0.13.0
    • Operator
    • None
    • 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7), 2020 Week 40-42 (from Sep 28)

      As an user, I wish to configure my custom Kogito service on Kubernetes cluster to use the supported persistence layers by Kogito core. To this date, the supported persistence infrastructure are MongoDB and Infinispan.

      Depending on the persistence layer chosen, the operator should get the connection information passed through the CR and inject this information in the target Kogito services. Could be more than one since an user could use the same persistence server for many custom or support services (such as Data Index).

      Specific information about the persistence implementation should not be in the CR attributes like we have today, nor coupled to the KogitoService interface.

      Example of a service that depends on Infinispan today:

      apiVersion: app.kiegroup.org/v1alpha1
      kind: KogitoDataIndex
      metadata:
        name: data-index
      spec:
        replicas: 1
        image:
          tag: "0.12"
        kafka:
          useKogitoInfra: true
        infinispan:
          useKogitoInfra: true
      

      The approach should be more DI, like:

      apiVersion: app.kiegroup.org/v1alpha1
      kind: KogitoDataIndex
      metadata:
        name: data-index
      spec:
        replicas: 1
        image: myimage
        # KogitoInfra with information about this persistence instance
        infra: 
          - kogito-infinispan
      ---
      apiVersion: app.kiegroup.org/v1alpha1
      kind: KogitoInfra
      metadata:
        name: kogito-infinispan
      spec:
       implementation: infinispan
       type: persistence
       url: myinfinispan:9000
       credentials:
           secret:
              userKey: username
              passKey: password 
      

      So the service controller could inject all the information regards the platform into the deployed Kogito service. On "dev mode", the KogitoInfra controller could deploy infinispan via Infinispan Operator like we are doing today (see KOGITO-3142), having this info in the CR and on production users would just update the "platform" CR, not their service.

      This could also be used for others use case like eventing:

      apiVersion: app.kiegroup.org/v1alpha1
      kind: KogitoDataIndex
      metadata:
        name: data-index
      spec:
        replicas: 1
        image: myimage
        infra:
          - kogito-infinispan
          - kogito-knative
      ---
      apiVersion: app.kiegroup.org/v1alpha1
      kind: KogitoInfra
      metadata:
        name: kogito-infinispan  
      spec:
       resource:
         kind: app.infinispan.org/v1
         namespace: infinispan-namespace
         name: infinispan-instance-name
      ---
      apiVersion: app.kiegroup.org/v1alpha1
      kind: KogitoInfra
      metadata:
        name: kogito-knative
      spec:
       implementation: knative
       type: messaging
       topics:
         - name: mytopic1
           type: consumed
         - name: mytopic2
           type: produced
      

      This is just a rough draft, more to come in the upcoming weeks with a proper design document.

              vajain Vaibhav Jain
              rhn-support-zanini Ricardo Zanini
              Karel Suta Karel Suta
              Karel Suta Karel Suta
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: