Normally these ServiceTestSpecification relationships should have been translated (for me anyway) into ServiceTest relationships in the data model but it seems that these are missing from the API...
Original Message:
Sent: Nov 20, 2024 05:30
From: Ján Krištof
Subject: TMF653 missing ServiceTestRelationship
Hi Frederic,
I'm just browsing TMF653 version 4.2.0 and resource model for ServiceTestSpecification, what about these fields?
serviceTestSpecRelationship - A list of service test spec relationships (ServiceTestSpecRelationship [*]). A list of service test specifications related to this specification e.g. dependency, substitution.
entitySpecRelationship - A list of entity specification relationships (EntitySpecificationRelationship [*]). Relationship to another specification.
Edit:
Sorry, I missunderstood yours question because of my poor english and careless reading. This already you knows.
BR,
Jan
------------------------------
Ján Krištof
T-Mobile Czech & Slovak Telekom, a.s.
Original Message:
Sent: Nov 20, 2024 04:57
From: Frederic Thise
Subject: TMF653 missing ServiceTestRelationship
Hi Jan,
Indeed, for me the CFS ServiceTest will contain the collection of RFS ServiceTests "as is" and potentially some "aggregated/deduced" information as testMeasure. The state of the CFS ServiceTest will also be inferred from the RFS ServiceTest states.
What we are missing is the "collection part" property...
Best regards,
------------------------------
Frederic Thise
Proximus SA
Original Message:
Sent: Nov 20, 2024 03:41
From: Ján Krištof
Subject: TMF653 missing ServiceTestRelationship
Hi Frederic,
We are in a similar situation here. We are investigating the TMF653 API and its guide on how to use it in our Service Assurance solution. I share your view that a service test should be composed of resource tests using the CFS - RFS - Resource relationship. In this case, when you start a service test for a CFS, you can access the service inventory to determine which RFS instances compose the CFS instance. Then, you can ask the Service Test Specification to provide a list of all available RFS tests and run them all. The question here is, what if you don't want to run them all and just some of them? This is not addressed.
In general, I have the impression that the current specification is quite simple in this area. It can be used for simple use cases, mostly for resource tests, but it doesn't cover many use cases where complex diagnostics of a service must be performed. What I miss is a description of test execution-how exactly is the test executed? But I might be wrong and may not fully understand the specification.
I have a question for you. If, in your case, a CFS test is a set of RFS tests, what is the outcome of the CFS test? Is it just an array of all RFS test outcomes, or do you somehow analyze all outputs and merge them into one output? If yes, how?
Thanks,
Jan
------------------------------
Ján Krištof
T-Mobile Czech & Slovak Telekom, a.s.
Original Message:
Sent: Nov 19, 2024 04:19
From: Frederic Thise
Subject: TMF653 missing ServiceTestRelationship
Hi guys,
We are investigating TMF653 API to document and execute our Service tests (ping, speed tests and various platform specific ones). In the UseCase we are investigating, there are multiple scenarios where a ServiceTest related to a CFS has to call mutliple test platforms (each one related to a RFS attached to the CFS).
The problem is that we find a property to describe relationships between ServiceTestSpecifications (serviceTestSpecRelationship) but not between ServiceTests. We really need to aggregate all the RFS ServiceTests into a list of ServiceTest relationships attached to the CFS ServiceTest.
Is this serviceTestRelationship property missing from the yaml (was it overlooked) or is there another way to do what we want?
Best regards,
------------------------------
Frederic Thise
Proximus SA
------------------------------