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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

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


Subject: Re: [tosca] Groups - TOSCA Architectures and Language impact uploaded


On Fri, Dec 4, 2020 at 1:41 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote:

There is obviously a balancing between expressive power on one hand and staying simple/usable/implementable and abstract on the other hand.


I'm not sure I agree with this! Simplicity often leads to more expressivity. (It also often, by contrast, leads to more verbosity, which I don't think we are too concerned about.)

I think our balancing act is different:

* On the one hand, we want TOSCA to have as little opinion as possible about orchestration implementations, because we believe it is valuable to use it at various levels of the orchestration stack, and also we know that in some industries (telco) we don't always have much choice as to which orchestrator to use.

* On the other hand, we want to target a clear minimal functional architecture (which you have been helping to define) that would be shared by all TOSCA orchestrators and enable powerful shared tooling (toolchains and pipelines). This "MFA" could also be the basis of "pure" TOSCA orchestrators, both simple and complex.

I think our specific challenge right now is where to place features. We are all generally aligned on the contours of the MFA (if not the internal details yet), but not so much on how to grow from there. I'm on the side of wanting all extensions of the MFA to be expressible in profiles, using existing grammatical features. Profiles, as I understand them, represent not just orchestration domains but also orchestration features and even orchestration paradigms (Kubernetes consolidates them together). I do think, as I've said before, that in order to achieve this goal we would likely need to extend the grammar a bit.

So, things like propagation, monitoring, workflows, lifecycles, and even cardinality -- these are all domain-specific, orchestration-specific, paradigm-specific concepts and should be expressed in TOSCA in all their diversity and specificity using the TOSCA type system. If we can achieve that in TOSCA 2.0, it will have basically completed my goals in joining the group and believe there will be less resistance to bringing TOSCA tools into existing efforts.


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