Thanks Mark. I have much clarity now. BR, Viswa
On Fri, Jun 23, 2017 at 12:15 PM, Mark Pond <[email protected]> wrote: > 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]> 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]> 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]> 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]> >> 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 >>> >>> >>> >>> [image: cid:[email protected]] <image002.jpg> >>> >>> >>> >>> *From:* ROSE, DANIEL V [mailto:[email protected]] >>> *Sent:* Friday, June 16, 2017 7:20 PM >>> *To:* Viswa KSP <[email protected]> >>> *Cc:* Kedar Ambekar <[email protected]>; >>> [email protected]; Halfon Tal <[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] >>> <[email protected]>] >>> *Sent:* Friday, June 16, 2017 5:27 AM >>> *To:* ROSE, DANIEL V <[email protected]> >>> *Cc:* Kedar Ambekar <[email protected]>; >>> [email protected]; Halfon Tal <[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]> wrote: >>> >>> https://gerrit.onap.org/r/gitweb?p=sdc.git;a=tree;f=openecom >>> p-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]] *On Behalf Of *Viswa KSP >>> *Sent:* Thursday, June 15, 2017 10:35 AM >>> *To:* Kedar Ambekar <[email protected]> >>> *Cc:* [email protected]; Halfon Tal <[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]> >>> wrote: >>> >>> Thank you. I will try with 1.0-STAGING-latest tag. >>> >>> >>> >>> *From:* Halfon Tal [mailto:[email protected]] >>> *Sent:* Wednesday, June 14, 2017 10:26 PM >>> >>> >>> *To:* Kedar Ambekar <[email protected]>; >>> [email protected] >>> *Subject:* RE: Disabling heat validation in SDC ? >>> >>> >>> >>> Do not catch there later J >>> >>> But use the latest one and seams that it works >>> >>> >>> >>> >>> >>> Best regards >>> >>> Tal Halfon >>> >>> >>> >>> Development Manager @ Amdocs >>> >>> >>> >>> P. +972 54 2213763 >>> >>> >>> >>> [image: cid:[email protected]] <image002.jpg> >>> >>> >>> >>> *From:* Kedar Ambekar [mailto:[email protected] >>> <[email protected]>] >>> *Sent:* Wednesday, June 14, 2017 2:18 PM >>> *To:* Halfon Tal <[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] <[email protected]>] >>> >>> *Sent:* Wednesday, June 14, 2017 9:14 PM >>> *To:* Kedar Ambekar <[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 >>> >>> >>> >>> [image: cid:[email protected]] <image002.jpg> >>> >>> >>> >>> *From:* Kedar Ambekar [mailto:[email protected] >>> <[email protected]>] >>> *Sent:* Wednesday, June 14, 2017 2:03 PM >>> *To:* Halfon Tal <[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] <[email protected]>] >>> >>> *Sent:* Wednesday, June 14, 2017 7:54 PM >>> *To:* Kedar Ambekar <[email protected]>; >>> [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 >>> >>> >>> >>> [image: cid:[email protected]] <image002.jpg> >>> >>> >>> >>> *From:* [email protected] [ >>> mailto:[email protected] >>> <[email protected]>] *On Behalf Of *Halfon Tal >>> *Sent:* Wednesday, June 14, 2017 12:53 PM >>> *To:* Kedar Ambekar <[email protected]>; >>> [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 >>> >>> >>> >>> [image: cid:[email protected]] <image002.jpg> >>> >>> >>> >>> *From:* [email protected] [ >>> mailto:[email protected] >>> <[email protected]>] *On Behalf Of *Kedar Ambekar >>> *Sent:* Wednesday, June 14, 2017 9:51 AM >>> *To:* [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] <[email protected]>] >>> >>> *Sent:* Wednesday, June 14, 2017 4:35 PM >>> *To:* Kedar Ambekar <[email protected]>; >>> [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 >>> >>> >>> >>> [image: cid:[email protected]] <image002.jpg> >>> >>> >>> >>> *From:* [email protected] [ >>> mailto:[email protected] >>> <[email protected]>] *On Behalf Of *Kedar Ambekar >>> *Sent:* Wednesday, June 14, 2017 7:38 AM >>> *To:* [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/Di >>> sclaimer.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] >>> 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] >> 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 >
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
