Re: [opnfv-tech-discuss] [Auto] CI for Auto thoughts

2018-06-05 Thread gerard.d...@wipro.com
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

2018-04-10 Thread gerard.d...@wipro.com
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

2018-03-11 Thread gerard.d...@wipro.com
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

2018-03-04 Thread gerard.d...@wipro.com
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

2018-03-02 Thread gerard.d...@wipro.com
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

2018-02-19 Thread gerard.d...@wipro.com
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

2018-02-16 Thread gerard.d...@wipro.com
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