Store Orion data via Cygnus - fiware

I'm using Orion (2.2.0) and Cygnus (1.9.0) to store data in MySQL. It worked using attrsFormat: 'legacy' in the subscription payload.
My question is this: could I install the new version of Cygnus to without usage of attrsFormat = legacy?
Thanks a lot
Pasquale

Cygnus support for NGSIv2 (which would avoid the usage of "attrsFormat": "legacy") will be available in the next version of Cygnus (1.18.0).
In fact, the PR implementing the functionality has been merged this afternoon :), so if you are in a hurry, you can use Cygnus from master branch (:latest tag if you grab it from dockerhub) and test it. Any feedback is welcome!

Related

About the version of each component in release 7.5 of FIWARE

Currently I am going to verify FIWARE.
Release 7.5 was announced, but there are components whose version is lower in the core component.
cygnus
Release7.4 : version2.0.0
Release7.5 : version1.9.0
sth-comet
Release7.4 : version2.4.0
Release7.5 : version2.3.0
I want to know the reason why the version of the component is going down.
With regards to Cygnus, the short history is that FIWARE wrongly used "Cygnus" as software name in FIWARE 7.4 for a component that in FIWARE 7.5 was renamed to "Draco". Cygnus stills existing of course but release 2.0.0 has not come yet. Last Cygnus available version in the moment of writting this is Cygnus 1.10.0, to be included as part of FIWARE release 7.5.1.
With regards to STH, probably FIWARE releases are still using this fork as reference, when it should be using the original one. Note the original repository is the most updated and the one which uses version 2.4.0 at the present moment.
#fgalan is correct, some elements were inconsistently labelled in release 7.4 and 7.5. A patch release has finally corrected this.
As of 7.5.1, the following versions are correct:
cygnus 1.10.0
sth-comet 2.5.0
draco FIWARE_7.5
The new draco generic enabler had been initially released as cygnus 2.x which was incorrect.

Integration Wirecloud with IDM Keyrock

I'm trying to replicate the installation guide to integrate Wirecloud 1.0.1 with the latest version of IDM Keyrock.
I'd like to understand if the guide in the documentation is valid again for this version of WC.
Thanks in advance for the answers.
As you suspected, the linked documentation is not valid for WireCloud v1.0.1, you linked to the latest branch of the documentation, that is the documentation for the development version of WireCloud.
The documentation on how to configure WireCloud v1.0.1 to use the IdM can be found in this link.
We know that is not clear that the latest branch is the one used for document the development version, but Read The Docs does not allow us to rename (or we do not know yet how to do it) this branch using a more meaningful name (e.g. develop). The default branch is stable (pointing to the documentation of the latest stable version of WireCloud) but it has proben to not be enough. We have created a ticket for improving this aspect.

How do I create the fiware-orion deb package?

My project used a Raspberry Pi3 with Debian OS and in it I execute the fiware-orion. I have compiled the Orion source code for the architecture arm64 (aarch64). Now I need to create the fiware-orion deb package.
The documentation only explains how to build the rpm package with rpm-build.
I did a search and that's all I found:
Fiware Orion context Broker on Ubuntu
Is it possible to create the fiware-orion deb package?
Thank you for your help!
I think it should be possible. However, as far as I know, nobody has do that yet :)
As said in the question post you cite:
FIWARE Orion is a open source community driver project, so if you want to contribute in that sense [to create a .deb package], don't hesitate to propose the needed changes to the repository (as pull requests).
This document seems to be a good starting point.

How to add a new Sink for Cygnus - Fiware?

I have installed Cygnus and I have it properly running with MYSQL. I would like to send the data which arrive to Cygnus through the notifications from Orion Context Broker, to a REST server.
I need to create a new Sink that processes the data that come from Orion, create the POST requests and run them. In order to do this, I have to create new Java files and I have to put these files in (according to "Adding new sinks development guide"):
fiware-connectors/flume/src/main/java/es/tid/fiware/fiwareconnectors/cygnus/sinks
and:
fiware-connectors/flume/src/main/java/es/tid/fiware/fiwareconnectors/cygnus/backends/<my_backend_classes>/
But I can not find these places. I installed Cygnus through the yum install command, so I do not know how to locate the places where I have to place these new java files.
Could you help me with this? Thanks in advance
Installing Cygnus by RPM will not install the sources. For that, you have to clone the Github repo (the git tool must be installed as well):
$ git clone https://github.com/telefonicaid/fiware-cygnus.git
That will clone the master branch, which is currently synchronized with the release 0.7.1.
Then, once you have added your new sink, you will have to build and install Cygnus from sources (your altered ones) as explained here.

How to download the last version of orion pep proxy?

I am installing the orion pep proxy but I think that I have not downloaded the correct version and I am having errors when using a local instance of KeyRock to validate and generate tokens.
I know that the latest version is 0.6.0 but i do not know how to complete the following command to obtain the last version:
./create-rpm.sh
Which is the difference between version and number?
Could you help me with this?
Thanks in advance
The idea of having those two numbers is to help the Release Engineer in debugging their releases, or changes they make to the packagin process itself. The "release number" indicates the version of the package, not the one of the software. E.g.: if you are packaging version 0.6.0, you usually will use release number 1; but, if you find out that you want to add some dependencies for the spec, or you want to update the package to change part of the packaging process, for example, and you try to replace the installed version with a new one, the system will claim the package is up-to-date; in that case, you increase the release number (as the software itself, that is, the Node.js files that constitute the PEP Proxy) hasn't change.
Hope this clarifies the behavior.