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
In order to gain more flexibility and safety during updates of both configuration and images, the following behavior of components depending on the Portal API may be very helpful:
The portal API provides and end point which gives back some kind of hash of the static configuration
When calling webhooks, this hash is passed in as a header parameter (Configuration-Hash or similar)
At startup, each component retrieves the initial hash and stores it in memory
Whenever a hash mismatch is detected, e.g. because the portal API has restarted and retrieved/gotten a new configuration, the depending component can take action
Such an action could be just to quit the current process to let the orchestration layer (e.g. compose or Kubernetes) restart the container, so that the new configuration can be retrieved from the portal API
This would enable a much easier handling of configuration updates: It would be enough to stop/restart the portal API, and all other components would automatically draw the new configuration. Such behavior would be ideal for environments such as Kubernetes.
The text was updated successfully, but these errors were encountered:
In order to gain more flexibility and safety during updates of both configuration and images, the following behavior of components depending on the Portal API may be very helpful:
Configuration-Hash
or similar)This would enable a much easier handling of configuration updates: It would be enough to stop/restart the portal API, and all other components would automatically draw the new configuration. Such behavior would be ideal for environments such as Kubernetes.
The text was updated successfully, but these errors were encountered: