Re: [opnfv-tech-discuss] [Auto] CI for Auto thoughts
Thanks for your feedback ! In the same order of your 9 bullet points: 1) dedicated pod, 2nd pod, robustness: That particular pod is reserved for Auto. It is bare-metal, with 6 separate machines. There might indeed be a need in the future for a 2nd pod, but we're not there yet ;) Can you check if the Jenkins slave on that pod is correctly configured and robust ? 2) job frequency, per branch Yes, the master branch can be triggered daily (even if no repo change). In the early weeks/months, there should not be any overload on the pod. Indeed, for the stable/ branch, it only needs to be triggered when there was a change. Maybe also do a weekly sanity/health check. 3) job definition in YAML file in releng repo and job content in project repo The structure was inspired by the armband project, and I guess is the same for all projects ? It is the same approach used for the documentation (doc file names centralized in opnfvdocs repo, doc files distributed in project repos). Centralized content is changed less frequently than distributed content. 4) conditional sequence of job groups Yes, certainly, no point trying subsequent jobs in case one fails. Just one comment, though: some jobs near the end of the pipeline will be performance measurements (test cases). They will need to "pass" from a software execution point of view, but even if the measured performance is "poor" (against some SLA target numbers for example), the pipeline still needs to continue. The result analysis phase afterwards will sort things out. In other words, quantitative "quality/performance failures" should not interrupt a pipeline like binary pass/fail "execution failures". 5) output filtering, full logs retention period Sure, that can help. Specific Auto test cases will definitely have customized outputs in files or DBs (to capture metric values), not just standard outputs to the console. Also, repetitive analysis could be designed, which could look systematically into the full logs (data mining, even ML/AI ultimately, to empirically fine-tune things like policies and thresholds) 6) sharing Verify and Merge Agreed: it sounds to me like Merge is a special case of Verify (last Verify of a change/patch-implied sequence of Verifies). 7) storing artefacts into OPNFV I'm not familiar with this, but I'd say the test case execution results could end up in some OPNFV store, maybe in Functest, or in this artifactory. For the installation jobs, some success/failure results may also be stored. The ONAP-specific results might be shared with ONAP. 8) OPNFV and ONAP versions as parameters Yes, absolutely. And additional parameters would be CPU architectures, VNFs (and their versions too), clouds (start with OpenStack: various versions, then AWS+Azure+GCP+... and their versions), VM image versions, There could easily be way too many parameters, leading to combinatorial explosion: better order another 10 or 100 pods already ;) 9) OPNFV installer, ONAP deployment method as parameters Yes, likewise: yet other parameters. I suppose the combination of parameters will have to be controlled and selected manually, not the full Cartesian product of all possibilities. We'll be debriefing this discussion during the next Auto weekly meeting (June 11th): https://wiki.opnfv.org/display/AUTO/Auto+Project+Meetings Best regards, Gerard From: Klozik Martin [mailto:martin.klo...@tieto.com] Sent: Monday, June 4, 2018 9:40 AM To: opnfv-tech-discuss@lists.opnfv.org Cc: Tina Tsou ; Gerard Damm (Product Engineering Service) Subject: [Auto] CI for Auto thoughts ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** Hi Auto Team, I've read the CI related wiki page at https://wiki.opnfv.org/display/AUTO/CI+for+Auto and I would like to discuss with you a few thoughts based on my experience with CI from OPNFV vswitchperf project. * I agree, that a dedicated POD should be reserved for Auto CI. Based on the length of the job execution and the content of VERIFY & MERGE jobs, it might be required to introduce an additional (2nd) POD in the future. I would prefer a bare metal POD to virtual one to simplify the final setup and thus improve its robustness. * Based on the configuration, daily jobs can be triggered daily or "daily if there was any commit since the last CI run" (pollSCM trigger). The second setup can easy the load at CI POD - useful in case that POD is shared among several projects or jobs, e.g. more compute power is left for VERIFY/MERGE jobs. I suppose that in case of Auto the frequency will be really daily to constantly verify OPNFV & ONAP (master branch) functionality even if Auto repository was not modified. In case of stable release it doesn't make sense to run it on daily basis as OPNFV & ONAP versions will be fixed. * I agree with the split of functionality between job definition yaml file (in releng repo) and real job "body"
[opnfv-tech-discuss] [Auto] update of Enterprise vCPE Use Case and test cases definition
Hello, There is an existing description of Auto Use Case 3 (Enterprise vCPE) from last year: https://wiki.opnfv.org/display/AUTO/Auto+Use+Cases#AutoUseCases-UseCase3 (with a related proposal at: https://wiki.opnfv.org/display/AUTO/Use+Case+proposal%3A+Enterprise+vCPE ). We've prepared an update of the test cases and corresponding JIRA tickets (existing and planned new), summarized here: https://wiki.opnfv.org/display/AUTO/Use+case+3+%28Enterprise+vCPE%29+analysis The Auto team would be interested in your feedback on the definition of this Enterprise vCPE Use Case and its test cases (please reply here, or even better post comments on the Wiki pages for easier reference). Many thanks in advance ! Best regards, Gerard Damm The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
[opnfv-tech-discuss] [opnfvdocs] automated/manual publishing
Hi, Can someone clarify (or point to a webpage where it is already explained) the publishing mechanics of OPNFV docs, after the Gerrit approval stage ? Specifically, what is automated, and what is manual ? For the Platform overview page (http://docs.opnfv.org/en/latest/release/overview.html), there is a manual process, according to: http://docs.opnfv.org/en/latest/how-to-use-docs/documentation-guide.html But for the rest of the documentation, this page: http://docs.opnfv.org/en/latest/how-to-use-docs/addendum.html indicates that there is a Jenkins-based automation after the Gerrit-level merge, for documents like user guides, that should take about 15 minutes. Then, for example, these 2 User Guide pages would be updated automatically as per this process: Features: http://docs.opnfv.org/en/latest/release/userguide.introduction.html Testing: http://docs.opnfv.org/en/latest/testing/testing-user.html Is that correct ? Or is there some manual edition to be done (e.g., in the source files of the 2 pages listed above), to add references to new projects ? Thanks in advance for details and pointers and best regards, Gerard The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
Re: [opnfv-tech-discuss] [OPNFV Documentation, opnfvdocs] submodule for Auto project
I've also tried with the password-protected HTTP, and with SSH, and keep getting error messages like these: fatal: remote error: Upload denied for project 'opnfvdocs' remote: Unauthorized fatal: Authentication failed The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
[opnfv-tech-discuss] [OPNFV Documentation, opnfvdocs] submodule for Auto project
Hi,
Following this page:
http://docs.opnfv.org/en/latest/how-to-use-docs/include-documentation.html
I've tried to create a placeholder for Auto documentation (I have a local
folder, with the recommended subfolder structure, with 9 new .rst files, and 3
index.rst files, ready to be uploaded).
I have trouble connecting to Gerrit, either using git review ("Could not
connect to Gerrit" error),
or git push origin HEAD:refs/for/master with Gerrit-generated HTTP password
("Upload denied for project 'opnfvdocs'" error)
Any suggestion ?
Git bash dump pasted below.
Thanks,
Gerard Damm
$ cd opnfvdocs/docs/submodules/
$ git submodule add https://gerrit.opnfv.org/gerrit/auto
Cloning into
'D:/<...snip...>/Auto-docs-local-repo/opnfvdocs/docs/submodules/auto'...
remote: Total 9 (delta 0), reused 9 (delta 0)
Unpacking objects: 100% (9/9), done.
warning: LF will be replaced by CRLF in .gitmodules.
The file will have its original line endings in your working directory.
$ git submodule init auto/
$ git submodule update auto/
$ git add .
$ git commit -sv
[master 246d32f5] Signed-off-by: Gerard Damm <gerard.d...@wipro.com>
2 files changed, 4 insertions(+)
create mode 16 docs/submodules/auto
$ git review
git: 'review' is not a git command. See 'git --help'.
<that's an issue of not being able to install git-review on this machine.
I've tried on another machine where I could install git-review, and in that
case, I'm getting a
"Could not connect to Gerrit" error>
$ git remote -v
origin https://gerrit.opnfv.org/gerrit/opnfvdocs (fetch)
origin https://gerrit.opnfv.org/gerrit/opnfvdocs (push)
$ git push origin HEAD:refs/for/master
fatal: remote error:
Upload denied for project 'opnfvdocs'
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments. WARNING: Computer viruses can be transmitted via email. The
recipient should check this email and any attachments for the presence of
viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email. www.wipro.com
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
[opnfv-tech-discuss] [OPNFV Auto] installation of ONAP on the Auto Arm pod
Hello everybody, About the installation of ONAP with DCAE on the Arm pod (OPNFV Auto project), how can we best converge ? Maybe initiate a discussion on these 2 mailing lists (ONAP and OPNFV-Auto), and then arrange for an ad-hoc audio conference later this week ? It seems the preferable direction is to aim for an ONAP/Kubernetes variant. Adolfo, your name was mentioned about a successful (at least partially) install of ONAP on Arm-based OD1000 (SoftIron OverDrive 1000). Would you be able to chip in ? Is there a URL with info on that ONAP installation ? The Arm-compatible VNFs can be either on K8S or OpenStack (as long as there are enough resources on the Arm pod to have multiple co-existing environments). The VNFs would have to be installed via ONAP (i.e. onboarded via SDC, and deployed via VID), not via an installer. DCAE does not run yet on K8S, but hopefully will at some point. The Resilience Improvements tests need DCAE, because they require VI monitoring and CLAMP closed loops enforcing: see https://wiki.opnfv.org/display/AUTO/Auto+Use+Cases#AutoUseCases-UseCase2 with test pattern updated after today's Auto meeting (Monday Feb/19). Best regards, Gerard Damm The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
[opnfv-tech-discuss] [Auto] VNFs and ONAP setup for Kubernetes and Arm pod at UNH
Hello, Does anyone have pointers to open-source (containerized) VNFs for Kubernetes ? (something like this: http://dougbtv.com/nfvpe/2017/05/30/vnf-asterisk-kubernetes/, thanks Joe Kidder for sharing the link!) Even more specifically, Arm-compatible VNFs ? And which would be a recommended ONAP install setup (i.e. successfully tried at least once) to manage and use them ? (among those listed at https://wiki.onap.org/display/DW/ONAP+on+Kubernetes). The target for that installation is the Auto Arm pod at UNH IOL. Best regards, Gerard Damm The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
