Deal with CLMSG_PROGRESS sent to gosa-si-server not responsible for the job

[mbenkmann]

From matthias...@gmail.com on May 09, 2013 11:55:01

Situation:

1. Client is on and registered at go-susi server A
2. Server A launches update or install job for Client
3. Client reboots in response to the job
4. Client registers at gosa-si-server B (for whatever reason, e.g. because Client was only registered at A because B was not available at the time it booted up, even though B is its assigned server)
5. Client sends CLMSG_PROGRESS to server B
6. The job is not removed when it is done, because server B does not see itself responsible for the job and server A does not get the CLMSG_PROGRESS

Original issue: http://code.google.com/p/go-susi/issues/detail?id=124

[mbenkmann]

From mux2...@gmail.com on May 14, 2013 08:39:02

Another problem in this scenario:

Server B does not update the of the job.

[mbenkmann]

From mux2...@gmail.com on May 14, 2013 08:41:38

I think I should check the uses of JobsModifyLocal() to see if they should be changed to JobsModify(). If I get a CLMSG_* from a client, then obviously I should update the job, no matter if the job is local or not.

Another idea: When receiving here_i_am, modify all jobs in status processing to have me as the siserver. Can I successfully send this to a peer via fju?

[mbenkmann]

From mux2...@gmail.com on May 16, 2013 06:46:18

The implementation planned for issue #34 will eliminate this issue here as well, because when server B gets the here_i_am, it will create a new local job and will send server A fju for that job (with status processing). This will cause server A to discard its job and replace it with server B's. This works even with gosa-si-server because gosa-si-server's behaviour AFAICT gives the same results.

[mbenkmann]

From mux2...@gmail.com on May 21, 2013 03:20:52

Done

Status: Done