Need to be able to (re-)configure the sub-process running within an ochopod instance · Issue #9 · autodesk-cloud/ochothon · GitHub
More Web Proxy on the site http://driver.im/
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
I was thinking of a feature that would be great to have in ochothon: the ability to pass some parameters to the desired pods in order to re-configure the underlying application.
My use case: ochopod cluster running a number of instances of my scala+akka+spray application (web service). Sometimes I need to change some configuration properties (that are currently in the application.conf). Would be great if I could do this from ochothon. No need to redeploy the pod: just pass some configuration values (specific to you application) and the sub-process is restarted if needed.
The configuration should ideally be persisted so that it is still used in case the pods are destroyed and re-created. Not all pods in a given cluster will use the same configuration though (i.e. configuration is instance-specific and not cluster-specific).
The text was updated successfully, but these errors were encountered:
I was thinking of a feature that would be great to have in ochothon: the ability to pass some parameters to the desired pods in order to re-configure the underlying application.
My use case: ochopod cluster running a number of instances of my scala+akka+spray application (web service). Sometimes I need to change some configuration properties (that are currently in the application.conf). Would be great if I could do this from ochothon. No need to redeploy the pod: just pass some configuration values (specific to you application) and the sub-process is restarted if needed.
The configuration should ideally be persisted so that it is still used in case the pods are destroyed and re-created. Not all pods in a given cluster will use the same configuration though (i.e. configuration is instance-specific and not cluster-specific).
The text was updated successfully, but these errors were encountered: