[Spce-user] [EXTERNAL] Re: mr13.5.1 to mr14.0.1 Upgrade Help

SPCE Newbie spce-user at tel.co.uk
Fri Dec 19 07:18:19 EST 2025


Sure Jose,

config.yml:

cluster_sets:
  default_set: default
  sets:
  - dispatcher_id: '50'
    name: default
  type: central

network.yml:

    lo:
      cluster_sets:
      - default
      eee: no
      ip: 127.0.0.1
      netmask: 255.255.255.0
      shared_ip: []
      shared_v6ip: []
      type:
      - ha_int
      - web_int
      - aux_ext
      - rtp_int
      - stor_int
      v6_dad: no
      v6ip: ::1
      v6netmask: 128


sip_int, api_int and ssh_int are missing from mine.

I don't think DISPATCHER_IPS is empty:-

$ declare -A DISPATCHER_IDS="(
   [default]=50
)"
$ echo $DISPATCHER_IDS

it just appears empty, but if you do

$ echo ${DISPATCHER_IDS[*]}
50

E&OE


----- Original Message ----
Date: Fri, 19 Dec 2025 13:08:00 +0100
From: Jose Antonio Su Ng <jsung at sipwise.com>
To: SPCE Newbie <spce-user at tel.co.uk>
Cc: spce-user at lists.sipwise.com
Subject: Re: [Spce-user] RE: [EXTERNAL] Re: mr13.5.1 to mr14.0.1
Upgrade Help


Hi,

Ok, so looking at the output you provided to me, DISPATCHER_IPS is
empty after generating the final config from the templates.

Could you please provide the whole section of cluster_sets in
config.yml and from network.yml.

It should look something like this:

For config.yml:
cluster_sets:
   default_set: default
   sets:
   - dispatcher_id: '50'
     name: default
   type: central

For network.yml:
     lo:
       cluster_sets:
       - default
       eee: no
       ip: 127.0.0.1
       netmask: 255.255.255.0
       shared_ip: []
       shared_v6ip: []
       type:
       - sip_int
       - ha_int
       - aux_ext
       - ssh_ext
       - api_int
       - rtp_int
       - stor_int
       v6_dad: no
       v6ip: ::1
       v6netmask: 128

Best regards,
Jos Su

On 12/19/25 11:57, SPCE Newbie wrote:
> Noone else has reported issues in updating, so apologies if it's self-
> inflicted (but don't believe reckless or even 'ambitious' changes
> made).
>
> Sorry rudely continuing to follow-up my own posts, but I found some
> extended discussion of this online:-
>
> https://serverfault.com/questions/477503/check-if-array-is-empty-in-bash
> https://stackoverflow.com/questions/65957633/check-if-array-is-empty-in-bash
>
> with many contributions but no summary.  However the general consensus
> does appear to be that interpolation of an array into a string is the
> way to go, but as, by default, shell values are space-separated, one
> ought-to  collapse and restore (or at least, reset) afterward, e.g.:-
>
>    IFS=""
>    if [[ -z "${var_value}[*]" ]] ; then
>      die "Missing mandatory environment variable '\$${var_name}',
>    exiting."
>    fi
>    IFS=" "
>
>
> ----- Original Message -----
> Date: Fri, 19 Dec 2025 10:28:25 +0000
> From: SPCE Newbie<spce-user at tel.co.uk>
> To: Jose Antonio Su Ng<jsung at sipwise.com>
> Cc:spce-user at lists.sipwise.com
> Subject: RE: [Spce-user] RE: [EXTERNAL] Re:  mr13.5.1 to mr14.0.1
> Upgrade Help
>
>
> Good morning Jose Su,
>
> I could be way off here, in which case apologies, but:
>
> The Bash function fatal_missing_var() is called on the following:
>
> fatal_missing_var ASTERISK_IPS		# Scalar
> fatal_missing_var ASTERISK_PORT		# Scalar
> fatal_missing_var RTPENGINE_IPS		# Scalar
> fatal_missing_var RTPENGINE_HTTPPORT	# Scalar
> fatal_missing_var DISPATCHER_IPS	# Composite
> fatal_missing_var KAMAILIO_LB_PORT	# Scalar
> fatal_missing_var KAMAILIO_PROXY_PORT	# Scalar
> fatal_missing_var MGMT_SIP_IPS		# Scalar
> fatal_missing_var MYSQL_HOST		# Scalar
> fatal_missing_var MYSQL_PORT		# Scalar
> fatal_missing_var NGCP_IS_DB		#
> fatal_missing_var NGCP_TYPE		#
> fatal_missing_var PROSODY_CTRLPORT	# Scalar
> fatal_missing_var GENERALRPCADDR	# Scalar
> fatal_missing_var PRXRPCADDR		# Scalar
> fatal_missing_var SEMS_IPS		# Scalar
> fatal_missing_var SEMS_PORT		# Scalar
> fatal_missing_var SEMS_XMLRPCPORT	# Scalar
> fatal_missing_var SEMS_SBC_PORT		# Scalar
> fatal_missing_var SEMS_SBC_XMLRPCPORT	# Scalar
> fatal_missing_var LB_IPS		#
> fatal_missing_var FREESWITCH		# Scalar
>
> All the others are scalar so the test works, but not DISPATCHER_IPS
> so it will bail on the fifth call.
>
> I can't test by editing it and replacing:-
>
>    if [[ -z "${var_value}" ]] ; then
>      die "Missing mandatory environment variable '\$${var_name}',
>    exiting."
>    fi
>
> with:-
>
>    if [[ -z "${var_value}[*]" ]] ; then
>      die "Missing mandatory environment variable '\$${var_name}',
>    exiting."
>    fi
>
> since the script is dynamically generated.
>
> However the modified test appears to be generalisable.
>
> Thanks in advance.
>
>
> ----- Original Message -----
> Date: Fri, 19 Dec 2025 09:30:55 +0000
> From: "Newbie <spce-user"@tel.co.uk
> To: Jose Antonio Su Ng<jsung at sipwise.com>
> Cc:spce-user at lists.sipwise.com
> Subject: [Spce-user] RE:: [EXTERNAL] Re:  mr13.5.1 to
> mr14.0.1 Upgrade Help
>
>
> Good morning Jose Su,
>
> # grep "cluster_set" /etc/ngcp-config/*yml
> /etc/ngcp-config/config.yml:cluster_sets:
> /etc/ngcp-config/network.yml:      cluster_sets:
>
>
> # cd /etc/ngcp-provisioning-tools
> # grep -A2 "DISPATCHER" * mysql_values.cfg:DISPATCHER_IPS=""
> mysql_values.cfg:declare -A DISPATCHER_IDS=(
> mysql_values.cfg-  [default]=50
> mysql_values.cfg-)
> --
> mysql_values.cfg_2025-12-18_1324:DISPATCHER_IPS=""
> mysql_values.cfg_2025-12-18_1324:declare -A DISPATCHER_IDS=(
> mysql_values.cfg_2025-12-18_1324-  [default]=50
> mysql_values.cfg_2025-12-18_1324-)
>
>
> # diff mysql_values.cfg_2025-12-18_1324 mysql_values.cfg
> #
>
> In the spirit of self-help, the mysql_values.cfg_2025-12-18_1324 file
> was an attempt to test whether it was quoting that was causing the
> problem.  It was not so reverted, hence that file is same as distro.
>
> Thank you.
>
> ----- Original Message -----
> Date: Fri, 19 Dec 2025 10:02:49 +0100
> From: Jose Antonio Su Ng<jsung at sipwise.com>
> To: SPCE Newbie<spce-user at tel.co.uk>,spce-user at lists.sipwise.com
> Subject: Re: [EXTERNAL] Re: [Spce-user] mr13.5.1 to mr14.0.1 Upgrade
> Help
>
>
> Hi,
>
> Could you share the output of these?
>
> grep "cluster_set" /etc/ngcp-config/*yml
>
> grep -A2 "DISPATCHER" /etc/ngcp-provisioning-tools/*
>
> Best regards,
> Jose Su
>
> On 12/18/25 14:57, SPCE Newbie wrote:  
>> It's rude to follow-up one's own post, so sorry.  I found this:
>>
>> /etc/ngcp-config/templates/etc/ngcp-provisioning-tools/mysql_values.cfg.services
>>
>> initialises DISPATCHER_IPS to an associative array
>>
>> $ echo ${DISPATCHER_IDS[*]}
>> 50
>>
>> But the missing mandatory environment variable test in
>>
>> /usr/share/ngcp-upgrade/steps/mr9.0/update_mysql_values
>>
>> appears equivalent to:
>>
>> $ if [[ -z "${DISPATCHER_IDS}" ]]; then echo zero; else echo
>> non-zero; fi
>> zero
>>
>> so would always fail.  Anyone successfully upgraded?
>>
>>
>> ----- Original Message -----
>> Date: Thu, 18 Dec 2025 13:02:47 +0000
>> From: SPCE Newbie<spce-user at tel.co.uk>
>> To:spce-user at lists.sipwise.com
>> Subject: [Spce-user] mr13.5.1 to mr14.0.1 Upgrade Help
>>
>>
>> Hi fellow spc-users,
>>
>> 1.  Expected Behaviour
>>
>> After reboot, ngcp-upgrade --target mr14.0.1 completes successfully.
>>
>>
>> 2.  Observed Behaviour
>>
>> # ngcp-upgrade --target mr14.0.1
>> ...
>> 2025-12-18 13:54:09: [57/63] 'spce' Running:
>> /usr/share/ngcp-upgrade/steps/mr9.0/update_mysql_values ERROR:
>> Missing mandatory environment variable '$DISPATCHER_IPS', exiting.
>> ERROR: the step 'mr9.0/update_mysql_values' failed, upgrade aborted!
>> Please fix the root of the issue and restart 'ngcp-upgrade' (see
>> error details in log file
>> /ngcp-data/ngcp-upgrade/mr13.5.1-mr14.0.1/logs/ngcp-upgrade-mr13.5.1-mr14.0.1-1766062443.log
>> ).
>>
>>
>> 3.  Attempted Resolution
>>
>> # source /etc/profile.d/ngcp-bash.sh
>> In case of local profile/bashrc customisation, then re-ran.
>>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20251219/e043be76/attachment-0001.htm>


More information about the Spce-user mailing list