Re: [opnfv-tech-discuss] [release][euphrates] Euphrates status

[David McBride]

UPDATE Oct 16, 2017

*Scenario Summary*

Total (listed on scenario status page and found in Jenkins) 52
Pass Deploy 65%
Fail Deploy 17%
Not Running 17%
Functest results 71%
YardStick results 56%


On Fri, Oct 13, 2017 at 8:59 PM, David McBride  wrote:

> UPDATE Oct 13, 2017
>
> *Scenario Summary*
>
> Total (listed on scenario status page and found in Jenkins) 52
> Pass Deploy 63%
> Fail Deploy 19%
> Not Running 17%
> Functest results 69%
> YardStick results 58%
>
> *UPDATE on Issues:*
>
>1. *Chinese National Holiday.  *The Huawei lab is back online and
>Joid, Compass, and Yardstick Jenkins jobs are running again.
>2. *Intel lab firewall reconfiguration.*  The workaround implemented
>by the release engineering tea was successful and the lab resources are
>once again available for use in CI.
>3. *Docker builds.*  See RELENG-315
>.  This issue was mitigated
>by applying additional resources, as well as changes to the script.
>
>
>
> On Mon, Oct 2, 2017 at 5:33 PM, David McBride <
> dmcbr...@linuxfoundation.org> wrote:
>
>> Updated installer and scenario data after the weekend:
>>
>> *Installer Summary (changes in red)*
>>
>>
>>
>> *DEPLOY ON EUPHRATES *
>>
>> *FUNCTEST DASHBOARD ON EUPHRATES*
>>
>> *YARDSTICK DASHBOARD ON EUPHRATES*
>>
>> *APEX*
>>
>> yes
>>
>> yes
>>
>> yes
>>
>> *COMPASS*
>>
>> yes
>>
>> *yes*
>>
>> yes
>>
>> *DAISY*
>>
>> yes
>>
>> yes
>>
>> n/a
>>
>> *FUEL (X86)*
>>
>> yes
>>
>> yes
>>
>> no
>>
>> *FUEL (AARCH64)*
>>
>> yes
>>
>> yes
>>
>> no
>>
>> *JOID*
>>
>> yes
>>
>> yes
>>
>> yes
>>
>> *Scenario Summary*
>>
>> Total (listed on scenario status page and found in Jenkins) 45
>> Pass Deploy 58%
>> Fail Deploy 36%
>> Not Running 9%
>> Functest results 58%
>> YardStick results 42%
>>
>>
>> On Fri, Sep 29, 2017 at 7:50 PM, David McBride <
>> dmcbr...@linuxfoundation.org> wrote:
>>
>>> TSC Members,
>>>
>>> As you know, the Euphrates release is scheduled for Oct 6.  In advance
>>> of the next TSC meeting, here is the status of the release. Let me know if
>>> you have questions or comments.
>>>
>>> *Installer Summary*
>>>
>>>
>>>
>>> *deploy on euphrates *
>>>
>>> *Functest dashboard on euphrates*
>>>
>>> *yardstick dashboard on euphrates*
>>>
>>> *Apex*
>>>
>>> yes
>>>
>>> yes
>>>
>>> yes
>>>
>>> *Compass*
>>>
>>> yes
>>>
>>> no
>>>
>>> no
>>>
>>> *daisy*
>>>
>>> yes
>>>
>>> yes
>>>
>>> n/a
>>>
>>> *fuel (x86)*
>>>
>>> yes
>>>
>>> yes
>>>
>>> no
>>>
>>> *fuel (aarch64)*
>>>
>>> yes
>>>
>>> no
>>>
>>> no
>>>
>>> *Joid*
>>>
>>> yes
>>>
>>> yes
>>>
>>> yes
>>>
>>>
>>> *Scenario Summary*
>>>
>>> Total (listed on scenario status page and found in Jenkins) 45
>>> Pass Deploy 47%
>>> Fail Deploy 42%
>>> Not Running 11%
>>> Functest results 49%
>>> YardStick results 38%
>>> *Major Issues*
>>>
>>>1. *Chinese National Holiday.  *There is a Chinese holiday from Oct
>>>1 - 8.  During this period, there will be power maintenance in the
>>>building where the Huawei lab is located and the pods will be offline.
>>>(https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-S
>>>eptember/018333.html) This will impact the Compass and JOID
>>>installers, as well as all of the projects that depend on those 
>>> installers. The
>>>Yardstick project will also be impacted by the Huawei lab outage.
>>>2. *Intel lab firewall reconfiguration.*  The status remains
>>>unchanged.  In the mean time, the LF release engineering team has
>>>identified a workaround which could be in place by Monday or Tuesday.
>>>The main impact has been that the Apex, Compass, and JOID installers have
>>>had to shift builds to an alternate POD, thereby reducing capacity.  In
>>>addition, the VSPerf and KVM4NFV projects are without CI support.
>>>3. *Docker builds.*  See RELENG-315
>>>.  With the increase of
>>>the number of docker jobs in Euphrates, there have been a lot of failures
>>>due to timeouts.  This has been partially resolved with additional 
>>> capacity
>>>and improvements to the script, but remains an open issue.  This affects
>>>any project that requires docker builds, such as StorPerf.
>>>
>>>
>>> --
>>> *David McBride*
>>> Release Manager, OPNFV
>>> Mobile: +1.805.276.8018
>>> Email/Google Talk: dmcbr...@linuxfoundation.org
>>> Skype: davidjmcbride1
>>> IRC: dmcbride
>>>
>>
>>
>>
>> --
>> *David McBride*
>> Release Manager, OPNFV
>> Mobile: +1.805.276.8018
>> Email/Google Talk: dmcbr...@linuxfoundation.org
>> Skype: davidjmcbride1
>> IRC: dmcbride
>>
>
>
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>



-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride

Re: [opnfv-tech-discuss] [Doctor] Telco Scheduled Host Maintenance POC demo

[Juvonen, Tomi (Nokia - FI/Espoo)]

Hi,

There seemed to be error in the recording and the video is not full. I will 
remove the video for now and put back later when have the final version ready 
that is also aimed for wider audience.

Br,
Tomi

  _
  From: Juvonen, Tomi (Nokia - FI/Espoo)
  Sent: Friday, October 06, 2017 1:56 PM
  To: opnfv-tech-discuss@lists.opnfv.org
  Subject: [Doctor] Telco Scheduled Host Maintenance POC demo


  Hi Doctors,

  Added the POC demo video to our project page, so all can see the demo I 
kept in the last meeting.
  Telco Scheduled Host Maintenance 
POC
 (Oct 6 2017)

  Have a nice weekend,
  Tomi



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

[opnfv-tech-discuss] [Doctor][Functest] about doctor verify job using 'functest-suite-builder'

[dong.wenjuan]

Hi All,






As doctor verify job using the 'functest-suite-builder' to test, I found that 
many parameters are not passed to start functest docker container.


Such as {sshkey_vol}, {TESTCASE_OPTIONS}, you can see the log from[1]






[1] 
https://build.opnfv.org/ci/job/doctor-python-verify-apex-sample-master/121/console



This part:

docker run --privileged=true -e INSTALLER_TYPE=apex -e INSTALLER_IP=192.168.X.X 
-e NODE_NAME=zte-virtual3 -e DEPLOY_SCENARIO=os-nosdn-nofeature-ha -e 
BUILD_TAG=jenkins-doctor-python-verify-apex-sample-master-121 -e 
DEPLOY_TYPE=baremetal -v 
/home/jenkins/opnfv/functest/images:/home/opnfv/functest/images -v 
/home/jenkins/opnfv/functest/results/master:/home/opnfv/functest/results -v 
/home/jenkins/opnfv-openrc.sh:/home/opnfv/functest/conf/openstack.creds 
opnfv/functest-features:latest /bin/bash -c 'prepare_env start && run_tests -r 
-t doctor-notification'




You can see that  {sshkey_vol}, {TESTCASE_OPTIONS} are missing and 
'INSTALLER_IP' is wrong.


I remember that using 'export XXX=XXX' in different builders are not effective, 
they have different workspace.


Not sure about that. Do you have any ideas? Can you help to fix it? Thanks~










BR,


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

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Hi

Can we have a quick discussion in any weekly meeting (sdnvpn, functest?) on 
this topic to pick the best approach to move forward? Also Xu Dan has raised 
few other concerns on the location of log files and option for disabling the 
gathering logs…etc.

Thanks
Srikanth



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Friday, October 13, 2017 4:28 AM
To: Tim Irnich 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Tim,

My only concern is that by implementing this function inside the test case, we 
might run into exceptions raised if there is a problem with SSH keys or 
whatever other problem accessing the nodes.

Collecting logs when the test fails makes sense, but it doesn’t harm if we 
collect it when it passes as well. Anyway, if we do it only when having 
failures, I imagine that logic could also be implemented post-job by checking 
the "criteria": “FAIL" value on the DB and executing some j-job to collect the 
logs. This logs could be uploaded to artifact repo for further analysis as we 
do for the Functest logs.

Regards,
Jose




On 13 Oct 2017, at 09:27, Tim Irnich 
> wrote:

Jose,

I see the point of avoiding log collection in the code for test execution to 
avoid false negatives in case something with the log collection itself goes 
wrong (although I’m wondering a bit if that cannot also be handled by carefully 
implementing the test pass/fail criteria).

There are however cases where we’ll want to collect logs only if a test fails, 
in order to enable a first tier of offline troubleshooting. You’ll remember the 
gather_logs function Niko implemented for the bgpvpn tests – that is one 
example. Can that effectively be handled if we separate things as you suggest?

Regards, Tim


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Friday, October 13, 2017 09:16
To: xudan (N) >; Morgan, Jack 
>
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi,

When it comes to log collection, I strongly believe it should be done post-job 
in our CI pipeline, not as part of the test case. Users can always collect logs 
manually regardless of the installer tools they use…

And regarding making it automated in OPNFV after Functest/Yardstick execution, 
would it make sense to re-use the PDF (Pod Descriptor File)? Otherwise, we are 
duplicating config files like pod.yaml or new files with information about the 
servers…
@Jack: is there a possibility to include login information in the PDF (user, 
password, path to private key, …) of the nodes already deployed?

Regards,
Jose




On 12 Oct 2017, at 03:50, xudan (N) 
> wrote:

Hi Srikanth,

I have one question. Are the paths of all these log files constant for 
different environment (Apex, Fuel and commercial deployments)?
If all paths for different deployments are the same, then using config file to 
login and getting files can work.
If not, there will be some errors even though it can login with the config file.

One more question, what logs do SDNVPN get from all nodes? Are they useful for 
users? If not, can we have an option to disable it?

Thanks
Dan Xu

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of limingjiang
Sent: Thursday, October 12, 2017 9:24 AM
To: Srikanth Vavilapalli
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Srikanth,

Yardstick can use a global pod.yaml for test cases.
Since each test case default use the “pod.yaml” located in 
“/etc/yardstick/pod.yaml”. so if you put “pod.yaml” here, it can apply to each 
test case.
The picture you show below is how yardstick test suite customize the input 
parameters, so it also support each test case with different “pod.yaml”
if you give each test case different “pod.yaml”

BR,
Rex

+---+

+ Mingjiang Li (Rex) Mobile: +86 13761275017
+ Shanghai Institute, Huawei
+ No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
+---+

Re: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Hi Dan

I think you raised a valid point for which I am not sure if the log file paths 
across all deployments stays remain same (in some case, there may be no local 
logging configured)

Seems like the gather_logs() routine in sdnvpn is assuming certain log file 
locations. It is collecting the logs from the following locations on the 
openstack nodes:

  1.  OpenStack
 *   /var/log/nova/
 *   /var/log/neutron/
  2.  OpenDaylight sdnvpn related Karaf logs (If running)
 *   /opt/opendaylight/data/log/
  3.  OVS (Logs for port,flows,groups dump)
 *   /var/log/openvswitch/

I believe these logs are more for debugging purposes rather than for end user 
consumption, but I may be wrong here.

Thanks
Srikanth

From: xudan (N) [mailto:xuda...@huawei.com]
Sent: Wednesday, October 11, 2017 6:50 PM
To: Srikanth Vavilapalli ; 
opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Srikanth,

I have one question. Are the paths of all these log files constant for 
different environment (Apex, Fuel and commercial deployments)?
If all paths for different deployments are the same, then using config file to 
login and getting files can work.
If not, there will be some errors even though it can login with the config file.

One more question, what logs do SDNVPN get from all nodes? Are they useful for 
users? If not, can we have an option to disable it?

Thanks
Dan Xu

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of limingjiang
Sent: Thursday, October 12, 2017 9:24 AM
To: Srikanth Vavilapalli
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] 答复: [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Srikanth,

Yardstick can use a global pod.yaml for test cases.
Since each test case default use the “pod.yaml” located in 
“/etc/yardstick/pod.yaml”. so if you put “pod.yaml” here, it can apply to each 
test case.
The picture you show below is how yardstick test suite customize the input 
parameters, so it also support each test case with different “pod.yaml”
if you give each test case different “pod.yaml”

BR,
Rex

+---+
[cid:image001.png@01D0A50A.DD5A8F20]
+ Mingjiang Li (Rex) Mobile: +86 13761275017
+ Shanghai Institute, Huawei
+ No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
+---+

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年10月12日 9:03
收件人: Jose Lausuch; Georg Kunz
抄送: 
opnfv-tech-discuss@lists.opnfv.org
主题: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Thanks everyone for your inputs.

So if Yardstick based approach is the preferred one, then I am thinking of 
extending the existing Deployment Factory class with a new generic INSTALLER 
type (something like “config-file” or so) which will provide the same interface 
as other adapters (ApexAdapter, FuelAdapter…etc), but instead reads from the a 
configured pod.yaml file to provide Node information. Plz let me know if you 
see any issues with this approach.

One quick question on Yardstick: Looks like Yardstick accepts the custom 
pod.yaml file on a per test case basis as shown in the below example. Can it 
also accept a global pod.yaml file that can be applied to all or a group of 
test cases.
-
file_name: opnfv_yardstick_tc043.yaml
   constraint:
  installer: xxx
  pod: xxx-pod1
   task_args:
  xxx-pod1: '{"pod_info": "etc/yardstick/.../pod.yaml",
  "host": "node1.LF","target": "node2.LF"}'

Thanks
Srikanth

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Wednesday, October 11, 2017 10:45 AM
To: Georg Kunz >
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi,

I would vote for having something similar to Yardstick [1] but centralized in 
Releng with an easy python lib that enables functions like SCP things to/from 
the deployed nodes.

For your third point, log collection shouldn’t be done at test case level. It 
should be performed by CI after running 

Re: [opnfv-tech-discuss] [xci] xci - aio installation failed on a ubuntu 16.04 VM

[Srikanth Vavilapalli]

Thanks Mark

I recreated my VM with 8GB RAM and 8 vCPUs as recommended in the wiki, but I 
still hit the same issue. I will try to increase the RAM further and try, but 
in the meantime if there are anything else I could try, plz let me know...

vagrant@xci:~/releng-xci/xci$ sudo virsh start opnfv
error: Failed to start domain opnfv
error: internal error: early end of file from monitor, possible problem: 
2017-10-16T22:14:57.110918Z qemu-system-x86_64: cannot set up guest memory 
'pc.ram': Cannot allocate memory

vagrant@xci:~/releng-xci/xci$ free -m
  totalusedfree  shared  buff/cache   available
