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

[Operator] Service discovery API not working in the Sonataflow operator prod profile

XMLWordPrintable

    • False
    • None
    • False
    • ---
    • ---

      In the https://github.com/flows-examples/techpreview2 project, if we use for example the usecase3 and try to configure the kogito.service.url with the service discovery we get the following errors/results:

       

      CASE 1:

       
      If we configure:
       
      kogito.service.url=kubernetes:services.v1/usecase3/callbackstatetimeouts
       
      and we deploy all the use case, etc., in the moment that we try to create a workflow instance, we get this result we the workflow is created with the POST.

      {"message":"Not valid URI: kubernetes:services.v1/usecase3/callbackstatetimeouts/management/jobs/callbackstatetimeouts/instances/92bb1087-6aad-4fae-928c-14582caa41c1/timers/-1"}

      w
       
      The, if we look in the corresponding POD logs, there are no log traces with errors.
       
      if we query the GET method in the callbackstatetimeouts to get the workflow instances we get this result:
       
       \\\\{"id":"92bb1087-6aad-4fae-928c-14582caa41c1","workflowdata":{}}
       
      so the workflow was created wrongly.
       
      CASE 2:
       
       
      If we instead configure:
       
      kogito.service.url=${kubernetes:services.v1/usecase3/callbackstatetimeouts} 
       
      it looks like the service discovery API at least tries to resolve the value, however it doesn't work well.
       
      Similarly to CASE1, when we try to create a workflow instance, we get this error:

      {"message":"Not valid URI: kubernetes:services.v1/usecase3/callbackstatetimeouts/management/jobs/callbackstatetimeouts/instances/800a698b-4902-4d05-a980-0a022e9b7fbc/timers/-1"}

      However, this time, if we query the POD logs, we can see errors produce by the discovery: 

      see: https://gist.github.com/wmedvede/8f1a1a0e6e7611cde3d1f026bdbe0f4e

      This time, it looks like the resolution was tried, but we have the ServiceAccount and the RoleBinding are missing.
       

      OK, if we try to create the ServiceAccount and RoleBinding manually, now the problem is that the deployment produce by the operator is not liked to it, i.e.:

      the -> serviceAccountName: XXXXXXX is not produced in the Deployment generate by the operator.

       
      We need to asses if the creation of the ServiceAccount and RoleBinding, and the subsequent link of he Deployment to the ServiceAccount name is responsibility of the operator, or any other solution.
       
      Attached goes the Deployment and Service produced by the sonataflow operator.

       

      Operator Produced Deployment: callbackstatetimeouts.operator.produced.deployment.yaml

      Operator Produced Service: callbackstatetimeouts.operator.produced.service.yaml

      Manually produced ServiceAccount and RoleBinding for the test:  manually_generated_service_account.yaml

       

      Modified files in the workflows/sonataflow-callbackstatetimeouts files that can be useful for future testing/solution:

      01-serviceaccount_callbackstatetimeouts.yaml

      02-configmap_callbackstatetimeouts-props.yaml

      03-sonataflow_callbackstatetimeouts.sw.yaml

      kustomization.yaml

       

       

       

              rhn-support-zanini Ricardo Zanini
              wmedvede@redhat.com Walter Medvedeo
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: