In a previous implementation using timestamps we ran into timing
problems on slower systems. So instead lets record the git commit
ID of the latest ngcpcfg commit and check whether we have a match
between this commit and an according ngcpcfg build.
If the "ngcpcfg build" was executed without an "ngcpcfg commit"
before then we mark it as dirty since we don't have an according
git commit available for testing against. Since that's a common
workflow we don't report it as a real problem though, instead we
inform the user using:
| OK: nothing to build (latest build newer than latest commit)
As we commit AFTER the build in the apply action we can use a
workaround for this situation, so build and commit state match
with each other in that case then.
Change-Id: I48e32db6f42b53fe97a0b88805e7ddbee8576133
This reverts commit db373d3927.
Conflicts:
etc/ngcp-config/ngcpcfg.cfg
Until we've a working solution for this let's revert
the broken change so we avoid this being a release
stopper.
Change-Id: If03d9b3913de23c698b430d583dc7babfcc4ff04
There are some times when a configuration, service or system upgrade
requires a reboot to take effect. When a component requires a reboot,
it will record this fact in the file system through the file
«/var/run/reboot-required», and «ngcpcfg status» will notify the user
that a reboot has been requested.
We use the «/var/run/reboot-required» because it is already being used
in the unattended-upgrades package on Debian/Ubuntu which does something
similar.
Change-Id: I43997bfb83892f67bd57bb55ad3ec0a41a5e088d
If the latest git commit has a newer timestamp than
our latest "build" action then a "build" (or apply)
run is required, inform the user about it.
Change-Id: I83e2ff47ba54da733d368d78b6616d13d31a66d4
Provide "apply" action as separate script.
We don't care about changes related to etckeeper, but just
about outstanding commits in /etc/ngcp-config.
Change-Id: I47411f00a5085d65cacf9e24fc8a468258d57c31
Previously we guessed the status of current branch by parsing
'git status' output. Unfortunately we have to care about a
corner cases in this way. In the same time we can easily
consider current branch status comparing commits.
Introducing the new function to provide current branch status:
up-2-date, ahead, behind or diverged with origin.
Change-Id: I4d09c8867069ccafc97e5d31638e8bc94caa58cd
This allows us to abort in 'ngcpcfg status' whenever there are
outstanding changes to pull/push from the shared storage. Using
the --no-action-failure option allows the user to continue anyway.
Change-Id: I4062d5bb627bb553b98705bb122575651b035849
`which $function` doesn't work as intended, commit
dc984aa2e7 in ngcpcfg-ha.git broke the HA features
in 'ngcpcfg status' therefore.
Change-Id: I2bb9ed9b3276e63fc6d127559df32ae229a43b33
The default Hash::Merge->merge() behaviour is LEFT_PRECEDENT:
http://search.cpan.org/~rehsack/Hash-Merge-0.200/lib/Hash/Merge.pm
Which means:
> The values buried in the left hash will never be lost;
> any values that can be added from the right hash will be attempted.
So, the values from HOST_CONFIG never overwrites default NGCPCTL_CONFIG:
> NGCPCTL_CONFIG="${NGCPCTL_MAIN}/config.yml"
> HOST_CONFIG="${NGCPCTL_MAIN}/config.$(hostname).yml"
We need to use RIGHT_PRECEDENT order to be in sync with 'scripts/build':
> ${NGCPCTL_CONFIG:-} ${HOST_CONFIG:-} ${LOCAL_CONFIG:-} ${NETWORK_CONFIG:-} ${EXTRA_CONFIG_FILES:-} ${CONSTANTS_CONFIG:-}
Change-Id: I597bb082a1791c1f06072d85c4a26fbb8b8320ce
Disabled by default as we need a time to check it carefuly.
Also we need to solve the "tilda" problem reported upstream:
https://github.com/eserte/p5-Kwalify/issues/1
Change-Id: Ia2c3d48f0ac6fc6ac9899d44f4291544373806d9
- added quiet option to disable loading output at tt2-daemon
- detect arrays and output values joined by space
Change-Id: I0b7694a366a284ca2b24ea2df55cb285b598e66d
We will use first free port instead which will be stored into
/var/run/ngcpcfg.port file while tt2-daemon is up and running.
Change-Id: I1a918f865d87863eef7d34be8abd1032282220b8
Otherwise users notice error during upgrade mr3.7->mr3.8:
> ngcpcfg commit 'snapshot during /usr/share/ngcp-upgrade-mr3.8/upgrade-2.8-to-mr3.8 - Mon Apr 13 10:29:24 CEST 2015'
> YAML Error: Couldn't open /etc/ngcp-rtpengine-daemon/interfaces.yml for input:\nNo such file or directory
> Code: YAML_LOAD_ERR_FILE_INPUT
> at /usr/share/perl5/YAML.pm line 71
> OK
> Synchronizing data from /etc/ngcp-config/constants.yml
Change-Id: I2e4b8780d2ada64854186da93b03b8817eac99bf
Sometimes it contains very useful information, like:
> /usr/share/ngcp-ngcpcfg/helper//validate-yml /etc/ngcp-config/network.yml
>> YAML::Tiny failed to classify line ' hwaddr:5C:F3:FC:11:67:26 '
>> Can't call method "write_string" without a package or object
>> reference at /usr/share/ngcp-ngcpcfg/helper//validate-yml line 15.
Change-Id: I762b4dc1b0e6b3446f6a431b038fa6ed674e5516
Victor Seva
Guillem Jover
Richard Fuchs
Michael Prokop
Jenkins User
Alexander Lutay
Kirill Solomko
Rene Krenn