Hi Tal,

I had a glance of puccini and am yet to explore more by getting my hands
dirty. But then I have following questions, based on my glance.

   - As you had rightly mentioned in your AriaTosca message in mailinglist,
   ONAP has already got handful of parsers, including very own aria and it is
   not fully integrated with SO yet ( please correct me if I'm wrong ). What
   unique advantages would puccini bring, apart from being yet another, fresh,
   tosca 1.1 compliant, standalone, golang-js-based parser ? I'm not debating
   the arguments that you made on the aria-mailing list, am just trying to
   understand your argument on how it could benefit ONAP in particular?
   - Since today, SO is predominantly BPMN driven, how much effort does it
   take to come up with BPMN backend ? Is it feasible ?
   - IMHO Kubern8s space is already (kinda) standardized and deployment of
   ONAP components may not need another language. Personally I am interested
   to know if puccini would ease the job of parsing SOL 001 compliant NSDs &
   VNFDs and seamlessly translate to ONAP specific workflows ( BPMN, DAGs etc
   ) with minimum efforts.

Looking forward to your talk at Beijing summit.

BR,
Viswa


<http://www.verizon.com>

Viswanath Kumar Skand Priya
Architect
Technology, Architecture & Planning


On Tue, Jun 12, 2018 at 10:42 PM, Tal Liron <tli...@redhat.com> wrote:

> Hi folks,
>
> I'm happy to finally reveal a project I've been working on for a few
> months:
>
> https://github.com/tliron/puccini
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tliron_puccini&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ&m=MJRff2sguAcB41OPSRvEKIOauXFg2qB1GXlB6-k40Yg&s=iIvWzlLCDDMOCmFaeg--LgVtF_pFqsmW5jUbFv_v5LQ&e=>
>
> The gist of Puccini:
>
> 1) Very fast and full-featured stateless TOSCA compiler
> 2) Targets Kubernetes directly (more targets to come)
> 3) Finally introduces an "intermediary format" for TOSCA, called "Clout"
>
> For ONAP, I humbly suggest that it could provide 1) a way to deploy
> containerized VNFs while staying entirely in TOSCA and CSAR, and 2) a
> possible alternative to Helm in order to minimize the number of modeling
> languages in the project. Or neither! This is not an official proposal,
> just the beginning of a discussion that with hopefully expand our
> imagination on ways to solve some thorny architectural problems.
>
> I'll be presenting it in Beijing next week, but will be happy to answer
> questions here, too.
>
> Also, to be clear: this is *not* an official or endorsed Red Hat project.
>
> For a comparison with AriaTosca, see this message
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.apache.org_mod-5Fmbox_ariatosca-2Ddev_201806.mbox_-253CCANvR1OT3teUgPH78hE6Yx1E2RQ19JmxaoG7iN8-2DBv6-253D-5FMp-5FRVQ-2540mail.gmail.com-253E&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ&m=MJRff2sguAcB41OPSRvEKIOauXFg2qB1GXlB6-k40Yg&s=ACbxqoH0UKjv5bYWJLk8IdIFGnhh8HhUkNEeObHD49w&e=>
> .
>
> _______________________________________________
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwICAg&c=
> udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-
> 2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ&m=
> MJRff2sguAcB41OPSRvEKIOauXFg2qB1GXlB6-k40Yg&s=gsMHRQj-
> oDHwMcitvir9lRjevH7VUwkUECsh5qCiSeQ&e=
>
>
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Reply via email to