On 19 Aug 2015, at 16:43, Sam Hartman <[log in to unmask]> wrote:
> Adam, I'd like to ask you to look over the config file handling in this.
> In particular, I think that the handling your init script does where it
> tries a candidate config will not work with this model.

I don't handle this in the init script (the init script just has the capability to managed multiple instances and execute a functional test on a running instance). My update scripts will require changes.

> The assumption is that the trust router will reload its config into the
> running process.

Great.

> So, you might want to think about what checks we need to be able to do
> on a config or what requirements you have in this space.

So, what I want is a switch (-c?) that runs the config parsing, and returns 0 if the config parses with no errors - i.e. the trust router believes to the best of its ability the config will load. This eliminates the part of my update code where I parse logs to make sure I get the error "Address already in use".

The second thing my update script does is a functional test - it creates a new directory, builds the config and executes it on a different port, then attempts an authentication. I expect this part to remain, unless you have any ideas on how to predict if the trust router will halt or continue into infinity with a given config :)

If that succeeds, it then initiates a HA failover, waits for all connections to be terminated, kills tr-instance1, restarts it, initiates another HA failover, waits for all connections to be terminated, kills tr-instance2, restarts it.

I would very much like this section to be replaced.

My preference would be for explicit reconfiguration (SIGHUP?), rather than something like inotify. Having the configuration magically reload itself would present problems with atomicity; valid yet nonsensical configurations could end up being loaded, causing a brief outage.

Time based config reloads (i.e. every 30 seconds) could result in the same issue.

Any error in reloading the config should result in the config reload being aborted, and some kind of alert being raised (but should not block any further attempts to reload the config).

Regards,

Adam Bishop
Systems Development Specialist

  gpg: 0x6609D460
    t: +44 (0)1235 822 245
 xmpp: [log in to unmask]

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.