Most plugin-related files are available in the xivo-provd-plugins repository. Following examples are relative to the repository directory tree. Any modifications should be preceeded by a git pull.
Updating a Plugin¶
We will be using the xivo-cisco-spa plugins family as an example on this page
There is one directory per family. Here is the directory structure for
plugins/xivo-cisco-spa/ +-- model_name_xxx +-- model_name_xxx +-- common +-- build.py
Every plugin has a folder called
common which regoups common ressources for each model.
Every model has its own folder with its version number.
After modifying a plugin, you must increment the version number.
You can modifiy the file
plugin-info to change the version number:
plugins/xivo-cisco-spa/ +-- model_name_xxx +-- plugin-info
If ever you modify the folder
common, you must increment the version number of all the models.
Use Case: Update Firmwares for a given plugin¶
Let us suppose we want to update firmwares for xivo-snom from 18.104.22.168 to 22.214.171.124 5. Here are the steps to follow :
- Copy folder plugins/xivo-snom/126.96.36.199 to plugins/xivo-snom/188.8.131.52.5
- Update VERSION number in plugins/xivo-snom/184.108.40.206.5/entry.py
- Update VERSION number in plugins/xivo-snom/220.127.116.11.5/plugin-info
- Download new firmwares (.bin files from snom website)
- Update VERSION number and URIs in plugins/xivo-snom/18.104.22.168.5/pkgs/pkgs.db (with uris of downloaded files from snom website)
- Update sizes and sha1sums in plugins/xivo-snom/22.214.171.124.5/pkgs/pkgs.db (using helper script xivo-tools/dev-tools/check_fw)
- Update plugins/xivo-snom/build.py (duplicate and update section 126.96.36.199 > 188.8.131.52.5)
Test your changes¶
You have three different methods to test your changes on your development machine.
Always increase plugin version (easiest)¶
If the production version is 0.4, change the plugin version to 0.4.01, make your changes and upload to testing (see below).
Next modification will change the plugin version to 0.4.02, etc. When you are finished making changes, change the version to 0.5 and upload one last time.
Edit directly on Wazo¶
Edit the files in
To apply your changes, go in
xivo-provd-cli and run:
Disable plugin caching¶
/etc/xivo/provd/provd.conf and add the line:
/var/cache/xivo-provd and restart provd.
Make your changes in provd-plugins, update the plugin version to the new one and upload to testing (see below). Now, every time you uninstall/install the plugin, the new plugin will be fetched from testing, instead of being cached, even without changing the version.
Uploading to testing¶
Before updating a plugin, it must be passed through the testing phase. Once it has been approved it can be uploaded to the production server
Before uploading a plugin in the testing provd repository, make sure to git pull the xivo-provd-plugins git repository.
To upload the modified plugin in the testing repo on provd.wazo.community, you can execute the following command:
$ make upload
Afterwards, in the web-interface, you must modify the URL in sectionto:
You can then update the list of plugins and check the version number for the plugin that you modified. Don’t forget to install the plugin to test it.
Uploading to stable¶
Once checked, you must synchronize the plugin from testing to stable. If applicable, you should also update the archive repo.
To download the stable and archive plugins:
$ make download-stable $ make download-archive
Go to the plugins/_build directory and delete the plugins that are going to be updated. Note that if you are not updating a plugin but you are instead removing it “once and for all”, you should instead move it to the archive directory:
$ rm -fi stable/xivo-cisco-spa*
Copy the files from the directory testing to stable:
$ cp testing/xivo-cisco-spa* stable
Go back to the plugins directory and upload the files to the stable and archive repo:
$ make upload-stable $ make upload-archive
The file are now up to date and you can test by putting back the stable url in the web-interface’s configuration: