Since VZDump/JobBase.pm in guest-common doesn't declare that it has an
option 'id', this is unused anyway and the auto-inject logic wouldn't
trigger.
Alternatively, the 'id' option could be added in VZDump/JobBase.pm (as
optional, because existing jobs.cfg don't contain the id as a property
within the section), but it would lead to the id being written to the
section in write_config, which is not nice at all as the id is already
in the header.
Signed-off-by: Fiona Ebner <f.eb...@proxmox.com>
---
src/PVE/Job/Registry.pm | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/src/PVE/Job/Registry.pm b/src/PVE/Job/Registry.pm
index 32e0272..03bed5e 100644
--- a/src/PVE/Job/Registry.pm
+++ b/src/PVE/Job/Registry.pm
@@ -18,14 +18,6 @@ use base qw(PVE::SectionConfig);
my $defaultData = {
propertyList => {
type => { description => "Section type." },
- # FIXME: remove below? this is the section ID, schema would only be
checked if a plugin
- # declares this as explicit option, which isn't really required as its
available anyway..
- id => {
- description => "The ID of the job.",
- type => 'string',
- format => 'pve-configid',
- maxLength => 64,
- },
enabled => {
description => "Determines if the job is enabled.",
type => 'boolean',
@@ -66,11 +58,6 @@ sub parse_config {
my $data = $cfg->{ids}->{$id};
my $type = $data->{type};
- # FIXME: below id injection is gross, guard to avoid breaking plugins
that don't declare id
- # as option; *iff* we want this it should be handled by section config
directly.
- if ($defaultData->{options}->{$type} && exists
$defaultData->{options}->{$type}->{id}) {
- $data->{id} = $id;
- }
$data->{enabled} //= 1;
$data->{comment} = PVE::Tools::decode_text($data->{comment}) if
defined($data->{comment});
--
2.30.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
