Open jarhodes314 opened 7 months ago
I've been looking at making the logic work for tedge cert create
and have hit a bit of an issue. In the case of the built-in bridge, we want the device certificate to be owned by tedge
, but in the mosquitto bridge, the device certificate should instead be owned by mosquitto
. At the moment, the configuration for the bridge is c8y.bridge.built_in
, implying that this setting is per-cloud, but since only one of mosquitto or the mapper should be able to read the cert/key at a time, it isn't actually possible to have this setting work differently for different clouds.
@didier-wenzek @reubenmiller do you think it's reasonable to change the setting to bridge.built_in
(or some other name), or do you have other suggestions as to how to resolve this?
I've been looking at making the logic work for
tedge cert create
and have hit a bit of an issue. In the case of the built-in bridge, we want the device certificate to be owned bytedge
, but in the mosquitto bridge, the device certificate should instead be owned bymosquitto
. At the moment, the configuration for the bridge isc8y.bridge.built_in
, implying that this setting is per-cloud, but since only one of mosquitto or the mapper should be able to read the cert/key at a time, it isn't actually possible to have this setting work differently for different clouds.@didier-wenzek @reubenmiller do you think it's reasonable to change the setting to
bridge.built_in
(or some other name), or do you have other suggestions as to how to resolve this?
I see different alternatives - none really convincing
tedge cert create
checks the c8y.bridge.built_in
setting (or better as you propose a generic bridge.built_in
setting) to assign the appropriate owner to the private key, One might improve the user experience if tedge cert create
can also be used to re-assign the proper owner if the setting for bridge.built_in
is changed.
In #2716, support was added to the mapper for a built-in Cumulocity bridge, to replace the mosquitto-based bridge.
Here is a list of follow up tasks that need completing before the feature is fully complete and ready to be enabled for users:
c8y/s/uc/my-template-id
. There were no issues with subscribing to the template topic before the template existed, as I hoped would be the case. Deleting the template in the UI didn't stop Cumulocity from sending the template messages, although this is clearly a Cumulocity behaviour, and not within our control, even if it does seem a bit weird.tedge connect c8y
tedge-mapper-c8y
service nametedge config list
andtedge config list --doc