Preferred order of launching Wicked Portal micro services

[Krieke]

Is there a preferred order of launching Wicked Portal docker containers? We have seen that when a new "static" config was created with "kickstarter" that sometimes the other running docker containers should also be restarted when the new "Portal API" is launched.

[DonMartin76]

This will change in 0.11.0; all containers depending on portal-api will continuously poll the API to check for a new configuration version (via a content hash of the repository). In case the hash changes, the other containers will shut down and let themselves be restarted by the orchestration layer restart policy (Kubernetes, Docker Compose, Mesos,...).

This means that it will be a lot easier to actually treat the different containers as microservices instead of part of a split up "monolith", and the startup order does no longer matter: The containers wait for the other services to be available and start as soon as that's the case. They check for version changes and restart automatically, if necessary.

Does this answer the question?

[DonMartin76]

See also #36 and #38.

[DonMartin76]

Documentation and code will surface in 0.11.0 (due Monday).