autonomic-cooperative/multiball
1
0
Fork 1
Code Issues 4 Pull Requests Packages Projects Releases Wiki Activity

can we automate "list the hostnames of each server to be upgraded" #5

New Issue
Open
opened 2025-10-02 16:19:28 +00:00 by trav · 1 comment
trav commented 2025-10-02 16:19:28 +00:00
Owner
Copy Link

in the instructions it says "list the hostnames of each server to be upgraded". The output from upgradable was like 1200 lines. Shouldn't it be possible to automatically create a list of hosts to upgrade from this? Or at least parse the output from upgradable to display an easier to work with list?

in the instructions it says "list the hostnames of each server to be upgraded". The output from upgradable was like 1200 lines. Shouldn't it be possible to automatically create a list of hosts to upgrade from this? Or at least parse the output from `upgradable` to display an easier to work with list?
cas commented 2025-10-03 20:02:25 +00:00
Owner
Copy Link

Short answer yes, also it's been in my plans since I started multiball, also I have started working on that project.

Long answer:

The upgrade process is meant to require you to reason about the upgradable output. We don't show the lines to have a long thing you have to paste for the sake of it: you're meant to look at the list and decide to reboot (or not) servers in question based on what needs to be upgraded. It also allows us to see when a particular package was upgraded for debugging purposes in case things break unexpectedly and/or invisibly after the upgrade process.

This reasoning step is part of the labor of the upgrade process which I hope to simplify but not eliminate: upgrading isn't meant to be a hands-off process, it's meant to be a safe process that doesn't leave us with mysterious breakages.

Short answer yes, also it's been in my plans since I started multiball, also I have started working on that project. Long answer: The upgrade process is meant to require you to reason about the upgradable output. We don't show the lines to have a long thing you have to paste for the sake of it: you're meant to look at the list and decide to reboot (or not) servers in question based on what needs to be upgraded. It also allows us to see when a particular package was upgraded for debugging purposes in case things break unexpectedly and/or invisibly after the upgrade process. This reasoning step is part of the labor of the upgrade process which I hope to simplify but not eliminate: _upgrading isn't meant to be a hands-off process_, it's meant to be a safe process that doesn't leave us with mysterious breakages.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aadil analuisa autono-bot autonomic cas kawaiipunk knoflook lucas maazah notplants renovate-bot tma trav veganvenom
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: autonomic-cooperative/multiball#5
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?