Date   
Re: [onap-tsc] TSC Election Ballots Distributed

Kenny Paul
 

FINAL REMINDER!

 

Ballots for the 2019 TSC election were  distributed Nov. 5th. Voting ends 22:00 UTC, Nov. 19, 2019.

If you qualified as an Active Community Member and did not receive your ballot, please check your spam folder.

Make sure your spam filter does not block mail from civs@... or you may not receive a ballots in the future.

Ballots can only be resent from the tool, they cannot be sent as a forward from an individual.

 

 

Thanks!

-kenny

 

 

Re: #appc #helm Deploying APP-C using helm chart #appc #helm

Taka Cho
 

I saw your failure was on common/etcd. Did you git pull to the head of master for the all OOM repo?

 

Taka

APPC PTL

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of zychen
Sent: Monday, November 18, 2019 7:40 AM
To: onap-discuss@...
Subject: [onap-discuss] #appc #helm Deploying APP-C using helm chart

 

Hi,

I want to deploy APP-C for testing its capability, and I follow oom_quickstart_guide

And I use Helm 2.16.1, macOS Catalina version 10.15.1

However, after I modified 'appc enable: true' and run 'make all; make onap'. These is always an ERROR about [ERROR] Chart.yaml: apiVersion is required, and Error: aaf chart not found in repo http://127.0.0.1:8879

How could I fix this?

Re: VID support for E2E service ?

Stern, Ittay
 

It is not supported at this time.

 

Ittay

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Aniello Paolo Malinconico
Sent: Monday, November 18, 2019 3:29 PM
To: onap-discuss@...
Subject: [onap-discuss] VID support for E2E service ?

 

Hi all,
I am working on Onap Dublin Release and I want to create a simple service using the e2e workflow.
My question is:
Since on wiki page, I have understood that the VID supports only voLTE use case, is it true?
Can I deploy an e2e service instance via VID GUI? or Do I need to use Postman via REST API?

Thanks,
Aniello Paolo Malinconico

Java 11 (LTS) recommended for ONAP for Frankfurt release

Pawel Pawlak
 

Hello,

Following today’s discussion at the PTL call, I would like to remind you to target Java 11.0.5 with Alpine 3.10.3 for Frankfurt release.

