* [pve-devel] [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup @ 2024-06-04 9:28 Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD Max Carrara ` (3 more replies) 0 siblings, 4 replies; 10+ messages in thread From: Max Carrara @ 2024-06-04 9:28 UTC (permalink / raw) To: pve-devel Section Config: Documentation & Code Cleanup ============================================ The main focus of this series is the comprehensive documentation which is added in patch 01. While not every single quirk and implementation detail may be covered, it should be decent enough to help developers quickly get started with writing their own Section Config plugin architecture. The docs are written in POD - not necessarily because it is a convenient format to write documentation in, but rather because the entire Perl ecosystem uses it. No need to reinvent the wheel. Furthermore, POD is supported by LSPs (at least Perl Navigator), which means that the "docstrings" for Section Config methods will actually show up as inlay hints. Patch 02 updates the module's code style to be more in line with our Perl Style Guide [0]. Patch 03 cleans up the Section Config parser's internal logic and makes its control flow easier to follow. Note that this patch does *not* mean to change the parsing behaviour in any way, as that would risk accidentally breaking existing Section Config plugin architectures or config APIs. Testing ------- Even though the existing unit tests pass, it would be nice if someone could give this series a spin and tried to change or add various config settings, e.g. storage settings and SDN settings, to make sure that the updated parser logic really does behave the same as before. Generating Docs --------------- If you prefer to read the added docs in a different format, you may use `perldoc` to render e.g. a webpage of the module's docs instead: $ perldoc -ohtml src/PVE/SectionConfig.pm > docs.html $ firefox docs.html Summary of Changes ------------------ Max Carrara (3): section config: document package and its methods with POD section config: update code style section config: clean up parser logic src/PVE/SectionConfig.pm | 982 +++++++++++++++++++++++++++++++-------- 1 file changed, 798 insertions(+), 184 deletions(-) -- 2.39.2 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD 2024-06-04 9:28 [pve-devel] [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Max Carrara @ 2024-06-04 9:28 ` Max Carrara 2024-06-11 10:46 ` Fabian Grünbichler 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 2/3] section config: update code style Max Carrara ` (2 subsequent siblings) 3 siblings, 1 reply; 10+ messages in thread From: Max Carrara @ 2024-06-04 9:28 UTC (permalink / raw) To: pve-devel Apart from the obvious benefits that documentation has, this also allows LSPs to provide docstrings e.g. via 'textDocument/hover' [0]. Tested with Perl Navigator [1]. [0]: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_hover [1]: https://github.com/bscan/PerlNavigator Signed-off-by: Max Carrara <m.carrara@proxmox.com> --- src/PVE/SectionConfig.pm | 737 +++++++++++++++++++++++++++++++++++---- 1 file changed, 672 insertions(+), 65 deletions(-) diff --git a/src/PVE/SectionConfig.pm b/src/PVE/SectionConfig.pm index a18e9d8..99ee348 100644 --- a/src/PVE/SectionConfig.pm +++ b/src/PVE/SectionConfig.pm @@ -10,65 +10,102 @@ use PVE::Exception qw(raise_param_exc); use PVE::JSONSchema qw(get_standard_option); use PVE::Tools; -# This package provides a way to have multiple (often similar) types of entries -# in the same config file, each in its own section, thus "Section Config". -# -# The intended structure is to have a single 'base' plugin that inherits from -# this class and provides meaningful defaults in its '$defaultData', e.g. a -# default list of the core properties in its propertyList (most often only 'id' -# and 'type') -# -# Each 'real' plugin then has it's own package that should inherit from the -# 'base' plugin and returns it's specific properties in the 'properties' method, -# its type in the 'type' method and all the known options, from both parent and -# itself, in the 'options' method. -# The options method can also be used to define if a property is 'optional' or -# 'fixed' (only settable on config entity-creation), for example: -# -# ```` -# sub options { -# return { -# 'some-optional-property' => { optional => 1 }, -# 'a-fixed-property' => { fixed => 1 }, -# 'a-required-but-not-fixed-property' => {}, -# }; -# } -# ``` -# -# 'fixed' options can be set on create, but not changed afterwards. -# -# To actually use it, you have to first register all the plugins and then init -# the 'base' plugin, like so: -# -# ``` -# use PVE::Dummy::Plugin1; -# use PVE::Dummy::Plugin2; -# use PVE::Dummy::BasePlugin; -# -# PVE::Dummy::Plugin1->register(); -# PVE::Dummy::Plugin2->register(); -# PVE::Dummy::BasePlugin->init(); -# ``` -# -# There are two modes for how properties are exposed, the default 'unified' -# mode and the 'isolated' mode. -# In the default unified mode, there is only a global list of properties -# which the plugins can use, so you cannot define the same property name twice -# in different plugins. The reason for this is to force the use of identical -# properties for multiple plugins. -# -# The second way is to use the 'isolated' mode, which can be achieved by -# calling init with `1` as its parameter like this: -# -# ``` -# PVE::Dummy::BasePlugin->init(property_isolation => 1); -# ``` -# -# With this, each plugin get's their own isolated list of properties which it -# can use. Note that in this mode, you only have to specify the property in the -# options method when it is either 'fixed' or comes from the global list of -# properties. All locally defined ones get automatically added to the schema -# for that plugin. +=pod + +=head1 NAME + +SectionConfig + +=head1 DESCRIPTION + +This package provides a way to have multiple (often similar) types of entries +in the same config file, each in its own section, thus I<Section Config>. + +Under the hood, this package automatically creates and manages a matching +I<JSONSchema> for one's plugin architecture that is used to represent data +that is read from and written to the config file. + +Where this config file is located, as well as its permissions and other related +things, is up to the plugin author and is not handled by C<PVE::SectionConfig> +at all. + +=head1 USAGE + +The intended structure is to have a single I<base plugin> that inherits from +this class and provides meaningful defaults in its C<$defaultData>, such as a +default list of core C<PVE::JSONSchema> I<properties>. The I<base plugin> is +thus very similar to an I<abstract class>. + +Each I<child plugin> is then defined in its own package that should inherit +from the I<base plugin> and defines which I<properties> it itself provides and +uses, as well as which I<properties> it uses from the I<base plugin>. + +The methods that need to be implemented are annotated in the L</METHODS> section +below. + + ┌─────────────────┐ + │ SectionConfig │ + └────────┬────────┘ + │ + │ + │ + ┌────────▼────────┐ + │ BasePlugin │ + └────────┬────────┘ + │ + ┌─────────┴─────────┐ + │ │ + ┌────────▼────────┐ ┌────────▼────────┐ + │ConcretePluginFoo│ │ConcretePluginBar│ + └─────────────────┘ └─────────────────┘ + +=head2 REGISTERING PLUGINS + +In order to actually be able to use plugins, they must first be I<registered> +and then I<initialized> via the "base" plugin: + + use PVE::Example::BasePlugin; + use PVE::Example::PluginA; + use PVE::Example::PluginB; + + PVE::Example::PluginA->register(); + PVE::Example::PluginB->register(); + PVE::Example::BasePlugin->init(); + +=head2 MODES + +There are two modes for how I<properties> are exposed. + +=head3 unified mode (default) + +In this mode there is only a global list of I<properties> which the child +plugins can use. This has the consequence that it's not possible to define the +same property name more than once in different plugins. + +The reason behind this behaviour is to ensure that properties with the same +name don't behave in different ways, or in other words, to enforce the use of +identical properties for multiple plugins. + +=head3 isolated mode + +This mode can be used by calling C<init> with an additional parameter: + + PVE::Example::BasePlugin->init(property_isolation => 1); + +With this mode each I<child plugin> gets its own isolated list of I<properties>, +or in other words, a fully isolated schema namespace. Normally one wants to use +C<oneOf> schemas when enabling isolation. + +Note that in this mode it's only necessary to specify a I<property> in the +C<options> method when it's either C<fixed> or stems from the global list of +I<properties>. + +All locally defined I<properties> of a I<child plugin> are automatically added +to its schema. + +=head2 METHODS + +=cut my $defaultData = { options => {}, @@ -77,11 +114,85 @@ my $defaultData = { propertyList => {}, }; +=pod + +=head3 private + +B<REQUIRED:> Must be implemented in the I<base plugin>. + + $data = PVE::Example::Plugin->private() + $data = $class->private() + +Getter for C<SectionConfig>-related private data. + +Most commonly this is used to simply retrieve the default I<property> list of +one's plugin architecture, for example: + + use PVE::JSONSchema qw(get_standard_option); + + use base qw(PVE::SectionConfig); + + # [...] + + my $defaultData = { + propertyList => { + type => { + description => "Type of plugin." + }, + nodes => get_standard_option('pve-node-list', { + description => "List of nodes for which the plugin applies.", + optional => 1, + }), + disable => { + description => "Flag to disable the plugin.", + type => 'boolean', + optional => 1, + }, + 'max-foo-rate' => { + description => "Maximum 'foo' rate of the plugin. Use '-1' for unlimited.", + type => 'integer', + minimum => -1, + default => 42, + optional => 1, + }, + # [...] + }, + }; + + sub private { + return $defaultData; + } + +=cut + sub private { die "overwrite me"; return $defaultData; } +=pod + +=head3 register + + PVE::Example::Plugin->register() + +Used to register I<child plugins>. + +This method must be called on each child plugin before I<initializing> the base +plugin. + +For example: + + use PVE::Example::BasePlugin; + use PVE::Example::PluginA; + use PVE::Example::PluginB; + + PVE::Example::PluginA->register(); + PVE::Example::PluginB->register(); + PVE::Example::BasePlugin->init(); + +=cut + sub register { my ($class) = @_; @@ -96,22 +207,127 @@ sub register { $pdata->{plugins}->{$type} = $class; } +=pod + +=head3 type + +B<REQUIRED:> Must be implemented in I<child plugins>. + + $type = PVE::Example::Plugin->type() + $type = $class->type() + +Returns the I<type> of a I<child plugin>, which is a I<unique> string. This is +used to identify the I<child plugin>. + +Should be overridden on I<child plugins>: + + sub type { + return "foo"; + } + +=cut + sub type { die "overwrite me"; } +=pod + +=head3 properties + +B<REQUIRED:> Must be implemented in I<child plugins>. + + $props = PVE::Example::Plugin->properties() + $props = $class->properties() + +Returns the I<properties> specific to a I<child plugin> as a hash. + + sub properties() { + return { + path => { + description => "Path used to retrieve a 'foo'.", + type => 'string', + format => 'some-custom-format-handler-for-paths', + }, + is_bar = { + description => "Whether the 'foo' is 'bar' or not.", + type => 'boolean', + }, + bwlimit => get_standard_option('bwlimit'), + }; + } + +=cut + sub properties { return {}; } +=pod + +=head3 options + +B<REQUIRED:> Must be implemented in I<child plugins>. + + $opts = PVE::Example::Plugin->options() + $opts = $class->options() + +This method is used to specify which I<properties> are actually configured for +a given I<child plugin>. More precisely, only the I<properties> that are +contained in the hash this method returns can be used. + +Additionally, it also allows to declare whether a property is C<optional> or +C<fixed>. + + sub options { + return { + 'some-optional-property' => { optional => 1 }, + 'a-fixed-property' => { fixed => 1 }, + 'a-required-but-not-fixed-property' => {}, + }; + } + +C<optional> I<properties> are not required to be set. + +C<fixed> I<properties> may only be set on creation of the config entity. + +=cut + sub options { return {}; } +=pod + +=head3 plugindata + +B<OPTIONAL:> Can be implemented in I<child plugins>. + + $plugindata = PVE::Example::Plugin->plugindata() + $plugindata = $class->plugindata() + +This method is used by plugin authors to provide any kind of data specific to +their plugin implementation and is otherwise not touched by C<SectionConfig>. + +This mostly exists for convenience and doesn't need to be implemented. + +=cut + sub plugindata { return {}; } +=pod + +=head3 has_isolated_properties + + $is_isolated = PVE::Example::Plugin->has_isolated_properties() + $is_isolated = $class->has_isolated_properties() + +Checks whether the plugin has isolated I<properties> (runs in isolated mode). + +=cut + sub has_isolated_properties { my ($class) = @_; @@ -168,6 +384,34 @@ my sub add_property { } }; +=pod + +=head3 createSchema + + $schema = PVE::Example::Plugin->($skip_type, $base) + $schema = $class->($skip_type, $base) + +Returns the C<PVE::JSONSchema> used for I<creating> instances of a +I<child plugin>. + +This schema may then be used as desired, for example as the definition of +parameters of an API handler (C<POST>). + +=over + +=item C<$skip_type> (optional) + +Can be set to C<1> if there's a I<property> named "type" in the list of +default I<properties> that should be excluded from the generated schema. + +=item C<$base> (optional) + +The I<properties> to use per default. + +=back + +=cut + sub createSchema { my ($class, $skip_type, $base) = @_; @@ -242,6 +486,18 @@ sub createSchema { }; } +=pod + +=head3 updateSchema + +Returns the C<PVE::JSONSchema> used for I<updating> instances of a +I<child plugin>. + +This schema may then be used as desired, for example as the definition of +parameters of an API handler (C<PUT>). + +=cut + sub updateSchema { my ($class, $single_class, $base) = @_; @@ -326,12 +582,22 @@ sub updateSchema { }; } -# the %param hash controls some behavior of the section config, currently the following options are -# understood: -# -# - property_isolation: if set, each child-plugin has a fully isolated property (schema) namespace. -# By default this is off, meaning all child-plugins share the schema of properties with the same -# name. Normally one wants to use oneOf schema's when enabling isolation. +=pod + +=head3 init + + $base_plugin->init(); + $base_plugin->init(property_isolation => 1); + +This method is used to initialize all I<child plugins> that have been +I<registered> beforehand. + +Optionally, it is also possible to pass C<property_isolation> as parameter in +order to activate I<isolated mode>. See L</MODES> in the package-level +documentation for more information. + +=cut + sub init { my ($class, %param) = @_; @@ -392,6 +658,18 @@ sub init { $propertyList->{type}->{enum} = [sort keys %$plugins]; } +=pod + +=head3 lookup + + $plugin = PVE::Example::BasePlugin->lookup($type) + $plugin = $class->lookup($type) + +Returns the I<child plugin> corresponding to the given C<type> or dies if it +cannot be found. + +=cut + sub lookup { my ($class, $type) = @_; @@ -405,6 +683,17 @@ sub lookup { return $plugin; } +=pod + +=head3 lookup_types + + $types = PVE::Example::BasePlugin->lookup_types() + $types = $class->lookup_types() + +Returns a list of all I<child plugins'> C<type>s. + +=cut + sub lookup_types { my ($class) = @_; @@ -413,18 +702,66 @@ sub lookup_types { return [ sort keys %{$pdata->{plugins}} ]; } +=pod + +=head3 decode_value + +B<OPTIONAL:> Can be implemented in the I<base plugin>. + + $decoded_value = PVE::Example::BasePlugin->decode_value($type, $key, $value) + $decoded_value = $class->($type, $key, $value) + +Called during C<check_config> in order to convert values that have been read +from a C<SectionConfig> file which have been I<encoded> beforehand by +C<encode_value>. + +Does nothing to C<$value> by default, but can be overridden in the I<base plugin> +in order to implement custom conversion behavior. + +=cut + sub decode_value { my ($class, $type, $key, $value) = @_; return $value; } +=pod + +=head3 encode_value + +B<OPTIONAL:> Can be implemented in the I<base plugin>. + + $encoded_value = PVE::Example::BasePlugin->encode_value($type, $key, $value) + $encoded_value = $class->($type, $key, $value) + +Called during C<write_config> in order to convert values into a serializable +format. + +Does nothing to C<$value> by default, but can be overridden in the I<base plugin> +in order to implement custom conversion behavior. Usually one should also +override C<decode_value> in a matching manner. + +=cut + sub encode_value { my ($class, $type, $key, $value) = @_; return $value; } +=pod + +=head3 check_value + + $checked_value = PVE::Example::BasePlugin->check_value($type, $key, $value, $storeid, $skipSchemaCheck) + $checked_value = $class->check_value($type, $key, $value, $storeid, $skipSchemaCheck) + +Used internally to check if various invariants are upheld. It's best to not +override this. + +=cut + sub check_value { my ($class, $type, $key, $value, $storeid, $skipSchemaCheck) = @_; @@ -473,6 +810,46 @@ sub check_value { return $value; } +=pod + +=head3 parse_section_header + +B<OPTIONAL:> Can be I<extended> in the I<base plugin>. + + ($type, $sectionId, $errmsg, $config) = PVE::Example::BasePlugin->parse_section_header($line) + ($type, $sectionId, $errmsg, $config) = $class->parse_section_header($line) + +Parses the header of a section and returns an array containing the section's +C<type>, ID and optionally an error message as well as additional config +attributes. + +Can be overriden on the I<base plugin> in order to provide custom logic for +handling the header, e.g. if the section IDs need to be parsed or validated in +a certain way. + +Note that the section B<MUST> initially be parsed with the regex used by the +original method when overriding in order to guarantee compatibility. +For example: + + sub parse_section_header { + my ($class, $line) = @_; + + if ($line =~ m/^(\S):\s*(\S+)\s*$/) { + my ($type, $sectionId) = ($1, $2); + + my $errmsg = undef; + eval { check_section_id_is_valid($sectionId); }; + $errmsg = $@ if $@; + + my $config = parse_extra_stuff_from_section_id($sectionId); + + return ($type, $sectionId, $errmsg, $config); + } + return undef; + } + +=cut + sub parse_section_header { my ($class, $line) = @_; @@ -485,12 +862,40 @@ sub parse_section_header { return undef; } +=pod + +=head3 format_section_header + +B<OPTIONAL:> Can be overridden in the I<base plugin>. + + $header = PVE::Example::BasePlugin->format_section_header($type, $sectionId, $scfg, $done_hash) + $header = $class->format_section_header($type, $sectionId, $scfg, $done_hash) + +Formats the header of a section. Simply C<"$type: $sectionId\n"> by default. + +Note that when overriding this, the header B<MUST> end with a newline (C<\n>). +One also might want to add a matching override for C<parse_section_header>. + +=cut + sub format_section_header { my ($class, $type, $sectionId, $scfg, $done_hash) = @_; return "$type: $sectionId\n"; } +=pod + +=head3 get_property_schema + + $schema = PVE::Example::BasePlugin->get_property_schema($type, $key) + $schema = $class->get_property_schema($type, $key) + +Returns the schema of a I<property> of a I<child plugin> that is denoted via +its C<$type>. + +=cut + sub get_property_schema { my ($class, $type, $key) = @_; @@ -506,6 +911,106 @@ sub get_property_schema { return $schema; } +=pod + +=head3 parse_config + + $config = PVE::Example::BasePlugin->parse_config($filename, $raw, $allow_unknown) + $config = $class->parse_config($filename, $raw, $allow_unknown) + +Parses the contents of a C<SectionConfig> file and returns a complex nested +hash which not only contains the parsed data, but additional information that +one may or may not find useful. More below. + +=over + +=item C<$filename> + +The name of the file whose content is stored in C<$raw>. + +=item C<$raw> + +The raw content of C<$filename>. + +=item C<$allow_unknown> + +Whether to allow parsing unknown I<types>. + +=back + +The returned hash is structured as follows: + + { + ids => { + foo => { + key => value, + ... + }, + bar => { + key => value, + ... + }, + }, + order => { + foo => 1, + bar => 2, + }, + digest => "5f5513f8822fdbe5145af33b64d8d970dcf95c6e", + errors => ( + { + context => ..., + section => "section ID", + key => "some_key", + err => "error message", + }, + ... + ), + } + +=over + +=item C<ids> + +Each section's parsed configuration values, or more precisely, the I<section +identifiers> and their associated configuration options as returned by +C<check_config>. + +=item C<order> + +The order in which the sections in C<ids> were parsed. + +=item C<digest> + +A SHA1 hex digest of the contents in C<$raw>. + +=item C<errors> (optional) + +An optional list of error hashes, where each hash contains the following keys: + +=over 2 + +=item C<context> + +In which file and in which line the error was encountered. + +=item C<section> + +In which section the error was encountered. + +=item C<key> + +Which I<property> the error corresponds to. + +=item C<err> + +The error. + +=back + +=back + +=cut + sub parse_config { my ($class, $filename, $raw, $allow_unknown) = @_; @@ -642,6 +1147,23 @@ sub parse_config { return $cfg; } +=pod + +=head3 check_config + + $settings = PVE::Example::BasePlugin->check_config($sectionId, $config, $create, $skipSchemaCheck) + $settings = $class->check_config($sectionId, $config, $create, $skipSchemaCheck) + +Does not just check whether a section's configuration is valid, despite its +name, but also calls C<decode_value> (among other things) internally. + +Returns a hash which contains all I<properties> for the given C<$sectionId>. +In other words, all configured key-value pairs for the provided section. + +It's best to not override this. + +=cut + sub check_config { my ($class, $sectionId, $config, $create, $skipSchemaCheck) = @_; @@ -700,6 +1222,52 @@ my $format_config_line = sub { } }; +=pod + +=head3 write_config + + $output = PVE::Example::BasePlugin->write_config($filename, $cfg, $allow_unknown) + $output = $class->write_config($filename, $cfg, $allow_unknown) + +Generates the output that should be written to the C<SectionConfig> file. + +=over + +=item C<$filename> (unused) + +The name of the file to which the generated output will be written to. +This parameter is currently unused and has no effect. + +=item C<$cfg> + +The hash that represents the entire configuration that should be written. +This hash is expected to have the following format: + + { + ids => { + foo => { + key => value, + ... + }, + bar => { + key => value, + ... + }, + }, + order => { + foo => 1, + bar => 2, + }, + } + +=item C<$allow_unknown> + +Whether to allow writing sections with an unknown C<type>. + +=back + +=cut + sub write_config { my ($class, $filename, $cfg, $allow_unknown) = @_; @@ -798,6 +1366,45 @@ sub assert_if_modified { PVE::Tools::assert_if_modified($cfg->{digest}, $digest); } +=pod + +=head3 delete_from_config + + $config = PVE::Example::BasePlugin->delete_from_config($config, $option_schema, $new_options, $to_delete) + $config = $class->delete_from_config($config, $option_schema, $new_options, $to_delete) + +Convenience method to delete key from a hash of configured I<properties> which +performs necessary checks beforehand. + +Note: The passed C<$config> is modified in place and also returned. + +=over + +=item C<$config> + +The section's configuration that the given I<properties> in C<$to_delete> should +be deleted from. + +=item C<$option_schema> + +The schema of the I<properties> associated with C<$config>. See the C<options> +method. + +=item C<$new_options> + +The I<properties> which are to be added to C<$config>. Note that this method +doesn't add any I<properties> itself; this is to prohibit simultaneously +setting and deleting the same I<property>. + +=item C<$to_delete> + +A reference to an array containing the names of the I<properties> to delete +from C<$config>. + +=back + +=cut + sub delete_from_config { my ($config, $option_schema, $new_options, $to_delete) = @_; -- 2.39.2 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD Max Carrara @ 2024-06-11 10:46 ` Fabian Grünbichler 2024-06-13 9:14 ` Max Carrara 0 siblings, 1 reply; 10+ messages in thread From: Fabian Grünbichler @ 2024-06-11 10:46 UTC (permalink / raw) To: Proxmox VE development discussion On June 4, 2024 11:28 am, Max Carrara wrote: > Apart from the obvious benefits that documentation has, this also > allows LSPs to provide docstrings e.g. via 'textDocument/hover' [0]. > > Tested with Perl Navigator [1]. > > [0]: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_hover > [1]: https://github.com/bscan/PerlNavigator > > Signed-off-by: Max Carrara <m.carrara@proxmox.com> > --- > src/PVE/SectionConfig.pm | 737 +++++++++++++++++++++++++++++++++++---- > 1 file changed, 672 insertions(+), 65 deletions(-) > > diff --git a/src/PVE/SectionConfig.pm b/src/PVE/SectionConfig.pm > index a18e9d8..99ee348 100644 > --- a/src/PVE/SectionConfig.pm > +++ b/src/PVE/SectionConfig.pm > @@ -10,65 +10,102 @@ use PVE::Exception qw(raise_param_exc); > use PVE::JSONSchema qw(get_standard_option); > use PVE::Tools; > > -# This package provides a way to have multiple (often similar) types of entries > -# in the same config file, each in its own section, thus "Section Config". > -# > -# The intended structure is to have a single 'base' plugin that inherits from > -# this class and provides meaningful defaults in its '$defaultData', e.g. a > -# default list of the core properties in its propertyList (most often only 'id' > -# and 'type') > -# > -# Each 'real' plugin then has it's own package that should inherit from the > -# 'base' plugin and returns it's specific properties in the 'properties' method, > -# its type in the 'type' method and all the known options, from both parent and > -# itself, in the 'options' method. > -# The options method can also be used to define if a property is 'optional' or > -# 'fixed' (only settable on config entity-creation), for example: > -# > -# ```` > -# sub options { > -# return { > -# 'some-optional-property' => { optional => 1 }, > -# 'a-fixed-property' => { fixed => 1 }, > -# 'a-required-but-not-fixed-property' => {}, > -# }; > -# } > -# ``` > -# > -# 'fixed' options can be set on create, but not changed afterwards. > -# > -# To actually use it, you have to first register all the plugins and then init > -# the 'base' plugin, like so: > -# > -# ``` > -# use PVE::Dummy::Plugin1; > -# use PVE::Dummy::Plugin2; > -# use PVE::Dummy::BasePlugin; > -# > -# PVE::Dummy::Plugin1->register(); > -# PVE::Dummy::Plugin2->register(); > -# PVE::Dummy::BasePlugin->init(); > -# ``` > -# > -# There are two modes for how properties are exposed, the default 'unified' > -# mode and the 'isolated' mode. > -# In the default unified mode, there is only a global list of properties > -# which the plugins can use, so you cannot define the same property name twice > -# in different plugins. The reason for this is to force the use of identical > -# properties for multiple plugins. > -# > -# The second way is to use the 'isolated' mode, which can be achieved by > -# calling init with `1` as its parameter like this: > -# > -# ``` > -# PVE::Dummy::BasePlugin->init(property_isolation => 1); > -# ``` > -# > -# With this, each plugin get's their own isolated list of properties which it > -# can use. Note that in this mode, you only have to specify the property in the > -# options method when it is either 'fixed' or comes from the global list of > -# properties. All locally defined ones get automatically added to the schema > -# for that plugin. > +=pod > + > +=head1 NAME > + > +SectionConfig > + > +=head1 DESCRIPTION > + > +This package provides a way to have multiple (often similar) types of entries > +in the same config file, each in its own section, thus I<Section Config>. > + > +Under the hood, this package automatically creates and manages a matching > +I<JSONSchema> for one's plugin architecture that is used to represent data > +that is read from and written to the config file. this sentence is too long and hard to parse. For each SectionConfig-based config file, a I<JSONSchema> is derived automatically. This schema can be used to implement CRUD operations for the config data. or something like that? > + > +Where this config file is located, as well as its permissions and other related > +things, is up to the plugin author and is not handled by C<PVE::SectionConfig> > +at all. it's not really up to the plugin author? it's up to the author of the code using SectionConfig, which might be someone else entirely. the plugin author might be some third party.. > + > +=head1 USAGE > + > +The intended structure is to have a single I<base plugin> that inherits from > +this class and provides meaningful defaults in its C<$defaultData>, such as a s/inherits from this class/uses the SectionConfig module as base module in Perl, a class is a perl structure that has been blessed. while the code here uses '$class', it's not really one. > +default list of core C<PVE::JSONSchema> I<properties>. The I<base plugin> is > +thus very similar to an I<abstract class>. > + > +Each I<child plugin> is then defined in its own package that should inherit > +from the I<base plugin> and defines which I<properties> it itself provides and > +uses, as well as which I<properties> it uses from the I<base plugin>. > + > +The methods that need to be implemented are annotated in the L</METHODS> section > +below. > + > + ┌─────────────────┐ > + │ SectionConfig │ > + └────────┬────────┘ > + │ > + │ > + │ > + ┌────────▼────────┐ > + │ BasePlugin │ > + └────────┬────────┘ > + │ > + ┌─────────┴─────────┐ > + │ │ > + ┌────────▼────────┐ ┌────────▼────────┐ > + │ConcretePluginFoo│ │ConcretePluginBar│ > + └─────────────────┘ └─────────────────┘ lots of trailing whitespace there.. /-> ConcretePluginFoo SectionConfig -> BasePlugin -X \-> ConcretePluginBar would show the same info IMHO, but I don't care much either way :-P > + > +=head2 REGISTERING PLUGINS > + > +In order to actually be able to use plugins, they must first be I<registered> > +and then I<initialized> via the "base" plugin: > + > + use PVE::Example::BasePlugin; > + use PVE::Example::PluginA; > + use PVE::Example::PluginB; > + > + PVE::Example::PluginA->register(); > + PVE::Example::PluginB->register(); > + PVE::Example::BasePlugin->init(); > + > +=head2 MODES > + > +There are two modes for how I<properties> are exposed. > + > +=head3 unified mode (default) > + > +In this mode there is only a global list of I<properties> which the child > +plugins can use. This has the consequence that it's not possible to define the > +same property name more than once in different plugins. > + > +The reason behind this behaviour is to ensure that properties with the same > +name don't behave in different ways, or in other words, to enforce the use of > +identical properties for multiple plugins. > + > +=head3 isolated mode > + > +This mode can be used by calling C<init> with an additional parameter: > + > + PVE::Example::BasePlugin->init(property_isolation => 1); > + > +With this mode each I<child plugin> gets its own isolated list of I<properties>, > +or in other words, a fully isolated schema namespace. Normally one wants to use > +C<oneOf> schemas when enabling isolation. > + > +Note that in this mode it's only necessary to specify a I<property> in the > +C<options> method when it's either C<fixed> or stems from the global list of in the *return value of the* > +I<properties>. > + > +All locally defined I<properties> of a I<child plugin> are automatically added > +to its schema. > + > +=head2 METHODS > + > +=cut > > my $defaultData = { > options => {}, > @@ -77,11 +114,85 @@ my $defaultData = { > propertyList => {}, > }; > > +=pod > + > +=head3 private > + > +B<REQUIRED:> Must be implemented in the I<base plugin>. > + > + $data = PVE::Example::Plugin->private() > + $data = $class->private() > + > +Getter for C<SectionConfig>-related private data. > + > +Most commonly this is used to simply retrieve the default I<property> list of > +one's plugin architecture, for example: > + > + use PVE::JSONSchema qw(get_standard_option); > + > + use base qw(PVE::SectionConfig); > + > + # [...] > + > + my $defaultData = { > + propertyList => { > + type => { > + description => "Type of plugin." > + }, > + nodes => get_standard_option('pve-node-list', { > + description => "List of nodes for which the plugin applies.", > + optional => 1, > + }), > + disable => { > + description => "Flag to disable the plugin.", > + type => 'boolean', > + optional => 1, > + }, > + 'max-foo-rate' => { > + description => "Maximum 'foo' rate of the plugin. Use '-1' for unlimited.", > + type => 'integer', > + minimum => -1, > + default => 42, > + optional => 1, > + }, > + # [...] > + }, > + }; > + > + sub private { > + return $defaultData; > + } > + > +=cut > + this is not really explaining what this sub does.. while yes, it's implemented in the base plugin and returns the default data there, this is actually the getter for the internal state of the whole SectionConfig.. > sub private { > die "overwrite me"; > return $defaultData; > } > > +=pod > + > +=head3 register > + > + PVE::Example::Plugin->register() > + > +Used to register I<child plugins>. > + > +This method must be called on each child plugin before I<initializing> the base > +plugin. > + and what does it do? :) > +For example: > + > + use PVE::Example::BasePlugin; > + use PVE::Example::PluginA; > + use PVE::Example::PluginB; > + > + PVE::Example::PluginA->register(); > + PVE::Example::PluginB->register(); > + PVE::Example::BasePlugin->init(); > + > +=cut > + > sub register { > my ($class) = @_; > > @@ -96,22 +207,127 @@ sub register { > $pdata->{plugins}->{$type} = $class; > } > > +=pod > + > +=head3 type > + > +B<REQUIRED:> Must be implemented in I<child plugins>. on fact, this must be implemented in *each* child plugin (a difference that matters ;)) > + > + $type = PVE::Example::Plugin->type() > + $type = $class->type() > + > +Returns the I<type> of a I<child plugin>, which is a I<unique> string. This is > +used to identify the I<child plugin>. > + > +Should be overridden on I<child plugins>: no, it must ;) > + > + sub type { > + return "foo"; > + } > + > +=cut > + > sub type { > die "overwrite me"; > } > > +=pod > + > +=head3 properties > + > +B<REQUIRED:> Must be implemented in I<child plugins>. not technically true (or rather, always true)? it is implemented in all plugins since it is implemented below.. and it's fine to not override it in a specific plugin if that is not necessary.. > + > + $props = PVE::Example::Plugin->properties() > + $props = $class->properties() > + > +Returns the I<properties> specific to a I<child plugin> as a hash. this also doesn't really explain what this is used for IMHO.. this is used to *register* properties for use in this or other plugin's `options()` return value. depending on the isolation mode, of course. > + > + sub properties() { > + return { > + path => { > + description => "Path used to retrieve a 'foo'.", > + type => 'string', > + format => 'some-custom-format-handler-for-paths', > + }, > + is_bar = { > + description => "Whether the 'foo' is 'bar' or not.", > + type => 'boolean', > + }, > + bwlimit => get_standard_option('bwlimit'), > + }; > + } > + > +=cut > + > sub properties { > return {}; > } > > +=pod > + > +=head3 options > + > +B<REQUIRED:> Must be implemented in I<child plugins>. again, this is not really true.. especially in the case of property isolation, it's fine to leave this blank, since the properties are used to initialize the options.. > + > + $opts = PVE::Example::Plugin->options() > + $opts = $class->options() > + > +This method is used to specify which I<properties> are actually configured for configured? allowed/used fits better IMHO > +a given I<child plugin>. More precisely, only the I<properties> that are > +contained in the hash this method returns can be used. wrong, see above.. > + > +Additionally, it also allows to declare whether a property is C<optional> or > +C<fixed>. optional can also be set via the property itself, in case of isolated properties. > + > + sub options { > + return { > + 'some-optional-property' => { optional => 1 }, > + 'a-fixed-property' => { fixed => 1 }, > + 'a-required-but-not-fixed-property' => {}, > + }; > + } > + > +C<optional> I<properties> are not required to be set. > + > +C<fixed> I<properties> may only be set on creation of the config entity. > + > +=cut > + > sub options { > return {}; > } > > +=pod > + > +=head3 plugindata > + > +B<OPTIONAL:> Can be implemented in I<child plugins>. > + > + $plugindata = PVE::Example::Plugin->plugindata() > + $plugindata = $class->plugindata() > + > +This method is used by plugin authors to provide any kind of data specific to > +their plugin implementation and is otherwise not touched by C<SectionConfig>. > + > +This mostly exists for convenience and doesn't need to be implemented. > + > +=cut > + > sub plugindata { > return {}; > } > > +=pod > + > +=head3 has_isolated_properties > + > + $is_isolated = PVE::Example::Plugin->has_isolated_properties() > + $is_isolated = $class->has_isolated_properties() > + > +Checks whether the plugin has isolated I<properties> (runs in isolated mode). > + > +=cut > + > sub has_isolated_properties { > my ($class) = @_; > > @@ -168,6 +384,34 @@ my sub add_property { > } > }; > > +=pod > + > +=head3 createSchema > + > + $schema = PVE::Example::Plugin->($skip_type, $base) > + $schema = $class->($skip_type, $base) > + > +Returns the C<PVE::JSONSchema> used for I<creating> instances of a > +I<child plugin>. "instances of a child plugin" sounds confusing. config entries defined by a child plugin? > + > +This schema may then be used as desired, for example as the definition of > +parameters of an API handler (C<POST>). > + > +=over > + > +=item C<$skip_type> (optional) > + > +Can be set to C<1> if there's a I<property> named "type" in the list of > +default I<properties> that should be excluded from the generated schema. can be described in much simpler terms: Set to '1' to not add 'type' property to schema. > + > +=item C<$base> (optional) > + > +The I<properties> to use per default. no, this defines the schema of additional properties not derived from the plugin definition. > + > +=back > + > +=cut > + > sub createSchema { > my ($class, $skip_type, $base) = @_; > > @@ -242,6 +486,18 @@ sub createSchema { > }; > } > > +=pod > + > +=head3 updateSchema > + > +Returns the C<PVE::JSONSchema> used for I<updating> instances of a > +I<child plugin>. same as above.. > + > +This schema may then be used as desired, for example as the definition of > +parameters of an API handler (C<PUT>). > + > +=cut what about the parameters here? ;) > + > sub updateSchema { > my ($class, $single_class, $base) = @_; > > @@ -326,12 +582,22 @@ sub updateSchema { > }; > } > > -# the %param hash controls some behavior of the section config, currently the following options are > -# understood: > -# > -# - property_isolation: if set, each child-plugin has a fully isolated property (schema) namespace. > -# By default this is off, meaning all child-plugins share the schema of properties with the same > -# name. Normally one wants to use oneOf schema's when enabling isolation. > +=pod > + > +=head3 init > + > + $base_plugin->init(); > + $base_plugin->init(property_isolation => 1); > + > +This method is used to initialize all I<child plugins> that have been > +I<registered> beforehand. not really.. it is used to initialize the SectionConfig itself using the registered plugins.. > + > +Optionally, it is also possible to pass C<property_isolation> as parameter in > +order to activate I<isolated mode>. See L</MODES> in the package-level > +documentation for more information. this actually is worse then the old variant since the information *how to set* it is lost here.. > + > +=cut > + > sub init { > my ($class, %param) = @_; > > @@ -392,6 +658,18 @@ sub init { > $propertyList->{type}->{enum} = [sort keys %$plugins]; > } > > +=pod > + > +=head3 lookup > + > + $plugin = PVE::Example::BasePlugin->lookup($type) > + $plugin = $class->lookup($type) > + > +Returns the I<child plugin> corresponding to the given C<type> or dies if it > +cannot be found. > + > +=cut > + > sub lookup { > my ($class, $type) = @_; > > @@ -405,6 +683,17 @@ sub lookup { > return $plugin; > } > > +=pod > + > +=head3 lookup_types > + > + $types = PVE::Example::BasePlugin->lookup_types() > + $types = $class->lookup_types() > + > +Returns a list of all I<child plugins'> C<type>s. I<child plugin> C<type>s ? > + > +=cut > + > sub lookup_types { > my ($class) = @_; > > @@ -413,18 +702,66 @@ sub lookup_types { > return [ sort keys %{$pdata->{plugins}} ]; > } > > +=pod > + > +=head3 decode_value > + > +B<OPTIONAL:> Can be implemented in the I<base plugin>. > + > + $decoded_value = PVE::Example::BasePlugin->decode_value($type, $key, $value) > + $decoded_value = $class->($type, $key, $value) > + > +Called during C<check_config> in order to convert values that have been read > +from a C<SectionConfig> file which have been I<encoded> beforehand by > +C<encode_value>. > + > +Does nothing to C<$value> by default, but can be overridden in the I<base plugin> > +in order to implement custom conversion behavior. > + > +=cut description what type/key/value are would be nice? also, some example? > + > sub decode_value { > my ($class, $type, $key, $value) = @_; > > return $value; > } > > +=pod > + > +=head3 encode_value > + > +B<OPTIONAL:> Can be implemented in the I<base plugin>. > + > + $encoded_value = PVE::Example::BasePlugin->encode_value($type, $key, $value) > + $encoded_value = $class->($type, $key, $value) > + > +Called during C<write_config> in order to convert values into a serializable > +format. > + > +Does nothing to C<$value> by default, but can be overridden in the I<base plugin> > +in order to implement custom conversion behavior. Usually one should also > +override C<decode_value> in a matching manner. > + > +=cut same here > + > sub encode_value { > my ($class, $type, $key, $value) = @_; > > return $value; > } > > +=pod > + > +=head3 check_value > + > + $checked_value = PVE::Example::BasePlugin->check_value($type, $key, $value, $storeid, $skipSchemaCheck) > + $checked_value = $class->check_value($type, $key, $value, $storeid, $skipSchemaCheck) > + > +Used internally to check if various invariants are upheld. It's best to not > +override this. should we make it internal then? > + > +=cut > + > sub check_value { > my ($class, $type, $key, $value, $storeid, $skipSchemaCheck) = @_; > > @@ -473,6 +810,46 @@ sub check_value { > return $value; > } > > +=pod > + > +=head3 parse_section_header > + > +B<OPTIONAL:> Can be I<extended> in the I<base plugin>. > + > + ($type, $sectionId, $errmsg, $config) = PVE::Example::BasePlugin->parse_section_header($line) > + ($type, $sectionId, $errmsg, $config) = $class->parse_section_header($line) > + > +Parses the header of a section and returns an array containing the section's > +C<type>, ID and optionally an error message as well as additional config > +attributes. > + > +Can be overriden on the I<base plugin> in order to provide custom logic for > +handling the header, e.g. if the section IDs need to be parsed or validated in > +a certain way. > + > +Note that the section B<MUST> initially be parsed with the regex used by the > +original method when overriding in order to guarantee compatibility. why? that's not true at all, and also not true for our code using this (e.g., see PVE::Mapping::USB, where the type is encoded in the file name, and the section header just consists of the id followed by a newline). > +For example: > + > + sub parse_section_header { > + my ($class, $line) = @_; > + > + if ($line =~ m/^(\S):\s*(\S+)\s*$/) { > + my ($type, $sectionId) = ($1, $2); > + > + my $errmsg = undef; > + eval { check_section_id_is_valid($sectionId); }; > + $errmsg = $@ if $@; > + > + my $config = parse_extra_stuff_from_section_id($sectionId); > + > + return ($type, $sectionId, $errmsg, $config); > + } > + return undef; > + } > + > +=cut > + > sub parse_section_header { > my ($class, $line) = @_; > > @@ -485,12 +862,40 @@ sub parse_section_header { > return undef; > } > > +=pod > + > +=head3 format_section_header > + > +B<OPTIONAL:> Can be overridden in the I<base plugin>. > + > + $header = PVE::Example::BasePlugin->format_section_header($type, $sectionId, $scfg, $done_hash) > + $header = $class->format_section_header($type, $sectionId, $scfg, $done_hash) > + > +Formats the header of a section. Simply C<"$type: $sectionId\n"> by default. > + > +Note that when overriding this, the header B<MUST> end with a newline (C<\n>). > +One also might want to add a matching override for C<parse_section_header>. > + > +=cut > + > sub format_section_header { > my ($class, $type, $sectionId, $scfg, $done_hash) = @_; > > return "$type: $sectionId\n"; > } > > +=pod > + > +=head3 get_property_schema > + > + $schema = PVE::Example::BasePlugin->get_property_schema($type, $key) > + $schema = $class->get_property_schema($type, $key) > + > +Returns the schema of a I<property> of a I<child plugin> that is denoted via > +its C<$type>. Returns the schema of the property '$key' of the plugin for '$type'. > + > +=cut > + > sub get_property_schema { > my ($class, $type, $key) = @_; > > @@ -506,6 +911,106 @@ sub get_property_schema { > return $schema; > } > > +=pod > + > +=head3 parse_config > + > + $config = PVE::Example::BasePlugin->parse_config($filename, $raw, $allow_unknown) > + $config = $class->parse_config($filename, $raw, $allow_unknown) > + > +Parses the contents of a C<SectionConfig> file and returns a complex nested > +hash which not only contains the parsed data, but additional information that > +one may or may not find useful. More below. that comment about usefulness serves no purpose. Parses the contents of a file as SectionConfig, returning the parsed data annotated with additional information (see below). > + > +=over > + > +=item C<$filename> > + > +The name of the file whose content is stored in C<$raw>. this is just used for error messages/warnings, so it can also be something else ;) > + > +=item C<$raw> > + > +The raw content of C<$filename>. > + > +=item C<$allow_unknown> > + > +Whether to allow parsing unknown I<types>. > + > +=back > + > +The returned hash is structured as follows: > + > + { > + ids => { > + foo => { > + key => value, > + ... > + }, > + bar => { > + key => value, > + ... > + }, > + }, > + order => { > + foo => 1, > + bar => 2, > + }, > + digest => "5f5513f8822fdbe5145af33b64d8d970dcf95c6e", > + errors => ( > + { > + context => ..., > + section => "section ID", > + key => "some_key", > + err => "error message", > + }, > + ... > + ), > + } > + > +=over > + > +=item C<ids> > + > +Each section's parsed configuration values, or more precisely, the I<section > +identifiers> and their associated configuration options as returned by > +C<check_config>. Each section's parsed data (via check_config), indexed by the section ID. > + > +=item C<order> > + > +The order in which the sections in C<ids> were parsed. not only parsed, but found in the config file. > + > +=item C<digest> > + > +A SHA1 hex digest of the contents in C<$raw>. the purpose would be good to add here ;) > + > +=item C<errors> (optional) > + > +An optional list of error hashes, where each hash contains the following keys: > + > +=over 2 > + > +=item C<context> > + > +In which file and in which line the error was encountered. > + > +=item C<section> > + > +In which section the error was encountered. > + > +=item C<key> > + > +Which I<property> the error corresponds to. > + > +=item C<err> > + > +The error. > + > +=back > + > +=back > + > +=cut > + > sub parse_config { > my ($class, $filename, $raw, $allow_unknown) = @_; > > @@ -642,6 +1147,23 @@ sub parse_config { > return $cfg; > } > > +=pod > + > +=head3 check_config > + > + $settings = PVE::Example::BasePlugin->check_config($sectionId, $config, $create, $skipSchemaCheck) > + $settings = $class->check_config($sectionId, $config, $create, $skipSchemaCheck) > + > +Does not just check whether a section's configuration is valid, despite its > +name, but also calls C<decode_value> (among other things) internally. > + > +Returns a hash which contains all I<properties> for the given C<$sectionId>. > +In other words, all configured key-value pairs for the provided section. > + > +It's best to not override this. that's not true, this is actually okay to override if you need additional checks that can't be expressed in the schema. you do have to be aware of the decode_value part.. some of that can also be expressed via hooks though. > + > +=cut > + > sub check_config { > my ($class, $sectionId, $config, $create, $skipSchemaCheck) = @_; > > @@ -700,6 +1222,52 @@ my $format_config_line = sub { > } > }; > > +=pod > + > +=head3 write_config > + > + $output = PVE::Example::BasePlugin->write_config($filename, $cfg, $allow_unknown) > + $output = $class->write_config($filename, $cfg, $allow_unknown) > + > +Generates the output that should be written to the C<SectionConfig> file. > + > +=over > + > +=item C<$filename> (unused) > + > +The name of the file to which the generated output will be written to. > +This parameter is currently unused and has no effect. > + > +=item C<$cfg> > + > +The hash that represents the entire configuration that should be written. > +This hash is expected to have the following format: > + > + { > + ids => { > + foo => { > + key => value, > + ... > + }, > + bar => { > + key => value, > + ... > + }, > + }, > + order => { > + foo => 1, > + bar => 2, > + }, > + } any other top-level keys will be ignored (it's okay to pass in `digest` as well, for example). > + > +=item C<$allow_unknown> > + > +Whether to allow writing sections with an unknown C<type>. > + > +=back > + > +=cut > + > sub write_config { > my ($class, $filename, $cfg, $allow_unknown) = @_; > > @@ -798,6 +1366,45 @@ sub assert_if_modified { > PVE::Tools::assert_if_modified($cfg->{digest}, $digest); > } > > +=pod > + > +=head3 delete_from_config > + > + $config = PVE::Example::BasePlugin->delete_from_config($config, $option_schema, $new_options, $to_delete) > + $config = $class->delete_from_config($config, $option_schema, $new_options, $to_delete) > + > +Convenience method to delete key from a hash of configured I<properties> which > +performs necessary checks beforehand. this whole part here is very confusing, and also, this is not even part of the plugin interface at all, it's just a convenience helper operating on a single section's config data.. what it does is delete from $config if allowed (not required or fixed or set it in the same go). > + > +Note: The passed C<$config> is modified in place and also returned. > + > +=over > + > +=item C<$config> > + > +The section's configuration that the given I<properties> in C<$to_delete> should > +be deleted from. > + > +=item C<$option_schema> > + > +The schema of the I<properties> associated with C<$config>. See the C<options> > +method. > + > +=item C<$new_options> > + > +The I<properties> which are to be added to C<$config>. Note that this method > +doesn't add any I<properties> itself; this is to prohibit simultaneously > +setting and deleting the same I<property>. > + > +=item C<$to_delete> > + > +A reference to an array containing the names of the I<properties> to delete > +from C<$config>. > + > +=back > + > +=cut > + > sub delete_from_config { > my ($config, $option_schema, $new_options, $to_delete) = @_; > > -- > 2.39.2 > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD 2024-06-11 10:46 ` Fabian Grünbichler @ 2024-06-13 9:14 ` Max Carrara 0 siblings, 0 replies; 10+ messages in thread From: Max Carrara @ 2024-06-13 9:14 UTC (permalink / raw) To: Proxmox VE development discussion On Tue Jun 11, 2024 at 12:46 PM CEST, Fabian Grünbichler wrote: > On June 4, 2024 11:28 am, Max Carrara wrote: > > Apart from the obvious benefits that documentation has, this also > > allows LSPs to provide docstrings e.g. via 'textDocument/hover' [0]. > > > > Tested with Perl Navigator [1]. > > > > [0]: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_hover > > [1]: https://github.com/bscan/PerlNavigator > > > > Signed-off-by: Max Carrara <m.carrara@proxmox.com> > > --- Making a cut here because I agree with pretty much everything you said; will incorporate all of your comments into v2 (unless some questions arise from my side). Thanks a lot for your thorough review, it's really appreciated! :) ---- snip 8<------ _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [pve-devel] [PATCH v1 pve-common 2/3] section config: update code style 2024-06-04 9:28 [pve-devel] [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD Max Carrara @ 2024-06-04 9:28 ` Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 3/3] section config: clean up parser logic Max Carrara 2024-07-24 11:34 ` [pve-devel] applied: [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Fiona Ebner 3 siblings, 0 replies; 10+ messages in thread From: Max Carrara @ 2024-06-04 9:28 UTC (permalink / raw) To: pve-devel 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> --- src/PVE/SectionConfig.pm | 62 ++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/src/PVE/SectionConfig.pm b/src/PVE/SectionConfig.pm index 99ee348..a6b0183 100644 --- a/src/PVE/SectionConfig.pm +++ b/src/PVE/SectionConfig.pm @@ -422,7 +422,7 @@ sub createSchema { my $props = $base || {}; if (!$class->has_isolated_properties()) { - foreach my $p (keys %$propertyList) { + for my $p (keys $propertyList->%*) { next if $skip_type && $p eq 'type'; if (!$propertyList->{$p}->{optional}) { @@ -435,7 +435,7 @@ sub createSchema { my $copts = $class->options(); $required = 0 if defined($copts->{$p}) && $copts->{$p}->{optional}; - foreach my $t (keys %$plugins) { + for my $t (keys $plugins->%*) { my $opts = $pdata->{options}->{$t} || {}; $required = 0 if !defined($opts->{$p}) || $opts->{$p}->{optional}; } @@ -450,7 +450,7 @@ sub createSchema { } } } else { - for my $type (sort keys %$plugins) { + for my $type (sort keys $plugins->%*) { my $opts = $pdata->{options}->{$type} || {}; for my $key (sort keys $opts->%*) { my $schema = $class->get_property_schema($type, $key); @@ -510,7 +510,7 @@ sub updateSchema { my $filter_type = $single_class ? $class->type() : undef; if (!$class->has_isolated_properties()) { - foreach my $p (keys %$propertyList) { + for my $p (keys $propertyList->%*) { next if $p eq 'type'; my $copts = $class->options(); @@ -526,7 +526,7 @@ sub updateSchema { $modifyable = 1 if defined($copts->{$p}) && !$copts->{$p}->{fixed}; - foreach my $t (keys %$plugins) { + for my $t (keys $plugins->%*) { my $opts = $pdata->{options}->{$t} || {}; next if !defined($opts->{$p}); $modifyable = 1 if !$opts->{$p}->{fixed}; @@ -536,7 +536,7 @@ sub updateSchema { $props->{$p} = $propertyList->{$p}; } } else { - for my $type (sort keys %$plugins) { + for my $type (sort keys $plugins->%*) { my $opts = $pdata->{options}->{$type} || {}; for my $key (sort keys $opts->%*) { next if $opts->{$key}->{fixed}; @@ -605,7 +605,7 @@ sub init { my $pdata = $class->private(); - foreach my $k (qw(options plugins plugindata propertyList isolatedPropertyList)) { + for my $k (qw(options plugins plugindata propertyList isolatedPropertyList)) { $pdata->{$k} = {} if !$pdata->{$k}; } @@ -613,9 +613,9 @@ sub init { my $propertyList = $pdata->{propertyList}; my $isolatedPropertyList = $pdata->{isolatedPropertyList}; - foreach my $type (keys %$plugins) { + for my $type (keys $plugins->%*) { my $props = $plugins->{$type}->properties(); - foreach my $p (keys %$props) { + for my $p (keys $props->%*) { my $res; if ($property_isolation) { $res = $isolatedPropertyList->{$type}->{$p} = {}; @@ -624,16 +624,16 @@ sub init { $res = $propertyList->{$p} = {}; } my $data = $props->{$p}; - for my $a (keys %$data) { + for my $a (keys $data->%*) { $res->{$a} = $data->{$a}; } $res->{optional} = 1; } } - foreach my $type (keys %$plugins) { + for my $type (keys $plugins->%*) { my $opts = $plugins->{$type}->options(); - foreach my $p (keys %$opts) { + for my $p (keys $opts->%*) { my $prop; if ($property_isolation) { $prop = $isolatedPropertyList->{$type}->{$p}; @@ -644,7 +644,7 @@ sub init { # automatically the properties to options (if not specified explicitly) if ($property_isolation) { - foreach my $p (keys $isolatedPropertyList->{$type}->%*) { + for my $p (keys $isolatedPropertyList->{$type}->%*) { next if $opts->{$p}; $opts->{$p} = {}; $opts->{$p}->{optional} = 1 if $isolatedPropertyList->{$type}->{$p}->{optional}; @@ -655,7 +655,7 @@ sub init { } $propertyList->{type}->{type} = 'string'; - $propertyList->{type}->{enum} = [sort keys %$plugins]; + $propertyList->{type}->{enum} = [sort keys $plugins->%*]; } =pod @@ -796,7 +796,7 @@ sub check_value { } PVE::JSONSchema::check_prop($value, $checkschema, '', $errors); - if (scalar(keys %$errors)) { + if (scalar(keys $errors->%*)) { die "$errors->{$key}\n" if $errors->{$key}; die "$errors->{_root}\n" if $errors->{_root}; die "unknown error\n"; @@ -1076,7 +1076,7 @@ sub parse_config { } while ($line = $nextline->()) { - next if $skip; # skip + next if $skip; $errprefix = "file $filename line $lineno"; @@ -1105,7 +1105,7 @@ sub parse_config { }; if (my $err = $@) { warn "$errprefix (section '$sectionId') - unable to parse value of '$k': $err"; - push @$errors, { + push $errors->@*, { context => $errprefix, section => $sectionId, key => $k, @@ -1142,7 +1142,7 @@ sub parse_config { order => $order, digest => $digest }; - $cfg->{errors} = $errors if scalar(@$errors) > 0; + $cfg->{errors} = $errors if scalar($errors->@*) > 0; return $cfg; } @@ -1173,7 +1173,7 @@ sub check_config { my $settings = { type => $type }; - foreach my $k (keys %$config) { + for my $k (keys $config->%*) { my $value = $config->{$k}; die "can't change value of fixed parameter '$k'\n" @@ -1189,7 +1189,7 @@ sub check_config { if ($create) { # check if we have a value for all required options - foreach my $k (keys %$opts) { + for my $k (keys $opts->%*) { next if $opts->{$k}->{optional}; die "missing value for required option '$k'\n" if !defined($config->{$k}); @@ -1199,7 +1199,7 @@ sub check_config { return $settings; } -my $format_config_line = sub { +my sub format_config_line { my ($schema, $key, $value) = @_; my $ct = $schema->{type}; @@ -1279,17 +1279,17 @@ sub write_config { my $order = $cfg->{order}; my $maxpri = 0; - foreach my $sectionId (keys %$ids) { + for my $sectionId (keys $ids->%*) { my $pri = $order->{$sectionId}; $maxpri = $pri if $pri && $pri > $maxpri; } - foreach my $sectionId (keys %$ids) { + for my $sectionId (keys $ids->%*) { if (!defined ($order->{$sectionId})) { $order->{$sectionId} = ++$maxpri; } } - foreach my $sectionId (sort {$order->{$a} <=> $order->{$b}} keys %$ids) { + for my $sectionId (sort {$order->{$a} <=> $order->{$b}} keys $ids->%*) { my $scfg = $ids->{$sectionId}; my $type = $scfg->{type}; my $opts = $pdata->{options}->{$type}; @@ -1304,7 +1304,7 @@ sub write_config { if (!$opts && $allow_unknown) { $done_hash->{type} = 1; my @first = exists($scfg->{comment}) ? ('comment') : (); - for my $k (@first, sort keys %$scfg) { + for my $k (@first, sort keys $scfg->%*) { next if defined($done_hash->{$k}); $done_hash->{$k} = 1; my $v = $scfg->{$k}; @@ -1324,7 +1324,7 @@ sub write_config { my $k = 'comment'; my $v = $class->encode_value($type, $k, $scfg->{$k}); my $prop = $class->get_property_schema($type, $k); - $data .= &$format_config_line($prop, $k, $v); + $data .= format_config_line($prop, $k, $v); } $data .= "\tdisable\n" if $scfg->{disable} && !$done_hash->{disable}; @@ -1332,8 +1332,8 @@ sub write_config { $done_hash->{comment} = 1; $done_hash->{disable} = 1; - my @option_keys = sort keys %$opts; - foreach my $k (@option_keys) { + my @option_keys = sort keys $opts->%*; + for my $k (@option_keys) { next if defined($done_hash->{$k}); next if $opts->{$k}->{optional}; $done_hash->{$k} = 1; @@ -1342,16 +1342,16 @@ sub write_config { if !defined ($v); $v = $class->encode_value($type, $k, $v); my $prop = $class->get_property_schema($type, $k); - $data .= &$format_config_line($prop, $k, $v); + $data .= format_config_line($prop, $k, $v); } - foreach my $k (@option_keys) { + for my $k (@option_keys) { next if defined($done_hash->{$k}); my $v = $scfg->{$k}; next if !defined($v); $v = $class->encode_value($type, $k, $v); my $prop = $class->get_property_schema($type, $k); - $data .= &$format_config_line($prop, $k, $v); + $data .= format_config_line($prop, $k, $v); } $out .= "$data\n"; -- 2.39.2 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [pve-devel] [PATCH v1 pve-common 3/3] section config: clean up parser logic 2024-06-04 9:28 [pve-devel] [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 2/3] section config: update code style Max Carrara @ 2024-06-04 9:28 ` Max Carrara 2024-06-11 10:46 ` Fabian Grünbichler 2024-07-24 11:34 ` [pve-devel] applied: [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Fiona Ebner 3 siblings, 1 reply; 10+ messages in thread From: Max Carrara @ 2024-06-04 9:28 UTC (permalink / raw) To: pve-devel 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> --- src/PVE/SectionConfig.pm | 189 ++++++++++++++++++++------------------- 1 file changed, 98 insertions(+), 91 deletions(-) diff --git a/src/PVE/SectionConfig.pm b/src/PVE/SectionConfig.pm index a6b0183..30faaa4 100644 --- a/src/PVE/SectionConfig.pm +++ b/src/PVE/SectionConfig.pm @@ -1014,25 +1014,26 @@ The error. sub parse_config { my ($class, $filename, $raw, $allow_unknown) = @_; - my $pdata = $class->private(); + if (!defined($raw)) { + return { + ids => {}, + order => {}, + digest => Digest::SHA::sha1_hex(''), + }; + } + + my $re_begins_with_comment = qr/^\s*#/; + my $re_kv_pair = qr/^\s+ (\S+) (\s+ (.*\S) )? \s*$/x; my $ids = {}; my $order = {}; - - $raw = '' if !defined($raw); - my $digest = Digest::SHA::sha1_hex($raw); - my $pri = 1; + my $current_order = 1; + my $line_no = 0; - my $lineno = 0; my @lines = split(/\n/, $raw); - my $nextline = sub { - while (defined(my $line = shift @lines)) { - $lineno++; - return $line if ($line !~ /^\s*#/); - } - }; + my @errors; my $is_array = sub { my ($type, $key) = @_; @@ -1043,106 +1044,112 @@ sub parse_config { return $schema->{type} eq 'array'; }; - my $errors = []; - while (@lines) { - my $line = $nextline->(); + my $get_next_line = sub { + while (scalar(@lines)) { + my $line = shift(@lines); + $line_no++; + + next if ($line =~ m/$re_begins_with_comment/); + + return $line; + } + + return undef; + }; + + my $skip_to_next_empty_line = sub { + while ($get_next_line->() ne '') {} + }; + + while (defined(my $line = $get_next_line->())) { next if !$line; - my $errprefix = "file $filename line $lineno"; + my $errprefix = "file $filename line $line_no"; - my ($type, $sectionId, $errmsg, $config) = $class->parse_section_header($line); - if ($config) { - my $skip = 0; - my $unknown = 0; + my ($type, $section_id, $errmsg, $config) = $class->parse_section_header($line); - my $plugin; + if (!defined($config)) { + warn "$errprefix - ignore config line: $line\n"; + next; + } - if ($errmsg) { - $skip = 1; - chomp $errmsg; - warn "$errprefix (skip section '$sectionId'): $errmsg\n"; - } elsif (!$type) { - $skip = 1; - warn "$errprefix (skip section '$sectionId'): missing type - internal error\n"; - } else { - if (!($plugin = $pdata->{plugins}->{$type})) { - if ($allow_unknown) { - $unknown = 1; - } else { - $skip = 1; - warn "$errprefix (skip section '$sectionId'): unsupported type '$type'\n"; - } - } - } + if ($errmsg) { + chomp $errmsg; + warn "$errprefix (skip section '$section_id'): $errmsg\n"; + $skip_to_next_empty_line->(); + next; + } + + if (!$type) { + warn "$errprefix (skip section '$section_id'): missing type - internal error\n"; + $skip_to_next_empty_line->(); + next; + } + + my $plugin = eval { $class->lookup($type) }; + my $is_unknown_type = defined($@) && $@ ne ''; + + if ($is_unknown_type && !$allow_unknown) { + warn "$errprefix (skip section '$section_id'): unsupported type '$type'\n"; + $skip_to_next_empty_line->(); + next; + } + + # Parse kv-pairs of section - will go on until empty line is encountered + while (my $section_line = $get_next_line->()) { + if ($section_line =~ m/$re_kv_pair/) { + my ($key, $value) = ($1, $3); - while ($line = $nextline->()) { - next if $skip; - - $errprefix = "file $filename line $lineno"; - - if ($line =~ m/^\s+(\S+)(\s+(.*\S))?\s*$/) { - my ($k, $v) = ($1, $3); - - eval { - if ($unknown) { - if (!defined($config->{$k})) { - $config->{$k} = $v; - } else { - if (!ref($config->{$k})) { - $config->{$k} = [$config->{$k}]; - } - push $config->{$k}->@*, $v; - } - } elsif ($is_array->($type, $k)) { - $v = $plugin->check_value($type, $k, $v, $sectionId); - $config->{$k} = [] if !defined($config->{$k}); - push $config->{$k}->@*, $v; + eval { + if ($is_unknown_type) { + if (!defined($config->{$key})) { + $config->{$key} = $value; } else { - die "duplicate attribute\n" if defined($config->{$k}); - $v = $plugin->check_value($type, $k, $v, $sectionId); - $config->{$k} = $v; + $config->{$key} = [$config->{$key}] if !ref($config->{$key}); + push $config->{$key}->@*, $value; } - }; - if (my $err = $@) { - warn "$errprefix (section '$sectionId') - unable to parse value of '$k': $err"; - push $errors->@*, { - context => $errprefix, - section => $sectionId, - key => $k, - err => $err, - }; + } elsif ($is_array->($type, $key)) { + $value = $plugin->check_value($type, $key, $value, $section_id); + $config->{$key} = [] if !defined($config->{$key}); + push $config->{$key}->@*, $value; + } else { + die "duplicate attribute\n" if defined($config->{$key}); + $value = $plugin->check_value($type, $key, $value, $section_id); + $config->{$key} = $value; } - - } else { - warn "$errprefix (section '$sectionId') - ignore config line: $line\n"; + }; + if (my $err = $@) { + warn "$errprefix (section '$section_id') - unable to parse value of '$key': $err"; + push @errors, { + context => $errprefix, + section => $section_id, + key => $key, + err => $err, + }; } } + } - if ($unknown) { - $config->{type} = $type; - $ids->{$sectionId} = $config; - $order->{$sectionId} = $pri++; - } elsif (!$skip && $type && $plugin && $config) { - $config->{type} = $type; - if (!$unknown) { - $config = eval { $config = $plugin->check_config($sectionId, $config, 1, 1); }; - warn "$errprefix (skip section '$sectionId'): $@" if $@; - } - $ids->{$sectionId} = $config; - $order->{$sectionId} = $pri++; + if ($is_unknown_type || ($type && $plugin && $config)) { + $config->{type} = $type; + + if (!$is_unknown_type) { + $config = eval { $config = $plugin->check_config($section_id, $config, 1, 1); }; + warn "$errprefix (skip section '$section_id'): $@" if $@; } - } else { - warn "$errprefix - ignore config line: $line\n"; + $ids->{$section_id} = $config; + $order->{$section_id} = $current_order++; } } my $cfg = { ids => $ids, order => $order, - digest => $digest + digest => $digest, }; - $cfg->{errors} = $errors if scalar($errors->@*) > 0; + + $cfg->{errors} = \@errors if scalar(@errors) > 0; return $cfg; } -- 2.39.2 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH v1 pve-common 3/3] section config: clean up parser logic 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 3/3] section config: clean up parser logic Max Carrara @ 2024-06-11 10:46 ` Fabian Grünbichler 2024-06-13 9:27 ` Max Carrara 0 siblings, 1 reply; 10+ messages in thread From: Fabian Grünbichler @ 2024-06-11 10:46 UTC (permalink / raw) To: Proxmox VE development discussion On June 4, 2024 11:28 am, Max Carrara wrote: > 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. it also mixes deeper changes with things like variable renaming, which makes it unnecessarily hard to review.. > > Signed-off-by: Max Carrara <m.carrara@proxmox.com> > --- > src/PVE/SectionConfig.pm | 189 ++++++++++++++++++++------------------- > 1 file changed, 98 insertions(+), 91 deletions(-) > > diff --git a/src/PVE/SectionConfig.pm b/src/PVE/SectionConfig.pm > index a6b0183..30faaa4 100644 > --- a/src/PVE/SectionConfig.pm > +++ b/src/PVE/SectionConfig.pm > @@ -1014,25 +1014,26 @@ The error. > sub parse_config { > my ($class, $filename, $raw, $allow_unknown) = @_; > > - my $pdata = $class->private(); > + if (!defined($raw)) { > + return { > + ids => {}, > + order => {}, > + digest => Digest::SHA::sha1_hex(''), > + }; > + } > + > + my $re_begins_with_comment = qr/^\s*#/; > + my $re_kv_pair = qr/^\s+ (\S+) (\s+ (.*\S) )? \s*$/x; I am not sure this is really more readable? especially in a RE that is basically only concerned with whitespace.. and for a RE that is only used once.. > > my $ids = {}; > my $order = {}; > - > - $raw = '' if !defined($raw); > - > my $digest = Digest::SHA::sha1_hex($raw); > > - my $pri = 1; > + my $current_order = 1; this is actually a worse name than before. this would be something like current_index? current_position? section_no? > + my $line_no = 0; > > - my $lineno = 0; > my @lines = split(/\n/, $raw); > - my $nextline = sub { > - while (defined(my $line = shift @lines)) { > - $lineno++; > - return $line if ($line !~ /^\s*#/); > - } > - }; > + my @errors; what do we gain from this? > > my $is_array = sub { > my ($type, $key) = @_; > @@ -1043,106 +1044,112 @@ sub parse_config { > return $schema->{type} eq 'array'; > }; > > - my $errors = []; > - while (@lines) { > - my $line = $nextline->(); > + my $get_next_line = sub { > + while (scalar(@lines)) { > + my $line = shift(@lines); > + $line_no++; > + > + next if ($line =~ m/$re_begins_with_comment/); > + > + return $line; > + } > + > + return undef; > + }; > + > + my $skip_to_next_empty_line = sub { > + while ($get_next_line->() ne '') {} > + }; > + > + while (defined(my $line = $get_next_line->())) { > next if !$line; > > - my $errprefix = "file $filename line $lineno"; > + my $errprefix = "file $filename line $line_no"; > > - my ($type, $sectionId, $errmsg, $config) = $class->parse_section_header($line); > - if ($config) { > - my $skip = 0; > - my $unknown = 0; > + my ($type, $section_id, $errmsg, $config) = $class->parse_section_header($line); > > - my $plugin; > + if (!defined($config)) { > + warn "$errprefix - ignore config line: $line\n"; > + next; > + } > > - if ($errmsg) { > - $skip = 1; > - chomp $errmsg; > - warn "$errprefix (skip section '$sectionId'): $errmsg\n"; > - } elsif (!$type) { > - $skip = 1; > - warn "$errprefix (skip section '$sectionId'): missing type - internal error\n"; > - } else { > - if (!($plugin = $pdata->{plugins}->{$type})) { > - if ($allow_unknown) { > - $unknown = 1; > - } else { > - $skip = 1; > - warn "$errprefix (skip section '$sectionId'): unsupported type '$type'\n"; > - } > - } > - } > + if ($errmsg) { > + chomp $errmsg; > + warn "$errprefix (skip section '$section_id'): $errmsg\n"; > + $skip_to_next_empty_line->(); > + next; > + } > + > + if (!$type) { > + warn "$errprefix (skip section '$section_id'): missing type - internal error\n"; > + $skip_to_next_empty_line->(); > + next; > + } > + > + my $plugin = eval { $class->lookup($type) }; > + my $is_unknown_type = defined($@) && $@ ne ''; > + > + if ($is_unknown_type && !$allow_unknown) { > + warn "$errprefix (skip section '$section_id'): unsupported type '$type'\n"; > + $skip_to_next_empty_line->(); > + next; > + } > + > + # Parse kv-pairs of section - will go on until empty line is encountered > + while (my $section_line = $get_next_line->()) { > + if ($section_line =~ m/$re_kv_pair/) { > + my ($key, $value) = ($1, $3); > > - while ($line = $nextline->()) { > - next if $skip; > - > - $errprefix = "file $filename line $lineno"; > - > - if ($line =~ m/^\s+(\S+)(\s+(.*\S))?\s*$/) { > - my ($k, $v) = ($1, $3); > - > - eval { > - if ($unknown) { > - if (!defined($config->{$k})) { > - $config->{$k} = $v; > - } else { > - if (!ref($config->{$k})) { > - $config->{$k} = [$config->{$k}]; > - } > - push $config->{$k}->@*, $v; > - } > - } elsif ($is_array->($type, $k)) { > - $v = $plugin->check_value($type, $k, $v, $sectionId); > - $config->{$k} = [] if !defined($config->{$k}); > - push $config->{$k}->@*, $v; > + eval { > + if ($is_unknown_type) { > + if (!defined($config->{$key})) { > + $config->{$key} = $value; > } else { > - die "duplicate attribute\n" if defined($config->{$k}); > - $v = $plugin->check_value($type, $k, $v, $sectionId); > - $config->{$k} = $v; > + $config->{$key} = [$config->{$key}] if !ref($config->{$key}); > + push $config->{$key}->@*, $value; > } > - }; > - if (my $err = $@) { > - warn "$errprefix (section '$sectionId') - unable to parse value of '$k': $err"; > - push $errors->@*, { > - context => $errprefix, > - section => $sectionId, > - key => $k, > - err => $err, > - }; > + } elsif ($is_array->($type, $key)) { > + $value = $plugin->check_value($type, $key, $value, $section_id); > + $config->{$key} = [] if !defined($config->{$key}); > + push $config->{$key}->@*, $value; > + } else { > + die "duplicate attribute\n" if defined($config->{$key}); > + $value = $plugin->check_value($type, $key, $value, $section_id); > + $config->{$key} = $value; > } > - > - } else { > - warn "$errprefix (section '$sectionId') - ignore config line: $line\n"; > + }; > + if (my $err = $@) { > + warn "$errprefix (section '$section_id') - unable to parse value of '$key': $err"; > + push @errors, { > + context => $errprefix, > + section => $section_id, > + key => $key, > + err => $err, > + }; > } > } > + } > > - if ($unknown) { > - $config->{type} = $type; > - $ids->{$sectionId} = $config; > - $order->{$sectionId} = $pri++; > - } elsif (!$skip && $type && $plugin && $config) { > - $config->{type} = $type; > - if (!$unknown) { > - $config = eval { $config = $plugin->check_config($sectionId, $config, 1, 1); }; > - warn "$errprefix (skip section '$sectionId'): $@" if $@; > - } > - $ids->{$sectionId} = $config; > - $order->{$sectionId} = $pri++; > + if ($is_unknown_type || ($type && $plugin && $config)) { > + $config->{type} = $type; > + > + if (!$is_unknown_type) { > + $config = eval { $config = $plugin->check_config($section_id, $config, 1, 1); }; > + warn "$errprefix (skip section '$section_id'): $@" if $@; > } > > - } else { > - warn "$errprefix - ignore config line: $line\n"; > + $ids->{$section_id} = $config; > + $order->{$section_id} = $current_order++; > } > } > > my $cfg = { > ids => $ids, > order => $order, > - digest => $digest > + digest => $digest, > }; > - $cfg->{errors} = $errors if scalar($errors->@*) > 0; > + > + $cfg->{errors} = \@errors if scalar(@errors) > 0; > > return $cfg; > } > -- > 2.39.2 > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH v1 pve-common 3/3] section config: clean up parser logic 2024-06-11 10:46 ` Fabian Grünbichler @ 2024-06-13 9:27 ` Max Carrara 0 siblings, 0 replies; 10+ messages in thread From: Max Carrara @ 2024-06-13 9:27 UTC (permalink / raw) To: Proxmox VE development discussion On Tue Jun 11, 2024 at 12:46 PM CEST, Fabian Grünbichler wrote: > On June 4, 2024 11:28 am, Max Carrara wrote: > > 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. > > it also mixes deeper changes with things like variable renaming, which > makes it unnecessarily hard to review.. Should've mentioned that; mea culpa. Will see if I can retain the old names, otherwise will mention / list the renamed variables. > > > > > Signed-off-by: Max Carrara <m.carrara@proxmox.com> > > --- > > src/PVE/SectionConfig.pm | 189 ++++++++++++++++++++------------------- > > 1 file changed, 98 insertions(+), 91 deletions(-) > > > > diff --git a/src/PVE/SectionConfig.pm b/src/PVE/SectionConfig.pm > > index a6b0183..30faaa4 100644 > > --- a/src/PVE/SectionConfig.pm > > +++ b/src/PVE/SectionConfig.pm > > @@ -1014,25 +1014,26 @@ The error. > > sub parse_config { > > my ($class, $filename, $raw, $allow_unknown) = @_; > > > > - my $pdata = $class->private(); > > + if (!defined($raw)) { > > + return { > > + ids => {}, > > + order => {}, > > + digest => Digest::SHA::sha1_hex(''), > > + }; > > + } > > + > > + my $re_begins_with_comment = qr/^\s*#/; > > + my $re_kv_pair = qr/^\s+ (\S+) (\s+ (.*\S) )? \s*$/x; > > I am not sure this is really more readable? especially in a RE that is > basically only concerned with whitespace.. and for a RE that is only > used once.. I mean I could drop the `x` flag if you'd like, just thought that it would make it a little easier to parse... Though, the reason why I'm personally a fan of assigning regexes to variables is because it makes the code more expressive IMO. If someone who usually doesn't deal with regexes has to read this code, the variable name describes what the regex does. That's mainly the reason why I put it there. > > > > > my $ids = {}; > > my $order = {}; > > - > > - $raw = '' if !defined($raw); > > - > > my $digest = Digest::SHA::sha1_hex($raw); > > > > - my $pri = 1; > > + my $current_order = 1; > > this is actually a worse name than before. this would be something like > current_index? current_position? section_no? Hm, agreed - those are actually better. Will incorporate in v2, thanks! > > > + my $line_no = 0; > > > > - my $lineno = 0; > > my @lines = split(/\n/, $raw); > > - my $nextline = sub { > > - while (defined(my $line = shift @lines)) { > > - $lineno++; > > - return $line if ($line !~ /^\s*#/); > > - } > > - }; > > + my @errors; > > what do we gain from this? My intention here was to work on the array directly and then return it as a reference below (if there are any errors) rather than working with a reference from the get-go, having to deref whenever there's a `push`. I guess it's more a personal preference of mine, I just find it better to work with. Can keep the array ref in v2 though, doesn't matter that much. :P > > > > > my $is_array = sub { > > my ($type, $key) = @_; > > @@ -1043,106 +1044,112 @@ sub parse_config { > > return $schema->{type} eq 'array'; > > }; > > > > - my $errors = []; > > - while (@lines) { > > - my $line = $nextline->(); > > + my $get_next_line = sub { > > + while (scalar(@lines)) { > > + my $line = shift(@lines); > > + $line_no++; > > + > > + next if ($line =~ m/$re_begins_with_comment/); > > + > > + return $line; > > + } > > + > > + return undef; > > + }; > > + > > + my $skip_to_next_empty_line = sub { > > + while ($get_next_line->() ne '') {} > > + }; > > + > > + while (defined(my $line = $get_next_line->())) { > > next if !$line; > > > > - my $errprefix = "file $filename line $lineno"; > > + my $errprefix = "file $filename line $line_no"; > > > > - my ($type, $sectionId, $errmsg, $config) = $class->parse_section_header($line); > > - if ($config) { > > - my $skip = 0; > > - my $unknown = 0; > > + my ($type, $section_id, $errmsg, $config) = $class->parse_section_header($line); > > > > - my $plugin; > > + if (!defined($config)) { > > + warn "$errprefix - ignore config line: $line\n"; > > + next; > > + } > > > > - if ($errmsg) { > > - $skip = 1; > > - chomp $errmsg; > > - warn "$errprefix (skip section '$sectionId'): $errmsg\n"; > > - } elsif (!$type) { > > - $skip = 1; > > - warn "$errprefix (skip section '$sectionId'): missing type - internal error\n"; > > - } else { > > - if (!($plugin = $pdata->{plugins}->{$type})) { > > - if ($allow_unknown) { > > - $unknown = 1; > > - } else { > > - $skip = 1; > > - warn "$errprefix (skip section '$sectionId'): unsupported type '$type'\n"; > > - } > > - } > > - } > > + if ($errmsg) { > > + chomp $errmsg; > > + warn "$errprefix (skip section '$section_id'): $errmsg\n"; > > + $skip_to_next_empty_line->(); > > + next; > > + } > > + > > + if (!$type) { > > + warn "$errprefix (skip section '$section_id'): missing type - internal error\n"; > > + $skip_to_next_empty_line->(); > > + next; > > + } > > + > > + my $plugin = eval { $class->lookup($type) }; > > + my $is_unknown_type = defined($@) && $@ ne ''; > > + > > + if ($is_unknown_type && !$allow_unknown) { > > + warn "$errprefix (skip section '$section_id'): unsupported type '$type'\n"; > > + $skip_to_next_empty_line->(); > > + next; > > + } > > + > > + # Parse kv-pairs of section - will go on until empty line is encountered > > + while (my $section_line = $get_next_line->()) { > > + if ($section_line =~ m/$re_kv_pair/) { > > + my ($key, $value) = ($1, $3); > > > > - while ($line = $nextline->()) { > > - next if $skip; > > - > > - $errprefix = "file $filename line $lineno"; > > - > > - if ($line =~ m/^\s+(\S+)(\s+(.*\S))?\s*$/) { > > - my ($k, $v) = ($1, $3); > > - > > - eval { > > - if ($unknown) { > > - if (!defined($config->{$k})) { > > - $config->{$k} = $v; > > - } else { > > - if (!ref($config->{$k})) { > > - $config->{$k} = [$config->{$k}]; > > - } > > - push $config->{$k}->@*, $v; > > - } > > - } elsif ($is_array->($type, $k)) { > > - $v = $plugin->check_value($type, $k, $v, $sectionId); > > - $config->{$k} = [] if !defined($config->{$k}); > > - push $config->{$k}->@*, $v; > > + eval { > > + if ($is_unknown_type) { > > + if (!defined($config->{$key})) { > > + $config->{$key} = $value; > > } else { > > - die "duplicate attribute\n" if defined($config->{$k}); > > - $v = $plugin->check_value($type, $k, $v, $sectionId); > > - $config->{$k} = $v; > > + $config->{$key} = [$config->{$key}] if !ref($config->{$key}); > > + push $config->{$key}->@*, $value; > > } > > - }; > > - if (my $err = $@) { > > - warn "$errprefix (section '$sectionId') - unable to parse value of '$k': $err"; > > - push $errors->@*, { > > - context => $errprefix, > > - section => $sectionId, > > - key => $k, > > - err => $err, > > - }; > > + } elsif ($is_array->($type, $key)) { > > + $value = $plugin->check_value($type, $key, $value, $section_id); > > + $config->{$key} = [] if !defined($config->{$key}); > > + push $config->{$key}->@*, $value; > > + } else { > > + die "duplicate attribute\n" if defined($config->{$key}); > > + $value = $plugin->check_value($type, $key, $value, $section_id); > > + $config->{$key} = $value; > > } > > - > > - } else { > > - warn "$errprefix (section '$sectionId') - ignore config line: $line\n"; > > + }; > > + if (my $err = $@) { > > + warn "$errprefix (section '$section_id') - unable to parse value of '$key': $err"; > > + push @errors, { > > + context => $errprefix, > > + section => $section_id, > > + key => $key, > > + err => $err, > > + }; > > } > > } > > + } > > > > - if ($unknown) { > > - $config->{type} = $type; > > - $ids->{$sectionId} = $config; > > - $order->{$sectionId} = $pri++; > > - } elsif (!$skip && $type && $plugin && $config) { > > - $config->{type} = $type; > > - if (!$unknown) { > > - $config = eval { $config = $plugin->check_config($sectionId, $config, 1, 1); }; > > - warn "$errprefix (skip section '$sectionId'): $@" if $@; > > - } > > - $ids->{$sectionId} = $config; > > - $order->{$sectionId} = $pri++; > > + if ($is_unknown_type || ($type && $plugin && $config)) { > > + $config->{type} = $type; > > + > > + if (!$is_unknown_type) { > > + $config = eval { $config = $plugin->check_config($section_id, $config, 1, 1); }; > > + warn "$errprefix (skip section '$section_id'): $@" if $@; > > } > > > > - } else { > > - warn "$errprefix - ignore config line: $line\n"; > > + $ids->{$section_id} = $config; > > + $order->{$section_id} = $current_order++; > > } > > } > > > > my $cfg = { > > ids => $ids, > > order => $order, > > - digest => $digest > > + digest => $digest, > > }; > > - $cfg->{errors} = $errors if scalar($errors->@*) > 0; > > + > > + $cfg->{errors} = \@errors if scalar(@errors) > 0; > > > > return $cfg; > > } > > -- > > 2.39.2 > > > > > > > > _______________________________________________ > > pve-devel mailing list > > pve-devel@lists.proxmox.com > > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > > > > > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [pve-devel] applied: [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup 2024-06-04 9:28 [pve-devel] [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Max Carrara ` (2 preceding siblings ...) 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 3/3] section config: clean up parser logic Max Carrara @ 2024-07-24 11:34 ` Fiona Ebner 2024-07-24 11:46 ` Fabian Grünbichler 3 siblings, 1 reply; 10+ messages in thread From: Fiona Ebner @ 2024-07-24 11:34 UTC (permalink / raw) To: Proxmox VE development discussion, Max Carrara Am 04.06.24 um 11:28 schrieb Max Carrara: > > Max Carrara (3): > section config: document package and its methods with POD > section config: update code style > section config: clean up parser logic > > src/PVE/SectionConfig.pm | 982 +++++++++++++++++++++++++++++++-------- > 1 file changed, 798 insertions(+), 184 deletions(-) > For the record, it seems like this already got applied: https://git.proxmox.com/?p=pve-common.git;a=commit;h=6cba8d7660b62002ffdc81655b8e8668952614a9 Could you re-send the changes for v2 as follow-ups? Or v1 could also be reverted and v2 applied? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] applied: [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup 2024-07-24 11:34 ` [pve-devel] applied: [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Fiona Ebner @ 2024-07-24 11:46 ` Fabian Grünbichler 0 siblings, 0 replies; 10+ messages in thread From: Fabian Grünbichler @ 2024-07-24 11:46 UTC (permalink / raw) To: Fiona Ebner, Max Carrara, Proxmox VE development discussion On July 24, 2024 1:34 pm, Fiona Ebner wrote: > Am 04.06.24 um 11:28 schrieb Max Carrara: >> >> Max Carrara (3): >> section config: document package and its methods with POD >> section config: update code style >> section config: clean up parser logic >> >> src/PVE/SectionConfig.pm | 982 +++++++++++++++++++++++++++++++-------- >> 1 file changed, 798 insertions(+), 184 deletions(-) >> > > For the record, it seems like this already got applied: > https://git.proxmox.com/?p=pve-common.git;a=commit;h=6cba8d7660b62002ffdc81655b8e8668952614a9 > > Could you re-send the changes for v2 as follow-ups? Or v1 could also be > reverted and v2 applied? I reverted them for now - it seems they accidentally slipped in when I applied an unrelated patch cause of a dirty repo state I missed before pushing.. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-07-24 11:46 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-06-04 9:28 [pve-devel] [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 1/3] section config: document package and its methods with POD Max Carrara 2024-06-11 10:46 ` Fabian Grünbichler 2024-06-13 9:14 ` Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 2/3] section config: update code style Max Carrara 2024-06-04 9:28 ` [pve-devel] [PATCH v1 pve-common 3/3] section config: clean up parser logic Max Carrara 2024-06-11 10:46 ` Fabian Grünbichler 2024-06-13 9:27 ` Max Carrara 2024-07-24 11:34 ` [pve-devel] applied: [PATCH v1 pve-common 0/3] Section Config: Documentation & Code Cleanup Fiona Ebner 2024-07-24 11:46 ` Fabian Grünbichler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox