We move some of the OpenPGP support into this file, which we will extend
once we switch to use the OpenPGP Stateless OpenPGP support.
Change-Id: I56acd993cb394dd8bc12a8da3cf4c78088adb61b
* sync_timezone_version() checks the current olson database
version from DateTime::TimeZone vs ngcp.timezone.version
and updates billing.contacts.timezone field with the new
names following the "links" (aliases)
Change-Id: Iacb552a9151ffb8eaaa40a16b530cbde0cc4b718
These commands are db-specific, and the constants one involves the
database credentials, so give both better names to make it clear these
are not general purpose commands.
Preserve backwards compatibility symlinks for external callers, or
user muscle memory, which this gets migrated away.
Change-Id: I3baae364e786ebbdc9e386dfc4f8c0bf54333cd1
Move perl code which actually modifies yml file to separate helper as
there is no sense to recreate it every call of 'ngcpcfg del'.
Change-Id: Iab9e023318cf9798bdb10d89b08dc2afe125c495
Move perl code which actually modifies yml file to separate helper as
there is no sense to recreate it every call of 'ngcpcfg set'.
Change-Id: I08b10186b1aa127d4a2b81ef36b234dfdd46fc8e
Introduce a list of checks related to connections:
* check that we don't have instance names duplicates
* prove an existence of a preferred for instnace host
* an instance to which instance gets connected exists
* a host to which instance gets connected exists
* interface via which instance gets connected is defined
Change-Id: I24f43b0fb24e308f571a88f30a72a9b6dd04b94d
We add support for YAML schemas, and hook it into the check command to
validate the sites.yml file.
Change-Id: Ic6ed43e36361d395b485230af4ec3cf7e77758bb
The configuration files specific to the ngcpcfg tool should not be
mixed with the site specific configuration, as that's rather confusing,
more so when the actual ngcpcfg configuration contains references to the
location of the ngcp-config dir itself, which makes it self-referential.
Change-Id: I93f59e2ce3441c2c315956f68e22e4b2e9c839ac
The factory_default files are not created anymore by the installer,
and the systems.cfg file is neither created by the installer nor
needed or used since commit 5e2037cf82.
Change-Id: I9c58021db307f23923b4cfee8a1862561dc09d3d
Path.is_relative() (as used in t/fixtures/programs.py) is a new feature
as of Python 3.9, see
https://docs.python.org/3.9/whatsnew/changelog.html?highlight=is_relative_to
and https://github.com/python/cpython/issues/81870
When running with an older python3 version, tests fail with:
| env = {}
|
| def prepare_conf(env={}):
| testenv = define_env(env)
| ngcpcfg_path = testenv["NGCPCFG"]
| > if not ngcpcfg_path.is_relative_to(CWD):
| E AttributeError: 'PosixPath' object has no attribute 'is_relative_to'
While python3-pytest depends on python3:any, let's keep the build
dependency slim, by build-depending on the python3-minimal package only.
Problem spotted while trying to debug the git safe.directory issue
in an outdated bullseye based container, providing python3 3.7.5-3.
Change-Id: Ib620a796a780817a81a51d791a766c950b1a541c
This new action concatenates the various configuration files and outputs
the result as YAML. This is useful because they have a determined
ordering, and include optional host specific files that might not be
obvious how to merge.
This will also be the foundation for verifying all the current host
settings against the cfg-schema.
Change-Id: I72a61193f74caf3b2f7a58a47eefad2ed46c973a
will provide a new instance_info variable with the all the content
defined at network.yml for the instance
removed intance_name since instance_info.name has the same value
Change-Id: I349d0b430b59280bc383d46d5ba6a61f5d1f9046
we need to produce different output for each instance defined
from the same source
* helper/instances-info, produces the needed output to feed
helper/tt2-process with the proper arguments to build
instances files. We inject ``instance_name`` with the
proper value to templates and INSTANCE_NAME to hooks
environment
* ${NGCPCTL_MAIN}/ngcpcfg.instances is where we define the
supported instance templates and where the output path is
* helper/tt2-process, add -r --replace <path:path> option
in order to allow generation of different output from
the same source
Change-Id: I067266b5226485ea0d6c3bc3436275c5553a8177
These have been around for enough time to leave admins room to switch to
the new alternatives. Time for cleanup.
Change-Id: I40a51c8107daf53a6d7fd24b5035bbc2aff77bb6
Normally it is necessary to press TAB multiple times, e.g:
> vim /etc/ngcp-conf<TAB>/con<TAB>f<TAB>...
For new NGCP users it is even longer.
In the same time we have a nice usability experience for ngcp-ppa,
where users are just pressing "ngcp-ppa<ENTER>1<ENTER>1<ENTER>".
Let's add the same concept here as the order of the main files is static:
> 1) /etc/ngcp-config/config.yml
> 2) /etc/ngcp-config/network.yml
> 3) /etc/ngcp-config/constants.yml
if I need to edit network.yml I will type:
> ngcpc<TAB> e<TAB><ENTER>2<ENTER>
or even:
> ngcpc<TAB> e<TAB>2<ENTER>
Change-Id: Id20fec8c931c15c73a73689a3f8b552a72ef11f7
When we invoke `ngcp-config <tab>` for the very first time in a bash
session, our shell completion doesn't work. Once `ngcpcfg <tab>` was
invoked, then the shell completion for ngcp-config works as well though.
This is caused by the fact, that bash loads the completion file(s)
on-demand, and we register the completion for `ngcp-config` inside our
`ngcpcfg` completion file.
If we provide /usr/share/bash-completion/completions/ngcp-config as
symlink pointing to /usr/share/bash-completion/completions/ngcpcfg, then
the completion for `ngcp-config` also works on first invocation of both
ngcpcfg *and* ngcp-config.
Change-Id: I99ce535b0be6ff47c0c72ab158cc943b1a1962e3
Sipwise Jenkins Builder
Guillem Jover
Kirill Solomko
Michael Prokop
Mykola Malkov
dzenichev
ngcp-config
Alexander Lutay