When introducing significant changes to the VNF Validation Program (VVP) project or changes that may require discussion.  It recommended that a Proposal be created.  The wiki page will be the place to collaborate and track changes as the proposal is reviewed, revised, and ultimately accepted or rejected.

Please follow these steps when creating a proposal.

  1. Copy the Proposal Template and create a page under the Proposals section of the VNF Requirements Wiki.
  2. Update the content of your proposal and set the status to Draft
  3. Create a JIRA ticket in the VNF Validation Program (VVP) project announcing the proposal, and also put a reference to the ticket on the Proposals page
    1. Project: VNF Validation Program
    2. Issue Type: Epic
    3. Summary: Proposal Review:Title of Proposal
    4. Description: Link to proposal


Current Proposals

  • No labels

6 Comments

  1. Steven Wright

    What's common between these three proposals?,

    What are the three different use cases - Why do we need three different things here ?

    Is there overlap/redundancy ?

  2. Vincent Scharf

    In my opinion, each of this proposal is a "frontend" for the validation scripts in a more or less complex way. For the Linter and the stand-alone tool, the use-cases are pretty straightforward. The stand-alone tool is just a package that provides an environment for the validation scripts and generates advanced reports that help the developer debug his VNF easier. The Linter on the other side is meant to be used in a CI/CD chain to automate the validation of the HEAT files. VVP-web is a different approach. It is meant to provide a central validation platform for everyone to use. It manages and validates the VNF HEAT templates in "projects" and offers analytics components for the management to track the progress similar to GitLab. It is meant to be a collaboration tool for ONAP VNF development.

    So every tool targets a completely different core use case. The overlap/redundancy I see is the generation of reports. I think we should outsource the report generation component into its own project which should be used by every "frontend" component. This way we guarantee that whichever solution the user decides to use we have a standardized report format which can be exchanged inside the community and will be understandable for everyone.

  3. Trevor Lovett

    Currently the report generation (HTML, CSV, and Excel) is part of the core validation-scripts project which all front-ends would consume already.  Is there a specific reason we need to break it out into a separate project?  I agree we should standardize and reuse to the greatest extent possible, but I'm concerned having a separate project for the reports introduces some extra complexity into the development, build, and distribution process so I wouldn't want to do that unless there were some clear benefits to it.

  4. Vincent Scharf

    Trevor Lovett I assumed, that you, like me, did not use the core validation scripts HTML output when building your stand-alone tool. I agree, that having the generation of the outputs in the core scripts is probably the best. So for the VVP-web this means I have to replace the report generation with the built-in one.

    1. Trevor Lovett

      Sounds good. Yes, when we added the new reporting options we built them into the CLI version of the tool so the reports could be produced even if you opted to not use the stand-alone tool.

      1. Vincent Scharf

        That would be perfect! Having every toolset providing the same output is the core feature if we want to provide three different approaches for different use cases.