BitShares Forum
Main => General Discussion => Topic started by: coolspeed on June 07, 2014, 02:04:40 pm
-
In order to provide high availability and faith about the network, and not to be fired for missing blocks in their turn, Delegates must have some DevOps process. I want to discuss some processes from scratch with you all.
As the development lasts, there will always be need to upgrade Delegate program versions. Or you will be fired. And you'd better upgrade on-the-fly.
After every shuffle, the order of next 100 blocks' forgers is determined. So most of the delegates may have time to tear the node down for a while and relaunch it. At this time, another instance needs to be already pulled from GitHub and built. In fact, you may always need a 'left' instance and 'right' instance, just like a seesaw. The left instance and right instance can share the same data directory, which is ~/.BitSharesXTS by default.
If I did not miss something, Delegates can miss no block at all in this way.
-
In order to provide high availability and faith about the network, and not to be fired for missing blocks in their turn, Delegates must have some DevOps process. I want to discuss some processes from scratch with you all.
As the development lasts, there will always be need to upgrade Delegate program versions. Or you will be fired. And you'd better upgrade on-the-fly.
After every shuffle, the order of next 100 blocks' forgers is determined. So most of the delegates may have time to tear the node down for a while and relaunch it. At this time, another instance needs to be already pulled from GitHub and built. In fact, you may always need a 'left' instance and 'right' instance, just like a seesaw. The left instance and right instance can share the same data directory, which is ~/.BitSharesXTS by default.
If I did not miss something, Delegates can miss no block at all in this way.
It is really as simple as having two nodes on the network (different data directories)... then lock one wallet and unlock the other to switch versions. You can take down the locked version for an update and then bring it back up.
Just make sure you don't unlock them both at the same time or you risk producing 2 blocks at once and getting canned on the spot with extreme prejudice.
-
So all we need is just a script that do the lock and unlock stuff automatically and can prevent operators to do it in wrong order.
-
After every shuffle, the order of next 100 blocks' forgers is determined. So most of the delegates may have time to tear the node down for a while and relaunch it. At this time, another instance needs to be already pulled from GitHub and built. In fact, you may always need a 'left' instance and 'right' instance, just like a seesaw. The left instance and right instance can share the same data directory, which is ~/.BitSharesXTS by default.
Thought exactly the same thing :) Also, you don't really need to wait for a shuffle as the time between blocks is 30s and the client starts in much less than that, so you should have time to hot-swap an upgraded delegate at pretty much any time you want. You definitely need to have it built at that time already so you just need to bring it up. I'll probably write some (python or bash) scripts at some point to deal with that, if it seems that this is the way to go, I'll share them on github.
It is really as simple as having two nodes on the network (different data directories)... then lock one wallet and unlock the other to switch versions. You can take down the locked version for an update and then bring it back up.
I'm not sure I understand everything here. Do you mean that a delegate can only sign blocks if its wallet is unlocked? So if I start a delegate and open a wallet, but don't unlock it with its password then it won't sign blocks? How can we deal with timeout for unlocking then? Does wallet_unlock accept a timeout of 0 meaning infinite time? Or did you mean open/close instead of unlock/lock?
Also, do I understand correctly that the IP of the delegate is not important as long as it is able to sign blocks in time, and that it is completely feasible to bring one down with an IP and another one up with another IP? That would be super awesome because it means it is possible to have a backup delegate node in a different location which can immediately be switched up if the first one fails.
-
After every shuffle, the order of next 100 blocks' forgers is determined. So most of the delegates may have time to tear the node down for a while and relaunch it. At this time, another instance needs to be already pulled from GitHub and built. In fact, you may always need a 'left' instance and 'right' instance, just like a seesaw. The left instance and right instance can share the same data directory, which is ~/.BitSharesXTS by default.
Thought exactly the same thing :) Also, you don't really need to wait for a shuffle as the time between blocks is 30s and the client starts in much less than that, so you should have time to hot-swap an upgraded delegate at pretty much any time you want. You definitely need to have it built at that time already so you just need to bring it up. I'll probably write some (python or bash) scripts at some point to deal with that, if it seems that this is the way to go, I'll share them on github.
It is really as simple as having two nodes on the network (different data directories)... then lock one wallet and unlock the other to switch versions. You can take down the locked version for an update and then bring it back up.
I'm not sure I understand everything here. Do you mean that a delegate can only sign blocks if its wallet is unlocked? So if I start a delegate and open a wallet, but don't unlock it with its password then it won't sign blocks? How can we deal with timeout for unlocking then? Does wallet_unlock accept a timeout of 0 meaning infinite time? Or did you mean open/close instead of unlock/lock?
Also, do I understand correctly that the IP of the delegate is not important as long as it is able to sign blocks in time, and that it is completely feasible to bring one down with an IP and another one up with another IP? That would be super awesome because it means it is possible to have a backup delegate node in a different location which can immediately be switched up if the first one fails.
Wallet must be unlocked to have access to the private key used to sign blocks.
IP is irrelevant so multiple nodes is ok.
You can set the unlock time to near infinity unlock 999999999 (30 years)
-
Thanks! Getting super excited about this :D