Sorry for not responding until now as I have been traveling. Two things....
Design time There is a questionnaire in onboarding which collects information so that any special needs can be considered (manually) for VIM setup offline ahead of any deployment. Aspects of the HEAT are captured in the design model during onboarding and I believe you could also capture custom extensions. Run Time The ONAP optimisation framework (which looks at the model) which intends to help SO to make a homing/placement decision on which VIM or data centre to use could do this based on the extensions required by the model Most of what I have said will be in place for the R1 or is in place now - however I suggest that if this functionality is vital to you that you work with one of the use case teams to get this entered as part of the flow Regards Mark On 18 Jun 2017, at 17:49, Viswa KSP <[email protected]<mailto:[email protected]>> wrote: Hi Mark Pond, "MSO receives the HEAT from SDC through the distribution scheme, not via A&AI" => So this must be happening through DMAAP ?? "Whatever processes the HEAT extension needs to be installed and working in Openstack " => So then this becomes a requirement for deployment. But then this is not captured well in design phase, isn't it? In a typical service provider scenario, design & deployment happen in multiple isolated team and design team won't have access to deployment VIM ( managed VIM ). So in that case, there should be some indication / notification that actually indicates the admin ( one who deploys VNFs ) that this model contains vendor extensions, that are needed to be pre-installed in VIM isn't it? Please let me know if I'm missing anything here. Once again thanks for helping me understand heat validation better. BR, VIswa On Sun, Jun 18, 2017 at 7:17 PM, Mark Pond <[email protected]<mailto:[email protected]>> wrote: MSO receives the HEAT from SDC through the distribution scheme, not via A&AI Whatever processes the HEAT extension needs to be installed and working in Openstack Regards Mark On 18 Jun 2017, at 11:52, Viswa KSP <[email protected]<mailto:[email protected]>> wrote: Hi Tal Halfon, Thanks for details. If I understand correctly, I deduce that new extensions can be added by overriding a known interface. In that case, may I ask how does the vendor extensions cascaded in deployment time. i.e In SDC, I'm uploading a heat artifact with vendor extensions and by overriding this validator, my implementation would be called to validate the same. So in design time everything goes smooth. This VSP would then be promoted as VNF / network service and be distributed. In deployment time, AAI would pull these models from SDC and then feed it to MSO, which would then call openstack APIs to on-board the VNF in NFVI. Here, how about the extensions be handled? Should this then require a manual step of patching HEAT component with downstream openstack ? BR, Viswa On Sun, Jun 18, 2017 at 3:17 PM, Halfon Tal <[email protected]<mailto:[email protected]>> wrote: Hi SDC has its own validation logic that can be configured. The validations is not based on OpenStack. User can add new Validators (as code base libraries) and disable others There is a configuration framework that user can build its own extension to the validation mechanism and then run with SDC. The configuration is supporting only build time and not run time How Does it work: The validation lib contains number of validators, each one contains its own validations. Every validator implements the "Validator" interface, and has to override the "validate" method. this method gets a globalContext, which contains the files to validate and the validation error messages for each file. this context is shared between all the validators, and we "move" it from one to another in order to collect all the possible validation messages, since there is no dependency between the validators. A validator can get enabled/disabled using configuration, and as a result - all of its validations will get enabled/disabled. Best regards Tal Halfon Development Manager @ Amdocs P. +972 54 2213763 [cid:[email protected]] <image002.jpg> From: ROSE, DANIEL V [mailto:[email protected]<mailto:[email protected]>] Sent: Friday, June 16, 2017 7:20 PM To: Viswa KSP <[email protected]<mailto:[email protected]>> Cc: Kedar Ambekar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Halfon Tal <[email protected]<mailto:[email protected]>> Subject: RE: [onap-discuss] Disabling heat validation in SDC ? As sdc has to deconstruct the heat and then create a tosca from it, yes you need to enhance both heat to tosca and heat parser logic for new stuff. Contrail is included out of the box though which is something vmx uses I think? Anything else custom would be development work in sdc. Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: Viswa KSP [mailto:[email protected]] Sent: Friday, June 16, 2017 5:27 AM To: ROSE, DANIEL V <[email protected]<mailto:[email protected]>> Cc: Kedar Ambekar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Halfon Tal <[email protected]<mailto:[email protected]>> Subject: Re: [onap-discuss] Disabling heat validation in SDC ? Thanks Daniel. In that case may I ask, how heat extensions are managed? Will this require a patch to said heat component? BR, Viswa On Thu, Jun 15, 2017 at 10:37 PM, ROSE, DANIEL V <[email protected]<mailto:[email protected]>> wrote: https://gerrit.onap.org/r/gitweb?p=sdc.git;a=tree;f=openecomp-be/lib/openecomp-heat-lib/src/main;hb=refs/heads/master<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdc.git-3Ba-3Dtree-3Bf-3Dopenecomp-2Dbe_lib_openecomp-2Dheat-2Dlib_src_main-3Bhb-3Drefs_heads_master&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=MlBSwCNay_heO0jqrdC-7fY2r0ijHgbn81bc_BAzdp8&s=CRPBqHx79pGOIm2pD9LDu1xqmE2-QRfOkBKgj0B6il4&e=> has the heat types and is not just a call to openstack Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Viswa KSP Sent: Thursday, June 15, 2017 10:35 AM To: Kedar Ambekar <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Halfon Tal <[email protected]<mailto:[email protected]>> Subject: Re: [onap-discuss] Disabling heat validation in SDC ? Dear All, Does ONAP SDC has a customer HEAT validator inbuilt or whether the HEAT validation goes all the way down to Openstack VIM? Basically I would like to understand how custom extensions of HEAT are being validated in SDC. * If HEAT validation is being done at downstream openstack level, then extensions based on existing HEAT resources ( like Juniper vMX case ) or extensions based on HEAT plugins will be done based on capability extended by HEAT component. * Or In other words, you need to manually install HEAT plugins in server component and validation will then be cascaded back to SDC level. * If HEAT validation is bring done at SDC level, that means you are having a standalone HEAT parser. * If so, how the custom extensions based on derivations and heat plugins are being performed? * If I have a HEAT resource based on my own HEAT plugin, how am I suppose to install that in SDC inorder to make the validation happen? BR, Viswa On Wed, Jun 14, 2017 at 6:03 PM, Kedar Ambekar <[email protected]<mailto:[email protected]>> wrote: Thank you. I will try with 1.0-STAGING-latest tag. From: Halfon Tal [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, June 14, 2017 10:26 PM To: Kedar Ambekar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: Disabling heat validation in SDC ? Do not catch there later :) But use the latest one and seams that it works Best regards Tal Halfon Development Manager @ Amdocs P. +972 54 2213763 [cid:[email protected]] <image002.jpg> From: Kedar Ambekar [mailto:[email protected]] Sent: Wednesday, June 14, 2017 2:18 PM To: Halfon Tal <[email protected]<mailto:[email protected]>> Subject: RE: Disabling heat validation in SDC ? Ohh ! You are saying if I update to the latest SDC build, it will accept the zip I sent without making any change ? From: Halfon Tal [mailto:[email protected]] Sent: Wednesday, June 14, 2017 9:14 PM To: Kedar Ambekar <[email protected]<mailto:[email protected]>> Subject: RE: Disabling heat validation in SDC ? It was the zip you sent me Best regards Tal Halfon Development Manager @ Amdocs P. +972 54 2213763 [cid:[email protected]] <image002.jpg> From: Kedar Ambekar [mailto:[email protected]] Sent: Wednesday, June 14, 2017 2:03 PM To: Halfon Tal <[email protected]<mailto:[email protected]>> Subject: RE: Disabling heat validation in SDC ? Thanks Halfon !! Could you share the zip as well ? I received only screenshot confirming success in second email. KeDar Ambekar | Network Services | Tech Mahindra • Desk: +91 20 66018100 x 2879 <image003.gif.awsec> Mobile: +91 95616 50414 ( Current : +61 416 521 949) From: Halfon Tal [mailto:[email protected]] Sent: Wednesday, June 14, 2017 7:54 PM To: Kedar Ambekar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: Disabling heat validation in SDC ? Sorry I attach it now Best regards Tal Halfon Development Manager @ Amdocs P. +972 54 2213763 [cid:[email protected]] <image002.jpg> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Halfon Tal Sent: Wednesday, June 14, 2017 12:53 PM To: Kedar Ambekar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] Disabling heat validation in SDC ? Hi I succeed do it on my environment. Please look at the attach Are you using the last build/code of SDC in ONAP. We contribute some new validation and supporting more HEAT validation then before. Best regards Tal Halfon Development Manager @ Amdocs P. +972 54 2213763 [cid:[email protected]] <image002.jpg> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kedar Ambekar Sent: Wednesday, June 14, 2017 9:51 AM To: [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] Disabling heat validation in SDC ? Hi Halfon, Ok, got it. Thanks ! PFA zip that contains Juniper vMX heat templates taken from GitHub. From cloned files, we have removed the ones not needed for our topology. Also as mandated by guidelines, we have added env file (with some dummy values) for every YAML. Appreciate if you suggest on changes needed. From: Halfon Tal [mailto:[email protected]] Sent: Wednesday, June 14, 2017 4:35 PM To: Kedar Ambekar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: Disabling heat validation in SDC ? Hi Basically there is no way to disable the heat validation using configuration Can you send me the Heat zip that I will be able to check it for you? Can you capture the error and send it? Best regards Tal Halfon Development Manager @ Amdocs P. +972 54 2213763 [cid:[email protected]] <image002.jpg> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kedar Ambekar Sent: Wednesday, June 14, 2017 7:38 AM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] Disabling heat validation in SDC ? Hi All, We are trying to onboard a Vendor Software Product. SDC is not accepting the corresponding zip file saying its invalid (doesn’t give more details in UI ! ). We have found that there many violations of mandatory heat guidelines due to which SDC is accepting the zip. But changing the templates so that these guidelines get passed is very tedious work. Any possibility that this validation can be disabled in SDC for time being ? Thank you. ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=rmOBybenslXv2Gx2QKU_O4alGlrBedVFcOjxYEc5ZT0&e=> externally http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=NEdawXrZMGKy4vtIHN7g1TQtLv3mfUl1I0gitdGVkQw&e=> internally within TechMahindra. ============================================================================================================================ This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=HSc1Lb8w9B8Abr1nGgUeIwyR8mDZMhXcTGhU8Y_Tv3k&e=> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=HSc1Lb8w9B8Abr1nGgUeIwyR8mDZMhXcTGhU8Y_Tv3k&e=> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=HSc1Lb8w9B8Abr1nGgUeIwyR8mDZMhXcTGhU8Y_Tv3k&e=> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=HSc1Lb8w9B8Abr1nGgUeIwyR8mDZMhXcTGhU8Y_Tv3k&e=> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=HSc1Lb8w9B8Abr1nGgUeIwyR8mDZMhXcTGhU8Y_Tv3k&e=> _______________________________________________ onap-discuss mailing list [email protected]<mailto:[email protected]> https://lists.onap.org/mailman/listinfo/onap-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=1zDcNEx_-0exV1dNPKzM2ZP7IQlxFgyVF7qAimA27mw&s=4ILkgbSpFe4OPtyxe8DsdYG26Q-R6YGl3I077yrXtKo&e=> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer _______________________________________________ onap-discuss mailing list [email protected]<mailto:[email protected]> https://lists.onap.org/mailman/listinfo/onap-discuss This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
