Changes between Version 1 and Version 2 of Meeting17December2010


Ignore:
Timestamp:
Jan 4, 2017, 2:19:14 AM (21 months ago)
Author:
rutsky
Comment:

update "slave" with "worker"

Legend:

Unmodified
Added
Removed
Modified
  • Meeting17December2010

    v1 v2  
    5555   * message broker structure
    5656   * dynamic reconfig via graceful restart
    57    * simplified slaves
     57   * simplified workers
    5858
    5959== Dustin's Notes ==
     
    6464  * assign maintainers to components, and track it officially in git
    6565  * need a loose definition of "maintainer" that can include "concerned user" as a domain expert
    66   * another option: if you like $component, offer a slave to test it.  This is especially relevant for version control
     66  * another option: if you like $component, offer a worker to test it.  This is especially relevant for version control
    6767 * commit rights and other developer permissions
    6868  * I should offer, rather than wait for developers to ask -- push instead of waiting
     
    7373  * continue to operate in firefighting mode for now, rather than trying to take a comprehensive approach without comprehensive APIs
    7474 * Dependency versions
    75   * versions are much more of a worry for buildslaves, rather than masters, so the policy approach should be different
     75  * versions are much more of a worry for workers, rather than masters, so the policy approach should be different
    7676  * python version compatibility is different from prerequisite packages (which can be installed easily if necessary)
    7777  * at a minimum, we should support prerequisite versions shipped with the most recent distro
     
    9494 * Log/artifact Storage
    9595  * separate log server?
    96    * push logs (artifacts) to it directly from slave
     96   * push logs (artifacts) to it directly from worker
    9797   * use a unique identifier (hash?) for the artifact; perhaps pre-generate that unique id before getting the data, if that makes coordination easier
    9898  * tailing is cool, but should be treated as a special case, as the important thing is getting the artifacts where they need to be
    99   * we have lots of models for how data should move: to central server? between two slaves? into a cluster of servers?
     99  * we have lots of models for how data should move: to central server? between two workers? into a cluster of servers?
    100100  * ddunbar is interested in working on / driving this
    101101 * Separate server processes are helpful, but can't be required
     
    106106  * Hosted config generator??
    107107    * loki does a good job here
    108   * Making the slave list dynamically editable
    109     * makes it easy to add/remove a user-submitted slave at runtime
     108  * Making the worker list dynamically editable
     109    * makes it easy to add/remove a user-submitted worker at runtime
    110110    * this is a smaller case of web-based config editor
    111     * do we really need slave "names"?  Can a slave just connect to the master and say "I can do builds"?  (Its identity would be in the build history for debugging purposes)
     111    * do we really need worker "names"?  Can a worker just connect to the master and say "I can do builds"?  (Its identity would be in the build history for debugging purposes)