Custom Key/value pairs for targets

[SebastianSchildt]

Hi,

We are using Hawkbit with a custom backend (an Appstore), and thus we have more data to manage regarding targets then Hawkbit needs by itself. Where possible, we would like to prevent having some "shadow database" mirroring and synchronising with Hawkbits state, but instead put relevant information into Hawkbit, so we have only one central repository of information.

To that end it would be tremendously helpful, if Targets in Hawkbit could be extended with arbitrary custom key/value pairs.

We found an 80% solution with the PUT /{tenant}/controller/v1/{controllerid}/configDatacall in the DDI API, however these fields are under control of the device. What we need (and I guess would be useful for lots of other applications as well), is a similar mehtod, but where the fields are under control of the backend (and can not be changed by the target itself)

@fayvaz @rai20 @laverman I think this would make our KUKSA appstore architecture cleaner and more secure

[sbabic]

Hi Sebastian,

On 05/09/2018 10:58, SebastianSchildt wrote: Hi, We are using Hawkbit with a custom backend (an Appstore), and thus we have more data to manage regarding targets then Hawkbit needs by itself. Where possible, we would like to prevent having some "shadow database" mirroring and synchronising with Hawkbits state, but instead put relevant information into Hawkbit, so we have only one central repository of information. To that end it would be tremendously helpful, if Targets in Hawkbit could be extended with arbitrary custom key/value pairs. We found an 80% solution with the |PUT /{tenant}/controller/v1/{controllerid}/configData|call in the DDI API, however these fields are under control of the device. What we need (and I guess would be useful for lots of other applications as well), is a similar mehtod, but where the fields are under control of the backend (and can not be changed by the target itself)

Anyway, this feature is actively used to get information from devices, even if they are not known at the time the device was added to Hawkbit. For example, a defected device is replaced with a new one, it could still have the old id but it has new MAC, serial number and hardware revision number - and much more. Key/values from devices should not be rejected - you need maybe to add a mask for each key to set if value can be overridden. Best regards, Stefano Babic

…

@fayvaz <https://github.com/fayvaz> @rai20 <https://github.com/rai20> @laverman <https://github.com/laverman> I think this would make our KUKSA appstore architecture cleaner and more secure

-- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================

[SebastianSchildt]

Hello Stefano,

yes, I understand the feature makes sense as it is now. To be clear: I did not propose to change the behavior as it is now, but rather complement it with something similar, which is not under the control of the device itself.

This may either be a completely different set auf attributes/annotations that is not even visible on the DDI interface, or as you suggested some masking/flagging of "device-readonly" in the existing attributes. However, on a first look it seems more complicated because at the moment attributes are free, if I see it correctly: The device can report whatever it wants. If there would be some access limitations, where do they need to come from, and does it mean all "allowed" attributes for a device must be provisioned somewhere? What would happen if a device tries to add an attributes where the mask/access rights are not defined? That would not be very transparent on the device side.

[sbabic]

On 07/09/2018 09:19, SebastianSchildt wrote: Hello Stefano, yes, I understand the feature makes sense as it is now. To be clear: I did not propose to change the behavior as it is now, but rather complement it with something similar, which is not under the control of the device itself.

Fine with me because it is still compatible with devices in field.

This may either be a completely different set auf attributes/annotations that is not even visible on the DDI interface,

ok

or as you suggested some masking/flagging of "device-readonly" in the existing attributes. However, on a first look it seems more complicated because at the moment attributes are free, if I see it correctly: The device can report whatever it wants.

Right.

If there would be some access limitations, where do they need to come from, and does it mean all "allowed" attributes for a device must be provisioned somewhere? What would happen if a device tries to add an attributes where the mask/access rights are not defined? That would not be very transparent on the device side.

Agree. Best regards, Stefano

…

-- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================