Re: [onap-discuss] [modeling] Network Service Descriptor model

[Xu Yang]

Hi Jessie,

Thanks for the update and explanation, it’s clear to me now.

BR,
Xu

From: jessie jewitt [mailto:jessie.jew...@oamtechnologies.com]
Sent: Saturday, August 25, 2018 12:59 AM
To: onap-discuss ; yangxu (H) 
Cc: 郭楚怡 ; denglingli ; 
zhang.maopeng1 ; zhan.jie1 
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
If I understand you correctly, you mean you are not seeing an attribute on 
the diagram that has type "ConnectivityType"? You see it in the table because 
NsVirtualLinkDesc inherits from VirtualLinkDesc which contains the attribute 
called "connectivityType" of type "ConnectivityType". I updated the diagram to 
show this inheritance relationship, so you should see it now. Let me know if 
that is satisfactory to you.
-Jessie

On Thu, Aug 23, 2018 at 7:19 PM, Xu Yang 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

Thanks for updating.
A quick comment, the diagram is too vague, would you please help update it?

BR,
Xu

From: onap-discuss@lists.onap.org 
[mailto:onap-discuss@lists.onap.org] On 
Behalf Of Jessie Jewitt
Sent: Friday, August 24, 2018 1:39 AM
To: onap-discuss 
mailto:onap-discuss@lists.onap.org>>; 
jessie.jew...@oamtechnologies.com
Cc: 郭楚怡 mailto:guoch...@chinamobile.com>>; denglingli 
mailto:denglin...@chinamobile.com>>; zhang.maopeng1 
mailto:zhang.maope...@zte.com.cn>>; zhan.jie1 
mailto:zhan.j...@zte.com.cn>>

Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

I have updated the Network Service Descriptor 

 model on the wiki based on recommendations from this team to align with R2.
Two notes:
1. NSD was missing in R2 a nsdIdentifier. This is a must have.
2. Some of the types are empty. I'll fill those in next week.

-Jessie

On Thu, Aug 23, 2018 at 9:40 AM, Jessie Jewitt 
mailto:jessie.jew...@oamtechnologies.com>> 
wrote:
Hi Xu-
Two comments:
1. I will mark association member ends and referenced classes as experimental 
and put them in the output.
2. You don't see things like ConnectivityType on the diagram because it is a 
class diagram and ConnectivityType is a datatype.

-Jessie

On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

Please see inline.

Best regards,
Xu

From: onap-discuss@lists.onap.org 
[mailto:onap-discuss@lists.onap.org] On 
Behalf Of Jessie Jewitt
Sent: Thursday, August 23, 2018 1:44 AM
To: yangxu (H) mailto:yang...@huawei.com>>
Cc: 郭楚怡 mailto:guoch...@chinamobile.com>>; 
onap-discuss mailto:onap-discuss@lists.onap.org>>; 
denglingli mailto:denglin...@chinamobile.com>>; 
zhang.maopeng1 mailto:zhang.maope...@zte.com.cn>>; 
zhan.jie1 mailto:zhan.j...@zte.com.cn>>
Subject: Re: [onap-discuss] [modeling] Network Service Descriptor model

Hi Xu-
   I hadn't seen your response when I answered Chuyi's email. Please see my 
comments embedded below...
Thanks,
Jessie

On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H) 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

In R2, we did have a call for approval for the NSD model, as shown in 
https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on that 
anymore and focus on improving the current model.
Jessie: Yes, agree

It’s true that we don’t have a UML diagram for the NSD model on the wiki page I 
give, the proposal from my side is that we create a Papyrus model for the NSD 
(as we are doing it now) and align it with the R2 wiki page, fix issues and put 
it into R3 clean model.
Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD 
model in Papyrus with the R2 model, but fix the issues and prepare this to go 
in clean. I can have it ready by next Monday, hopefully, though I won't be on 
the call.
Further improvement and alignment with ETSI specs are better to be put into R4 
as we are coming to the deadline for the final draft.
Jessie: Agree.
Regarding the issues, I think you are right the current model is not complete, 
we can either remove those attributes that are not defined or mark them as 
experimental like what we have done for the VNFD model.
Jessie: The "attributes" that are not defined are member ends of associations. 
We need to either remove the associations, or add the referenced classes in the 
model. I personally don't think it would be correct to mark them as 
"experimental" as they would be incomplete definitions. For example, you 
reference a Sapd, but don't define the Sapd class? It wouldn't be possible to 
implement something like that.
[xy] I agree, I’m suggesting either we remove those attributes/associations or 
add the referenced classes and mark those classes as “experimental”. For 
example, either we don’t have any attributes/classes called Sapd in the model, 
or we add an empty Sapd class marked as “experiment

