OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca-comment] TOSCA v2 treatment of artefact, repository and nodes in general


Hi Paul, some very important proposals here.

On Tue, Oct 6, 2020 at 1:01 AM <paul.m.jordan@bt.com> wrote:
  1. Allow get_input on various artefact keynames and on repository.url
Let me attempt to generalize the requirement here.

We need a better way to "parameterize" service templates. The TOSCA intrinsic functions are fine for values, but as you pointed out they will not work for keywords, specifically the "type" keyword. In terms of grammar, it's obvious why this would be the case -- you cannot call a function without a value, and you cannot have values before you know the type. Actually, this same limitation exists in many TOSCA-like declarative languages.

The workaround is often to add a text templating layer, via something like Jinja2. So, imagine a "template.yaml.j2" being converted to the final TOSCA "template.yaml". Such workarounds are bad -- they steal the syntactical advantage of having a structured language. We see this happening everywhere, from OpenStack Heat to Kubernetes Helm ... and it's always a problem. Let's try to avoid it in TOSCA as much as we can.

I would be very much in favor of having some built in support for this feature, which I would call "keyword parameterization", so we can avoid ugly workarounds. But, I don't think we should be using intrinsic functions here. The reason is that this feature works entirely differently from values: these parameters must be renderable and rendered during the parsing phase, otherwise the entire template could not be parsed. I'm also not entirely convinced it should be implemented via TOSCA inputs, because those are exactly used for instantiation and it could be confusing to use them for two separate purposes.

My instinct is to support some kind of "environment variable" rendering, which is available in a wide range of declarative languages. E.g.:

topology_template:
 node_template:
ÂÂÂ my_node:
ÂÂÂÂÂ type: $NODE_NAME

I hope we can discuss this feature in a future ad hoc meeting. Paul, would you be able to join?
Â

  1. Be explicit on whether all nodes must be capable of instantiation.
I have a lot to say about this. :) The general topic is the "instance model", a consideration of how TOSCA templates relate to real-world instances.
Â

I believe that in TOSCA 1.3 there is an implicit assumption that each node in the template must be capable of being deployed by an orchestrator i.e. there is always at least one set of circumstances (due to interface operation, substitution, policy etc.) that would require the orchestrator to create an instance of the node; a node cannot exist in the template for any other reason.


I do not have that assumption. I think the very idea of a "template" is that it represents a possibility for 0 or more instances, and the exact runtime behavior should be configurable and conditional (and ideally policy-driven). Actually, this is an explicit part of TOSCA, that according to your inputs and runtime changes (get_attribute) each instance of the same service template might be different. My implicit understanding is that this includes runtime node instantiation -- including the count of how many (which could be zero in same cases). In other words, templates are placeholders.

Note that if this assumption did not exist you would have to create many versions of the same service template for each slight variation. We obviously want to make TOSCA more expressive than that.
Â

I suggest that TOSCA 2.0 presents an opportunity to explicitly allow TOSCA nodes to be extended via relationship of type âextends/extendedByâ to a node which cannot be instantiated itself, but which adds functionality or information. It may be convenient to give such extension nodes a different name or a directive to distinguish them from the classic node concept. If this proposal is rejected then I would like to see the standard make an explicit statement that all node types must be deployable.


So, again, I don't think TOSCA assumes (or should assume) how node templates are instantiated. Indeed, in many cases we want to model parts of platforms and infrastructure and cloud workloads that are "logical" rather than "physical", meaning there is no specific provisioning happening. The diversity of orchestration paradigms is such that TOSCA cannot have an opinion if it wants to be consumable by all of these (including future paradigms that have not yet been articulated).

The solution, I think, is in data, not in grammar. Add properties that describe how or when the node should be instantiated, if at all. Create data types as complex as you need to support this. Use groups/policies to apply these properties to many node templates at once.
Â

My use case for this proposal is that I would like to extend node definitions to include metric definitions which make use of the TMForum Information Model for metrics. That model contains a powerful, but complex, set or related entities.

To date I have been achieving this by denormalizing the Metric Information Model and representing it as TOSCA data types which can be attached to a node. This has proved restrictive because:

a)The denormalization process means that the information model relationships can only be navigated in one direction once they are in TOSCA.


I would suggest that it's important to distinguish between design-time relationships and runtime relationships. The former are between templates, not between instances. So indeed at runtime you can only follow the actual relationships made, which could have complex topologies (many-to-one, some-to-many, redundancy, pooling, etc.). The design-time relationship is a guide to where the runtime relationship(s) could be, in the same way that a node template is a guide to where node instance(s) could be.

Remember, the design is an "intent" rather than a statement of reality. It represents guides, hints, and limits for orchestration. And also let's not forget that a template is "day 1". In "day 2" (even minutes after deployment) there could be changes. In the cloud-native paradigm this is a given. So, denormalization is likely a necessity. And even not in cloud-native, remember that cloud resources are always somewhat ephemeral. E.g. we might have created a database connection as a relationship, but that connection failed in runtime. Maybe it will come back, maybe it won't. We end up having to follow the real connections.
Â

b) The information model contains relationships between abstract entities, but TOSCA does not allow relationships between abstract datatypes. My resolution to date has been to define relationships between each concrete TOSCA datatype but this is not scalable.


Could you explain this in more detail?
Â

  1. Generalise Artefact and Repository

If, from item 2, we accept that a deployable node can be extended by some other non-deployable support entity via a particular type of relationship which represents that support, then we can consider that:

  1. artefact is an extension of node
There is general agreement that we need to rethink how artifacts work.

By the way, the workaround for now would be to simply not use artifacts. Nothing is stopping you from defining your own node types that represent artifacts and using relationships to associate them with other nodes.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]