Mem:   7982 8974226  1228596738
Swap:   511   0 511
vagrant@xci:~/releng-xci/xci$


Thanks
Srikanth

-Original Message-
From: Markos Chandras [mailto:mchand...@suse.de] 
Sent: Friday, October 13, 2017 1:17 AM
To: Srikanth Vavilapalli ; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [xci] xci - aio installation failed on a 
ubuntu 16.04 VM

On 12/10/17 19:33, Srikanth Vavilapalli wrote:
> Hi Markos
> 
> The following is the error I get when I start the opnfv domain. It says 
> "cannot allocate memory". I have 4GB RAM assigned to my vagrant VM where I am 
> bringing up the XCI. May I know what are minimum RAM needs fro XCI AIO flavor?
> 
> vagrant@xci:~$ sudo virsh start opnfv
> error: Failed to start domain opnfv
> error: internal error: early end of file from monitor, possible 
> problem: 2017-10-12T18:29:50.649458Z qemu-system-x86_64: cannot set up 
> guest memory 'pc.ram': Cannot allocate memory
> 
> vagrant@xci:~$ free -m
>   totalusedfree  shared  buff/cache   
> available
> Mem:   3951 6561853  361441
> 2958
> Swap:   511  19 492
> vagrant@xci:~$

The AIO requirements are listed here

https://git.opnfv.org/releng-xci/tree/xci/config/aio-vars

The opnfv VM will need 8G of RAM so your vagrant box has to have more than that.

--
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 
(AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing installer dependent information in the test tools

[Srikanth Vavilapalli]

Thanks Rex for the clarification.

From: limingjiang [mailto:limingji...@huawei.com]
Sent: Wednesday, October 11, 2017 6:24 PM
To: Srikanth Vavilapalli 
Cc: opnfv-tech-discuss@lists.opnfv.org; Jose Lausuch ; 
Georg Kunz 
Subject: 答复: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi Srikanth,

Yardstick can use a global pod.yaml for test cases.
Since each test case default use the “pod.yaml” located in 
“/etc/yardstick/pod.yaml”. so if you put “pod.yaml” here, it can apply to each 
test case.
The picture you show below is how yardstick test suite customize the input 
parameters, so it also support each test case with different “pod.yaml”
if you give each test case different “pod.yaml”

BR,
Rex

+---+
[cid:image001.png@01D0A50A.DD5A8F20]
+ Mingjiang Li (Rex) Mobile: +86 13761275017
+ Shanghai Institute, Huawei
+ No. , Xinjinqiao Road, Pudong, Shanghai, 201206, P.R.China
+---+

发件人: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Srikanth Vavilapalli
发送时间: 2017年10月12日 9:03
收件人: Jose Lausuch; Georg Kunz
抄送: 
opnfv-tech-discuss@lists.opnfv.org
主题: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Thanks everyone for your inputs.

So if Yardstick based approach is the preferred one, then I am thinking of 
extending the existing Deployment Factory class with a new generic INSTALLER 
type (something like “config-file” or so) which will provide the same interface 
as other adapters (ApexAdapter, FuelAdapter…etc), but instead reads from the a 
configured pod.yaml file to provide Node information. Plz let me know if you 
see any issues with this approach.

One quick question on Yardstick: Looks like Yardstick accepts the custom 
pod.yaml file on a per test case basis as shown in the below example. Can it 
also accept a global pod.yaml file that can be applied to all or a group of 
test cases.
-
file_name: opnfv_yardstick_tc043.yaml
   constraint:
  installer: xxx
  pod: xxx-pod1
   task_args:
  xxx-pod1: '{"pod_info": "etc/yardstick/.../pod.yaml",
  "host": "node1.LF","target": "node2.LF"}'

Thanks
Srikanth

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Wednesday, October 11, 2017 10:45 AM
To: Georg Kunz >
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [sdnvpn] Proposal for removing 
installer dependent information in the test tools

Hi,

I would vote for having something similar to Yardstick [1] but centralized in 
Releng with an easy python lib that enables functions like SCP things to/from 
the deployed nodes.

For your third point, log collection shouldn’t be done at test case level. It 
should be performed by CI after running the test tools, otherwise you can a 
false negative when running those test on non-OPNFV installers.

Regards,
Jose

[1] 
https://raw.githubusercontent.com/opnfv/yardstick/master/etc/yardstick/nodes/fuel_virtual/pod.yaml


On 11 Oct 2017, at 18:08, Georg Kunz 
> wrote:

Hi,

Just to highlight this, from a Dovetail/CVP perspective, the important aspect 
is that there are no dependencies on OPNFV-specific resources/lib in order to 
be able to run test cases against commercial non-OPNFV deployments.

Having to write an adapter for a particular commercial deployment before you 
can run Dovetail is obviously not really an option. So, for tests which require 
SSH/SCP access, we need to think about...

  *   If the adapter can be parameterized, so that we can make it a 
configuration option, e.g., specifying login credentials, source and target 
directories, etc., similarly to Yardstick.
  *   Reuse what Yardstick is using?
  *   If the test case be parameterized such that it does not attempt to gather 
logs if used for certification? (limited use, of course)
  *   …

Cheers
Georg

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Jose Lausuch
Sent: Wednesday, October 11, 2017 4:40 PM
To: Beierl, Mark >
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] 

[opnfv-tech-discuss] [OPNFV Helpdesk #45345] Regarding Bottlenecks Gerrit Privilege

[Aric Gardner via RT]

Hi Amit,

Is everything working as expected?

-Aric


On Wed Sep 06 13:57:31 2017, bramwelt wrote:
> Hi Amit,
> 
> Sorry for the delay on this, looks like we already have a form on file
> for you!
> 
> I have sent you an invite to join the Bottlenecks contributors group.
> 
> This will prompt you to create a Linux Foundation account if you don't
> already have one. Please choose a username without spaces or special
> characters as Gerrit requires a valid unix username.
> 
> You will also need to sign the individual CLA[1] and upload an SSH
> public key
> in Gerrit[2] before you can upload code.
> 
> Don't hesitate to contact us at helpd...@opnfv.org if you run into any
> issues.
> 
> Welcome to OPNFV, thanks for contributing to Bottlenecks, and we wish
> you the best on your internship!
> 
> Regards,
> Trevor Bramwell
> 
> [1] https://gerrit.opnfv.org/gerrit/#/settings/agreements
> [2] https://gerrit.opnfv.org/gerrit/#/settings/ssh-keys
> 
> On Tue Sep 05 19:10:13 2017, amitkumarj...@gmail.com wrote:
> > Hi Aric,
> >
> > Thanks for your response.
> >
> > I don't have a company email and I'm a OPNFV Intern working on Stress
> > testing.
> >
> > Please send me the required form.
> >
> > Thanks in advance!
> >
> > Regards
> > Amit Kumar Jaiswal
> > ᐧ
> >
> > Amit Kumar Jaiswal
> > Mozilla Representative  |
> > LinkedIn
> >  | Portfolio
> > 
> > New Delhi, India
> > M : +91-8081187743 | T : @AMIT_GKP | PGP : EBE7 39F0 0427 4A2C
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Sep 5, 2017 at 5:32 PM, Aric Gardner via RT <
> > opnfv-helpd...@rt.linuxfoundation.org> wrote:
> >
> > > Hi Amit,
> > >
> > > Do you have a company email? We have a DCO that needs to be signed
> > > off
> > > on, and If you are not working for a member company I will need to
> > > ask
> > > my colleague Ray to send you an form.
> > >
> > > Regards,
> > > Aric
> > >
> > > On Tue, Sep 5, 2017 at 3:03 AM, AMIT KUMAR JAISWAL via RT
> > >  wrote:
> > > >
> > > > Tue Sep 05 03:03:31 2017: Request 45345 was acted upon.
> > > >  Transaction: Ticket created by amitkumarj...@gmail.com
> > > >Queue: OPNFV Helpdesk
> > > >  Subject: Regarding Bottlenecks Gerrit Privilege
> > > >Owner: Nobody
> > > >   Requestors: amitkumarj...@gmail.com
> > > >   Status: new
> > > >  Ticket  > > > https://rt.linuxfoundation.org/Ticket/Display.html?id=
> > > 45345 >
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I would like to contribute to the Bottlenecks project and willing
> > > > to take
> > > > up the ongoing Bottlenecks task. Please give the gerrit
> > > > privilege,
> > > > below
> > > is
> > > > my Gerrit details:
> > > >
> > > > Gerrit Username: amitkumarjaiswal
> > > > Email : amitkumarj...@gmail.com
> > > >
> > > > Thanks in advance!
> > > >
> > > > Regards
> > > > Amit Kumar Jaiswal
> > > > Mozilla Representative 
> > > > |
> > > LinkedIn
> > > >  | Portfolio
> > > > 
> > > > New Delhi, India
> > > > M : +91-8081187743 | T : @AMIT_GKP | PGP : EBE7 39F0 0427 4A2C
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ᐧ
> > > >
> > >
> > >



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

Re: [opnfv-tech-discuss] [Yardstick] Testcase stuck at "Creating stack state: CREATE_IN_PROGRESS"

[Srikanth Lingala]

Thanks Trinath…
I am able to fix the heat stack issue, by creating external network in 
OpenStack Controller node.
But, I am facing one more issue while connecting to VM through SSH, via 
Floating IP.
I am getting the below logs, while connecting to VM:

2017-10-16 18:50:33,483 [DEBUG] yardstick.ssh.athena ssh.py:371 Ssh is still 
unavailable: SSHError("Exception  was raised during 
connect. Exception value is: timeout('timed out',)",)
2017-10-16 18:50:35,485 [DEBUG] yardstick.ssh.athena ssh.py:371 Ssh is still 
unavailable: SSHError("Exception  was raised during 
connect. Exception value is: timeout('timed out',)",)
2017-10-16 18:50:37,487 [DEBUG] yardstick.ssh.athena ssh.py:371 Ssh is still 
unavailable: SSHError("Exception  was raised during 
connect. Exception value is: timeout('timed out',)",)
Process Duration-Ping-1452:
Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
  File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
  File "/home/opnfv/repos/yardstick/yardstick/benchmark/runners/duration.py", 
line 51, in _worker_process
benchmark = cls(scenario_cfg, context_cfg)
  File 
"/home/opnfv/repos/yardstick/yardstick/benchmark/scenarios/networking/ping.py", 
line 47, in __init__
self.connection.wait(timeout=600)
  File "/home/opnfv/repos/yardstick/yardstick/ssh.py", line 374, in wait
raise SSHTimeout("Timeout waiting for '%s'", self.host)
SSHTimeout: ("Timeout waiting for '%s'", u'172.16.0.138')
2017-10-16 18:50:38,534 [ERROR] yardstick.benchmark.core.task task.py:277 
Scenario NO.1: "Ping" ERROR!
2017-10-16 18:50:38,535 [ERROR] yardstick.benchmark.core.task task.py:128 
Testcase: "opnfv_yardstick_tc002" FAILED!!!
Traceback (most recent call last):
  File "/home/opnfv/repos/yardstick/yardstick/benchmark/core/task.py", line 
124, in start
data = self._run(scenarios, run_in_parallel, args.output_file)
  File "/home/opnfv/repos/yardstick/yardstick/benchmark/core/task.py", line 
279, in _run
"{0} runner status {1}".format(runner.__execution_type__, status))
RuntimeError: Duration runner status 1

Regards,
Srikanth.

From: Trinath Somanchi [mailto:trinath.soman...@gmail.com]
Sent: Monday, October 16, 2017 9:42 PM
To: Srikanth Lingala 
Cc: opnfv-tech-discuss@lists.opnfv.org; opnfv-us...@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Yardstick] Testcase stuck at "Creating stack 
state: CREATE_IN_PROGRESS"

Hi Srikanth-

Can you verify the heat logs ?

/Trinath

On 16-Oct-2017 9:26 PM, "Srikanth Lingala" 
> wrote:
Hi,
I am trying to execute an OPNFV testcase with Yardstick.
I downloaded yardstick docker and able to run the docker container.
I wanted to run the usecase “opnfv_yardstick_tc002.yaml” from the repository. I 
executed the below command in yardstick docker VM:

#> yardstick -d task start 
/home/opnfv/repos/yardstick/tests/opnfv/test_cases/opnfv_yardstick_tc002.yaml

But, starting the usecase, I am keep getting the following message and not 
coming out from the above command:

2017-10-16 15:48:34,066 [DEBUG] yardstick.orchestrator.heat heat.py:622 
Creating stack state: CREATE_IN_PROGRESS

Following is the total output:

https://pastebin.com/G1t5jRKN

Can anyone help me to resolve the issue?

Thanks and Regards,
Srikanth.

___
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] [docs] Fuel and Armband merged documentation

[Alexandru Avadanii]

Hi, Ray,
It’s hard to say whether this will continue beyond E release.
Meanwhile, we will keep the docs dir in Armband, like we did in previous 
releases.

BR,
Alex


From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Monday, October 16, 2017 6:26 AM
To: Alexandru Avadanii
Cc: Sofia Wallin; David McBride; opnfv-tech-discuss; Cristina Pauna; Bob Monkman
Subject: Re: [docs] Fuel and Armband merged documentation

Hi Alex,

I think it makes sense for Armband team to have a separate documentation if you 
are going have support of other installers (e.g. Apex or JOID) in the future

I agree that replicating docs is wasteful, but do you think this would continue 
beyond Euphrates?

Thanks,

Ray

On Sunday, October 15, 2017, Alexandru Avadanii 
> wrote:
Hi,
During the E release cycle, Fuel and Armband projects merged their 
documentation(s).
Currently, the contents of Fuel's 'docs/' dir describe usage for both 
architecture.
To keep the old behavior unchanged, we duplicated that docs dir in Armband for 
now.

Going forward, I think building the same documentation twice is wasteful and 
unnecessary.
How do you think we should proceed in this case?

We can agree that Armband project won't publish any docs going further, and 
just remove the docs dir from our repo.
Or we can add a stub pointing to the Fuel project.

Please let us know what you think.

Thank you,
Alex
___
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] Infra WG Weekly Meeting Minutes - Oct. 9th

[Alexandru Avadanii]

Hi, Julien,
We have 2 PODs that rely on PDF (+IDF) currently:

-  lf-pod2 (main Fuel x86_64 baremetal CI POD);

-  arm-pod5 (main Armband Fuel AArch64 baremetal CI POD);
The current securedlab contents are up to date (both master and stable/E 
branches).

However, note that this is *not* enough to unblock MCP on those PODs because 
interface names are not yet described by PDF or IDF, so they are hardcoded to 
lf-pod2/arm-pod5 defaults in the reclass model. This is something I want to fix 
asap, but it requires agreeing on the PDF/IDF mechanism to describe the mapping 
between interface index defined in PDF and the OS interface name.

I will announce it here once we have a PoC for the network interface name 
mapping.

BR,
Alex


From: Julien [mailto:julien...@gmail.com]
Sent: Monday, October 16, 2017 3:26 AM
To: Alexandru Avadanii; Jack Morgan; opnfv-tech-discuss
Cc: Guillermo Herrero
Subject: Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - 
Oct. 9th

Hi Alex,

It's a great news.
2 PODs in our lab reserved for MCP are blocked to deploy in master branch. Can 
you give me a PDF/IDF link which are used now, then we will submit PDF/IDF 
patches according to your version.

