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

[Yujun Zhang]

Please feel free to add topics you wish to discuss.

QTIP project weekly meeting on 2016-11-02
online chatting: irc://#opnfv-qtip@freenode
screen sharing: https://zoom.us/j/914417686
Action followup

   - #done @yujunz resend PyCharm keys to @serena


   - #done @yujunz to promote at least one more committer


   - @zhihui to followup on fuel status


   - #done @yujunz check JIRA permissions for contributors and submitters


   - @yujunz to acquire docker file admin permission


   - #done @yujunz create tasks for next sprint

Topics

   - visualization solution


   - grafana: good at realtime data visualization (comments from Yardstick
   PTL kubi)


   - (preferred) kibana: good at searching and data mining with
   elasticsearch


   - #info committer update


   - new: wu.zhih...@zte.com.cn


   - retired: Nauman Ahad


   - removed: Michael Haugh


   - #info Embargo level for security issues in JIRA


   -
   
https://wiki.opnfv.org/display/security/Security+Vulnerability+Classification+in+OPNFV+JIRA


   - storage benchmark explaination

Recurring

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


   - update during last week 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] [opnfv-project-leads] Security Vulnerability Classification in OPNFV JIRA

[Yujun Zhang]

Thanks for Luke to provide such solution for OPNFV projects.

A short word in my understanding, security issues should not be exposed to
public before it gets fixed.

The JIRA security scheme provide us a convenient way to protect such
secrets. I would encourage every project to try it out.

Step 1. send a request to helpdesk.
Step 2. use it

See more details in
https://wiki.opnfv.org/display/security/Security+Vulnerability+Classification+in+OPNFV+JIRA

--
Yujun

On Tue, Nov 1, 2016 at 7:49 PM Luke Hinds  wrote:

> Hi,
>
> We now have a JIRA private security scheme that can be requested for
> assignment to projects.
>
> This will allow OPNFV projects to tag security issues raised in JIRA as
> private.
>
> I really would advise projects to make use of this JIRA feature. Being
> able to work on security fixes under a private embargo reduces the pressure
> of a security risk being found in your project, and in turn allows
> downstream stakeholders time to prepare patches / patch deployment plans.
>
> By being vulnerability managed, you will have the help of the security
> group to allow a co-ordinated response using 'responsible disclosure'
> approach.
>
> More details on how to sign up are on the security group wiki page:
> https://wiki.opnfv.org/display/security/Security+Vulnerability+Classification+in+OPNFV+JIRA
>
> Big thanks for Mark Beierl for setting this up, and the support from Yujun
> Zhang on making QTIP a pilot project.
>
> Regards,
>
> Luke - Security Group PTL.
> ___
> opnfv-project-leads mailing list
> opnfv-project-le...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
>
___
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] [opnfvdocs] Planning of D release documentation

[Yujun Zhang]

The epic name is quite long.

Since it is all under OPNFV namespace, we may omit the prefix and use some
abbreviation. e.g. Danube docs
--
Yujun

On Tue, Nov 1, 2016 at 8:18 PM Sofia Wallin 
wrote:

> Hi Maryam,
>
> Depending on which documents you plan contributing to, create one or more
> new stories within your project and then add an Epic Link to targeted
> document,
>
> OPNFV Danube Installation and configuration guide
> , OPNFV Danube User Guide
>  and/or Danube documentation
> .
>
>
>
> You can do this using the Epic Link field on new story creation form by
> adding the corresponding epic there, see example here,
>
> https://jira.opnfv.org/browse/RELENG-157
>
>
>
> For additional documentation (release notes, test specifications,
> development etc.) Danube documentation
>  has been created to be used as
> Epic reference.
>
>
>
> BR,
>
> Sofia
>
>
>
> *From:* Tahhan, Maryam [mailto:maryam.tah...@intel.com]
> *Sent:* den 1 november 2016 10:34
> *To:* Sofia Wallin ;
> opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV (
> opnfv-tech-discuss@lists.opnfv.org) 
> *Subject:* RE: [opnfv-project-leads] [opnfvdocs] [opnfv-tech-discuss]
> Planning of D release documentation
>
>
>
> Hi Sofia
> How do I cross reference JIRA issues to “OPNFV documentation”? through a
> label or something else?
>
> Thanks
>
> Maryam
>
>
>
> *From:* opnfv-project-leads-boun...@lists.opnfv.org [
> mailto:opnfv-project-leads-boun...@lists.opnfv.org
> ] *On Behalf Of *Sofia Wallin
> *Sent:* Monday, October 31, 2016 3:19 PM
> *To:* opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV (
> opnfv-tech-discuss@lists.opnfv.org) 
> *Subject:* [opnfv-project-leads] [opnfvdocs] [opnfv-tech-discuss]
> Planning of D release documentation
>
>
>
> Hi everyone,
>
> Looking into the D release planning for all projects I’ve noticed that not
> all of you have indicated if any documentation is planned for the D release
> or not.
>
> To be able to follow the documentation progress I would appreciate your
> help in creating a Jira ticket with a cross reference to “OPNFV
> documentation” and/or add this information to the planning page
> 
> that David created
>
> (see example for Copper project
> ).
>
>
>
>
> *It is still not clear how we shall handle Jira tickets for our
> documentation but listening to your feedback from Colorado it is at least
> for now preferable to have these tickets governed within each project
> instead of having them created by the docs project. This will allow you to
> update the progress yourself. *
>
>
>
> Let me know if you have any questions or comments and everyone is welcome
> to participate in the docs project meeting Wednesdays every second week
> (odd weeks).
>
>
>
> Regards,
>
> Sofia
> ___
> opnfv-project-leads mailing list
> opnfv-project-le...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Graduation reviews discussion

[Yujun Zhang]

I think there would be a different expectation for "mature" projects.

It is quite difficult to define "fully functional" and "stable" since the
projects never stop evolution even after mature.

>From a developer's view, a mature project can be judged from

   1. regular release cycle
   2. test coverage
   3. documentation completeness
   4. security integrity
   5. timely response on feedback
   6. fluent process on evolution

My two cents.

On Thu, Nov 3, 2016 at 1:25 PM Raymond Paik 
wrote:

> All,
>
> One of my action items from the TSC meeting  We discussed graduation
> reviews for "mature" projects in OPNFV.  On the Project Lifecycle document (
> https://www.opnfv.org/developers/technical-project-governance/project-lifecycle),
> a mature project is defined as "Project is fully functioning and stable,
> has achieved successful releases."
>
> One of the questions that was raised on the call was, after graduation how
> would "mature" projects be different from projects in the "incubation"
> stage.  Is this just a badge/label or are there different expectations?
>
> Please discuss :-)
>
> 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] OPNFV on Github

[Yujun Zhang]

Looks great!

Can we just disable "issue", "pull request" and "wiki"?

And it would be good to provide project link in the description line.


On Fri, Nov 4, 2016 at 4:07 AM Trevor Bramwell <
tbramw...@linuxfoundation.org> wrote:

Hi Luke, et al.,

The OPNFV Gerrit repos should now exist under https://github.com/opnfv,
and they get updated within 30s of Gerrit changes being merged.

We are still working on getting the bot in place to close PR's and
forward people onto a 'Getting started with OPNFV' page.

For those interested in seeing their OPNFV contributions show up in
their Github profile, they will need to update their list of email
addresses on their Github account to include the address used to submit
changes to Gerrit.

If you see any repos missing, or have any concerns, please let us know
at helpd...@opnfv.org.

Regards,
Trevor Bramwell

On Fri, Oct 21, 2016 at 10:38:03AM +0100, Luke Hinds wrote:
> Hi All,
>
> I took my eye off the ball and missed the dates for this week.
>
> Did anything transpire?
>
> Luke
>
>
>
> >
> > On Wed, Oct 5, 2016 at 10:41 AM, Christopher Price <
chrispric...@gmail.com
> > > wrote:
> >
> >> Hi Folks,
> >>
> >>
> >>
> >> I’d like to propose that we:
> >>
> >> 1)   Clarify how we want this to be done  (looks like we have a
> >> solid idea of this now)
> >>
> >> 2)   Determine whom will “own” the github account (Aric &/or Trevor
> >> I guess)
> >>
> >> 3)   Present and discuss in community (October 13th call I think is
> >> the best)
> >>
> >> 4)   Present it to the TSC for approval (October 18th would seem
> >> adequate)
> >>
> >> 5)   Make it so…
> >>
> >>
> >>
> >> Maybe we can capture this on the wiki in some way.
> >>
> >> I have made a start:  https://wiki.opnfv.org/display
> >> /DEV/Licensing+and+External+repo%27s+discussion#Licensinga
> >> ndExternalrepo%27sdiscussion-ProposalforOPNFVrepomirroringtoGitHub but
> >> it probably needs some niceness added to it.  J
> >>
> >> We can present and discuss this on the 13th and potentially use it for
> >> TSC approval on the 18th.
> >>
> >>
> >>
> >> / Chris
> >>
> >>
> >>
> >> *From: * on behalf of Peter
> >> Lee 
> >> *Date: *Wednesday 5 October 2016 at 04:58
> >> *To: *"SULLIVAN, BRYAN L" , Aric Gardner <
> >> agard...@linuxfoundation.org>, "MORTON JR., AL" 
> >> *Cc: *TECH-DISCUSS OPNFV 
> >>
> >> *Subject: *Re: [opnfv-tech-discuss] OPNFV on Github
> >>
> >>
> >>
> >> I started the opnfv org in github a while back to host the promise
> >> project and associated assets. I'd be happy to transfer the ownership
of
> >> the GitHub opnfv org to whoever we designate as the new owner.
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> On Tue, Oct 4, 2016 at 1:02 PM SULLIVAN, BRYAN L 
wrote:
> >>
> >> Aric,
> >>
> >> When you say " mirroring to github is done " you don't mean currently,
> >> right? ("will be done")
> >>
> >> Also - any chance we could get Iben to donate opnfv to us as the org
> >> name? He got out ahead of this game a while back:
> >> https://github.com/opnfv
> >> It would be great if we could hang our repos off that link and org...
> >>
> >> Thanks,
> >> Bryan Sullivan | AT&T
> >>
> >> -Original Message-
> >> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> >> opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Aric Gardner
> >> Sent: Tuesday, October 04, 2016 12:32 PM
> >> To: MORTON JR., AL 
> >> Cc: opnfv-tech-discuss@lists.opnfv.org
> >> Subject: Re: [opnfv-tech-discuss] OPNFV on Github
> >>
> >> The mirroring to github is done with a Gerrit plugin and updates live.
> >>
> >> Regards,
> >> Aric
> >>
> >> On Tue, Oct 4, 2016 at 12:06 PM, MORTON, ALFRED C (AL) <
acmor...@att.com>
> >> wrote:
> >> > Sounds good to me, +1.
> >> >
> >> >
> >> >
> >> > Additional question:
> >> >
> >> > How often will we execute the mirroring operation to GitHub?
> >> >
> >> > Nightly (UTC)?
> >> >
> >> >
> >> >
> >> > Al
> >> >
> >> >
> >> >
> >> > From: opnfv-tech-discuss-boun...@lists.opnfv.org
> >> > [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Ash
> >> > Sent: Tuesday, October 04, 2016 11:47 AM
> >> > To: Leif Madsen
> >> > Cc: opnfv-tech-discuss@lists.opnfv.org
> >> > Subject: Re: [opnfv-tech-discuss] OPNFV on Github
> >> >
> >> >
> >> >
> >> > It sounds like we're all in violent agreement on this. And I'm okay
for
> >> the
> >> > meeting being delayed to the 13th.
> >> >
> >> >
> >> >
> >> > So, to summarize:
> >> >
> >> >
> >> >
> >> > 1) The github repo should be a read-only mirror of Gerrit.
> >> >
> >> > 2) Gerrit should be the workflow for and point for all check-ins
> >> >
> >> > 3) Still, to protect ourselves on github, all admins/owners will
utilize
> >> > 2-factor authentication for security purposes.
> >> >
> >> > 4) We will postpone the community discussion until Bin's 10/13 call.
> >> >
> >> > 5) Since the github repo will be a mirror of what's on Gerrit, it
will
> >> > continue to reinforce/reflect OPNFV governance, license practices,
and
> >> any
> >> > 

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

[Yujun Zhang]

Please note that it has been rescheduled to *UTC0800 every Monday* to avoid
confliction with TestPerf APAC meeting. And we shall use only IRC.

This change is affecting all the future meetings.

See agenda as below and feel free to add new topics you wish to talk.

https://etherpad.opnfv.org/p/qtip-meetings-2016-11-07

QTIP project weekly meeting on 2016-11-07
time: UTC0800
irc://#opnfv-qtip@freenode
Action followup

   - @Taseer to test and update kibana playbook


   - @zhifeng provide details on the ELK setup playbook


   - #done @yujunz provide an example of using vagrant in unit test


   - @zhihui to do some research on dovetail on how to consume test data
   from YardStick

Topics

   - Should CLI be installed and run from host or container?

Recurring

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


   - update during last week https://jira.opnfv.org/issues/?filter=11198

AOB

   - 
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
VERSION:2.0
X-WR-CALNAME:QTIP Weekly Meeting
METHOD:PUBLISH
PRODID:-//Apple Inc.//Mac OS X 10.12.1//EN
BEGIN:VEVENT
TRANSP:OPAQUE
DTEND:20161107T09Z
UID:6FE27228-7512-443B-8B7E-61D3EDD389C1
DTSTAMP:20161104T063645Z
LOCATION:irc://#opnfv-qtip@freenode
DESCRIPTION:
URL;VALUE=URI:https://etherpad.opnfv.org/p/qtip-meetings
SEQUENCE:0
SUMMARY:QTIP Weekly Meeting
DTSTART:20161107T08Z
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
CREATED:20161101T055612Z
RRULE:FREQ=WEEKLY
BEGIN:VALARM
X-WR-ALARMUID:DEBB6140-D901-4B35-94A9-59112029E5FB
UID:DEBB6140-D901-4B35-94A9-59112029E5FB
TRIGGER:-PT10M
DESCRIPTION:Reminder
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
___
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] Reset Server State and alarms in general

[Yujun Zhang]

Hi, doctors

Is there any update on this topic?

It seems parallel execution will boost the performance on large scale
system.

But there was a different opinion on whether the current workflow is
reasonable or not. Should the notification be sent from inspector directly
or setting VM state error and leave it to NOVA to send notification?

BTW: the doctor demo on OpenStack Summit is fabulous[1]. Don't miss it.

[1]
https://www.openstack.org/videos/video/demo-openstack-and-opnfv-keeping-your-mobile-phone-calls-connected

--
Yujun

On Tue, Oct 4, 2016 at 8:54 PM Juvonen, Tomi (Nokia - FI/Espoo) <
tomi.juvo...@nokia.com> wrote:

> Hi,
>
>
>
> Not DB issue since just sending notifications took same time as changing
> DB at the same.
>
>
>
> Br,
>
> Tomi
>
>
>
> *From:* Ryota Mibu [mailto:r-m...@cq.jp.nec.com]
> *Sent:* Tuesday, October 04, 2016 3:48 PM
> *To:* Juvonen, Tomi (Nokia - FI/Espoo) ; Yujun
> Zhang ; opnfv-tech-discuss@lists.opnfv.org
>
>
> *Subject:* RE: [opnfv-tech-discuss] [Doctor] Reset Server State and
> alarms in general
>
>
>
> Tomi,
>
>
>
>
>
> So, it seems to be a DB bottleneck issue.
>
>
>
> Having bulk API to reset servers with query would be a solution?
>
>
>
> Anyhow, we can talk in the meeting soon.
>
>
>
>
>
> BR,
>
> Ryota
>
>
>
> *From:* Juvonen, Tomi (Nokia - FI/Espoo) [mailto:tomi.juvo...@nokia.com
> ]
> *Sent:* Tuesday, October 04, 2016 9:08 PM
> *To:* Mibu Ryota(壬生 亮太) ; Yujun Zhang <
> zhangyujun+...@gmail.com>; opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] [Doctor] Reset Server State and
> alarms in general
>
>
>
> Hi,
>
>
>
> Still modified the test so that I do not do the reset server state, but
> instead just make the notification about “reset server state error” for
> each instance when force-down API called:
>
> for instance in instances:
>
> notifications.send_update_with_states(context, instance,
>
> instance.vm_state, vm_states.ERROR,instance.task_state,
>
> None, service="compute", host=host,verify_states=False)
>
>
>
> This had the same result as trough instance.save() that also changes the
> DB. So didn’t make things any better.
>
>
>
> Br,
>
> Tomi
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [
> mailto:opnfv-tech-discuss-boun...@lists.opnfv.org
> ] *On Behalf Of *Juvonen,
> Tomi (Nokia - FI/Espoo)
> *Sent:* Tuesday, October 04, 2016 12:30 PM
> *To:* Ryota Mibu ; Yujun Zhang <
> zhangyujun+...@gmail.com>; opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Suspected SPAM - Re: [opnfv-tech-discuss] [Doctor] Reset
> Server State and alarms in general
>
>
>
> Hi,
>
>
>
> 1.  Tried that 300 while it is also the default, so no difference.
>
>
>
> 2.  Then I modified force-down API that it internally makes reset
> server state for all instances on host (so it is the only API called from
> inspector) and was no difference:
> With 10VMs where 5 VMs on failing host: 1000ms
> With 10VMs where 5 VMs on failing host: 1040ms
> With 20VMs where 10 VMs on failing host: 1540ms to 1780ms
>
>
>
> 3.  Then added debug print over this code in modified forced-down API
> that gets servers and does reset state for each.
> Run Doctor test case:
> With 20VMs where 10 VMs on failing host: 1540ms
> In Nova code:
>
> Getting instances:
>
> instances = self.host_api.instance_get_all_by_host(context, host)
>
> Took: 32ms
>
> Looping 10 instances to make reset server state to error:
>
> for instance in instances:
>
> instance.vm_state = vm_states.ERROR
>
> instance.task_state = None
>
> instance.save(admin_state_reset=True)
>
> Took: 1250ms
>
> And can then also pick up the whole time the *API* took:
>
> 2016-10-04 09:05:46.075 5029 INFO nova.osapi_compute.wsgi.server
> [req-368d7fa5-dad6-4805-b9ed-535bf05fff06 b175813579a14b5d9eafe759a1d3e392
> 1dedc52c8caa42b8aea83b913035f5d9 - - -] 192.0.2.6 "PUT
> /v2.1/1dedc52c8caa42b8aea83b913035f5d9/os-services/*force-down* HTTP/1.1"
> status: 200 len: 354 time: 1.4085381
>
>
>
> So the usage of reset server state is currently not feasible (and like
> indicated before, shouldn’t even be used).
>
>
>
> Br,
>
> Tomi
>
>
>
> *From:* Ryota Mibu [mailto:r-m...@cq.jp.nec.com ]
> *Sent:* Saturday, October 01, 2016 8:54 AM
> *To:* Yujun Zhang ; Juvonen, Tomi (Nokia -
> FI/Espoo) ; opnfv-tech-discuss@lists.opnfv.org
> *Subject:* RE: [opnfv-tech-discuss] [Doctor] Reset Server State and
> al

[opnfv-tech-discuss] [infra] etherpad down?

[Yujun Zhang]

I got 502 Bad Gateway error while accessing https://etherpad.opnfv.org/
Is it down?

--
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] [infra] etherpad down?

[Yujun Zhang]

Forwarded to helpdesk.

Thanks for reminding.

On Mon, Nov 7, 2016 at 12:18 PM Raymond Paik 
wrote:

> Yujun,
>
> Thanks for the heads-up.  The best thing to do is to send an email to
> opnfv-helpd...@rt.linuxfoundation.org (rather than post on
> opnfv-tech-discuss).  I already sent an email to opnfv-helpdesk so that a
> ticket has been created
>
> Thanks,
>
> Ray
>
> On Sun, Nov 6, 2016 at 5:20 PM, Yujun Zhang 
> wrote:
>
> I got 502 Bad Gateway error while accessing https://etherpad.opnfv.org/
> Is it down?
>
> --
> Yujun
>
>
> ___
> 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] [VES] Team Meeting Schedule

[Yujun Zhang]

Which week day is the meeting? Not mentioned in the original message.

On Wed, Nov 2, 2016 at 12:17 AM SULLIVAN, BRYAN L  wrote:

> FYI: OPNFV MANO WG Meeting Details
> Meeting Times: Weekly 7 AM PDT (15:00 UTC) this week and 7 AM PST (14:00
> UTC) after daylight changes next week
>
___
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] testing meeting APAC slot

[Yujun Zhang]

Hi, all

Thank Morgan for bringing QTIP to the agenda.

May I propose to postpone it to next week? I haven't get the presentation
ready yet :-(. It is too hurry for tomorrow.

About the APAC slot, it is even more confusing for Dec because Dec 1st is
Thursday.

How about modifying the rule as *2nd meeting* of each month for APAC
meeting. What do you think?
--
Yujun

On Tue, Nov 8, 2016 at 5:14 PM  wrote:

> Hi
>
> the next weekly meeting APAC slot is not clear. We indicate 2 dates in the
> wiki: https://wiki.opnfv.org/display/meetings/TestPerf
>
> According to the calendar it is on the 9th but the agenda is declared for
> the 10th...
>
> I assume it is the 9 8UTC => I modified the wiki
>
> if so for the moment we do not have chair/minutes and the agenda is
> limited to the discussion on priority for Danube (I assume I will introduce
> the topic during the TSC meeting today see attached "Building a TSC vision
> for Danube" deck )
>
> I also created some slides to illustrate what we have discussed in
> Barcelona on the some aggregation actions to provide a consistent Testing
> reporting view as well as web pages to allow scenario owner/user to select
> their list of cases among all the test cases...
>
> I can present it but I have a constraints at 8h25 so I may not be able to
> attend all the meeting
>
> Suggested agenda (do not hesitate to amend it on the wiki...)
>
>- Testing community Danube release landing page + scenario selection
>proposals(15')
>- Test community common goals (20')
>https://etherpad.opnfv.org/p/TestCommunityGoals
>- QTIP presentation (15')
>- AoB (5')
>
> /Morgan
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
___
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] testing meeting APAC slot

[Yujun Zhang]

Yes, it should be Dec 14 according to the rule we set.

Most time it is the second meeting of each month, but in Dec, the third. So
I was afraid some people may not notice the tiny difference.

Anyway, let's discuss it in tomorrow's meeting.
--
Yujun

On Tue, Nov 8, 2016 at 6:26 PM  wrote:

> Hi
>
> no problem, I put Bottleneck update instead
>
> regarding the meeting, let' discuss 5 minutes tomorrow.
> I do not know if the second meeting of the month would be easier than the
> rule the second wednesday of the month.
> so for me in December the APAC slot should be the 14th of December (not
> the 1st of December...)
>
> Maybe an alignment on the day (always Thursday) would also a good idea...
>
> /Morgan
>
>
> Le 08/11/2016 à 10:23, Yujun Zhang a écrit :
>
> Hi, all
>
> Thank Morgan for bringing QTIP to the agenda.
>
> May I propose to postpone it to next week? I haven't get the presentation
> ready yet :-(. It is too hurry for tomorrow.
>
> About the APAC slot, it is even more confusing for Dec because Dec 1st is
> Thursday.
>
> How about modifying the rule as *2nd meeting* of each month for APAC
> meeting. What do you think?
> --
> Yujun
>
> On Tue, Nov 8, 2016 at 5:14 PM  wrote:
>
> Hi
>
> the next weekly meeting APAC slot is not clear. We indicate 2 dates in the
> wiki: https://wiki.opnfv.org/display/meetings/TestPerf
>
> According to the calendar it is on the 9th but the agenda is declared for
> the 10th...
>
> I assume it is the 9 8UTC => I modified the wiki
>
> if so for the moment we do not have chair/minutes and the agenda is
> limited to the discussion on priority for Danube (I assume I will introduce
> the topic during the TSC meeting today see attached "Building a TSC vision
> for Danube" deck )
>
> I also created some slides to illustrate what we have discussed in
> Barcelona on the some aggregation actions to provide a consistent Testing
> reporting view as well as web pages to allow scenario owner/user to select
> their list of cases among all the test cases...
>
> I can present it but I have a constraints at 8h25 so I may not be able to
> attend all the meeting
>
> Suggested agenda (do not hesitate to amend it on the wiki...)
>
>- Testing community Danube release landing page + scenario selection
>proposals(15')
>- Test community common goals (20')
>https://etherpad.opnfv.org/p/TestCommunityGoals
>- QTIP presentation (15')
>- AoB (5')
>
> /Morgan
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
>
> --
> Morgan Richomme
> Orange/ IMT/ OLN/ CNC/ NCA/ SINA
>
> Network architect for innovative services
> Future of the Network community member
> Open source Orange community manager
>
>
> tel. +33 (0) 296 072 106
> mob. +33 (0) 637 753 326morgan.richo...@orange.com
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [doctor] performance profile design spec

[Yujun Zhang]

Hi, doctors,

Would you spare sometime to review the spec for performance profile[1]?

The motivation for this feature is described in JIRA: DOCTOR-72 [2]

Please feel free to give comments.

[1]: https://gerrit.opnfv.org/gerrit/#/c/23963/
[2]: https://jira.opnfv.org/browse/DOCTOR-72
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [opnfvdocs] documentation landing page

[Yujun Zhang]

Folks,

@Morgan mentioned a landing page for test results during yesterdays weekly
meeting. I wonder if there is any similar plan for documentation.

Currently the published documents are available on artifacts site. But it
seems there is no landing page giving an table of all available contents
and we lack a friendly navigation page.

I think it would be nice to have one like http://docs.openstack.org/

What do you think?
--
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] Attention required for project folder structure

[Yujun Zhang]

Dear qtip runners,

We planned a folder reorganization[1] in this sprint. And it is quite
important to complete it ASAP so other tasks won't get blocked.

So I propose to merge a patch set[2] to setup the base folder structure.

The existing features might get broken. But I believe it will be easier to
fix them with the target structure in place.

What do you think? Please reply before tomorrow. Thank you.

[1] https://jira.opnfv.org/browse/QTIP-131
[2] https://gerrit.opnfv.org/gerrit/#/c/24133/
___
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 meeting pages - info on updates

[Yujun Zhang]

Looks good.

But I doubt there is usually another copy of meeting information under each
project so the index is likely out of sync.

Secondly, it is easy to search for one dedicated meeting in this page, but
hard to find out an available time slot for new meetings. In this case, I
would prefer the meetings sorted by starting time. Searching for a project
is not too difficult in a browser.

What do you think?
--
Yujun

On Thu, Nov 10, 2016 at 5:47 PM Christopher Price 
wrote:

> Hi All,
>
>
>
> I spent a little time this morning touching up the meeting wiki page
> because I find it increasingly difficult to run my eyes over it and know
> what is going on.  J
>
>
>
> I have ordered things by three areas:
>
> Community meetings
> 
>
> Working group meetings
> 
>
> Project Meetings
> 
>
>
>
> The sub-bullets are then in alphabetical order (aside from the community
> meetings which I put in a randomly adjudged order or precedence) so if you
> are looking for a project meeting you can run down the list until you find
> it.
>
> It would be great if we could keep this structure (or an improved one) so
> that this stays relatively well tended.
>
>
>
> / Chris
>
>
>
>
>
>
>
>
> ___
> 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] Agenda of Weekly Meeting on 2016-11-14

[Yujun Zhang]

https://etherpad.opnfv.org/p/qtip-meetings-2016-11-14

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

   - #open @zhihui to do some research on dovetail on how to consume test
   data from YardStick next week

Topics

   - sprint QTIP-D2 retrospective


   - What worked well for us?


   - What did not work well for us?


   - What actions can we take to improve our process going forward?


   - sprint QTIP-D3 planning


   - intern program


   - project proposal suitable for 3 month full time or 6 month half time
   work


   - interview and decision process


   - #info Test Landing Page https://goo.gl/OwSWgf


   - #info Goals & vision for the Danube release (draft)
   https://goo.gl/LmIA6V


   - #info POSCA in Bottlenecks D Release https://goo.gl/yddgYR


   - 

Recurring

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


   - recent updates 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] sprint QTIP-D2 update and QTIP-D3 proposal

[Yujun Zhang]

QTIP contributors,

Would you please update the status of JIRA tickets in current sprint[1]? It
is supposed to be completed last Friday.

To get the sprint cycle synchronized with weekly meeting, I would propose
we delay QTIP-D2 to end of today and QTIP-D3 will be started tomorrow.

Please also join the team to propose tasks for next sprint. Thanks.

[1]:
https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=135&projectKey=QTIP
--
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] QTIP-D2 sprint report

[Yujun Zhang]

Hi all qtip runners

QTIP-D2 is completed with 6 out of 8 tasks done.

Thanks to everyone's contribution we are one or two steps closer to our
release target

   - finished directory reorganization
   - setup script for installation with pip

See sprint report[1] for details and participate in the retrospective[2] so
we can improve next sprint.

[1]:
https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=135&view=reporting&chart=sprintRetrospective&sprint=175

[2]: https://wiki.opnfv.org/display/qtip/QTIP-D2
___
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-D3 started

[Yujun Zhang]

QTIP runners,

Sprint QTIP-D3 is kicked off today. It will last for 15 working days. We
shall focus on

   - architecture design
   - yardstick integration
   - compute QPI
   - internship program

Please feel free to claim the tasks in current sprint[1]. Thank you.

[1]:
https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=135&projectKey=QTIP
___
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] candidate of report content

[Yujun Zhang]

Is it a log message or final report for end user?

If it is targeting end user, a user friendly name for test cases might be
prefered, e.g. aggregating the result, short name.

- [2/3] objective
  - [pass] bulk create delete network
  - [fail] bulk create delete port
  - [pass] bulk create delete subnet

My two cents
--
Yujun

On Tue, Nov 15, 2016 at 4:34 PM Leo Wang  wrote:

> Hi all
>
> With the project moving on, the report of dovetail  also needs to evolve
> with more information to present the status of the test.
>
> Here is a candidate report style:
>
> 
>
> Compliance Report
>
> Version: 1.0
> TestSuite: basic
> Certify ID: 9b2a4144-21f8-7c2a-987b-8f2c125c2df2
> Create Date: 2016-11-01 20:17:21 UTC
> Upload Date: 2016-11-01 20:27:21 UTC
> Duration: 514 seconds
>
> Status:
> Pass Rate: 0% (0/1)   *#passed tests/ total tests*
> Compliance : NO*#final result of this compliance*
>
> Overview:
> dovetail.ipv6.tc001(2/3)* # passed sub tests/ total sub tests*
> -objective: VIM ipv6 operations, to create/delete network, port and subnet
> - -
> tempest.api.network.test_networks.BulkNetworkOpsIpV6Test.test_bulk_create_delete_network
> pass
> - -
> tempest.api.network.test_networks.BulkNetworkOpsIpV6Test.test_bulk_create_delete_port
> fail
> - -
> tempest.api.network.test_networks.BulkNetworkOpsIpV6Test.test_bulk_create_delete_subnet
> pass
>
>
>
> Welcome to share your ideas within the mailing list or the wiki page
> https://wiki.opnfv.org/pages/editpage.action?pageId=8685074
>
> 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

Re: [opnfv-tech-discuss] [dovetail] candidate of report content

[Yujun Zhang]

On Wed, Nov 16, 2016 at 10:27 AM Leo Wang  wrote:

> Hi Yujun, Chris
>
> I suggest that add a segment for each test case in their definition
> scripts to explicitly tell this info
> then the tool can generate the report in a general way
>
+1 for auto generation from test case description
___
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] candidate of report content

[Yujun Zhang]

On Wed, Nov 16, 2016 at 10:27 AM Leo Wang  wrote:

> Hi Yujun, Chris
>
> I suggest that add a segment for each test case in their definition
> scripts to explicitly tell this info
> then the tool can generate the report in a general way
>

+1 for auto generation from test case description
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] 答复: [fuel][CI]Fuel deployment CI job is failed on ZTE PODs

[Yujun Zhang]

It seems the target site is forcing a redirection to https.

-L will work.

An alternative solution is downloading from the target link, i.e.
https://build.opnfv.org/artifacts.opnfv.org/fuel/latest.properties


On Wed, Nov 16, 2016 at 3:00 PM  wrote:

> I think I find the reason.
> ZTE PODs use URL
> http://build.opnfv.org/artifacts.opnfv.org/fuel/latest.properties to
> fetch latest.properties and ISO file. If use curl to download via this url,
> it should add parameter -L.
> And It doesn't affect PODs which use url
> http://artifacts.opnfv.org/fuel/latest.properties
>
> [opnfvjenkins@server28 ~]$ curl -s -o latest.properties
> http://build.opnfv.org/artifacts.opnfv.org/fuel/latest.properties
> [opnfvjenkins@server28 ~]$ cat latest.properties
> 
> 301 Moved Permanently
> 
> 301 Moved Permanently
> nginx/1.10.2
> 
> 
> [opnfvjenkins@server28 ~]$ curl -L -s -o latest.properties
> http://build.opnfv.org/artifacts.opnfv.org/fuel/latest.properties
> [opnfvjenkins@server28 ~]$ cat latest.properties
> OPNFV_ARTIFACT_VERSION=2016-11-16_04-00-10
> OPNFV_GIT_URL=https://gerrit.opnfv.org/gerrit/fuel
> OPNFV_GIT_SHA1=d4b0f79649da3ad7a3f3f59d3b92ea230f5b1826
> OPNFV_ARTIFACT_URL=artifacts.opnfv.org/fuel/opnfv-2016-11-16_04-00-10.iso
>
> OPNFV_ARTIFACT_SHA512SUM=0db27bdd560b58d7c412f3cea10047e7496bbdf2e3be9d1c3c9be0b6438a8c4be7053cf899f54e85cf86d07fce8e9118d460f6f52aa22100fc5983402ba1e20c
> OPNFV_BUILD_URL=
> https://build.opnfv.org/ci/job/fuel-build-daily-master/1301/
> [opnfvjenkins@server28 ~]$
>
>
>
> Br,
> Zhihui
>
> *吴之惠   WuZhihui*
>
> 软件测试工程师   Software Test Engineer
> 虚拟化开发七部 / 无线产品经营部VI Development Dept.VII/ Wireless Product Operation
>
>
>
> 上海市浦东新区碧波路889号/上研D座2楼
> 2/D, Shanghai R&D Building, ZTE Corporation
> 889# Bibo Rd, Pudong New District,Shanghai, P.R.China, 201203
> T: +86 021 68896651 <021%206889%206651>M: +86 18121012137
> <181%202101%202137>
> E:Wu.zhihui1 @zte.com.cn
> *www.zte.com.cn* 
>
>
>
>
> *吴之惠098564/user/zte_ltd*
>
> 2016/11/15 11:16
>
> 收件人
> "opnfv-tech-discuss@lists.opnfv.org" ,
>
>
> 抄送
> 主题
> [opnfv-tech-discuss][fuel][CI]Fuel deployment CI job is failed on ZTE PODs
>
>
>
> Hi Fuel team，
>
> Fuel deployment CI job is failed on ZTE PODs. See
> https://build.opnfv.org/ci/job/fuel-deploy-zte-pod1-daily-master/lastBuild/console
>
> [fuel-deploy-zte-pod1-daily-master] $ /bin/bash
> /tmp/hudson6589147116698030944.sh
> Downloading
> *http://build.opnfv.org/artifacts.opnfv.org/fuel/latest.properties*
> 
>
> latest.properties: line 1: html: No such file or directory
> Build step 'Execute shell' marked build as failure
>
> It cause by the path of file "latest.properties". According to
> fuel-download-artifact.sh， latest.properties is downloaded to $WORKSPACE. I
> check the file exists in $WORKSPACE.
> But why check and source latest.properties without path $WORKSPACE?
> And I am curious that this error seems only happen on ZTE PODs. Any idea
> about this problem? Thanks in advance.
>
> Br,
> Zhihui
>
>
>
> *吴之惠   WuZhihui*
> 软件测试工程师   Software Test Engineer
> 虚拟化开发七部 / 无线产品经营部VI Development Dept.VII/ Wireless Product Operation
>
>
>
> 上海市浦东新区碧波路889号/上研D座2楼
> 2/D, Shanghai R&D Building, ZTE Corporation
> 889# Bibo Rd, Pudong New District,Shanghai, P.R.China, 201203
> T: +86 021 68896651 <021%206889%206651>M: +86 18121012137
> <181%202101%202137>
> E:Wu.zhihui1 @zte.com.cn
> *www.zte.com.cn* 
>
>
>
> ___
> 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] [doctor] question on code refactoring task (DOCTOR-71)

[Yujun Zhang]

Hi, doctors,

Carlos has started code refactoring of the test script[1]. It looks good to
separate common function and installer specific function into different
modules and improve the readability of main script.[2][3]

I just have some concerns about the future complexibility of this test
script. We are going to handle a multidimensional matrix of test condition,
i.e. N installers * M inspectors * K notifiers * ... I'm not sure shell
script can handle it well and provide a user friendly way for debugging,
profiling[4] and reporting.

No intention to start another war between programming languages. But this
is something we need to consider before going deep in code refactoring.

[1]: https://jira.opnfv.org/browse/DOCTOR-71
[2]: https://gerrit.opnfv.org/gerrit/#/c/24395/
[3]: https://gerrit.opnfv.org/gerrit/#/c/24399/
[4]: https://jira.opnfv.org/browse/DOCTOR-72
___
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] question on code refactoring task (DOCTOR-71)

[Yujun Zhang]

Wenjuan,

A README for the overview of your design would help reviewers to understand
the huge chunk of code.


On Thu, Nov 17, 2016 at 12:33 PM  wrote:

>
> Hi All,
>
> I agree that we should discuess more about how to refactor the test script
> to let it become more modular, readable and maintainable.
> The programming languages is the first step.
>
>
> I propsed a framwork about the refactor the test script[1].
> This is my init ideal, any comments are welcome. :)
>
> [1]*https://github.com/openzero-zte/doctor_test_refactor
> <https://github.com/openzero-zte/doctor_test_refactor>*
>
> BR.
> dwl
>
>
>
>
> *Yujun Zhang >*
> 发件人:  opnfv-tech-discuss-boun...@lists.opnfv.org
>
> 2016-11-17 09:48
>
> 收件人
> TECH-DISCUSS OPNFV 
>
> 抄送
> 主题
> [opnfv-tech-discuss] [doctor] question on code refactoring task
>  (DOCTOR-71)
>
>
>
>
> Hi, doctors,
>
> Carlos has started code refactoring of the test script[1]. It looks good
> to separate common function and installer specific function into different
> modules and improve the readability of main script.[2][3]
>
> I just have some concerns about the future complexibility of this test
> script. We are going to handle a multidimensional matrix of test condition,
> i.e. N installers * M inspectors * K notifiers * ... I'm not sure shell
> script can handle it well and provide a user friendly way for debugging,
> profiling[4] and reporting.
>
> No intention to start another war between programming languages. But this
> is something we need to consider before going deep in code refactoring.
>
> [1]: *https://jira.opnfv.org/browse/DOCTOR-71*
> <https://jira.opnfv.org/browse/DOCTOR-71>
> [2]: *https://gerrit.opnfv.org/gerrit/#/c/24395/*
> <https://gerrit.opnfv.org/gerrit/#/c/24395/>
> [3]: *https://gerrit.opnfv.org/gerrit/#/c/24399/*
> <https://gerrit.opnfv.org/gerrit/#/c/24399/>
> [4]: *https://jira.opnfv.org/browse/DOCTOR-72*
> <https://jira.opnfv.org/browse/DOCTOR-72>
> ___
> 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] Agenda for weekly meeting 2016-11-21

[Yujun Zhang]

https://etherpad.opnfv.org/p/qtip-meetings-2016-11-21

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

   - @zhihui to do some research on dovetail on how to consume test data
   from YardStick this week


   - @SerenaFeng to provide yujunz some detail about internship program
   after talking to her student

Topics

   - internship program proposals


   - https://wiki.opnfv.org/display/qtip/Intern+Projects


   - https://wiki.opnfv.org/display/DEV/Intern-projects-page

Recurring

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


   - recent updates 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] 答复: [doctor] question on code refactoring task (DOCTOR-71)

[Yujun Zhang]

In fact, the error starts with Wenjuan's reply :-)

Could you check @wenjuan?

On Tue, Nov 22, 2016 at 10:50 PM Carlos Goncalves <
carlos.goncal...@neclab.eu> wrote:

> It seems like when I replied to Yujun’s emails I sent to the
> opnfv-tech-discuss-bounces address.
>
> Please see below my reply.
>
>
>
> Carlos
>
...

>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [
> mailto:opnfv-tech-discuss-boun...@lists.opnfv.org
> ] *On Behalf Of *
> dong.wenj...@zte.com.cn
>
>
> *Sent:* 17 November 2016 05:34
> *To:* Yujun Zhang
> *Cc:* opnfv-tech-discuss-boun...@lists.opnfv.org; TECH-DISCUSS OPNFV
>
> *Subject:* [opnfv-tech-discuss] 答复: [doctor] question on code refactoring
> task (DOCTOR-71)
>
>
>
>
> Hi All,
>
> I agree that we should discuess more about how to refactor the test script
> to let it become more modular, readable and maintainable.
> The programming languages is the first step.
>
>
> I propsed a framwork about the refactor the test script[1].
> This is my init ideal, any comments are welcome. :)
>
> [1]*https://github.com/openzero-zte/doctor_test_refactor
> <https://github.com/openzero-zte/doctor_test_refactor>*
>
> BR.
> dwl
>
>
> *Yujun Zhang >*
> 发件人:  opnfv-tech-discuss-boun...@lists.opnfv.org
>
> 2016-11-17 09:48
>
> 收件人
>
> TECH-DISCUSS OPNFV 
>
> 抄送
>
> 主题
>
> [opnfv-tech-discuss] [doctor] question on code refactoring task
>  (DOCTOR-71)
>
>
>
>
>
>
> Hi, doctors,
>
> Carlos has started code refactoring of the test script[1]. It looks good
> to separate common function and installer specific function into different
> modules and improve the readability of main script.[2][3]
>
> I just have some concerns about the future complexibility of this test
> script. We are going to handle a multidimensional matrix of test condition,
> i.e. N installers * M inspectors * K notifiers * ... I'm not sure shell
> script can handle it well and provide a user friendly way for debugging,
> profiling[4] and reporting.
>
> No intention to start another war between programming languages. But this
> is something we need to consider before going deep in code refactoring.
>
> [1]: https://jira.opnfv.org/browse/DOCTOR-71
> [2]: https://gerrit.opnfv.org/gerrit/#/c/24395/
> [3]: https://gerrit.opnfv.org/gerrit/#/c/24399/
> [4]: https://jira.opnfv.org/browse/DOCTOR-72
> ___
> 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] [doctor] Danube plan overview

[Yujun Zhang]

Hi doctors,

I'm reviewing the requirement document for an internal presentation. There
is a release plan for Arno and it looks good[1].

We have already sorted out the working items for Danube release, but it
would be better if we can have an overview about the goals we want to
achieve.

@Ryota, what do you think?

[1]:
http://artifacts.opnfv.org/doctor/docs/requirements/index.html#implementation-plan-for-opnfv-release-1

[2]: https://wiki.opnfv.org/display/doctor/Danube+Planning
___
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 2016-11-21

[Yujun Zhang]

Hi, Wenjing

Thank you for bringing QTIP project to OPNFV and all the contribution you
have done for the project.

Wish you a good success in the new sailing in Danube!
--
Yujun

On Thu, Nov 24, 2016 at 3:07 AM Wenjing Chu  wrote:

> Hi Yujun
>
> I’m glad to see qtip developing into an important part of testing
> capabilities in OPNFV. As you can see, I find myself unable to find time to
> contribute anymore, so please take me off as a committer in qtip.
>
> I want to take this opportunity to thank you and everyone in the project –
> from one of the original qtip committers. Cheers to you.
>
>
>
> Wenjing
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Yujun Zhang
> *Sent:* Thursday, November 17, 2016 10:18 PM
> *To:* TECH-DISCUSS OPNFV 
> *Subject:* [opnfv-tech-discuss] [qtip] Agenda for weekly meeting
> 2016-11-21
>
>
>
> https://etherpad.opnfv.org/p/qtip-meetings-2016-11-21
>
>
> QTIP project weekly meeting on 2016-11-21
>
> time: UTC0800
>
> irc://#opnfv-qtip@freenode
>
> index: https://etherpad.opnfv.org/p/qtip-meetings
> Action followup
>
> ·@zhihui to do some research on dovetail on how to consume test
> data from YardStick this week
>
> ·@SerenaFeng to provide yujunz some detail about internship
> program after talking to her student
> Topics
>
> ·internship program proposals
>
>- https://wiki.opnfv.org/display/qtip/Intern+Projects
>
>
>- https://wiki.opnfv.org/display/DEV/Intern-projects-page
>
> Recurring
>
> ·active sprint followup
> https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP&rapidView=135
>
> ·recent updates 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 weekly meeting

[Yujun Zhang]

https://etherpad.opnfv.org/p/qtip-meetings-2016-11-28

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

   - @all send @yujunz google account for document sharing and review

Topics

   - project update


   - contact page: https://wiki.opnfv.org/display/qtip/Contacts restricted
   access to qtip-contributors


   - documents sharing on google drive


   - active reviewers group: qtip-reviewers on gerrit


   - committer retirement: Wenjing CHU


   - new contributor: Akhil Batra


   - scheduled downtime of AWS instance UTC1600-2400 every day to save 1/3
   cost


   - server names


   - dev => desk


   - test => table

Recurring

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


   - recent updates 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] ##freemail## [doctor] Danube plan overview

[Yujun Zhang]

I see. Thanks for clarification.

On Fri, Nov 25, 2016 at 12:37 AM Ryota Mibu  wrote:

> Yujun,
>
>
> Well, we don't have much new features in Danube. We need documentation and
> testing improvements in Danube. Those are not easy to be mapped in an
> overview picture.
>
> We wrote down the release plan while we didn't have JIRA and guidelines at
> the early stage of OPNFV. The original plan and figure could be kept, but I
> prefer to update that part with what we requires currently and move the
> overview of old releases into an appendix for archive.
>
>
> BR,
> Ryota
>
> > -Original Message-
> > From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> > Sent: Wednesday, November 23, 2016 3:59 PM
> > To: TECH-DISCUSS OPNFV 
> > Cc: Mibu Ryota(壬生 亮太) 
> > Subject: ##freemail## [doctor] Danube plan overview
> >
> > Hi doctors,
> >
> > I'm reviewing the requirement document for an internal presentation.
> There is a release plan for Arno and it looks
> > good[1].
> >
> > We have already sorted out the working items for Danube release, but it
> would be better if we can have an overview
> > about the goals we want to achieve.
> >
> > @Ryota, what do you think?
> >
> > [1]:
> http://artifacts.opnfv.org/doctor/docs/requirements/index.html#implementation-plan-for-opnfv-release-1
> > [2]: https://wiki.opnfv.org/display/doctor/Danube+Planning
>
___
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

[Yujun Zhang]

Postponed to this Wednesday 16:00, Nov 30th.

Sorry for late notification.
--
Yujun

On Fri, Nov 25, 2016 at 2:06 PM Yujun Zhang 
wrote:

> https://etherpad.opnfv.org/p/qtip-meetings-2016-11-28
>
> QTIP project weekly meeting on 2016-11-28
> time: UTC0800
> irc://#opnfv-qtip@freenode
> index: https://etherpad.opnfv.org/p/qtip-meetings
> Action followup
>
>- @all send @yujunz google account for document sharing and review
>
> Topics
>
>- project update
>
>
>- contact page: https://wiki.opnfv.org/display/qtip/Contacts restricted
>access to qtip-contributors
>
>
>- documents sharing on google drive
>
>
>- active reviewers group: qtip-reviewers on gerrit
>
>
>- committer retirement: Wenjing CHU
>
>
>- new contributor: Akhil Batra
>
>
>- scheduled downtime of AWS instance UTC1600-2400 every day to save
>1/3 cost
>
>
>- server names
>
>
>- dev => desk
>
>
>- test => table
>
> Recurring
>
>- active sprint followup
>https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP&rapidView=135
>
>
>- recent updates 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 weekly meeting 2016-11-30

[Yujun Zhang]

Deferred from 11-28

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

   - @all send @yujunz google account for document sharing and review

Topics

   - project update


   - contact page: https://wiki.opnfv.org/display/qtip/Contacts restricted
   access to qtip-contributors


   - documents sharing on google drive https://goo.gl/ydB2aj


   - active reviewers group: qtip-reviewers on gerrit


   - committer retirement: Wenjing CHU


   - new contributor: Akhil Batra


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


   - scheduled downtime of AWS instance UTC1600-2400 every day to save 1/3
   cost


   - server names


   - dev => desk


   - test => table

Recurring

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


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


   - recent updates 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] [infra] "gate" job BEFORE merging

[Yujun Zhang]

During the code refactoring in QTIP project, I found it easily to get
things broken[1]. And it can only be detected during the daily integration
AFTER merge.

Is it possible that we have a gate job to detect such failure before a
patchset get merged?

I remember it may have been discussed before. Could anybody remind me of
the outcome?

[1]
https://build.opnfv.org/ci/view/qtip/job/qtip-fuel-zte-pod3-daily-master/lastFailedBuild/
___
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] "gate" job BEFORE merging

[Yujun Zhang]

Hi, Fatih

The verify job works well for each commit.

But when there are several commits in parallel, the one get verified seems
not identical to the one after merge. For example,

 A
 +---+
 |   |
 B   C
 +   +
 |   |
 +---+
 D

1. Both patch B and patch C are submit for review and passed verification
job.
2. Patch B is merged, everything is fine.
3. When merging patch C, a merge commit D will be created by CI. Will it
get verified?


On Wed, Nov 30, 2016 at 3:15 PM Fatih Degirmenci <
fatih.degirme...@ericsson.com> wrote:

> Hi,
>
> The purpose of verify jobs is this. Qtip has it so you need to decide what
> other checks you want to have and adjust the job accordingly.
>
> https://build.opnfv.org/ci/view/qtip/job/qtip-verify-master/616/console
>
> /Fatih
>
> On 30 Nov 2016, at 04:36, Yujun Zhang  wrote:
>
> During the code refactoring in QTIP project, I found it easily to get
> things broken[1]. And it can only be detected during the daily integration
> AFTER merge.
>
> Is it possible that we have a gate job to detect such failure before a
> patchset get merged?
>
> I remember it may have been discussed before. Could anybody remind me of
> the outcome?
>
> [1]
> https://build.opnfv.org/ci/view/qtip/job/qtip-fuel-zte-pod3-daily-master/lastFailedBuild/
>
> ___
> 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] [infra] "gate" job BEFORE merging

[Yujun Zhang]

My previous reply is a bit deviated from original question.

The problem was when a bunch of patchsets get merged in a day and then we
find the daily integration job fails on the next day.

Is there a way to find out quickly which commit breaks the build?


On Wed, Nov 30, 2016 at 3:28 PM Yujun Zhang 
wrote:

> Hi, Fatih
>
> The verify job works well for each commit.
>
> But when there are several commits in parallel, the one get verified seems
> not identical to the one after merge. For example,
>
>  A
>  +---+
>  |   |
>  B   C
>  +   +
>  |   |
>  +---+
>  D
>
> 1. Both patch B and patch C are submit for review and passed verification
> job.
> 2. Patch B is merged, everything is fine.
> 3. When merging patch C, a merge commit D will be created by CI. Will it
> get verified?
>
>
> On Wed, Nov 30, 2016 at 3:15 PM Fatih Degirmenci <
> fatih.degirme...@ericsson.com> wrote:
>
> Hi,
>
> The purpose of verify jobs is this. Qtip has it so you need to decide what
> other checks you want to have and adjust the job accordingly.
>
> https://build.opnfv.org/ci/view/qtip/job/qtip-verify-master/616/console
>
> /Fatih
>
> On 30 Nov 2016, at 04:36, Yujun Zhang  wrote:
>
> During the code refactoring in QTIP project, I found it easily to get
> things broken[1]. And it can only be detected during the daily integration
> AFTER merge.
>
> Is it possible that we have a gate job to detect such failure before a
> patchset get merged?
>
> I remember it may have been discussed before. Could anybody remind me of
> the outcome?
>
> [1]
> https://build.opnfv.org/ci/view/qtip/job/qtip-fuel-zte-pod3-daily-master/lastFailedBuild/
>
> ___
> 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] [infra] "gate" job BEFORE merging

[Yujun Zhang]

Thanks for the information. Looking forward to the evolution of CI infra.

On Wed, Nov 30, 2016 at 3:59 PM Fatih Degirmenci <
fatih.degirme...@ericsson.com> wrote:

> Hi,
>
> What we have as verify jobs corresponds to what openstack calls check and
> these are not enough to gate commits as you experienced.
>
> If we had zuul, we could have gate jobs using dependent pipeline. [1]
> Until we get zuul, my suggestion to you is to rebase changes before
> submitting them to ensure you rerun verify jobs for the pending change
> against the latest master. But you might find yourself in same situation
> over and over again if heavy development is going on within the project and
> master is in constant move.
>
> Finding problematic commits is manual work if they slip through. You need
> to check the delta between the latest successful run and failed one.
>
> I'm aware that this is probably not the answer you're looking for but this
> is what we have with the current tooling. I hope openstack releases stable
> zuul v3 soon so we try it out.
>
> [1] http://docs.openstack.org/infra/zuul/gating.html#dependent-pipeline
>
> /Fatih
>
> On 30 Nov 2016, at 08:41, Yujun Zhang  wrote:
>
> My previous reply is a bit deviated from original question.
>
> The problem was when a bunch of patchsets get merged in a day and then we
> find the daily integration job fails on the next day.
>
> Is there a way to find out quickly which commit breaks the build?
>
>
> On Wed, Nov 30, 2016 at 3:28 PM Yujun Zhang 
> wrote:
>
> Hi, Fatih
>
> The verify job works well for each commit.
>
> But when there are several commits in parallel, the one get verified seems
> not identical to the one after merge. For example,
>
>  A
>  +---+
>  |   |
>  B   C
>  +   +
>  |   |
>  +---+
>  D
>
> 1. Both patch B and patch C are submit for review and passed verification
> job.
> 2. Patch B is merged, everything is fine.
> 3. When merging patch C, a merge commit D will be created by CI. Will it
> get verified?
>
>
> On Wed, Nov 30, 2016 at 3:15 PM Fatih Degirmenci <
> fatih.degirme...@ericsson.com> wrote:
>
> Hi,
>
> The purpose of verify jobs is this. Qtip has it so you need to decide what
> other checks you want to have and adjust the job accordingly.
>
> https://build.opnfv.org/ci/view/qtip/job/qtip-verify-master/616/console
>
> /Fatih
>
> On 30 Nov 2016, at 04:36, Yujun Zhang  wrote:
>
> During the code refactoring in QTIP project, I found it easily to get
> things broken[1]. And it can only be detected during the daily integration
> AFTER merge.
>
> Is it possible that we have a gate job to detect such failure before a
> patchset get merged?
>
> I remember it may have been discussed before. Could anybody remind me of
> the outcome?
>
> [1]
> https://build.opnfv.org/ci/view/qtip/job/qtip-fuel-zte-pod3-daily-master/lastFailedBuild/
>
> ___
> 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] Agenda for weekly meeting 2016-12-05

[Yujun Zhang]

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

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

   - #done yujunz fix permission issues of contact page


   - shared in https://goo.gl/aGJN5n


   - zhihui clean up deprecated CI jobs

Topics

   - Call for internship mentor


   - dashboard design and implementation


   - api server design and implementation


   - Sprint QTIP-D3 restropective


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


   - Sprint QTIP-D4 planning


   - #info Test documentation
   https://lists.opnfv.org/pipermail/test-wg/2016-December/26.html

Recurring

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


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


   - recent updates 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] [doctor] doctor CI now available

[Yujun Zhang]

Nice job!

One comment inline.

On Sun, Dec 4, 2016 at 3:55 PM Ryota Mibu  wrote:

> Hi,
>
>
> Doctor CI jobs are now available and I confirmed those returns green
> lights with current codes on the master branch.
>
> Reviewers, please check the CI results before merging a patch set.


So the verification job is not voting? Why not?


> If the CI jobs were run before Dec 2nd, just trigger CI jobs again by
> leaving comment "recheck".
>
>doctor-verify-apex-sample-master
>doctor-verify-apex-congress-master
>
> Note: congress works fine, with some quick hack on the POD after I
> installed OPNFV with latest apex. I'll work with apex team to fix issues I
> found.
>
> Let me know if you find any problems in those CI jobs.
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [doctor] performance profiler

[Yujun Zhang]

Doctors,

Please find the slides[1] for the background of performance profiler[2] as
requested in gerrit review[3] and last meeting[4].

Feel free to give comments.

[1]: https://goo.gl/98Osig
[2]: https://jira.opnfv.org/browse/DOCTOR-72
[3]: https://gerrit.opnfv.org/gerrit/#/c/25081/
[4]:
http://meetbot.opnfv.org/meetings/opnfv-doctor/2016/opnfv-doctor.2016-11-29-14.01.html
___
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 Report QTIP-D3

[Yujun Zhang]

Thanks to all contributors' effort, we accomplished many goals in this
sprint

1. kicked off the first internship program in QTIP
2. completed the compute QPI design specification
3. resumed verification job is after framework refactoring

Though there is some delay on YardStick integration spec and architecture
design, we can still announce proudly that

QTIP-D3 is completed

*4* issues were Done.
*4* incomplete issues will be returned to the top of the backlog.
*2* partially complete issues will be returned to the top of the backlog.

Please check the full report[1] and join the retrospectivity[2]

[1]:
https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=135&view=reporting&chart=sprintRetrospective&sprint=187

[2]: https://wiki.opnfv.org/display/qtip/QTIP-D3

--

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] Sprint QTIP-D4 started

[Yujun Zhang]

QTIP runners,

Ready for the fourth sprint in Danube? Let's go!

In this sprint, we shall focus on

1. YardStick integration
2. CLI evolution (intern project)
3. Runner module refactoring

Check the active sprint page[1] for details

[1]: https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=135
___
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] doctor CI now available

[Yujun Zhang]

Is this verification job locked to a speciific POD or runnable in all CI
PODs deployed by APEX?

On Tue, Dec 6, 2016 at 7:13 PM Ryota Mibu  wrote:

> Hi,
>
>
>
> Let me explain current status in today’s meeting.
>
>
>
>
>
> BR,
>
> Ryota
>
>
>
> *From:* Carlos Goncalves [mailto:carlos.goncal...@neclab.eu]
> *Sent:* Monday, December 05, 2016 11:52 AM
> *To:* Yujun Zhang ; Mibu Ryota(壬生 亮太) <
> r-m...@cq.jp.nec.com>; opnfv-tech-discuss@lists.opnfv.org
> *Subject:* RE: [opnfv-tech-discuss] [doctor] doctor CI now available
>
>
>
> Yujun, it still cares for further (human) validation before we can make it
> voting – the email I sent earlier shows that it’s not 100% ready yet.
>
>
>
> Carlos
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [
> mailto:opnfv-tech-discuss-boun...@lists.opnfv.org
> ] *On Behalf Of *Yujun Zhang
> *Sent:* 05 December 2016 02:00
> *To:* Ryota Mibu; opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] [doctor] doctor CI now available
>
>
>
> Nice job!
>
>
>
> One comment inline.
>
>
>
> On Sun, Dec 4, 2016 at 3:55 PM Ryota Mibu  wrote:
>
> Hi,
>
>
> Doctor CI jobs are now available and I confirmed those returns green
> lights with current codes on the master branch.
>
> Reviewers, please check the CI results before merging a patch set.
>
>
>
> So the verification job is not voting? Why not?
>
>
>
> If the CI jobs were run before Dec 2nd, just trigger CI jobs again by
> leaving comment "recheck".
>
>doctor-verify-apex-sample-master
>doctor-verify-apex-congress-master
>
> Note: congress works fine, with some quick hack on the POD after I
> installed OPNFV with latest apex. I'll work with apex team to fix issues I
> found.
>
> Let me know if you find any problems in those CI jobs.
>
>
___
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] doctor CI now available

[Yujun Zhang]

On Thu, Dec 8, 2016 at 6:41 AM Ryota Mibu  wrote:

Yujun,



Yes, but I can remove it if some can provide POD(s) for these CI jobs.
Maybe I can put document how to build such pod.


That would be great. Let me see if we can request some resource from ZTE
lab for Doctor CI.
___
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 2016-12-12

[Yujun Zhang]

Please note that the it has been rescheduled to UTC0730 from now on.

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

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

   - all review CLI intern project plan on https://goo.gl/cWf9cR


   - yujunz create a poll for meeting slot with framadate.org or doodle.com

Topics

   - architecture evolution updates

Recurring

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


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


   - recent updates 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][yardstick] co-meeting about integration in Danube

[Yujun Zhang]

Dear testers,

We shall hold a co-meeting between QTIP and Yardstick team to discuss about
the integration of these two projects in Danube release.

Please check the logistical information as below and join us if you are
interested.

See agenda in https://etherpad.opnfv.org/p/qtip-yardstick

Topic: QTIP Yardstick
Time: Dec 14, 2016 UTC0030

IRC: #opnfv-testperf
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/735117661

Or iPhone one-tap (US Toll):  +16465588656,735117661# or
+14086380968,735117661#

Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 735 117 661
International numbers available:
https://zoom.us/zoomconference?m=N6F-LXYeckdL-WYpVcNqK8EDscejOeFL
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Fwd: [qtip][yardstick] co-meeting about integration in Danube

[Yujun Zhang]

*Correction!*

Time: Thursday, Dec 15, 2016 UTC0030

-- Forwarded message -
From: Yujun Zhang 
Date: Tue, Dec 13, 2016 at 9:49 AM
Subject: [qtip][yardstick] co-meeting about integration in Danube
To: TECH-DISCUSS OPNFV , test-wg <
test...@lists.opnfv.org>
Cc: Gaoliang (D) 


Dear testers,

We shall hold a co-meeting between QTIP and Yardstick team to discuss about
the integration of these two projects in Danube release.

Please check the logistical information as below and join us if you are
interested.

See agenda in https://etherpad.opnfv.org/p/qtip-yardstick

Topic: QTIP Yardstick
Time: Dec 14, 2016 UTC0030

IRC: #opnfv-testperf
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/735117661

Or iPhone one-tap (US Toll):  +16465588656 <(646)%20558-8656>,735117661# or
+14086380968 <(408)%20638-0968>,735117661#

Or Telephone:
Dial: +1 646 558 8656 <(646)%20558-8656> (US Toll) or +1 408 638 0968
<(408)%20638-0968> (US Toll)
Meeting ID: 735 117 661
International numbers available:
https://zoom.us/zoomconference?m=N6F-LXYeckdL-WYpVcNqK8EDscejOeFL


qtip-yardstick.ics
Description: application/ics
___
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]

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  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)
> --
> *From:* Raymond Paik [rp...@linuxfoundation.org]
> *Sent:* 14 December 2016 13:33
>
> *To:* joehuang
> *Cc:* opnfv-tech-discuss
> *Subject:* Re: [opnfv-tech-discuss] committer list maintainance
> Joe,
>
> On the first point, I'm not sure why you are saying you need to be
> committer to submit a patch in OPNFV.  There are plenty of regular
> contributors who submit code/patches to OPNFV.  Let me know if I'm not
> understanding your point.
>
> On your second point, I can recall a few committers who voluntarily
> stepped down in the past few of months.  One of them was your Board member
> Wenjing who stepped down as a committer for QTIP.  One of the reasons why
> TSC approval is desired for revoking committer status is to prevent PTLs
> from potentially acting in bad faith.  I don't know if there are any PTLs
> in OPNFV who would act in bad faith, but it's good to have checks &
> balances.  Is it really that difficult to send an email to the TSC mailing
> list and then come to the TSC meeting for 5 minutes to get an approval?
>
> Others in the community are welcome to weigh in on this...
>
> Thanks,
>
> Ray
>
> On Tue, Dec 13, 2016 at 9:10 PM, joehuang  wrote:
>
> Hello, Raymond,
>
> My suggestion is to update the TSC Charter. Compared to OpenStack core
> reviewer/contributor maintenance, often feel that OPNFV governance brings
> lots of inconvenience:
>
> For example, if one wants to submit a patch, he/she usually has to be a
> committer in OPNFV before he submit a patch. But in OpenStack, anyone is
> able to submit a patch, and core reviewers will make sure this patch should
> be approved or not. If one is nominated as committer to be a core reviewer,
> and pass the voting, then any other core reviewer can add the new one to
> core reviewer list, but in OPNFV, you have to submit a patch or ask help
> from help-desk.
>
> And another example, I seldom find that there is a stepping down
> notification in OPNFV mail-list from committer(yes, I saw some PTL stepping
> down notification), it seems not the fashion in OPNFV. But in OpenStack, a
> core reviewer is quite important role in code review, if he is not able to
> do the core reviewer responsibility, he will send a notification to the
> OpenStack mail-list.
>
> I really don't know the reason why when we find some committer is inactive
> in the past 6 months, we need the approve from TSC?
>
> Best Regards
> Chaoyi Huang (joehuang)
> --
> *From:* Raymond Paik [rp...@linuxfoundation.org]
> *Sent:* 14 December 2016 12:43
> *To:* joehuang
> *Cc:* opnfv-tech-discuss
> *Subject:* Re: [opnfv-tech-discuss] committer list maintainance
>
> Joe,
>
> If there's an inactive committer (for more than 6 months) and the PTL is
> not able to reach that committer for whatever reason, the PTL needs to make
> a request to the TSC to revoke the committer status.  The PTL should not do
> this unilaterally.
>
> Please see the 8th paragraph in the Section 8 of the TSC Charter (
> https://www.opnfv.org/developers/technical-project-governance/tsc-charter).
> ..
>
> Thanks,
>
> Ray
>
> On Tue, Dec 13, 2016 at 6:18 PM, joehuang  wrote:
>
> Hello,
>
> In each project's wiki page, we often list committers and contributors, as
> OPNFV's ongoing development, some new committers come, some committers grow
> other interesting and put less focus on the old project.
>
> I have one suggestion for the maintenance on committer list: for those who
> have shifted interest, for example, not shown in the weekly meeting and
> mail-list discussion ( all these could be found in the log) in the past 6
> months, but they forget to send a stepping down notification in the
> mail-list, PTL should be able to move the committer to the contributor list
> by default, and update the list in the git reposi

Re: [opnfv-tech-discuss] Taking Tech Discuss to the Forums

[Yujun Zhang]

It seems this new forum requires new account.

Would it possible to enable single sign on with existing account?

On Wed, Dec 14, 2016 at 4:25 PM Ash  wrote:

> All,
>
> To help make discussions easier between time zones, searchable,linkable,
> etc., we've put up a new Tech Discuss Forum .
> We have our email list. We have our Thursday morning calls with Bin. And
> now we have a forum where you can have threaded conversations on important
> technical subjects.
>
> Currently, we have the following topic under discussion:
>
> 1) Security Scanning in the CI
> 2) We have started an opening thread on the OPNFV Architecture
> 3) We have opened a topic on storage requirements
>
> This is not to replace our Confluence/Wiki. But it's an easier and more
> intuitive interface for conversation than looking at markup language. You
> can post diagrams, code, whatever you want.
>
> If you get tagged on a discussion thread and someone asks a question of
> you, you can even respond via email, if you happen to be mobile.
>
> Anyway, please take note of it and please help with the current
> discussions.
>
> Best,
>
> Ash
> ___
> 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] [doctor] subtasks created for performance profiler

[Yujun Zhang]

Hi, Ryota

I have split the task into several working items in JIRA[1]. Some of them
may not catch up with Danube release as I explained in last meeting [2].

Shall I modify the `Fix Version/s` field now or wait till release window to
update them?

[1]: https://jira.opnfv.org/browse/DOCTOR-72
[2]: https://etherpad.opnfv.org/p/doctor_meetings
___
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] co-meeting about integration in Danube

[Yujun Zhang]

Meeting minutes

http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.html


Meeting summary

   1.
  1.
  
https://gerrit.opnfv.org/gerrit/#/c/25949/1/benchmarks/suite/compute.yaml,unified
   (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-7>,
  00:40:14)
  2. zhihui asks about yardstick output format (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-9>,
  00:45:51)
  3. yujunz introduce how to calculate score in QTIP (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-10>,
  00:46:45)
  4. https://wiki.opnfv.org/display/qtip/Architecture (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-15>,
  00:50:45)
  5. yujunz introduce agent mode (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-17>,
  00:52:39)
  6. QTIP in Danube will focus on compute performance index (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-18>,
  00:53:25)
  7. QTIP request for specific test case for its index calculation (
  yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-19>,
  00:55:22)
  8. https://etherpad.opnfv.org/p/qtip-yardstick (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-54>,
  01:06:17)
  9. ACTION: kubi001 yujunz continue discussion on etherpad (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-56>,
  01:06:42)
  10. ACTION: kubi001 to book another joint meeting next week (yujunz
  
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html#l-57>,
  01:06:56)



Meeting ended at 01:07:11 UTC (full logs
<http://ircbot.wl.linuxfoundation.org/meetings/opnfv-testperf/2016/opnfv-testperf.2016-12-15-00.38.log.html>
).

Action items

   1. kubi001 yujunz continue discussion on etherpad
   2. kubi001 to book another joint meeting next week



Action items, by person

   1. kubi001
  1. kubi001 yujunz continue discussion on etherpad
  2. kubi001 to book another joint meeting next week
   2. yujunz
  1. kubi001 yujunz continue discussion on etherpad



People present (lines said)

   1. yujunz (41)
   2. kubi001 (7)
   3. Mingjiang1 (5)
   4. collabot (4)
   5. zhihui (1)
   6. JackChan (1)


On Tue, Dec 13, 2016 at 9:54 AM Yujun Zhang 
wrote:

> *Correction!*
>
> Time: Thursday, Dec 15, 2016 UTC0030
>
> -- Forwarded message -
> From: Yujun Zhang 
> Date: Tue, Dec 13, 2016 at 9:49 AM
> Subject: [qtip][yardstick] co-meeting about integration in Danube
> To: TECH-DISCUSS OPNFV , test-wg <
> test...@lists.opnfv.org>
> Cc: Gaoliang (D) 
>
>
> Dear testers,
>
> We shall hold a co-meeting between QTIP and Yardstick team to discuss
> about the integration of these two projects in Danube release.
>
> Please check the logistical information as below and join us if you are
> interested.
>
> See agenda in https://etherpad.opnfv.org/p/qtip-yardstick
>
> Topic: QTIP Yardstick
> Time: Dec 14, 2016 UTC0030
>
> IRC: #opnfv-testperf
> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/735117661
>
> Or iPhone one-tap (US Toll):  +16465588656 <(646)%20558-8656>,735117661#
> or +14086380968 <(408)%20638-0968>,735117661#
>
> Or Telephone:
> Dial: +1 646 558 8656 <(646)%20558-8656> (US Toll) or +1 408 638 0968
> <(408)%20638-0968> (US Toll)
> Meeting ID: 735 117 661
> International numbers available:
> https://zoom.us/zoomconference?m=N6F-LXYeckdL-WYpVcNqK8EDscejOeFL
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [all] TestPerf EcoSystem diagram now editable

[Yujun Zhang]

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

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

[Yujun Zhang]

On Thu, Dec 15, 2016 at 9:20 PM Jose Lausuch 
wrote:

> Hi Yujun,
>
>
>
> That looks good. It’s a great idea to have diagrams and pictures editable
> so that we can change it when we see the need.
>
Sure. Manage the images like code.

> Maybe we should apply the same for the other pictures/graphs.
>
Agree. Then it could be done in a collaborative way. Confluence is quite
powerful with plugins.

>
___
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) 于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

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

[Yujun Zhang]

Replies inline

On Thu, Dec 15, 2016 at 10:20 PM Gaoliang (kubi) 
wrote:

> 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.
>

By the first day QTIP is created, it is for Platform Performance
Benchmarking as titled in the wiki page[1] and OPNFV project index.

If there is any scope change, I assume it should be discussed and approved
by TSC. Is that so?

[1]: https://wiki.opnfv.org/display/qtip
___
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 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&rapidView=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] 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,  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  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)
> --
&g

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] Starting to clean-up meetings page on the wiki

[Yujun Zhang]

On Fri, Dec 16, 2016 at 3:36 AM Raymond Paik 
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] Starting to clean-up meetings page on the wiki

[Yujun Zhang]

Hi Ray,

I have similar question.

Since I want to keep the meeting information in QTIP front page to give the
visitor all essential information on the first glance.

Can we link from the index page to a daughter page like
https://wiki.opnfv.org/display/functest/Functest+Meeting

or an anchor like
https://wiki.opnfv.org/display/qtip#PlatformPerformanceBenchmarking-Meeting
 ?

On Fri, Dec 16, 2016 at 5:35 PM Jose Lausuch 
wrote:

> Hi Ray,
>
>
>
> I’ve seen you have created
> https://wiki.opnfv.org/display/meetings/Functest  which contains the same
> info as in the main page.
>
> Shall I move all the content from
> https://wiki.opnfv.org/display/functest/Functest+Meeting to that one to
> avoid pointers to pointers?
>
>
>
> Thanks,
>
> Jose
>
>
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Raymond Paik
> *Sent:* Friday, December 16, 2016 5:36 AM
> *To:* Aimee Ukasick
> *Cc:* opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] Starting to clean-up meetings page on
> the wiki
>
>
>
> I did find a few project meetings where the daughter page was missing the
> meeting logistics info, so I copied them from the main meetings page.  I
> will also be reaching out to a few PTLs where the meeting information is
> inconsistent...
>
>
>
> Finally, if there are meetings that are no longer occurring could you let
> me know so that I can remove them from the meetings page?
>
>
>
> Thanks,
>
>
>
> Ray
>
>
>
>
>
> On Thu, Dec 15, 2016 at 2:13 PM, Aimee Ukasick <
> aimeeu.opensou...@gmail.com> wrote:
>
> VNF Event Streaming looks good.
>
>
>
> On 12/15/2016 01:35 PM, Raymond Paik wrote:
> > All,
> >
> > Following up on one of my action items from a few weeks ago  On
> > the meetings wiki page
> > (https://wiki.opnfv.org/display/meetings/Meetings), a relatively
> > simple fix I mentioned was to eliminate the "Project Meetings" section
> > from the main page and keep all the meetings detail on the daughter
> > pages for each project teams.  Please see the attached screenshot.
> > This will keep the main page short plus eliminate having to make
> > meeting updates on two places on the wiki.
> >
> > There were 15 projects that did not have daughter pages, so I went
> > ahead and created them and copied the information from the main page.
> > The 15 projects were Apex, Barometer (I just renamed the SFQM page),
> > Daisy4NFV, Domino, Fuel, Functest, HA, Models, ONOSFW, OVS4NFV, Qtip,
> > Security, SFC, VES, and Yardstick.  Could I ask project team members
> > from these 15 projects to verify that the information in the daughter
> > pages are correct?  If I don't hear any feedback by January 3rd, I
> > will go ahead and delete the project meeting details on the main page...
> >
> > 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.
> >
> > Thanks,
> >
> > Ray
> >
> >
>
> > ___
> > opnfv-tech-discuss mailing list
> > opnfv-tech-discuss@lists.opnfv.org
> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> --
> Aimee Ukasick, AT&T Open Source
>
>
> ___
> 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] 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  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 
> 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
> ] *On Behalf Of *Yujun Zhang
> *Sent:* Freitag, 16. Dezember 2016 10:41
> *To:* Raymond Paik ;
> 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 
> 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] Starting to clean-up meetings page on the wiki

[Yujun Zhang]

Alfred,

There is calendar and the widget. One widget can display several calendars
in one place. Each calendar in the widget can be considered as a filter.

So we either have no filter, all projects in same calendar, or one filter
for each group, or one filter for one project.
MORTON, ALFRED C (AL) 于2016年12月18日 周日00:17写道：

>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Yujun Zhang
> *Sent:* Saturday, December 17, 2016 8:10 AM
> *To:* Beierl, Mark; Kunzmann, Gerald
> *Cc:* opnfv-tech-discuss@lists.opnfv.org
>
>
> *Subject:* Re: [opnfv-tech-discuss] Starting to clean-up meetings page on
> the wiki
>
>
>
> 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.
>
>
>
> *[ACM] *
>
> *I don’t see how that would work, since the meetings are *
>
> *scheduled for specific projects. I could appreciate*
>
> *separate calendars for the different work areas*
>
> *(Requirements, Integration and Testing, Collaborative Development)*
>
> *as on the Approved projects page [2]*
>
> *But if the purpose of the master calendar is to help*
>
> *(new) projects to avoid all other meetings, then we need*
>
> *all meetings in the one place.*
>
>
>
> *Al*
>
> *[2] https://wiki.opnfv.org/display/PROJ/Approved+Projects
> <https://wiki.opnfv.org/display/PROJ/Approved+Projects>*
>
>
>
> On Sat, Dec 17, 2016 at 12:52 AM Beierl, Mark 
> 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 
> 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
> ] *On Behalf Of* Yujun Zhang
> *Sent:* Freitag, 16. Dezember 2016 10:41
> *To:* Raymond Paik ;
> 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 
> 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] [qtip] Agenda for weekly meeting 2016-12-19

[Yujun Zhang]

All,

We shall use zoom channel https://zoom.us/j/834597864 for today's meeting.

Topic: QTIP Weekly
Time: Dec 19, 2016 3:30 PM (GMT+8:00) Beijing, Shanghai

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/834597864

Or iPhone one-tap (US Toll):  +14086380968,834597864# or
+16465588656,834597864#

Or Telephone:
Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
Meeting ID: 834 597 864
International numbers available:
https://zoom.us/zoomconference?m=oi98SXg-voXc3EAzJLjm_k3Ja5cqdVFx


On Fri, Dec 16, 2016 at 9:32 AM Yujun Zhang 
wrote:

> @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*
><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&rapidView=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] [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] [test-wg] [all] TestPerf EcoSystem diagram now editable

[Yujun Zhang]

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) 
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) 
> 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, Testperf Ecosystem Diagram is not only to
> show what the one project will do , but also the relationship between each
> projects. It is on the Testing Work Group Home Page and shows the
> consensus to the whole community. Another important function of this
> diagram is that It could help the test projects to avoid  overlap.  *We
> shouldn’t modify the Ecosystem Diagram before  consensus. *Otherwise it
> may delivers misleading information to the whole community.
>
>
>
> I suggest to discuss the modification process of our Testperf Ecosystem
> Diagram in our testperf weekly meeting. Before the discussion taking place, 
> *we’d
> better go back to the structure[1]  of ecosystem on which we have consensus
> *and keep it editable. Currently, what is in my mind about the process is
> that maybe a proposal first, then we could discuss together and decide how
> to make the modification.
>
>
>
>
>
> [1]
> https://wiki.opnfv.org/download/attachments/2926690/OPNFV_testing_group.png?version=1&modificationDate=1467636653000&api=v2
>
>
>
> Regards,
>
> Kubi
>
>
>
> 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

[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&rapidView=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

[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&projectKey=QTIP&view=reporting&chart=sprintRetrospective&sprint=207
___
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

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

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

[Yujun Zhang]

QTIP runners,

Next weekly meeting on 2017-01-02 is cancelled for New Year Holiday.

Happy 2017 to all \o/

--
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] [test-wg] unit test strategy in test projects

[Yujun Zhang]

Some of my ideas on unit test inline

On Wed, Jan 4, 2017 at 1:26 AM  wrote:

> Hi
>
> First of all, all the best for 2017!
>
> we got an interesting discussion on unit tests in Functest this morning
> and more specifically on how we should use them.
>
> see
>
> http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2017/opnfv-functest.2017-01-03-08.00.log.html
> from 08:36:00
>
> Did you already elaborate any strategy regarding your unit tests?
>
> - coverage target 100%? 80% any figure? exit jenkins if not reached?
>

I think 80% is a reasonable starting point. And we could apply it in
verification job but skip voting to avoid blocking fast development.

We may enforce it for stable branch as a release criteria.

- function / method based
>

Yes, we enforce a companion unit test for every module in QTIP and covers
the public interface.

- use of mock objects
>

mock is especially useful in unit test to isolate modules under test from
others

- unit versus unit/functionnal tests
>

unit test and functional test focus on different target. Unit test
guarantee a module works as expected, while functional test ensures related
modules works together correctly to fulfil a functional requirement.

What are your best practices?
>

The above are my two cents in unit testing :-)
___
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] unit test strategy in test projects

[Yujun Zhang]

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  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 further more whether it breaks the original
> functionality, we cannot tell.
>
>
> BRs
>
> Serena
>
>
>
> E: feng.xiao...@zte.com.cn
> Original Mail
> *Sender: *YujunZhang
> *To: *＜morgan.richo...@orange.com＞＜test...@lists.opnfv.org＞
> *CC: *Ashish Kumar;TECH-DISCUSS OPNFV;
> *Date: *2017/01/04 08:48
> *Subject: **Re: [test-wg] unit test strategy in test projects*
> Some of my ideas on unit test inline
>
> On Wed, Jan 4, 2017 at 1:26 AM ＜morgan.richo...@orange.com＞ wrote:
>
> Hi
>
> First of all, all the best for 2017!
>
> we got an interesting discussion on unit tests in Functest this morning
> and more specifically on how we should use them.
>
> see
>
> http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2017/opnfv-functest.2017-01-03-08.00.log.html
> from 08:36:00
>
> Did you already elaborate any strategy regarding your unit tests?
>
> - coverage target 100%? 80% any figure? exit jenkins if not reached?
>
>
> I think 80% is a reasonable starting point. And we could apply it in
> verification job but skip voting to avoid blocking fast development.
>
> We may enforce it for stable branch as a release criteria.
>
> - function / method based
>
>
> Yes, we enforce a companion unit test for every module in QTIP and covers
> the public interface.
>
> - use of mock objects
>
>
> mock is especially useful in unit test to isolate modules under test from
> others
>
> - unit versus unit/functionnal tests
>
>
> unit test and functional test focus on different target. Unit test
> guarantee a module works as expected, while functional test ensures related
> modules works together correctly to fulfil a functional requirement.
>
> What are your best practices?
>
>
> The above are my two cents in unit testing :-)
>
___
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] 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  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 
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  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 further more whether it breaks the original
func

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 
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) ; test-wg <
test...@lists.opnfv.org>
*Cc:* TECH-DISCUSS OPNFV ; Morgan
Richomme (morgan.richo...@orange.com) ; Jose
Lausuch ; Cooper, Trevor ;
mark.bei...@emc.com; Yuyang (Gabriel) 
*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) 
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) 
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, Testperf Ecosystem Diagram is not only to
show what the one project will do , but also the relationship between each
projects. It is on the Testing Work Group Home Page and shows the consensus
to the whole community. Another important function of this diagram is that
It could help

[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&rapidView=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] [infra][doctor] experimental trigger not working

[Yujun Zhang]

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


[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: * on behalf of Yujun
> Zhang 
> *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]

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 
> *Date: *Friday, 6 January 2017 at 12:46
> *To: *Fatih Degirmenci , "
> 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: * on behalf of Yujun
> Zhang 
> *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]

Hi, Fatih

It seems the experimental check will clear verified status which is an
unexpected side-effect.

[image: Screen Shot 2017-01-07 at 9.35.49 PM.png]
×


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 
> *Date: *Friday, 6 January 2017 at 12:46
> *To: *Fatih Degirmenci , "
> 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: * on behalf of Yujun
> Zhang 
> *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] 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&rapidView=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  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&rapidView=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] [pinpoint] project release plan

[Yujun Zhang]

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

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 
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

Re: [opnfv-tech-discuss] [pharos] Including Documentation on the Wiki

[Yujun Zhang]

An alternative solution is to use markdown instead of rst. Confluence
supports Markdown inclusion quite well.

See example page in QTIP[1][2]

[1]: https://wiki.opnfv.org/display/qtip/Contributing
[2]: https://git.opnfv.org/qtip/tree/CONTRIBUTING.md


On Tue, Jan 10, 2017 at 8:37 AM Trevor Bramwell <
tbramw...@linuxfoundation.org> wrote:

> Hi all,
>
> I've written a guide on embedding documentation from the artifacts site
> into
> wiki pages[1]. The hope is that this will be used to facilitate the
> migration of Pharos lab documentation into the repo.
>
> One drawback to this from our current approach (HTML Include), is the
> iframe does not automatically grow to the height of the underlying page,
> causing an extra scrollbar to be added to the page.
>
> If anyone has expertise with JavaScript and the time to tackle that
> issue, it would be greatly appreciated.
>
> Regards,
> Trevor Bramwell
>
> [1] https://wiki.opnfv.org/display/SKETCH/Including+External+Documentation
> ___
> 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] Follow-up on the meetings wiki page discussion

[Yujun Zhang]

Done for QTIP.  See https://wiki.opnfv.org/display/meetings/QTIP

Please check if this is the expected result.

[image: Screen Shot 2017-01-11 at 3.38.32 PM.png]
×
Yujun

On Wed, Jan 11, 2017 at 2:02 PM Raymond Paik 
wrote:

> All,
>
> Following up on our conversation from the TSC call...
>
> As discussed, we streamlined the project/working group meetings
> information on the wiki (https://wiki.opnfv.org/display/meetings) so that
> you don't have to update the same meeting information both on the main
> meetings page and the daughter pages for individual meetings.
>
> As Mark also noted during the call, we have the opportunity to carry this
> further if project teams utilize the "team calendars" macro in meetings
> pages.  The information from the team calendars can be aggregated into the
> main calendar on the meetings wiki page which now has to be manually
> updated.  You'll find an example on the Storperf meetings page (
> https://wiki.opnfv.org/display/meetings/Storperf+Team+Weekly+Meeting)
> plus Mark's proposal before the holidays at
> https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2016-December/014182.html.
>  [Mark, feel free to add/correct anything :-)]
>
> Please let us know if you have any thoughts/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

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

[Yujun Zhang]

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

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

   - all review yardstick-qtip integration proposal if interested


   - Taseer update Prequisite and OPNFV section on
   https://etherpad.opnfv.org/p/qtip-bootcamp


   - yujunz finalize qtip-bootcamp and move it to wiki page


   - #done yujunz send proposal of fast track submit to all committers

Topics

   - Danube release schedule: https://wiki.opnfv.org/display/SWREL/Danube


   - Arrangement during Sprint Festival

Recurring

   - active sprint followup
   https://jira.opnfv.org/secure/RapidBoard.jspa?projectKey=QTIP&rapidView=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] [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  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  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  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) 
> 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  wrote:
>
> 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.
>
>
>
>
>
>
> --
>
> ***
> *Lincoln Lavoie*
>

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

[Yujun Zhang]

On Sat, Jan 14, 2017 at 10:16 AM Leo Wang  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  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  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  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  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)  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  wrote:

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 p

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] [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 
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 
> 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 
> 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

[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] [Doctor] reset server state performance issues

[Yujun Zhang]

+1 for notification from inspector.

For inspector with RCA like Vitrage, it is quite straight forward to deduce
the VM error from Host failure.
Juvonen, Tomi (Nokia - FI/Espoo) 于2017年1月17日
周二18:52写道：

> In my current APEX testing environment Doctor use case takes average about
> 290ms (from detection to alarm received by consumer).
>
> I have been testing this again a bit and here is some data and conclusions.
>
> In my system the average ”reset state to error Nova API call” duration was:
> 248ms
> Then I changed the forming of the payload in Nova to contain the
> absolutely minimum to our needs (which was the thing I measured to take a
> lot of time already back in autumn):
> tenant_id
> user_id
> instance_id
> state
> With this change I dropped the average ”reset state to error Nova API
> call” duration to:
> 158ms
>
> So average of 90ms was taken from Doctor use case execution by this trial
> code.
>
> Anyhow this is still not enough as I would be happy to have total time
> under 50ms to reach some kind of Telco expectations (if didn’t calculate
> yet, in my testing system the other part of Doctor consumes already ~50ms)
>
> Note! As I have been restarting nova-api when doing code changes I have
> discover a reason for our random failure in Doctor testing. When nova-api
> is restarted, the first ”reset state to error Nova API call” usually takes
> little over 1second. Also you can get this 3 times as it means first API
> call on each controller (and we have 3). Even with my enhanced notification
> payload, this will still be an issues, since it cuts just that average of
> 90ms (yes, even the API call would take normally let’s say 1050ms, it still
> cuts just about the same amount of time ending with total execution over
> 1second). I have not looked deeper wither this is some Nova cache or making
> the .pyc in first call, just measured this is what happens. I have also
> seen the same issue with other environment.
>
> Note! As there is this radical problem of first ”reset state to error Nova
> API call”, I have not included that in my time measures.
>
> Next thing to try would be the right thing to do: Make the notification
> straight from Inspector and get rid of the needles ”reset state to error
> Nova API call”.
>
> Br,
> Tomi
>
> ___
> 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] 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] [intern] bootcamp for intern projects

[Yujun Zhang]

The first intern student in QTIP, Taseer Ahmed has created a wiki page[1]
as an orientation for intern *candidates* of OPNFV QTIP project *before*
 application.

Forwarded to mailing list since it could also be useful for other projects.

[1]: https://wiki.opnfv.org/display/qtip/Bootcamp
___
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

[opnfv-tech-discuss] [qtip][yardstick] Q&A 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

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

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] 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] 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