[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] Operation implementations
I believe there are actually two separate issues here:
- Do operation implementations need to be âsplit upâ into a âprimaryâ implementation and a list of âdependentâ implementations?
- Do operation implementations need to be typed, and if so, how to we specify the âtypeâ of the operation implementation
- In your example, you define (âdeclareâ) the type of the operation implementation in the interface type definition as follows:
 Maintenance:
ÂÂÂ operations:
ÂÂÂÂÂ maintenance-off:
ÂÂÂÂÂÂÂ type: SSH # data type for the implementation. if not declared, must be set in assignment
ÂÂÂÂÂÂÂ inputs:
ÂÂÂÂÂÂÂÂÂ immediate:
ÂÂÂÂÂÂÂÂÂÂÂ type: bool
I believe this is not good practice. An interface type definition should be just that: a definition of the set of operations that can be called within the context of that interface. Interface types should not have an opinion about how they should be implemented. Specifically, they should not restrict the type of their implementations.
- More importantly, your approach for handling the properties of the operation implementation data types is invalid TOSCA, in my opinion, and will not work. Here is your âRemoteâ data type definition:
data_types:
 Remote:
ÂÂÂ properties:
ÂÂÂÂÂ address:
ÂÂÂÂÂÂÂ type: string
ÂÂÂÂÂÂÂ default: { get_attribute: [ SELF, address ] }
ÂÂÂÂÂ credentials:
ÂÂÂÂÂÂÂ type: Credentials
ÂÂÂÂÂÂÂ default: { get_input: credentials }
The âaddressâ property has a default value that references SELF. However, data type definitions do not have a SELF context.
Your gRPC example illustrates this use case. By the way, I believe your example shows grammar that is slightly different from what you intended. If my understanding is correct, the following snippet is grammatically more correct (i.e., the type is specified inside the âimplementationâ block, not the other way around, and the âpropertiesâ keyword is required):
 node_templates:
ÂÂÂ server:
ÂÂÂÂÂ type: Server
ÂÂÂÂÂ interfaces:
ÂÂÂÂÂÂÂ Maintenance:
ÂÂÂÂÂÂÂÂÂ operations:
ÂÂÂÂÂÂÂÂÂÂÂ maintenance-on:
ÂÂÂÂÂÂÂÂÂÂÂÂÂ implementation:
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ type: GRPC
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ rpc: StartMaintenanceWithMode
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ timeout: 10 s
ÂÂÂÂÂÂÂÂÂÂÂÂÂ inputs:
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ mode: production
Â
Summary
As you pointed out, there are more issues that need to be resolved, but hopefully we can come to agreement on some of the basics. Here is my recommendation:
- Introduce a new Implementation Type that must be used when defining operation implementations (instead of the current Artifact Types)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]