Log of thoughts and implementation issues for the MirrorImprovementsProject


* The mirror_client

Could be resource only, no need for an actual component, but as we want to provide tools to let people query the status of their mirror, we might as well do this as component methods.

All the "client" does is configure rsync, it doesn't have its own daemon to stop and start. In future we could perhaps have the client start its own rsync on a non-standard port, so that we don't have to rely on LCFG macros to configure rsync resources, and so avoid clashing with other uses of the rsync component. But not for this version.

Nothing to do for "configure" or "run", but would provide method(s) to provide a report/status of mirror.


  • mirrorservers
  • taglist *
  • source_tag *
  • tape_tag *
  • cluster/group * (for reporting)
* = export to spanning map


changed "tape_tag" to "totape_tag".

subscribed to a mirrors server spanning map.

started lcfg-rmirror-client component


Turns out you can't publish tagged lists via spanning maps. Need some otherway of sharing the info. Two suggestions

  1. the mirror servers parse the mirror client profiles themselves to get the info (yuk)
  2. encode what we want in a single resource and unpack it at the server (slightly less yuk)

Will go with option 2, and only share what we need, ie name of rsync target and whether to tape or not. We'll make the group a per client resource, not a per tagged item resource. And the server doesn't really need to know the source dir.


Rename rmirror-client component to just rmirrorclient. Having - (dash) in the name isn't a good idea.

Try out the new encoded version of resources for the spanning maps.

Making the rmirror client a full version of rsync does look like the better way to do it. So there's only one set of resources to define, rather than using macros to set rsync and rmirrorclient ones. It would also mean more control over the rsync config file, as we don't have to share it with the regular rsync component. It would just run on a different port from the usual rsync. But for now, we'll bash on with plan A, ie macros to configure both components.


-- NeilBrown - 01 Oct 2010

Topic revision: r5 - 05 Oct 2010 - 15:27:36 - NeilBrown
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies