OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

 View Only
  • 1.  Re: [tosca] TOSCA for Ansible

    Posted 03-11-2021 16:53



    all good and very valuable pointsâ I have some research ongoing in some of them and Iâll share whatever I can learn as soon as possible :)


    D.



























    Damian A. Tamburri, Ph.D.
    Associate Professor 


    TU/e - JADS - 
    https://www.jads.nl/
    Sint Janssingel 92, sâHertogenbosch 

    Room 2.18, 2nd Floor



    Email: d.a.tamburri@tue.nl
    Cell: +39 3491279924
    Web: https://www.researchgate.net/profile/Damian_Tamburri

    Executive Director, Jheronimus Academy Data & Engineering (JADE) Lab
    Secretary, OASIS âTopology and Orchestration for Cloud Applicationsâ (TOSCA) Standard Technical Committee
    Secretary, IFIP - WG 2.14 / 6.12 / 8.10 on Service-Oriented Systems
    Associate Editor & Online Presence Director, ACM Transactions on Software Engineering & Methodology (TOSEM)



















































    On 11 Mar 2021, at 17:42, Tal Liron < tliron@redhat.com > wrote:



    Thanks! Nothing significant yet, just various Ansible hello-world-like scenarios.


    There are various challenges ahead:



    Generating "hosts" for Ansible. I think this might require a special Ansible profile with a "Host" capability. Otherwise it's hard to see how Ansible would know. Or maybe metadata that can be applied to any capability type or node type? Attributes. I think these will have to be set by an explicit Ansible role.
    Graph-iteration (this is a more general problem in Ansible, which has overly simple loops).




    On Thu, Mar 11, 2021 at 1:57 AM Tamburri, Damian < d.a.tamburri@tue.nl > wrote:


    Ciao Tal!


    This looks awesome! Are there specific scenarios in which you tested this?


    D.






















    Damian A. Tamburri, Ph.D.
    Associate Professor 


    TU/e - JADS - 
    https://www.jads.nl/
    Sint Janssingel 92, sâHertogenbosch 

    Room 2.18, 2nd Floor



    Email: d.a.tamburri@tue.nl
    Cell: +39 3491279924
    Web:  https://www.researchgate.net/profile/Damian_Tamburri

    Executive Director, Jheronimus Academy Data & Engineering (JADE) Lab
    Secretary, OASIS âTopology and Orchestration for Cloud Applicationsâ (TOSCA) Standard Technical Committee
    Secretary, IFIP - WG 2.14 / 6.12 / 8.10 on Service-Oriented Systems
    Associate Editor & Online Presence Director, ACM Transactions on Software Engineering & Methodology (TOSEM)



















































    On 10 Mar 2021, at 22:34, Tal Liron < tliron@redhat.com > wrote:



    Wouldn't it be nice if your Ansible playbooks could consume TOSCA?


    Well, now they can. This is still a work-in-progress, but Puccini now includes an Ansible module for TOSCA (which in turn relies on the Python wrapper).


    Here's an example of a simple playbook:



    https://github.com/tliron/puccini/blob/main/examples/ansible/hello-world.yaml


    There's still much more on the TODO list for supporting various Ansible use cases, but even at this early stage there's a lot that's possible by simply iterating on resolved node templates and doing the usual Ansible stuff.



    Feedback most welcome!





















  • 2.  Re: [tosca] TOSCA for Ansible

    Posted 03-12-2021 18:31
    So, I did find a way to generate Ansible's inventory dynamically from TOSCA. What's interesting about my solution is that it requires nothing specific on the TOSCA side, no special types and no metadata. Instead, you have a "tosca.yaml" file used by the plugin to filter the node and/or capability types that you want to consider as "hosts". This means it can work with any TOSCA profile for any environment. What's left to do is mapping properties or attributes to required Ansible host configurations. What's also interesting about this use case is that it does require a universal way to refer to types. That's where Puccini's "canonical type names" come into play, where I use the double-colon to specify the unambiguous names, e.g. "tosca::Container" ("tosca" here being not a user-specifed import namespace but the universal profile name). We've argued before over whether TOSCA should specify a canonical type name format, and I would say this is a good example of where it would be beneficial to have a standard. https://github.com/tliron/puccini/tree/main/examples/ansible/hosts