ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0003794 | Part 01: TTCN-3 Core Language | New Feature | public | 18-07-2008 10:36 | 02-09-2010 11:11

Reporter | Jens Grabowski |
Assigned To | Ina Schieferdecker |
Priority | low | Severity | feature | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.1 (published 2011-06) | Fixed in Version | v4.3.1 (published 2011-06) |
Clause Reference(s) | NONE
Source (company - Author) | Jens Grabowski (STF 347)

Summary | 0003794: Support for deployment
Description | TTCN-3 does not support the deployment of test configurations. Several users asked for such a support. A limited attempt for deployment support was made in CR 419.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0000419 | closed | Ina Schieferdecker | Identifying PTC host in create statements

Attached Files | CR3794-part6.doc (181,760) 01-09-2010 15:04 http://oldforge.etsi.org/mantis/file_download.php?file_id=2424&type=bug CR3794-part1.doc (55,808) 01-09-2010 15:40 http://oldforge.etsi.org/mantis/file_download.php?file_id=2425&type=bug CR3794-part1-2-Rev-Jens.doc (59,904) 01-09-2010 16:25 http://oldforge.etsi.org/mantis/file_download.php?file_id=2427&type=bug

Issue History
Date Modified | Username | Field | Change
18-07-2008 10:36 | Jens Grabowski | New Issue |
18-07-2008 10:36 | Jens Grabowski | Status | new => assigned
18-07-2008 10:36 | Jens Grabowski | Assigned To | => Gyorgy Rethy
18-07-2008 10:36 | Jens Grabowski | Clause Reference(s) | => NONE
18-07-2008 10:36 | Jens Grabowski | Source (company - Author) | => Jens Grabowski (STF 347)
18-07-2008 10:37 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2008 09:15 | Ina Schieferdecker | Target Version | => Edition 4.1.1 (not yet published)
12-12-2008 16:01 | Ina Schieferdecker | Relationship added | related to 0000419
07-09-2009 10:18 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
16-02-2010 14:25 | Jens Grabowski | Note Added: 0009218 |
22-03-2010 17:25 | Gyorgy Rethy | Assigned To | Jens Grabowski =>
22-03-2010 17:25 | Gyorgy Rethy | Status | assigned => new
22-03-2010 17:25 | Gyorgy Rethy | Target Version | Edition 4.1.1 Published 2009-06-02 => Edition 4.3.1 (not yet published)
23-03-2010 13:01 | Gyorgy Rethy | Assigned To | => Jens Grabowski
23-03-2010 13:01 | Gyorgy Rethy | Priority | normal => low
23-03-2010 13:01 | Gyorgy Rethy | Status | new => assigned
31-08-2010 10:57 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
31-08-2010 12:50 | Jacob Wieland - Spirent | Note Added: 0009664 |
31-08-2010 12:58 | Jacob Wieland - Spirent | Note Added: 0009665 |
01-09-2010 10:07 | Jens Grabowski | Note Added: 0009668 |
01-09-2010 13:47 | Jacob Wieland - Spirent | File Added: CR3794-part1.doc |
01-09-2010 13:47 | Jacob Wieland - Spirent | Note Added: 0009675 |
01-09-2010 15:04 | Jacob Wieland - Spirent | File Added: CR3794-part6.doc |
01-09-2010 15:09 | Jacob Wieland - Spirent | Note Added: 0009679 |
01-09-2010 15:11 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
01-09-2010 15:40 | Jacob Wieland - Spirent | File Deleted: CR3794-part1.doc |
01-09-2010 15:40 | Jacob Wieland - Spirent | File Added: CR3794-part1.doc |
01-09-2010 16:25 | Jens Grabowski | File Added: CR3794-part1-2-Rev-Jens.doc |
01-09-2010 16:26 | Jens Grabowski | Note Added: 0009681 |
01-09-2010 16:27 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
01-09-2010 17:08 | Jacob Wieland - Spirent | Note Added: 0009684 |
01-09-2010 17:10 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
01-09-2010 17:10 | Jacob Wieland - Spirent | Note Added: 0009685 |
02-09-2010 11:10 | Ina Schieferdecker | Note Added: 0009695 |
02-09-2010 11:10 | Ina Schieferdecker | Status | assigned => resolved
02-09-2010 11:10 | Ina Schieferdecker | Resolution | open => fixed
02-09-2010 11:10 | Ina Schieferdecker | Fixed in Version | => Edition 4.3.1 (not yet published)
02-09-2010 11:11 | Ina Schieferdecker | Status | resolved => closed

