P44-DSB-X not compatible wih dSS V 1.11.0 ?
72 views
Skip to first unread message
Benno Lange
Mar 16, 2016, 1:16:59 PM3/16/16
to plan44_vdcd
Hi,
we upgraded our dSS to the new version 1.11.0 and the previously installed P44-DSB-X disappeared and is no more recognized/found !
We even created a new SD from the downloadable image but the P44-DSB-X is still not seen ?!?
It seems that there is an incompatible change somewhere ?!?
Will there be a new image in the foreseeable future ?
Or do we have to buy a commercial version (just for testing..) :-(
Regards
Benno
we upgraded our dSS to the new version 1.11.0 and the previously installed P44-DSB-X disappeared and is no more recognized/found !
We even created a new SD from the downloadable image but the P44-DSB-X is still not seen ?!?
It seems that there is an incompatible change somewhere ?!?
Will there be a new image in the foreseeable future ?
Or do we have to buy a commercial version (just for testing..) :-(
Regards
Benno
thomas r. hollensteiner
Mar 17, 2016, 8:12:02 AM3/17/16
to plan44_vdcd
hello,
i had the same issue that the VDSM was not recognized anymore - i did run the p44 but because of better performance i run the VDSM+VDCD on an intel platform - so there shouldn't be a difference
i hole house went down because of the upgrade to 1.11 and all i got on support was to post to the developer forum - but after some hours - trying i could get it back to work with the DSS
see my post in the list and my own found solution...
error description:
solution:
so maybe you just need to modify your start cmd for the VDSM as well,..
best regards
holli
Lukas Zeller
Mar 21, 2016, 12:10:05 PM3/21/16
to thomas r. hollensteiner, plan44_vdcd
Hello,
> On 17.03.2016, at 13:12, thomas r. hollensteiner <ho...@holli.at> wrote:
>
> i had the same issue that the VDSM was not recognized anymore - i did run the p44 but because of better performance i run the VDSM+VDCD on an intel platform - so there shouldn't be a difference
But there is ;-) On a P44-DSB, the vdsm is compiled without any Bonjour/Avahi code, because the vdcd is doing all discovery/advertising related tasks.
The reason for this is that the P44-DSB is already prepared for automatic migration to the central dSS-hosted vdsm, which is already active in testing builds and will become active in a near future dSS release. So the vdcd can detect the presence of that "master" vdsm and will shut down the local vdsm, and will also switch to advertising itself (type _ds_vdc._tcp) instead of the vdsm (_ds_vdsm._tcp).
Additionally, using avahi-client, dbus and avahi-daemon is too expensive for the small embedded platforms some P44-DSB run on. Instead, as long as the vdcd is the only process using Avahi, it can be built to directly using the much simpler avahi-core code. That's the other reason for having all advertising code in the vdcd.
But your standard builds of vdcd and vdsm on Intel both use avahi-client, connecting via dbus to avahi-daemon. So, in your configuration, the vdsm *is* advertising itself, and it *is* important to have the related command line switches correct, including the new ones: -u,-n-d-,-r and -M.
The change in dSS 1.11 is that it now checks some additional TXT records in the vdsm advertisement. In particular, only vdsms advertising themselves as "collectable" will be connected, that's why you need -u now.
If you are interested in the details of vdsm and vdc discovery, have a look at chapter 3 in http://developer.digitalstrom.org/Architecture/vDC-API.pdf
> [...] so maybe you just need to modify your start cmd for the VDSM as well,..
Not on the P44-DSB, for the reasons above.
Note however that the problem reported by Benno is something entirely different, which could have affected (but luckily didn't!) your vdsm even when correctly started with -u:
The dSS (more precisely, the ds485p) uses a white/blacklist to avoid connecting the wrong vdsms (e.g. if you have multiple dSS in a single LAN). In a normal single-dSS environment, the mechanism should be entirely automatic - unfortunately there's a bug in dSS 1.11 which sometimes sets a "do not connect" flag on a vdsm.
That's a problem which can currently only be solved with root access to the dSS - which customers, including me, don't have - so dS support needs to fix that when it happens, until a dSS bugfix is out.
Best Regards,
Lukas
> On 17.03.2016, at 13:12, thomas r. hollensteiner <ho...@holli.at> wrote:
>
> i had the same issue that the VDSM was not recognized anymore - i did run the p44 but because of better performance i run the VDSM+VDCD on an intel platform - so there shouldn't be a difference
The reason for this is that the P44-DSB is already prepared for automatic migration to the central dSS-hosted vdsm, which is already active in testing builds and will become active in a near future dSS release. So the vdcd can detect the presence of that "master" vdsm and will shut down the local vdsm, and will also switch to advertising itself (type _ds_vdc._tcp) instead of the vdsm (_ds_vdsm._tcp).
Additionally, using avahi-client, dbus and avahi-daemon is too expensive for the small embedded platforms some P44-DSB run on. Instead, as long as the vdcd is the only process using Avahi, it can be built to directly using the much simpler avahi-core code. That's the other reason for having all advertising code in the vdcd.
But your standard builds of vdcd and vdsm on Intel both use avahi-client, connecting via dbus to avahi-daemon. So, in your configuration, the vdsm *is* advertising itself, and it *is* important to have the related command line switches correct, including the new ones: -u,-n-d-,-r and -M.
The change in dSS 1.11 is that it now checks some additional TXT records in the vdsm advertisement. In particular, only vdsms advertising themselves as "collectable" will be connected, that's why you need -u now.
If you are interested in the details of vdsm and vdc discovery, have a look at chapter 3 in http://developer.digitalstrom.org/Architecture/vDC-API.pdf
> [...] so maybe you just need to modify your start cmd for the VDSM as well,..
Not on the P44-DSB, for the reasons above.
Note however that the problem reported by Benno is something entirely different, which could have affected (but luckily didn't!) your vdsm even when correctly started with -u:
The dSS (more precisely, the ds485p) uses a white/blacklist to avoid connecting the wrong vdsms (e.g. if you have multiple dSS in a single LAN). In a normal single-dSS environment, the mechanism should be entirely automatic - unfortunately there's a bug in dSS 1.11 which sometimes sets a "do not connect" flag on a vdsm.
That's a problem which can currently only be solved with root access to the dSS - which customers, including me, don't have - so dS support needs to fix that when it happens, until a dSS bugfix is out.
Best Regards,
Lukas
Reply all
Reply to author
Forward
0 new messages