RE: [tosca] Towards an instance model for TOSCA

Iâm not sure the two approaches are incompatible. I just want to make sure we donât preclude one approach or the other.

Yes, more perspectives would be welcome. Letâs continue the discussion.

Thanks,

Chris

From: Tal Liron <tliron@redhat.com>
Sent: Thursday, October 03, 2019 8:59 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Towards an instance model for TOSCA

On Thu, Oct 3, 2019 at 10:24 AM Chris Lauwers <lauwers@ubicity.com> wrote:

Sounds like more areas for differences of opinions.

We need to expand this discussion and bring more perspectives. I'm not sure if either of us can budge here.

As far as I understand, you seem to be wanting to build an orchestrator based on TOSCA, whereby TOSCA is the language for telling the orchestrator what to do. My view has always been that TOSCA would fail if it were to go that way. There are so many orchestrators out there already, some of them already declarative and powerful and packed with real-world features (Terraform, Cloudify, etc.). I'm not interested in competing in that space, and don't think a standards body is the right place to do so had I wanted to compete in that space. I would just go and create that orchestrator and create a powerful language for it. If it's good, it would succeed.

If TOSCA would go in the direction of dictating orchestration, it would stop being interesting to me, and indeed it would be hard for me to recommend any major company invest in the standard. If TOSCA would have any chance of succeeding it would be the "bring your own orchestrator" approach. It would be as a language for integrating existing orchestration solutions, not creating new ones.

tosca message