What is the proper procedure for upgrading a redundant ignition system so the clients do not get kicked off? upgrade the master first or the backup?
Currently, the best way is to upgrade the master first. When you take the master down, the clients will switch over. Then, after the master is upgraded, the clients will switch back, and will update if necessary. You can then update the backup.
The problem is that when the backup is a different version, it gets marked as “incompatible”, and won’t become active (since it’s not receiving project updates, and could be running an old version of the project). So, upgrading the backup first doesn’t work correctly, as the clients won’t be allowed to connect to it.
This is the part that has got me in the past it seems that all the clients update at this point without user intervention. Can the update bar at the top of the client screen show up instead of an automatic update? The reason being what if the user is in the middle of typing or some other action and the client just auto updates on them?
Correct me if I’m wrong, but wouldn’t “Notify” publish mode provide the alert bar you are seeking, or soesn’t that apply when doing upgrades?
You’re right, they do update right away. This is something we should look at improving. Once the gateway has been updated, we can’t wait to update clients- they may not be able to talk to the gateway any more (we could try to make them more resilient to gw versions, but depending on the upgrade, there will always be the chance that they’ll need to update).
The best thing I can think of at this moment to do would be to allow you to upgrade the backup first, and then force a transfer of the clients to that new backup version. The clients would get a bar that says “Client will transfer in 30…29…etc Seconds” with a button for “Cancel Transfer” (and maybe one for “Ok”). If cancel is selected, all clients will stay on the current master. If all clients say OK, or the timer runs out, the backup will be made active, all clients will go over there and update, and the master can then be shut down and upgraded. What do you think?
That is how we have all our clients setup, but the notify settings seems to be for when saving a project not for when upgrading the gateway.
The manual client switch sounds like it could be useful. If some one says no to the upgrade could I then try asking again at a later time to see if all clients are ok with switching?
Would it also be possible to add a scheduled client switch? So i could make all clients at 2 AM switch without prompting the user. then when i come in the next morning i can upgrade the master gateway.
The idea to manually switch clients over is already in the feature request system (the ticket system we have, not the feature request forum), but it doesn’t have the idea of switch veto’ing or scheduled switching. I’ll add those ideas onto it.
We’re going to have a few meetings in the next few days to go over timelines. The next update is going to focus on tackling many of the feature requests that have been outstanding for a while. I think these ideas are pretty important, and have been coming up as many more companies add in redundancy.