[onap-discuss] [modeling] #modeling Modeling Subcommittee Elections Call for Self-Nominations #lfn

[Kenny Paul]

The nomination period is now over.

Your candidates are Andy Mayer and Deng Hui.

37 people responded to the poll regarding How would you like to see the Chair 
elections handled?  91.9% were in favor of Chair & Vice Chair (elected via the 
top vote getter and 1st runner up respectively)

 

I will assemble the ballots and they will be distributed shortly.

Thanks!

-kenny

 

 

From: Kenny Paul 
Date: Monday, August 20, 2018 at 1:41 PM
To: "onap-discuss@lists.onap.org" 
Subject: [modeling] #modeling Modeling Subcommittee Elections Call for 
Self-Nominations

 

As per Subcommittee Chair Elections I am officially opening the self-nomination 
period for the Modeling Subcommittee Chair elections.

The nomination period will end on Friday, Aug 24 @ 2:00 Pm Pacific

 

The members eligible to be a voting member is set to V118 of the Modeling 
Subcommittee Membership Page

I have updated that page, adding a column for Company and a column that says 
"Voting Member", and removing 3 individuals I know are no longer involved with 
ONAP.  One of them never even set up a wiki account.

 

The "Voting Member" column usage is simple. If you are the person from your 
company that will be casting the vote, then put "Yes" in that column. If not, 
leave it blank.

 

Who is eligible to Run: Subcommittee members of record (as per v118 of the wiki 
page) 

Who is eligible to Vote: Subcommittee members of record (as per v118 of the 
wiki page) AND as controlled within the context of Section 4.4.1.4 of the 
Community Document
Process:
Self-Nomination Phase
When appropriate a call for nominations will be sent by the LF to the 
appropriate distribution list, using the subcommittee's specific email tag.  
Individuals interested in running for the Subcommittee Chair position must 
reply-all to that email with your intention to run.  It is recommended that 
candidates include a biography and statement of intent on why you would be a 
good person to hold this position.

·

·
The nomination phase begins with the receipt of the announcement ( as verified 
by checking the appropriate list in groups.io )
The nomination phase ends four (4) full business days after the announcement in 
the same time zone the poll was initiated from
Election Phase
A Condorcet election will be held using the CIVS voting system.  All 
subcommittee members (as indicated above) will receive an invitation to vote.

·

·
The election phase will begin on with the distribution of the CIVS poll via 
email
The election phase will end four (4) full business days later in the same time 
zone the poll was initiated from
 

Election Results 

·

·
The individual receiving the highest number of votes from all votes cast shall 
be declared the winner.
The LF will update the Voting Results History page with their name, date, and 
link to the publicly viewable CIVS results and send an email to the 
distribution list and to onap-tsc
NOTE For the modeling Subcommittee, the decision was made that the Top @ 
finishers in the election would be 
 

 

Best Regards, 
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12061): https://lists.onap.org/g/onap-discuss/message/12061
Mute This Topic: https://lists.onap.org/mt/24948382/21656
Mute #modeling: https://lists.onap.org/mk?hashtag=modeling&subid=2740164
Mute #lfn: https://lists.onap.org/mk?hashtag=lfn&subid=2740164
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [ONAP Helpdesk #60122] Missing docker images

[Gary Wu]

I don't have a record; probably need the respective teams to chime in.

Thanks,
Gary

-Original Message-
From: Jessica Wagantall via RT [mailto:onap-helpd...@rt.linuxfoundation.org] 
Sent: Friday, August 24, 2018 1:23 PM
To: Gary Wu 
Cc: onap-discuss@lists.onap.org
Subject: [ONAP Helpdesk #60122] Missing docker images

Is there a way we can know how old were these images?

We still have in place the task that cleans images after they were created
25 days ago. 

Thanks!
Jess

On Fri Aug 24 13:20:55 2018, gary.i...@huawei.com wrote:
> Hi helpdesk,
> 
> Currently the following docker images have gone missing:
> 
> onap/activity-spec:1.3.0 (note that this was NOT a released image) 
> onap/multicloud/vio:1.2.0-STAGING
> 
> Can you take a look?
> 
> Thanks,
> Gary
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12060): https://lists.onap.org/g/onap-discuss/message/12060
Mute This Topic: https://lists.onap.org/mt/24948060/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [integration]Manifest Issue

[Gary Wu]

Looks like some docker images are disappearing from nexus3 again.  I’ve logged 
helpdesk ticket 60122 for this.

Thanks,
Gary

From: fu.guangr...@zte.com.cn [mailto:fu.guangr...@zte.com.cn]
Sent: Friday, August 24, 2018 1:19 AM
To: Gary Wu 
Cc: onap-discuss@lists.onap.org
Subject: [integration]Manifest Issue


Hi Gary,



I updated the manifest files a little bit and submitted them 
(https://gerrit.onap.org/r/#/c/61747/). But the Jenkins verification job keeps 
failing. The reason is that one component is missing from the nexus repo.



[ERROR] onap/activity-spec:1.3.0 not found



Since it's not our project, I've no idea on how to deal with that.



Could you please help to take a look at it?



Thanks,

Guangrong









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12059): https://lists.onap.org/g/onap-discuss/message/12059
Mute This Topic: https://lists.onap.org/mt/24942770/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [ONAP] E2E VNF functional testing

[Christopher Donley]

Morgan,

See in-line.

Chris

From: "morgan.richo...@orange.com" 
mailto:morgan.richo...@orange.com>>
Date: Friday, August 24, 2018 at 8:12 AM
To: Yunxia Chen mailto:helen.c...@huawei.com>>, 
"ran.pol...@amdocs.com" 
mailto:ran.pol...@amdocs.com>>, Chris Donley 
mailto:christopher.don...@huawei.com>>, 
"moshe...@amdocs.com" 
mailto:moshe...@amdocs.com>>, Gary Wu 
mailto:gary.i...@huawei.com>>, 
"kevin@att.com" 
mailto:kevin@att.com>>, "Yang Xu (Yang, Fixed Network)" 
mailto:yang@huawei.com>>, 
"plata...@research.att.com" 
mailto:plata...@research.att.com>>, 
"bf1...@att.com" mailto:bf1...@att.com>>
Cc: DEBEAU Eric IMT/OLN 
mailto:eric.deb...@orange.com>>, 
"onap-discuss@lists.onap.org" 
mailto:onap-discuss@lists.onap.org>>
Subject: Re: [ONAP] E2E VNF functional testing

Hi Chris

thanks for the reply
comments, answers and questions in the mail

/Morgan

Le jeudi 23 août 2018 à 20:46 +, Christopher Donley (Chris) a écrit :
Most of your wishlist items are in the VNFSDK roadmap.

ok
does it mean that
- Testsuite deals with tests of ONAP (which may include canonical VMs) as a 
solution
- VNFSDK deals with ONAP compatible VNF tests.
yes
VNFSDK name was a bit misleading for me as the goal is not to provide a toolkit 
to develop but to validate and integrate in CI/CD chains.
It's a long story dating back to its origination in Open-O…
However the description of the project is clear :)"build an ecosystem for ONAP 
compatible VNFs by developing tools for vendor CI/CD toolchains and developing 
validation and testing tools"

Does it mean that you plan to develop VNF, leverage OPNFV VNF project, develop 
tests in addition of testing tools?
We're not developing the VNFs, but we are developing packaging tools in 
addition to the tests.  We haven't been working with OPNFV VNFs.

#3 on your list is already part of VNFSDK (dovetail-integration repo).

ok
I had a quick loop, it looks like python + yaml templating but covers the same 
areas than robot + python extention script from testsuite
it is already dockerized an inherited stuff from dovetail
I need to test it :)