For **net_config**, I personally suggest to move it to IDF and get the 
template/format approved ASSP, for it is really important to us.

BR/Julien

Alexandru Avadanii 
>于2017年10月15日周日 
下午9:44写道：
Hi,
Fuel has been using PDF and IDF for weeks now.
We still rely on net_config, which is out of spec, to map between PDF networks 
and the network role within the installer.
Apart from net_config, we still need to sort out the mapping between interfaces 
indexes in PDF and the interface names inside OS (e.g. iface 0 = eno1, iface 2 
= enp1s0f1).

For net_config, Guillermo proposed an alternative as a comment in [1], which 
imo is closer to the hardware view of the setup (especially the port_matrix 
part).
For iface name mapping, we will probably add it to IDF as a Fuel-specific 
section for now (no PoC proposed yet).

BR,
Alex

[1] 
https://gerrit.opnfv.org/gerrit/#/c/42893/6/labs/lf/pod4.yaml


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of Julien
Sent: Sunday, October 15, 2017 12:38 PM
To: Jack Morgan; opnfv-tech-discuss
Subject: Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting Minutes - 
Oct. 9th

Hi Jack and Infra team:

This week I have a chance to directly discuss with installer team: Apex and 
Compass. I still can not contact Joid.

This is the status of PDF in each installer:

Apex: Not started, won't support in E release, and I have submitted a Jira 
ticket in Apex.
Compass: Not started, and plan to support in F release
Daisy: PDF is supported and used in CI PODs for deployment, while IDF is not 
used for now
Fuel: Started, not finished yet
Joid: No response in email and IRC(#opnfv-joid)

I would like to suggest to clear PDF/IDF patches in gerrit, let's make an 
acceptable template and update them in the future, then the lab owners can 
submit their PDF/IDF and used for deployment.

BR/Julien
Jack Morgan >于2017年10月10日周二 
上午12:38写道：
October 9th

Agenda:
1.Status update on PDF
• complete discussion from last week as this is a deliverable for 
Euphrates release
2.LaaS and Dashboard integration Lincoln 
Lavoie
3.Infra documentation on RTD - patch 

Re: [opnfv-tech-discuss] [Yardstick] Testcase stuck at "Creating stack state: CREATE_IN_PROGRESS"

[Trinath Somanchi]

Hi Srikanth-

Can you verify the heat logs ?

/Trinath

On 16-Oct-2017 9:26 PM, "Srikanth Lingala"  wrote:

> Hi,
>
> I am trying to execute an OPNFV testcase with Yardstick.
>
> I downloaded yardstick docker and able to run the docker container.
>
> I wanted to run the usecase “opnfv_yardstick_tc002.yaml” from the
> repository. I executed the below command in yardstick docker VM:
>
>
>
> #> yardstick -d task start /home/opnfv/repos/yardstick/
> tests/opnfv/test_cases/opnfv_yardstick_tc002.yaml
>
>
>
> But, starting the usecase, I am keep getting the following message and not
> coming out from the above command:
>
>
>
> 2017-10-16 15:48:34,066 [DEBUG] yardstick.orchestrator.heat heat.py:622
> Creating stack state: CREATE_IN_PROGRESS
>
>
>
> Following is the total output:
>
>
>
> https://pastebin.com/G1t5jRKN
>
>
>
> Can anyone help me to resolve the issue?
>
>
>
> Thanks and Regards,
>
> Srikanth.
>
> ___
> 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] [Yardstick] Testcase stuck at "Creating stack state: CREATE_IN_PROGRESS"

[Srikanth Lingala]

Hi,
I am trying to execute an OPNFV testcase with Yardstick.
I downloaded yardstick docker and able to run the docker container.
I wanted to run the usecase "opnfv_yardstick_tc002.yaml" from the repository. I 
executed the below command in yardstick docker VM:

#> yardstick -d task start 
/home/opnfv/repos/yardstick/tests/opnfv/test_cases/opnfv_yardstick_tc002.yaml

But, starting the usecase, I am keep getting the following message and not 
coming out from the above command:

2017-10-16 15:48:34,066 [DEBUG] yardstick.orchestrator.heat heat.py:622 
Creating stack state: CREATE_IN_PROGRESS

Following is the total output:

https://pastebin.com/G1t5jRKN

Can anyone help me to resolve the issue?

Thanks and Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [release][fraser] release plans and scenarios (MS1 / Nov 3)

[David McBride]

Team,

I've been working on the Fraser release page
 in the wiki, including
setting up a page for release plans

and for scenario status
.  Please feel
free to add your release plans and scenarios as you are ready.  Recall that
release plans are due as of MS1 on Nov 3.

I've changed the release plan summary

form so that it no longer asks you to list scenarios you are using, since
this seemed redundant to the scenario status page
.  Instead,
I'm asking that all scenario owners add their scenarios to the scenario
status page 
at the same time (or before), they submit their release plan
.

David

-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [Infra] Infra WG Meeting Minutes - Oct. 16th

[Jack Morgan]

  
  
October 16th
Agenda:

  Zuul v3, Fatih Degirmenci

  possibility to start a prototype?

  
  vPOD for container4nfv, Ruijing Guo, Fatih Degirmenci

  INFRA-185 - vPOD for container4nfv OPEN

  
  Long duration testing POD request 

  INFRA-154

  
  Status Updates

  PDF, IDF , SDF efforts
  LaaS and Dashboard integration
  Infra documentation on RTD

  https://gerrit.opnfv.org/gerrit/#/c/45089/

  

  
  Jenkins Plugin Requests

  Timestamper - QTIP
  Warnings Plugin -
Functest

  
  Review actions items

Action Items:

  
Work with Lincoln Lavoie to get CI Pods displayed on labs.opnfv.org Trevor Bramwell
  
  
Determine requirements for
  CI-PODs to ensure ZTE-POD2 meets them. Trevor Bramwell
  
  Update
  documents on CI POD requirements Trevor Bramwell
  Create documentation
  about the job creation on stable branch Fatih Degirmenci, Trevor Bramwell
  Work on putting
infrastructure documentation structure in place Trevor Bramwell
  Clean up securelab access
including creating new ldap group for lab owners Aric Gardner
  Clean up non-active Pharos
committers Jack Morgan

  Pharos project needs to define
hardware details to be included Jack Morgan
  Send email to Lab owners to
request them to input lab information into dashboard Jack Morgan
  Infra WG needs to decide how to
manage documentation - we have two proposals Fatih Degirmenci, Jack Morgan, Ulrich Kleber, Luke Hinds

Ongoing Items:

  Identify
what can be moved from OPNFV Wiki Infra Space to RTD and
what can stay on Wiki, Jack Morgan, Ulrich Kleber, Fatih Degirmenci
  Document how to control commit
  gating in CI evolution Fatih
Degirmenci
  Document how to build an OPNFV Pharos
  lab Jack Morgan


  
Minutes (link)

  
Zuul v3
  
fdegir provides an overview of Zuul
including that potential to bring to OPNFV
its still in testing upstream but
looks interesting for starting a POC
  

vPOD for container4nfv
  
they need a vPOD to run daily jobs
need to find hardware resources  
  

Long duration testing POD request 
  
Intel labs is not able to host this
effort and will need to find hardware resources
in addition Intel labs will be
reducing the total number POD 
  

Status Updates 
  
David_Orange said the work is
progressing for PDF, IDF effort 
Link to patch - https://gerrit.opnfv.org/gerrit/#/c/45037/ and https://gerrit.opnfv.org/gerrit/#/c/45037/
David_Orange is working on a tool to
generate the SDF file based on templates
he shares that this will help
customize and change the SDF as features are
added/removed
there was some discussion between
more static SDF that are maintained by scenario owners
vs auto generated model that David_Orange is introducing
Link to SDF template - https://gerrit.opnfv.org/gerrit/gitweb?p=octopus.git;a=blob;f=scenarios/templates/sdf-template.yaml
Link to RTD structure of Infra WG projects - https://gerrit.opnfv.org/gerrit/#/c/45089/
Lincoln and parker are working on
LaaS/dashboard, they have control of system and will
provide more update next week  
  

Jenkins Plugin Request
  
first is Timestamper = which provides
a time stamp on the build
second is warnings plugins = which
shows plylint graphs but concern is access to Jenkins
interface might slow it down
decision is to move forward to use
timestamper plugin but delay adding warning plugins
until after the release 
Link to patch - https://gerrit.opnfv.org/gerrit/#/c/44603
please review above patch and provide
feedback on alternative proposal to IDF
  

  

Closed
  Actions: 

  

  Enable
yamllint on releng itself Trevor Bramwell RELENG-254 - Fix Yamllint violations in Releng OPEN

Follow up on security audit job logs  RELENG-272 - Ericsson Build 3 not reporting failures to
  comments CLOSED

[opnfv-tech-discuss] Oct 11 Board meeting summary

[Wenjing Chu]

Hi OPNFV community,
The OPNFV Board of Directors met on October 11, 2017 in a teleconference call. 
The following is a summary of what was discussed.

  *   Technical community update: There was a discussion on community 
elections, Euphrates release, and an update on the next Plugfest planning.
  *   Lab-as-a-Service (LaaS): Quotes for hardware and hosting were reviewed 
with the goal of making in a decision in a few weeks.
  *   Open Source Networking (OSN) Days: There was an update on OSN Days 
planned in Europe and Japan over the next two weeks and a discussion on the 
first event in Paris.
  *   Networking projects harmonization: There was a discussion on a proposed 
timeline and a review of resolutions for projects harmonization.  Vote on 
resolutions is expected at the next Board meeting.
Regards
Wenjing

---

Wenjing Chu
Sr. Director, Open Source and Research
Futurewei Technologies, Inc.
(m) +1 (408) 203-2657

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

Re: [opnfv-tech-discuss] NetReady withdraws from Euphrates release

[David McBride]

Hi Georg,

The intent-to-participate window is now open for the "Fraser" release.  The
deadline is Nov 3.  I just wanted to follow up with you to see if the
Netready project would be participating in Fraser.  Thanks.

David

On Fri, Jun 2, 2017 at 6:49 AM, David McBride 
wrote:

> Thanks for the update, Georg. - D
>
> On Fri, Jun 2, 2017 at 4:53 AM, Georg Kunz 
> wrote:
>
>> Hi David,
>>
>>
>>
>> I’d like to inform you that we will put the NetReady project on hold
>> during the Euphrates release cycle. I will be on parental leave for two
>> months after the summit and there are currently no candidates who can take
>> over the project lead. As a result, NetReady will withdraw from the
>> Euphrates release. Moreover, the scenario maintained by me
>> (os-odl-gluon-noha) will not be included in the Euphrates release.
>>
>>
>>
>> Best regards
>>
>> Georg
>>
>
>
>
> --
> *David McBride*
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>



-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Canceled: OPNFV Doctor weekly meeting

[Ryota Mibu]

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:UTC
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Ryota Mibu:MAILTO:r-m...@cq.jp.nec.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=opnfv-tec
 h-disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=andrew.ve
 i...@netcracker.com:MAILTO:andrew.vei...@netcracker.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Marco Var
 lese:MAILTO:marco.varl...@suse.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=Alan McNa
 mee:MAILTO:alan...@openet.com
DESCRIPTION;LANGUAGE=ja-JP:Doctor is a fault management and maintenance pro
 ject to develop and realize the consequent implementation for the OPNFV re
 ference platform.\n\n•   Doctor page: https://wiki.opnfv.org/doctor\
 n•   When: Every Monday 14:00-15:00 UTC (Your local time: http://www
 .timeanddate.com/worldclock/fixedtime.html?iso=20170710T14)\n•   Age
 nda: https://etherpad.opnfv.org/p/doctor_meetings\n•   IRC channel: 
 #opnfv-doctor @ Freenode (Web Chat)\n•   To join: https://global.got
 omeeting.com/join/391235029\n•   You can also dial in using your pho
 ne.\n•   Access Code: 819-733-085\n\n•   United States +1 (312
 ) 757-3126\n•   Australia +61 2 8355 1040\n•   Austria +43 7 2
 088 0034\n•   Belgium +32 (0) 28 93 7018\n•   Canada +1 (647) 
 497-9350\n•   Denmark +45 69 91 88 64\n•   Finland +358 (0) 92
 3 17 0568\n•   France +33 (0) 170 950 592\n•   Germany +49 (0)
  692 5736 7211\n•   Ireland +353 (0) 15 360 728\n•   Italy +39
  0 247 92 13 01\n•   Netherlands +31 (0) 208 080 219\n•   New 
 Zealand +64 9 280 6302\n•   Norway +47 75 80 32 07\n•   Spain 
 +34 911 82 9906\n•   Sweden +46 (0) 853 527 836\n•   Switzerla
 nd +41 (0) 435 0167 13\n•   United Kingdom +44 (0) 330 221 0086\n\n\
 nThanks\,\nThe OPNFV Doctor team\n\n\n
SUMMARY;LANGUAGE=ja-JP:Canceled: OPNFV Doctor weekly meeting
DTSTART;TZID=UTC:20171016T14
DTEND;TZID=UTC:20171016T15
UID:04008200E00074C5B7101A82E008203C9B517AF9D201000
 01000D19B88DBBFD0654880BA067256A93CE5
RECURRENCE-ID;TZID=UTC:20171016T14
CLASS:PUBLIC
PRIORITY:1
DTSTAMP:20171016T135219Z
TRANSP:OPAQUE
STATUS:CANCELLED
SEQUENCE:1
LOCATION;LANGUAGE=ja-JP:GoToMeeting
X-MICROSOFT-CDO-APPT-SEQUENCE:1
X-MICROSOFT-CDO-OWNERAPPTID:2074769377
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:2
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-DISALLOW-COUNTER:TRUE
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] [Infra] Infra WG Weekly Meeting Minutes - Oct. 9th

[Julien]

Hi David,

I agree your comments about net_config in [2]. Before my holiday maybe I
make a mistake that I think IDF is used for infrastructure network
descriptor.
For Jobs naming, I think in Kubernetes, we still need to resolve the usage
of network and storage, while these features are not well supported in the
Kubernetes community. Control is equivalent to Master, and Minion is
equivalent to Minion. It is difficult to define one set of names to meet
all the requirement. If someday VMware or HyperV is introduced into the
community as VIM, the names are meaningful to the new VIMs?


于2017年10月16日周一 下午4:26写道：

