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

[Fiona Ebner]

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.