[pve-devel] [PATCH manager v5 05/16] api: replication: add 'replication-job' to notification metadata

[Lukas Wagner]

On  2024-04-19 15:11, Fiona Ebner wrote:
> Am 19.04.24 um 14:22 schrieb Lukas Wagner:
>>
>>
>> On  2024-04-19 14:02, Fiona Ebner wrote:
>>> Am 15.04.24 um 10:26 schrieb Lukas Wagner:
>>>> This allows users to create notification match rules for specific
>>>> replication jobs, if they so desire.
>>>>
>>>> Signed-off-by: Lukas Wagner <l.wagner at proxmox.com>
>>>> ---
>>>>  PVE/API2/Replication.pm | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/PVE/API2/Replication.pm b/PVE/API2/Replication.pm
>>>> index 0dc944c9..703640f5 100644
>>>> --- a/PVE/API2/Replication.pm
>>>> +++ b/PVE/API2/Replication.pm
>>>> @@ -140,8 +140,8 @@ my sub _handle_job_err {
>>>>      };
>>>>  
>>>>      my $metadata_fields = {
>>>> -	# TODO: Add job-id?
>>>>  	type => "replication",
>>>> +	"replication-job" => $job->{id},
>>>>      };
>>>>  
>>>>      eval {
>>>
>>> Not sure if we should use "replication-job" and "backup-job" for the
>>> metadata entries rather then just "job-id". The type is already
>>> something that can be matched, why re-do it implicitly with the field
>>> name? E.g. I want to see all jobs with -fiona- on the system, now I'd
>>> have to create a matcher rule for each job type.
>>
>> Had a 'job-id' field at first, but I *think* (can't be too sure after more than 
>> 4 months of not working on this) the reason why I changed it to this approach
>> were the replication job IDs, which look like '100-0' or similar.
>> Giving them and other job IDs a unique field made it a bit easier to
>> understand what is what when creating a matcher in the improved UI.
>>
>> For instance, if you just have 'job-id', the pre-filled combo box in the 
>> match-field edit UI might contain these values
>>
>>   - backup-gaasdgh7asdfg
>>   - 100-0
>>   - 101-0
>>
>> IMO it's a bit hard to understand that the last two are replication jobs. The separate
>> job fields make this easier.
> 
> We know that it either starts with "backup-" (or "realmsync-", should
> those get notifications), or is a replication job. So we could also just
> display something that indicates they are replication jobs (e.g.
> "replication-XYZ" or "XYZ (replication)"), until we turn replication
> jobs into proper jobs in the backend. Otherwise, each job type we add
> will just have a new matcher field for its ID.

Ok, fine with me. :)

-- 
- Lukas