date:20170524

[onap-discuss] 答复: [ONAP] Use Case: VoLTE (vIMS + vEPC)

2017-05-24 Thread 杨艳

Hi  Eric,

 

Thanks for your questions and I will do some clarification.

 

1. The open source VNF you mentioned is open source VNF, or vendor VNF?
who is responsible for maintaining in the integration test and docking with
other VNFs in end-to-end testing?

 

2. The parser component in Instantiation figure is TOSCA parser which is
included in the Modeling project.

 

3. User sends a request to Portal firstly and not to DCAE.it is just a
mistake and we will correct it later.

 

4. Welcome to provide relevant workflow charts based app-c.For
example,instantiation,termination and control loop.

 

5. Whether the minimum set of EPC scenes contains only two or three
VNFs, and if so, it is no longer an end-to-end VoLTE Use Case, and whether
need other VNFs.In this case how to do end-to-end business verification, or
as a separate VNF to verify? Is there a closed loop control?

 

 

 

Thanks,

Yan

发件人: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] 代表 eric.deb...@orange.com
发送时间: 2017年5月24日 15:11
收件人: onap-discuss@lists.onap.org
主题: [onap-discuss] [ONAP] Use Case: VoLTE (vIMS + vEPC)

 

Hello

 

I would like to clarify some points on the use-case on the mailing-list
before clarification on the wiki.

 

For VNF, I believe that we should add a column for open-source based
solution.

 

There is a parser component in the Instantiation figure. What is it ? I
understand as a TOSCA parser, but it is not described.

 

On the termination call flow, I do not understand why the user sends a
request to the DCAE…Why not using the SO directly ?

 

The various call flows are based on VF-C, but why not using APP-C ?

 

The use-case should include minimal vEPC use-case as proposed in MiddleTown
(with PGW, MME and HSS).

 

Regards

 

Eric


_
 
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.
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] YANG.XML format

2017-05-24 Thread Law, Owen

Hi ONAPers:

There is an option in SDC to add deployment artefacts as part of the service 
composition – is there a specific guideline on what format is needed for the 
YANG.XML  ?

Regards
Owen
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] SDNC container keeps failing

2017-05-24 Thread Alex Vicol (avicol)

Thanks Josef,

Indeed the /etc/resolv.conf in all the sdnc containers contains dummy values 
instead of the expected entries:


root@7d1a4e03a38d:/# cat /etc/resolv.conf

search cisco.com

nameserver 127.0.0.11

options ndots:0

The difference in my case I guess is that my sdnc VM resolv.conf looks correct. 
I checked other VMs and their containers and they are all in sync and using the 
right dns entries. Looks like it’s only the sdnc containers getting the wrong 
info. Is there a proper way to force the sdnc containers to get the right info?
I will try to change the compose file to manually change the dns config, hope 
it fixes the problem for now.

Thanks,
Alex
From: Josef Reisinger 
Date: Wednesday, May 24, 2017 at 12:53 AM
To: "Alex Vicol (avicol)" 
Cc: "onap-discuss@lists.onap.org" 
Subject: Re: [onap-discuss] SDNC container keeps failing

Alex,

I can see the getaddrinfo ENOTFOUND error which hit me too as few days ago. For 
me it could be resolved with a bit weird change of the resolv.conf of the SDC 
VM. See details here: 
https://wiki.onap.org/questions/5734531/sdnc---portal-container-error-npm-err-network-getaddrinfo-enotfound

Mit freundlichen Grüßen / Kind regards
Josef Reisinger
When wisdom comes to call, there's nobody listening at all - Pendragon / Man Of 
Nomadic Traits

IBM Sales & Distribution, Communications Sector
Certified IT-Architect Telecommunications
IBM Certified Telecommunications Industry ITA
Lehrbeauftragter an der Hochschule Fresenius

IBM Deutschland
Godesberger Allee 127
53175 Bonn Beuel

Phone:+49 151 1426 4559
Mobile:  +49-(0) 151 1426 4559
E-Mail:  josef.reisin...@de.ibm.com


IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Martina Koederitz (Vorsitzende), Nicole Reimer, Norbert 
Janzen, Dr. Christian Keller, Ivo Koerner, Stefan Lutz
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 
14562 / WEEE-Reg.-Nr. DE 99369940






From:"Alex Vicol (avicol)" 
To:"onap-discuss@lists.onap.org" 
Date:24.05.2017 09:10
Subject:[onap-discuss]  SDNC container keeps failing
Sent by:onap-discuss-boun...@lists.onap.org




Hi everyone,

One of the sdnc containers (the portal_container) keeps failing in our 
Openstack deployment. Using 1.0-STAGING-latestas the docker version. Looks like 
it’s complaining about a network issue or a missing “debug” module, but not 
clear what the problem is. Overall the ONAP deployment is up and running fine: 
portal, sdc, vid, appc, … I’m able to run the demo part until the preload part. 
That’s where it’s complaining about the sdnc portal being down.

root@vm1-sdnc:/opt# docker ps
CONTAINER IDIMAGE   COMMAND 
 CREATED STATUS  PORTS NAMES
8900dc6eb41fopenecomp/dgbuilder-sdnc-image:latest   "/bin/bash -c 'cd 
..."   2 hours ago Up 2 hours  0.0.0.0:3000->3100/tcp
sdnc_dgbuilder_container
809db6dad2dcopenecomp/admportal-sdnc-image:latest   "/bin/bash -c 'cd 
..."   2 hours ago Up 4 seconds0.0.0.0:8843->8843/tcp
sdnc_portal_container
d91cf4c9470bopenecomp/sdnc-image:latest 
"/opt/openecomp/sd..."   2 hours ago Up 2 hours  
0.0.0.0:8282->8181/tcpsdnc_controller_container
d9987a61cbbemysql/mysql-server:5.6  "/entrypoint.sh 
my..."   7 days ago  Up 6 days   0.0.0.0:32768->3306/tcp   
sdnc_db_container
root@vm1-sdnc:/opt#
root@vm1-sdnc:/opt# docker logs sdnc_portal_container
npm http GET https://registry.npmjs.org/debug
npm http GET https://registry.npmjs.org/ejs
npm http GET https://registry.npmjs.org/express
npm http GET https://registry.npmjs.org/express-session
npm http GET https://registry.npmjs.org/fs.extra
npm http GET https://registry.npmjs.org/lodash
npm http GET https://registry.npmjs.org/moment
npm http GET https://registry.npmjs.org/morgan
npm http GET https://registry.npmjs.org/multer
npm http GET https://registry.npmjs.org/mysql
npm http GET https://registry.npmjs.org/node-uuid
npm http GET https://registry.npmjs.org/path
npm http GET https://registry.npmjs.org/properties-reader/0.0.9
npm http GET https://registry.npmjs.org/sax
npm http GET https://registry.npmjs.org/body-parser
npm http GET https://registry.npmjs.org/serve-favicon
npm http GET https://registry.npmjs.org/xml2js
npm http GET https://registry.npmjs.org/dns-sync
npm http GET https://registry.npmjs.org/bootstrap
npm http GET https://registry.npmjs.org/bootstrap-table
npm http GET https://registry.npmjs.org/cookie-parser
npm http GET https://registry.npmjs.org/csv
npm http GET https://registry.npmjs.org/csvtojson
npm http GET https://registry.npmjs.org/dateformat
npm http GET https://registry.npmjs.org/bootstrap

Re: [onap-discuss] Staging repo in settings.xml

2017-05-24 Thread SPATSCHECK, OLIVER (OLIVER)

> On May 24, 2017, at 10:54 AM  EDT, Gary Wu  wrote:
> 
> 3) I understand that all the staging process was meant to be temporary, and 
> to add on Gary’s last question, what is the plan moving forward and how could 
> we contribute to that effort ?

I think that’s a TSC question. We wouldn’t mind moving this to a formal release 
just because it makes it easier to deal with the code. However,   the current 
plan is to have the first formal release in November when the code bases have 
merged and not on the seed code in the current repos.  Assuming we stick with 
that plan it means we will stay in staging at least till November to ensure we 
have a working code base for demos etc… .

Oliver
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [onap-discssus] Tooling for call flow

2017-05-24 Thread ROSE, DANIEL V

Hi Eric,

Are you talking about call flows in the model 
(https://wiki.onap.org/display/DW/Service+Design#ServiceDesign-CNCF )?

Or are you talking about DGs in sdnc?

Thanks,
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of eric.deb...@orange.com
Sent: Wednesday, May 24, 2017 3:17 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] [onap-discssus] Tooling for call flow

Hello

To be able to work on call flow in a collaborative way, I believe that we 
should use a tool based on a description language rather using images.

Is there any guideline within the Linux Foundation for such tooling ?

Within Orange, we developed a cool tool:
https://github.com/Orange-OpenSource/EtherPlant

Eric

_



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.
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Staging repo in settings.xml

2017-05-24 Thread Gary Wu

#1 is correct; the Pro version is required to use the Staging repos feature.

#2: if you don't have Pro version, you won't be able to deploy to a staging 
repo.  You should still be able to build the SNAPSHOT artifacts that pull 
staging dependencies, but those will need to come from the LF Nexus.

#3: Hopefully Christophe or someone else can chime in.

Thanks,
Gary

-Original Message-
From: Coquelin, Sebastien [mailto:sebastien.coque...@bell.ca] 
Sent: Wednesday, May 24, 2017 7:50 AM
To: Gary Wu ; Closset, Christophe ; 
Andrew Grimberg ; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] Staging repo in settings.xml

Hi Christophe, Gary, Andy,

I’m trying also to build projects on a local Jenkins and I’m facing some issues 
related to the nexus-staging-maven-plugin.
I am reaching out to clarify a few things :

1) On the nexus-staging-maven-plugin documentation page 
(https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin),
 it states that it’s mandatory to have the Nexus Repository Pro version to 
leverage the staging feature. Can you please confirm ? 

2) Is there any – quick - workaround to build all projects and skip the staging 
step if we want to stick with Nexus Repository OSS version ?

3) I understand that all the staging process was meant to be temporary, and to 
add on Gary’s last question, what is the plan moving forward and how could we 
contribute to that effort ?

Thanks,
Sébastien


On 2017-05-16, 1:30 PM, "onap-discuss-boun...@lists.onap.org on behalf of Gary 
Wu"  
wrote:

Hi Christophe,

Thanks for adding the historical context.

If I understand correctly, the staging approach was meant to be temporary 
right before a release.  Is a release imminent, or has that been canceled?  
What's the current timeline to move all the artifacts back to SNAPSHOT 
versioning (and remove Staging repo from build dependencies) in preparation for 
active ONAP development?

Thanks,
Gary


-Original Message-
From: Closset, Christophe [mailto:cc6...@intl.att.com] 
Sent: Friday, May 12, 2017 5:52 AM
To: Gary Wu ; Andrew Grimberg 
; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] Staging repo in settings.xml

Hi Gary, Andy,

As for the OpenECOMP history, the whole original idea was also to align 
everyone's release number and date to a common one for the launch (the current 
release-1.0.0 branch). 
Concerns were raised in the dev teams (as you pointed below) that 
everyone's pace would be different eventually and that we should have a way of 
releasing components independently even though we have serious inter 
dependencies within ONAP. So instead of a MEGA build - all components have 
their independent release jobs building on staging. This hybrid approach 
somehow suited us nicely, now we did not go through the blessing process to 
move all these to proper release artifacts and kept moving with this in the 
master branch as Andy explained.

I agree that it's confusing and not ideal right now (the concept of not 
really released 'release artifacts' is puzzling at first but we got used to it).
If (and that's probably a TSC decision to make) we want to move to a fully 
decoupled model - which with the number of repositories growing is probably a 
good idea - then we should also remove the joint numbering somewhat (TSC) so 
that components can truly release independently. This indeed brings the issue 
of managing dependencies in a non-intuitive manner (I'm building ONAP release X 
and I see dependencies with strange numbers, potentially from previous ONAP 
releases )and would need to be adopted by the community as well.

One benefit of the staging approach is that it allows to limit version 
variance during a stabilization period. Staging should be limited in time, 
probably for a period at the end of the official release cycle when everyone's 
artifact are mostly ready. The Release Candidate approach is another way of 
achieving this I believe.

Regards
Christophe

-Original Message-
From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu
Sent: Friday, May 12, 2017 12:29 AM
To: Andrew Grimberg ; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] Staging repo in settings.xml

Hi Andy, thanks for the explanation.

It sounds like this will require a larger discussion on the overall 
versioning and release strategy across ONAP projects and artifacts.

For everyone's reference, in OPEN-O we decided to keep all artifact 
versions in sync across projects in order to minimize the management and 
support burden.  Under this assumption, the autorelease "mega-build" that 
builds everything together was a way to enforce synchronized version labels and 
to detect cross-project compilation issues since everyone was building against 
SNAPSHOT depende

Re: [onap-discuss] Staging repo in settings.xml

2017-05-24 Thread Coquelin, Sebastien

Hi Christophe, Gary, Andy,

I’m trying also to build projects on a local Jenkins and I’m facing some issues 
related to the nexus-staging-maven-plugin.
I am reaching out to clarify a few things :

1) On the nexus-staging-maven-plugin documentation page 
(https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin),
 it states that it’s mandatory to have the Nexus Repository Pro version to 
leverage the staging feature. Can you please confirm ? 

2) Is there any – quick - workaround to build all projects and skip the staging 
step if we want to stick with Nexus Repository OSS version ?

3) I understand that all the staging process was meant to be temporary, and to 
add on Gary’s last question, what is the plan moving forward and how could we 
contribute to that effort ?

Thanks,
Sébastien


On 2017-05-16, 1:30 PM, "onap-discuss-boun...@lists.onap.org on behalf of Gary 
Wu"  
wrote:

Hi Christophe,

Thanks for adding the historical context.

If I understand correctly, the staging approach was meant to be temporary 
right before a release.  Is a release imminent, or has that been canceled?  
What's the current timeline to move all the artifacts back to SNAPSHOT 
versioning (and remove Staging repo from build dependencies) in preparation for 
active ONAP development?

Thanks,
Gary


-Original Message-
From: Closset, Christophe [mailto:cc6...@intl.att.com] 
Sent: Friday, May 12, 2017 5:52 AM
To: Gary Wu ; Andrew Grimberg 
; onap-discuss@lists.onap.org
Subject: RE: [onap-discuss] Staging repo in settings.xml

Hi Gary, Andy,

As for the OpenECOMP history, the whole original idea was also to align 
everyone's release number and date to a common one for the launch (the current 
release-1.0.0 branch). 
Concerns were raised in the dev teams (as you pointed below) that 
everyone's pace would be different eventually and that we should have a way of 
releasing components independently even though we have serious inter 
dependencies within ONAP. So instead of a MEGA build - all components have 
their independent release jobs building on staging. This hybrid approach 
somehow suited us nicely, now we did not go through the blessing process to 
move all these to proper release artifacts and kept moving with this in the 
master branch as Andy explained.

I agree that it's confusing and not ideal right now (the concept of not 
really released 'release artifacts' is puzzling at first but we got used to it).
If (and that's probably a TSC decision to make) we want to move to a fully 
decoupled model - which with the number of repositories growing is probably a 
good idea - then we should also remove the joint numbering somewhat (TSC) so 
that components can truly release independently. This indeed brings the issue 
of managing dependencies in a non-intuitive manner (I'm building ONAP release X 
and I see dependencies with strange numbers, potentially from previous ONAP 
releases )and would need to be adopted by the community as well.

One benefit of the staging approach is that it allows to limit version 
variance during a stabilization period. Staging should be limited in time, 
probably for a period at the end of the official release cycle when everyone's 
artifact are mostly ready. The Release Candidate approach is another way of 
achieving this I believe.

Regards
Christophe

-Original Message-
From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu
Sent: Friday, May 12, 2017 12:29 AM
To: Andrew Grimberg ; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] Staging repo in settings.xml

Hi Andy, thanks for the explanation.

It sounds like this will require a larger discussion on the overall 
versioning and release strategy across ONAP projects and artifacts.

For everyone's reference, in OPEN-O we decided to keep all artifact 
versions in sync across projects in order to minimize the management and 
support burden.  Under this assumption, the autorelease "mega-build" that 
builds everything together was a way to enforce synchronized version labels and 
to detect cross-project compilation issues since everyone was building against 
SNAPSHOT dependencies that can change at any time.

If we don't want to build against SNAPSHOT dependencies across projects, 
then it means that different projects may have different release cycles, and we 
may end up with a mix of different artifact versions for the official "ONAP 
Version 1" distribution.  This has the benefit of breaking up the autorelease 
"mega-build", at the cost of having to manage and support a mix of artifact 
versions and differing release schedules.

Can someone from ECOMP pipe in to add some historical perspective and/or 
the current assumptions on artifact versioning?

Regarding the issue at ha

Re: [onap-discuss] Versions to use for ONAP

2017-05-24 Thread PLATANIA, MARCO (MARCO)

Josef,

Please use the following parameters in the heat template:

artifacts_version: 1.1.0-SNAPSHOT
docker_version: 1.0-STAGING-latest
gerrit_branch: release-1.0.0
dcae_code_version: 1.0.0

Thanks,
Marco

From:  on behalf of Josef Reisinger 

Date: Wednesday, May 24, 2017 at 9:09 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] Versions to use for ONAP

Folks,

I am in the process to re-create the ONAP stack and wonder which version of 
artifacts/docker/gerrit-branchto use.

I know that there is an 1.1-STAGING-latest version of the docker images, which 
works better in case of VID. Should I stick with 1.0-STAGING-latest in the 
environment file or is it safe/advised to use 1.1-STATING-latest?

Mit freundlichen Grüßen / Kind regards
Josef Reisinger
When wisdom comes to call, there's nobody listening at all - Pendragon / Man Of 
Nomadic Traits

IBM Sales & Distribution, Communications Sector
Certified IT-Architect Telecommunications
IBM Certified Telecommunications Industry ITA
Lehrbeauftragter an der Hochschule Fresenius

IBM Deutschland
Godesberger Allee 127
53175 Bonn Beuel

Phone:+49 151 1426 4559
Mobile:  +49-(0) 151 1426 4559
E-Mail:  josef.reisin...@de.ibm.com






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

Re: [onap-discuss] Versions to use for ONAP

2017-05-24 Thread DRAGOSH, PAMELA L (PAM)

Josef,

Use the 1.0-STAGING it is stable. The 1.1 is unstable right now.

Thanks,

Pam


Pamela Dragosh
Lead Inventive Scientist
ONAP Policy
AT&T Research
pdrag...@research.att.com



From:  on behalf of Josef Reisinger 

Date: Wednesday, May 24, 2017 at 9:09 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] Versions to use for ONAP

Folks,

I am in the process to re-create the ONAP stack and wonder which version of 
artifacts/docker/gerrit-branchto use.

I know that there is an 1.1-STAGING-latest version of the docker images, which 
works better in case of VID. Should I stick with 1.0-STAGING-latest in the 
environment file or is it safe/advised to use 1.1-STATING-latest?

Mit freundlichen Grüßen / Kind regards
Josef Reisinger
When wisdom comes to call, there's nobody listening at all - Pendragon / Man Of 
Nomadic Traits

IBM Sales & Distribution, Communications Sector
Certified IT-Architect Telecommunications
IBM Certified Telecommunications Industry ITA
Lehrbeauftragter an der Hochschule Fresenius

IBM Deutschland
Godesberger Allee 127
53175 Bonn Beuel

Phone:+49 151 1426 4559
Mobile:  +49-(0) 151 1426 4559
E-Mail:  josef.reisin...@de.ibm.com






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

[onap-discuss] Versions to use for ONAP

2017-05-24 Thread Josef Reisinger

Folks,

I am in the process to re-create the ONAP stack and wonder which version 
of artifacts/docker/gerrit-branchto use.

I know that there is an 1.1-STAGING-latest version of the docker images, 
which works better in case of VID. Should I stick with 1.0-STAGING-latest 
in the environment file or is it safe/advised to use 1.1-STATING-latest?

Mit freundlichen Grüßen / Kind regards 
Josef Reisinger 
When wisdom comes to call, there's nobody listening at all - Pendragon / 
Man Of Nomadic Traits 
IBM Sales & Distribution, Communications Sector
Certified IT-Architect Telecommunications
IBM Certified Telecommunications Industry ITA
Lehrbeauftragter an der Hochschule Fresenius
IBM Deutschland 
Godesberger Allee 127 
53175 Bonn Beuel
Phone:+49 151 1426 4559 
Mobile:  +49-(0) 151 1426 4559 
E-Mail:  josef.reisin...@de.ibm.com 





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

Re: [onap-discuss] Git review failing validating Jira issue

2017-05-24 Thread FLOOD, JERRY

Thanks. I was able to successfully do a git review after creating a new commit, 
however, the Jira issue error continues to be reported.

Jerry



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FLOOD, JERRY
Sent: Wednesday, May 24, 2017 7:24 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Git review failing validating Jira issue

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
I am receiving an error during git review command validating Jira issue

$ git review
remote: Processing changes: refs: 1, done
remote: Failed to check whether or not issue TEST-32 exists
remote: java.io.IOException: RestClientException{statusCode=Optional.of(403), 
errorCollections=[]}
remote: Non-existing issue ids referenced in commit message
remote: The issue-ids
remote: * TEST-32
remote: are referenced in the commit message of
remote: d1ad6c53a43ea4f56082f44f914ff2ad53492603,
remote: but do not exist in its-jira Issue-Tracker
To https://gerrit.onap.org/r/a/testsuite
! [remote rejected] HEAD -> refs/publish/master (change 
http://gerrit.onap.org/r/4441 closed)

Please advise

Thanks
Jerry
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Git review failing validating Jira issue

2017-05-24 Thread Alexis de Talhouët

Le mercredi 24 mai 2017, FLOOD, JERRY  a écrit :

> I am receiving an error during git review command validating Jira issue
>
>
>
> $ git review
>
> remote: Processing changes: refs: 1, done
>
> remote: Failed to check whether or not issue TEST-32 exists
>
> remote: java.io.IOException: RestClientException{statusCode=Optional.of(403),
> errorCollections=[]}
>
> remote: Non-existing issue ids referenced in commit message
>
> remote: The issue-ids
>
> remote: * TEST-32
>
> remote: are referenced in the commit message of
>
> remote: d1ad6c53a43ea4f56082f44f914ff2ad53492603,
>
> remote: but do not exist in its-jira Issue-Tracker
>
> To https://gerrit.onap.org/r/a/testsuite
>
> ! [remote rejected] HEAD -> refs/publish/master (change
> http://gerrit.tonap.org/r/4441  closed)
>

You're pushing some changes on a closed commit...you have to create a new
commit with your changes.

>
>
> Please advise
>
>
>
> Thanks
>
> Jerry
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Git review failing validating Jira issue

2017-05-24 Thread FLOOD, JERRY

I am receiving an error during git review command validating Jira issue

$ git review
remote: Processing changes: refs: 1, done
remote: Failed to check whether or not issue TEST-32 exists
remote: java.io.IOException: RestClientException{statusCode=Optional.of(403), 
errorCollections=[]}
remote: Non-existing issue ids referenced in commit message
remote: The issue-ids
remote: * TEST-32
remote: are referenced in the commit message of
remote: d1ad6c53a43ea4f56082f44f914ff2ad53492603,
remote: but do not exist in its-jira Issue-Tracker
To https://gerrit.onap.org/r/a/testsuite
! [remote rejected] HEAD -> refs/publish/master (change 
http://gerrit.onap.org/r/4441 closed)

Please advise

Thanks
Jerry
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] SDNC container keeps failing

2017-05-24 Thread Josef Reisinger

Alex,

I can see the getaddrinfo ENOTFOUND error which hit me too as few days 
ago. For me it could be resolved with a bit weird change of the 
resolv.conf of the SDC VM. See details here: 
https://wiki.onap.org/questions/5734531/sdnc---portal-container-error-npm-err-network-getaddrinfo-enotfound


Mit freundlichen Grüßen / Kind regards 
Josef Reisinger 
When wisdom comes to call, there's nobody listening at all - Pendragon / 
Man Of Nomadic Traits 
IBM Sales & Distribution, Communications Sector
Certified IT-Architect Telecommunications
IBM Certified Telecommunications Industry ITA
Lehrbeauftragter an der Hochschule Fresenius
IBM Deutschland 
Godesberger Allee 127 
53175 Bonn Beuel
Phone:+49 151 1426 4559 
Mobile:  +49-(0) 151 1426 4559 
E-Mail:  josef.reisin...@de.ibm.com 


IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter 
Geschäftsführung: Martina Koederitz (Vorsitzende), Nicole Reimer, Norbert 
Janzen, Dr. Christian Keller, Ivo Koerner, Stefan Lutz 
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, 
HRB 14562 / WEEE-Reg.-Nr. DE 99369940 




From:   "Alex Vicol (avicol)" 
To: "onap-discuss@lists.onap.org" 
Date:   24.05.2017 09:10
Subject:[onap-discuss]  SDNC container keeps failing
Sent by:onap-discuss-boun...@lists.onap.org



Hi everyone,
 
One of the sdnc containers (the portal_container) keeps failing in our 
Openstack deployment. Using 1.0-STAGING-latest as the docker version. 
Looks like it?s complaining about a network issue or a missing ?debug? 
module, but not clear what the problem is. Overall the ONAP deployment is 
up and running fine: portal, sdc, vid, appc, ? I?m able to run the demo 
part until the preload part. That?s where it?s complaining about the sdnc 
portal being down.
 
root@vm1-sdnc:/opt# docker ps
CONTAINER IDIMAGE   COMMAND   
CREATED STATUS  PORTS NAMES
8900dc6eb41fopenecomp/dgbuilder-sdnc-image:latest   "/bin/bash -c 
'cd ..."   2 hours ago Up 2 hours  0.0.0.0:3000->3100/tcp  
 sdnc_dgbuilder_container
809db6dad2dcopenecomp/admportal-sdnc-image:latest   "/bin/bash -c 
'cd ..."   2 hours ago Up 4 seconds0.0.0.0:8843->8843/tcp  
 sdnc_portal_container
d91cf4c9470bopenecomp/sdnc-image:latest "/opt/openecomp/sd..."   2 
hours ago Up 2 hours  0.0.0.0:8282->8181/tcp 
sdnc_controller_container
d9987a61cbbemysql/mysql-server:5.6 "/entrypoint.sh my..."   7 days 
ago  Up 6 days   0.0.0.0:32768->3306/tcp sdnc_db_container
root@vm1-sdnc:/opt#
root@vm1-sdnc:/opt# docker logs sdnc_portal_container
npm http GET https://registry.npmjs.org/debug
npm http GET https://registry.npmjs.org/ejs
npm http GET https://registry.npmjs.org/express
npm http GET https://registry.npmjs.org/express-session
npm http GET https://registry.npmjs.org/fs.extra
npm http GET https://registry.npmjs.org/lodash
npm http GET https://registry.npmjs.org/moment
npm http GET https://registry.npmjs.org/morgan
npm http GET https://registry.npmjs.org/multer
npm http GET https://registry.npmjs.org/mysql
npm http GET https://registry.npmjs.org/node-uuid
npm http GET https://registry.npmjs.org/path
npm http GET https://registry.npmjs.org/properties-reader/0.0.9
npm http GET https://registry.npmjs.org/sax
npm http GET https://registry.npmjs.org/body-parser
npm http GET https://registry.npmjs.org/serve-favicon
npm http GET https://registry.npmjs.org/xml2js
npm http GET https://registry.npmjs.org/dns-sync
npm http GET https://registry.npmjs.org/bootstrap
npm http GET https://registry.npmjs.org/bootstrap-table
npm http GET https://registry.npmjs.org/cookie-parser
npm http GET https://registry.npmjs.org/csv
npm http GET https://registry.npmjs.org/csvtojson
npm http GET https://registry.npmjs.org/dateformat
npm http GET https://registry.npmjs.org/bootstrap-submenu
npm http GET https://registry.npmjs.org/debug
npm http GET https://registry.npmjs.org/ejs
npm http GET https://registry.npmjs.org/express-session
npm http GET https://registry.npmjs.org/express
npm http GET https://registry.npmjs.org/fs.extra
npm http GET https://registry.npmjs.org/lodash
npm http GET https://registry.npmjs.org/moment
npm http GET https://registry.npmjs.org/morgan
npm http GET https://registry.npmjs.org/multer
npm http GET https://registry.npmjs.org/mysql
npm http GET https://registry.npmjs.org/node-uuid
npm http GET https://registry.npmjs.org/path
npm http GET https://registry.npmjs.org/properties-reader/0.0.9
npm http GET https://registry.npmjs.org/sax
npm http GET https://registry.npmjs.org/body-parser
npm http GET https://registry.npmjs.org/serve-favicon
npm http GET https://registry.npmjs.org/xml2js
npm http GET https://registry.npmjs.org/dns-sync
npm http GET https://registry.npmjs.org/bootstrap
npm http GET https://registry.npmjs.org/bootstrap-table
npm http GET https://registry.npmjs.org/cookie-parser
npm

[onap-discuss] [onap-discssus] Tooling for call flow

2017-05-24 Thread eric.debeau

Hello

To be able to work on call flow in a collaborative way, I believe that we 
should use a tool based on a description language rather using images.

Is there any guideline within the Linux Foundation for such tooling ?

Within Orange, we developed a cool tool:
https://github.com/Orange-OpenSource/EtherPlant

Eric

_

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.

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

[onap-discuss] [ONAP] Use Case: VoLTE (vIMS + vEPC)

2017-05-24 Thread eric.debeau

Hello

I would like to clarify some points on the use-case on the mailing-list before 
clarification on the wiki.

For VNF, I believe that we should add a column for open-source based solution.

There is a parser component in the Instantiation figure. What is it ? I 
understand as a TOSCA parser, but it is not described.

On the termination call flow, I do not understand why the user sends a request 
to the DCAE...Why not using the SO directly ?

The various call flows are based on VF-C, but why not using APP-C ?

The use-case should include minimal vEPC use-case as proposed in MiddleTown 
(with PGW, MME and HSS).

Regards

Eric

_

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.

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

[onap-discuss] SDNC container keeps failing

2017-05-24 Thread Alex Vicol (avicol)

Hi everyone,

One of the sdnc containers (the portal_container) keeps failing in our 
Openstack deployment. Using 1.0-STAGING-latest as the docker version. Looks 
like it’s complaining about a network issue or a missing “debug” module, but 
not clear what the problem is. Overall the ONAP deployment is up and running 
fine: portal, sdc, vid, appc, … I’m able to run the demo part until the preload 
part. That’s where it’s complaining about the sdnc portal being down.


root@vm1-sdnc:/opt# docker ps

CONTAINER IDIMAGE   COMMAND 
 CREATED STATUS  PORTS NAMES

8900dc6eb41fopenecomp/dgbuilder-sdnc-image:latest   "/bin/bash -c 'cd 
..."   2 hours ago Up 2 hours  0.0.0.0:3000->3100/tcp
sdnc_dgbuilder_container

809db6dad2dcopenecomp/admportal-sdnc-image:latest   "/bin/bash -c 'cd 
..."   2 hours ago Up 4 seconds0.0.0.0:8843->8843/tcp
sdnc_portal_container

d91cf4c9470bopenecomp/sdnc-image:latest 
"/opt/openecomp/sd..."   2 hours ago Up 2 hours  
0.0.0.0:8282->8181/tcpsdnc_controller_container

d9987a61cbbemysql/mysql-server:5.6  "/entrypoint.sh 
my..."   7 days ago  Up 6 days   0.0.0.0:32768->3306/tcp   
sdnc_db_container

root@vm1-sdnc:/opt#

root@vm1-sdnc:/opt# docker logs sdnc_portal_container

npm http GET https://registry.npmjs.org/debug

npm http GET https://registry.npmjs.org/ejs

npm http GET https://registry.npmjs.org/express

npm http GET https://registry.npmjs.org/express-session

npm http GET https://registry.npmjs.org/fs.extra

npm http GET https://registry.npmjs.org/lodash

npm http GET https://registry.npmjs.org/moment

npm http GET https://registry.npmjs.org/morgan

npm http GET https://registry.npmjs.org/multer

npm http GET https://registry.npmjs.org/mysql

npm http GET https://registry.npmjs.org/node-uuid

npm http GET https://registry.npmjs.org/path

npm http GET https://registry.npmjs.org/properties-reader/0.0.9

npm http GET https://registry.npmjs.org/sax

npm http GET https://registry.npmjs.org/body-parser

npm http GET https://registry.npmjs.org/serve-favicon

npm http GET https://registry.npmjs.org/xml2js

npm http GET https://registry.npmjs.org/dns-sync

npm http GET https://registry.npmjs.org/bootstrap

npm http GET https://registry.npmjs.org/bootstrap-table

npm http GET https://registry.npmjs.org/cookie-parser

npm http GET https://registry.npmjs.org/csv

npm http GET https://registry.npmjs.org/csvtojson

npm http GET https://registry.npmjs.org/dateformat

npm http GET https://registry.npmjs.org/bootstrap-submenu

npm http GET https://registry.npmjs.org/debug

npm http GET https://registry.npmjs.org/ejs

npm http GET https://registry.npmjs.org/express-session

npm http GET https://registry.npmjs.org/express

npm http GET https://registry.npmjs.org/fs.extra

npm http GET https://registry.npmjs.org/lodash

npm http GET https://registry.npmjs.org/moment

npm http GET https://registry.npmjs.org/morgan

npm http GET https://registry.npmjs.org/multer

npm http GET https://registry.npmjs.org/mysql

npm http GET https://registry.npmjs.org/node-uuid

npm http GET https://registry.npmjs.org/path

npm http GET https://registry.npmjs.org/properties-reader/0.0.9

npm http GET https://registry.npmjs.org/sax

npm http GET https://registry.npmjs.org/body-parser

npm http GET https://registry.npmjs.org/serve-favicon

npm http GET https://registry.npmjs.org/xml2js

npm http GET https://registry.npmjs.org/dns-sync

npm http GET https://registry.npmjs.org/bootstrap

npm http GET https://registry.npmjs.org/bootstrap-table

npm http GET https://registry.npmjs.org/cookie-parser

npm http GET https://registry.npmjs.org/csv

npm http GET https://registry.npmjs.org/csvtojson

npm http GET https://registry.npmjs.org/dateformat

npm http GET https://registry.npmjs.org/bootstrap-submenu

npm http GET https://registry.npmjs.org/debug

npm http GET https://registry.npmjs.org/express

npm http GET https://registry.npmjs.org/ejs

npm http GET https://registry.npmjs.org/express-session

npm http GET https://registry.npmjs.org/fs.extra

npm http GET https://registry.npmjs.org/moment

npm http GET https://registry.npmjs.org/lodash

npm http GET https://registry.npmjs.org/morgan

npm http GET https://registry.npmjs.org/multer

npm http GET https://registry.npmjs.org/mysql

npm http GET https://registry.npmjs.org/node-uuid

npm http GET https://registry.npmjs.org/path

npm http GET https://registry.npmjs.org/properties-reader/0.0.9

npm http GET https://registry.npmjs.org/sax

npm http GET https://registry.npmjs.org/body-parser

npm http GET https://registry.npmjs.org/serve-favicon

npm http GET https://registry.npmjs.org/xml2js

npm http GET https://registry.npmjs.org/dns-sync

npm http GET https://registry.npmjs.org/bootstrap

npm http GET https://registry.npmjs.org/bootstrap-table

npm ht

[onap-discuss] 答复: [ONAP] Use Case: VoLTE (vIMS + vEPC)

[onap-discuss] YANG.XML format

Re: [onap-discuss] SDNC container keeps failing

Re: [onap-discuss] Staging repo in settings.xml

Re: [onap-discuss] [onap-discssus] Tooling for call flow

Re: [onap-discuss] Staging repo in settings.xml

Re: [onap-discuss] Staging repo in settings.xml

Re: [onap-discuss] Versions to use for ONAP

Re: [onap-discuss] Versions to use for ONAP

[onap-discuss] Versions to use for ONAP

Re: [onap-discuss] Git review failing validating Jira issue

Re: [onap-discuss] Git review failing validating Jira issue

[onap-discuss] Git review failing validating Jira issue

Re: [onap-discuss] SDNC container keeps failing

[onap-discuss] [onap-discssus] Tooling for call flow

[onap-discuss] [ONAP] Use Case: VoLTE (vIMS + vEPC)

[onap-discuss] SDNC container keeps failing

17 matches

Site Navigation

Mail list logo

Footer information