In order to make the parser somewhat more maintainable in the future,
this commit cleans up its logic and makes its control flow easier to
follow.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Replace `foreach` with `for` and use postfix deref instead of block
(circumfix) dereference (`$foo->%*` instead of `%$foo`).
Furthermore, make `format_config_line` a private sub instead of
unnecessarily declaring it as an anonymous subroutine, which avoids
the `&$sub_ref(...)` syntax altogether.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Even with just one param it's extra work to check what it refers too,
with named ones in a hash one hasn't that issue even with many params.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
When using 'init(property_isolation => 1)', the code saves the
property lists per type instead of a big one, and using
create/updateSchema creates a new schema with the options as 'oneOf'
and/or 'instance-types' (depending if the schemas match).
With that, we change how we work with the options hash:
It's not needed anymore to specify options that are specified in the
type specific propertyList, except if it's 'fixed => 1' (since that does
not exist in the schema)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: ensure consistency with new property-isolation terminology ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if we're parsing an unknown section, we cannot check the schema with
`is_array` to check if it's an array type or not, thus we have to
handle that separately.
fix this by handling data in unknown sections like an array similar to
"cb2646c7b4974e33f4148752deec71f0d589b0f3" in proxmox-section-config.
This way we can write unknown section out again like we parsed it.
Add a regression test for an unknown field not in the schema.
This fixes an issue, where calling `qm destroy ID --purge` removed much
of the configs ob backup jobs (since there we parse an 'unknown' section
and run into the `is_array` error)
(Reported in the forum: https://forum.proxmox.com/threads/132091)
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
enables section configs in the style of:
----
type: id
property value
property value2
property value3
----
can be combined with property strings
the provided create and update schema just pass through the array type
to the api, so the api call must always contain the complete array
also adds a test case for such array fields
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This is a pattern that can be found often in Proxmox VE's API stack,
so implement it centrally here for re-use.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This adds an opt-in flag to `parse_config` and
`write_config` to allow for unknown section types.
This will simply be left unverified.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
so that callers can know about them. This is useful in places where we'd rather
abort then continue with a faulty configuration. For example, when reading the
storage configuration before executing a backup job.
Originally-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It turns out that the line number counting was also broken (even on
files without multiple blanks), since the body of the while inside
the nextline subroutine would not be executed for a blank.
I guess the subroutine was intended to skip comments and blanks, but
since we use blanks to recognize the end of a section, I changed it
to only skip comments.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
If, somehow, someone passes a config to check_config with keys set
that are not in the options for that type, this fixed check
lead to autovivification, meaning that any future calls to the same
worker had an additional option for that type which is not optional
this lead to a wrongfully deleting of entries when updating an entry of
a different type, since all entries of the original types suddenly
did not satisfy their required options and would not get parsed
by read_file anymore (thus missing when a successful write_file was done)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This is important when we convert the result to JSON.
Else the GUI receives booleans as "0", which evaluate to true
in JS!
NOTE: "0" evaluates to false with perl.
Because when only writing the ones which are true we're
breaking the ones which default to true (like the mkdir
option on directory storages, where we need a false value
to be written out explicitly).
The old code used string substitution for every line of the
input string, while perl can also iterate over all matches
via the /g re modifier, and can turn ^ and $ to act as
beginning/end of line via the /m modifier.
Effectively allowing a "match over all lines" via a simple
while ($data =~ /^.*$/gm);
The situation is a little different in SectionConfig because
there's a nested loop invovled which doesn't work with /g.
For this there are two options and I chose the safer one by
simply doing a split on newlines first.
The alternative would be to open the data as a
filehandle-to-string and use <$fh> to read lines, however
I'd have to throw in an eval{} to be sure to close the
handle afterwards.
