ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781) |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0007978 | Ext Pack: Config & Deployment Support (ES 202 781) | New Feature | public | 13-08-2020 15:00 | 18-12-2020 14:36 |
|
| Reporter | Jacob Wieland - Spirent | |
| Assigned To | Gyorgy Rethy | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | v1.7.1 (published 2019-04) | |
| Target Version | v1.8.1 (ongoing) | Fixed in Version | v1.8.1 (ongoing) | |
| Clause Reference(s) | 6.1.13, 7.3.3, 8.5.3, 9.4.3, 10.6.3,12.5.3, C.3 |
| Source (company - Author) | Spirent - Jacob Wieland |
| TS version | |
|
| Summary | 0007978: Dealing with parallel control components |
| Description | TCI functions should be added to the CH interface to deal with:
- creation of parallel control components
- starting of PCCs
- termination of PCCs
- done/killed of PCCs
- alive/running of PCCs
These should mainly be copies of the same functionality for PTCs with the exception of verdict handling |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | 0007910 | closed | Jens Grabowski | Part 01: TTCN-3 Core Language | Allow parallel control parts/components |
|
| Attached Files |  CR7978.docx (1,419,628) 05-10-2020 13:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3955&type=bug
CR7978-2.docx (923,429) 08-10-2020 15:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3961&type=bug
CR7978-3.docx (933,358) 07-12-2020 14:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3970&type=bug
CR7978-4.docx (1,112,937) 08-12-2020 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3973&type=bug
CR7978-5.docx (231,066) 10-12-2020 13:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3985&type=bug
CR7978-6.docx (231,344) 11-12-2020 11:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3986&type=bug
CR7978-7.docx (275,617) 11-12-2020 12:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3987&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 13-08-2020 15:00 | Jacob Wieland - Spirent | New Issue | |
| 13-08-2020 15:00 | Jacob Wieland - Spirent | Status | new => assigned |
| 13-08-2020 15:00 | Jacob Wieland - Spirent | Assigned To | => Jacob Wieland - Spirent |
| 13-08-2020 15:01 | Jacob Wieland - Spirent | Relationship added | related to 0007910 |
| 05-10-2020 12:42 | Jacob Wieland - Spirent | Note Added: 0015757 | |
| 05-10-2020 13:26 | Jacob Wieland - Spirent | File Added: CR7978.docx | |
| 05-10-2020 13:27 | Jacob Wieland - Spirent | Note Added: 0015758 | |
| 05-10-2020 13:27 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban |
| 05-10-2020 13:27 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 06-10-2020 13:26 | Jens Grabowski | Assigned To | Tomas Urban => Jacob Wieland - Spirent |
| 06-10-2020 13:26 | Jens Grabowski | Status | confirmed => assigned |
| 08-10-2020 15:40 | Jacob Wieland - Spirent | File Added: CR7978-2.docx | |
| 08-10-2020 15:41 | Jacob Wieland - Spirent | Note Added: 0015782 | |
| 08-10-2020 15:41 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban |
| 08-10-2020 15:41 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 09-10-2020 08:28 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent |
| 09-10-2020 08:28 | Tomas Urban | Status | confirmed => assigned |
| 09-10-2020 08:35 | Tomas Urban | Note Added: 0015788 | |
| 09-10-2020 15:14 | Jacob Wieland - Spirent | Project | Part 06: TTCN-3 Control Interface => Ext Pack: Config & Deployment Support (ES 202 781) |
| 07-12-2020 14:45 | Jacob Wieland - Spirent | File Added: CR7978-3.docx | |
| 07-12-2020 14:52 | Jacob Wieland - Spirent | File Deleted: CR7978-3.docx | |
| 07-12-2020 14:53 | Jacob Wieland - Spirent | File Added: CR7978-3.docx | |
| 07-12-2020 14:55 | Jacob Wieland - Spirent | Note Added: 0015800 | |
| 07-12-2020 14:55 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban |
| 07-12-2020 14:55 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 08-12-2020 13:08 | Tomas Urban | File Added: CR7978-4.docx | |
| 08-12-2020 13:12 | Tomas Urban | Note Added: 0015812 | |
| 08-12-2020 13:12 | Tomas Urban | Assigned To | Tomas Urban => Kristóf Szabados |
| 09-12-2020 21:23 | Kristóf Szabados | Note Added: 0015830 | |
| 09-12-2020 21:40 | Kristóf Szabados | Note Added: 0015831 | |
| 09-12-2020 21:41 | Kristóf Szabados | Assigned To | Kristóf Szabados => Jacob Wieland - Spirent |
| 09-12-2020 21:41 | Kristóf Szabados | Status | confirmed => assigned |
| 10-12-2020 08:02 | Tomas Urban | Note Added: 0015834 | |
| 10-12-2020 13:19 | Jacob Wieland - Spirent | File Added: CR7978-5.docx | |
| 10-12-2020 13:21 | Jacob Wieland - Spirent | Note Added: 0015840 | |
| 10-12-2020 13:21 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Kristof.Szabados |
| 10-12-2020 13:21 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 10-12-2020 13:52 | Kristóf Szabados | Assigned To | Kristof.Szabados => Kristóf Szabados |
| 10-12-2020 13:52 | Kristóf Szabados | Status | confirmed => assigned |
| 10-12-2020 14:13 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 11-12-2020 10:29 | Kristóf Szabados | Note Added: 0015845 | |
| 11-12-2020 10:29 | Kristóf Szabados | Note Added: 0015846 | |
| 11-12-2020 10:30 | Kristóf Szabados | Note Added: 0015847 | |
| 11-12-2020 10:30 | Kristóf Szabados | Assigned To | Kristóf Szabados => Jacob Wieland - Spirent |
| 11-12-2020 10:30 | Kristóf Szabados | Status | confirmed => assigned |
| 11-12-2020 11:58 | Jacob Wieland - Spirent | File Added: CR7978-6.docx | |
| 11-12-2020 11:59 | Jacob Wieland - Spirent | Note Added: 0015848 | |
| 11-12-2020 11:59 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban |
| 11-12-2020 11:59 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 11-12-2020 12:27 | Tomas Urban | File Added: CR7978-7.docx | |
| 11-12-2020 12:34 | Tomas Urban | Note Added: 0015849 | |
| 11-12-2020 12:34 | Tomas Urban | Status | confirmed => resolved |
| 11-12-2020 12:34 | Tomas Urban | Resolution | open => fixed |
| 11-12-2020 12:34 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy |
| 18-12-2020 14:36 | Gyorgy Rethy | Note Added: 0015891 | |
| 18-12-2020 14:36 | Gyorgy Rethy | Status | resolved => closed |
| 18-12-2020 14:36 | Gyorgy Rethy | Product Version | Next version (to be defined) => v1.7.1 (published 2019-04) |
| 18-12-2020 14:36 | Gyorgy Rethy | Fixed in Version | => v1.8.1 (ongoing) |
| 18-12-2020 14:36 | Gyorgy Rethy | Target Version | Next version (to be defined) => v1.8.1 (ongoing) |
|
Notes |
|
|
|
Having reviewed the existing TCI for component handling, I don't think new functionality needs to be introduced for handling of control components after all, as the CH is completely agnostic to what purpose a component has.
The only exception is the functionality tciGetMTCReq/tciGetMTC.
This should be supplemented by tciGetParallelMTC(TriComponentId pcc) to provide the mtc associated with the given pcc. As before, tciGetMTC() should give back the mtc executed by the MCC (if any). |
|
|
|
|
|
|
|
|
|
please review draft in Config&Deployment (still without TCI) |
|
|
|
|
I am basically fine with the proposed draft. However, I found three issues:
1. any and all component operations cannot have exactly the same semantics as in the core language standard as they are related to PTCs, while they should be related to PCCs in this case.
2. What is the use case for allowing map and connect operations in MCC and PCCs? I thought that communication operations are used only for controlling the test execution, i.e. for exchanging data between the control components. Are they supposed to be used for setting up the test run on the SUT side? If it is so, we should add a note explaining this so that users don't start to implement test logic directly in the control components.
3. There's a typo in the 2nd paragraph of 5.3.0 exected -> executed |
|
|
|
|
|
I have addressed the issues and added the other changes to the TciCHRequired/TciCHProvided interfaces in the different language mappings needed for getting the mtc associated with a running pcc. |
|
|
|
|
I am mostly fine with the last proposal, I only made two minor changes:
- changed "testcase" to "test case" as the core language specification usually uses the latter term
- added a note describing the purpose of communication between MCC/PCC and the SUT
Since it is a long proposal, could you please check it two and if you are fine with it, assign it back to Jacob for final acceptance. |
|
|
|
|
1)
Teh description sounds a bit confusing. There is nothing on what an MCC or PCC is, but there is a description on what it might do.
2)
I know this is nitpicking, but according to the current description an MCC may create PCC while "executing" a control function ... but is also allowed for it to simply not do anything, irrespective of what the user wanted.
Please note that the core in similar circumstances talks about executing the behaviour defined in the body of the test case ... aka. the behaviour is performed, while the current description allows to simply write out onto the screen "executig the control function".
Also in the core the behaviour shall execute on the component ... not may do something.
3)
Please note that according to the current description parallel test execution is not yet allowed.
The core states: "Within every configuration there shall be one (and only one) Main Test Component (MTC)"
As this is not overriden here, effectively it does not matter how many PCC there are in the system, only one of them can have a test case executing at any point in time. |
|
|
|
|
4)
It is not clear how the existing component operations, like any component, changes.
The current description contains: "coordinated parallel execution of independent test cases "
However if each test cases running parallelly on PCCs is independent, than any component and all component shall refer only to the components started on the PCC they are invoked on, not every component in the whole system irrespective of which PCC they were started on.
Otherwise the test cases are not independent.
5)
Actually any component and all component, if I understand correctly should refer to different set of PTCs on each PCC and a separate set of PCCs on the MCC.
6)
According to the core standard the create operation shall return a unique component reference of the newly created instance.
In the context of MCC and PCCs, it needs to be clarified if that means systemwide uniqueness or uniqueness only in the context of a given PCC.
(for example when tools log something also containing the component reference do we wish to allow to have the same component reference on several PCC -s confusing the user or not) |
|
|
|
|
|
I think Kristof's remarks are addressed to Jacob, who is the author of the proposal. Jacob, could you please comment? |
|
|
|
|
|
I have addressed all your points in the last draft. Please review. |
|
|
|
|
1)
maybe there should be a note for implementors, that while the local ids of components can be the same in different testcases, they can also differ (having a benefit during human processing of logs)
2)
"test`case " might be a typo.
3)
"When the main control function is started"
Please note, that the term "main control function" is not defined.
Maybe we could say that the "control function started first is called/becomes the main control function" |
|
|
|
|
4)
"Inside the behaviour definition being executed by a control component it is allowed to dynamically create additional parallel control components (PCCs) and start them with other control behaviour "
This seems to contradict itself.
If control components are not allowed to execute behaviour (other than creating additional parallel control components), there is no point in trying to start them with a behaviour (PCC -s are also control components).
5)
"The restriction that in every configuration there shall be one (and only one) MTC is amended to that in every test case configuration shall be exactly one MTC"
This is a strange sentence.
If there is only one MTC, than that is the only one MTC in every test case configuration.
6)
"Control hehaviour has no way of referencing components created for an executed test case"
A control behaviour can be any function called by control directly or indirectly.
The exact same function could also be called by a testcase directly or indirectly.
This might cause confusion in users, regarding what exactly for example any component will mean, loking at only the code of the function. |
|
|
|
|
7)
"The component operations create, start, call, stop, kill, running, alive, done, killed shall be allowed to be used also in control behaviour with the same semantics and the same restrictions as for test components inside test behaviour "
Can PCC -s be alive?
And this way, transfer information from 1 test case to the next?
8)
"The semantics of alt statements and interleave statements as well as the activate and deactivate operations are the same as for test case behaviour"
I would believe they should rather work like any component and all component, in the sense that each test case behaiour and each PCC should have their own distinct set of activated defaults ... otherwise there can be sideeffects between the tests.
9)
"As for the MCC, the execute operation inside PCC behaviour will block until either the executed test case has terminated or the given timeout has occurred and test execution has been stopped"
This sounds strange.
Like ... lets talk about the MCC! <switching topic> the PCC behaves like this and that.
There was also no mention of the MCC being a PCC so far. |
|
|
|
|
|
Addressed the issues as discussed in the meeting. please check. |
|
|
|
|
The proposal is mostly fine, but I made three changes in the final draft:
1. Added the following sentence to address Kristof's points 0000004 and 0000005:
PCCs are allowed to execute test cases independently and in parallel with test cases being executed on other PCCs and the MCC.
2. Changed the expression "test case behaviour" to "behaviour executed on a test component" to address Kristof's point 0000008
3. Replaced TTCN-3 upper case letter with lower case in TTCN-3 operations listed in the table 2.
All these changes were discussed with Jacob who approved them.
With these small updates, the proposal is ready to be included in the next version of the specification. |
|
|
|
|
|
Implemented in draft 1.7.2 |
|