I personally donât think the current terminology is all that confusing:
- An orchestrator âinstantiatesâ a service from a template.
- In order to perform ongoing lifecycle management on the newly deployed âservice instanceâ, the orchestrator keeps an internal representation (an âinstance modelâ) of that deployed
service.
This would mean that:
- When we talk about instances, we refer to the external entities in the âreal worldâ. We have referred to those as âruntime instancesâ, âresourcesâ, âinfrastructureâ, âservice componentsâ,
âservice entitiesâ, etc. but âinstancesâ is a perfectly fine general-purpose term, in my opinion.
- When we talk about âinstance modelsâ, we *ALWAYS* refer to a representation (in the orchestratorâs database, memory, etc.) of the (external world) instances.
I believe that is how the spec has defined the term âinstance modelâ for a while now, and based on the discussion in this email thread, Iâm not sure there is much of a reason to change it.
Thanks,
Chris
From: adam souzis <adam@souzis.com>
Sent: Friday, November 13, 2020 7:36 PM
To: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Cc: Tal Liron <tliron@redhat.com>; Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Language Ad-Hoc WG 2020-11-10.docx uploaded
Yes I agree... Let's call them "instances" or "service instances" and give those real-world things another term like "infrastructure", "configurations" or (as I suggested) "resources". I suggested the latter because that's what Kubernetes,
Terraform and AWS call those things (among others) so I suspect most readers will be familiar with that usage.
Thanks,
Adam
On Fri, Nov 13, 2020 at 4:06 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote:
Since the term âinstancesâ is causing confusion I suggest it is at least disambiguated in some way.
Do we have a term for what it is that interfaces and their associated artifacts are doing to whatever they are doing something to.
In ETSI, we used âInfrastructureâ â virtualized or physical - as a generic term for the external âthingsâ that are being acted on or created. Ok, there is added complexity of VNF Managers, but that is because it is specifically working in the NFV domain.
Anyway, what the artifacts âdo to the infrastructureâ is to âconfigureâ it. Infrastructure may be a Cloud Provider (OpenStack, Amazon, â), a chemical production plant (as we saw), or something completely different.
Service Director can even manipulate physical equipment (like ordering new hardware or initiate the shipping a device to a customer) so from my perspective there should be a very broad understanding of what an atomic operation can do. To me ârun-timeâ is also confusing because of this.
But if we can call the things that operations act on in the real world âconfigurationsâ (or something else hinting real-world existence external to the TOSCA Orchestrator) instead of âinstancesâ, then it would be safer to call the logical representation of a template during deployment an âinstanceâ or âservice instanceâ.
Just my 5 cents.
Best regards
Peter
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of adam souzis
Sent: 12. november 2020 19:47
To: Tal Liron <tliron@redhat.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Language Ad-Hoc WG 2020-11-10.docx uploaded
Yes... And I'm proposing we continue to them "instances" and just make it clear that they are not "resources" but rather the logical instances you are referring to here...
á
On Thu, Nov 12, 2020 at 10:40 AM Tal Liron <tliron@redhat.com> wrote:
On Thu, Nov 12, 2020 at 12:37 PM adam souzis <adam@souzis.com> wrote:
Templates instantiate logical "instances" -- so of which will create live "resources" and some won't.
Yes. :) The problem is that we also have been talking about an "instance model" (and the TOSCA spec uses the word "instance" a lot, in confusing ways). But we are actually not talking run-time instances, we are talking something else that exists in between TOSCA templates and the run-time. I have tentatively proposed to call those things "objects".
á