Modeling a deployment

Our hosts

           colo (environment)
                      | West | East

application | db | db-w1 | db-e1 | db-w1 | db-e2 | api | api-w1 | api-e1 | api-w2 | api-e2 | api-w3 | api-e3 | web | web-w[1-16] | web-w[1-16]

You must declare a namespace before starting - either by setting it in .pogo_conf or on the commandline.

If the following command is run, "apt-get upgrade foo" will be run against all hosts in hostfile.txt -

irrespective of the above

pogo-run -H hostfile.txt apt-get upgrade foo

Job will be submitted via web service API to dispatcher.

Then ZK nodes will be created:

/pogo/job/pXXXXXXXX (new sequence # created by ZK) /pogo/job/pXXXXXXXX/meta/ /user => user /cmd => command /namespace => namespace /range => range /hosts /db-w1 => state (see below) /... /web-e16 /lock # used to synchronize continuejob orders among dispatchers /slots /db_colo_west # if there are constraints /db-w1

States can be ready running finished (or failed)

/pogo/ns/foo is consistent with /pogo/job/pXXXXX/meta/slots via locking

"slots" node is how concurrency is maintained

/pogo/ns/foo /slots /<env_key><env_value> /<job_id>_

/pogo/lock/*

/pogo/job/pXXXXXXXXX/log/lXXXXXXXXXX => [timestamp, "log content"]

/pogo/taskq/ /

Possible commands in the task queue: runhost : run this job on this host continuejob: reprocess this job (sent by a worker after a task is complete) - dispatcher could then insert a new runhost message startjob: special case of continuejob, initializes ZK with job metadata