Provide progress updates when installing/removing packages (opkg) #51328
Labels
Feature
new functionality including changes to functionality and code refactors, etc.
Pending-Discussion
The issue or pull request needs more discussion before it can be closed or merged
Milestone
We need to define a way to provide progress updates when installing/removing packages. Before creating a PR I want to make sure that we all approve the solution for this since it can be applied to any pkg implementation.
In the following lines I will refer to opkg and any solution we chose should not be the default case (we will execute the "progress updates code path" only if a certain key-value pair is present in kwargs).
First task to solve is how we can get real-time information from opkg during an opkg install operation. From what I know opkg doesn't support writing the output to a specific file.
One way to do this is by reading the stdout through pipe. Something like this:
proc = subprocess.Popen(cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
while True:
try:
output = proc.stdout.readline().decode("utf-8")
except:
...
if output == '' and proc.poll() is not None:
break
...
So we have the updates from opkg but what can we do to inform the master?
We could fire an event to salt-master bus from here(opkg.install function) to inform the master which package is currently being installed/downloaded. We can use a time interval that can be provided through kwargs to avoid the congestion of salt-master event bus. In addition to that we could count the number of packages that were installed and provide this number as well.
We can write the output to a file (/var/volatile/something) and let another salt component be responsible of notifying the master with the updates. My first thought is that the file should have the same name as the id of the job and it should be deleted after the command is completed (here we could have problems if we run two pkg.install jobs in the same time, I will think about it if we go with this solution). I feel that the update load should contain the job_id to be as explicit as possible. Then we could have a beacon that can read the file and fire the event with the updates to the salt master. The beacon will do nothing if it doesn't find a file in that specific directory. Or we could have an inotify beacon that is watching the folder for updates and implement a module that can process the file content and return the progress.
Do we cross the red line if we implement the first solution? Is it too much for an execution module to fire events to the salt-master bus? Are we too intrusive? The second solution seems lighter and less-coupled.
What do you guys think about this?
@terminalmage @rares-pop @skizunov @adelcast
The text was updated successfully, but these errors were encountered: