<div dir="ltr"><div>Hi Tackers,</div><div><br></div><div>For those who attended OpenStack Summit recently, hope you all took some time to take a break and come back refreshed. </div><div><br></div><div>Here are some highlights from the Tacker design summit event. If I've missed anything or you've some thoughts on things mentioned below, please chime in.</div><div><br></div><div>- VNF Forwarding Graph Descriptor Support </div><div><br></div><div>   We have iterated few times integrating Tacker with Service Function Chaining (SFC). We discussed the current focus for Newton, to introduce VNF Forwarding Graph Descriptor support using TOSCA. This will be integrated with Neutron using its networking-SFC APIs using a driver backend. A sequence of specs has been lined up for tacker-vnffg-plugin -> tacker-vnffg-sfc driver -> networking-SFC -> networking-odl. This first iteration needs to be properly scoped, though. For example; this initial version may not support multi-site, cross-AZ chaining, VDU scaling or fwd-graphs within VNF (among VDUs). These advanced scenarios will be taken up in the future (there is interest in them as heard in NFV Orchestration BoF session [4]).</div><div><br></div><div>- TOSCA parser integration</div><div><br></div><div>   <a href="https://etherpad.openstack.org/p/tacker-austin-tosca">https://etherpad.openstack.org/p/tacker-austin-tosca</a></div><div><br></div><div>   tosca-parser integration is at the heart of Tacker project. Few keys themes we decided to go after in Newton are (a) Support TOSCA enhancements and fixes for features in the Newton pipeline - VNF Forwarding Graph Descriptor and Network Services Descriptor (NSD), including support for substitution_mappings. (b) Move CSD03 items in Tacker into tosca-parser.</div><div><br></div><div>- VNF / VDU Scaling</div><div><br></div><div>  Again, we have discussed this few times over last two cycles. The initial focus for Newton is to bring in VDU AutoScaling using alarm-based monitoring policy and Ceilometer. The design should factor in supporting Manual Scaling of specific VDU VMs. Key things to handle per-VDU Tacker features like config-drive/ cloud-init, mgmt-driver and monitoring-driver need to stay intact as the VDUs scale out / in. It was a godsend when Heat core-team member joined this discussion at the right time! Also, Tacker needs to leverage existing TOSCA enhancements in flight in heat-translator project for this work item.</div><div><br></div><div>- Network Services Descriptor (NSD)</div><div>  NSD TOSCA template would allow multiple VNFs to be instantiated using one TOSCA template. When combined with VNF FGD descriptor this will be quite powerful. A quick poll of the attendees showed this is a useful feature for the community.</div><div><br></div><div>- Multi-Tenancy</div><div><br></div><div>Multi-Tenancy was one of the interesting discussions during on summit. There is an interest to introduce Multi-Tenancy in non-MultiSite Tacker deployments. Multi-tenancy in MultiSite Tacker deployments seems to way out of scope for just Tacker to handle. We need solutions from other projects like Keystone Federation, Tricircle or others to enable support for that. Meanwhile, there is a desire to introduce basic single site multi-tenancy in Tacker. There was an observation w.r.t different Tacker components might need different privilege. For e.g. Tacker NFVO could use a higher privilege to handle things like Flavor create. Tacker VNFM might be able to operate with a lower privileged user. </div><div><br></div><div>- Refactoring - Infra Driver</div><div>   a) Create VNF: Move most TOSCA parsing steps and config/mgmt-driver handling from Heat-driver to plugin side. </div><div>   b) Delete VNF: Use OpenWRT mgmt-driver as the gold standard, reference mgmt-driver. For, e.g., have OpenWRT mgmt-driver to remove configs previous applied as part of the Delete workflow.</div><div><br></div><div>- VNF Audit Trail</div><div><br></div><div>Today VNF "status" is the only visibility into the state of VNF. The desire is to introduce a capability to store an audit trail of all VNF state transitions along with its timestamps and dispositions. A follow-on work item would be to support an external message bus using Zaqar to "emit" them for an external OSS/BSS system to integrate.</div><div><br></div><div>- CSAR support</div><div><br></div><div>   CSAR support will be introduced in two phases. First, CSAR bundle support with TOSCA template + glance image (without custom mgmt-driver and monitoring-driver). There is an opportunity to integrate with Glare to store CSAR zip bundle. In the second phase, which is the end goal here, is to introduce VNF specific mgmt and monitoring driver scoped for that specific VNF and that can be introduced at tacker runtime (as opposed to having this configured in tacker.conf and setup.cfg). There was a concern raised w.r.t malicious code coming and running in the context of mgmt-driver. This is a valid concern; we need to introduce capabilities like CSAR bundle signing before those dynamic scripts can be introduced into Tacker.</div><div><br></div><div>- Extendable VIM Infra Driver </div><div><br></div><div>  Cloudify team is interested in introducing new VIM Infra Driver type to integrate Tacker with Aria. The "ask" from them is to send the TOSCA template as-is to the infra-driver as the DSL is quite different from the default TOSCA-NFV profile supported by Tacker. A couple of options that stood out are (a) to send both parsed TOSCA DOM tree and unparsed TOSCA template as-is to the infra driver to handle such variation. (b) carve out TOSCA parsing as a pluggable component that is VIM dependent. More discussions needed on this.</div><div><br></div><div>Bottomline, there is a desire to enable innovation in this area where different vendors might bring in specialized Tacker VIM infra-drivers. Of course, the community will continue to focus on delivering a full-featured, open source, openstack based reference VIM Infra Driver.</div><div><br></div><div>- Decomposed Tacker Server</div><div><br></div><div>  On the architecture evolution side, there is a desire to evolve from the current single process, greenlets based tacker-server to more decomposed tacker runtimes (like tacker-api, tacker-engine, tacker-mon-agent). Such an architecture will be useful to both cluster-ize and containerize tacker components.</div><div><br></div><div>- Align with ETSI IFA011 (VNF Packaging)</div><div>  Few community members requested Tacker to align with the new VNF Packaging specification coming out from ETSI NFV ISG. </div><div><br></div><div>- NFVO & VNFM separation</div><div>  There is a continued desire to have these two functions available as separate components within Tacker. Currently, they are separate components (extensions) within Tacker. </div><div><br></div><div>- Cross-Project integration with Murano, Glare, Kingbird</div><div><br></div><div>  There is an opportunity to integrated, leverage and collaborate with different openstack projects:</div><div><br></div><div>  Glare - to store TOSCA artifacts</div><div>  Murano - to collaborate on a common Catalog for VNFs and NSDs</div><div>  Kingbird - to consume MultiSite Quota / Resource Reservation</div><div><br></div><div>References:</div><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/tacker-newton-summit">https://etherpad.openstack.org/p/tacker-newton-summit</a></div><div>[2] <a href="https://etherpad.openstack.org/p/tacker-newton-refactoring">https://etherpad.openstack.org/p/tacker-newton-refactoring</a></div><div>[3] <a href="https://etherpad.openstack.org/p/tacker-austin-tosca">https://etherpad.openstack.org/p/tacker-austin-tosca</a></div><div>[4] <a href="https://etherpad.openstack.org/p/austin-2016-nfv-orchestration-bof">https://etherpad.openstack.org/p/austin-2016-nfv-orchestration-bof</a></div><div><br></div></div>