Notes

(0009218)
Jens Grabowski
16-02-2010 14:25

To be discussed again for v5.1.1

(0009664)
Jacob Wieland - Spirent
31-08-2010 12:50

In principle, the proposal from CR419 is valid and would work:
For this, as Ina mentioned, the following functions in TCI-CH need to be
changed:
tciCreateTestComponentReq()/tciCreateTestComponent() - add additional host parameter
Likewise, the execute() statement should also get an additional optional parameter so that the MTC can also be started on a specific host.
For this, also the following functions in TCI-CH need to be changed:
tciExecuteTestCaseReq()/tciExecuteTestCase()
In both cases, the CH implementation needs to be able to resolve the remote TE from the given host id in the -Req() functions and then relay those requests to that remote TE.
The same approach would also work together with static configurations.
Only in case that the additional parameter is given to the execute() or create() operations should the CH be asked to deploy the MTC/PTC on the given host, otherwise, it shall deploy as it sees fit (like before).
===============================================================================
Additionally, it could be allowed to declare a host type in the component type definition. In the create/execute operations, the given host expression (if any) would then have to be of the declared host type. If no host type is declared, the default host type should still be charstring.
The syntax could look like this:
type component C runs on hosttype {
}
(where hosttype must be a valid type reference)
But, for component inheritance, rules to resolve clashes of host types must be considered. Several possibilities come to mind:
- the host type is not inheritable, each component type MUST declare its own host type (and in case it does not, it is the default host type charstring)
- the host type is inherited if all extended component types have the same host type, otherwise, it is the default host type. In this case, the host type can be overridden by the extending component type definition if it should be different.
Personally, I favor option 1. In 99 % of cases the host type will be charstring anyway.

(0009665)
Jacob Wieland - Spirent
31-08-2010 12:58

Of course, the TLI must also be changed to include the host. The following events need a new sub-element: tliCCreate, tliTcExecute the element could look like this: <xsd:element name="host" type="Values:Value"/>

(0009668)
Jens Grabowski
01-09-2010 10:07

Ok, if everbody thinks that a charstring in a CREATE statement is enough support for deployment, then lets go for it.

(0009675)
Jacob Wieland - Spirent
01-09-2010 13:47

added necessary changes to part 1

(0009679)
Jacob Wieland - Spirent
01-09-2010 15:09

uploaded the added changes to TCI:
only changes necessary were those for tciCreateTestComponentReq() as the CH then relays this request to the right remote TE (identified by the hostId) which does not need to get relayed the hostId. These changes have been made for all language mappings.
tciExecuteTestCaseReq() does not need to be changed either because it is called after the MTC has already been created via tciCreateTestComponentReq()
The tli interface does not really need to be changed either, because implicit deployment was also possible before and the information wasn't interesting before, either. But, we could of course still add the optional host id field in the tli.

(0009681)
Jens Grabowski
01-09-2010 16:26

Re-assigned to Jacob for cross-checking.

(0009684)
Jacob Wieland - Spirent
01-09-2010 17:08

review by Jens okay by me

(0009685)
Jacob Wieland - Spirent
01-09-2010 17:10

please review part 6

(0009695)
Ina Schieferdecker
02-09-2010 11:10

Ok with me. Implemented in Part 1 and Part 6 as proposed with one addition to TLI so that one can log the hostId in tliCCreate:
<xsd:complexType name="tliCCreate">
<xsd:complexContent mixed="true">
<xsd:extension base="Events:Event">
<xsd:sequence>
<xsd:element name="comp" type="Types:TriComponentIdType"/>
<xsd:element name="name" type="SimpleTypes:TString"/>
<xsd:element name="hostId" type="Values:Value" minOccurs="0"/>
<xsd:element name="alive" type="SimpleTypes:TBoolean"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>