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