The choice of Java 11 release is due to its Long-term Support (see details: https://en.wikipedia.org/wiki/Java_version_history ).

Please do not consider Java 13 as its support is only till March 2020.

 

We will work on building Java and Alpine container with the Integration Team as discussed at the PTL call.

 

Best regards  

 

Paweł Pawlak

 

ONAP SECCOM Chair

Leader in IT & Network Convergent Operations
FT/TGI/OLN/TOP/OST

 

Orange Polska S.A.

Corporate Services Agency

Obrzeżna 7, 02-691 Warszawa
tel. +48 22 699 52 17
fax +48 22 857 99 86
tel. mob. +48 501 501 030

P   Czy musisz drukować tę wiadomość? Pomyśl o środowisku.
__________________________________________________________________
Treść tej wiadomości jest własnością Orange Polska i zawiera informacje stanowiące tajemnicę przedsiębiorstwa Orange Polska. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Orange Polska Spółka Akcyjna z siedzibą i adresem w Warszawie (02-326) przy Al. Jerozolimskich 160, wpisana do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000010681; REGON 012100784, NIP 526-02-50-995; z pokrytym w całości kapitałem zakładowym wynoszącym 3.937.072.437 złotych.

 

 

VID support for E2E service ?

Aniello Paolo Malinconico
 

Hi all,
I am working on Onap Dublin Release and I want to create a simple service using the e2e workflow.
My question is:
Since on wiki page, I have understood that the VID supports only voLTE use case, is it true?
Can I deploy an e2e service instance via VID GUI? or Do I need to use Postman via REST API?

Thanks,
Aniello Paolo Malinconico

#appc #helm Deploying APP-C using helm chart #appc #helm

zychen
 

Hi,

I want to deploy APP-C for testing its capability, and I follow oom_quickstart_guide

And I use Helm 2.16.1, macOS Catalina version 10.15.1

However, after I modified 'appc enable: true' and run 'make all; make onap'. These is always an ERROR about [ERROR] Chart.yaml: apiVersion is required, and Error: aaf chart not found in repo http://127.0.0.1:8879

How could I fix this?

Re: [CDS] Run CDS locally on elalto branch

MALAKOV, YURIY
 

Hi Michal,

 

In El Alto release, the controller blueprint ms has been consolidated into blueprint processor.

 

 

 

 

 

Yuriy Malakov

SDN-CP Lead Engineer

732-420-3030, Q-Chat

Yuriy.Malakov@...

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Jagiello, Michal
Sent: Monday, November 18, 2019 4:37 AM
To: onap-discuss@...
Subject: [onap-discuss] [CDS] Run CDS locally on elalto branch

 

Hi,

 

I found guide how to run CDS locally (https://wiki.onap.org/display/DW/Running+Blueprints+Controller+Microservice+Locally). It works fine on Dublin branch, but for elalto it’s only possible to build cds-ui and blueprintprocessor, for controllerblueprint microservice there is missing ‘distribution’ directory.

How to run controllerblueprint locally?

 

Thanks,

Michał Jagiełło

T-MOBILE POLSKA S.A. z siedzibą w Warszawie
Adres: ul. Marynarska 12, 02-674 Warszawa
Zarząd Spółki:
Andreas Maierhofer – Prezes Zarządu;
Juraj Andráš – Członek Zarządu, Dyrektor ds. Finansowych;
Dorota Kuprianowicz-Legutko – Członek Zarządu, Dyrektor ds. Polityki Personalnej;
Włodzimierz Nowak – Członek Zarządu, Dyrektor ds. Prawnych, Bezpieczeństwa i Zarządzania Zgodnością;
Frederic Perron – Członek Zarządu, Dyrektor ds. Rynku Prywatnego;
Petri Pehkonen – Członek Zarządu, Dyrektor ds. Technologii i Innowacji;
Agnieszka Rynkowska – Członek Zarządu, Dyrektor ds. Rynku Biznesowego.

Spółka zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie,
XIII Wydział Gospodarczy Krajowego Rejestru Sądowego.
KRS 0000391193 | NIP 526-10-40-567 | Regon 011417295
Kapitał zakładowy 471 mln złotych, kapitał wpłacony w całości.

DUŻE ZMIANY ZACZYNAJĄ SIĘ OD MAŁYCH - CHROŃ PLANETĘ, NIE DRUKUJ TEGO E-MAILA, JEŻELI NIE MUSISZ.

Ta wiadomość i jej treść są zastrzeżone w szczegółowym zakresie dostępnym na http://www.t-mobile.pl/stopka

This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS: see http://www.t-mobile.pl/stopka

[CDS] Run CDS locally on elalto branch

Jagiełło, Michał
 

Hi,

 

I found guide how to run CDS locally (https://wiki.onap.org/display/DW/Running+Blueprints+Controller+Microservice+Locally). It works fine on Dublin branch, but for elalto it’s only possible to build cds-ui and blueprintprocessor, for controllerblueprint microservice there is missing ‘distribution’ directory.

How to run controllerblueprint locally?

 

Thanks,

Michał Jagiełło

T-MOBILE POLSKA S.A. z siedzibą w Warszawie
Adres: ul. Marynarska 12, 02-674 Warszawa
Zarząd Spółki:
Andreas Maierhofer – Prezes Zarządu;
Juraj Andráš – Członek Zarządu, Dyrektor ds. Finansowych;
Dorota Kuprianowicz-Legutko – Członek Zarządu, Dyrektor ds. Polityki Personalnej;
Włodzimierz Nowak Członek Zarządu, Dyrektor ds. Prawnych, Bezpieczeństwa i Zarządzania Zgodnością;
Frederic Perron – Członek Zarządu, Dyrektor ds. Rynku Prywatnego;
Petri Pehkonen – Członek Zarządu, Dyrektor ds. Technologii i Innowacji;
Agnieszka Rynkowska – Członek Zarządu, Dyrektor ds. Rynku Biznesowego.

Spółka zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie,
XIII Wydział Gospodarczy Krajowego Rejestru Sądowego.
KRS 0000391193 | NIP 526-10-40-567 | Regon 011417295
Kapitał zakładowy 471 mln złotych, kapitał wpłacony w całości.

DUŻE ZMIANY ZACZYNAJĄ SIĘ OD MAŁYCH - CHROŃ PLANETĘ, NIE DRUKUJ TEGO E-MAILA, JEŻELI NIE MUSISZ.

Ta wiadomość i jej treść są zastrzeżone w szczegółowym zakresie dostępnym na http://www.t-mobile.pl/stopka

This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS: see http://www.t-mobile.pl/stopka

Re: 答复: [onap-discuss][aai]replace aai-schema-*.jar in schema-service pod

Chuanyu Chen
 

Hi A&AI team,

       Does anyone know how to test the schema change in a real environment by updating jars?

Thanks,

Chuanyu Chen.

 

发件人: onap-discuss@... [mailto:onap-discuss@...] 代表 shashikath
发送时间: 20191114 17:38
收件人: onap-discuss@...
主题: [onap-discuss][aai]replace aai-schema-*.jar in schema-service pod

 

Hi All,

         After modify xml file for schema changes aai-schema-*.jar generated successfully, I want to test changes by replacing this jar in ONAP environment but could not find this jar in schema-service-pod, in which pod I need to replace aai-schema jar to test ?

 

Shashikanth VH

Senior Technical Lead

OpenSource Team,

P&S General Development Branch.

 

Huawei Technologies India Pvt Ltd.

Survey No.37, Next to EPIP Area, Kundalahalli, Whitefield

Bengaluru-560066, Karnataka

Tel:+91-80-49160700 Ext 70139|| Mob: 9902703318 Email:shashikanth.vh@...

 

HuaweiLogs_tiny

 

Re: [oom] Helm 3 (and OpenShift)

Dominic Lunanuova
 

I see a good discussion here, but shouldn’t this idea at least be introduced to  OOM Release Planning before requesting any changes from the general community?

 

-Dom

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of FREEMAN, BRIAN D
Sent: Friday, November 15, 2019 1:14 PM
To: Tal Liron <tliron@...>
Cc: onap-discuss@...
Subject: Re: [onap-discuss] [oom] Helm 3 (and OpenShift)

 

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

Some people dont use an override.yaml file – they directly modify their values.yaml to set environment specific parameters so they would need guidance.

 

I think moving to a new helm is a good thing – just process/infrastructure setup changes need to be complete so we can test and support folks doing this that are sometimes starting with very little supporting infrastructure.

 

Brian

 

 

From: Tal Liron <tliron@...>
Sent: Friday, November 15, 2019 12:57 PM
To: FREEMAN, BRIAN D <bf1936@...>
Cc: onap-discuss@...
Subject: Re: [onap-discuss] [oom] Helm 3 (and OpenShift)

 

Thanks Brian, I didn't entirely understand your reply.

 

At least I was not suggesting a "central repository". I'm suggesting that OOM should not have an opinion about that. If a repository is necessary/useful for the testing process, well, setting that up can be part of the tests. For users of OOM, why do they need a repository at all? They could deploy one if they like. And of course they may already have a chart repository in their organization.

 

On Fri, Nov 15, 2019 at 11:49 AM FREEMAN, BRIAN D <bf1936@...> wrote:

In test we modify the helm charts to change version to load a snapshot and do manual fixes in advance of a patch and in somce cases to test patch sets before they are merged

 

We still need to be able to do that step.

 

We can install a local repository on the nfs server if needed (which is the same as helm serve) but a central repository would be an unacceptable impact on the testing process if we cant make helm chart changes and apply patchsets via git pull/fetch as needed.

 

Brian

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Tal Liron
Sent: Friday, November 15, 2019 12:43 PM
To: onap-discuss <onap-discuss@...>
Subject: [onap-discuss] [oom] Helm 3 (and OpenShift)

 

Hi OOMers,

 

As you may know, Helm 3 was released this week. It changes a lot of things in the way Helm works, most notably getting rid of Tiller (finally).

 

I'm working on getting ONAP running properly on OpenShift, and there are a lot of challenges due to some rather wild assumptions about security being made by some ONAP charts (and containers, really). Hopefully I'll be able to come up with a series of patches and recommendations. Specifically, this also involves moving to Helm 3, because Helm 2 with Tiller doesn't play nicely with OpenShift security. I can help the team if there's interest in learning from my experience.

 

To the issues:

 

First, Helm 3 is a bit stricter in validating the charts, so small errors that exist currently cause breakage. These are papercuts that are easy to fix.

 

The more serious issue is that Helm 3 no longer supports "helm serve" (because it doesn't have Tiller, which was what "helm server" would run locally). The solution is to use a 3rd party chart repository. I had success using ChartMuseum, and can help you set it up. The Makefile needs to be patched for this.

But I also really hope we can revisit this requirement. It's both annoying and not scalable to have to run a local repository. And it shouldn't be necessary. OOM can just provide charts and let the users decide if they want to deploy them to/from a repository (of their choice).

On that note, of course the custom "deploy" plugin also doesn't work with Helm 3. And that's another added complexity that I hope can be revisted and removed. At least in my work I don't use it all.

 

[Onap-usecasesub] PNF Upgrade (UTC 2:00pm) Nov 21, 2019

Zu Qiang
 

Hello, Yaoguang

                The following are the proposed discussion items in the PNF upgrade meeting this week. Please let me know if you have any comments.

  • SO API format discussion - SO-2071 (Yaoguang)
  • SO Decision layer implementation proposed (Henry)
  • SO to APPC client parameters (Raj)
  • AOB

 

Have a nice day

Zu

 

Policy-Drool Maven download stuck El-Alto Release#drools #policy

minsang.yoon@...
 

I was trying to run 'create-cl-amsterdam' script from 'policy-drool' container in ONAP R5 - ElAlto release but it failed because it is stuck in downloading files from maven repository while building maven artifacts. I manually download the file and saved it to the local repository but it stucks in downloading the next files continuously. This is not the problem of our environment or network because I successfully download the same file from other containers like 'policy-pdp' and 'policy-pap'. Does anyone has the same issue or idea about this issue?

Thanks,

Re: [oom] Helm 3 (and OpenShift)

Brian Freeman
 

Some people dont use an override.yaml file – they directly modify their values.yaml to set environment specific parameters so they would need guidance.

 

I think moving to a new helm is a good thing – just process/infrastructure setup changes need to be complete so we can test and support folks doing this that are sometimes starting with very little supporting infrastructure.

 

Brian

 

 

From: Tal Liron <tliron@...>
Sent: Friday, November 15, 2019 12:57 PM
To: FREEMAN, BRIAN D <bf1936@...>
Cc: onap-discuss@...
Subject: Re: [onap-discuss] [oom] Helm 3 (and OpenShift)

 

Thanks Brian, I didn't entirely understand your reply.

 

At least I was not suggesting a "central repository". I'm suggesting that OOM should not have an opinion about that. If a repository is necessary/useful for the testing process, well, setting that up can be part of the tests. For users of OOM, why do they need a repository at all? They could deploy one if they like. And of course they may already have a chart repository in their organization.

 

On Fri, Nov 15, 2019 at 11:49 AM FREEMAN, BRIAN D <bf1936@...> wrote:

In test we modify the helm charts to change version to load a snapshot and do manual fixes in advance of a patch and in somce cases to test patch sets before they are merged

 

We still need to be able to do that step.

 

We can install a local repository on the nfs server if needed (which is the same as helm serve) but a central repository would be an unacceptable impact on the testing process if we cant make helm chart changes and apply patchsets via git pull/fetch as needed.

 

Brian

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Tal Liron
Sent: Friday, November 15, 2019 12:43 PM
To: onap-discuss <onap-discuss@...>
Subject: [onap-discuss] [oom] Helm 3 (and OpenShift)

 

Hi OOMers,

 

As you may know, Helm 3 was released this week. It changes a lot of things in the way Helm works, most notably getting rid of Tiller (finally).

 

I'm working on getting ONAP running properly on OpenShift, and there are a lot of challenges due to some rather wild assumptions about security being made by some ONAP charts (and containers, really). Hopefully I'll be able to come up with a series of patches and recommendations. Specifically, this also involves moving to Helm 3, because Helm 2 with Tiller doesn't play nicely with OpenShift security. I can help the team if there's interest in learning from my experience.

 

To the issues:

 

First, Helm 3 is a bit stricter in validating the charts, so small errors that exist currently cause breakage. These are papercuts that are easy to fix.

 

The more serious issue is that Helm 3 no longer supports "helm serve" (because it doesn't have Tiller, which was what "helm server" would run locally). The solution is to use a 3rd party chart repository. I had success using ChartMuseum, and can help you set it up. The Makefile needs to be patched for this.

But I also really hope we can revisit this requirement. It's both annoying and not scalable to have to run a local repository. And it shouldn't be necessary. OOM can just provide charts and let the users decide if they want to deploy them to/from a repository (of their choice).

On that note, of course the custom "deploy" plugin also doesn't work with Helm 3. And that's another added complexity that I hope can be revisted and removed. At least in my work I don't use it all.

Re: [oom] Helm 3 (and OpenShift)

Tal Liron
 

Thanks Brian, I didn't entirely understand your reply.

At least I was not suggesting a "central repository". I'm suggesting that OOM should not have an opinion about that. If a repository is necessary/useful for the testing process, well, setting that up can be part of the tests. For users of OOM, why do they need a repository at all? They could deploy one if they like. And of course they may already have a chart repository in their organization.


On Fri, Nov 15, 2019 at 11:49 AM FREEMAN, BRIAN D <bf1936@...> wrote:

In test we modify the helm charts to change version to load a snapshot and do manual fixes in advance of a patch and in somce cases to test patch sets before they are merged

 

We still need to be able to do that step.

 

We can install a local repository on the nfs server if needed (which is the same as helm serve) but a central repository would be an unacceptable impact on the testing process if we cant make helm chart changes and apply patchsets via git pull/fetch as needed.

 

Brian

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Tal Liron
Sent: Friday, November 15, 2019 12:43 PM
To: onap-discuss <onap-discuss@...>
Subject: [onap-discuss] [oom] Helm 3 (and OpenShift)

 

Hi OOMers,

 

As you may know, Helm 3 was released this week. It changes a lot of things in the way Helm works, most notably getting rid of Tiller (finally).

 

I'm working on getting ONAP running properly on OpenShift, and there are a lot of challenges due to some rather wild assumptions about security being made by some ONAP charts (and containers, really). Hopefully I'll be able to come up with a series of patches and recommendations. Specifically, this also involves moving to Helm 3, because Helm 2 with Tiller doesn't play nicely with OpenShift security. I can help the team if there's interest in learning from my experience.

 

To the issues:

 

First, Helm 3 is a bit stricter in validating the charts, so small errors that exist currently cause breakage. These are papercuts that are easy to fix.

 

The more serious issue is that Helm 3 no longer supports "helm serve" (because it doesn't have Tiller, which was what "helm server" would run locally). The solution is to use a 3rd party chart repository. I had success using ChartMuseum, and can help you set it up. The Makefile needs to be patched for this.

But I also really hope we can revisit this requirement. It's both annoying and not scalable to have to run a local repository. And it shouldn't be necessary. OOM can just provide charts and let the users decide if they want to deploy them to/from a repository (of their choice).

On that note, of course the custom "deploy" plugin also doesn't work with Helm 3. And that's another added complexity that I hope can be revisted and removed. At least in my work I don't use it all.

Re: [oom] Helm 3 (and OpenShift)

Brian Freeman
 

In test we modify the helm charts to change version to load a snapshot and do manual fixes in advance of a patch and in somce cases to test patch sets before they are merged

 

We still need to be able to do that step.

 

We can install a local repository on the nfs server if needed (which is the same as helm serve) but a central repository would be an unacceptable impact on the testing process if we cant make helm chart changes and apply patchsets via git pull/fetch as needed.

 

Brian

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Tal Liron
Sent: Friday, November 15, 2019 12:43 PM
To: onap-discuss <onap-discuss@...>
Subject: [onap-discuss] [oom] Helm 3 (and OpenShift)

 

Hi OOMers,

 

As you may know, Helm 3 was released this week. It changes a lot of things in the way Helm works, most notably getting rid of Tiller (finally).

 

I'm working on getting ONAP running properly on OpenShift, and there are a lot of challenges due to some rather wild assumptions about security being made by some ONAP charts (and containers, really). Hopefully I'll be able to come up with a series of patches and recommendations. Specifically, this also involves moving to Helm 3, because Helm 2 with Tiller doesn't play nicely with OpenShift security. I can help the team if there's interest in learning from my experience.

 

To the issues:

 

First, Helm 3 is a bit stricter in validating the charts, so small errors that exist currently cause breakage. These are papercuts that are easy to fix.

 

The more serious issue is that Helm 3 no longer supports "helm serve" (because it doesn't have Tiller, which was what "helm server" would run locally). The solution is to use a 3rd party chart repository. I had success using ChartMuseum, and can help you set it up. The Makefile needs to be patched for this.

But I also really hope we can revisit this requirement. It's both annoying and not scalable to have to run a local repository. And it shouldn't be necessary. OOM can just provide charts and let the users decide if they want to deploy them to/from a repository (of their choice).

On that note, of course the custom "deploy" plugin also doesn't work with Helm 3. And that's another added complexity that I hope can be revisted and removed. At least in my work I don't use it all.

[oom] Helm 3 (and OpenShift)

Tal Liron
 

Hi OOMers,

As you may know, Helm 3 was released this week. It changes a lot of things in the way Helm works, most notably getting rid of Tiller (finally).

I'm working on getting ONAP running properly on OpenShift, and there are a lot of challenges due to some rather wild assumptions about security being made by some ONAP charts (and containers, really). Hopefully I'll be able to come up with a series of patches and recommendations. Specifically, this also involves moving to Helm 3, because Helm 2 with Tiller doesn't play nicely with OpenShift security. I can help the team if there's interest in learning from my experience.

To the issues:

First, Helm 3 is a bit stricter in validating the charts, so small errors that exist currently cause breakage. These are papercuts that are easy to fix.

The more serious issue is that Helm 3 no longer supports "helm serve" (because it doesn't have Tiller, which was what "helm server" would run locally). The solution is to use a 3rd party chart repository. I had success using ChartMuseum, and can help you set it up. The Makefile needs to be patched for this.

But I also really hope we can revisit this requirement. It's both annoying and not scalable to have to run a local repository. And it shouldn't be necessary. OOM can just provide charts and let the users decide if they want to deploy them to/from a repository (of their choice).

On that note, of course the custom "deploy" plugin also doesn't work with Helm 3. And that's another added complexity that I hope can be revisted and removed. At least in my work I don't use it all.

AAI GUI not showing new resources #aai

Aniello Paolo Malinconico
 

Hi all,
I am running  the ONAP Dublin version.
I have instantiated a service containing a PNF as the 5G PnP use case without errors.
In fact , I can verify it: 
  1. via VID into "Search for existing services instance" (Found)
  2. via Postman, by making a GET for https://{{k8s}}:30233/aai/v14/network/pnfs/pnf/testPNF_20191115 or querying by the service instance (Found)
  3. via AAI GUI, I cant find any reference to my service or pnf (No results Found)
Anyone can help me?
Where am I wrong?

Thanks a lot,
Aniello Paolo Malinconico

[SDC] How to delete a distributed service modal from SDC.

Sunilkumar Shivangouda Biradar
 

Hi Team,

 

Is there a way to delete/disable a distributed service modal in SDC.

 

Regards,

Sunil B

============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ============================================================================================================================

[ONAP][Integration] component healthcheck test evaluation

Morgan Richomme
 

Hi

according to an action point from last integration weekly meeting, I
added a column in
https://wiki.onap.org/display/DW/0%3A+Integration+Weather+Board+for+Frankfurt+Release

The goal consists in evaluating the robot healthcheck of each
component in order to discuss with the PTLs for possible improvements.
In fact today the robot healthcheck test content differs from one
project to another, we should consider the best practices in order to
improve the overall quality.

Indeed sometimes healthcheck tests are OK even if the component is not
working as expected.
End to end tests are used to go beyond healthcheck tests but the sooner
we get the feedback, the better.


/Morgan

_________________________________________________________________________________________________________________________

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

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

A&AI UI not up ONAP portal

Ranvijay Singh
 

 

Hi Jimmy,

 

1.        I am not able to access A&AI UI from ONAP portal I have followed Portal

2.        PORTAL-653 Jira  also made  all changes as given to this Jira Still not able to access  A&AI UI getting the following error message I attached the screen shot below. A&AAI ONAP community  meeting got cancelled since last two weeks  due to time conflict please response me waiting for appreciable response .

3.         

4.        

5.        

6.      

 

Regards

Ranvijay Singh

 

 

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.