Currently, the API server (manager/create-a-container) knows almost nothing about site agents (pull-config clients). Agents are essentially stateless, just querying the API server for configs per the rules of pull-config. What I'd like to do instead is have each agent "check-in" with the manager. This will be on the same schedule as pull-config, but will send additional data, including system info (hostname, ip addresses, etc) and last sync status (success/failure).
Instead of relying on ETags, the API server should respond to the check-in with the services that need updated. This should reduce the overall request load as well and enable caching in a future update.
This will then allow admins to see what agents are active for a site, when they last checked in, their current health. It will also allow the API server to make intelligent decisions about other containers based on the agent status.
Currently, the API server (manager/create-a-container) knows almost nothing about site agents (pull-config clients). Agents are essentially stateless, just querying the API server for configs per the rules of pull-config. What I'd like to do instead is have each agent "check-in" with the manager. This will be on the same schedule as pull-config, but will send additional data, including system info (hostname, ip addresses, etc) and last sync status (success/failure).
Instead of relying on ETags, the API server should respond to the check-in with the services that need updated. This should reduce the overall request load as well and enable caching in a future update.
This will then allow admins to see what agents are active for a site, when they last checked in, their current health. It will also allow the API server to make intelligent decisions about other containers based on the agent status.