Re: [opnfv-tech-discuss] [Fuel] Tacker fuel plugin error with Fuel 10 deployment

[Veena Lingadahalli]

Hi Tim,

Tacker fuel-plugin used in Colorado release is based on your repo [1]. I
see that there are some code changes in tacker newton as part of the
implementation of bp tacker-vnffg [2]. So do you have any plans to rebase
the SFC_colorado changes to newton? How should we proceed about adding
tacker-plugin in Fuel 10.?


[1] https://github.com/trozet/tacker/tree/SFC_colorado
[2] https://blueprints.launchpad.net/tacker/+spec/tacker-vnffg

Thanks,
-Veena


On Tue, Jan 31, 2017 at 7:34 AM, Serg Melikyan 
wrote:

> Hi Georgios,
>
> Aimee was asking same question couple of weeks ago, and I had added
> you in the thread as person originally enabled Tacker in Colorado
> release.
>
> > Possibly this is because in Fuel 10 we are using Ubuntu 16.04 with
> systemd instead of 14.04 with upstart?
> Seems like so.
>
> >Will fuel-plugin-tacker be updated for Fuel 10?
> It's pretty late in the cycle, so the only way Tacker might be added
> to Fuel is through feature freeze exception and fixing it quickly. Do
> you want to work on that?
>
>
> On Mon, Jan 30, 2017 at 12:33 AM, Paraskevopoulos Georgios
>  wrote:
> > Hi all,
> >
> >
> >
> > I’m trying to deploy Fuel 10 with Tacker plugin enabled and I’m getting
> the
> > following error:
> >
> > (/Stage[main]/Tacker::Service/Service[tacker]) Provider upstart is not
> > functional on this host
> >
> >
> >
> > Possibly this is because in Fuel 10 we are using Ubuntu 16.04 with
> systemd
> > instead of 14.04 with upstart?
> >
> > Will fuel-plugin-tacker be updated for Fuel 10?
> >
> >
> >
> > Thanks,
> >
> > George
> >
> >
> >
> >
> >
> >
> >
> > George Paraskevopoulos
> >
> > Software Engineer (SDN/NFV), INTRACOM-TELECOM
> >
> >  + 30 210 667 7689
> >
> >  geo...@intracom-telecom.com
> >
> >  19.7 km Markopoulou Ave 19002 Peania, Athens, Greece
> >
> >
> >
> > The information in this e-mail message and any attachments are intended
> only
> > for the individual or entity to whom it is addressed and may be
> > confidential. If you have received this transmission in error, and you
> are
> > not an intended recipient, be aware that any copying, disclosure,
> > distribution or use of this transmission or its contents is prohibited.
> > INTRACOM TELECOM and the sender accept no liability for any loss,
> disruption
> > or damage to your data or computer system that may occur while using data
> > contained in, or transmitted with, this email. Views or opinions
> expressed
> > in this message may be those of the author and may not necessarily
> represent
> > those of INTRACOM TELECOM.
> >
> >
> >
> >
> > ___
> > opnfv-tech-discuss mailing list
> > opnfv-tech-discuss@lists.opnfv.org
> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
> >
>
>
>
> --
> Serg Melikyan, Development Manager at Mirantis, Inc.
> http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
>
___
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] Tacker fuel plugin error with Fuel 10 deployment

[Serg Melikyan]

Hi Georgios,

Aimee was asking same question couple of weeks ago, and I had added
you in the thread as person originally enabled Tacker in Colorado
release.

> Possibly this is because in Fuel 10 we are using Ubuntu 16.04 with systemd 
> instead of 14.04 with upstart?
Seems like so.

>Will fuel-plugin-tacker be updated for Fuel 10?
It's pretty late in the cycle, so the only way Tacker might be added
to Fuel is through feature freeze exception and fixing it quickly. Do
you want to work on that?


On Mon, Jan 30, 2017 at 12:33 AM, Paraskevopoulos Georgios
 wrote:
> Hi all,
>
>
>
> I’m trying to deploy Fuel 10 with Tacker plugin enabled and I’m getting the
> following error:
>
> (/Stage[main]/Tacker::Service/Service[tacker]) Provider upstart is not
> functional on this host
>
>
>
> Possibly this is because in Fuel 10 we are using Ubuntu 16.04 with systemd
> instead of 14.04 with upstart?
>
> Will fuel-plugin-tacker be updated for Fuel 10?
>
>
>
> Thanks,
>
> George
>
>
>
>
>
>
>
> George Paraskevopoulos
>
> Software Engineer (SDN/NFV), INTRACOM-TELECOM
>
>  + 30 210 667 7689
>
>  geo...@intracom-telecom.com
>
>  19.7 km Markopoulou Ave 19002 Peania, Athens, Greece
>
>
>
> The information in this e-mail message and any attachments are intended only
> for the individual or entity to whom it is addressed and may be
> confidential. If you have received this transmission in error, and you are
> not an intended recipient, be aware that any copying, disclosure,
> distribution or use of this transmission or its contents is prohibited.
> INTRACOM TELECOM and the sender accept no liability for any loss, disruption
> or damage to your data or computer system that may occur while using data
> contained in, or transmitted with, this email. Views or opinions expressed
> in this message may be those of the author and may not necessarily represent
> those of INTRACOM TELECOM.
>
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>



-- 
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Apex] ScaleIO puppet modules

[Beierl, Mark]

Hello, Tim.

Adding Andrey's EMC address here...

I'd like to look into getting the blueprint started and seeing what can be done 
upstream for this.  Please do let me know how to get started on that :)

Regards,
Mark

Mark Beierl
Advisory Solutions Architect
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

> On Jan 24, 2017, at 17:40, Tim Rozet  wrote:
> 
> Hi Mark,
> I had a chance to go through the repo.  Much of it looks like it could be 
> translated into TripleO heat/puppet for Apex and TripleO upstream.  The 
> design of how Andrey is installing will need to change though.  What he is 
> doing right now is using ExtraConfig to initiate calls to bash scripts which 
> end up calling puppet to deploy scaleio.  The proper way is to add real 
> ScaleIO services to OOO so that heat templates call the puppet directly to 
> deploy scaleio, and not initiate bash scripts.
> 
> If you want to tackle adding this to TripleO I can help guide you.  We would 
> need a blueprint and I can walk you through how it all works.  Otherwise if 
> you want the Apex team to handle adding ScaleIO I think we will need to wait 
> until after Danube as we are already overloaded with features right now.  
> Maybe Andrey would want to contribute as well? (cc'ed)
> 
> Thanks,
> 
> Tim Rozet
> Red Hat SDN Team
> 
> - Original Message -
> From: "Mark Beierl" 
> To: "Tim Rozet" 
> Cc: opnfv-tech-discuss@lists.opnfv.org
> Sent: Monday, January 23, 2017 5:43:46 PM
> Subject: Re: [opnfv-tech-discuss] [Apex] ScaleIO puppet modules
> 
> Hey, Tim.
> 
> The original repo has been moving forward: 
> https://github.com/codedellemc/puppet-scaleio
> 
> Not sure what changes you needed to make, or if they have been superseded by 
> changes in the codedellemc repo.  It now claims to support CentOS 6/7, so 
> maybe?
> 
> The other repo (https://github.com/cloudscaling/redhat-kvm) has a bunch of 
> overcloud scripts that appear to pull in the correct puppet modules and 
> configure them.  I wonder if anything from those scripts can be used directly 
> in Apex?
> 
> Regards,
> Mark
> 
> Mark Beierl
> Advisory Solutions Architect
> Dell EMC | Office of the CTO
> mobile +1 613 314 8106
> mark.bei...@dell.com
> 
>> On Jan 23, 2017, at 17:30, Tim Rozet  wrote:
>> 
>> Hi Mark,
>> Back at the previous plugfest in Colorado I had modified scaleio puppet 
>> module to work with Apex as a POC.  Not sure if they still work or not, but 
>> I never had time to go back and integrate into Apex upstream:
>> 
>> https://github.com/trozet/puppet-scaleio/tree/rpm_support
>> 
>> Tim Rozet
>> Red Hat SDN Team
>> 
>> - Original Message -
>> From: "Mark Beierl" 
>> To: opnfv-tech-discuss@lists.opnfv.org
>> Sent: Monday, January 23, 2017 12:38:08 PM
>> Subject: [opnfv-tech-discuss] [Apex] ScaleIO puppet modules
>> 
>> Hello, Apex team, but probably mainly Dan/Tim. 
>> 
>> At the plugfest, Dan and I chatted briefly about getting ScaleIO puppet 
>> modules integrated with Apex. I have noticed that some work has been done by 
>> the ScaleIO team in a side repo [1]. Does any of this look like it would be 
>> reusable for Apex? 
>> 
>> [1] https://github.com/cloudscaling/redhat-kvm 
>> 
>> Regards, 
>> Mark 
>> 
>> Mark Beierl 
>> Advisory Solutions Architect 
>> Dell EMC | Office of the CTO 
>> mobile +1 613 314 8106 
>> mark.bei...@dell.com 
>> 
>> 
>> ___
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
> 

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

[opnfv-tech-discuss] Models Weekly Meeting A

[SULLIVAN, BRYAN L]

I am traveling today so no Models meeting. Still working on getting an OPNFV 
Danube deploy going, as pre-req to completing Danube work. Any offers of 
resources (PODs, dev support) are appreciated.

Models Weekly Meeting A
Scheduled: Monday, Jan 30, 2017 from 8:00 AM to 9:00 AM
Location: https://global.gotomeeting.com/join/865421325
Invitees: 'Trinath Somanchi'‌, 'Zhangyi (ZHANG YI, SCC)'‌, 'Ramia, Kannan 
Babu'‌, Alan McNamee‌, Daniel Smith‌, 'Tal Barenboim'‌, MORTON JR., AL‌, Elzur, 
Uri‌, 'Seiler, Glenn'‌, 'Vandris, Steve'‌, 'Ulas Kozat'‌, Pauls, Michael‌, 
'Vul, Alex'‌, 'Gabor Halász'‌, Edna Ganon‌, 
'a...@gigaspaces.com'‌, 'Henry Fourie'‌, 'S, 
Deepak'‌, 'Dan Westerberg'‌, Charles Hale‌, 'Kuppuswamy, Prabu'‌, 
'opnfv-tech-discuss@lists.opnfv.org'‌,
 Malla, Malathi‌, 'Canio Cillis'‌, 'Lawrence Lamers'‌, 'Ahmed Elbornou 
(amaged)'‌, 'Mario Torrecillas Rodriguez'‌, Tomasini, Lorenzo‌, GUPTA, ALOK‌, 
'Andrew Veitch'‌, 'ramki_krish...@dell.com'‌, 
'Sen, Prodip'‌, Pierre Lynch‌, 'Ola Liljedahl'‌, 'yaohelan'‌, 'Shobhan 
AyyadevaraSesha (sayyadev)'‌, Reid Cheng (xincheng)‌, DRUTA, DAN‌, 'David 
Suarez Fuentes'‌, 'Randy Levensalor'


Thanks,
Bryan Sullivan | at
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

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

[Yujun Zhang]

Hi, Fatih

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

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

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

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

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

[Yujun Zhang]

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

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

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

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

> Hi,
>
>
>
> This is in our plans since last year. The idea is to come up with a common
> format to use in commit message which gets processed by the verify job,
> running the impacted scenario.
>
>
>
> Please see the first step in below section.
>
>
>
>
> https://wiki.opnfv.org/display/INF/CI+Evolution#CIEvolution-HowtheThingsFitTogether
>
>
>
> We are currently working on aligning job structures (verify and daily) and
> scope of the patchset verification for all the installers since the current
> situation is not good, some do things properly some does nothing.
>
>
>
> Here is who does what as part of patchset verification.
>
>
>
> - apex: unit test, build, virtual deploy, functest smoke test
>
> - compass: lint, virtual deploy, functest smoke test
>
> - daisy: build, virtual deploy
>
> - fuel: build
>
> - joid: nothing
>
>
>
> Apart from not reaching to this step to come up with a proposal for commit
> message, this depends on scenario consolidation/naming activity as well. We
> can hopefully start working with this after Danube.
>
>
>
> /Fatih
>
>
>
> *From: * on behalf of Yujun
> Zhang 
> *Date: *Tuesday, 24 January 2017 at 08:41
> *To: *Chigang , "opnfv-tech-discuss@lists.opnfv.org" <
> opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *Re: [opnfv-tech-discuss] [Releng/Octopus] Patch verification
> suggestion
>
>
>
> I think it is technically feasible.
>
>
>
> We added an experimental trigger for doctor project not long ago[1]. The
> trigger is similar to your requirement.
>
>
>
> [1]:
> https://gerrit.opnfv.org/gerrit/#/c/26839/4/jjb/global/releng-macros.yml
>
>
>
>
>
> On Tue, Jan 24, 2017 at 12:31 PM Chigang (Justin) 
> 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] [ovsnfv] Discussion points (outlier) for PriPath

[Lee, Chunghan]

Hi Billy,

Thank you for the reply.
I can understand the experiment condition clearly.

>[[BO'M]] This is a valid suggestion and is worth investigating. I would like 
>to use linux tracing tools such as perf to see when or if the pmd thread in
>testpmd is de-scheculed and if so for how long. Actually I’d start by checking 
>this on the testpmd thread on the host - as this removes any doubt about
>timestamp accuracy on VMs.

Very good!
Actually, I have another suggestion
to control CPU allocation for testpmd using taskset.
In this time, we can observe the latency of
process scheduling, and compare their pattern with the outlier.
If the latency has a similar pattern,
it would be  a major cause of the outlier.

See you in the meeting.

Regards,
Chunghan Lee

--
Chunghan Lee
Cloud Network Project. Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku,
Kawasaki-shi, Kanagawa 211-8588, Japan
E-mail： lee.chung...@jp.fujitsu.com
--

From: O Mahony, Billy [mailto:billy.o.mah...@intel.com]
Sent: Monday, January 30, 2017 7:12 PM
To: Lee, Chunghan/李 忠翰; Gray, Mark D; 
therb...@redhat.com
Cc: 
opnfv-tech-discuss@lists.opnfv.org
Subject: RE: Discussion points (outlier) for PriPath

Hi Chunghan,

Some responses below.

We can also discuss at the OVS-NFV synch-up call later today.

/Billy.

From: Lee, Chunghan [mailto:lee.chung...@jp.fujitsu.com]
Sent: Monday, January 30, 2017 2:20 AM
To: O Mahony, Billy 
>; Gray, Mark D 
>; 
therb...@redhat.com
Cc: Lee, Chunghan 
>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Discussion points (outlier) for PriPath

Hi,

I considered that the reason why the outlier (such as, 120-200 or 200-400)
for Hi Pri PTP is observed with 120% tput.

There are two estimation for the outlier.

The first one is VM scheduling latency.
In this experiment, the VM is used for the measurement.
The results would be different due to the number of VMs on node.
If there are many VMs on the node and it suffers a lack of CPU resource,
the scheduling latency will be increased and it would be a major cause of the 
outlier.
Did you confirm the number of VMs in the experiment ?
[[BO'M]] There is just one  VM which is pinned to two host cores. However I 
have not isolated the those cpus so linux could decide to schedule something on 
them -  however with a lightly loaded system and 28 other cores to choose from 
I don’t think this should be an issue.

The next one is the packet processing delay of testpmd.
In my understanding, testpmd is user process on VM.
Although pmd thread forwards packets to testpmd as soon as possible,
the context switching of testpmd would be occurred by kernel.
As a result, testpmd cannot process the packets from the pmd thread as soon as 
possible.
[[BO'M]] This is a valid suggestion and is worth investigating. I would like to 
use linux tracing tools such as perf to see when or if the pmd thread in 
testpmd is de-scheculed and if so for how long. Actually I’d start by checking 
this on the testpmd thread on the host - as this removes any doubt about 
timestamp accuracy on VMs.

Please let me confirm the experiment condition without baseline again.
In the priority path, is there no queue for Hi Pri PTP?
Thus, there is only one designated queue for Lo Pri2.
The traffic of Lo Pri2 is en/dequeued on the designated queue.
There is no special function on DPDK OVS switch to process the traffic Hi Pri 
PTP.
Is it right ?
[[BO'M]] For the baseline case yes there is just one queue on all of the ports. 
(In reality the PMD polls queues not ports.) For the priority path case there 
are two queues on both the NIC ports. And the code sets up a flow-director 
filter on the NICs to assign the priority traffic to one of the queues.

Regards,
Chunghan Lee

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

[opnfv-tech-discuss] [Fuel] Tacker fuel plugin error with Fuel 10 deployment

[Paraskevopoulos Georgios]

Hi all,



I'm trying to deploy Fuel 10 with Tacker plugin enabled and I'm getting the 
following error:

(/Stage[main]/Tacker::Service/Service[tacker]) Provider upstart is not 
functional on this host



Possibly this is because in Fuel 10 we are using Ubuntu 16.04 with systemd 
instead of 14.04 with upstart?

Will fuel-plugin-tacker be updated for Fuel 10?



Thanks,

George








George Paraskevopoulos

Software Engineer (SDN/NFV), INTRACOM-TELECOM


 + 30 210 667 7689

   geo...@intracom-telecom.com


 19.7 km Markopoulou Ave 19002 Peania, Athens, Greece





The information in this e-mail message and any attachments are intended only 
for the individual or entity to whom it is addressed and may be confidential. 
If you have received this transmission in error, and you are not an intended 
recipient, be aware that any copying, disclosure, distribution or use of this 
transmission or its contents is prohibited.  INTRACOM TELECOM and the sender 
accept no liability for any loss, disruption or damage to your data or computer 
system that may occur while using data contained in, or transmitted with, this 
email. Views or opinions expressed in this message may be those of the author 
and may not necessarily represent those of INTRACOM TELECOM.





___
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]L3VPN for dovetail area

[morgan.richomme]

Le 27/01/2017 à 18:49, Wenjing Chu a écrit :
>
> I agree more information is better, however it is not obvious where
> that information will come from.
>
>  
>
> -Test case run result history
>
> Do we keep records of old runs in Colorado for functest & yardsticks?
> If we do, let’s link them up.
>
> If not, we can always re-run these tests on the frozen Colorado
> release and produce these results. Are we regularly running them now?
>
> Also note, the Colorado release is frozen, test cases are frozen, so
> this spot info may not be as relevant as it appears. However I agree
> it’ll become more informational and valuable with longer history.
>
>  
>
http://testresults.opnfv.org/reporting/functest/release/colorado/index-status-apex.html
no run on colorado since more than 10 days
ressources allocated to Danube/Master

all previous tests stored in the DB
http://testresults.opnfv.org/test/api/v1/results?project=yardstick=10=colorado
http://testresults.opnfv.org/test/api/v1/results?case=tempest_smoke_serial=10=colorado



> -Source code of test cases
>
> Do we have a link to source code repos in openstack, ODL/ONOS, etc
> upstreams?
>
> Can someone involved in CI/CD pitch in?
>
??
for Functest we may find such links in the build of the docker file
https://git.opnfv.org/functest/tree/docker/Dockerfile?h=stable/colorado

you wil find the reference to OPNFV repos and upstream repos used for
the tests

|# OpenStack repositories RUN git clone --depth 1 -b $OPENSTACK_TAG
https://github.com/openstack/networking-bgpvpn ${repos_dir}/bgpvpn RUN
git clone --depth 1 -b $KINGBIRD_TAG
https://github.com/openstack/kingbird.git ${repos_dir}/kingbird RUN git
clone --depth 1 -b $RALLY_TAG https://github.com/openstack/rally.git
${repos_dir}/rally RUN git clone --depth 1 -b $TEMPEST_TAG
https://github.com/openstack/tempest.git ${repos_dir}/tempest |

Note that a catalog web site is planned for Danube

/Morgan

>  
>
> Wenjing
>
>  
>
> *From:*SULLIVAN, BRYAN L [mailto:bs3...@att.com]
> *Sent:* Friday, January 27, 2017 6:20 AM
> *To:* Wenjing Chu ; Pierre Lynch
> ; Jose Lausuch 
> *Cc:* TECH-DISCUSS OPNFV 
> *Subject:* RE: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area
>
>  
>
> More inline.
>
>  
>
> Thanks,
>
> Bryan Sullivan | AT
>
>  
>
> *From:*Wenjing Chu [mailto:wenjing@huawei.com]
> *Sent:* Thursday, January 26, 2017 12:30 PM
> *To:* SULLIVAN, BRYAN L >;
> Pierre Lynch >; Jose
> Lausuch >
> *Cc:* TECH-DISCUSS OPNFV  >
> *Subject:* RE: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area
>
>  
>
> Hi Bryan
>
>  
>
> Hope my inline responses are still readable …
>
> Thanks.
>
>  
>
> Wenjing
>
>  
>
> *From:*SULLIVAN, BRYAN L [mailto:bs3...@att.com]
> *Sent:* Thursday, January 26, 2017 8:29 AM
> *To:* Wenjing Chu  >; Pierre Lynch  >; Jose Lausuch  >
> *Cc:* TECH-DISCUSS OPNFV  >
> *Subject:* RE: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area
>
>  
>
> More comments inline.
>
>  
>
> Thanks,
>
> Bryan Sullivan | AT
>
>  
>
> *From:*Wenjing Chu [mailto:wenjing@huawei.com]
> *Sent:* Wednesday, January 25, 2017 3:00 PM
> *To:* SULLIVAN, BRYAN L >;
> Pierre Lynch >; Jose
> Lausuch >
> *Cc:* TECH-DISCUSS OPNFV  >
> *Subject:* RE: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area
>
>  
>
> Thanks Bryan. See my response inline below.
>
>  
>
> Wenjing
>
>  
>
> *From:*SULLIVAN, BRYAN L [mailto:bs3...@att.com]
> *Sent:* Wednesday, January 25, 2017 11:32 AM
> *To:* Wenjing Chu  >; Pierre Lynch  >; Jose Lausuch  >
> *Cc:* TECH-DISCUSS OPNFV  >
> *Subject:* RE: [opnfv-tech-discuss] [dovetail]L3VPN for dovetail area
>
>  
>
> I posted some comments in gerrit. Here are the main points I think we
> need alignment on:
>
> 1)  All proposed dovetail included tests will be added one-by-one,
> in a separate commit.
>
>  
>
> Please follow the gerrit tickets below and see if you can follow
> through. Test cases are organized into two levels for convenience:
>