Hello Tal,
Many thanks for your reply and explanation!
It makes sense to me.
BR.
Matej
On Fri, Apr 8, 2022 at 2:54 PM Tal Liron <
tliron@redhat.com> wrote:
> Hi Matej,
>
> It doesn't seem likely that OASIS TOSCA would arbitrate this matter. The community
> repository <https://github.com/oasis-open/tosca-community-contributions/>
> is open to profile contributions, but none of these are OASIS standards.
> Indeed several Kubernetes profiles may be contributed. After a somewhat
> negative experience with managing the Simple Profile, the TOSCA TC has
> decided that profile development should best be left to the community. That
> said, nothing is stopping the community from embracing a "de facto
> standard" if a certain profile or combination becomes widely used and
> supported.
>
> Compare this to the experience with programming languages. Though all
> programming languages come with a basic standard library, multiple open
> source solutions may exist for the same problem, each with its own
> subjective advantages. An obvious example is logging: I don't know of a
> programming language with just one logging API, even if the standard
> library includes logging.
>
> We obviously care about portability but not at all costs. Each
> orchestrator that supports TOSCA is its own product with its own design
> paradigms and may have different assumptions and requirements for modeling.
> For example, Turandot works entirely differently from Cloudify and it's
> hard to imagine a Kubernetes profile that could be trivially consumed by
> both.
>
> That said, in some cases it shouldn't be necessary to reinvent the wheel.
> The Kubernetes API is published and well-annotated, so it's deterministic
> to convert it to TOSCA. With Turandot I've included a profile generator
> <https://github.com/tliron/turandot/tree/main/turandot-profile-generator>
> (work in progress) that does exactly that. I know that Chris has something
> similar in Ubicity.
>
> On Fri, Apr 8, 2022 at 7:29 AM Matej Feder <
matej.feder@dnation.cloud>
> wrote:
>
>> Dear TOSCA community,
>>
>> With this email, I would like to ask you what is the state-of-the-art for
>> TOSCA-based application deployment to the Kubernetes environment.
>>
>> In other words, I would like to define the TOSCA template for the
>> Kubernetes resources ( Kubernetes Deployments
>> <https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment>,
>> Kubernetes Configmaps,
>> <https://kubernetes.io/docs/concepts/configuration/configmap/#configmaps-and-pods>and
>> so on) based on publicly available TOSCA types.
>>
>> I went through a couple of opensource projects like:
>> - Turandot <https://github.com/tliron/turandot>
>> - Cloudify <https://github.com/cloudify-cosmo/cloudify-kubernetes-plugin>
>> - MiCADO <https://github.com/micado-scale/tosca>
>> - Indigo <https://github.com/indigo-dc/orchestrator>
>>
>> and, it seems that each project defined its *own* TOSCA Types for
>> Kubernetes resources.
>>
>> My question is:
>>
>> Is there any standardized way how to describe Kubernetes resources by
>> TOSCA?
>>
>> Thanks in advance for your help.
>>
>> Regards,
>>
>> Matej Feder
>>
>> DevOps Engineer at dNation <https://dnation.cloud/>
>>
>>