network tests: switch to ifupdown2 adapt allow-* to auto, and drop the one test where behaviour is not testable anymore. Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
section config: avoid unamed boolean parameter use hash 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>
section config: add tests for separated property lists more or less a copy from the normal section config test, but now with properties defined multiple times as well as conflicting options Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> [ TL: improve consistency with property-isolation terminology ] Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
SectionConfig: fix handling unknown sections 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>
section config: implement array support 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>
JSONSchema: add support for array parameter in api calls, cli and config a few things were missing for it to work: * on the cli, we have to get the option as an array if the type is an array * the untainting must be done recursively, otherwise, the regex matching converts an array hash into the string 'ARRAY(0x123412341234)' * JSONSchema::parse_config did not handle array formats specially, but we want to allow to specify them multiple time * the biggest point: in the RESTHandler, to be compatible with the current gui behavior, we have to rewrite two parameter types: - when the api defines a '-list' format for a string type, but we get a list (because of the changes in http-server), we join the list with a comma into a string - when the api defines an 'array' type, but we get a scalar value, wrap the value in an array (because for www-form-urlencoded, you cannot send an array with a single value) add tests for this behavior, some of which we want to deprecate and remove in the future Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
tests: section config: comment need for warn on debugging as often only warn really makes it out of perl/our pit of std out/err handling (e.g., I had a case where neither print STDERR nor syslog worked, but warn did) also, the tests are rather brittle w.r.t their expect_fail variant, as the actual expected error should be enforced. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
CalendarEvent: use rust implementation by replacing the parsing code and 'compute_next_event' by their PVE::RS::CalendarEvent equivalent adapt the tests, since we do not have access to the internal structure (and even if we had, it would be different) and the error messages are different the 'compute_next_event' and parsing tests still pass though Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
inotify: network: improve "allow-hotplug" & "auto" interaction commit c86cfb8bbd9b505d06b580582297fa670561437b dropped allow-hotplug from the primary interfaces file completely on write, but that breaks setups that come from plain Debian. Instead, as stop-gap measurement, transform "allow-hotplug" to auto in the PVE controlled config. That avoids conflict and improves installing PVE on top of plain Debian, as the interface still comes up after the first reboot. But it is not ideal auto is not the same as hotplug, so we need to also track that difference in the future, but that needs some adaptions in the API too (change autostart from boolean to string+enum or so= Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>