> Hi everyone,
>
> I agree that the PDF/IDF definitions must be fixed ASAP.
>
>- *About net_config in IDF*: I think it is a bad idea. As i answer in
>the patch #42233 [2], if the L3 network is configured in the infra
>(firewall, router, ...), and not configurable by the installer, it must
>stay in the PDF. If the PDF leaves an empty L3 network section, it could be
>fixed by the installer, and configured in the IDF.
>- *About net_config as proposed by **Guillermo Herrero in #42893 [1]:*
>+1 with an official naming less openstack 'like'. For a better
>understanding and writing by infra ops, can we authorize comments
>describing what is this network in simple name (and openstack 'like' naming
>if the author like it)? We must consider that ops may not use the same
>convention in the data center, and pdf writting must not be painful.
>- *Jobs naming: *Today, jobs in IDF are also openstack centric and can
>only describe a ha or noha mode, but not both, I propose in #42233[2] that
>we use 'infra', 'worker' and 'infra_or_worker' as naming for main node's
>job. This will let SDF file describing what is the mapping  to openstack,
>k8s or any other vim naming.
>- *storage definition in shared IDF part [3]*: Julien propose to add
>the storage definition in IDF, I agree, but it must be consolidated. I will
>comment in the patch
>
> BR
>
> David
>
> [1] https://gerrit.opnfv.org/gerrit/#/c/42893
> 
> 
> [2]
> https://gerrit.opnfv.org/gerrit/#/c/42233
> 
>
> [3]
> https://gerrit.opnfv.org/gerrit/#/c/44603/1/labs/att/idf-pod1.yaml
> 
>
>
> --
> David BLAISONNEAU
> NFV platforms DevOPS - OPNFV contributor
> Orange - IMT / OLN / CNC / NCA / SINA
>
> tel: +33 (0)2 96 07 27 93 <+33%202%2096%2007%2027%2093>
> email: david.blaisonn...@orange.com
> 2, avenue Pierre Marzin 22307 LANNION Cedex - France
>
> Le 16/10/2017 à 02:25, Julien a écrit :
>
> Hi Alex,
>
> It's a great news.
> 2 PODs in our lab reserved for MCP are blocked to deploy in master branch.
> Can you give me a PDF/IDF link which are used now, then we will submit
> PDF/IDF patches according to your version.
>
> For **net_config**, I personally suggest to move it to IDF and get the
> template/format approved ASSP, for it is really important to us.
>
> BR/Julien
>
> Alexandru Avadanii 于2017年10月15日周日 下午9:44写道：
>
>> Hi,
>>
>> Fuel has been using PDF and IDF for weeks now.
>>
>> We still rely on net_config, which is out of spec, to map between PDF
>> networks and the network role within the installer.
>>
>> Apart from net_config, we still need to sort out the mapping between
>> interfaces indexes in PDF and the interface names inside OS (e.g. iface 0 =
>> eno1, iface 2 = enp1s0f1).
>>
>>
>>
>> For net_config, Guillermo proposed an alternative as a comment in [1],
>> which imo is closer to the hardware view of the setup (especially the
>> port_matrix part).
>>
>> For iface name mapping, we will probably add it to IDF as a Fuel-specific
>> section for now (no PoC proposed yet).
>>
>>
>>
>> BR,
>>
>> Alex
>>
>>
>>
>> [1] https://gerrit.opnfv.org/gerrit/#/c/42893/6/labs/lf/pod4.yaml
>>
>>
>>
>>
>>
>> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
>> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Julien
>> *Sent:* Sunday, October 15, 2017 12:38 PM
>> *To:* Jack Morgan; opnfv-tech-discuss
>> *Subject:* Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly Meeting
>> Minutes - Oct. 9th
>>
>>
>>
>> Hi Jack and Infra team:
>>
>>
>>
>> This week I have a chance to directly discuss with installer team: Apex
>> and Compass. I still can not contact Joid.
>>
>>
>>
>> This is the status of PDF in each installer:
>>
>>
>>
>> Apex: Not started, won't support in E release, and I have submitted a
>> Jira ticket in Apex.
>>
>> Compass: Not started, and plan to support in F release
>>
>> Daisy: PDF is supported and used in CI PODs for deployment, while IDF is
>> not used for now
>>
>> Fuel: Started, not 

Re: [opnfv-tech-discuss] 答复: [opnfv-tsc] [release] Intent to Participate in "F" Release

[Michael Polenchuk]

Hi,

The Fuel@OPNFV project intends to participate in the OPNFV Fraser release.



> Today marks the opening of the intent-to-participate window for the "F"
> release (i.e. MS0).  Please find the procedure here
> .
> The window closes as of MS1 on Nov 3.
>
>
>
>
>
>


-- 
  Michael Polenchuk
  Private Cloud / Mirantis Inc.
___
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][ovsnfv] Disabling RPM builds in ovsnfv

[Thomas F Herbert]

On 10/16/2017 03:36 AM, Fatih Degirmenci wrote:


Hi Thomas,

The change below disables daily jobs. If you think you will never need 
these jobs, we can remove them completely.


https://gerrit.opnfv.org/gerrit/#/c/45181/

A related question; are packages for debian built somewhere?

I am assuming that they are built as part of the downstream Ubuntu 
distro but I am less familiar with that distro.


/Fatih

*From: * on behalf of 
Thomas F Herbert 

*Date: *Sunday, 15 October 2017 at 16:55
*To: *"opnfv-tech-discuss@lists.opnfv.org" 

*Subject: *[opnfv-tech-discuss] [releng][ovsnfv] Disabling RPM builds 
in ovsnfv


Question about best way to disable RPM builds in ovsnfv

In the August ovsnfv meeting we agreed to disable the building of OVS 
and DPDK RPM artifacts within the ovsnfv project as this effort is 
redundant with OVS RPMs found in downstream Centos repos.


Having received no negative public comments,  we merged a local patch 
to ovsnfv.


However, we are still getting build errors in Euphrates daily builds: 
https://build.opnfv.org/ci/job/ovsnfv-daily-euphrates/11/console


Do we need to cherry-pick that patch to a different patch or should 
the disable of ovsnfv builds be done with a patch releng?


--Tom

--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*



--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [docs] Fuel and Armband merged documentation

[Sofia Wallin]

Hi Alex,
I think the best solution is to remove the document links for Armband on 
docs.opnfv.org (or have them linked to Fuel documentation).
But keep the docs directory in your repo if things would change in the future.

//Sofia

From: Raymond Paik 
Date: Monday, 16 October 2017 at 05:26
To: Alexandru Avadanii 
Cc: Sofia Wallin , "dmcbr...@linuxfoundation.org" 
, OPNFV , 
Cristina Pauna , Bob Monkman 
Subject: Re: [docs] Fuel and Armband merged documentation

Hi Alex,

I think it makes sense for Armband team to have a separate documentation if you 
are going have support of other installers (e.g. Apex or JOID) in the future

I agree that replicating docs is wasteful, but do you think this would continue 
beyond Euphrates?

Thanks,

Ray

On Sunday, October 15, 2017, Alexandru Avadanii 
> wrote:
Hi,
During the E release cycle, Fuel and Armband projects merged their 
documentation(s).
Currently, the contents of Fuel's 'docs/' dir describe usage for both 
architecture.
To keep the old behavior unchanged, we duplicated that docs dir in Armband for 
now.

Going forward, I think building the same documentation twice is wasteful and 
unnecessary.
How do you think we should proceed in this case?

We can agree that Armband project won't publish any docs going further, and 
just remove the docs dir from our repo.
Or we can add a stub pointing to the Fuel project.

Please let us know what you think.

Thank you,
Alex
___
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] Infra WG Weekly Meeting Minutes - Oct. 9th

[david.blaisonneau]

Hi everyone,

I agree that the PDF/IDF definitions must be fixed ASAP.

 * *About net_config in IDF*: I think it is a bad idea. As i answer in
   the patch #42233 [2], if the L3 network is configured in the infra
   (firewall, router, ...), and not configurable by the installer, it
   must stay in the PDF. If the PDF leaves an empty L3 network section,
   it could be fixed by the installer, and configured in the IDF.
 * *About net_config as proposed by **Guillermo Herrero in #42893 [1]:*
   +1 with an official naming less openstack 'like'. For a better
   understanding and writing by infra ops, can we authorize comments
   describing what is this network in simple name (and openstack 'like'
   naming if the author like it)? We must consider that ops may not use
   the same convention in the data center, and pdf writting must not be
   painful.
 * *Jobs naming: *Today, jobs in IDF are also openstack centric and can
   only describe a ha or noha mode, but not both, I propose in
   #42233[2] that we use 'infra', 'worker' and 'infra_or_worker' as
   naming for main node's job. This will let SDF file describing what
   is the mapping  to openstack, k8s or any other vim naming.
 * *storage definition in shared IDF part [3]*: Julien propose to add
   the storage definition in IDF, I agree, but it must be consolidated.
   I will comment in the patch

