Opened 17 years ago
Closed 15 years ago
#223 closed defect (fixed)
bitten-slave should be notified about Bitten versions on server and client not matching
Reported by: | olle.jonsson@… | Owned by: | osimons |
---|---|---|---|
Priority: | major | Milestone: | 0.6 |
Component: | General | Version: | 0.5.3 |
Keywords: | usability | Cc: | |
Operating System: | BSD |
Description
Explanation by way of a scenario:
When someone updates the server's Bitten via easy_install (to Bitten trunk version), its version gets bumped, say from 516 to 518.
Next morning, I start my bitten-slave, and it just sits there, its POST to the server goes unheeded, since the two pieces of software have different version numbers.
It would be useful to be informed that "No Bitten plugin on the server matches 516" in this case.
Attachments (0)
Change History (4)
comment:1 Changed 15 years ago by osimons
- Milestone 0.6 deleted
comment:2 Changed 15 years ago by osimons
- Milestone set to 0.6
- Owner changed from cmlenz to osimons
comment:3 Changed 15 years ago by osimons
Latest attachment:ticket:421:t421-session_token-r721.diff for #421 incorporates a version check to make sure slave and master correspond. This number bitten.slave.PROTOCOL_VERSION is intended to be bumped for each change to the protocol and dependencies that require slaves and master to be in sync.
Following recent changes, a proper error will also propogate to debug logging on the slave whenever mismatch arise.
comment:4 Changed 15 years ago by osimons
- Resolution set to fixed
- Status changed from new to closed
Protocol version is now part of master-slave communication as part of [723].
I agree. Should think of some simple implementation that basically just bumps a number for each important change in the protocol. For instance, last patch on #421 proposes to use session tokens for identification - which also depends on #208 giving slaves support for cookies in order to store the ids between requests.
It won't be needed for all changes - really the need should be quite rare. But when needed, it would make a safe and simple way of informing slaves that they need to upgrade. The sooner we get this change in, the more we can depend on it to assert that slaves and master are on speaking terms.
The simple implementation would just be for the slave to post its protocol version number as part of configuration when connecting, with master raising some HTTP error if version numbers don't match.