You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by "Andy Kurth (JIRA)" <ji...@apache.org> on 2017/05/22 21:31:04 UTC

[jira] [Updated] (VCL-1040) Issues with backend usage of Site Configuration variables

     [ https://issues.apache.org/jira/browse/VCL-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Kurth updated VCL-1040:
----------------------------
    Fix Version/s:     (was: 2.5)
                   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
>             Fix For: 2.5.1
>
>
> 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
(v6.3.15#6346)