will-moss
[Feature Request] Bulk restart / Bulk Recreate
Hello,
First of all thanks for this tool ! It's a life saver !
Would it be possible to implement a bulk restart & a bulk recreate ?
I would like to update all my stack at once and then have the ability to restart / recreate everything at once.
Thanks for your help :)
Hadrien
Hi Hadrien !
Thanks a lot for opening the issue, as well as for the kind words.
Just to make sure :
- There is currently a bulk restart feature that is already available (Stacks > Bulk actions > Restart all stacks).
- You would like to be able to perform a "Stacks > Bulk actions > Restart all stacks with --force-recreate flag".
Am I understanding correctly?
Then, the new flow would be :
- Focus the Stacks panel
- Show the bulk actions
- Pick "restart all stacks"
- A prompt appears, and we must choose between "restart all stacks" and "restart all stacks with --force-recreate"
- After selection, the appropriate command is executed.
Would that meet your need?
Let me know, and thanks again!
Will
Hello Will, thx for your fast answer !
I'm not sure where is the Stacks panel you are reffering too.
Here is my current setup :
One master node, a lot of agents : https://i.imgur.com/BC80IxQ.png
Here is all of my bulk commands on the container tab : https://i.imgur.com/xxRbkFS.png
I currently don't have an option "Restart all containers".
I think the new flow you are proposing would be perfect in this context !
Hadrien
Re Hadrien,
Thank you very much as well for those details and for confirmining the flow.
Please find hereafter a screenshot where the Stacks panel is visible on my end : https://ibb.co/pjtgMMpG
This panel will automatically appear if Isaiah detects any "Docker Compose" project on your system.
You can also press the key "C", copy-paste a docker-compose.yml file, and create a new stack. Also, if you have existing stacks detected by Isaiah, you can also use all those features : https://ibb.co/KjjfwyZg
In your case, I think this panel doesn't appear because either you installed Isaiah via the Docker image rather than via the binary executable, or you just don't have any Docker Compose project running on your Master / Agents that could be detected. (Relevant part of the documentation : https://ibb.co/bMP1qKvj)
Now all that being said, I will soon push a release that includes the "Bulk restart" feature for the containers.
See you soon here again !
Hi again,
I've just published a new version that includes two new bulk actions for the containers : bulk restart, and bulk update.
You can pull the latest image / replay the install script !
Just like before, the "bulk update" is marked as experimental because it isn't a native feature provided by the Docker API.
I hope that it works well on your end, and meets your need.
Cheers
Hi,
Just wanted to ask if everything was working on your end, and if the issue could be closed.
Without response, I may close it in a few weeks.
Thanks in advance!
@will-moss Hello :)
I miss your answer sorry ! Didn't think you'll add it so fast ! thx a lot !
I just tested it, there is an issue with the bulk update / restart.
I think it's stopping isaiah's container first and that means it can't restart itself / the other containers. When I try to restart / update, I just loss connexion to the agent and I have to manually connect to the server to restart / update everything manually :)
Hi !
Thanks a lot for reporting back, and very sorry for the extra issue caused.
I've just published a new version that fixes it, and that also fixes previous scenarios that I hadn't thought about (namely : bulk restarting would cause Isaiah to try to restart itself, bulk stop would cause Isaiah to stop itself, and bulk remove...well, you've guessed it !). There is now an internal to prevent Isaiah from killing itself during bulk operations.
The newly-versioned image is published.
Thanks again for investigating and for your feedback.
Hope that it all works fine now 🙏
@will-moss I've made a first test (but all my containers where already updated, so I will make an other one in a few days), it's working perfectly fine !
I've got two suggestions :
- when it's updated it currently shows the ID of the container instead of the container_name. That a bit hard to check.
- After it's done updating the other containes, could the isaiah agent try to update itself ? When I try to make the agent restart itself, it's working fine, a simple restart is working. Not sure if an auto update + recreation is possible.
(none of those suggestions are "important". Isaiah is already AWESOME as is !
Hi again,
Thanks a lot for your kind words, and for the suggestions! Much appreciated.
I've just published a new release (and you can pull the latest image), that will display the containers' name rather than their ID on the UI when performing bulk operations. I was somehow convinced that IDs were better because unique, but I found that the names also had to be unique, so, all good !
As for Isaiah updating itself, I am afraid it cannot work because the container must be stopped and recreated. I've explored the idea of creating a temporary duplicate container, and then replacing the original with the duplicate, but it's also tricky because there are port bindings, and the duplicate is clashing with the original here (as both have the same port bindings). I've included a note for that on the UI, advising to pull the latest image and restart the container. However, if you have any idea of how to implement that or circumvent the limitation I saw, I'll gladly take it!
Looking forward to reading from you, and thanks again!
@will-moss For the Master node, I understand why there would be an issue with the port binding, but for the agents, there is no port binding that would prevent that isn't it ?
Ah this is an excellent remark, and you are absolutely right here. Thanks for pointing that out.
Then, running a bulk update / single update on an Isaiah container that is an Agent node could be implemented, in order to attain self-updating capability on the Agent nodes. I think I foresee a potential case where Agent nodes would be updated to the latest version, but the Master node would be N versions behind, causing new issues.
Can I ask, what do you think about that whole self-updating situation?
For me, on the one hand, I love the idea that Isaiah could update itself (be it Docker-wise, or binary-wise). That would spare everyone the need for checking updates (via the 'V' shortcut by the way), and for updating manually.
On the other hand, I think there's also cases when it's not desirable :
- Some prefer to pin their app to a given version, rather than using the "latest" tag / release.
- Some prefer to go with dedicated updates manager, such as WatchTower.
All that leads me to believe that, either :
- This should be configurable ( = decide, via a configuration variable, whether Isaiah can update itself or not).
- While keeping in mind that, in a Docker setup, updating the Master node wouldn't be doable unless I find a way.
- This should be let to other programs / people to manage.
One solution could be to have 2 Isaiah instance on the master node. One master to rule them all and one agent to update the master. And when you try to update the master, it just send the info to the agent who update the master instead.
Personnaly, I think the choice between manual update / auto update etc, should be left to the user. A simple config check should be enough IMO.
Personnaly, considering my usage of Isaiah, I would love to be able to update everything at once without having to mannually connect into each of my LXCs.
Hello @will-moss
Are you still working on this issue or should I close it ? :)
Have a good day
Hi again Hadrien,
It's a shame because it is implemented at the moment, but I haven't found the time to test it properly before publishing it.
Let's keep that issue open, and I'm hoping that I will soon have the time to test and publish that feature.
By the way, I didn't reply, but I have implemetend the "Update all Remote Agents from Master" part.
As for the "having two instances on the Master node to be able to update the Master" part, I noted that it may be just a little too complex to implement given the time that I have on my hands at the moment. But I kept the idea in my notes to, potentially, work that out and release it when I have more time.
Thank you once again so much, your inputs, reports, and suggestions really help make the app better for everyone, including myself.