BR

David

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

[2] 
https://gerrit.opnfv.org/gerrit/#/c/42233 



[3] 
https://gerrit.opnfv.org/gerrit/#/c/44603/1/labs/att/idf-pod1.yaml




--
David BLAISONNEAU
NFV platforms DevOPS - OPNFV contributor
Orange - IMT / OLN / CNC / NCA / SINA

tel: +33 (0)2 96 07 27 93
email: david.blaisonn...@orange.com
2, avenue Pierre Marzin 22307 LANNION Cedex - France

Le 16/10/2017 à 02:25, Julien a écrit :

Hi Alex,

It's a great news.
2 PODs in our lab reserved for MCP are blocked to deploy in master 
branch. Can you give me a PDF/IDF link which are used now, then we 
will submit PDF/IDF patches according to your version.


For **net_config**, I personally suggest to move it to IDF and get the 
template/format approved ASSP, for it is really important to us.


BR/Julien

Alexandru Avadanii >于2017年10月15日周日 下午9:44写道：


Hi,

Fuel has been using PDF and IDF for weeks now.

We still rely on net_config, which is out of spec, to map between
PDF networks and the network role within the installer.

Apart from net_config, we still need to sort out the mapping
between interfaces indexes in PDF and the interface names inside
OS (e.g. iface 0 = eno1, iface 2 = enp1s0f1).

For net_config, Guillermo proposed an alternative as a comment in
[1], which imo is closer to the hardware view of the setup
(especially the port_matrix part).

For iface name mapping, we will probably add it to IDF as a
Fuel-specific section for now (no PoC proposed yet).

BR,

Alex

[1] https://gerrit.opnfv.org/gerrit/#/c/42893/6/labs/lf/pod4.yaml

*From:*opnfv-tech-discuss-boun...@lists.opnfv.org

[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org
] *On Behalf Of
*Julien
*Sent:* Sunday, October 15, 2017 12:38 PM
*To:* Jack Morgan; opnfv-tech-discuss
*Subject:* Re: [opnfv-tech-discuss] [Infra] Infra WG Weekly
Meeting Minutes - Oct. 9th

Hi Jack and Infra team:

This week I have a chance to directly discuss with installer team:
Apex and Compass. I still can not contact Joid.

This is the status of PDF in each installer:

Apex: Not started, won't support in E release, and I have
submitted a Jira ticket in Apex.

Compass: Not started, and plan to support in F release

Daisy: PDF is supported and used in CI PODs for deployment, while
IDF is not used for now

Fuel: Started, not finished yet

Joid: No response in email and IRC(#opnfv-joid)

I would like to suggest to clear PDF/IDF patches in gerrit, let's
make an acceptable template and update them in the future, then
the lab owners can submit their PDF/IDF and used for deployment.

BR/Julien

Jack Morgan >于2017年10月10日周二 上午12:38写道：


October 9th

*Agenda:*

1.Status update on PDF

·complete discussion from last week as this is a deliverable
for Euphrates release

2.LaaS and Dashboard integration Lincoln Lavoie

[opnfv-tech-discuss] Canceled: [barometer] Weekly Call

[Tahhan, Maryam]

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T01
TZOFFSETFROM:+
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Tahhan, Maryam":MAILTO:maryam.tah...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN=opnfv-tec
 h-disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Power, Da
 mien":MAILTO:damien.po...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Mcmahon, 
 Tony B":MAILTO:tony.b.mcma...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Campbell,
  Wesley":MAILTO:wesley.campb...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Ray, Bj":M
 AILTO:bj@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Duignan, 
 Andrew":MAILTO:andrew.duig...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'Parker, 
 Daniel'":MAILTO:daniel.par...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Foley, Em
 ma L":MAILTO:emma.l.fo...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Pavan Gu
 pta':MAILTO:pavan.gu...@calsoftinc.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Mario To
 rrecillas Rodriguez':MAILTO:mario.rodrig...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Chornyi, 
 TarasX":MAILTO:tarasx.chor...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'GUPTA, A
 LOK'":MAILTO:ag1...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'MORTON, 
 ALFRED C (AL)'":MAILTO:acmor...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Lawrence
  Lamers':MAILTO:ljlam...@vmware.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Shobhan 
 AyyadevaraSesha (sayyadev)':MAILTO:sayya...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Seiler, G
 lenn (Wind River)":MAILTO:glenn.sei...@windriver.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Scott Ma
 nsfield':MAILTO:scott.mansfi...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'Bernier,
  Daniel (520165)'":MAILTO:daniel.bern...@bell.ca
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Canio Ci
 llis':MAILTO:canio.cil...@de.ibm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'Tomasini
 , Lorenzo'":MAILTO:lorenzo.tomas...@fokus.fraunhofer.de
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Srinivas
 a Chaganti':MAILTO:schaga...@versa-networks.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'Laporte,
  Laurent [CTO]'":MAILTO:laurent.lapo...@sprint.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Ola Lilj
 edahl':MAILTO:ola.liljed...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'Jaggi, M
 anish'":MAILTO:manish.ja...@cavium.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Gabor Ha
 lász':MAILTO:gabor.hal...@ericsson.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='杨艳':
 MAILTO:yangya...@chinamobile.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'SULLIVAN
 , BRYAN L'":MAILTO:bs3...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Andrew V
 eitch':MAILTO:andrew.vei...@netcracker.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'DRUTA, D
 AN'":MAILTO:dd5...@att.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Javier A
 rauz':MAILTO:j.javier.ar...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="'Sen, Pro
 dip'":MAILTO:prodip@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Alan McN
 amee':MAILTO:alan...@openet.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Kedalagud
 de, Meghashree Dattatri":MAILTO:meghashree.dattatri.kedalagu...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Gherghe, 
 Calin":MAILTO:calin.gher...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Murthy, K
 rishna J":MAILTO:krishna.j.mur...@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='Pierre L
 ynch':MAILTO:ply...@ixiacom.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN="Sun, Ning"
 :MAILTO:ning@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE;CN='rgrigar@
 

Re: [opnfv-tech-discuss] [releng][ovsnfv] Disabling RPM builds in ovsnfv

[Fatih Degirmenci]

Hi Thomas,

The change below disables daily jobs. If you think you will never need these 
jobs, we can remove them completely.

https://gerrit.opnfv.org/gerrit/#/c/45181/

A related question; are packages for debian built somewhere?

/Fatih

From:  on behalf of Thomas F 
Herbert 
Date: Sunday, 15 October 2017 at 16:55
To: "opnfv-tech-discuss@lists.opnfv.org" 
Subject: [opnfv-tech-discuss] [releng][ovsnfv] Disabling RPM builds in ovsnfv


Question about best way to disable RPM builds in ovsnfv

In the August ovsnfv meeting we agreed to disable the building of OVS and DPDK 
RPM artifacts within the ovsnfv project as this effort is redundant with OVS 
RPMs found in downstream Centos repos.

Having received no negative public comments,  we merged a local patch to ovsnfv.

However, we are still getting build errors in Euphrates daily builds: 
https://build.opnfv.org/ci/job/ovsnfv-daily-euphrates/11/console

Do we need to cherry-pick that patch to a different patch or should the disable 
of ovsnfv builds be done with a patch releng?

--Tom
--
Thomas F Herbert
NFV and Fast Data Planes
Office of Technology
Red Hat
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Auto Project Meeting 10/16/2017 - Auto - OPNFV Wiki

[Tina Tsou]

Dear all,

Meeting agenda of Auto weekly meeting on Monday 10/16 is posted.

https://wiki.opnfv.org/pages/viewpage.action?pageId=13206017

Talk to you soon.


Thank you,
Tina
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss