You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working between microservices for issue #1422, the differences in definition of Constants across microservices became troublesome for cross-service communication. The webhooks service and the iam-utils library both defined the "User" entity as "USER", but the flow-repository defines this same entity as "user". The first two both use a constants file to contain this value, whereas the flow-repository has this text defined directly in the code.
Therefore, it would be preferable to provide some additional tooling for ensuring the consistency of "constants" and configuration-type data throughout the system.
Potential solutions:
Add a "global" ConfigMap to Kubernetes deployments in order to be used by all services when creating pods. This solution is good for permanent or "almost-permanent" values which would only be changed on rebuild of the system.
Provide an additional service to handle configuration values. This service could then provide a polling endpoint for other services to grab values, or could push the configuration via sidecar to all other services periodically, or on change. This is better for values which are more likely to be changed / manipulated. (Timeouts, retry counts, etc)
Provide a configuration tool which will update config maps and other constant files across services. This would probably only be used on initial deployment of the framework. Also only to be used for permanent values.
The text was updated successfully, but these errors were encountered:
When working between microservices for issue #1422, the differences in definition of Constants across microservices became troublesome for cross-service communication. The webhooks service and the iam-utils library both defined the "User" entity as "USER", but the flow-repository defines this same entity as "user". The first two both use a constants file to contain this value, whereas the flow-repository has this text defined directly in the code.
Therefore, it would be preferable to provide some additional tooling for ensuring the consistency of "constants" and configuration-type data throughout the system.
Potential solutions:
The text was updated successfully, but these errors were encountered: