rgolangh commented on issue #3573:
URL: 
https://github.com/apache/incubator-kie-kogito-runtimes/issues/3573#issuecomment-2244850419

   I'm trying to capture what you say:
   - key exist in initial context? calculate value and save to db
   
   - open api state handler
     - take key and val from db. no value? use build config, then uri in spec
    
   problem with that is that this is a surprizing API because the users can't 
really know what value will be used if they for example don't send it.
   So a call to a workflow without a param $clustername, could lead to a some 
other default (buildtime) key to be used, where the user didn't expect, and 
even the workflow could even create resources on that  (wrong) cluster.
   
   But perhaps I didn't get your proposal properly. Please correct me if 
anything here is wrong.
    
   Can we consider a more explicit API, either we have the value or fail?
   I would expect something like providing an argument to the openapi function 
that will specify the key:
   
   ```yaml
   functions:
     - name: createDeployment
       operation: kube.yaml#createDeployment
       restConfigKey: EXPRESSION
   ```
   so now it is at least visible that EXPRESSION is resolved during invocation.
   Plus, add syntax to access the request params , or the one saved in the 
db(similar to how SECRETS is to application pros):
   
   
   restConfigKey: 'REQUEST.clusterName'  
   ```
   
   And whatever the resolution of the key is, that is what is used. otherwise 
failure.
   
   Again, my point of view is, making the developer of the workflow easy to 
understand and use those nice configuration items, but with limitation that 
will still prevent mistake, and will be easier to debug.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to