Per design, the in-built mock does not know the target ID, because the mock is part of the project's HTTP lib: target ID is not available at this stage (we could change this, though, and pass the target name to the backend...)
Therefore, today, the OSVIP is used as a target id. This leads to the restrictons that
the OSVIP is mandatory for targets to be compatible with the mock
the OSVIP must be unique
The problem is aggravated by the fact that we have not yet defined a validator that checks that the OSVIP is present and unique. It is not that simple, since the OSVIP is not a target attribute, but it is hidden in target.configuration attribute and to retrieve it, the configuration text must be parsed.
I have set the prio to normal, because it is an annoying restriction, put applies to simulation mode only. Productive systems are not affected.
Per design, the in-built mock does not know the target ID, because the mock is part of the project's HTTP lib: target ID is not available at this stage (we could change this, though, and pass the target name to the backend...)
Therefore, today, the OSVIP is used as a target id. This leads to the restrictons that
The problem is aggravated by the fact that we have not yet defined a validator that checks that the OSVIP is present and unique. It is not that simple, since the OSVIP is not a target attribute, but it is hidden in target.configuration attribute and to retrieve it, the configuration text must be parsed.
I have set the prio to normal, because it is an annoying restriction, put applies to simulation mode only. Productive systems are not affected.