← Back to branch summary

~tcuthbert/ubuntu-repository-cache/squid-mem-max

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Robert Jennings
  • Date: 2014-08-21 02:20:38 UTC
  • Revision ID: robert.jennings@canonical.com-20140821022038-16h2c7qgk51ynvwu
Updates to documentation and added missing copyright file

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
1
 
 * Call out difference between this and squid-deb-proxy/squid-reverse-proxy
2
 
   in README
3
 
 * Configure ephemeral storage for the mirror and squid cache store
4
 
 * Validate repository after rsync is performed
5
 
 * Add active/inactive repository copies so that update/validation can
 
1
 o [Doc] Call out difference between this and 
 
2
   squid-deb-proxy/squid-reverse-proxy in README
 
3
 o [Doc] Add a DESIGN file for in-depth information regarding the charm,
 
4
   reference it in the README
 
5
 o Set apt repository to sync-host for updates so that apt doesn't try to
 
6
   contact the mirror this charm is providing
 
7
 o Configure storage for the mirror and squid cache store
 
8
 o Validate repository after rsync is performed
 
9
 o Add active/staging repository copies so that update/validation can
6
10
   occur without changing view for clients
7
 
 * Add relationship to support haproxy front-end
8
 
 * Add basic peer relationship for horizontal scaling
9
 
 * Add simplified leadership mechanism for peers
10
 
 * Add ability for peers to rsync from leader
11
 
 * Add method for synchronized switch to new metadata by all peers
12
 
 * Add monitoring support
13
 
 * Test with multiple HAProxy frontends
14
 
 * Test failure scenario edge cases
15
 
 * When juju supports leader elections, switch to that.
16
 
 * Determine how charm install will be affected by lack of reachable
17
 
   archive mirror (as the charm will be the mirror).  May need to defer
18
 
   update during deploy and then change apt's repos to point to a
19
 
   definitive source.
20
 
    * Set apt repository to sync-host for updates
 
11
 o Use same IP for entire sync operation from master
 
12
 o Abort if update in progress on master (or choose new IP from pool)
 
13
 o Abort (or choose new IP from pool) if master metadata is older than current
 
14
 o Create cron job for content update
 
15
   ('juju run or relation-set' to trigger hooks on peers
 
16
    Notes: need to set env var JUJU_RELATION_ID and JUJU_REMOTE_UNIT.
 
17
    `juju run ...` can only be used to invoke triggers on local unit.
 
18
    Use `relation-list -r JUJU_RELATION_ID` to get all units, loop
 
19
    through units triggering hook with `relation-set -r <JUJU_RELATION_ID> \
 
20
    key=val <JUJU_REMOTE_UNIT>` to trigger remote hooks.)
 
21
 o [Scale] Add NTP support
 
22
 x [Scale] Add relationship to support haproxy front-end
 
23
 o [Scale] Add basic peer relationship for horizontal scaling
 
24
 o [Scale] Add method for updating staging copy of metadata on peers
 
25
 o [Scale] Add method for synchronized switch to staged metadata by all peers
 
26
 o Add npre monitoring relationship support
 
27
 o [Scale] Test with multiple HAProxy frontends
 
28
 o Test failure scenario edge cases
 
29
 o Document juju environments.yaml config option to skip apt update/upgrade
 
30
   on automated deployment when available (juju 1.21?).  Otherwise deploy
 
31
   could block on the archive if the charm is supposed to be providing the
 
32
   archive content for the cloud image.
 
33
 o Add logging relationship support
 
34
 o Add generic monitoring relationship support (look at mysql as example)