How to query all services (groups) from an iotagent

[ohcibi]

We have a hard time understanding the meaning of the different hierarchy levels provided by the iotagent. There is the fiware-service, the fiware-servicepath and underneath it is a bunch of services that in turn have a bunch of devices associated.

Now we understood how to query for all devices and all services underneath a given fiware-service and fiware-servicepath. We also understood how to query for all fiware-servicepaths given a certain fiware-service. But how to query for all those "top level" fiware-services?

Our goal is to create a device management user interface which enables an end user to provision and unprovision the devices he is managing. Maybe we have a misconception of the fiware-service here but since one can add such services with a certain POST request our expectation would be that we can somehow query for all those services. What are we missing?

[fgalan]

I think it should be better to post this question in StackOverflow (http://www.stackoverflow.com), given it is more related with a functionality question that with an actual issue in the software (bug, etc.).

Thus, could you post your question (basically, a copy-paste) in SOF, please? Please use the "fiware" label.

Once done, please add a comment with a link to the question in SOF in this issue, then close the issue.

Thanks!

[ohcibi]

https://stackoverflow.com/questions/60436577/how-to-query-all-services-groups-from-an-iotagent

I didn't closed the issue because I consider this at least a missing piece of documentation. So for that regard the issue should remain open until that is added to the docs.

[fgalan]

https://stackoverflow.com/questions/60436577/how-to-query-all-services-groups-from-an-iotagent

I didn't closed the issue because I consider this at least a missing piece of documentation. So for that regard the issue should remain open until that is added to the docs.

Thanks for the feedback!

Which piece of documentation are you exactly missing? Please, provide some more detail so we can manage the suggested documentation improvement.

CC: @jason-fox (as he has been involved in the response to your question in SOF)

[ohcibi]

Which piece of documentation are you exactly missing

The piece that tells that fiware services are meant to be hardcoded on a per iotagent instance basis and a reasoning (including examples) for that.

Without any background information the fiware servicepath, subservice path and the service itself seem like arbitrary hierarchy levels that can be used for whatever purpose. The documentation also reads like that as for all 3 levels it provides only generic examples. There is no explicit note telling that the 'servicepath' level is a special one as it is meant to be hardcoded.

The only thing that suggests that the 'servicepath' level is a special one is the fact that the documentation misses a GET /servicepaths or thelike. As far as I understood the implementation and documentation however the decision to not have this getter, although it could be easily added as all information necessary is inside the mongodb, seems like pretty arbitrary.

But again, I might have totally misunderstood what a 'servicepath' (or the hierarchy including the other levels in general) is actually good for or maybe I didnt got the purpose of this specific implementation but so far I can only think of specific use cases where one would want to restrict the management of hierarchy levels but nothing that is generic for any type of system.

[fgalan]

The piece that tells that fiware services are meant to be hardcoded on a per iotagent instance basis and a reasoning (including examples) for that.

Could you provide the link to the document in which you miss that piece, please? (we have a lot of documentation out there and sometimes is difficult to know to which one somebody refers :)

Thanks!

[ohcibi]

Well the document we’ve been looking into the most is https://fiware-tutorials.readthedocs.io/en/latest/iot-agent/index.html

But we read a lot of docs and as far as We understood service and service paths are part of the core concepts of fiware so the problem is everywhere throughout the docs. The point here is that the fact that one cannot query all the services in general simply makes no sense by what is explained about those. Plus it is not mentioned at all that those cannot be queried. I guess there has been a reasoning about this but nobody added it to the docs. The example with the city that is used in the link I posted (in the paragraph that tries to explain the two terms service and service path) is in fact a good example where an app would need to list all existing services, hence querying them. So the example rather confirms that this really is a missing feature/bug.

The responses at stackoverflow don’t help because they describe specific use cases. Yes in some use cases one might want to simply not provide GET /services but I don’t see at all how that fits into a generic concept. Again I think it is a bug rather.

_{Sent with GitHawk}

[perrolobo]

Service and ServicePath are OTT concepts to the whole platform. I agree with you that they should be managed. They could be managed E2E by Apps/Clients (in basic scenarios), or by some kind of central manager like: https://thinking-cities.readthedocs.io/en/latest/management_api/index.html where you can find the requested operations to retrieve the services and subservices: https://orchestrator2.docs.apiary.io/# So it's not a bug, it's just a matter of separation of responsibility in a microservice architecture. Remark that the Orchestrator service has dependencies with Keystone as related IDM. Best.

…

On Fri, Jun 5, 2020 at 9:06 AM Tobias Witt ***@***.***> wrote: Well the document we’ve been looking into the most is https://fiware-tutorials.readthedocs.io/en/latest/iot-agent/index.html But we read a lot of docs and as far as We understood service and service paths are part of the core concepts of fiware so the problem is everywhere throughout the docs. The point here is that the fact that one cannot query all the services in general simply makes no sense by what is explained about those. Plus it is not mentioned at all that those cannot be queried. I guess there has been a reasoning about this but nobody added it to the docs. The example with the city that is used in the link I posted (in the paragraph that tries to explain the two terms service and service path) is in fact a good example where an app would need to list all existing services, hence querying them. So the example rather confirms that this really is a missing feature/bug. The responses at stackoverflow don’t help because they describe specific use cases. Yes in some use cases one might want to simply not provide GET /services but I don’t see at all how that fits into a generic concept. Again I think it is a bug rather. Sent with GitHawk <http://githawk.com> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#417 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG3WUVUD2LOSU3T7FLRGCDRVCKRFANCNFSM4KXC7JNQ> .

-- - Marcos -

[perrolobo]

BTW. Services/Groups in IoTAgent has nothing to do with the concepts of Service and ServicePath (multitnancy concepts). Just an unfortunate collision in naming which is being solved lately. For listing Groups in the IoTAgent (aka Services but not FIWARE-Services) you have this api call: https://github.com/telefonicaid/iotagent-node-lib/blob/master/doc/api.md#get-iotservices Best.

…

On Fri, Jun 5, 2020 at 10:05 AM Marcos Reyes ***@***.***> wrote: Service and Subservice are OTT concepts to the whole platform. I agree with you that they should be managed. They could be managed E2E by Apps/Clients (in basic scenarios), or by some kind of central manager like: https://thinking-cities.readthedocs.io/en/latest/management_api/index.html where you can find the requested operations to retrieve the services and subservices: https://orchestrator2.docs.apiary.io/# So it's not a bug, it's just a matter of separation of responsibility in a microservice architecture. Remark that the Orchestrator service has dependencies with Keystone as related IDM. Best. On Fri, Jun 5, 2020 at 9:06 AM Tobias Witt ***@***.***> wrote: > Well the document we’ve been looking into the most is > https://fiware-tutorials.readthedocs.io/en/latest/iot-agent/index.html > > But we read a lot of docs and as far as We understood service and service > paths are part of the core concepts of fiware so the problem is everywhere > throughout the docs. The point here is that the fact that one cannot query > all the services in general simply makes no sense by what is explained > about those. Plus it is not mentioned at all that those cannot be queried. > I guess there has been a reasoning about this but nobody added it to the > docs. The example with the city that is used in the link I posted (in the > paragraph that tries to explain the two terms service and service path) is > in fact a good example where an app would need to list all existing > services, hence querying them. So the example rather confirms that this > really is a missing feature/bug. > > The responses at stackoverflow don’t help because they describe specific > use cases. Yes in some use cases one might want to simply not provide GET > /services but I don’t see at all how that fits into a generic concept. > Again I think it is a bug rather. > > Sent with GitHawk <http://githawk.com> > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#417 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAG3WUVUD2LOSU3T7FLRGCDRVCKRFANCNFSM4KXC7JNQ> > . > -- - Marcos -

-- - Marcos -

[fgalan]

Well the document we’ve been looking into the most is https://fiware-tutorials.readthedocs.io/en/latest/iot-agent/index.html

But we read a lot of docs and as far as We understood service and service paths are part of the core concepts of fiware so the problem is everywhere throughout the docs. The point here is that the fact that one cannot query all the services in general simply makes no sense by what is explained about those. Plus it is not mentioned at all that those cannot be queried. I guess there has been a reasoning about this but nobody added it to the docs. The example with the city that is used in the link I posted (in the paragraph that tries to explain the two terms service and service path) is in fact a good example where an app would need to list all existing services, hence querying them. So the example rather confirms that this really is a missing feature/bug.

The responses at stackoverflow don’t help because they describe specific use cases. Yes in some use cases one might want to simply not provide GET /services but I don’t see at all how that fits into a generic concept. Again I think it is a bug rather.

With regards to https://fiware-tutorials.readthedocs.io/en/latest/iot-agent/index.html and SOF question, I'd suggest to contact with its author (@jason-fox ) so he can take into account your feedback. I think the master git repository associated to that link is this one: https://github.com/FIWARE/tutorials.Step-by-Step

With regards to IOTA-UL documentation, if you find some specific document to be fixed in this repository, please tell us about it.

As @mrutid says there is an unfortunate collision of terms. However, we are in the process of fixing it (see telefonicaid/iotagent-node-lib#780) using a new term (configGroups) in IOTAs, preserving "service" for the multi-tenancy concept.