Thanks Paul. Has your work on OpenAPI integration led you to any additional opinions about how to manage state transitions in interface type definitions?
Thanks,
Chris
From: paul.m.jordan@bt.com <paul.m.jordan@bt.com>
Sent: Tuesday, December 8, 2020 11:50 PM
To: tliron@redhat.com; Chris Lauwers <lauwers@ubicity.com>
Cc: tosca-comment@lists.oasis-open.org
Subject: RE: [tosca-comment] RE: Artifacts for Node Interfaces
I would not want to see the concept of interfaces removed; an OAS3 definition is a definition of an interface containing an number of operations.
I do have sympathy for the formal definition of a state machine for interfaces but have trouble in the past trying to map to pre-existing state definition to those prescribed by Tosca.nodes.root (BTW in 1.3 they are inconsistent
anyway) so I wouldnât want to keep a formal definition of states, just a mechanism for authors to define their own.
But I would point out that:
- A state machine definition would need to include the unhappy paths as well as success, otherwise you canât specify error recovery actions.
- The state machine for an interface is not the same as the state machine for the node which that interface manages. (e.g. A node can be down but under management,
a node may be operational but the user may not be authorised to execute operations)
I note that a RESTful API doesnât attach the state machine to the whole interface, but rather it effectively lists the currently available state transitions as each state is reached.
From:
tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: 08 December 2020 05:15
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Jordan,PM,Paul,TNK6 R <paul.m.jordan@bt.com>;
tosca-comment@lists.oasis-open.org
Subject: Re: [tosca-comment] RE: Artifacts for Node Interfaces
I think this is an interesting idea, Chris, and could be useful for *some* implementations. However, it is also extremely specific and would require some kind of state management by *all* orchestrators. In my view, the
TOSCA membrane into orchestrators (operations and notifications -> I'd rather we call them "events") should be as generic as possible. If this means erring on the side of more atomicity, then so be it. Orchestrators can implement their own "calling" system,
be it transactions, states, or whatever else. There are simply too many calling paradigms and we cannot cover them all.
An Operation Type could allow for a way to provide some more hints to orchestrators.
My workaround for this is that I always create interfaces with single operations. Very awkward!
I agree that Interfaces are currently not very well defined in TOSCA. However, that doesnât mean we should get rid of them, it means we should flesh them out more. The reason operations
are grouped in interfaces is because operations associated with an interfaces can typically only be called in a specific order or, more technically correct, when the interface is in a given state. Unfortunately, there is no way currently to specify this in
the interface type definition.
I have proposed the following solution to this in the past:
-
Define a âstateâ attribute on interface types
-
For each operation definition, define:
-
The interface state(s) for which it is valid to invoke the operation
-
The interface state into which the interface transitions after the operation (successfully) executes.
In my opinion, this is a far better approach than what our current specification says, which is that node types should have a state attribute (defined in tosca.nodes.Root) which
can only have a limited set of predefined values (also defined in the standard). This approach has the following problems:
-
It creates a language dependency on the simple profile types
-
It doesnât allow for multiple interfaces that each could have their own state values
-
It doesnât allow for the introduction of additional state values
The approach Iâm suggesting would also create a path towards automatic generation of declarative workflows for arbitrary interfaces: the workflow could define the target states
(the âdesired stateâ) for all nodes in the topology, and then create âstepsâ to get there based on the state transitions specified in the operation definitions (this gives us a general-purpose path towards intent-based deployments).
Thanks,
Chris
One suggested solution --
We should have Operation Types, and remove the concept of Interfaces entirely. I have yet to see a use of Interfaces in TOSCA that is in any way similar to how the concept works
in other languages. You would still need to declare Operations in node types and relationship types. And that set declarations is itself the "interface".
We could then dive into Operation Types and allow artifacts to be attached and see how we can better support RPC, REST, and other patterns.
Just having an "implementation" string (plus "dependencies") is insufficient, and it's awkward to attach the relevant artifact at the node rather than at the operation.
Hi Paul, this is an interesting idea, but if this were supported, we would still need syntax to specify how a specific operation in the interface maps to a specific API call in
the OpenAPI definition. BTW, I believe there are parallels with Java JAR files or Python packages. One may have a JAR or Package that implements a specific API, but each operation must somehow map to a specific âentry pointâ in the JAR or Package. It would
be nice to have a general solution for this type of situation.
Thanks,
Chris
The TOSCA standard includes the definition of lifecycle operations which may be performed on nodes or relationships. Such operation definitions are grouped into
TOSCA interface definitions. Node templates may include such interfaces.
A common pattern for servers to expose operations is via a RESTful API. The contract between a client and a server using a RESTful API is often described using
common file format, either swagger or its successor OpenAPI.
When a node template relates to a node which implements a REST API it may be desirable to supply the relevant OpenAPI file as an artifact.
With the current grammar an artefact can be supplied with a node template and also with an interface operation. However while OpenAPI describes the operation
of the whole interface, TOSCA does not allow an artefact to be supplied at the level of node:interface.
Would it be possible to add keyname artefact to the definition of Interface Assignment?
Paul Jordan
OSS Specialist
BT
Technology | Tel
+44 (0) 3316252643 |
paul.m.jordan@bt.com
This email contains information from BT that might be privileged or confidential. And it's
only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.
We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000
|