Designing topics to ensure defined behaviour

[phro-sudo]

Hello,

when I design the topics for my zenoh system, I am tempted to only think about the system in its current state.

Thinking about changes in implementation which might only be deployed to some of the clients in the system and the system functionality changing as a whole, I am not sure how to design my topics to ensure "defined behaviour" across all my clients.

In this case, by "defined behaviour" I mean that for a command sent into the system, the sender either knows:

• The command has been executed successfully and gets response data or
• The command has not been executed and gets an error code

The question now is: Can Zenoh cope with changing topics so I can use the topic string to determine which command I want to run or do I have to define a generic topic where the command is only determined by the data payload.

[gabrik]

Hi @phro-sudo,

We had a very similar "issue" when working on Eclipse fog05, in that case, we wanted to define the desired state of the system, similar to sending a command, like: Instantiate that Container on that node and then checking the actual state of the system to verify if the command was executed successfully or not.

You can find more information here, in chapter III section B.

The idea behind that is that your application works in a reconciliation loop, thus it gets what the system status should be and acts to make it actual. This is actually being used also in Kubernetes

Therefore, you can imagine to arrange your Key Expression tree in something like this:

Let's say now you want to turn lamp0 of the patio on, what you should do it do put on myapp/desired/lights/patio/lamp0 with value {"status": "on", "color": "FFFFFF", "brightness":0.5} the application upon receiving this publication will know that it has to turn on the lamp with the specified parameters, and once it is done, or if there was an error will do a put on myapp/actual/lights/patio/lamp0.

So, if for instance, everything was right it is going to store the value {"status": "on", "color": "FFFFFF", "brightness":0.5} in the actual state.

Please let me know if this answers your question, or if you need more details.

[phro-sudo]

Hi @gabrik,

Thanks for you response. That is a really nice idea.

But it only answers a part of what i am searching for. In your paper you have defined the path like:
system_id/node_id/typeofresource/id_of_resource/type_of_subresource/if_od_subresource/ with the data as a parameter.

Now my question is what happens when:

• I have a sub_sub_resource that gets added two years into the project and I do not know the exact type or function of it now and can not update all nodes with this new code.
• When I now set the desired state, how do I know that that node even has the capability to work on this request? (Do I have to ask for the actual state first and see if it exists?)

Thank you in advance :)

[gabrik]

Hi @phro-sudo,

Now my question is what happens when:

* I have a sub_sub_resource that gets added two years into the project and I do not know the exact type or function of it now and can not update all nodes with this new code.

In that case, you may need to add versioning to your resources, similar to what happens in gRPC or REST APIs.
Add this version metadata to the data you are publishing, and that metadata of course has to be understood also by the "legacy" part of your system.
Also if your sub_sub_resources appends to your current KE structure, like: system_id/node_id/typeofresource/id_of_resource/type_of_subresource/if_od_subresource/type_of_sub_sub_resource/id_of_sub_sub_resource

The "legacy node may have subscribers like: system_id/node_id/typeofresource/id_of_resource/type_of_subresource/*, thus they will not be notified by the new resources.

* When I now set the desired state, how do I know that that node even has the capability to work on this request? (Do I have to ask for the actual state first and see if it exists?)

That's an option, or you can design your application to have a queriable that provides the type of the supported resource (along with they KE if needed)

In general, for the future evolution of a system, I would prefer to version the KE tree, so that if you are asking for new resources you are "forced" to use the "new" KE tree.
Something like: system_id/node_id/api_version/typeofresource/id_of_resource/type_of_subresource/if_od_subresource

In any case, the key expression tree design is a very important step and it should try to map your application information model.

I hope this clarifies a bit.