[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 00/10] mirror: allow switching from background to active m
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v2 00/10] mirror: allow switching from background to active mode |
Date: |
Thu, 29 Feb 2024 06:28:12 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:
> On 03.11.23 18:56, Markus Armbruster wrote:
>> Is the job abstraction a failure?
>>
>> We have
>>
>> block-job- command since job- command since
>> -----------------------------------------------------
>> block-job-set-speed 1.1
>> block-job-cancel 1.1 job-cancel 3.0
>> block-job-pause 1.3 job-pause 3.0
>> block-job-resume 1.3 job-resume 3.0
>> block-job-complete 1.3 job-complete 3.0
>> block-job-dismiss 2.12 job-dismiss 3.0
>> block-job-finalize 2.12 job-finalize 3.0
>> block-job-change 8.2
>> query-block-jobs 1.1 query-jobs
>>
>> I was under the impression that we added the (more general) job-
>> commands to replace the (less general) block-job commands, and we're
>> keeping the latter just for compatibility. Am I mistaken?
>>
>> Which one should be used?
>>
>> Why not deprecate the one that shouldn't be used?
>>
>> The addition of block-job-change without even trying to do job-change
>> makes me wonder: have we given up on the job- interface?
>>
>> I'm okay with giving up on failures. All I want is clarity. Right now,
>> I feel thoroughly confused about the status block-jobs and jobs, and how
>> they're related.
>
> Hi! I didn't notice, that the series was finally merged.
>
> About the APIs, I think, of course we should deprecate block-job-* API,
> because we already have jobs which are not block-jobs, so we can't deprecate
> job-* API.
>
> So I suggest a plan:
>
> 1. Add job-change command simply in block-core.json, as a simple copy of
> block-job-change, to not care with resolving inclusion loops. (ha we could
> simply name our block-job-change to be job-change and place it in
> block-core.json, but now is too late)
>
> 2. Support changing speed in a new job-chage command. (or both in
> block-job-change and job-change, keeping them equal)
>
> 3. Deprecate block-job-* APIs
>
> 4. Wait 3 releases
>
> 5. Drop block-job-* APIs
>
> 6. Move all job-related stuff to job.json, drop `{ 'include': 'job.json' }`
> from block-core.json, and instead include block-core.json into job.json
Sounds good to me.
> If it's OK, I can go through the steps.
Lovely!