Regarding #2, we have been focusing on packaging tests, but recently updated 
the functional tests (functest repo) in Beijing.  Lifecycle tests have been 
dormant since OPEN-O, but we can resurrect as soon as we have resources.  One 
prerequisite is a small test version of ONAP (ONAP-lite?).  Ideally, we should 
be able to quickly instantiate it in a cloud environment, run our tests, and 
tear it down. We should talk about your Python framework.

regarding packaging, I created a docker integrating the demo and the 
vvp/validation repos within a xtesting docker
this 45 Mo docker 
(https://hub.docker.com/r/morganrol/xtesting-onap-vnfpkgcheck/) checks the 
different heat template available in the demo repos (traces attached)
VNFSDK has been focusing on TOSCA.  We should discuss whether it makes sense to 
incorporate these for HEAT – we're currently using VVP tests.
regarding the Python Framework
Our first idea was to create python client for the components (like in 
Openstack); we used theses components to onboard then instantiate some simple 
opensource VNFs
Our goal was to include daily instantiation of simple VNFs (vIMS, vAAA - much 
simpler than the demo VNF including proprietary VNFs but integrable into CI/CD 
chains (open source VNFs))

We can sync during a VNFSDK / Integration / ad-hoc meeting if you want
Sounds good
 We're cleaning up our test engine this release to make it easier to run Java, 
Python, or shell tests.

xtesting includes natively the possibility to run bash, python, junit or robot 
tests.
it also runs VNFs through a python vnf abstraction developed in OPNFV and used 
with open-o, cloudify, juju, openbaton, heat (currently 
heat/cloudify+clearwater IMS, cloudify+vyos vrouter and juju+vEPC previously we 
had also open-o/openbaton + clearwater IMS and openbaton = openIMS)

Prior to now, we had a number of test engines coming in from different sources, 
using different languages.  I expect by the end of Casablanca to have a stable 
test framework so we can focus more on the tests in Dublin.

I would say that Robotframework is a very stable test framework :)
We're already using Robot as part of the function test repo ;-).
The python frameworks are also probably stable...
Yes, we're using Tox…
From Amsterdam to Beijing, the only unstability I can see is due to API & data 
model changes in the components
Somehow the diversity of the test frameworks reflects the stability of the SUT 
and the community testing vitality.
The issue we're facing is the challenge of test development…We're trying to 
refactor to simplify test creation.
It is not surprising to see several initiatives.
It is a richness for a community and it beco

[onap-discuss] Missing docker images

[Gary Wu]

Hi helpdesk,

Currently the following docker images have gone missing:

onap/activity-spec:1.3.0 (note that this was NOT a released image)
onap/multicloud/vio:1.2.0-STAGING

Can you take a look?

Thanks,
Gary



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12057): https://lists.onap.org/g/onap-discuss/message/12057
Mute This Topic: https://lists.onap.org/mt/24946661/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [modeling] Network Service Descriptor model

[Jessie Jewitt]

Hi Xu-
If I understand you correctly, you mean you are not seeing an attribute
on the diagram that has type "ConnectivityType"? You see it in the table
because NsVirtualLinkDesc inherits from VirtualLinkDesc which contains the
attribute called "connectivityType" of type "ConnectivityType". I updated
the diagram to show this inheritance relationship, so you should see it
now. Let me know if that is satisfactory to you.
-Jessie

On Thu, Aug 23, 2018 at 7:19 PM, Xu Yang  wrote:

> Hi Jessie,
>
>
>
> Thanks for updating.
>
> A quick comment, the diagram is too vague, would you please help update it?
>
>
>
> BR,
>
> Xu
>
>
>
> *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On
> Behalf Of *Jessie Jewitt
> *Sent:* Friday, August 24, 2018 1:39 AM
> *To:* onap-discuss ;
> jessie.jew...@oamtechnologies.com
> *Cc:* 郭楚怡 ; denglingli <
> denglin...@chinamobile.com>; zhang.maopeng1 ;
> zhan.jie1 
>
> *Subject:* Re: [onap-discuss] [modeling] Network Service Descriptor model
>
>
>
> I have updated the Network Service Descriptor
> model
> on the wiki based on recommendations from this team to align with R2.
>
> Two notes:
>
> 1. NSD was missing in R2 a nsdIdentifier. This is a must have.
>
> 2. Some of the types are empty. I'll fill those in next week.
>
>
>
> -Jessie
>
>
>
> On Thu, Aug 23, 2018 at 9:40 AM, Jessie Jewitt  oamtechnologies.com> wrote:
>
> Hi Xu-
>
> Two comments:
>
> 1. I will mark association member ends and referenced classes as
> experimental and put them in the output.
>
> 2. You don't see things like ConnectivityType on the diagram because it is
> a class diagram and ConnectivityType is a datatype.
>
>
>
> -Jessie
>
>
>
> On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang  wrote:
>
> Hi Jessie,
>
>
>
> Please see inline.
>
>
>
> Best regards,
>
> Xu
>
>
>
> *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On
> Behalf Of *Jessie Jewitt
> *Sent:* Thursday, August 23, 2018 1:44 AM
> *To:* yangxu (H) 
> *Cc:* 郭楚怡 ; onap-discuss <
> onap-discuss@lists.onap.org>; denglingli ;
> zhang.maopeng1 ; zhan.jie1 <
> zhan.j...@zte.com.cn>
> *Subject:* Re: [onap-discuss] [modeling] Network Service Descriptor model
>
>
>
> Hi Xu-
>
>I hadn't seen your response when I answered Chuyi's email. Please see
> my comments embedded below...
>
> Thanks,
>
> Jessie
>
>
>
> On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H)  wrote:
>
> Hi Jessie,
>
>
>
> In R2, we did have a call for approval for the NSD model, as shown in
> https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on
> that anymore and focus on improving the current model.
>
> Jessie: Yes, agree
>
>
>
> It’s true that we don’t have a UML diagram for the NSD model on the wiki
> page I give, the proposal from my side is that we create a Papyrus model
> for the NSD (as we are doing it now) and align it with the R2 wiki page,
> fix issues and put it into R3 clean model.
>
> Jessie: Agree. That's what I proposed to Chuyi. I'll align the current NSD
> model in Papyrus with the R2 model, but fix the issues and prepare this to
> go in clean. I can have it ready by next Monday, hopefully, though I won't
> be on the call.
>
> Further improvement and alignment with ETSI specs are better to be put
> into R4 as we are coming to the deadline for the final draft.
>
> Jessie: Agree.
>
> Regarding the issues, I think you are right the current model is not
> complete, we can either remove those attributes that are not defined or
> mark them as experimental like what we have done for the VNFD model.
>
> Jessie: The "attributes" that are not defined are member ends of
> associations. We need to either remove the associations, or add the
> referenced classes in the model. I personally don't think it would be
> correct to mark them as "experimental" as they would be incomplete
> definitions. For example, you reference a Sapd, but don't define the Sapd
> class? It wouldn't be possible to implement something like that.
>
> [xy] I agree, I’m suggesting either we remove those
> attributes/associations or add the referenced classes and mark those
> classes as “experimental”. For example, either we don’t have any
> attributes/classes called Sapd in the model, or we add an empty Sapd class
> marked as “experimental”. The reason why I’m suggesting to mark the class
> as “experimental” is that we don’t have a discussion on those classes
> before (and not likely to have before the deadline), marking them as
> “experimental” shows further discussion and refinement are needed.
>
>
>
> And as Chuyi pointed out, there’s something on the wiki that are not shown
> in the Papyrus model, update is needed to keep them aligned.
>
>
>
> Jessie: I didn't catch what was on the wiki, but not in the model. Can you
> remind me what that is?
>
> [xy] For example, I think several attributes (testAccess,
> connectivityType, etc.) of the NsVirtualLinkDesc class are not shown i

[onap-discuss] [Policy][Control-loop] Delay Policy Execution

[Xin Miao]

Hi, Folks,

Have we ever had a requirement or thought that user can control the execution 
of a recipe by some delay, say, delaying some action by certain amount of time 
at operational policy execution? And it can be controlled through Policy 
creation/configuration, i. e., by adding in another dimension/parameter of 
'delay time' into operational policy?  I have not seen a definition of this or 
any examples from the existing use cases.

Any idea?

Thank you and best regards,

Xin Miao
American Network Technology Lab
Futurewei Technologies, Inc.
5340 Legacy Dr., Suite 175 Plano, TX 75024
Phone: 469-277-5884; Mobile:469-268-5226
xin.m...@huawei.com
 [cid:image001.jpg@01CD505D.C18C2420]


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12055): https://lists.onap.org/g/onap-discuss/message/12055
Mute This Topic: https://lists.onap.org/mt/24945664/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [ONAP] E2E VNF functional testing

[Morgan Richomme]

Hi Chris

thanks for the reply
comments, answers and questions in the mail

/Morgan

Le jeudi 23 août 2018 à 20:46 +, Christopher Donley (Chris) a écrit :
Most of your wishlist items are in the VNFSDK roadmap.

ok
does it mean that
- Testsuite deals with tests of ONAP (which may include canonical VMs) as a 
solution
- VNFSDK deals with ONAP compatible VNF tests.

VNFSDK name was a bit misleading for me as the goal is not to provide a toolkit 
to develop but to validate and integrate in CI/CD chains.
However the description of the project is clear :)"build an ecosystem for ONAP 
compatible VNFs by developing tools for vendor CI/CD toolchains and developing 
validation and testing tools"

Does it mean that you plan to develop VNF, leverage OPNFV VNF project, develop 
tests in addition of testing tools?


#3 on your list is already part of VNFSDK (dovetail-integration repo).

ok
I had a quick loop, it looks like python + yaml templating but covers the same 
areas than robot + python extention script from testsuite
it is already dockerized an inherited stuff from dovetail
I need to test it :)


Regarding #2, we have been focusing on packaging tests, but recently updated 
the functional tests (functest repo) in Beijing.  Lifecycle tests have been 
dormant since OPEN-O, but we can resurrect as soon as we have resources.  One 
prerequisite is a small test version of ONAP (ONAP-lite?).  Ideally, we should 
be able to quickly instantiate it in a cloud environment, run our tests, and 
tear it down. We should talk about your Python framework.

regarding packaging, I created a docker integrating the demo and the 
vvp/validation repos within a xtesting docker
this 45 Mo docker 
(https://hub.docker.com/r/morganrol/xtesting-onap-vnfpkgcheck/) checks the 
different heat template available in the demo repos (traces attached)

regarding the Python Framework
Our first idea was to create python client for the components (like in 
Openstack); we used theses components to onboard then instantiate some simple 
opensource VNFs
Our goal was to include daily instantiation of simple VNFs (vIMS, vAAA - much 
simpler than the demo VNF including proprietary VNFs but integrable into CI/CD 
chains (open source VNFs))

We can sync during a VNFSDK / Integration / ad-hoc meeting if you want
 We're cleaning up our test engine this release to make it easier to run Java, 
Python, or shell tests.

xtesting includes natively the possibility to run bash, python, junit or robot 
tests.
it also runs VNFs through a python vnf abstraction developed in OPNFV and used 
with open-o, cloudify, juju, openbaton, heat (currently 
heat/cloudify+clearwater IMS, cloudify+vyos vrouter and juju+vEPC previously we 
had also open-o/openbaton + clearwater IMS and openbaton = openIMS)

Prior to now, we had a number of test engines coming in from different sources, 
using different languages.  I expect by the end of Casablanca to have a stable 
test framework so we can focus more on the tests in Dublin.

I would say that Robotframework is a very stable test framework :)
The python frameworks are also probably stable...
From Amsterdam to Beijing, the only unstability I can see is due to API & data 
model changes in the components
Somehow the diversity of the test frameworks reflects the stability of the SUT 
and the community testing vitality.

It is not surprising to see several initiatives.
It is a richness for a community and it becomes a real added value when 
synergies occur.


I will be at ONS, and happy to meet while we're there.

Let's plan a slot to discuss these different aspects.

Chris



From: "morgan.richo...@orange.com" 
mailto:morgan.richo...@orange.com>>
Date: Thursday, August 23, 2018 at 5:33 AM
To: Yunxia Chen mailto:helen.c...@huawei.com>>, 
"ran.pol...@amdocs.com" 
mailto:ran.pol...@amdocs.com>>, 
"moshe...@amdocs.com" 
mailto:moshe...@amdocs.com>>, Chris Donley 
mailto:christopher.don...@huawei.com>>, Gary Wu 
mailto:gary.i...@huawei.com>>, "Yang Xu (Yang, Fixed 
Network)" mailto:yang@huawei.com>>, 
"plata...@research.att.com" 
mailto:plata...@research.att.com>>, 
"kevin@att.com" 
mailto:kevin@att.com>>, 
"bf1...@att.com" mailto:bf1...@att.com>>
Cc: DEBEAU Eric IMT/OLN 
mailto:eric.deb...@orange.com>>, 
"onap-discuss@lists.onap.org" 
mailto:onap-discuss@lists.onap.org>>
Subject: [ONAP] E2E VNF functional testing

Hi,

a topic was dedicated to vCPE automation during Integration meeting today.

I think that E2E VNF testing automation is key to stabilize ONAP

For me automation means the ability to
- check packaging
- onboard the model
- instantiate the VNF
- check that resources are propely created on the target infrastructure
- perform functional tests (e.g. SIP tests on a vIMS VNF)
- clean the resources
- report the result

[onap-discuss] [SO] : building from sources : version problem ?

[Rene Robert]

Hi

I tried to generate SO docker container from SO source code available here :

git clone https://gerrit.onap.org/r/so

several branches are available :

$ git branch -a
* master
  remotes/origin/2.0.0-ONAP
  remotes/origin/HEAD -> origin/master
  remotes/origin/Test
  remotes/origin/amsterdam
  remotes/origin/beijing
  remotes/origin/container_test
  remotes/origin/master
  remotes/origin/release-1.0.0


If I have a look at the “beijing” branch, the pom.xml contains that line :

1.2.0-SNAPSHOT

If I have a look at the “2.0.0-ONAP” branch, the pom.xml contains that line :

1.2.0-SNAPSHOT

If I have a look at the “master” branch, the pom.xml contains that line :

1.3.0-SNAPSHOT


But (there is a but, of course…)

When I have a look at my ONAP (heat) installed platform (Beijing) then I see 
some 1.2.2 stuff inside the SO docker container.

So I am wondering how I can build a SO from source code to obtain exactly the 
same version of what is installed in the ONAP platform.


What did I missed ?

René

ORANGE


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12053): https://lists.onap.org/g/onap-discuss/message/12053
Mute This Topic: https://lists.onap.org/mt/24944842/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-discuss] Usecase subcommittee meeting agenda for 27/08/2018

[Alla Goldner]

Hi,

During our next meeting, we will review OSAM Roadmap and planned Dublin Release 
requirements.

Please let me know if you also plan (and ready) to present your plans regarding 
a functional requirements and use cases planned for Dublin (new ones and 
continuation of the existing ones).

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D43BC8.A37F1660]

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12052): https://lists.onap.org/g/onap-discuss/message/12052
Mute This Topic: https://lists.onap.org/mt/24944510/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-discuss] [integration]Manifest Issue

[Guangrong Fu]

Hi Gary,







I updated the manifest files a little bit and submitted them 
(https://gerrit.onap.org/r/#/c/61747/). But the Jenkins verification job keeps 
failing. The reason is that one component is missing from the nexus repo.






[ERROR] onap/activity-spec:1.3.0 not found






Since it's not our project, I've no idea on how to deal with that.






Could you please help to take a look at it?






Thanks,


Guangrong
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12051): https://lists.onap.org/g/onap-discuss/message/12051
Mute This Topic: https://lists.onap.org/mt/24942770/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [ONAP] E2E VNF functional testing

[Morgan Richomme]

Hi Brian

thanks for the quick answer
some answers & ... questions in the mail ..

/Morgan

Le jeudi 23 août 2018 à 12:56 +, FREEMAN, BRIAN D a écrit :
Morgan,

Jenkins jobs for daily installation and regression tests are off the 
jenkins/grafana site that Gary runs.

http://onapci.org/jenkins/
http://onapci.org/grafana/
http://onapci.org/grafana/d/8cGRqBOmz/daily-summary?orgId=1

That is what I had in mind but I did not find the link from the wiki.
is there any reason it is not referenced? if no objection , I could add it to 
the wiki integration page

My first reflex was to go to https://jenkins.onap.org/view/integration/
but onapci.org is much clearer from an integration perspective
I am not sure to fully understand why there are 2 jenkins dealing with 
integration.
More generally I also remember that there is a dedicate CI chains for OOM. The 
CI/CD governance is not fully clear.

On onapci jenkins, does the daily jobs deal with the Master branch (Casablanca 
candidate)?
is there any jobs using Beijing (to check the stability)

I can see that healthcheck tests are performed at the end of the installation 
(with heat & oom installer).
For the moment, none of the healthcheck test reached 100% (which is logic for a 
master branch at M3 milestone), is it why the VNF tests are not triggered?
As far as I remember vFW was integrated in CI chains for Beijing
It would make sense to keep all the supported & automated VNF E2E tests in the 
CI chains.


We could start the discussion even before ONS.
sure..

I would encourage us to look at incorporating testing into the testsuite 
project rather than a new project but I may be mis-understanding what you mean 
by xtesting.
I agree
it is always challenging, as creation - at least in first step - looks quicker 
(you are master on board) than joining existing projects due to the learning 
curve and the technical debt.
but one the most important community added value deals with the capability to 
avoid that.
regarding Orange contribution in this area, the problem is more with onap-tests 
than xtesting.
xtesting does not create any use case, it is a docker launcher tool consuming 
existing testsuites from upstream test projects using different 
languages/technologies(Robot, bash, python, junit,..).

the python onap-tests framework do things similar to what Robot does 
(onboarding, instantiation, openstack resource creation check).
we initiated it mainly to learn (creation of class per ONAP module a little bit 
like the openstack python clients per Openstack module - but not so well 
written...)
we were not so familiar with robot and, as, when it becomes complex, robot 
(which is written in python) calls python classes, we did it this way.
But we could probably reuse all the robot capabilities to run the vIMS or vAAA
We can see that some of the python classes called from robot scripts (hosted in 
python-testing-utils) are not very different (and probably better) to what we 
did.

regarding xtesting, we are using it to unify the way we launch tests from 
different projects (infra/kubernetes, infra/openstack, onap/healthcheck, 
onap/vvp, ..) in different CI/CD chains (jenkins, gitlab).

We use it for our infra and for ONAP.
for the infra, you can see some exemples from OPNFV CI/CD chains
- kubernetes infra check (test suite from kubernetes community): 
https://build.opnfv.org/ci/view/functest/job/functest-compass-baremetal-daily-master/249/console
- openstack infra check (testsuites from different sources:upstream openstack 
(rally, tempest, shaker, vmtp, ...), OPNFV feature project or test project own 
dev including VNF lifecycle tests on vIMS, vCPE): 
https://build.opnfv.org/ci/view/functest/job/functest-apex-baremetal-daily-master/225/console

on ONAP we use xtesting to
- run the existing Robotframework => docker pull morganrol/xtesting-onap-robot
- run ice validator towards referenced heat templates from official ONAP repo 
=> docker pull morganrol/xtesting-onap-vnfpkgcheck

[cid:b3ca07c0596c201ff83a052309c83f1fb9a37372.camel@orange.com]

One more time it does not create new testcase, it just "dockerizes" the launch 
and the way to declare the cases, get and export the results.
the test execution is independent from the SUT and cleaned once tests are 
executed
the docker creation shall be triggered each time one of the heat template 
and/or the code of the ice_validator is modified

Installation of ONAP is generally in the demo or integration repos (demo is 
more for the test vnfs going forward) .
OK

it is sometimes not fully crystal clear but I do not have all the history
in integration/test I can find a directory vcpe 
https://git.onap.org/integration/tree/test/vcpe
there is also several vCPE directories under demo
https://git.onap.org/demo/tree/vnfs/vCPE
https://git.onap.org/demo/tree/heat/vCPE

in integration, there are stuff related to the tests, the labs, the CI, lots of 
tools. it is not always to see the link between the different folders.

would it make se