egeoffrey-sdk v1.1 released
A significant change has taken place in the new egeoffrey-sdk version 1.1, even if completely transparent for the end user.
In all previous version of the SDK, modules were expecting to find the entire configuration pinned (retained) on the message bus. This was perfectly fine for a local gateway but was causing a few issues to the Cloud Gateway (when in use) because the whole configuration was supposed to be kept in memory and data of house no more in use would have been kept there forever, making the service not really scalable. Additionally, there was too much complexity for
controller/configto reconcile the local configuration with the one already pushed.
With version 1.1, there is an option for configuration to be no more pinned on the gateway but
controller/configwill send it over to every module requesting it. This is once again completely transparent for the user since the underlying SDK will take care of handling the entire process.
The behaviour is controller by the new global variable
EGEOFFREY_GATEWAY_VERSION(which superceed the static
API_VERSION). This gateway protocol version is used to allow modules to communicate each other in the same way. If set to "1", the old communication mechanism is used (configuration and messages retained in the bus), if set to "2", the new one is used.
Technical details about the design of this capability and the changes are available at https://github.com/egeoffrey/egeoffrey-sdk/issues/11.
To ensure backwards compatibility, default gateway protocol version will be v1 for existing deployments, v2 for the new ones. Of course all the modules connecting to the same gateway should be configured with the same protocol for communication to take place, packages must be built against SDK >= v1.1 (rebuild process is underway),
egeoffrey-controllermust be version >= 1.4.
An updated version of
egeoffrey-gui(v1.4) is also about to be released to support this capability. Upon login, the user can now select between v1 and v2 gateway protocol version.
Once again, nothing changes for both end users and developers since those changes are handled entirely by and within the SDK.
A couple of small bugs have been fixed as well, which were causing a huge CPU consumption when a package was started, which was particularly critical when many packages are started altogether (like when running
To leverage this capability, update your eGeoffrey deployment by running:
egeoffrey-cli updateto update all the packages with those built against SDK v1.1
egeoffrey-cli set_env EGEOFFREY_GATEWAY_VERSION 2to set gateway protocol version to v2
egeoffrey-cli restartto restart eGeoffrey and apply the changes
egeoffrey-cli logs_tailto review everything is working correctly and that the packages are using v2 gateway protocol under "Environment settings"
All eGeoffrey packages have been now upgraded to use SDK v1.1 (see above for instructions on how to update).
egeoffrey-clihas been also updated to use gateway protocol v2 when using the Cloud Gateway, v1 for local deployments.
For the few users using collections packages (which is not the default), please note package
egeoffrey-notification-chromecasthave been moved from
egeoffrey-collection-coredue to conflicts with the dependencies so
notification/chromecastshould be moved by manually editing the configuration file.
What's next? Support for Python3 of course!