Re: [opnfv-tech-discuss] [infra-wg] [infra][releng] proposal for RELENG project to take ownership of docker build resources

[Yujun Zhang (ZTE)]

Hi, Fatih

Thanks for the reply. It aligned my understanding of releng with the
current situation and future planning.

I agree that some problem may be caused by incorrect usage of releng repo
and we have already made some effort to make it right from project's
side[1].

In my opinion, there are something we could do in releng

   1. clean up and refactor the wrappers and triggers, some work is already
   in progress[2]
   2. provide a guideline for projects about best practise of using releng

I would be very happy to contribute on these part if the releng team wants
to push these things forward :-)

Excuse me for being a bit off topic on "docker build resources"...

[1]: https://gerrit.opnfv.org/gerrit/#/c/39395/
[2]: https://gerrit.opnfv.org/gerrit/#/c/39309/


On Wed, Nov 1, 2017 at 5:42 PM Fatih Degirmenci <
fatih.degirme...@ericsson.com> wrote:

> Hi Yujun,
>
>
>
> Thanks for the feedback.
>
>
>
> Releng aims to provide a similar service to the OPNFV projects like you
> explained but some of the limitations you listed below are due to Jenkins
> itself and how to manage CI in a consistent manner.
>
> We need to keep some kind of alignment and ensure that what we are doing
> on Jenkins and CI in general fits into the overall framework.
>
>
>
> In general, only the Jenkins job configurations and simple wrapper scripts
> should be located in releng repo. (excluding common utilities such as Test
> Result API which will move into a separate repo)
>
> The scripts that do project specific stuff such as running unit tests,
> builds and so on should be owned, developed, and maintained by
> corresponding projects.
>
>
>
> The overall structure followed by releng is like this or from [1].
>
> - preprocessing
>
> - actual build/test
>
> - postprocessing
>
>
>
> Preprocessing is simply doing general cleanup stuff, fixing permissions
> and so on before the actual build starts and this is common for all
> projects.
>
> Postprocessing deals with similar common stuff such as uploading artifacts
> to artifact repo.
>
>
>
> The scripts that are consumed by releng from projects are the ones that
> matter and I expect that these change more often than Jenkins jobs or
> wrappes themselves.
>
> Normally you don't need to touch jobs/wrappers if you are not doing a
> total structure change such as changing the job type from Freestyle to
> Multijob.
>
> These scripts are generally located in /ci/build.sh,
> /ci/test.sh which get executed by the wrapper scripts which
> in turn run by Jenkins jobs.
>
>
>
> When it comes to docker; it is a bit different since the use of docker
> containers for the test projects started in releng as common/community
> initiative and the build scripts have been in releng repo
> developed/maintained by the community at large, not just releng itself.
>
> But this is due wanting to have some kind of alignment and historical
> reasons which can be changed if the projects require different way of doing
> builds and so on. (I think Storperf is an example to this.)
>
>
>
> We have plans to look into Zuul v3 and start a PoC but we are waiting for
> OpenStack to finalize their migration and fix the issues they are
> experiencing.
>
> But we also need to keep in mind that we go further in our CI comparing to
> OpenStack so it is not just about OpenStack fixing all the issues but also
> fulfilling OPNFV needs. (one problem we will face is the number/types of
> plugins we use on our Jenkins and the impacts of having long running tests.)
>
>
>
> If you can point to specific examples or list additional needs we can take
> them into our backlog and improve what we do.
>
>
>
> [1]
> https://wiki.opnfv.org/download/attachments/11699697/image2017-6-6%2022%3A56%3A30.png?version=1=1496783473000=v2
>
>
>
> /Fatih
>
>
>
> *From: *<infra-wg-boun...@lists.opnfv.org> on behalf of "Yujun Zhang
> (ZTE)" <zhangyujun+...@gmail.com>
> *Date: *Wednesday, 1 November 2017 at 02:19
> *To: *David McBride <dmcbr...@linuxfoundation.org>
> *Cc: *"infra...@lists.opnfv.org" <infra...@lists.opnfv.org>, test-wg <
> test...@lists.opnfv.org>, "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>, Trevor Cooper <
> trevor.coo...@intel.com>
> *Subject: *Re: [infra-wg] [infra][releng] proposal for RELENG project to
> take ownership of docker build resources
>
>
>
> Not sure I fully understand the word "ownership" and the scope of building
> resources. For sure it is good to maintain the build scripts and *global*
> config in releng.
>
>
>
> But for project specific configuratio

Re: [opnfv-tech-discuss] [infra-wg] [infra][releng] proposal for RELENG project to take ownership of docker build resources

[Yujun Zhang (ZTE)]

Not sure I fully understand the word "ownership" and the scope of building
resources. For sure it is good to maintain the build scripts and *global*
config in releng.

But for project specific configuration, it is not so convenient to manage
them in a central repository. Sometimes I have to wait for committers of
releng to merge my patch which just fixes a small bug of the the build job
for my project. Most time the validation of releng job is only possible
*after* the patch is merged. When I found it does not work, I have to go
over the steps again. It is not so productive since this workflow involves
two teams (releng and project).

Ideally, I would expect releng to provide the building resource as a
service  and the project specific configuration managed inside project
repository. This is much like the solution provided by some CI SaaS like
Travis-CI[1]. And also the trend in OpenStack infra brought in by zuul v3,
which is called in repo configuration.

This is not just about docker building, but also applies for other
verification job.

[1]: https://travis-ci.org/
[2]: https://docs.openstack.org/infra/manual/zuulv3.html#what-is-zuul-v3

On Wed, Nov 1, 2017 at 5:56 AM David McBride <dmcbr...@linuxfoundation.org>
wrote:

> please +1, 0, or -1 to indicate your position
>
> Team,
>
> This topic came up during our release meeting two weeks ago.  I took an
> action to get a discussion started in the infra meeting.
>
> The proposal is for the RELENG project to take ownership of docker build
> resources (scripts,config files, etc.)
> <https://gerrit.opnfv.org/gerrit/gitweb?p=releng.git;a=tree;f=jjb/releng>
>  for the purpose of providing a common docker build capability available to
> all users of OPNFV CI.  Active committers to these resources will remain
> unchanged.
>
> We had a good discussion on Monday.  There was general consensus that this
> proposal makes sense.  The minutes are here
> <http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2017/opnfv-meeting.2017-10-30-14.59.html>.
>
>
> I took an action at the infra meeting to start a discussion on the mailing
> list to seek additional feedback.  Please respond to this email to indicate
> whether you support the proposal.  Also feel free to add your comments.
> Thanks.
>
> David
>
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
> ___
> infra-wg mailing list
> infra...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/infra-wg
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] New PTL of QTIP project

[Yujun Zhang (ZTE)]

I am happy to announce that Zhihui Wu is elected as new PTL for QTIP
project[1].

Congratulations, Zhihui

[1]: https://gerrit.opnfv.org/gerrit/#/c/45157/

On Mon, Oct 16, 2017 at 9:13 AM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
wrote:

> QTIP committers
>
> There have been no further nominations for the QTIP PTL position.
> Therefore Zhihui Wu is the sole candidate.
>
> To provide a record of this and acknowledgement from QTIP committers
> please vote on gerrit[1] indicating your approval/disapproval (+2, -2) for
> Zhihui to take over as PTL effective from the Fraser release.
>
> [1]: https://gerrit.opnfv.org/gerrit/#/c/45157/
>
> On Mon, Oct 9, 2017 at 8:05 PM 吴之惠 <zhihui.wu2006+...@gmail.com> wrote:
>
>>  I would like to accept the nomination for QTIP PTL and only hope that I
>> can be an excellent PTL like Yujun. :-)
>>
>>
>> Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>于2017年10月9日周一 下午4:32写道：
>>
>>> All,
>>>
>>> I'm opening the nomination period for QTIP PTL election. You may
>>> nominate yourself or others *before Oct 15th*.
>>>
>>> I would like to nominate Zhihui WU (wu.zhih...@zte.com.cn) as new PTL
>>> for QTIP. She has been active in the project since D release and make a
>>> major contribution to it. I believe she will lead the project to a new
>>> level.
>>>
>>> --
>>> Yujun
>>> --
>>> Yujun Zhang
>>>
>> ___
>>> opnfv-tech-discuss mailing list
>>> opnfv-tech-discuss@lists.opnfv.org
>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>>
>> --
> Yujun Zhang
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates with gerrit

[Yujun Zhang (ZTE)]

Hi, Alec

See my additional comments.

On Thu, Oct 19, 2017 at 10:06 PM Alec Hothan (ahothan) <ahot...@cisco.com>
wrote:

> Hi Yujun,
>
>
>
> The stable branch is created a few weeks before the release data and a lot
> can happen in a few weeks. It could be lots of small commits related to
> docs, lots of trivial fixes. The point I wanted to make is that you do not
> want to see all these small detail commits on your release branch and hence
> the notion of having a “clean” release branch devoid of detailed small
> commits that do not need to be tracked at that level of branch.
>
> Say you have 20 commits to fix docs or 20 trivial fixes in code in the
> week before release, will you want to have 20 commits on stable branch or
> one?
>

One by one, since this is the history of amending the stable branch, we
should keep it as it is. If we don't want to see trivial fixes, the right
way could be squash them *BEFORE* submitting to master branch.


> This is a case where a merge makes sense rather than cherry picking each
> of them.
>

Normally, when we created stable branch, the master branch is mainly used
for new feature development of next release. It may not be a good idea to
merge them to stable branch. That's why we use cherry-pick to select only
the bug fix and document amending. And this can not be done with merge.


> Another case where merges make sense is when you deliver 5.1.0 with
> possibly lots of new enhancements to 5.0, it makes sense to merge rather
> than cherry pick lots of commits.
>

This also confuses me a lot, since the release date for 5.1.0 and 5.2.0 is
overlapped with 6.0.0 development cycle. Normally I would add *NOTHING* new
in 5.1.0 or 5.2.0 except for bug fixes. All new features goes into 6.0.0.
This may save you from cherry-picking a bundle of commits and separate
feature development from bug fixing.

My another 2 cents.


-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates with gerrit

[Yujun Zhang (ZTE)]

This could do the trick but I don't quite recommend it. There would be some
commits on master you do NOT want to include in stable branches.

I suggest to pick commits carefully after inspection and do the cherrypick *one
by one *on gerrit. It will keep a record of which patch sets have been
cherry-picked in review history (not just git log).

If you have too many patch sets to be cherrypicked. Something may have gone
wrong. By the time we created stable branch, it should be considered as a
*stable* branch and not expecting too many changes, except for bug fix and
document amending.

My 2 cents.

On Thu, Oct 19, 2017 at 6:04 AM Trevor Bramwell <
tbramw...@linuxfoundation.org> wrote:

> Hey Alec,
>
> Here's a quick way to cherry-pick these all over to the stable/euphrates
> branch. Though you'll still need to submit them all through Gerrit:
>
>   git checkout euphrates
>   git cherry -v stable/euphrates master | cut -d' ' -f2 | xargs -I{} git
> cherry-pick -x '{}'
>
> 'git review' will ask you to confirm you want to upload multiple
> patchsets. A 'yes' should put all of them up for review.
>
> Regards,
> Trevor Bramwell
>
> On Wed, Oct 18, 2017 at 08:14:59PM +, Alec Hothan (ahothan) wrote:
> > I have many commits in master which I’d like to merge to
> stable/euphrates.
> > Would like to check if anybody knows how to merge master into a release
> branch using gerrit?
> > Looks like I may need the permission to upload merges with Gerrit.
> >
> > Here is what I did:
> >
> > $ git fetch origin  stable/euphrates:euphrates
> > $ git checkout euphrates
> >
> > $ git merge master –no-ff
> >
> > # at this point, so far so good, I got all my commits into my euphrates
> branch
> >
> > # git review fails due to permission:
> >
> > $ git review
> > Warning: Permanently added '[gerrit.opnfv.org]:29418,[198.145.29.81]:29418'
> (RSA) to the list of known hosts.
> > remote: Processing changes: refs: 1, done
> > To ssh://gerrit.opnfv.org:29418/nfvbench.git
> > ! [remote rejected] HEAD -> refs/publish/master/euphrates (you are not
> allowed to upload merges)
> > error: failed to push some refs to 'ssh://
> ahot...@gerrit.opnfv.org:29418/nfvbench.git'
> >
> >
> > Is there a different way to achieve this?
> > I do not want to cherry pick my commits as I have too many of them.
> >
> > Thanks
> >
> >   Alec
> >
>
> > ___
> > opnfv-tech-discuss mailing list
> > opnfv-tech-discuss@lists.opnfv.org
> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] voting for new PTL of QTIP project

[Yujun Zhang (ZTE)]

QTIP committers

There have been no further nominations for the QTIP PTL position. Therefore
Zhihui Wu is the sole candidate.

To provide a record of this and acknowledgement from QTIP committers please
vote on gerrit[1] indicating your approval/disapproval (+2, -2) for Zhihui
to take over as PTL effective from the Fraser release.

[1]: https://gerrit.opnfv.org/gerrit/#/c/45157/

On Mon, Oct 9, 2017 at 8:05 PM 吴之惠 <zhihui.wu2006+...@gmail.com> wrote:

>  I would like to accept the nomination for QTIP PTL and only hope that I
> can be an excellent PTL like Yujun. :-)
>
>
> Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>于2017年10月9日周一 下午4:32写道：
>
>> All,
>>
>> I'm opening the nomination period for QTIP PTL election. You may nominate
>> yourself or others *before Oct 15th*.
>>
>> I would like to nominate Zhihui WU (wu.zhih...@zte.com.cn) as new PTL
>> for QTIP. She has been active in the project since D release and make a
>> major contribution to it. I believe she will lead the project to a new
>> level.
>>
>> --
>> Yujun
>> --
>> Yujun Zhang
>>
> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>
> --
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] New PTL for VSPERF

[Yujun Zhang (ZTE)]

Congratulations, Sridhar Rao!

--
Yujun Zhang


On Fri, Oct 13, 2017 at 12:53 AM Singh, Gurpreet <gurpreet.si...@spirent.com>
wrote:

> Congratulations Sridhar!
>
>
>  Original message 
> From: "Cooper, Trevor" <trevor.coo...@intel.com>
> Date: 10/12/17 12:43 PM (GMT-05:00)
> To: opnfv-tech-discuss@lists.opnfv.org, opnfv-...@lists.opnfv.org
> Subject: [opnfv-tech-discuss] New PTL for VSPERF
>
> Congratulations to our new VSPERF PTL … Sridhar Rao from Spirent a leading
> supplier of Network Test Solutions.
>
>
>
>
>
> What is VSPERF? … VSPERF is an automated test-framework and test
> suite based on Industry Test Specifications for measuring data-plane
> performance of the virtual switch including physical and virtual network
> interfaces. The VSPERF architecture is switch and traffic generator
> agnostic and test cases can be easily customized. VSPERF is stand-alone
> i.e. independent of OpenStack so it sources, configures and deploys the
> device-under-test with component versions and network topology defined by
> the user. A new IETF benchmarking specification RFC8204 is based on VSPERF
> work and VSPERF is contributing to development of ETSI NFV test
> specifications.
>
>
>
> How is VSPERF used?   …VSPERF is used as a development tool for
> optimizing switching technologies, qualification of packet processing
> functions and for evaluation of data-path performance. It is also being
> used to study correlations between measured platform metrics and data-plane
> performance.
>
>
>
> What is new in Euphrates?…New test cases, flexibility in
> customizing test-cases, new results display options, improved tool
> resiliency, additional traffic generator support and VPP support.
>
>
>
> What do VSPERF users have to say?
>
>
>
> -  VSPERF provides a platform where the entire Industry can learn
> more about NFVI dataplane benchmarking, and try-out new techniques
> together.
>
>
>
> -  VSPERF CI testing has proven to be a valuable asset when
> examining the consistency and repeatability of the current LTD benchmarks
> with different deployment scenarios and vSwitches.
>
> -  We have found the tool invaluable for the upstream community
> to be able to determine what configuration they want to use for their
> environment
>
> -  Being able to independently quantify the overhead of
> switching, including being able to demonstrate the differences in
> acceleration technologies … is a key benefit
>
>
>
> -  Vswitch is a key element of NFV and … it is us critical to
> qualify the performance of such component and to get reference on testing
> on other PODs.
>
> -  Allow faster "hands-on" comparisons for people wanting to
> verify unbiased test results ... using an open-source tool, with
> open-source software traffic generators to quickly setup and automate tests
>
> -   vSwitch benchmarking is a must-to-do ... Vsperf has
> integrated popular software traffic generator, ready to use, no extra cost.
>
>
>
> /Trevor
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> 
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the taking of
> any action based upon reliance on the contents of this transmission is
> strictly forbidden. If you have received this message in error please
> notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676 <+44%201293%20767676>
> Fax No. +44 (0) 1293 767677 <+44%201293%20767677>
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300 <(818)%20676-2300>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] opening nomination period for QTIP PTL election

[Yujun Zhang (ZTE)]

All,

I'm opening the nomination period for QTIP PTL election. You may nominate
yourself or others *before Oct 15th*.

I would like to nominate Zhihui WU (wu.zhih...@zte.com.cn) as new PTL for
QTIP. She has been active in the project since D release and make a major
contribution to it. I believe she will lead the project to a new level.

--
Yujun
-- 
Yujun Zhang
___
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-project-leads] [release][euphrates] proposal to eliminate one of the two point releases for Euphrates

[Yujun Zhang (ZTE)]

+1

On Thu, Oct 5, 2017 at 2:45 AM David McBride <dmcbr...@linuxfoundation.org>
wrote:

> Team,
>
> Please respond to this mail with (+1, 0, -1) and your thoughts,
> suggestions, or alternatives.
>
> During the TSC call on Tues, Oct 3, the TSC agreed to slip the initial
> Euphrates release (5.0) to October 20.  In addition, I also proposed
> eliminating one of the two point releases (5.1, 5.2) planned for
> Euphrates.  The reasoning was as follows:
>
>1. Moving the 5.0 release to Oct 20 places that release just 3 weeks
>before the planned release of 5.1 (Nov 10).
>2. Slipping 5.1 and 5.2 could have negative consequences for the OPNFV
>"F" release, as happened with Euphrates when we decided to slip Danube 3.0.
>
> Therefore, the proposal is to eliminate the planned release on Nov 10, so
> that there would just be one point release on Dec 15.
>
> The proposal is described in more detail in the slide deck that I
> presented during the TSC meeting
> <https://wiki.opnfv.org/display/meetings/TSC#TSC-October3,2017> (see link
> labeled "euphrates contingency.pptx" under the heading "Euphrates update").
>
> David
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
> ___
> opnfv-project-leads mailing list
> opnfv-project-le...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [releng][testresults] test results repo and reporting page

[Yujun Zhang (ZTE)]

Hi, all

I noticed that releng-testresults has already been split from releng.

Does it mean all changes to testresults.opnfv.org should be submit to
releng-testresults instead of releng?

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

[Yujun Zhang (ZTE)]

+1 for Fraser <https://en.wikipedia.org/wiki/Fraser_River>

I agree that it could be problematic if we name the release after something
difficult to find in map.

On Tue, Sep 26, 2017 at 12:25 AM Raymond Paik <rp...@linuxfoundation.org>
wrote:

> All:
>
> Thanks for voting on the release naming poll.
>
> First, for G-release the winner is Gambia (the first African river for
> OPNFV).
>
> For the F-release, the top vote getter was Fenix in Argentina.  However,
> after some research it looks this is a tributary of another river (Deseado
> <https://en.wikipedia.org/wiki/Deseado_River>), and I wasn't able to find
> photos of Fenix River on the web (or even find it on Google Maps).
>
> I talked to LF marketing colleagues as we've been using river images for
> release marketing, and they do have concerns about going with a river that
> is not well known.  The second choice was Fraser
> <https://en.wikipedia.org/wiki/Fraser_River> in Canada (the longest river
> in British Columbia) and I suggest going with Fraser as the F-release
> name.  Although Fenix sounds cool, I think it's problematic if you can't
> find it on a map.
>
> Let me know if you have any questions.
>
> Ray
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

[Yujun Zhang (ZTE)]

I had a quick look at the wiki page and try to understand the rationale
behind proposal.

If I understand it correctly, it is like

- *opnfv-x.y.z* to sync with OPNFV official releasing cycle, i.e. Danube,
Euphrates (opnfv-5.y.z).
- *(optional) x.y.z* for project intermediate release which is managed by
each project.

Please correct me if anything wrong. I would vote +1 based on the
understanding above.

On Tue, Sep 26, 2017 at 3:34 AM Alec Hothan (ahothan) <ahot...@cisco.com>
wrote:

>
>
> I would like to get a quick vote from any person that works directly or
> indirectly with code in OPNFV
>
>
>
> Please reply with -1, 0 +1
>
>
>
> For using prefixed git tags for the Euphrates release: “opnfv-5.0.0”
>
>
>
> This is a slight change to the plan on record (which was to use “5.0.0”).
> This does NOT impact euphrates deliverables for participating OPNFV
> projects (git tags on stable/euphrates are applied by releng).
>
> The only externally visible effect is the naming of container tags for 
> *Euphrates
> official images* in DockerHub will be named accordingly (e.g.
> “opnfv/functest:opnfv-5.0.0”).
>
> Everything else remains the same.
>
>
>
> If you’d like to know more, the rationale is described here:
> https://wiki.opnfv.org/display/releng/OPNFV+projects+and+OPNFV+release+versioning
> (thanks for Fatih, David, Frank, Tapio for reviewing)
>
> In a nutshell, this adjustment is needed to prepare the path for proper
> continuous delivery support by projects.
>
> Any clarification/questions/discussion can be done over email or at the
> TSC or release meetings tomorrow.
>
>
>
> Thank You.
>
>
>
>   Alec
>
>
>
>
> _______
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [qtip] Nomination of Committer(s) promotion for: Taseer Ahmed and Akhil Batra

[Yujun Zhang (ZTE)]

+ cc mailing list

On Tue, Sep 19, 2017 at 10:10 AM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
wrote:

> I would like to nominate Taseer Ahmed and Akhil Batra as QTIP committers.
>
> Both of them have been contributed a lot[1][2] in Euphrates release[3] and
> it will be a great help to the project to have them as committers.
>
> QTIP committers please vote +1/-1 on gerrit. Thanks.
>
>- https://gerrit.opnfv.org/gerrit/#/c/42365/
>- https://gerrit.opnfv.org/gerrit/#/c/42367/
>
>
> [1] https://git.opnfv.org/qtip/log/?qt=author=tasee...@gmail.com
> [2]
> https://git.opnfv.org/cgit/qtip/log/?qt=author=akhil.ba...@research.iiit.ac.in
> [3]
> http://stackalytics.com/?project_type=opnfv-group=commits=qtip=pike
>
> --
> Yujun Zhang
>
-- 
Yujun Zhang
___
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-tsc] [announce] Opening nominations for Committers-at-Large TSC & Committer Board elections

[Yujun Zhang (ZTE)]

Yes, I accept the nomination.

On Fri, Sep 8, 2017 at 10:38 PM Raymond Paik <rp...@linuxfoundation.org>
wrote:

> Thanks Julien...
>
> Yujun, do you accept the nomination?
>
> Ray
>
> On Fri, Sep 8, 2017 at 7:06 AM, Julien <julien...@gmail.com> wrote:
>
>> Hi all,
>>
>> I would like to nominate Yujun (ZTE) for the TSC at-large
>> election. He has done a great work as QTIP PTL. He has enough knowledge
>> in open source community. He has worked for several open source projects
>> before joining in OPNFV. During his leadership QTIP project cooperates with
>> not only  OPNFV projects but also Openstack projects and great success has
>> been achieved.
>>
>> BR/Julien
>>
>>
>> Raymond Paik <rp...@linuxfoundation.org>于2017年9月4日周一 上午1:43写道：
>>
>>> All,
>>>
>>> I'm kicking off the nomination process for Committers-at-Large TSC
>>> (electing 5 members) plus the Committer Board (electing 1) elections.
>>>
>>> The list of eligible committers who can run for & vote in both elections
>>> are posted here, and I want to encourage all eligible committers to
>>> nominate community members who can represent the OPNFV technical community
>>> in both the TSC and the Board.  Self nominations are also welcome.   As I
>>> mentioned earlier in the week, I hope to see a diverse group of community
>>> members represented--in terms of geography, gender, projects,  service
>>> providers/vendors, etc.--in the nominations.
>>>
>>> Nominations should be posted to opnfv-tech-discuss & opnfv-tsc mailing
>>> lists by 5pm Pacific Time on September 8th (Friday).  You are welcome to
>>> reply to this email or if you're sending out a separate note, please
>>> include phrases like "Committer Board nomination" or "Committer-at-Large
>>> TSC nomination" in email subjects.  In nomination statements, please list
>>> the following information:
>>>
>>>- Which election (TSC vs. Board) the nomination is for
>>>- Name of the nominee
>>>- Organization
>>>- A brief description of nominee's qualifications
>>>
>>> As nominations are accepted, I will add them to this page
>>> <https://wiki.opnfv.org/display/DEV/Nominees+for+2017+Elections>.
>>> There will be separate Condorcet ballot for these two elections, and they
>>> will be sent out by September 11th.
>>>
>>> Thanks,
>>>
>>> Ray
>>>
>>> ___
>>> opnfv-tsc mailing list
>>> opnfv-...@lists.opnfv.org
>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tsc
>>>
>>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
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-project-leads] [release][euphrates] Milestone 6 - August 25

[Yujun Zhang (ZTE)]

Hi David,

Response from QTIP project

1. Console output of jenkins job

- Compute QPI:
https://build.opnfv.org/ci/view/qtip/job/qtip-compute-apex-master/15/console
- Storage QPI:
https://build.opnfv.org/ci/view/qtip/job/qtip-storage-apex-master/7/console

2. Document compliance page filled.

On Fri, Aug 25, 2017 at 6:49 AM David McBride <dmcbr...@linuxfoundation.org>
wrote:

> Team,
>
> As you know, MS6 is scheduled for tomorrow, August 25.  MS6 has two
> requirements:
>
>1. Complete test case implementation for test cases documented in the
>test case database for MS2.
>2. Complete preliminary documentation.  This means, at a minimum,
>committing the directory structure to your repo and adding placeholder
>files for the documents that you intend to deliver.
>
> Compliance verification:
>
>1. Please send me a link to the console output of your test cases
>running under Jenkins in OPNFV CI.
>2. Please complete the documentation compliance page for MS6 for your
>project.
>
> Let me know if you have questions.  Thanks.
>
> David
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
> ___
> opnfv-project-leads mailing list
> opnfv-project-le...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [releng] docker build fails

[Yujun Zhang (ZTE)]

Hi releng,

It seems the docker build service is not available. Is there anybody who
can have a look?

Something seems wrong with the docker daemon on the server[1]:

[qtip-docker-build-push-master] $ /bin/bash /tmp/hudson2319564546050375447.sh
Starting opnfv-docker for opnfv/qtip ...


Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is
the docker daemon running?
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is
the docker daemon running?
Current branch: master
Building docker image: opnfv/qtip:latest


docker build --no-cache -t opnfv/qtip:latest --build-arg BRANCH=master
-f Dockerfile .
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is
the docker daemon running?


[1]:
https://build.opnfv.org/ci/view/docker/job/qtip-docker-build-push-master/416/console



-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [releng] unable to post comments to gerrit from jenkins job

[Yujun Zhang (ZTE)]

Hi releng,

I'm trying to use the macro 'report-build-result-to-gerrit'[1] to post
comments from a CI job, but get an error about "Permission denied"[2].

Is there any restriction of using this macro?

See part of the log below.

+ ssh -p 29418 -o 'StrictHostKeyChecking no' gerrit.opnfv.org 'gerrit
review -p qtip  -m "Document link(s):

https://nbviewer.jupyter.org/urls/artifacts.opnfv.org/qtip/review/37731/compute-qpi-report/report.ipynb

https://nbviewer.jupyter.org/urls/artifacts.opnfv.org/qtip/review/37731/storage-qpi-report/storage-qpi.ipynb;
 cef0d6f511eaec6242664969ecbeb127c4d1c4b2  --notify
NONE'
Warning: Permanently added '[gerrit.opnfv.org]:29418' (RSA) to the
list of known hosts.
Permission denied (publickey).
Build step 'Execute shell' marked build as failure


[1]: https://git.opnfv.org/releng/tree/jjb/global/releng-macros.yml#n262
[2]: https://build.opnfv.org/ci/job/qtip-review-notebook-master/4/console

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [anteater] build log for anteator

[Yujun Zhang (ZTE)]

Yes, that's what I am seeking.

When a comment is posted by a bot, I would be curious on where this message
is coming from. I suppose it is posted from some periodic check task?


On Fri, Jul 14, 2017 at 7:00 AM Julien <julien...@gmail.com> wrote:

> Oh,
>
> I understand the issue: no output of the detailed log of the Jenkins task.
>
> Luke, I will deal with this.
>
>
> Luke Hinds <lhi...@redhat.com>于2017年7月13日周四 下午10:13写道：
>
>> How do you mean by build log Yujun? I am always interested in feedback /
>> improvements.
>>
>>
>> On Wed, Jul 12, 2017 at 4:10 AM, Yujun Zhang (ZTE) <
>> zhangyujun+...@gmail.com> wrote:
>>
>>> I notices a warning on license header in
>>> https://gerrit.opnfv.org/gerrit/#/c/36839/
>>>
>>> [image: Screen Shot 2017-07-12 at 11.03.55 AM.png]
>>>
>>> However the build log is not posted. It's OK for now since the failure
>>> is clear enough. But it would be nice to have the build log as well as
>>> other CI jobs.
>>>
>>> --
>>> Yujun
>>>
>>> --
>>> Yujun Zhang
>>>
>>> ___
>>> opnfv-tech-discuss mailing list
>>> opnfv-tech-discuss@lists.opnfv.org
>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>>
>>>
>>
>>
>> --
>> Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
>> e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 |
>> t: +44 12 52 36 2483
>> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>
> --
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [anteater] build log for anteator

[Yujun Zhang (ZTE)]

I notices a warning on license header in
https://gerrit.opnfv.org/gerrit/#/c/36839/

[image: Screen Shot 2017-07-12 at 11.03.55 AM.png]

However the build log is not posted. It's OK for now since the failure is
clear enough. But it would be nice to have the build log as well as other
CI jobs.

--
Yujun

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Multiple docker containers from one project

[Yujun Zhang (ZTE)]

Does anybody consider using the build service from docker-hub[1] ?

It supports multiple Dockerfile from same repository and easy to integrate
with OPNFV Github mirror.

[1]: https://docs.docker.com/docker-hub/builds/


On Thu, Jul 6, 2017 at 11:02 PM Jose Lausuch <jose.laus...@ericsson.com>
wrote:

> Hi Mark,
>
>
>
> I would incline for option 1), it sounds better than searching for a file.
> We could define specific values of DOCKERFILE var for each project.
>
>
>
> /Jose
>
>
>
>
>
> *From:* Beierl, Mark [mailto:mark.bei...@dell.com]
> *Sent:* Thursday, July 06, 2017 16:18 PM
> *To:* opnfv-tech-discuss@lists.opnfv.org
> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci <
> fatih.degirme...@ericsson.com>; Jose Lausuch <jose.laus...@ericsson.com>
> *Subject:* Re: [opnfv-tech-discuss] Multiple docker containers from one
> project
>
>
>
> Ideas:
>
>
>
>- Change the DOCKERFILE parameter in releng jjb so that it can accept
>a comma delimited list of Dockerfile names and paths.  Problem with this,
>of course, is how do I default it to be different for StorPerf vs.
>Functest, etc?
>- Change the opnfv-docker.sh to search for the named DOCKERFILE in all
>subdirectories.  This should cover the .aarch64 and vanilla docker file
>cases.
>
>
>
> Please +1/-1 or propose other ideas, thanks!
>
>
>
> Regards,
>
> Mark
>
>
>
> *Mark Beierl*
>
> SW System Sr Principal Engineer
>
> *Dell **EMC* | Office of the CTO
>
> mobile +1 613 314 8106 <1-613-314-8106>
>
> *mark.bei...@dell.com <mark.bei...@dell.com>*
>
>
>
> On Jun 24, 2017, at 04:05, Jose Lausuch <jose.laus...@ericsson.com> wrote:
>
>
>
> +1
>
>
>
> No need for an additional repo, the logic can be in Releng..
>
> Functest will probably move to different containers some time soon, so
> that is something we could also leverage.
>
>
>
> -Jose-
>
>
>
>
>
> On 23 Jun 2017, at 18:39, Julien <julien...@gmail.com> wrote:
>
>
>
> Agree,
>
>
>
> If StorPerf can list some rules and examples, current scripts can be
> adapted for multiple docker image building and other project can use this
> type of changes. It is not deserved to add a new repo just for build a new
> image.
>
>
>
>
>
>
>
> Fatih Degirmenci <fatih.degirme...@ericsson.com>于2017年6月21日周三 上午2:26写道：
>
> Hi Mark,
>
>
>
> It is perfectly fine to have different build processes and/or number of
> artifacts for the projects from releng point of view.
>
>
>
> Once you decide what to do for storperf, we can take a look and adapt
> docker build job/script to build storperf images, create additional repos
> on docker hub to push images and activate the builds when things are ready.
>
>
> /Fatih
>
>
> On 20 Jun 2017, at 19:18, Beierl, Mark <mark.bei...@dell.com> wrote:
>
> Hello,
>
>
>
> I'd like to poll the various groups about ideas for how to handle this
> scenario.  I have interns working on breaking down services from StorPerf
> into different containers.  In one case, it will be a simple docker compose
> that is used to fire up existing containers from the repos, but the other
> case requires more thought.
>
>
>
> We are creating a second container (storperf-reporting) that will need to
> be built and pushed to hub.docker.com.  Right now the build process for
> docker images lives in releng, and it only allows for one image to be
> built.  Should I be requesting a second git repo in this case, or should we
> look at changing the releng process to allow multiple docker images to be
> build?
>
>
>
> Regards,
>
> Mark
>
>
>
> *Mark Beierl*
>
> SW System Sr Principal Engineer
>
> *Dell **EMC* | Office of the CTO
>
> mobile +1 613 314 8106 <1-613-314-8106>
>
> *mark.bei...@dell.com <mark.bei...@dell.com>*
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip][storperf] questions on workload selection

[Yujun Zhang (ZTE)]

Hi, Mark

I have some doubts on selecting workload for storage performance testing.
It seems the configuration in StorPerf[1] is quite different from the SSS
PTS[2]

In StorPerf, it seems throughput, iops and latency are measured under the
same set of workloads.

However in SSS PTS, it selects different workload for measuring different
metrics. For example, for measuring throughput, only large block sizes
(128KiB and 1024KiB) at Sequential Read/Write (100/0, 0/100) is selected.
But in latency measurements, only small block sizes (0.5 KiB, 4KiB and
8KiB) is used.

Why is such difference, any special consideration?

[1] https://wiki.opnfv.org/display/storperf#Storperf-BlockStorage
[2] https://www.snia.org/tech_activities/standards/curr_standards/pts

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip][storperf] minimum development environment for running storperf

[Yujun Zhang (ZTE)]

Hi, Mark

Following up the project breakout session[1] on summit, we have kicked off
the integration of storperf testing for storage QPI.

The first question we have is the minimum requirements for running storperf
for *development* purpose. From my understanding, it seems to be a regular
openstack cloud will be enough, plus the following resources

   - Ubuntu 16.04 image in Glance
   - StorPerf flavor in Nova (2 CPU, 8GB RAM 4 GB disk)

Other configuration seems not relevant to testing itself, e.g.

   - The storage backend is not visible to `fio` since it tests against
   `/dev/vdb` by default, is that so?
   - generate-environment.sh seems to collect installer, network and cinder
   configuration but it seems not used by testing. Is it just for reporting?

[1]: https://etherpad.opnfv.org/p/qtip-storperf

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] cancelled Weekly meeting on 2017-05-29

[Yujun Zhang (ZTE)]

QTIP weekly meeting on May 29th is cancelled for public holiday in China

Sorry for late notification

--
Yujun

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [opnfv-summit] special travel guide for the community

[Yujun Zhang (ZTE)]

I took an action from last testperf meeting to provide a travel guide for
summit participants

Here is the link:
https://wiki.opnfv.org/display/EVNT/Beijing+Summit+Special+Travel+Guide

Calling for more volunteers to contribute to this guide, especially members
from China.

大家一起协作，为北京峰会提供一份特别的旅行指南

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [doctor] Beijing Design Summit: breakout sessions scheduling

[Yujun Zhang (ZTE)]

Carlos,

Could you please updated the sessions to the schedule[1]?

It is easier to check for confliction in a consensus table.

[1]: https://wiki.opnfv.org/display/EVNT/Beijing+Design+Summit+Schedule

On Thu, May 18, 2017 at 7:24 PM Carlos Goncalves <carlos.goncal...@neclab.eu>
wrote:

> Doctors,
>
>
>
> So far we’ve received 3 good session proposals [1]. Thanks everyone and
> feel free to propose more!
>
>
>
> I would like to start scheduling them taking into account the current room
> booking [2] as well as participants’ agenda because we have people across
> multiple projects (QTIP, Barometer, etc) with their own project sessions
> (e.g. Yujun with QTIP).
>
>
>
> Proposal draft:
>
>
>
> Text in *bold* means Doctor specific sessions; others are recommended to
> Doctor folks.
>
>
>
> DAY 1/MONDAY
>
> *11:15 – 12:15: Doctor: Host maintenance [room Sculpture]*
>
> *15:30 – 16:00: Doctor's achievements and what else you can do with it!
> [plenary]*
>
> *13:45 – 14:15: Doctor: Overview of Doctor tests refactoring to Python
> [room Sculpture]*
>
> 14:45 – 15:15: Barometer: Taking the pressure off of assurance and
> resource contention scenarios for NFVI [plenary]
>
> 16:30 – 17:00: OPNFV XCI: How to work with OpenStack Master
>
>
>
> DAY 2/TUESDAY
>
> 09:15 – 10:45: OPNFV XCI Intro, Hands on [Room Pastel]
>
> 09:45 – 10:16: Enabling Carrier-Grade availability within a cloud
> infrastructure [plenary]
>
> *14:00 – 15:00: Doctor: performance & profiling [room Pastel]*
>
>
>
>
>
> Please let us know in case you have a conflict or have other
> proposals/suggestions.
>
>
>
> [1] https://etherpad.opnfv.org/p/doctor_meetings
>
> [2] https://wiki.opnfv.org/display/EVNT/Beijing+Design+Summit+Schedule
>
>
>
> Thanks,
>
> Carlos
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-05-22

[Yujun Zhang (ZTE)]

*# QTIP project weekly meeting on 2017-05-22*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Topics*


   - weekly update


   - OPNFV summit schedule
   https://etherpad.opnfv.org/p/qtip-opnfv-summit-beijing


-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-05-15

[Yujun Zhang (ZTE)]

*https://etherpad.opnfv.org/p/qtip-meetings-2017-05-15
<https://etherpad.opnfv.org/p/qtip-meetings-2017-05-15> *

*# QTIP project weekly meeting on 2017-05-15*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Topics*


   - weekly updates


   - demo about ansible-semaphore


   - propose to use sunburst for QPI visualization:
   http://bl.ocks.org/vgrocha/1580af34e56ee6224d33


   - validation of test roles in docker
   https://etherpad.opnfv.org/p/qtip-docker


   - JIRA issues management


   - clean stale issues


   - track **definite** tasks or bugs only

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [summit] schedule for Design Summit

[Yujun Zhang (ZTE)]

Not sure which channel should I ask this question...

It seems currently only the schedule of OPNFV summit is published[1].

When will the schedule of *design summit* be released?

[1]: http://events.linuxfoundation.org/events/opnfv-summit/program/schedule

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda of weekly meeting 2017-05-05

[Yujun Zhang (ZTE)]

*# QTIP project weekly meeting on 2017-05-05*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - 


*## Topics*


   - Weekly updates


   - OPNFV plugfest retrospective


   - OPNFV summit sessions


   - Euphrates release plan

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Danube 2.0 release

[Yujun Zhang (ZTE)]

http://docs.opnfv.org/en/stable-danube/submodules/qtip/docs/release/release-notes/danube.html


New in Danube 2.0

^

* Bug fix in regex of ssl


NB, qtip user interface (CLI) has changed a lot since danube release. I
would encourage users to follow the master branch to try out the new
features even it is not mature so far.

Check the latest configuration guide[1] and user manual[2] for details

[1]
http://docs.opnfv.org/en/latest/submodules/qtip/docs/testing/user/configguide/configuration.html#install-from-source-code

[2]
http://docs.opnfv.org/en/latest/submodules/qtip/docs/testing/user/userguide/ansible.html


-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Cancelled weekly meeting 2017-05-01

[Yujun Zhang (ZTE)]

QTIP weekly meeting next Monday is cancelled for the International Worker's
Day.

Thanks

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [doctor] verification job in Python and the package

[Yujun Zhang (ZTE)]

I think there could be some misunderstanding about the original purpose of
https://gerrit.opnfv.org/gerrit/#/c/33381/ .

What @Wenjuan proposed at the beginning was actually a
`python-doctor-verification` package. We shall import in doctor
verification job, i.e. `python main.py`. That was the reason we had py27,
pep8, cover and pbr. They are all fundamental verification and release jobs
for the *python package, *not for* doctor feature verification.*

Anyway, we can setup the doctor verification job first and think about how
to organize the python package later.

My 2c

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda of weekly meeting

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-04-24

*# QTIP project weekly meeting on -mm-dd*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - none


*## Topics*


   - weekly updates


   - introduction of qtip runner and workspace creator using
   ansible-playbook


-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [infra] License checks in CI

[Yujun Zhang (ZTE)]

Note that

   1. the script repository has been renamed to Justin-chi/License
   2. people need to update the company list before using it, example in [1]

@Justin, could you check Github and review my pull request?

[1]: https://github.com/Justin-chi/License/pull/1/files

On Thu, Apr 20, 2017 at 10:44 PM Luke Hinds <lhi...@redhat.com> wrote:

> We have licence checking code staged for CI.
>
> 2017-04-20 15:27:43,197 - anteater.src.scan_tasks - INFO - Running Licence
> Check on: insecure-test-repo
> 2017-04-20 15:27:43,198 - anteater.src.scan_tasks - INFO - Licence Check
> passed for: /home/luke/ant_repos/insecure-python/path_traversal.py
> 2017-04-20 15:27:43,198 - anteater.src.scan_tasks - INFO - Licence Check
> passed for: /home/luke/ant_repos/insecure-python/shell_true.py
> 2017-04-20 15:27:43,198 - anteater.src.scan_tasks - ERROR - No License
> file within: /home/luke/ant_repos/insecure-python/tmp_path.py
> 2017-04-20 15:27:43,198 - anteater.src.scan_tasks - ERROR - No License
> file within: /home/luke/ant_repos/insecure-python/shell_true2.py
>
> It will search for the complete Apache 2.0 block, but will filter out text
> between:
>
> Copyright (c) 2017  and others
>
> ...As this is where an author adds unique fields, such as name, company,
> email.
>
> So this will pass for a python / bash file:
>
>
> ##
>   # Copyright (c) 2017 Donald Duck [dd...@warnerbros.com] and others.
>   #
>   # All rights reserved. This program and the accompanying materials
>   # are made available under the terms of the Apache License, Version 2.0
>   # which accompanies this distribution, and is available at
>   # http://www.apache.org/licenses/LICENSE-2.0
>
> ##
>
> So as long as someone uses the license format from the developers wiki or
> by means of Justin's license script [1], it will pass the gate. Any
> deviation from this, will get a -1 (when this is implemented at gate).
>
> I am planning on getting this rigged into CI during plugfest week. If
> anyone is interested or wants a demo, come by and say hello.
>
> [1] https://github.com/Justin-chi/Lab/blob/master/add_license.sh
>
> --
> Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
> 12 52 36 2483
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-04-17

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-04-17

*# QTIP project weekly meeting on 2017-04-17*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - yujunz create a JIRA issue to track docker build failure on master


*## Topics*


   - Euphrates roadmap - https://etherpad.opnfv.org/p/qtip-euphrates


   - Plugfest presentation rehearsal


   - Plugfest demo rehearsal

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] New project proposal: NFVbench

[Yujun Zhang (ZTE)]

Some question after reviewing the proposal.

   - Technically, is data plane / L2/L3 forwarding the *only* performance
   indicator for NFV?
   - Will NFVbench project expand to other performance metrics besides the
   main focus?
   - In what way will NFVbench plan to complement and leverage related
   projects?
   - What will be the main components of the toolkit? A test runner? Test
   cases? Drivers?

The following text are quoted for quick reference

The NFVbench project develops a *toolkit* that allows developers,
integrators, testers and customers to measure and assess the *L2/L3
forwarding performance* of an NFV-infrastructure solution stack (i.e. OPNFV
scenario) using a black-box approach.
...

The main focus of NFVbench is the NFVI full stack *data plane benchmarking*
using realistic production deployment conditions.

NFVbench does *not* focus on the following areas and will align with,
*complement
and leverage* projects that already cover properly these areas:
...

On Thu, Apr 13, 2017 at 12:40 AM Frank Brockners (fbrockne) <
fbroc...@cisco.com> wrote:

> Hi OPNFV,
>
>
>
> over the past few weeks we’ve distilled a proposals to create a toolkit to
> allow for black-box performance testing of NFVI with a network focus:
> NFVbench:
> https://wiki.opnfv.org/display/nfvbench/NFVbench+Project+Proposal
>
>
>
> The NFVbench project is to develop a toolkit that allows developers,
> integrators, testers and customers to measure and assess the L2/L3
> forwarding performance of an NFV-infrastructure solution stack (i.e. OPNFV
> scenario) using a black-box approach.
>
>
>
> We’re hoping for a discussion in the technical community meeting on
> April/20, and are also asking for an official TSC review post the technical
> community review on May/2, so that NFVbench can participate in Euphrates.
> Consequently, NFVbench asks for tentative inclusion into Euphrates.
>
>
>
> Your thoughts and ideas are greatly appreciated.
>
>
>
> Thanks much, Frank, Carsten, Alec
>
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for Weekly Meeting

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-04-10

*# QTIP project weekly meeting on 2017-04-10*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - None


*## Topics*


   - weekly update from team


   - Danube 1.0 release and 2.0 plan -
   https://etherpad.opnfv.org/p/qtip-danube


   - Euphrates plan - https://etherpad.opnfv.org/p/qtip-euphrates
   - Plugfest - https://etherpad.opnfv.org/p/qtip-plugfest


*## Recurring*


   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


*## AOB*


   - #info independent qtip docs site https://docs.qtip.io


   - #info qtip organization on github https://github.com/qtip-benchmark for
   experimental sub-projects


   - #info a site close to our vision for QTIP http://www.spec.org/


-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip][release] danube.1.0 tagged

[Yujun Zhang (ZTE)]

GIT: https://git.opnfv.org/qtip/refs/?h=danube.1.0
Docker: https://hub.docker.com/r/opnfv/qtip/tags/

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Functest] Tagging and docker build completed for Danube.1.0

[Yujun Zhang (ZTE)]

Hi, Jose

Thanks for the hint. Should RELEASE_VERSION be *`1.0`* or *`danube.1.0`*.
It seems the release name is automatically prefixed in jjb.

# Get tag version
echo "Current branch: $BRANCH"

if [[ "$BRANCH" == "master" ]]; then
DOCKER_TAG="latest"
else
if [[ -n "${RELEASE_VERSION-}" ]]; then
release=${BRANCH##*/}
DOCKER_TAG=${release}.${RELEASE_VERSION}
# e.g. colorado.1.0, colorado.2.0, colorado.3.0
else
DOCKER_TAG="stable"
fi
fi


On Sat, Apr 1, 2017 at 1:52 AM Jose Lausuch <jose.laus...@ericsson.com>
wrote:

> Hi,
>
>
>
> I did it manually from the latest built “stable” image when I tagged the
> repo. The Jenkins job we have allows you to do that automatically
> specifying the tag in the RELEASE_VERSION field (see below).
>
>
>
> You might need rights in Jenkins to run this job. If you have problems let
> me know and I can trigger the build for you.
>
>
>
>
>
>
>
>
>
> *From:* Yujun Zhang (ZTE) [mailto:zhangyujun+...@gmail.com]
> *Sent:* Friday, March 31, 2017 17:22 PM
> *To:* Jose Lausuch; TECH-DISCUSS OPNFV
> *Subject:* Re: [opnfv-tech-discuss] [Functest] Tagging and docker build
> completed for Danube.1.0
>
>
>
> Hi, Jose,
>
>
>
> When will the docker build with tag be triggered?
>
>
>
> Besides tagging in git, is there anything else  required to make it
> happen?
>
>
>
> On Fri, Mar 31, 2017 at 10:44 PM Jose Lausuch <jose.laus...@ericsson.com>
> wrote:
>
> Hi,
>
>
>
> Functest repo ready with tags:
>
> danube.1.0 :
> https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.0
>
> danube.1.RC1:
> https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.RC1
>
>
>
> Docker image built with tag “danube.1.0”
>
> https://hub.docker.com/r/opnfv/functest/tags/
>
>
>
>
>
> Thanks,
>
> Jose
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> --
>
> Yujun Zhang
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Functest] Tagging and docker build completed for Danube.1.0

[Yujun Zhang (ZTE)]

Hi, Jose,

When will the docker build with tag be triggered?

Besides tagging in git, is there anything else  required to make it happen?

On Fri, Mar 31, 2017 at 10:44 PM Jose Lausuch <jose.laus...@ericsson.com>
wrote:

Hi,



Functest repo ready with tags:

danube.1.0 :
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.0

danube.1.RC1:
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/danube.1.RC1



Docker image built with tag “danube.1.0”

https://hub.docker.com/r/opnfv/functest/tags/





Thanks,

Jose
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Cancelled Weekly Meeting 2017-04-03

[Yujun Zhang (ZTE)]

QTIP weekly meeting next Monday is *canceled* for public holiday 清明节 in
China.

Best Regards

--
Yujun Zhang
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] finalizing danube.1.0 release

[Yujun Zhang (ZTE)]

Hi, team

We have just merged the amending of document format. It seems we are ready
for the Danube.1.0 release.

Please check and see if anything is missing.

``danube.1.0`` will be tagged today[1]

[1]:
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Danube

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [doctor] about to finalize D1 release

[Yujun Zhang (ZTE)]

Fix proposed in https://gerrit.opnfv.org/gerrit/#/c/32637/


On Fri, Mar 31, 2017 at 1:08 AM David McBride <dmcbr...@linuxfoundation.org>
wrote:

> FYI - Doctor release notes link is empty
>
> http://docs.opnfv.org/en/stable-danube/release/release-notes.html
>
> David
>
> On Thu, Mar 30, 2017 at 8:49 AM, Ryota Mibu <r-m...@cq.jp.nec.com> wrote:
>
> Hi team,
>
>
> We have just merged our release notes of Doctor.
> I suppose there are nothing left for D1 release in Doctor.
> We have long backlog list though.
> Let me know if I miss something (e.g. bug) ASAP.
>
> By tomorrow, we need to express that we finished D1 activity as Doctor
> project by tagging in our stable/Danube branch [1].
>
>
> [1]
> https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Danube
>
>
> Cheers,
> Ryota
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for Weekly Meeting 2017-03-27

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-03-27

*# QTIP project weekly meeting on 2017-03-27*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - SerenaFeng to help investigate the logging issue JIRA: QTIP-230


   - all review https://gerrit.opnfv.org/gerrit/#/c/30971/ and finish
   document for Danube


   - Taseer to publish QTIP document to opnfv site


   - yujunz send Beijing Summit CFP draft for review


*## Topics*


   - CFP OPNFV Summit Beijing - https://goo.gl/rEtl13


   - Danube release - https://etherpad.opnfv.org/p/qtip-danube


   - E release planning - https://etherpad.opnfv.org/p/qtip-euphrates


*## Recurring*


   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfvdocs] docs-verify-rtd-danube fails

[Yujun Zhang (ZTE)]

Recovered. Thanks.

On Tue, Mar 21, 2017 at 5:45 PM Shubham Rathi <shubhamiiitbac...@gmail.com>
wrote:

> I think the patch to be cherry picked is this:
> https://gerrit.opnfv.org/gerrit/#/c/31093/
> In the danube branch, openretriever is off the .gitmodules file but not
> from opnfvdocs/docs/submodules/ which is causing the build to fail.
> ᐧ
>
>
> On Tue, Mar 21, 2017 at 2:14 PM, Yujun Zhang (ZTE) <
> zhangyujun+...@gmail.com> wrote:
>
> https://build.opnfv.org/ci/job/docs-verify-rtd-danube/ seems failing
> since yesterday evening and it is currently blocking all the document
> modification patch sets in projects, e.g.
> https://gerrit.opnfv.org/gerrit/#/c/31133/
>
> It should have been resolved by https://gerrit.opnfv.org/gerrit/#/c/31107/ on
> master branch. Need some committer to cherry-pick it to stable/danube and
> resolve the merge conflict.
>
> --
> Yujun
> --
> Yujun Zhang
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
> ᐧ
> ᐧ
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [opnfvdocs] docs-verify-rtd-danube fails

[Yujun Zhang (ZTE)]

https://build.opnfv.org/ci/job/docs-verify-rtd-danube/ seems failing since
yesterday evening and it is currently blocking all the document
modification patch sets in projects, e.g.
https://gerrit.opnfv.org/gerrit/#/c/31133/

It should have been resolved by https://gerrit.opnfv.org/gerrit/#/c/31107/ on
master branch. Need some committer to cherry-pick it to stable/danube and
resolve the merge conflict.

--
Yujun
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-03-20

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-03-20

*# QTIP project weekly meeting on 2017-03-20*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Topics*


   - Weekly update


   - Danube release progress https://etherpad.opnfv.org/p/qtip-danube


   - QTIP demo for Plugfest


   - CFP Beijing Summit
   https://etherpad.opnfv.org/p/qtip-opnfv-summit-beijing


-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-03-13

[Yujun Zhang (ZTE)]

Today's weekly meeting is postponed due to low participance.

New time will be notified later.

On Fri, Mar 10, 2017 at 12:56 PM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
wrote:

> https://etherpad.opnfv.org/p/qtip-meetings-2017-03-13
>
> *# QTIP project weekly meeting on 2017-03-13*
>
>
>- time: UTC0730
>
>
>- irc://#opnfv-qtip@freenode
>
>
>- index: https://etherpad.opnfv.org/p/qtip-meetings
>
>
> *## Action followup*
>
>
>- Taseer to send invitation of qtip-cli 2nd review next week
>
>
> *## Topics*
>
>
>- Danube 1.0 release notes
>
>
>- things to be followed up in Danube 2.0
>
>
>
> --
> Yujun Zhang
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [all][docs] template for release note

[Yujun Zhang (ZTE)]

Hi all,

I am starting to draft the release note for qtip.

I wonder if there is any recommended template for it. Or it is up to the
project team to define whatever they like.

-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-03-13

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-03-13

*# QTIP project weekly meeting on 2017-03-13*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - Taseer to send invitation of qtip-cli 2nd review next week


*## Topics*


   - Danube 1.0 release notes


   - things to be followed up in Danube 2.0



-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-03-06

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-03-06

*# QTIP project weekly meeting on 2017-03-06*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - all review api requirement and comment https://goo.gl/UrFzlR


   - all make proposals for OPNFV Summit Beijing before Mar 27th
   https://etherpad.opnfv.org/p/qtip-opnfv-summit-beijing


*## Topics*


   - Status update from the team


   - Danube release status update https://etherpad.opnfv.org/p/qtip-danube


*## Recurring*


   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


*## AOB*


   - #info MS7 stable branch on Mar 10th
   https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-March/015342.html


-- 
Yujun Zhang
___
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] [Danube] [Documentation] Organization of testing section

[Yujun Zhang (ZTE)]

Have we get an agreement on the document structure now?

Sorry that I missed yesterday's meeting.

--
Yujun

On Wed, Mar 1, 2017 at 9:54 PM <morgan.richo...@orange.com> wrote:

> And just to precise - the last table from my first mail could be
> mlisleading (we will exchange tomorrow during the weekly meeting)
> you shall now create a docs/testing directory reflecting the target view
> and put your docs there (as shown in Jose's patch)
>
> in your repo
> docs
> ├── release
> │   └── release-notes
> └── testing
> ├── developer
> └── user
>
> on docs.opnfv.org
> we will get
> Testing Documentation
>
>- Overview
>- User
>- Developper
>
> In Overview we will have our umbrella document
>
> in User, all the documents generated from  repo>/docs/testing/user
>
>- OPNFV FUNCTEST user guide
>
> <http://docs.opnfv.org/en/latest/submodules/functest/docs/userguide/index.html>
>- Bottlenecks - user guide
>
> <http://docs.opnfv.org/en/latest/submodules/bottlenecks/docs/userguide/index.html>
>- Yardstick Overview
>
> <http://docs.opnfv.org/en/latest/submodules/yardstick/docs/userguide/index.html>
>- VSPERF
><http://docs.opnfv.org/en/latest/submodules/vswitchperf/docs/index.html>
>- .
>
>
> in Developer, all the documents generated from  repo>/docs/testing/developer
>
> we probably should also adopt some conventions for the title to be as
> consistant as possible...
>
>   user guide
>
>  configuration guide
>
>  developer guide
>
> to be agreed tomorrow
>
> /Morgan
>
>  Le 01/03/2017 à 14:38, Jose Lausuch a écrit :
>
> Hi,
>
>
>
> Functest already following this approach:
> https://gerrit.opnfv.org/gerrit/#/c/29151/
>
>
>
> Thanks,
>
> Jose
>
>
>
> *From:* Sofia Wallin
> *Sent:* Wednesday, March 01, 2017 14:11 PM
> *To:* morgan.richo...@orange.com; David McBride
> *Cc:* opnfv-tech-discuss@lists.opnfv.org; Yujun Zhang; mark.bei...@emc.com;
> Jose Lausuch; Cooper, Trevor; Yuyang (Gabriel); Gaoliang (D)
> *Subject:* RE: [OPNFV] [Danube] [Documentation] Organization of testing
> section
>
>
>
> Hi Morgan,
>
> Yes – This is consistent with what we decided yesterday.
>
>
>
> Thank you,
>
> Sofia
>
>
>
> *From:* morgan.richo...@orange.com [mailto:morgan.richo...@orange.com
> <morgan.richo...@orange.com>]
> *Sent:* den 1 mars 2017 08:27
> *To:* Sofia Wallin <sofia.wal...@ericsson.com>; David McBride <
> dmcbr...@linuxfoundation.org>
> *Cc:* opnfv-tech-discuss@lists.opnfv.org; Yujun Zhang <
> zhangyujun+...@gmail.com>; mark.bei...@emc.com; Jose Lausuch <
> jose.laus...@ericsson.com>; Cooper, Trevor <trevor.coo...@intel.com>;
> Yuyang (Gabriel) <gabriel.yuy...@huawei.com>; Gaoliang (D) <
> jean.gaoli...@huawei.com>
> *Subject:* [OPNFV] [Danube] [Documentation] Organization of testing
> section
>
>
>
> Hi,
>
> during the last release meeting we had a discussion on the structure of
> the testing documentation for Danube
>
> we suggest to adopt the following approach for the test projects
>
> /docs
>
> |_ release
>
> ...
>|_ release-notes // release note of the projects involved in the release
>  reference http://testresults.opnfv.org/reporting
> snapshot of the status at the release date
> ...
> |_ testing
>
> testing overview // umbrella document => figure, description of the
> testing ecosystem, pointers to project documentation
> |__ user // will collect the documentation of the test
> projects allowing the end user to perform testing towards a OPNFV SUT
>  e.g.
> Functest/Yardstick/Vsperf/Storperf/Bottlenecks/Qtip installation/config &
> user guides
> |__ developer// will collect documentation to explain how to
> create your own test case and leverage existing testing frameworks
>  e.g. devloper guides
>
>
>
> the umbrella testing documentation "testing overview" is under opnfvdocs
> => will be put into /testing
>
> the other documents are in the project repos under
> /docs
> /installation guide
> /config guide
> /user guide
> /release note
> /development
> /development guide
> / interships
>
>
> ---

Re: [opnfv-tech-discuss] Project proposals for adding analytics to OPNFV

[Yujun Zhang (ZTE)]

Hi, Donald

It would be my pleasure to join the project. Signed as contributor on the
wiki page :-)

On Tue, Feb 28, 2017 at 1:12 AM Donald Hunter (donaldh) <dona...@cisco.com>
wrote:

> Hi Yujun,
>
>
>
> Yes, the Bamboo project’s goal is to use a PNDA instance to sink data from
> the various OPNFV testing projects. The first phase would involve getting a
> PNDA instance deployed and then integrating data from sources such as QTIP.
>
>
>
> The next step for us is to solicit input from project leads and hopefully
> encourage people like yourself to get involved. So your email is very
> timely. If you’d like to add your name to the contributors on the project
> proposal, that would be fantastic:
> https://wiki.opnfv.org/display/bamboo/Bamboo+Project+Proposal
>
>
>
> Many thanks,
>
> Donald.
>
>
>
> *From: *"Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
> *Date: *Friday, 24 February 2017 at 23:27
> *To: *"Frank Brockners (fbrockne)" <fbroc...@cisco.com>, "
> opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>
> *Cc: *"Koren Lev (korlev)" <kor...@cisco.com>, "John Evans (joevans)" <
> joev...@cisco.com>, "Donald Hunter (donaldh)" <dona...@cisco.com>
>
>
> *Subject: *Re: [opnfv-tech-discuss] Project proposals for adding
> analytics to OPNFV
>
>
>
> As QTIP PTL, I am particularly interested in Bamboo project.
>
>
>
> If I understand it correctly, it could be used to develop or deploy (not
> sure about the way of integration yet) the benchmark hub in QTIP
> architecture[1].
>
>
>
> The benchmark hub is supposed to be a sink of all data produced by QTIP.
>
>
>
> [1]: https://wiki.opnfv.org/display/qtip/Architecture
>
>
>
> Excuse me for late response, but better than never.
>
>
>
> On Wed, Feb 8, 2017 at 12:56 AM Frank Brockners (fbrockne) <
> fbroc...@cisco.com> wrote:
>
> Hi OPNFV,
>
>
>
> over the past few weeks we’ve distilled two proposals to add analytics and
> more diagnostic capabilities to OPNFV and OPNFV scenarios. We’ve published
> the two new project proposals on the wiki:
>
> ·   Bamboo:
> https://wiki.opnfv.org/display/bamboo/Bamboo+Project+Proposal
>
> ·   VINA: https://wiki.opnfv.org/display/vina/VINA+Project+Proposal
>
>
>
> Bamboo is to introduce the analytics infrastructure provided by PNDA.io to
> OPNFV. VINA is to offer discovery and system health status for VIMs. Both
> projects are to work and in hand and are expected to integrate with both
> Barometer, VES, Qtip, etc. – as well as integrate with the testresults
> post-processing that we already do.
>
>
>
> We’re hoping for a discussion in the technical community meeting on
> Feb/23, and are also asking for an official TSC review post the technical
> community review. Target would be the TSC call on March/7.
>
>
>
> Your thoughts and ideas are greatly appreciated.
>
>
>
> Thanks much, Frank
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> --
>
> Yujun Zhang
>
-- 
Yujun Zhang
___
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-tsc] [Announce] OPNFV E-release naming

[Yujun Zhang (ZTE)]

Big love for *Euphrates*.

Chinese students must be so familiar with 幼发拉底河
<https://zh.wikipedia.org/wiki/%E5%B9%BC%E5%8F%91%E6%8B%89%E5%BA%95%E6%B2%B3>
which
is a mandatory knowledge point for history course examination.

On Thu, Feb 23, 2017 at 9:45 PM Ash Young <a...@yunify.org> wrote:

> +1 Euphrates
>
> On Tue, Feb 21, 2017 at 6:36 AM, Raymond Paik <rp...@linuxfoundation.org>
> wrote:
>
> All,
>
> Just a quick reminder to send in your 2-3 nominations for the E-release
> name by 5pm Pacific Time this Friday (24th).
>
> Thanks,
>
> Ray
>
> On Wed, Feb 15, 2017 at 1:49 PM, Raymond Paik <rp...@linuxfoundation.org>
> wrote:
>
> All,
>
> As discussed on the last TSC call, I'd like to get the process started for
> the E-release naming.
>
> A quick reminder that we have a river theme for OPNFV releases and our
> first 4 release names are Arno (Europe), Brahmaputra (Asia), Colorado
> (Americas), and Danube (Europe).  Let's continue the tradition of rotating
> through continents/geographies, so we could venture into Africa/Oceania for
> the first time or return to Asia...
>
> Can you send me your top 2-3 nominations (at most) in the following format
> by 5pm Pacific Time on February 24th?  After I collect all the nominations,
> I'll send out a SurveyMonkey poll so the community can pick the winner.
>
> Format: River name (locations)
> For example,
>
>- Esk (Australia)
>- Euphrates (Asia)
>- etc.
>
>
> Thanks,
>
> Ray
>
>
>
> ___
> opnfv-tsc mailing list
> opnfv-...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tsc
>
>
> ___
> opnfv-tsc mailing list
> opnfv-...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tsc
>
-- 
Yujun Zhang
___
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-project-leads] [release][danube] MS6 compliance assessment

[Yujun Zhang (ZTE)]

You may use history in Github as an automatic query.

https://github.com/opnfv/storperf/commits/master/tests


On Sat, Feb 25, 2017 at 8:07 AM Beierl, Mark <mark.bei...@dell.com> wrote:

> Not really. Tests go with the code change. They are not separate.
>
>
> Regards,
> Mark
>
> *Mark Beierl*
> Advisory Solutions Architect
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-866-123-4567>
> mark.bei...@dell.com <john.gar...@dell.com>
>
>
> On Feb 24, 2017, at 18:40, David McBride <dmcbr...@linuxfoundation.org>
> wrote:
>
> Mark,
>
> Could you send me a git query, instead?  For example, for QTIP:
> https://gerrit.opnfv.org/gerrit/#/q/project:qtip+AND+topic:tests
>
> David
>
> On Fri, Feb 24, 2017 at 1:30 PM, Beierl, Mark <mark.bei...@dell.com>
> wrote:
>
> Responses for StorPerf:
>
> Test Framework Projects
>
>1. Please provide a list of commits for your self-validation tests.
>
>
> As with other projects, the list of commits would be very large.  The
> self-validation occurs on git review, and the Jenkins job can be found
> here: https://build.opnfv.org/ci/view/storperf/job/storperf-verify-master/
> There are just over 100 self-validation tests which provide 69% code
> coverage.
>
> There is now a Test Results DB dashboard for StorPerf:
> http://testresults.opnfv.org/reporting/display/master/storperf/status-apex.html
>
>
> Preliminary Documentation Requirement
>
>1. Please provide a link to the preliminary documentation for your
>project.
>
>
> http://artifacts.opnfv.org/storperf/docs/index.html
>
> Regards,
> Mark
>
> *Mark Beierl*
> Advisory Solutions Architect
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
>
>
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>
> ___
> opnfv-project-leads mailing list
> opnfv-project-le...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
>
-- 
Yujun Zhang
___
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-project-leads] [release][danube] MS6 compliance assessment

[Yujun Zhang (ZTE)]

See below for QTIP project

On Thu, Feb 23, 2017 at 4:31 AM David McBride <dmcbr...@linuxfoundation.org>
wrote:

> Team,
>
> I'd like to request that the PTLs for projects participating in Danube
> respond to the following questions, designed to assess compliance with MS6.
> Test Framework Projects
>
>1. Please provide a list of commits for your self-validation tests.
>
>
There are many commits. Some of them can be searched via

https://gerrit.opnfv.org/gerrit/#/q/project:qtip+AND+topic:tests

For a full list of test cases implemented, see

https://git.opnfv.org/qtip/tree/tests

> Preliminary Documentation Requirement
>
>1. Please provide a link to the preliminary documentation for your
>project.
>
>
See https://git.opnfv.org/qtip/tree/docs
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] bug smash day for Danube release

[Yujun Zhang (ZTE)]

QTIP runners,

We will organize a bug smash day *online* to accelerate the development for
Danube release. All developers are welcome to join us online and have *real
time collaborative coding* with the project team.

Besides, the core developers will give *two lightning talks about the basis
of QTIP development*. If you are interested in becoming a contributor,
don't miss them.

The agenda can be found in https://etherpad.opnfv.org/p/qtip-bug-smash


   - info


   - date: 2017-2-22


   - room: https://appear.in/qtip


   - participants (sign your ID here to register)


   - Yujun Zhang


   - Akhil Batra


   - Zhihui Wu


   - Julien


   - SerenaFeng


   - Taseer


   - schedule


   - UTC0030-0200 (Shanghai 8:30AM-10:00AM)


   - coding and discussion


   - UTC0215-0345 (Shanghai 10:15AM-11:45AM)


   - coding and discussion


   - UTC0530-0700 (Shanghai 1:30PM-3:00PM)


   - *lightning talk: architecture design introduction (yujunz)*


   - coding and discussion


   - UTC0730-0900 (Shanghai 3:30PM-5:00PM)


   - *lightning talk: QPI specs introduction (zhihui)*


   - coding and discussion


   - topics


   - 



-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Add license information for files without them

[Yujun Zhang (ZTE)]

+2 for gate check instead of reminding by Email.

It seems Ray has used another tool for license scanning.
Luke Hinds <lhi...@redhat.com>于2017年2月19日 周日06:32写道：

> If its useful we could add something to our gate to check for license
> text? We are trailing a system that checks for private keys, secrets and
> blobs being pushed to repos, I could look to extend this to perform a
> license check too?
>
> On Sat, Feb 18, 2017 at 5:27 PM, Yujun Zhang (ZTE) <
> zhangyujun+...@gmail.com> wrote:
>
> The script works great in qtip repo[1]. Thanks a lot, Justin.
>
> A few comments for improvements
>
>
>1. add license to this script itself so people know how to contribute.
>By default, it is proprietary.
>2. ignore __init__.py as indicated in OPNFV contribution
>guidelines[2]. A workaround is `git checkout **/__init__.py` after
>processing.
>3. use company name mapping in stackalytics[3]. I believe it covers
>most contributors in OPNFV
>4. rename the the repo. It is strange to fork a repo named Lab to
>other account.
>
>
> [1]: https://gerrit.opnfv.org/gerrit/#/c/29029/
> [2]: https://wiki.opnfv.org/display/DEV/Contribution+Guidelines
> [3]:
> http://git.openstack.org/cgit/openstack/stackalytics/tree/etc/default_data.json#n23439
>
> On Fri, Feb 17, 2017 at 10:52 AM gang chi <justin.chig...@gmail.com>
> wrote:
>
> Hi,
>
> I think most of team has received mail from Ray who told me there are over
> hundred files without License in Compass4nfv repo. I think some team may
> have same issue with me.
> so I share my script to generate license header for OPNFV repos.
>
> https://github.com/Justin-chi/Lab/blob/master/add_license.sh
>
> Here is result of the script: https://gerrit.opnfv.org/gerrit/#/c/28885/
>
> Hope it will works for you.
>
> Regards
> Justin
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> --
> Yujun Zhang
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
> --
> Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
> e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
> 12 52 36 2483
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Add license information for files without them

[Yujun Zhang (ZTE)]

The script works great in qtip repo[1]. Thanks a lot, Justin.

A few comments for improvements


   1. add license to this script itself so people know how to contribute.
   By default, it is proprietary.
   2. ignore __init__.py as indicated in OPNFV contribution guidelines[2].
   A workaround is `git checkout **/__init__.py` after processing.
   3. use company name mapping in stackalytics[3]. I believe it covers most
   contributors in OPNFV
   4. rename the the repo. It is strange to fork a repo named Lab to other
   account.


[1]: https://gerrit.opnfv.org/gerrit/#/c/29029/
[2]: https://wiki.opnfv.org/display/DEV/Contribution+Guidelines
[3]:
http://git.openstack.org/cgit/openstack/stackalytics/tree/etc/default_data.json#n23439

On Fri, Feb 17, 2017 at 10:52 AM gang chi <justin.chig...@gmail.com> wrote:

> Hi,
>
> I think most of team has received mail from Ray who told me there are over
> hundred files without License in Compass4nfv repo. I think some team may
> have same issue with me.
> so I share my script to generate license header for OPNFV repos.
>
> https://github.com/Justin-chi/Lab/blob/master/add_license.sh
>
> Here is result of the script: https://gerrit.opnfv.org/gerrit/#/c/28885/
>
> Hope it will works for you.
>
> Regards
> Justin
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for project meeting 2017-02-20

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-02-20

*# QTIP project weekly meeting on 2017-02-20*


   - time: UTC0730


   - irc://#opnfv-qtip@freenode


   - index: https://etherpad.opnfv.org/p/qtip-meetings


*## Action followup*


   - yujunz presentation about new code framework next week during the bug
   smash day


   - all please review qtip-api requirements


*## Topics*


   - bug smashing day schedule


   - documentation for Danube release


   - feature freeze for Danube release


*## Recurring*


   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


*## AOB*


   - 




-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [qtip][storperf] test coverage

[Yujun Zhang (ZTE)]

Thank you, Mark. Copied the brief guide to
https://jira.opnfv.org/browse/QTIP-204

CC also @Julien who has volunteered to take this task in QTIP

On Wed, Feb 15, 2017 at 11:39 PM Beierl, Mark <mark.bei...@dell.com> wrote:

> Hello,
>
> I am sorry for the delay in responding.  The Jenkins coverage report is
> created using a "publisher" in the JJB [1].  So from the verify job [2], I
> request that nosetests creates a coverage xml file, which is coberatura
> compatible.  It is that coverage.xml which the publisher uses.  There are
> also targets that can be specified so that Jenkins can automatically -1 a
> patch if coverage falls below a threshold, but I have not played with them.
>
> I also request it create coverage output in html, so it can be easily
> browsed locally if desired.
>
> [1]
> https://github.com/opnfv/releng/blob/master/jjb/storperf/storperf.yml#L67
> [2] https://github.com/opnfv/storperf/blob/master/ci/verify.sh#L57
>
> Regards,
> Mark
>
> *Mark Beierl*
> Advisory Solutions Architect
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Feb 6, 2017, at 08:50, Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
> wrote:
>
> Mark demonstrated a pretty test coverage report in last testperf
> meeting[1]. And we want to have similar report in QTIP.
>
> I have implemented the coverage test in QTIP verify job[2]. I wonder what
> will be the next step to generate such diagram in jenkins.
>
> @Mark, do you have a brief how-to document or any recommended guide for us
> to follow?
>
> [1]:
> https://build.opnfv.org/ci/view/storperf/job/storperf-verify-master/123/cobertura/
> [2]: https://gerrit.opnfv.org/gerrit/#/c/28055/
>
>
> --
> Yujun Zhang
>
>
> --
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] agenda for weekly meeting 2017-02-13

[Yujun Zhang (ZTE)]

https://etherpad.opnfv.org/p/qtip-meetings-2017-02-13

# QTIP project weekly meeting on 2016-02-13

time: UTC0730
irc://#opnfv-qtip@freenode
index: https://etherpad.opnfv.org/p/qtip-meetings

## Action followup

   -

## Topics

   - bug smash day on 22nd Feb


   - sprint follow up


   - @yujunz presentation about new code framework next week


   -

## Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


   -

## AOB



-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Zhihui will be delegated as QTIP PTL next week

[Yujun Zhang (ZTE)]

Dear all,

I will not be available for community work for one week. @Zhihui Wu will be
delegated as QTIP PTL during my absence.
-- 
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Continuing the Quarterly Awards discussion

[Yujun Zhang (ZTE)]

The category looks good.

I think we may need publish key indicators and selection process for these
awards to make it open and transparent. Not sure there is already some
policy defined by TSC.

My two cents.


On Wed, Feb 8, 2017 at 2:45 PM Raymond Paik <rp...@linuxfoundation.org>
wrote:

> That's correct...
>
> On Tue, Feb 7, 2017 at 10:37 PM, Yujun Zhang (ZTE) <
> zhangyujun+...@gmail.com> wrote:
>
> less frequently => do you mean from every quarter to each release?
>
> On Wed, Feb 8, 2017 at 6:21 AM Raymond Paik <rp...@linuxfoundation.org>
> wrote:
>
> Reviving the discussion after the Chinese New Year holidays...
>
> I wanted to propose the following new categories.  Also, since we're doing
> these awards less frequently we can award more than one person in each
> category (shown in numbers in parentheses).
>
>
>- Code development (3)
>- Community support/leadership (3)
>- Integration (3)
>- Testing (3)
>- Interns (2)
>
> Thoughts/comments?
>
> Thanks,
>
> Ray
>
> On Wed, Jan 25, 2017 at 5:14 PM, Yujun Zhang <zhangyujun+...@gmail.com>
> wrote:
>
> We may also consider recognition for *Leadership*.
>
> The candidates could be
>
>- Working group leader/coordinators
>- PTLs
>- Outstanding core developer who leads some in-project or
>cross-project subject
>
> On Thu, Jan 26, 2017 at 8:31 AM Raymond Paik <rp...@linuxfoundation.org>
> wrote:
>
> All,
>
> Following up on our discussion on the TSC call.
>
> A number of people made a suggestion to move away from quarterly awards
> and have community recognition after each release (in addition to annual
> awards at the Summit).
>
> For the Quarterly Awards, we have been selecting winners for the following
> 5 categories
>
>- Code development
>- Collaboration
>- Documentation & User Support
>- Integration
>- Testing
>
> If we move to release-based awards, should we keep the same categories?
> Morgan made the comment about recognizing interns, so we could add a new
> category for interns.  Also, how should voting be done?  In the past,
> nominations came from all community members but the voting was done by TSC
> members.
>
> Let me know your thoughts or if you have other suggestions.
>
> Thanks,
>
> Ray
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
> --
> Yujun Zhang
>
>
> --
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [qtip][yardstick] Q on integration

[Yujun Zhang (ZTE)]

Great, thanks!  As I mentioned before, @Zhihui will be the representative
for QTIP on this topic.

I'm sorry for the absence of tomorrow's meeting, dealing with some personal
emergency, and will be out of office next week also. I have expressed most
of my points in mailing list and will continue following the discussion.

During my absence, @Zhihui will make final decision for QTIP project. Hope
we can arrive at a consensus soon.

In case it can not be decided in tomorrow's meeting, we may probably have
to postpone the discussion to Beijing Summit and target it in next release.
Thank you for understanding.

On Mon, Feb 6, 2017 at 10:55 AM Gaoliang (kubi) <jean.gaoli...@huawei.com>
wrote:

> Hi Yujun，
>
>
>
> Sure, I added the topic into this week meeting agenda[1](US time slot with
> GTM), hope we will have a great discussion at the meeting.
>
>
>
> [1] https://wiki.opnfv.org/display/yardstick/Meetings
>
>
>
> Regards,
>
> Kubi
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Sunday, February 05, 2017 10:06 AM
> *To:* TECH-DISCUSS OPNFV; Gaoliang (kubi)
> *Subject:* Re: [qtip][yardstick] Q on integration
>
>
>
> Dear yardsticker,
>
>
>
> As suggested in last yardstick meeting[1], I've updated the QTIP
> architecture to introduce an even more simpler plugin mode[2]. We may
> discuss it in next Yardstick meeting.
>
>
>
> Do you think it will be OK? @Kubi
>
>
>
> The discussion has been lasting for months IIRC. We really need to make
> decision ASAP otherwise we are unlikely to catch up with Danube release.
>
>
>
> [1]:
> http://ircbot.wl.linuxfoundation.org/meetings/opnfv-yardstick/2017/opnfv-yardstick.2017-01-24-00.30.log.html
>
>
> [2]:
> https://wiki.opnfv.org/display/qtip/Architecture#Architecture-PluginMode(Melody
> )
>
>
>
> On Tue, Jan 24, 2017 at 11:47 AM Yujun Zhang <zhangyujun+...@gmail.com>
> wrote:
>
> Dear all
>
>
>
> I reviewed the meeting log[1] and it seems we have several questions to
> clarify. Feel free to comment.
>
>
>
> 1. how to integrate
>
>
>
> option 1: as a server like original proposal[2]
>
> option 2: as a module
>
>
>
> Both are OK to me, if it is YardStick's team to decide to integrate as a
> module, we need to revise the proposal and QTIP will provide full support
> on it as well.
>
>
>
> 2. testing vs benchmarking
>
>
>
> For sure benchmarking requires testing data. Benchmarking is one
> method/purpose of performance testing. Besides that, we may also use
> testing data for verification or validation. You may also use benchmarking
> result for verification or validation.
>
>
>
> 3. benchmarking in YardStick or testing in QTIP
>
>
>
> This is not a battle between two projects. We chase different targets and
> have common methodology.
>
>
>
> QTIP may consume testing data from YardStick but not all of them and not
> only from YardStick.
>
>
>
> YardStick may use QTIP as benchmarking module or implement its own module.
> It's up to YardStick team's decision and I'm fine with either way.
>
>
>
> [1]:
> http://ircbot.wl.linuxfoundation.org/meetings/opnfv-yardstick/2017/opnfv-yardstick.2017-01-24-00.30.log.html
>
>
> [2]: https://wiki.opnfv.org/display/yardstick/Yardstick-Qtip+integration
>
> --
Yujun Zhang
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [qtip][yardstick] Q on integration

[Yujun Zhang]

Dear yardsticker,

As suggested in last yardstick meeting[1], I've updated the QTIP
architecture to introduce an even more simpler plugin mode[2]. We may
discuss it in next Yardstick meeting.

Do you think it will be OK? @Kubi

The discussion has been lasting for months IIRC. We really need to make
decision ASAP otherwise we are unlikely to catch up with Danube release.

[1]:
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-yardstick/2017/opnfv-yardstick.2017-01-24-00.30.log.html

[2]:
https://wiki.opnfv.org/display/qtip/Architecture#Architecture-PluginMode(Melody
)

On Tue, Jan 24, 2017 at 11:47 AM Yujun Zhang <zhangyujun+...@gmail.com>
wrote:

> Dear all
>
> I reviewed the meeting log[1] and it seems we have several questions to
> clarify. Feel free to comment.
>
> 1. how to integrate
>
> option 1: as a server like original proposal[2]
> option 2: as a module
>
> Both are OK to me, if it is YardStick's team to decide to integrate as a
> module, we need to revise the proposal and QTIP will provide full support
> on it as well.
>
> 2. testing vs benchmarking
>
> For sure benchmarking requires testing data. Benchmarking is one
> method/purpose of performance testing. Besides that, we may also use
> testing data for verification or validation. You may also use benchmarking
> result for verification or validation.
>
> 3. benchmarking in YardStick or testing in QTIP
>
> This is not a battle between two projects. We chase different targets and
> have common methodology.
>
> QTIP may consume testing data from YardStick but not all of them and not
> only from YardStick.
>
> YardStick may use QTIP as benchmarking module or implement its own module.
> It's up to YardStick team's decision and I'm fine with either way.
>
> [1]:
> http://ircbot.wl.linuxfoundation.org/meetings/opnfv-yardstick/2017/opnfv-yardstick.2017-01-24-00.30.log.html
>
> [2]: https://wiki.opnfv.org/display/yardstick/Yardstick-Qtip+integration
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2017-02-06

[Yujun Zhang]

Welcome back, QTIP runners

https://etherpad.opnfv.org/p/qtip-meetings-2017-02-06

QTIP project weekly meeting on 2017-02-06
time: UTC0730
irc://#opnfv-qtip@freenode
index: https://etherpad.opnfv.org/p/qtip-meetings
Action followup

   - akhilbatra put qtip-api in public folder for review


   - yujunz create a draft page for proposals on architecture evolution

Topics

   - test coverage report


   - Example
   
https://build.opnfv.org/ci/view/functest/job/functest-verify-master/2934/cobertura/


   - bug smash day?

Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


   -

AOB
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for week meeting 2017-02-06

[Yujun Zhang]

Welcome back after the Spring Festival break.

https://etherpad.opnfv.org/p/qtip-meetings-2017-02-06

QTIP project weekly meeting on 2017-02-06
time: UTC0730
irc://#opnfv-qtip@freenode
index: https://etherpad.opnfv.org/p/qtip-meetings
Action followup

   - akhilbatra put qtip-api in public folder for review


   - yujunz create a draft page for proposals on architecture evolution

Topics

   - test coverage report


   - Example
   
https://build.opnfv.org/ci/view/functest/job/functest-verify-master/2934/cobertura/


   - bug smash day?

Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


   -

AOB
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Releng/Octopus] Patch verification suggestion

[Yujun Zhang]

Hi, Fatih

I was just wondering if it would be possible to trigger experimental jobs
from commit message instead of comment. Any example of using commit message
as trigger in current jobs?

What I want to achieve is to trigger doctor profiling jobs when I include a
tag in commit message, e.g. [ci profiling]. Is that possible with current
OPNFV CI?

On Mon, Jan 30, 2017 at 9:53 PM Fatih Degirmenci <
fatih.degirme...@ericsson.com> wrote:

> Hi Yujun,
>
>
>
> We don't plan to use an additional plugin since the commit message is
> injected into job environment (GERRIT_CHANGE_COMMIT_MESSAGE) by the Gerrit
> Trigger plugin. [1] That will be processed by the parent multijob, passing
> the scenario name into the phase jobs/scripts.
>
>
>
> We can extend this and make it possible for triggering (additional) jobs
> for other impacted scenarios by comments to patchset - like how you do
> similar things for doctor.
>
>
>
> [1]
> https://build.opnfv.org/ci/view/doctor/job/doctor-verify-master/351/injectedEnvVars/
>
>
>
> /Fatih
>
>
>
> *From: *Yujun Zhang <zhangyujun+...@gmail.com>
> *Date: *Monday, 30 January 2017 at 13:40
> *To: *Fatih Degirmenci <fatih.degirme...@ericsson.com>, Chigang <
> chig...@huawei.com>, "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>
>
>
> *Subject: *Re: [opnfv-tech-discuss] [Releng/Octopus] Patch verification
> suggestion
>
>
>
> Hi, Fatih
>
> It seems your proposal is based on commit message.
>
>
>
> Are you referring to Commit Message Trigger Plugin[1]? Is the plugin
> already installed on OPNFV CI?
>
>
>
> [1]:
> https://wiki.jenkins-ci.org/display/JENKINS/Commit+Message+Trigger+Plugin
>
>
>
> On Tue, Jan 24, 2017 at 5:15 PM Fatih Degirmenci <
> fatih.degirme...@ericsson.com> wrote:
>
> Hi,
>
>
>
> This is in our plans since last year. The idea is to come up with a common
> format to use in commit message which gets processed by the verify job,
> running the impacted scenario.
>
>
>
> Please see the first step in below section.
>
>
>
>
> https://wiki.opnfv.org/display/INF/CI+Evolution#CIEvolution-HowtheThingsFitTogether
>
>
>
> We are currently working on aligning job structures (verify and daily) and
> scope of the patchset verification for all the installers since the current
> situation is not good, some do things properly some does nothing.
>
>
>
> Here is who does what as part of patchset verification.
>
>
>
> - apex: unit test, build, virtual deploy, functest smoke test
>
> - compass: lint, virtual deploy, functest smoke test
>
> - daisy: build, virtual deploy
>
> - fuel: build
>
> - joid: nothing
>
>
>
> Apart from not reaching to this step to come up with a proposal for commit
> message, this depends on scenario consolidation/naming activity as well. We
> can hopefully start working with this after Danube.
>
>
>
> /Fatih
>
>
>
> *From: *<opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Yujun
> Zhang <zhangyujun+...@gmail.com>
> *Date: *Tuesday, 24 January 2017 at 08:41
> *To: *Chigang <chig...@huawei.com>, "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *Re: [opnfv-tech-discuss] [Releng/Octopus] Patch verification
> suggestion
>
>
>
> I think it is technically feasible.
>
>
>
> We added an experimental trigger for doctor project not long ago[1]. The
> trigger is similar to your requirement.
>
>
>
> [1]:
> https://gerrit.opnfv.org/gerrit/#/c/26839/4/jjb/global/releng-macros.yml
>
>
>
>
>
> On Tue, Jan 24, 2017 at 12:31 PM Chigang (Justin) <chig...@huawei.com>
> wrote:
>
> Hi,
>
> The Command "recheck" is used to run default patch verification again in
> Gerrit.
>
> But there are so many scenarios to be vericated, I think default patch
> verification is not enough.
>
> Is it possible to add a "scenarios" parameters to improve additional
> verification before patch merged in master?
>
> such as :
>
> "recheck odl" will trigged to odl related scenarios.
>
> Thanks
>
> Justin
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Releng/Octopus] Patch verification suggestion

[Yujun Zhang]

Hi, Fatih
It seems your proposal is based on commit message.

Are you referring to Commit Message Trigger Plugin[1]? Is the plugin
already installed on OPNFV CI?

[1]:
https://wiki.jenkins-ci.org/display/JENKINS/Commit+Message+Trigger+Plugin

On Tue, Jan 24, 2017 at 5:15 PM Fatih Degirmenci <
fatih.degirme...@ericsson.com> wrote:

> Hi,
>
>
>
> This is in our plans since last year. The idea is to come up with a common
> format to use in commit message which gets processed by the verify job,
> running the impacted scenario.
>
>
>
> Please see the first step in below section.
>
>
>
>
> https://wiki.opnfv.org/display/INF/CI+Evolution#CIEvolution-HowtheThingsFitTogether
>
>
>
> We are currently working on aligning job structures (verify and daily) and
> scope of the patchset verification for all the installers since the current
> situation is not good, some do things properly some does nothing.
>
>
>
> Here is who does what as part of patchset verification.
>
>
>
> - apex: unit test, build, virtual deploy, functest smoke test
>
> - compass: lint, virtual deploy, functest smoke test
>
> - daisy: build, virtual deploy
>
> - fuel: build
>
> - joid: nothing
>
>
>
> Apart from not reaching to this step to come up with a proposal for commit
> message, this depends on scenario consolidation/naming activity as well. We
> can hopefully start working with this after Danube.
>
>
>
> /Fatih
>
>
>
> *From: *<opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Yujun
> Zhang <zhangyujun+...@gmail.com>
> *Date: *Tuesday, 24 January 2017 at 08:41
> *To: *Chigang <chig...@huawei.com>, "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *Re: [opnfv-tech-discuss] [Releng/Octopus] Patch verification
> suggestion
>
>
>
> I think it is technically feasible.
>
>
>
> We added an experimental trigger for doctor project not long ago[1]. The
> trigger is similar to your requirement.
>
>
>
> [1]:
> https://gerrit.opnfv.org/gerrit/#/c/26839/4/jjb/global/releng-macros.yml
>
>
>
>
>
> On Tue, Jan 24, 2017 at 12:31 PM Chigang (Justin) <chig...@huawei.com>
> wrote:
>
> Hi,
>
> The Command "recheck" is used to run default patch verification again in
> Gerrit.
>
> But there are so many scenarios to be vericated, I think default patch
> verification is not enough.
>
> Is it possible to add a "scenarios" parameters to improve additional
> verification before patch merged in master?
>
> such as :
>
> "recheck odl" will trigged to odl related scenarios.
>
> Thanks
>
> Justin
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [VSPERF] Weekly Call

[Yujun Zhang]

Oops, wrong thread.

I was sending to the meeting notification for TestPerf meeting not VSPERF.

Sorry for that.

On Thu, Jan 26, 2017 at 3:21 PM Christo Kleu <christo.k...@netronome.com>
wrote:

> Good day Yujun,
>
> I was also not able to attend yesterdays meeting.
>
> VSPERF Project Meetings (link
> <https://wiki.opnfv.org/display/meetings/vsperf>)
> IRC meeting minutes for 2017-01-26 (link
> <http://ircbot.wl.linuxfoundation.org/meetings/opnfv-vswitchperf/2017/opnfv-vswitchperf.2017-01-25-16.00.html>
> )
>
> Regards,
> *Christo Kleu*
>
> On Thu, Jan 26, 2017 at 7:30 AM, Yujun Zhang <zhangyujun+...@gmail.com>
> wrote:
>
> Hi, testers
>
> I'm currently on vacation and may not be able to attend the testperf
> meeting today.
>
> It seems something is required from my side about Test Ecosystem diagram[1]
>
> Trevor Cooper <https://wiki.opnfv.org/display/~trev>
>
> I think additional input or a discussion would be helpful. I added a note
> to the agenda for this weeks Test WG meeting ... lets get some other input,
> if you can't make it we can defer any updates. I know the meeting time is
> really bad for you. thanks for all the feedback!
>
> If the potential change are just the following
>
>- 20 Jan 2017 Yujun Zhang <https://wiki.opnfv.org/display/~yujunz> change
>the description of QTIP to "Benchmarking as a Service"
>- 20 Jan 2017 Yujun Zhang <https://wiki.opnfv.org/display/~yujunz> add
>clarification on the difference between red and green blocks in
>Performance Testing
>
> Especially the first one, I don't see the necessity to defer the update
> because of my absence.
>
> I want to emphasis again my point on the diagram content and process: the 
> *project
> team* is the best candidates and maybe the only one to provide *original*
> content for discussion, not any party else.
>
> The reason that I made a proposal instead of modify the diagram directly
> is that I don't want the dispute on the old diagram[2] happens again and we
> lose the focus of the discussion.
>
> We may discuss about *which* kind of content to be put in the diagram,
> should it be project purpose or major content. But *what* to be put is
> NOT something worth discussion in working group meeting. The project team
> will provide it and be responsible to clarify it to the community.
>
> [1]: https://wiki.opnfv.org/display/testing/Testing+Ecosystem
> [2]: https://wiki.opnfv.org/display/testing/TestPerf
>
> On Wed, Jan 25, 2017 at 11:59 PM Cooper, Trevor <trevor.coo...@intel.com>
> wrote:
>
> VSPERF Weekly Meeting - Wednesday UTC 16h00, Ireland 16h00, Pacific 8h00
>
>
>- IRC:
>
>
>- freenode *https://freenode.net/* <https://freenode.net/>
>- IRC channel: #opnfv-vswitchperf
>*http://webchat.freenode.net/?channels=opnfv-vswitchperf*
><http://webchat.freenode.net/?channels=opnfv-vswitchperf>
>
>
>- MeetBot: *http://meetbot.opnfv.org/meetings/opnfv-vswitchperf/2015/*
><http://meetbot.opnfv.org/meetings/opnfv-vswitchperf/2015/>
>
>
> *Please join my meeting from your computer, tablet or smartphone.*
> https://global.gotomeeting.com/join/915183117
>
> *You can also dial in using your phone.*
> United States +1 (571) 317-3129
>
> *Access Code:* 915-183-117
>
> *More phone numbers*
> Australia +61 2 8355 1040 <+61%202%208355%201040>
> Austria +43 7 2088 0034
> Belgium +32 (0) 28 93 7018
> Canada +1 (647) 497-9350 <(647)%20497-9350>
> Denmark +45 69 91 88 64 <+45%2069%2091%2088%2064>
> Finland +358 (0) 923 17 0568
> France +33 (0) 170 950 592
> Germany +49 (0) 692 5736 7210
> Ireland +353 (0) 15 360 728
> Italy +39 0 247 92 13 01
> Netherlands +31 (0) 208 080 219
> New Zealand +64 9 909 7888 <+64%209-909%207888>
> Norway +47 75 80 32 07 <+47%2075%2080%2032%2007>
> Spain +34 955 32 0845 <+34%20955%2032%2008%2045>
> Sweden +46 (0) 853 527 836
> Switzerland +41 (0) 435 0167 13
> United Kingdom +44 (0) 330 221 0086 <(330)%20221-0086>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Continuing the Quarterly Awards discussion

[Yujun Zhang]

We may also consider recognition for *Leadership*.

The candidates could be

   - Working group leader/coordinators
   - PTLs
   - Outstanding core developer who leads some in-project or cross-project
   subject

On Thu, Jan 26, 2017 at 8:31 AM Raymond Paik 
wrote:

> All,
>
> Following up on our discussion on the TSC call.
>
> A number of people made a suggestion to move away from quarterly awards
> and have community recognition after each release (in addition to annual
> awards at the Summit).
>
> For the Quarterly Awards, we have been selecting winners for the following
> 5 categories
>
>- Code development
>- Collaboration
>- Documentation & User Support
>- Integration
>- Testing
>
> If we move to release-based awards, should we keep the same categories?
> Morgan made the comment about recognizing interns, so we could add a new
> category for interns.  Also, how should voting be done?  In the past,
> nominations came from all community members but the voting was done by TSC
> members.
>
> Let me know your thoughts or if you have other suggestions.
>
> Thanks,
>
> Ray
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Continuing the Quarterly Awards discussion

[Yujun Zhang]

+1 for interns

For voting, I would suggest keep it in TSC.

I thought also about PTLs or community's voting. But PTLs may not have a
global view of the activity in community and community's voting is likely
ending as a competition on which project has most members...

On Thu, Jan 26, 2017 at 8:31 AM Raymond Paik 
wrote:

> All,
>
> Following up on our discussion on the TSC call.
>
> A number of people made a suggestion to move away from quarterly awards
> and have community recognition after each release (in addition to annual
> awards at the Summit).
>
> For the Quarterly Awards, we have been selecting winners for the following
> 5 categories
>
>- Code development
>- Collaboration
>- Documentation & User Support
>- Integration
>- Testing
>
> If we move to release-based awards, should we keep the same categories?
> Morgan made the comment about recognizing interns, so we could add a new
> category for interns.  Also, how should voting be done?  In the past,
> nominations came from all community members but the voting was done by TSC
> members.
>
> Let me know your thoughts or if you have other suggestions.
>
> Thanks,
>
> Ray
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [doctor] Further discussion of NFVI / APP monitoring

[Yujun Zhang]

That would be an interesting topic.

We have already started something on inspector[1]. We may create one for
monitor as well.

[1]: https://jira.opnfv.org/browse/DOCTOR-73

On Wed, Jan 25, 2017 at 1:12 AM Aaron Smith  wrote:

> Hi,
>   Would there be interest in a separate meeting to discussion what an
> "ideal" monitoring framework might look like.
>
> Topics might include:
>   - Polling vs Event capture
>   - Platform independent monitor agent
> - Network Interfaces
> - Kernel events
> - VM / Container monitoring
> - Common bus for Events / Telemetry / Config
>   -  Common Object model
> - Agent configuration
> - Performance
>- <<50ms
>
> This would be an informal brainstorming activity with more emphasis on
> concepts than existing projects (unless necessary).
>
> Thoughts?
>
> Aaron
>
> --
> Aaron Smith | Senior Principal Software Engineer
> NFV Partner Engineering
> Red Hat
> aasm...@redhat.com
>
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Releng/Octopus] Patch verification suggestion

[Yujun Zhang]

I think it is technically feasible.

We added an experimental trigger for doctor project not long ago[1]. The
trigger is similar to your requirement.

[1]:
https://gerrit.opnfv.org/gerrit/#/c/26839/4/jjb/global/releng-macros.yml


On Tue, Jan 24, 2017 at 12:31 PM Chigang (Justin) 
wrote:

> Hi,
>
> The Command "recheck" is used to run default patch verification again in
> Gerrit.
>
> But there are so many scenarios to be vericated, I think default patch
> verification is not enough.
>
> Is it possible to add a "scenarios" parameters to improve additional
> verification before patch merged in master?
>
> such as :
>
> "recheck odl" will trigged to odl related scenarios.
>
> Thanks
>
> Justin
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip][yardstick] Q on integration

[Yujun Zhang]

Dear all

I reviewed the meeting log[1] and it seems we have several questions to
clarify. Feel free to comment.

1. how to integrate

option 1: as a server like original proposal[2]
option 2: as a module

Both are OK to me, if it is YardStick's team to decide to integrate as a
module, we need to revise the proposal and QTIP will provide full support
on it as well.

2. testing vs benchmarking

For sure benchmarking requires testing data. Benchmarking is one
method/purpose of performance testing. Besides that, we may also use
testing data for verification or validation. You may also use benchmarking
result for verification or validation.

3. benchmarking in YardStick or testing in QTIP

This is not a battle between two projects. We chase different targets and
have common methodology.

QTIP may consume testing data from YardStick but not all of them and not
only from YardStick.

YardStick may use QTIP as benchmarking module or implement its own module.
It's up to YardStick team's decision and I'm fine with either way.

[1]:
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-yardstick/2017/opnfv-yardstick.2017-01-24-00.30.log.html

[2]: https://wiki.opnfv.org/display/yardstick/Yardstick-Qtip+integration
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Cancelled weekly meeting on Jan 23 and Jan 30

[Yujun Zhang]

QTIP runners,

Next two weekly meetings will be cancelled for Spring Festival in China.

See you on Feb 6th.
--
Yujun
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [doctor] CFP planning for OpenStack Summit and ONS

[Yujun Zhang]

Quite interested in the performance topic and I'm willing to join the
presentation a co-speaker :-)

Updated in the etherpad.
--
Yujun

On Wed, Jan 18, 2017 at 12:37 AM Ryota Mibu  wrote:

> Hi,
>
>
> As I mentioned, I created an etherpad page to have discussion for our CFPs.
>
> https://etherpad.opnfv.org/p/doctor_openstack_summit_boston_2017
>
> VES demo is also put in this page, although we can post the CFP to ONS.
>
> I encourage you all to post your idea and be a presenter. ;-)
>
>
> Cheers,
> Ryota
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Sprint QTIP-D5 to Sprint QTIP-D6

[Yujun Zhang]

QTIP runners,

We are moving forward to QTIP-D6 which shall focuses on

- PoC for architecture evolution
- compute QPI implementation
- CLI evolution following the architecture changes
- Starting API server design and implementation

And possibly

- integration with Yardstick

In the last sprint QTIP-D5, we suffered a massive tasks delay (14 out of
19). Please review the QTIP-D6[1] contents carefully and make it more
practical.

Thank you all.

[1]: https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=135

--
Yujun
___
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-tsc] For the "quarterly projects health metrics" discussion on the TSC call

[Yujun Zhang]

Hi, Ray,

I downloaded it from the website and opened it in Numbers under macOS

On Tue, Jan 17, 2017 at 9:15 AM Raymond Paik <rp...@linuxfoundation.org>
wrote:

> Yujun,
>
> You probably need to download the file to see all the titles.  If you
> "view" via the browser, you may not see all the labels...  Let me know if
> that's not the case.
>
> Thanks,
>
> Ray
>
> On Mon, Jan 16, 2017 at 4:51 PM, Yujun Zhang <zhangyujun+...@gmail.com>
> wrote:
>
> It seems some project title is missing in the diagram, e.g. armband,
> barometer, ...
>
> [image: Screen Shot 2017-01-17 at 8.48.55 AM.png]
> ×
>
> [image: Screen Shot 2017-01-17 at 8.49.54 AM.png]
>
> On Tue, Jan 17, 2017 at 7:15 AM Raymond Paik <rp...@linuxfoundation.org>
> wrote:
>
> All,
>
> One of the agenda topics for this week's call is the projects health
> metrics.  On the TSC wiki, I posted a DRAFT report under the agenda topic
> at https://wiki.opnfv.org/display/meetings/TSC#TSC-January17,2017
>
> The goal of this exercise is to provide an overview of different projects'
> activity levels and to provide a data point for regular project discussions
> (e.g. does Project A need more resources, is Project X a candidate for
> termination review, etc.?)
>
> All data in this report came from public sources.  Most of the data came
> from the Bitergia dashboard, but there was definitely some manual work
> involved (e.g. for number of wiki contributions for individual project
> pages).  You may notice that some of the data are missing on git commits as
> we discovered that git data wasn't being pulled from some of the projects
> (e.g. daisy, ves, etc.) and I'm working with the Bitergia team on this.
>
> I encourage your feedback on this via mailing lists and on tomorrow's
> call.  Please let me know if you have any questions.
>
> Thanks,
>
> Ray
> ___
> opnfv-tsc mailing list
> opnfv-...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tsc
>
>
>
___
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-tsc] For the "quarterly projects health metrics" discussion on the TSC call

[Yujun Zhang]

It seems some project title is missing in the diagram, e.g. armband,
barometer, ...

[image: Screen Shot 2017-01-17 at 8.48.55 AM.png]
×

[image: Screen Shot 2017-01-17 at 8.49.54 AM.png]

On Tue, Jan 17, 2017 at 7:15 AM Raymond Paik 
wrote:

> All,
>
> One of the agenda topics for this week's call is the projects health
> metrics.  On the TSC wiki, I posted a DRAFT report under the agenda topic
> at https://wiki.opnfv.org/display/meetings/TSC#TSC-January17,2017
>
> The goal of this exercise is to provide an overview of different projects'
> activity levels and to provide a data point for regular project discussions
> (e.g. does Project A need more resources, is Project X a candidate for
> termination review, etc.?)
>
> All data in this report came from public sources.  Most of the data came
> from the Bitergia dashboard, but there was definitely some manual work
> involved (e.g. for number of wiki contributions for individual project
> pages).  You may notice that some of the data are missing on git commits as
> we discovered that git data wasn't being pulled from some of the projects
> (e.g. daisy, ves, etc.) and I'm working with the Bitergia team on this.
>
> I encourage your feedback on this via mailing lists and on tomorrow's
> call.  Please let me know if you have any questions.
>
> Thanks,
>
> Ray
> ___
> opnfv-tsc mailing list
> opnfv-...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tsc
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [dovetail]Dovetail encryption for report

[Yujun Zhang]

On Sat, Jan 14, 2017 at 10:16 AM Leo Wang <grakiss...@hotmail.com> wrote:

I guess we have some misunderstanding about this report.


The report is a dynamic generated file, it is not a part of the release, or
a static certificated file delivered from OPNFV(we do may have this final
certificate file, but that’s total a different thing )

If I understand it right, it is a dynamic generated file from a freezed
release. One report can have several steps of signature, I guess that is
the idea behind blockchain as Ash mentioned in follow-up discussions.

User get dovetail tool to run tests, then they get a report about this
test, they have a total control of the report, before they upload the
report to OPNFV, they can do anything with it.

Not sure for that if the test is run automatically without user
interference. We need forbid user to access the private key of the test
runner. I think the security expert may have a solution for that.

On Jan 13, 2017, at 16:42, Yujun Zhang <zhangyujun+...@gmail.com> wrote:

Based on my limited knowledge, a user can only sign the result with *his
own* private key. It is not possible for him to modify a report signed by
let's say *OPNFV release bot* and kept the original signature.

On Fri, Jan 13, 2017 at 4:38 PM Leo Wang <grakiss...@hotmail.com> wrote:

Hi Lincoln

I agree with you , your proposal can keep the integrity of the dovetail
tool(scripts/codes),

but i not sure that the content of results is right.

to sign the result can only proof its integrity that result is not tampered
with during the transfer or uploading

If user modify the result right after the result being generated then sign
the result

how to tell whether the result is the original one or not ?


BR

Leo Wang




On Jan 13, 2017, at 06:08, Lincoln Lavoie <lylav...@iol.unh.edu> wrote:

Hi Leo,

It may be worth separating the encryption from the signature piece.  I
believe the primary purpose of the security requirements were to ensure the
integrity of the testing (i.e. the dovetail tests were not modified by the
tester, to "solve" a failure).  In this process, I don't believe that is
accomplished, because the scripts are generating their own key each time.
I think this will also lead to a nightmare number of keys that have to be
kept, maintained, and tracked to look at results run in the past.

Attached is a different approach.  This approach would only sign the
results, which protects their integrity compared against the scripts that
were used to generate the results.  If a user wanted to "protect" their
results, I would leave it to them to encrypt them and share keeps with the
expected "consumer."  In this approach, OPNFV Staff would be responsible
for maintaining the public / private key (which should likely be updated
with each release.  That key is used, along with a hash (MD5 sum or
similar) of the Dovetail "scripts" to sign the results.  That signature can
then be validated against the public key, to ensure the scripts or results
were not tampered with prior to review.  This approach assumes the trust is
placed with the OPNFV staff, in building (compiling) the integrity tool w/
the private key, and providing only the compiled version with each release
(private key would have be protected within that tool).

The "gotcha" is making sure that compiled tool can run on all platforms and
ensuring the private key is well protected.  And, if the OPNFV staff are
able to maintain the set of keys, etc.



Thoughts?

Cheers,
Lincoln


On Thu, Jan 12, 2017 at 4:46 AM, Leo Wang <grakiss...@hotmail.com> wrote:

Hi, Luke and Lincoln,


Dovetail team plans to add this feature to dovetail tool , and need your
professional  advices  from security group and 3rd party lab,

so would you guys take a time to review this idea?


Thank you both in advance !


I’ve update the diagram with digital signature, and both encryption and
digital signature can be optional to fit in user’s demand

for details, please check this link:
https://wiki.opnfv.org/display/dovetail/Dovetail+Security+of+Report




On Dec 27, 2016, at 18:00, Lijun (Matthew) <matthew.li...@huawei.com> wrote:

digital signature should be added to do integrity checks, etc. +1.

/MatthewLi
*发件人：*Leo Wang
*收件人：*Yujun Zhang
*抄送：*Motamary, Shabrinath via opnfv-tech-discuss
*时间：*2016-12-27 16:32:46
*主题:*Re: [opnfv-tech-discuss] [dovetail]Dovetail encryption for report

Encryption or signature or certificate do have different role in this big
picture,

It can be done step by step.




On Dec 27, 2016, at 16:01, Yujun Zhang <zhangyujun+...@gmail.com> wrote:

On Tue, Dec 27, 2016 at 3:54 PM Leo Wang <grakiss...@hotmail.com> wrote:

As i mentioned , someone did show their concern on the security of test
report, so dovetail will provide this optional parameter for them

digital signature is used to identify the source and its integrity, and
surely it can raise the security

Re: [opnfv-tech-discuss] [dovetail]Dovetail encryption for report

[Yujun Zhang]

Based on my limited knowledge, a user can only sign the result with *his
own* private key. It is not possible for him to modify a report signed by
let's say *OPNFV release bot* and kept the original signature.

On Fri, Jan 13, 2017 at 4:38 PM Leo Wang <grakiss...@hotmail.com> wrote:

> Hi Lincoln
>
> I agree with you , your proposal can keep the integrity of the dovetail
> tool(scripts/codes),
>
> but i not sure that the content of results is right.
>
> to sign the result can only proof its integrity that result is not
> tampered with during the transfer or uploading
>
> If user modify the result right after the result being generated then sign
> the result
>
> how to tell whether the result is the original one or not ?
>
>
> BR
>
> Leo Wang
>
>
>
>
> On Jan 13, 2017, at 06:08, Lincoln Lavoie <lylav...@iol.unh.edu> wrote:
>
> Hi Leo,
>
> It may be worth separating the encryption from the signature piece.  I
> believe the primary purpose of the security requirements were to ensure the
> integrity of the testing (i.e. the dovetail tests were not modified by the
> tester, to "solve" a failure).  In this process, I don't believe that is
> accomplished, because the scripts are generating their own key each time.
> I think this will also lead to a nightmare number of keys that have to be
> kept, maintained, and tracked to look at results run in the past.
>
> Attached is a different approach.  This approach would only sign the
> results, which protects their integrity compared against the scripts that
> were used to generate the results.  If a user wanted to "protect" their
> results, I would leave it to them to encrypt them and share keeps with the
> expected "consumer."  In this approach, OPNFV Staff would be responsible
> for maintaining the public / private key (which should likely be updated
> with each release.  That key is used, along with a hash (MD5 sum or
> similar) of the Dovetail "scripts" to sign the results.  That signature can
> then be validated against the public key, to ensure the scripts or results
> were not tampered with prior to review.  This approach assumes the trust is
> placed with the OPNFV staff, in building (compiling) the integrity tool w/
> the private key, and providing only the compiled version with each release
> (private key would have be protected within that tool).
>
> The "gotcha" is making sure that compiled tool can run on all platforms
> and ensuring the private key is well protected.  And, if the OPNFV staff
> are able to maintain the set of keys, etc.
>
>
>
> Thoughts?
>
> Cheers,
> Lincoln
>
>
> On Thu, Jan 12, 2017 at 4:46 AM, Leo Wang <grakiss...@hotmail.com> wrote:
>
> Hi, Luke and Lincoln,
>
>
> Dovetail team plans to add this feature to dovetail tool , and need your
> professional  advices  from security group and 3rd party lab,
>
> so would you guys take a time to review this idea?
>
>
> Thank you both in advance !
>
>
> I’ve update the diagram with digital signature, and both encryption and
> digital signature can be optional to fit in user’s demand
>
> for details, please check this link:
> https://wiki.opnfv.org/display/dovetail/Dovetail+Security+of+Report
>
> 
>
>
> On Dec 27, 2016, at 18:00, Lijun (Matthew) <matthew.li...@huawei.com>
> wrote:
>
> digital signature should be added to do integrity checks, etc. +1.
>
> /MatthewLi
> *发件人：*Leo Wang
> *收件人：*Yujun Zhang
> *抄送：*Motamary, Shabrinath via opnfv-tech-discuss
> *时间：*2016-12-27 16:32:46
> *主题:*Re: [opnfv-tech-discuss] [dovetail]Dovetail encryption for report
>
> Encryption or signature or certificate do have different role in this big
> picture,
>
> It can be done step by step.
>
>
>
>
> On Dec 27, 2016, at 16:01, Yujun Zhang <zhangyujun+...@gmail.com> wrote:
>
> On Tue, Dec 27, 2016 at 3:54 PM Leo Wang <grakiss...@hotmail.com> wrote:
>
> As i mentioned , someone did show their concern on the security of test
> report, so dovetail will provide this optional parameter for them
>
> digital signature is used to identify the source and its integrity, and
> surely it can raise the security level, or even better to get a digital
> certificate to make it more secure?
>
>
> Sure.
>
> You may refer the international standard  ISO/IEC 17065 on how to certify
> a product. The standard is not about technical solution but quality
> processes and organizations.
>
> Encryption or signature are all technical methods to enhance the authority
> of a certification program.
>
>
>
>
>
>
> --
>
> ***

Re: [opnfv-tech-discuss] [pinpoint] project release plan

[Yujun Zhang]

Thanks, Uli

I am actually following Vitrage project.

May I ask what will be the relationship between pinpoint and vitrage in the
future?

On Mon, Jan 9, 2017 at 8:39 PM Ulrich Kleber <ulrich.kle...@huawei.com>
wrote:

> Hi Yujun,
>
> currently we don’t have plan to release something from Pinpoint in Danube
> for some resourcing issues.
>
> But a first step for the RCA topics will be implemented in OpenStack by
> the vitrage project, so maybe that could help your needs.
>
> See https://wiki.openstack.org/wiki/Vitrage
>
> Best,
>
> Uli
>
>
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Yujun Zhang
> *Sent:* Monday, 09 January, 2017 03:41
> *To:* TECH-DISCUSS OPNFV; Adi Molkho
> *Subject:* [opnfv-tech-discuss] [pinpoint] project release plan
>
>
>
> Hi, Adi
>
>
>
> We are looking for an RCA service in OPNFV. It seems pinpoint[1] is
> dedicated for this purpose.
>
>
>
> May I have more information on the project progress and release plan?
>
>
>
> [1]: https://wiki.opnfv.org/display/pinpoint
>
>
>
> --
>
> Yujun
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Updated Agenda for Weekly Meeting 2017-01-09

[Yujun Zhang]

https://etherpad.opnfv.org/p/qtip-meetings-2017-01-09

Resend since many new topics are added.

QTIP project weekly meeting on 2017-01-09
time: UTC0730
irc://#opnfv-qtip@freenode
index: https://etherpad.opnfv.org/p/qtip-meetings
Action followup

   - zhihui to investigate how to detect yardstick finishing after xmas and
   new year holiday


   - zhihui to propose design specification of yardstick integration


   - all create JIRA tasks for sprint QTIP-D5


   - yujunz create a design specification on the architecture and design
   evolution


   -

Topics

   - intern bootcamp proposal https://etherpad.opnfv.org/p/qtip-bootcamp


   - fast track submit


   - normal: at least one +2 vote from other committer


   - fast: no objection from other committer within 48 hours


   - architecture evolution


   - https://gerrit.opnfv.org/gerrit/#/c/26585/


   - developer guide


   - https://jira.opnfv.org/browse/QTIP-115


   - coding style


   - https://gerrit.opnfv.org/gerrit/#/c/26759


   - http://docs.openstack.org/developer/hacking/


   -

Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


   -

AOB

   -



On Fri, Jan 6, 2017 at 2:10 PM Yujun Zhang <zhangyujun+...@gmail.com> wrote:

> https://etherpad.opnfv.org/p/qtip-meetings-2017-01-09
>
> copy to opnfv-user list since the main topic would be *intern bootcamp*
>
> QTIP project weekly meeting on 2017-01-09
> time: UTC0730
> irc://#opnfv-qtip@freenode
> index: https://etherpad.opnfv.org/p/qtip-meetings
> Action followup
>
>- zhihui to investigate how to detect yardstick finishing after xmas
>and new year holiday
>
>
>- zhihui to propose design specification of yardstick integration
>
>
>- all create JIRA tasks for sprint QTIP-D5
>
>
>- yujunz create a design specification on the architecture and design
>evolution
>
>
>-
>
> Topics
>
>- intern bootcamp proposal https://etherpad.opnfv.org/p/qtip-bootcamp
>
>
>-
>
> Recurring
>
>- active sprint followup
>https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135
>
>
>- CI status https://build.opnfv.org/ci/view/qtip/
>
>
>- new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198
>
>
>-
>
> AOB
>
>- 
>
>
>-
>
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [infra][doctor] experimental trigger not working

[Yujun Zhang]

Ok, thanks.

BTW, is this type of error ignored on purpose or just not supported by jjb
checker?

On Sat, Jan 7, 2017 at 6:18 PM Fatih Degirmenci <
fatih.degirme...@ericsson.com> wrote:

> Hi Yujun,
>
>
>
> The issues are fixed now and the job gets triggered correctly by the
> keyword check-experimental.
>
> If the values are not passed to the macros, they will not be updated by
> jjb and stay as they are - {project} and {branch}.
>
>
>
> We verify jjb updates using jjb but this type of errors are not caught by
> it.
>
>
>
> /Fatih
>
>
>
> *From: *Yujun Zhang <zhangyujun+...@gmail.com>
> *Date: *Friday, 6 January 2017 at 12:46
> *To: *Fatih Degirmenci <fatih.degirme...@ericsson.com>, "
> opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *Re: [opnfv-tech-discuss] [infra][doctor] experimental trigger
> not working
>
>
>
> Thanks Fatih
>
>
>
> Fix proposed in https://gerrit.opnfv.org/gerrit/#/c/26767/
>
>
>
> What will the value of '{project}' be if we forget to pass a variable to
> the macro? Is it possible to detect such error with a verification job?
>
>
>
> On Fri, Jan 6, 2017 at 7:15 PM Fatih Degirmenci <
> fatih.degirme...@ericsson.com> wrote:
>
> Hi Yujun,
>
>
>
> This is due to not passing project and branch values to macro. This causes
> the use of incorrect values for PROJECT and GERRIT_PROJECT parameters in
> the created Jenkins job. (job has {project} as PROJECT value and {branch}
> as GERRIT_PROJECT value as oppose to doctor and master respectively.)
>
>
>
> You either need to pass those values
>
>
>
> triggers:
>
> - 'doctor-experimental':
>
> project: '{project}'
>
> branch: '{branch}'
>
>
>
> or move trigger into job body rather than using macro.
>
>
>
> /Fatih
>
>
>
> *From: *<opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Yujun
> Zhang <zhangyujun+...@gmail.com>
> *Date: *Friday, 6 January 2017 at 08:02
> *To: *"opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *[opnfv-tech-discuss] [infra][doctor] experimental trigger not
> working
>
>
>
> Hi, infra experts
>
>
>
> We want to introduce a jenkins job trigger for experimental changes[1]
>
>
>
> A trigger is created for doctor project[2], but it seems not working as
> expected. When a new comment "check experimental" is added[3], no job is
> triggered[4] as expected.
>
>
>
> *Could anyone give some hint on how to debug such issue?*
>
>
>
> The trigger is defined as a macro and referenced in
> doctor-profiling-master job
>
> - *trigger:*
> *name: *'doctor-experimental'
> *triggers:*
> - *gerrit:*
> *server-name: *'gerrit.opnfv.org'
> *trigger-on:*
> - *comment-added-contains-event:*
> *comment-contains-value: *'check experimental'
>
> - *job-template:*
> *name: *'doctor-profiling-{stream}'
> ...
> *triggers:*
> - 'doctor-experimental'
>
>
>
> [1]: http://docs.openstack.org/infra/system-config/test-infra-
>
> requirements.html#experimental
> <http://docs.openstack.org/infra/system-config/test-infra-requirements.html#experimental>
>
>
> [2]:https://gerrit.opnfv.org/gerrit/#/c/26439/
>
> [3]: https://gerrit.opnfv.org/gerrit/#/c/26531/
>
> [4]: https://build.opnfv.org/ci/view/doctor/job/doctor-profiling-master/
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [infra][doctor] experimental trigger not working

[Yujun Zhang]

Thanks Fatih

Fix proposed in https://gerrit.opnfv.org/gerrit/#/c/26767/

What will the value of '{project}' be if we forget to pass a variable to
the macro? Is it possible to detect such error with a verification job?

On Fri, Jan 6, 2017 at 7:15 PM Fatih Degirmenci <
fatih.degirme...@ericsson.com> wrote:

> Hi Yujun,
>
>
>
> This is due to not passing project and branch values to macro. This causes
> the use of incorrect values for PROJECT and GERRIT_PROJECT parameters in
> the created Jenkins job. (job has {project} as PROJECT value and {branch}
> as GERRIT_PROJECT value as oppose to doctor and master respectively.)
>
>
>
> You either need to pass those values
>
>
>
> triggers:
>
> - 'doctor-experimental':
>
> project: '{project}'
>
> branch: '{branch}'
>
>
>
> or move trigger into job body rather than using macro.
>
>
>
> /Fatih
>
>
>
> *From: *<opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Yujun
> Zhang <zhangyujun+...@gmail.com>
> *Date: *Friday, 6 January 2017 at 08:02
> *To: *"opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *[opnfv-tech-discuss] [infra][doctor] experimental trigger not
> working
>
>
>
> Hi, infra experts
>
>
>
> We want to introduce a jenkins job trigger for experimental changes[1]
>
>
>
> A trigger is created for doctor project[2], but it seems not working as
> expected. When a new comment "check experimental" is added[3], no job is
> triggered[4] as expected.
>
>
>
> *Could anyone give some hint on how to debug such issue?*
>
>
>
> The trigger is defined as a macro and referenced in
> doctor-profiling-master job
>
> -
> *trigger:name: *'doctor-experimental'
>
> *triggers:*-
> *gerrit:server-name: *'gerrit.opnfv.org'
>
> *trigger-on:*-
> *comment-added-contains-event:comment-contains-value: 
> *'check experimental'
>
> -
> *job-template:name: *'doctor-profiling-{stream}'
> ...
>
> *triggers:*- 'doctor-experimental'
>
>
>
> [1]: http://docs.openstack.org/infra/system-config/test-infra-
>
> requirements.html#experimental
> <http://docs.openstack.org/infra/system-config/test-infra-requirements.html#experimental>
>
>
> [2]:https://gerrit.opnfv.org/gerrit/#/c/26439/
>
> [3]: https://gerrit.opnfv.org/gerrit/#/c/26531/
>
> [4]: https://build.opnfv.org/ci/view/doctor/job/doctor-profiling-master/
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Agenda for Weekly Meeting 2017-01-09

[Yujun Zhang]

https://etherpad.opnfv.org/p/qtip-meetings-2017-01-09

copy to opnfv-user list since the main topic would be *intern bootcamp*

QTIP project weekly meeting on 2017-01-09
time: UTC0730
irc://#opnfv-qtip@freenode
index: https://etherpad.opnfv.org/p/qtip-meetings
Action followup

   - zhihui to investigate how to detect yardstick finishing after xmas and
   new year holiday


   - zhihui to propose design specification of yardstick integration


   - all create JIRA tasks for sprint QTIP-D5


   - yujunz create a design specification on the architecture and design
   evolution


   -

Topics

   - intern bootcamp proposal https://etherpad.opnfv.org/p/qtip-bootcamp


   -

Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198


   -

AOB

   - 


   -
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [test-wg] [all] TestPerf EcoSystem diagram now editable

[Yujun Zhang]

I'm glad that we are pulling this discussion back to technical track.

Some additional comments about QTIP inline.

On Thu, Jan 5, 2017 at 7:09 AM Cooper, Trevor <trevor.coo...@intel.com>
wrote:

I am glad we will discuss this in the Test Working Group meeting tomorrow …
the testing projects have evolved quite a bit since the first plugfest. We
should evolve wherever possible to normalize and avoid duplication BUT also
give projects autonomy they deserve to decide their interests and drive
their objectives. This seems to be what is emerging?



Functional testing

VIM + NFVI -> Functest

MANO -> ?

Compliance -> Dovetail



Performance testing

NFVI (+ VNF) characterization -> Yardstick

Compute, memory, storage sub-system (platform) performance -> Qtip


This is the major application of QTIP. A synthesis evaluation of platform
performance by benchmarking test.

As a companion delivery, QTIP is also developing a platform for performance
benchmarking, including common utility modules, base templates and
benchmark result sharing (possibly on opnfv testresult site)

Data-plane performance (switching technology, virtual and physical
networks) -> VSPERF

Storage performance -> Storperf

Controller performance -> CPerf

Performance trend analysis -> Bottleneck

/Trevor



*From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
*Sent:* Wednesday, December 21, 2016 6:36 AM
*To:* Gaoliang (kubi) <jean.gaoli...@huawei.com>; test-wg <
test...@lists.opnfv.org>
*Cc:* TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org>; Morgan
Richomme (morgan.richo...@orange.com) <morgan.richo...@orange.com>; Jose
Lausuch <jose.laus...@ericsson.com>; Cooper, Trevor <trevor.coo...@intel.com>;
mark.bei...@emc.com; Yuyang (Gabriel) <gabriel.yuy...@huawei.com>
*Subject:* Re: [test-wg] [all] TestPerf EcoSystem diagram now editable



Thanks for the detail explanation. As many test-wg members are on holiday,
I think we may not able to arrive at a consensus on the process soon.



The modification is actually not affecting any other projects but yardstick
and QTIP. It reflects my understanding of QTIP projects, for the past and
also for the future. And I didn't see any objection on the modification
content (not the process) in the past week. Reverting it to previous
version will mislead the community.



So I would like to keep the modified version unless we have a scope change
requested from the working group and approved by TSC. Do you think it will
work?



We may discuss about process in testperf meeting. But to my understanding,
community wiki is open for editing unless locked. This is a way to show
open spirit and improve efficiency. Of course that people who abuse this
right shall be banned. My two cents.



On Wed, Dec 21, 2016 at 4:50 PM Gaoliang (kubi) <jean.gaoli...@huawei.com>
wrote:

Hi Yujun,

To my knowledge, the Draft Testperf Ecosystem Diagram was discussed and
published at the first plugfest. Its orientation is to avoid overlap works
between our testing projects and also to reflect the relations. Then after
a lot of discussion within the community which leads to common consensus,
the Diagram was updated during the OPNFV Berlin Summit (please refer to the
presentation "Conversation with the Testing community"[1]).

Now, the Updated Diagram has been published in WIKI page for 6 months and
perceived stable community-wide. I believe if some modifications of the
Diagram are expected, we should discuss first, then we do the changes.
After all, we are working as a community.

In addition, since any change to the Diagram may result in different
relations between our testing projects, direct changes to the original
Diagram will make things more complicated. It's better to have our
discussion based on the summit version of our Testperf Ecosystem Diagram
for changes.

I'd like to work together with you to improve the modification process and
keeping things in order. For this purpose, I would like help add a topic in
the Testperf Weekly Meeting. I believe we can make further progress
together!

 [1]
https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=blob;f=docs/com/img/OPNFV_testing_group.png;h=4b8c2c053e0143b1a9abc7e54fd9e7671ccfcee8;hb=HEAD

Thanks,

Kubi





*发件人**:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]

*发送时间**:* 2016年12月16日 16:43

*收件人**:* Gaoliang (kubi); test-wg
*抄送**:* TECH-DISCUSS OPNFV; Morgan Richomme (morgan.richo...@orange.com);
Jose Lausuch; trevor.coo...@intel.com; mark.bei...@emc.com; Yuyang (Gabriel)
*主**题**:* Re: [test-wg] [all] TestPerf EcoSystem diagram now editable



See my replies inline.

On Fri, Dec 16, 2016 at 3:43 PM Gaoliang (kubi) <jean.gaoli...@huawei.com>
wrote:

Hi Yujun,

 Thanks for  your timely reply!



First, it is a very praiseworthy effort of you on making the diagram
editable!

What I concerned is the process of  the modification of the Testperf
Ecosystem Diagram. As you know, Testpe

Re: [opnfv-tech-discuss] [test-wg] unit test strategy in test projects

[Yujun Zhang]

Good point.

Some additional comments from my side inline

On Wed, Jan 4, 2017 at 6:47 PM Ashish Kumar <ashishk.i...@gmail.com> wrote:

Hello Everyone!

I think we have two different approaches here, each approach depends on our
definition of unit, what exactly should be our unit to test should it be
method-based or functionality based (group of methods defining a
functionality).

As Serena mentioned, In case of functionality based, when a test would
fail... we will easily know which functionality is broken but functionality
itself is a pipeline of methods right (correct me if I am wrong)?


Are you referring to methods of the same modules or different modules?


In this pipeline, we won't know which condition in which method is exactly
breaking the test. As per my understanding unit tests should be written at
the granularity level and methods are more granular than functionality.
Also we have to make a deal with the coverage rate in case of functionality
testing.

Taking given example in case of method based approach:
cli_base.env() and cli_env.prepare():

If we will go method based approach then one unit test for cli_base.env()
make sense and depending on the behaviour (considering branches/exception
etc.) of cli_env.prepare() multiple tests for the same method could be
there ( currently two written:
https://gerrit.opnfv.org/gerrit/#/c/26143/13/functest/tests/unit/cli/commands/test_cli_env.py
).

I agree we won't have high level overview about the functionality but
wondering if that is the motive of writing unit tests but we would have all
the possible breaking points covered in each functionality.


IMHO, it might be overkilled to cover all possible breaking points. There
is a *tradeoff* between comprehensive testing and the workloads required to
implement them and keep them up to date.

To me, the public interface is the contract given by the module and should
be verified. The internal details such as private methods are likely being
refactored during development.

When a failure is detected, developers may leverage other ways besides unit
test to diagnose it. Common ways for this are:

   1. log messages in a production system
   2. debugging tools in development environment.

Benefit of taking method based approach is:
1. we will know the exact method/condition where the issue is
2. There would be separation (non-overlapping) among the tests i.e. ideally
unit tests should have
3. We can achieve good code coverage
4. Our test would be much more modular and granular.

Also, I have prepared some slides mentioning some points I felt and
explored about unit tests.
I have make the link editable so that anyone with the link can edit, please
correct me if I am wrong somewhere  or add more points if needed.
Link:
https://docs.google.com/presentation/d/1vFVLP1SRPaKL3b90wTlc6NuE6zyf5Q4FhbxcN12W4IA/edit?usp=sharing


Thanks

On Wed, Jan 4, 2017 at 12:12 PM, Yujun Zhang <zhangyujun+...@gmail.com>
wrote:

Serena,

Maybe the term `interface` fits better here. I agree with you that the
target of unit test in Python is *module*.

We ensure with unit test the existing interfaces of the module are not
broken by new code and new interfaces implemented work as expected.

The private methods (which does not expose anything of the module) is not
something promised by the module and we don't need to create dedicated unit
test for them. They are normally covered by the unit test of related public
methods.

My another two cents...

On Wed, Jan 4, 2017 at 2:04 PM <feng.xiao...@zte.com.cn> wrote:

Sorry, I didn't express my idea clearly enough during the meeting.

When I say function-based, it is not equal to functional test. Unlike
functional test, it is still a kind of white-box test.

And compared to method-based unit test, which consider the method as a test
object, it treats the module as an unit,

it guarantees the module works as expected after new requirements come or
any refactor requires.


Sorry for my poor expression, and let me take 'functest env prepare' of cli
module in Functest for

example(where the discussion comes from).

Instead of testing cli_base.env() and cli_env.prepare() separately,

we can test them together by writing the following four test cases(naming
is not very good just for description purpose):

test_cli_env_first_time_prepare()

test_cli_env_re_prepare()

test_cli_env_not_prepare_again()

test_cli_env_invalid_prepare_answer()

In this way, all the code can be covered as method-based way do, and at the
same time when something

changed in cli_env.prepare() and if it doesn't break the functionality it
should provide, we don't need to

rewrite the unit test, and on the contrary, if it breaks, the unit test
will detect it and notify us with a failure,

and of course, if the functionality needs to change, we should rewrite the
unit test.

If unit test is written in the way of method-based, almost everytime the
code change will cause the rewriting

of the test code, and fu

Re: [opnfv-tech-discuss] [dovetail]Dovetail encryption for report

[Yujun Zhang]

On Tue, Dec 27, 2016 at 3:54 PM Leo Wang  wrote:

> As i mentioned , someone did show their concern on the security of test
> report, so dovetail will provide this optional parameter for them
>
> digital signature is used to identify the source and its integrity, and
> surely it can raise the security level, or even better to get a digital
> certificate to make it more secure?
>

Sure.

You may refer the international standard  ISO/IEC 17065 on how to certify a
product. The standard is not about technical solution but quality processes
and organizations.

Encryption or signature are all technical methods to enhance the authority
of a certification program.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [dovetail]Dovetail encryption for report

[Yujun Zhang]

I thought report is normally public to read.

But it is important to have digital signatures so that the content can be
trusted. The algorithm is similar to encryption.

My two cents.

On Tue, Dec 27, 2016 at 10:38 AM Leo Wang  wrote:

> Hi all
>
> The report in plain-text is vulnerable from malicious attacks.
>
> If user want to secure their report and do not want the report be peeked
> at by any unexpected person,they can simply add a parameter into the
> command line.
>
> Users do not need to know or learn any details about that how to encrypt.
>
> Dovetail will provide a optional parameter "-e" ("–encrypt") for user to
> encrypt the test report.
>
> With this parameter, dovetail will generate a report in cipher-text and a
> secret key in cipher-text together instead of a single plain-text report.
>
>
> Welcome to share your great ideas on this topic!!
>
> For more details, please punch in the link:
>
> https://wiki.opnfv.org/display/dovetail/Dovetail+Encryption+For+Report
>
>
> BR
>
> Leo Wang
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Sprint QTIP-D4 => QTIP-D5

[Yujun Zhang]

QTIP runners,

Sprint QTIP-D4 is completed with 7 out of 15 issues closed. See sprint
report[1] for details

In next sprint, we shall focus on

   1. Create Collector and Reporter PoC
   2. API server requirements and plan for Danube
   3. CLI for implemented modules
   4. Yardstick integration proposal

Ready? Go!

[1]
https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=135=QTIP=reporting=sprintRetrospective=207
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [qtip] Weekly Meeting Agenda 2016-12-26

[Yujun Zhang]

https://etherpad.opnfv.org/p/qtip-meetings-2016-12-26

QTIP project weekly meeting on 2016-12-26
time: UTC0730
irc://#opnfv-qtip@freenode
index: https://etherpad.opnfv.org/p/qtip-meetings
Action followup

   - @zhihui to investigate how to detect yardstick finishing


   - @zhihui to propose a design specification of yardstick integration

Topics

   - sprint QTIP-D5 planning


   - architecture and design evolution


   - https://wiki.opnfv.org/display/qtip/Architecture


   - https://wiki.opnfv.org/display/qtip/Design

Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198

AOB

   - new intern project qtip-api
   https://wiki.opnfv.org/display/DEV/Intern+Project%3A+QTIP+API+Server
___
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-security] Security checks at Gate

[Yujun Zhang]

Luke,

I remember that Fatih once mentioned that there are no gates in OPNFV CI
yet. So you are talking about some additional verification jobs enforced on
each commit. Or it is something like the current daily/weekly job.

Could you help to clarify it?

On Mon, Dec 19, 2016 at 7:39 PM Luke Hinds  wrote:

> Hi,
>
> Myself and Ash with help from Fatih are currently prototyping some new
> gates we plan to phase in overtime.
>
> The idea is that each commit made to an OPNFV repo will perform some
> checks.
>
> 1. Search for any strings containing passwords, ssh / tls certs and other
> stuff we don't want sitting around in repos to then be scooped up for a
> release.
>
> 2. Search out any binaries. We need to be very strict over what compiled
> binaries are packaged in release (if any at all), as a binary could be
> compromised (without the knowledge of the project itself).
>
> 3. Security lint checks. Code will be searched for patterns such as shell
> executions, xss flaws etc and reports linked within the gate.
>
> The plan is to have 1,2 as voting (-1 / +1) and 3 initially as a guide for
> projects, with the support of the security group, if needed.
>
> For both 1,2 we will maintain a waiver / exception list. This means that
> if no threat is shown to be present, an ignore entry can be made for a
> single project. The gate will then allow the said string, file etc to pass
> with no vote.
>
> Initially we are working with a sandbox project, so expect no
> interruptions at all. From there we will start to bring projects over, so
> they will be aware ahead of any changes implemented that will affect them.
>
> Cheers,
>
> Luke
> ___
> opnfv-security mailing list
> opnfv-secur...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-security
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Starting to clean-up meetings page on the wiki

[Yujun Zhang]

The demo page looks good.

Would it be acceptable to split meetings by working group instead of
projects? test-wg, mano-wg, infra-wg and etc.

On Sat, Dec 17, 2016 at 12:52 AM Beierl, Mark <mark.bei...@dell.com> wrote:

> Hello, Gerald.
>
> Unfortunately, there is not an easy way to filter out events from a
> calendar, but what can be done is to include the Promise calendar into the
> Team Meetings calendar.  As long as you use the same type for your event
> (i.e. OPNFV GoToMeeting) and colour, it will show up.
>
> I am not sure if that is the right approach, however, as that means each
> project would have its own calendar for meetings, instead of having a
> single calendar.
>
> Advantages:
>
>- Users can subscribe to a project's calendar and see only those
>events instead of everything.
>- Might get rid of the annoying "Some events were not shown in the
>calendars below..." banner
>- Teams have cleaner view
>
> Disadvantages:
>
>- "Legend" for team calendars will be huge as it must show every
>project title.
>- Each team calendar must have same event types and colours.
>
>
> I have put a "Test" calendar into the Demonstration Space [1] that shows
> what it looks like to display multiple calendars in a single view.  Note
> the legend on the left where it shows "TestPerf", "StorPerf", OPNFV Team
> Meetings.
>
> What do others think of the choices?
>
> [1] https://wiki.opnfv.org/display/ds/calendars
>
> Regards,
> Mark
>
> *Mark Beierl*
> Advisory Solutions Architect
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Dec 16, 2016, at 05:27, Kunzmann, Gerald <kunzm...@docomolab-euro.com>
> wrote:
>
> Hi Yujun, Mark, all,
>
> Thanks for the pointer to the list view.
>
> Does anyone know if I could include the “OPNFV Team Meetings” calendar in
> my project and **filter for Promise meetings**. That way, I could avoid
> maintaining a Promise calendar and the “OPNFV Team Meetings” calendar.
>
> Best regards,
> Gerald
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [
> mailto:opnfv-tech-discuss-boun...@lists.opnfv.org
> <opnfv-tech-discuss-boun...@lists.opnfv.org>] *On Behalf Of *Yujun Zhang
> *Sent:* Freitag, 16. Dezember 2016 10:41
> *To:* Raymond Paik <rp...@linuxfoundation.org>;
> opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] Starting to clean-up meetings page on
> the wiki
>
> On Fri, Dec 16, 2016 at 3:36 AM Raymond Paik <rp...@linuxfoundation.org>
> wrote:
>
> All,
>
> Next step is to see if there's a way to streamline the meetings calendar
> on the upper right corner.  If anyone has good ideas/suggestions, please
> let me know.
>
>
> We use the list view in TestPerf meeting calendar[1]. Not sure if this
> works for massive meetings.
>
> [1]: https://wiki.opnfv.org/display/meetings/TestPerf
>
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [test-wg] [all] TestPerf EcoSystem diagram now editable

[Yujun Zhang]

See my replies inline.

On Fri, Dec 16, 2016 at 3:43 PM Gaoliang (kubi) 
wrote:

> Hi Yujun,
>
>
>
>  it may delivers misleading information to the whole community.
>

This is exactly my motivation of the modification.

I hope we can find out the original agreement so we can know why it is
delivering a misleading message and we can work together to improve the
process to keep things in order.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] committer list maintainance

[Yujun Zhang]

+1 for the idea of automatic monitoring
--
Yujun

On Fri, Dec 16, 2016 at 4:15 AM Heather Kirksey <
hkirk...@linuxfoundation.org> wrote:

> I like Morgan's suggestion -- the expectation of committers is that
> they're active and actively working the project; if they're not
> participating and not responding to emails, it's reasonable to remove them
> from the committer file. As folks say, this isn't a "punishment for bad
> faith" but a recognition that people move on from companies, roles, or
> projects. Having an automated way to handle this sounds reasonable…..
>
> From my perspective, our TSC isn't focusing on what it needs to focus on
> if they're voting on the removal of every nonactive committer on every
> project. That's also not entirely a scalable solution as we continue to
> grow as a community. Empowering PTLs to manage their committers with the
> help of automated tools seems like the right thing to do.
>
> This also relates to our community metrics discussion; if some projects
> experience much higher than average turnover in committers, it might be a
> reason to see what's going on and if the project needs help in some way.
> Focusing on how to enable and help projects be successful and removing
> obstacles if they're having issues is a good use of time; micro-managing
> committer lists is not.
>
> My $.02.
>
> Heather
>
>
>
> On Thu, Dec 15, 2016 11:46 AM, Raymond Paik rp...@linuxfoundation.org
> wrote:
>
> Please see an example from May of this year:
> https://wiki.opnfv.org/display/meetings/TSC#TSC-May17,2016 when the
> VSPERF PTL had several inactive committers who were non-responsive/not
> reachable.
>
> If this is still too taxing for the PTLs, we can have a discussion in the
> TSC call
>
> On Wed, Dec 14, 2016 at 1:33 AM, <morgan.richo...@orange.com> wrote:
>
> in line with Yujun
> no need to attend TSC to remove non active committers
> usually we can do it through a patch of INFO file
>
> the only case I can see a need to attend TSC is in case of conflict but I
> never saw that so far
>
> during OpenStack Barcelona, we mentioned that it would be also nice to
> implement something to automatically remove 6 months non active
> contributors.
> the idea is not to blame but to clean the repo and reflect the reality of
> the project activity
> I agree that there are no commitments, people can move from one project to
> another
> however it is better to have a good idea of the project activity and then
> keeping long list of non active contributors is misleading
>
> So I would suggest to implement a job that will automatically remove a
> contributor Y of a project X if no activitiy has been reported since more
> than 6 months
> If the project has no commitor anymore or only the PTL or empty repo since
> x months => raise an alarm to TSC to clean also the project
>
> /Morgan
>
>
>
> Le 14/12/2016 à 08:31, joehuang a écrit :
>
> +1000 for this "I never think it is a shame to leave a project,  since it
> is normal that people move on to a new target and didn't have time to say
> goodbye"
>
> Best Regards
> Chaoyi Huang (joehuang)
> --
> *From:* Yujun Zhang [zhangyujun+...@gmail.com]
> *Sent:* 14 December 2016 15:10
> *To:* joehuang; Raymond Paik
> *Cc:* opnfv-tech-discuss
> *Subject:* Re: [opnfv-tech-discuss] committer list maintainance
>
> I think there is no mandatory rule for PTL to attend TSC meeting in order
> to complete the removal process. At least, I never did that before.
>
> On my side, I have tried to contact several inactive committers to ask for
> their willingness and most of them replies politely to explain why. And we
> have a happy ending by putting them in retired list[1].
>
> I did encounter the situation that losing contact to some committer. And
> we just ask TSC to approve the removal and that's it.
>
> After all, I never think it is a shame to leave a project, since it is
> normal that people move on to a new target and didn't have time to say
> goodbye.
>
> [1]:
> https://wiki.opnfv.org/display/qtip/Platform+Performance+Benchmarking#PlatformPerformanceBenchmarking-RetiredCommitters
>
>
> On Wed, Dec 14, 2016 at 2:17 PM joehuang <joehu...@huawei.com> wrote:
>
> In OPNFV we "assume bad faith"? This is not a good assumption.
>
> The less meeting, the better, and usually a TSC meeting will be in the
> night or early morning for me to join. If even need to go to TSC meeting
> for 5 minutes for approval, I would prefer to retain the inactive committer
> there, just let it be.
>
>
> Best Regards
> Chaoyi Huang (joehuang)
> --
> *Fro

[opnfv-tech-discuss] [qtip] Agenda for weekly meeting 2016-12-19

[Yujun Zhang]

@Kubi, @Rex, you are welcomed to join this meeting since the first and main
topic would be *yardstick integration*. Thanks a lot for the answers on
etherpad page.

@zhihui, please review the answers and let me know whether it is clear
enough for us to create a proposal on how to implement it.

QTIP project weekly meeting on 2016-12-19
time: UTC0730
irc://#opnfv-qtip@freenode
index: https://etherpad.opnfv.org/p/qtip-meetings
Action followup

   - 

Topics

   - *yardstick integration status update*


   - *https://etherpad.opnfv.org/p/qtip-yardstick*
   


   - project vision update


   - https://wiki.opnfv.org/display/qtip/Vision


   - architecture evolution


   - https://wiki.opnfv.org/display/qtip/Architecture


   - https://wiki.opnfv.org/display/qtip/Future


   - Benchmark terminology renaming, again...
   https://jira.opnfv.org/browse/QTIP-182


   - testplan => plan = condition + N * suite


   - suite => suite = formula + N * module


   - perftest => module = configuration + perf tool

Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP=135


   - CI status https://build.opnfv.org/ci/view/qtip/


   - new tasks in JIRA https://jira.opnfv.org/issues/?filter=11198

AOB

   - 


Feel free to update the topics in etherpad
https://etherpad.opnfv.org/p/qtip-meetings-2016-12-19
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [test-wg] [all] TestPerf EcoSystem diagram now editable

[Yujun Zhang]

Hi Kubi

Could you remind me record of the previous agreement? I may not be member
of QTIP project at that moment.

I made some correction on QTIP to make it closer to facts. Comments are
welcome.
Gaoliang (kubi) <jean.gaoli...@huawei.com>于2016年12月15日 周四22:20写道：

> Hi Yunjun,
>
>
>
> Thanks for your work to make the TestPerf Ecosystem image editable. But I
> ‘m a little confused with the rule of the TestPerf EcoSystem Diagram
> modification.
>
> It seems that you have modified the  TestPerf Ecosystem structure.  I ‘m
> not sure if it is a good way to modify the Ecosystem Diagram without
> agreement of whole testing community.
>
> All the performance test projects are involved in Benchmark area. I guess
> what Qtip want to do is to calculate the score from the Yardstick test
> result. So I guess we still need to have a discussion with test projects
> about the structure and the key words of each area. Thanks.
>
>
>
> Regards,
>
> Kubi
>
>
>
> *发件人:* test-wg-boun...@lists.opnfv.org [mailto:
> test-wg-boun...@lists.opnfv.org] *代表 *Yujun Zhang
> *发送时间:* 2016年12月15日 21:05
> *收件人:* test-wg
> *抄送:* TECH-DISCUSS OPNFV
> *主题:* [test-wg] [all] TestPerf EcoSystem diagram now editable
>
>
>
> Hi testers,
>
>
>
> I have replaced the previous image of TestPerf EcoSystem with an editable
> diagram in the overview section of testperf wiki page[1]. Please review and
> amend if something is missing.
>
>
>
> https://wiki.opnfv.org/display/testing/TestPerf
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss