These are not the droids you're looking for

[ludeeus]

Proposed change

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to the supervisor)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast supervisor tests)
• Tests have been added to verify that the new code works.

If API endpoints of add-on configuration are added/changed:

• Documentation added/updated for developers.home-assistant.io

[pvizeli]

Looks fine. We need a concept, how the API should look like to be usable. I think maybe we need also something like this:

MyXy(JobGroup):

    job_group = "xy"

   @Job(lock=True, wait=False, name="Optional name if not method")
   def xy():

And generate /xy/update which is set on the first context and gets inherit to child jobs. So the frontend can get the correct root job. We can also lock future access over this JobGroup. The question is, how we deal with sub progress etc.

API:

job	id	task	parent	progress
/supervisor/update	13kj123lk1j2	Supervisor.update	null	null
	jkfjsdwlf23423	DockerSupervisor.install	13kj123lk1j2	20%

That is just an idea. We need maybe write an RFC and implement that. So that we can start to implement this.

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

[ludeeus]

In due time @github-actions, in due time.

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

[ludeeus]

I think each root activity (started by API access or system), should generate a JobGroup
The JobManager would manage the JobGroup and the JobGroup would manage (create/update/remove) and track individual jobs.

So if you call /supervisor/update:

1. JobManager creates a new JobGroup with a uuid and that API path tracked as the name.
2. The JobGroup will then spawn individual SupervisorJob (jobs) that is needed (update apparmor, install new image, update ) to complete the API call
3. All processes are tracked individually in the jobs, and the JobGroup will keep overall progress.
4. The JobGroup will remove all associated jobs, and request removal of itself by the JobManager when the process is complete (success/fail)

[pvizeli]

make sense, yes

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.