[
https://issues.apache.org/jira/browse/VCL-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Thompson updated VCL-1040:
-------------------------------
Fix Version/s: (was: 2.5.1)
> Issues with backend usage of Site Configuration variables
> ---------------------------------------------------------
>
> Key: VCL-1040
> URL: https://issues.apache.org/jira/browse/VCL-1040
> Project: VCL
> Issue Type: Bug
> Components: vcld (backend)
> Affects Versions: 2.4.2
> Reporter: Andy Kurth
> Priority: Major
>
> Introduced in:
> http://svn.apache.org/viewvc?view=revision&revision=1614746
> +*Affiliation not being universally considered*+
> There's code in utils.pm that sets:
> $ENV\{management_node_info\}->\{CLUSTER_INUSE_CHECK\}
> and possibly other values without regard to affiliation. The affiliation
> *must* be considered for every value used from the variable table that is
> tied to an affiliation.
> +*DataStructure.pm's get_cluster_inuse_check doesn't work*+
> Luckily, $self->data->get_cluster_inuse_check isn't being called from
> anywhere.
> utils.pm sets and uses the following piece of data:
> {panel}$ENV\{management_node_info\}->\{CLUSTER_INUSE_CHECK\}{panel}
> DataStructure.pm has an automatic (get/set)_cluster_inuse_check method
> looking for the data in:
> {panel}$ENV\{management_node_info\}\{{color:red}*cluster*{color}_INUSE_CHECK\}{panel}
> Perl is _CaSE seNsiTive_ so this would have never worked.
> +*OS.pm::get_timings*+
> There's also an _OS.pm::get\_timings_ subroutine which requires a specific
> key to be provided as an argument. Thankfully, this actually is checking for
> affiliation-specific values.
> I'm not sure why we need this subroutine as-is. It requires the variable
> strings to be exactly correct in get_timings as well as the calling
> subroutine.
> It would be better to create a general _utils.pm::get\_affiliation\_variable_
> subroutine which checks if a value exists for the user's affiliation. If
> not, it returns the Global default value. _get\_timings_ and its hard-coded
> defaults could then go away.
> While on the topic, it would also be useful to create a
> _utils.pm::get\_management_node\_variable_ subroutine since there are also
> variables that are management node-specific.
> The naming convention for both types of variable should be the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
