Date   
Re: [E] [Onap-arc] Shared VNFs and Services

Gil Bullard <wb5674@...>
 

Ulas,

The term “shareable” can mean many different things in many different contexts, and so I think what is needed here is a more precise definition of what “shareable” means in the context.  Unfortunately I don’t have a precise definition in mind.  I have examples and I have terminology such as “use experience”.  Perhaps others can provide assistance in coming up with a formal definition.

 

But with respect to what I do have…

 

I have found that the examples of “VPN/VRF” and “Firewall” have been useful.

 

Regarding the first example, Wikipedia (the source of all knowledge) defines a VRF as follows:

 

In IP-based computer networks, virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time. One or more logical or physical interfaces may have a VRF and these VRFs do not share routes therefore the packets are only forwarded between interfaces on the same VRF. VRFs are the OSI layer 3 equivalent of a VLAN. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other. Network functionality is improved because network paths can be segmented without requiring multiple routers [1]

 

So VRF technology allows a given Router, call it vRouter_S, to be configured behave as if it were many router NF instances.  In the terminology of my deck, I would say that vRouter_B has been coded with the ability to provide multiple “router experiences” through configuration.   Now compare that to another Router, call it vRouter_D, that doesn’t support VRF technology.  Of course from one perspective, vRouter_D is “shared” in the sense that it participates in the routing and forwarding of many packets and sessions from many different endpoints and networks.  But I am using term “shareable” for the purposes of my deck to differentiate VNFs like vRouter_S from vRouter_D.  I.e., I am using the term “shareable” to refer to a VNF that has been coded with the ability to provide multiple “experiences” of a particular type.

 

Regarding the second example, imagine a single NF, call it Shareable_FW VNF, that has been coded to allow multiple instances of independent “firewall rules table sets” to co-exist within that same NF at the same time.  So for this VNF, both Coke and Pepsi could have their “firewall experience” provided through configuration of a single VNF instance without any compromise in security.  I would refer to Shareable_FW VNF as being “shareable”.  Contrast that to another NF, call it Dedicated_FW VNF that has not been coded in this way, but rather has been coded with only a single “firewall rules table set”.  So for this VNF, the Service Provider would need to create separate instances of Dedicated_FW VNF for Coke and for Pepsi in order for them both to have their respective “firewall experiences”.  This is, in fact, the example I used in my deck.

 

Hope this helps.

Gil   

 

 

 

From: Ulas Kozat <ukozat@...>
Sent: Thursday, June 06, 2019 1:49 PM
To: onap-discuss@...; BULLARD, GIL <wb5674@...>; fernando.oliveira@...; Srini <srinivasa.r.addepalli@...>
Cc: onap-arc@...
Subject: RE: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services

 

Hi Gil,

 

Could you clarify why a non-shareable VNF/PNF can only support one slice instance (hence one slice type)? I would imagine that a VNF/PNF instance out of the box may be able to support both eMBB or URLLC slice types. At least for gNB whether virtualized or not, I expect this to be the norm.

 

Also, I would think it should be the access policies in the control plane not the NF implementation itself should render an NF shareable or not in practice. A network function is typically designed to serve multiple network flows (and hence almost always shareable from the traffic flows perspective). Thus it can be wrapped around by a proper network controller and be shared among services/users/access groups. Or it can be dedicated to a particular service/user/access group. Could you clarify if I misunderstood or misapplied your comment on “shareability” as an intrinsic feature of NF?

 

Thanks,

 

Ulas

 

---------------------------------------------------------------------------------------------------------------------------------------

Ulas C. Kozat, Ph.D.

Futurewei Technologies, Inc.

2330 Central Expressway

Santa Clara, CA 95050

Tel:       +1-408-330-5143

Fax:      +1-408-330-5088

E-mail: ukozat@...

---------------------------------------------------------------------------------------------------------------------------------------

This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Gil Bullard via Lists.Onap.Org
Sent: Thursday, June 6, 2019 10:01 AM
To: fernando.oliveira@...; Srini <srinivasa.r.addepalli@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services

 

To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded.  If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration.  In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time.  In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance.  (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.

 

How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance.

Gil

 

 

From: fernando.oliveira@... <fernando.oliveira@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

Hi Srini,

                My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves.   An  NF instance of a SBA “5G service” would register with the NRF declaring  which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance.  The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s).  A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices  as well as other slice(s).

Regards,

Fred

 

From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

Hi,

 

As  I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs.  In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs.  I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?

 

Reason for asking is this:

 

  • In network slicing, there is a possibility that a given VNF is sharable only across set of network slices.  For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.

 

How does designers/administrator provide the access control information on the sharing aspect?

 

Thanks
Srini

 

 

[SO] RE: Regarding the cloud-owner issue.

Marcus G K Williams <marcus.williams@...>
 

Hi Seshu,

 

I am hoping to have a better idea about the issue today. If I need more help I’ll be sure to ask via email and the JIRA. Look for a JIRA update and code fix in a few hours.

 

Thanks,

 

Marcus Williams

IRC, Twitter, etc. @ mgkwill

Intel Corp.

 

From: Seshu m [mailto:seshu.kumar.m@...]
Sent: Thursday, June 6, 2019 8:55 AM
To: Williams, Marcus <marcus.williams@...>
Subject: Regarding the cloud-owner issue.

 

Hi Marcus

Thanks for the update on SO-1955. May I know the eta and if any help is needed on the issue.

Thanks and Regards,

M Seshu Kumar

Senior System Architect
Utraffic,  Software BU
Huawei Technologies India Pvt. Ltd.

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

Bengaluru-560066, Karnataka.

Tel: + 91-80-49160700 , Mob: 9845355488
____________________________________________________________________________________

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

Re: [E] [Onap-arc] Shared VNFs and Services

Rene Robert
 

Hello,


in addition, that means, when receiving a service slice order, there is a necessity to check if a VNF is already instantiated and if it remains some capacity to add an alloted service on it.


I suggest to add the capacity to link some instantiation rules to each part of a service, to be evaluated each time a service order is received by ONAP. And it is no limited to Slice services but a generic need.


René Robert

Orange


Envoyé depuis mon smartphone Xperia de Sony



---- Gil Bullard a écrit ----

To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded.  If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration.  In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time.  In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance.  (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.

 

How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance.

Gil

 

 

From: fernando.oliveira@... <fernando.oliveira@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

Hi Srini,

                My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves.   An  NF instance of a SBA “5G service” would register with the NRF declaring  which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance.  The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s).  A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices  as well as other slice(s).

Regards,

Fred

 

From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

Hi,

 

As  I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs.  In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs.  I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?

 

Reason for asking is this:

 

  • In network slicing, there is a possibility that a given VNF is sharable only across set of network slices.  For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.

 

How does designers/administrator provide the access control information on the sharing aspect?

 

Thanks
Srini

 

 

_________________________________________________________________________________________________________________________

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.

Re: [AAF] aaf-sms x509 certificate problem in Casablanca

Kiran Kamineni
 

I have added a jira with step by step instructions on how to do this here:

 

https://jira.onap.org/browse/AAF-848

 

-- K i r a n

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Brian
Sent: Thursday, June 06, 2019 5:51 AM
To: onap-discuss@...; huangxiangyu5@...
Subject: Re: [onap-discuss] [AAF] aaf-sms x509 certificate problem in Casablanca

 

The aaf-sms team has a DRAFT procedure on the wiki

 

https://wiki.onap.org/display/DW/Modifying+SMS+helm+Charts+to+override+the+builtin+certificates

 

 

I suspect we need to use Secret instead of ConfigMap for the volumes per :

https://wiki.onap.org/display/DW/Modify+APPC+Helm+Chart+to+override+the+pk12+certificate

 

the APPC method has been tested but obviously the specific name and file references are different for the aaf-sms certificate.

 

Brian

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of harry huang
Sent: Thursday, June 06, 2019 6:34 AM
To: onap-discuss@...
Subject: [onap-discuss] [AAF] aaf-sms x509 certificate problem in Casablanca

 

Hi AAF team,

 

I have observed  health check failure of aaf sms in Casablanca and it seems to be a certificate problem.

Kiran Kamineni has submitted patch https://gerrit.onap.org/r/#/c/oom/+/89190/ to updated certificates for SMS in master.

But this doesn’t work for Casablanca.

Is there a solution to fix problem in Casablanca ? Thanks in advance.

 

Regards,

Harry

 

Re: [E] [Onap-arc] Shared VNFs and Services

Ulas Kozat
 

Hi Gil,

 

Could you clarify why a non-shareable VNF/PNF can only support one slice instance (hence one slice type)? I would imagine that a VNF/PNF instance out of the box may be able to support both eMBB or URLLC slice types. At least for gNB whether virtualized or not, I expect this to be the norm.

 

Also, I would think it should be the access policies in the control plane not the NF implementation itself should render an NF shareable or not in practice. A network function is typically designed to serve multiple network flows (and hence almost always shareable from the traffic flows perspective). Thus it can be wrapped around by a proper network controller and be shared among services/users/access groups. Or it can be dedicated to a particular service/user/access group. Could you clarify if I misunderstood or misapplied your comment on “shareability” as an intrinsic feature of NF?

 

Thanks,

 

Ulas

 

---------------------------------------------------------------------------------------------------------------------------------------

Ulas C. Kozat, Ph.D.

Futurewei Technologies, Inc.

2330 Central Expressway

Santa Clara, CA 95050

Tel:       +1-408-330-5143

Fax:      +1-408-330-5088

E-mail: ukozat@...

---------------------------------------------------------------------------------------------------------------------------------------

This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Gil Bullard via Lists.Onap.Org
Sent: Thursday, June 6, 2019 10:01 AM
To: fernando.oliveira@...; Srini <srinivasa.r.addepalli@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services

 

To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded.  If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration.  In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time.  In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance.  (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.

 

How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance.

Gil

 

 

From: fernando.oliveira@... <fernando.oliveira@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

Hi Srini,

                My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves.   An  NF instance of a SBA “5G service” would register with the NRF declaring  which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance.  The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s).  A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices  as well as other slice(s).

Regards,

Fred

 

From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

Hi,

 

As  I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs.  In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs.  I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?

 

Reason for asking is this:

 

-          In network slicing, there is a possibility that a given VNF is sharable only across set of network slices.  For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.

 

How does designers/administrator provide the access control information on the sharing aspect?

 

Thanks
Srini

 

 

Re: R3 OOM - APPC CDT certificate_unknown #appc #casablanca #oom

Taka Cho
 

Great!

 

Appreciated your work for APPC

 

Taka

 

From: jkzcristiano <jkzcristiano@...>
Sent: Thursday, June 6, 2019 12:40 PM
To: CHO, TAKAMUNE <tc012c@...>; onap-discuss@...
Subject: Re: [onap-discuss] R3 OOM - APPC CDT certificate_unknown #appc #casablanca #oom

 

Dear Taka,

thank you for updating the wiki!

I tried to ping & curl from appc container before without success. I was able to ping to pod's IP (10.42...) but when you ping to "aaf-locate.onap" it is resolving the service IP (10.43...).
Yes it seems my setup entered in some inconsistent state in that regard.

Yes, the "enableAAF: false" setting allows me to work with CDT fine again.

Thank you Taka!
Xoan

Re: [E] [Onap-arc] Shared VNFs and Services

Gil Bullard <wb5674@...>
 

To add to what Vimal and Fred said, a VNF is “shareable” or not based on the way it is coded.  If a VNF is onboarded as “shared” it is onboarded as such because it is coded with the ability to be “shared” through configuration.  In the 5G case, as Fred’s example illustrates, it is the VNF configuration that drives how many slice instances an instance of that VNF will support at any given point in time.  In the case of a non-shareable VNF that supports slicing, an instance of the VNF itself could support only a single slice instance; configuration of the VNF would only determine the characteristics of that single slice instance.  (Presumably only core NFs, and not RAN NFs, would be “dedicated” to a single slice instance.

 

How a UE discovers a slice instance to use for a particular application purpose is out of the scope of the ONAP management of the NF that provides that slice instance, whether via a dedicated or shared NF instance.

Gil

 

 

From: fernando.oliveira@... <fernando.oliveira@...>
Sent: Thursday, June 06, 2019 12:52 PM
To: Srini <srinivasa.r.addepalli@...>; BULLARD, GIL <wb5674@...>
Cc: onap-arc@...; onap-discuss@...
Subject: Re: [E] [Onap-arc] Shared VNFs and Services

 

Hi Srini,

                My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves.   An  NF instance of a SBA “5G service” would register with the NRF declaring  which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance.  The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s).  A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices  as well as other slice(s).

Regards,

Fred

 

From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

Hi,

 

As  I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs.  In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs.  I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?

 

Reason for asking is this:

 

  • In network slicing, there is a possibility that a given VNF is sharable only across set of network slices.  For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.

 

How does designers/administrator provide the access control information on the sharing aspect?

 

Thanks
Srini

 

 

Re: [E] [Onap-arc] Shared VNFs and Services

FERNANDO OLIVEIRA
 

Hi Srini,

                My understanding is that the in 5G SBA, sharing access control is enforced by the “configuration” of the NFs themselves.   An  NF instance of a SBA “5G service” would register with the NRF declaring  which slice(s) it has been configured to support. When another NF asks the NRF for an instance of a particular “5G service”, it also passes the slice(s) that need to be supported by that “service” instance.  The NRF would select an appropriate NF instance of that “5G service” that has support for the requested slices(s).  A non-shared NF instance would be configured with only the dedicated slice(s) while the shared NF instances would be configured with the dedicated slices  as well as other slice(s).

Regards,

Fred

 

From: <onap-arc@...> on behalf of Srini <srinivasa.r.addepalli@...>
Date: Thursday, June 6, 2019 at 11:55 AM
To: "gil.bullard@..." <gil.bullard@...>
Cc: "onap-arc@..." <onap-arc@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [E] [Onap-arc] Shared VNFs and Services

 

Hi,

 

As  I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs.  In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs.  I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?

 

Reason for asking is this:

 

  • In network slicing, there is a possibility that a given VNF is sharable only across set of network slices.  For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.

 

How does designers/administrator provide the access control information on the sharing aspect?

 

Thanks
Srini

 

 

Re: R3 OOM - APPC CDT certificate_unknown #appc #casablanca #oom

jkzcristiano
 

Dear Taka,

thank you for updating the wiki!

I tried to ping & curl from appc container before without success. I was able to ping to pod's IP (10.42...) but when you ping to "aaf-locate.onap" it is resolving the service IP (10.43...).
Yes it seems my setup entered in some inconsistent state in that regard.

Yes, the "enableAAF: false" setting allows me to work with CDT fine again.

Thank you Taka!
Xoan

Shared VNFs and Services

Srini
 

Hi,

 

As  I understand from Tuesday architecture meeting that Networking slicing is one use case for Shared VNFs.  In some cases, each slice would have dedicated VNF instances and in some cases, there are shared VNFs and shared PNFs.  I understand from your presentation on how to represent the shared VNF in the model (during design time). What I did not see is on how the consumer would request for the VNF to be dedicated or use the shared one Or is it that if the VNF is onboarded as ‘shared’, is it always shared?

 

Reason for asking is this:

 

-        In network slicing, there is a possibility that a given VNF is sharable only across set of network slices.  For example, network slices belonging to an Enterprise can share the VNF, but not with network slices of other Enterprises.

 

How does designers/administrator provide the access control information on the sharing aspect?

 

Thanks
Srini

 

 

Re: R3 OOM - APPC CDT certificate_unknown #appc #casablanca #oom

Taka Cho
 

I uploaded stateful.yaml and secrets.yaml in the wiki page, those two yamls are working in SB02 in windriver lab. The p12 file should be located at resources/config/certs

 

Can you go into APPC docker try curl https://aaf-locate.onap:8095/locate/AAF_NS.service:2.0 ? or ping that? I am thinking something DNS is wrong in your k8s

 

So the “enableAAF: false” setting is working for you?

 

Taka

 

From: jkzcristiano <jkzcristiano@...>
Sent: Thursday, June 6, 2019 10:53 AM
To: CHO, TAKAMUNE <tc012c@...>; onap-discuss@...
Subject: Re: [onap-discuss] R3 OOM - APPC CDT certificate_unknown #appc #casablanca #oom

 

Dear Taka and all,

some feedback here.

The first time I followed your wiki.

The original file is (case A):

ubuntu@rancher:~/oom/kubernetes$ cat appc/templates/secrets.yaml

# Copyright © 2018  AT&T, Amdocs, Bell Canada Intellectual Property.  All rights reserved.

#

# Licensed under the Apache License, Version 2.0 (the "License");

# you may not use this file except in compliance with the License.

# You may obtain a copy of the License at

#

#

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an "AS IS" BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

 

apiVersion: v1

kind: Secret

metadata:

  name: {{ include "common.fullname" . }}

  namespace: {{ include "common.namespace" . }}

  labels:

    app: {{ include "common.fullname" . }}

    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}

    release: {{ .Release.Name }}

    heritage: {{ .Release.Service }}

type: Opaque

data:

  db-root-password: {{ .Values.config.mariadbRootPassword | b64enc | quote }}



But I changed it by (case B):

ubuntu@rancher:~/oom/kubernetes$ cat appc/templates/secrets.yaml

# Copyright © 2018  AT&T, Amdocs, Bell Canada Intellectual Property.  All rights reserved.

#

# Licensed under the Apache License, Version 2.0 (the "License");

# you may not use this file except in compliance with the License.

# You may obtain a copy of the License at

#

#

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an "AS IS" BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

 

apiVersion: v1
kind: Secret
metadata:
   name: {{ include "common.fullname" . }}-certs
   namespace: {{ include "common.namespace" . }}
   labels:
     app: {{ include "common.name" . }}
     chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
     release: {{ .Release.Name }}
     heritage: {{ .Release.Service }}
     type: Opaque
data:
{{ tpl (.Files.Glob "resources/config/certs/*").AsSecrets . | indent 2 }}



and make appc, make onap and deployed (update) APPC. This worked in the sense the unknown_certificate issue was solved.

However, I still had the error I told you (some connectivity issue with AAF).

Then I tried to repeat the process by using this file instead:

ubuntu@rancher:~/oom/kubernetes$ cat appc/templates/secrets.yaml

# Copyright © 2018  AT&T, Amdocs, Bell Canada Intellectual Property.  All rights reserved.

#

# Licensed under the Apache License, Version 2.0 (the "License");

# you may not use this file except in compliance with the License.

# You may obtain a copy of the License at

#

#

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an "AS IS" BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

 

apiVersion: v1

kind: Secret

metadata:

  name: {{ include "common.fullname" . }}

  namespace: {{ include "common.namespace" . }}

  labels:

    app: {{ include "common.fullname" . }}

    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}

    release: {{ .Release.Name }}

    heritage: {{ .Release.Service }}

type: Opaque

data:

  db-root-password: {{ .Values.config.mariadbRootPassword | b64enc | quote }}
---
apiVersion: v1
kind: Secret
metadata:
   name: {{ include "common.fullname" . }}-certs
   namespace: {{ include "common.namespace" . }}
   labels:
     app: {{ include "common.name" . }}
     chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
     release: {{ .Release.Name }}
     heritage: {{ .Release.Service }}
     type: Opaque
data:
{{ tpl (.Files.Glob "resources/config/certs/*").AsSecrets . | indent 2 }}


When I tried to update APPC (with make appc, make onap, helm deploy dev-appc ...)  some error came up (kubectl describe pod/dev-appc-appc-0 -n onap):

Events:

  Type     Reason            Age              From               Message

  ----     ------            ----             ----               -------

  Warning  FailedScheduling  6m               default-scheduler  AssumePod failed: pod 3e3c9094-884f-11e9-884b-02394a5c4c27 is in the cache, so can't be assumed

  Normal   Scheduled         6m               default-scheduler  Successfully assigned onap/dev-appc-appc-0 to k8s-dev

  Warning  FailedScheduling  6m (x2 over 6m)  default-scheduler  pod has unbound PersistentVolumeClaims

  Normal   Pulled            5m               kubelet, k8s-dev   Container image "oomk8s/readiness-check:2.0.0" already present on machine

  Normal   Created           5m               kubelet, k8s-dev   Created container

  Normal   Started           5m               kubelet, k8s-dev   Started container

  Warning  Failed            4m               kubelet, k8s-dev   Error: failed to start container "appc": Error response from daemon: oci runtime error: container_linux.go:247: starting container process caued "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"/var/lib/kubelet/pods/3e3c9094-884f-11e9-884b-02394a5c4c27/volume-subpaths/certs/appc/23\\\" to rootfs \\\"/var/lib/docker/afs/mnt/13cb603827f10995f6afad95b98b77ff1959f6cd5c4ae60253909d0e16155403\\\" at \\\"/var/lib/docker/aufs/mnt/13cb603827f10995f6afad95b98b77ff1959f6cd5c4ae60253909d0e16155403/opt/onap/appc/data/stores/org.onapappc.p12\\\" caused \\\"not a directory\\\"\""

: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

 

I tried to create that directory (oom/kubernetes/appc/resources/config/appc/opt/onap/appc/data/stores/
and locating also the file "org.onapappc.p12" there but the same error happened during helm deploy.

So I finally removed all the steps done in your wiki, undeployed/deployed appc with the option

...
appc:
  enabled: true
  config:
    enableAAF: false
...

in the overriding file. I lost some configuration of course but I only had one VNF in CDT so no issue. No APPC is not using AAF.

Kind regards and thank you for your kind help!
Xoan

Re: R3 OOM - APPC CDT certificate_unknown #appc #casablanca #oom

jkzcristiano
 

Dear Taka and all,

some feedback here.

The first time I followed your wiki.

The original file is (case A):

ubuntu@rancher:~/oom/kubernetes$ cat appc/templates/secrets.yaml
# Copyright © 2018  AT&T, Amdocs, Bell Canada Intellectual Property.  All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
 
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "common.fullname" . }}
  namespace: {{ include "common.namespace" . }}
  labels:
    app: {{ include "common.fullname" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
type: Opaque
data:
  db-root-password: {{ .Values.config.mariadbRootPassword | b64enc | quote }}


But I changed it by (case B):

ubuntu@rancher:~/oom/kubernetes$ cat appc/templates/secrets.yaml
# Copyright © 2018  AT&T, Amdocs, Bell Canada Intellectual Property.  All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
 
apiVersion: v1
kind: Secret
metadata:
   name: {{ include "common.fullname" . }}-certs
   namespace: {{ include "common.namespace" . }}
   labels:
     app: {{ include "common.name" . }}
     chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
     release: {{ .Release.Name }}
     heritage: {{ .Release.Service }}
     type: Opaque
data:
{{ tpl (.Files.Glob "resources/config/certs/*").AsSecrets . | indent 2 }}


and make appc, make onap and deployed (update) APPC. This worked in the sense the unknown_certificate issue was solved.

However, I still had the error I told you (some connectivity issue with AAF).

Then I tried to repeat the process by using this file instead:

ubuntu@rancher:~/oom/kubernetes$ cat appc/templates/secrets.yaml
# Copyright © 2018  AT&T, Amdocs, Bell Canada Intellectual Property.  All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
 
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "common.fullname" . }}
  namespace: {{ include "common.namespace" . }}
  labels:
    app: {{ include "common.fullname" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
type: Opaque
data:
  db-root-password: {{ .Values.config.mariadbRootPassword | b64enc | quote }}
---
apiVersion: v1
kind: Secret
metadata:
   name: {{ include "common.fullname" . }}-certs
   namespace: {{ include "common.namespace" . }}
   labels:
     app: {{ include "common.name" . }}
     chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
     release: {{ .Release.Name }}
     heritage: {{ .Release.Service }}
     type: Opaque
data:
{{ tpl (.Files.Glob "resources/config/certs/*").AsSecrets . | indent 2 }}


When I tried to update APPC (with make appc, make onap, helm deploy dev-appc ...)  some error came up (kubectl describe pod/dev-appc-appc-0 -n onap):

Events:
  Type     Reason            Age              From               Message
  ----     ------            ----             ----               -------
  Warning  FailedScheduling  6m               default-scheduler  AssumePod failed: pod 3e3c9094-884f-11e9-884b-02394a5c4c27 is in the cache, so can't be assumed
  Normal   Scheduled         6m               default-scheduler  Successfully assigned onap/dev-appc-appc-0 to k8s-dev
  Warning  FailedScheduling  6m (x2 over 6m)  default-scheduler  pod has unbound PersistentVolumeClaims
  Normal   Pulled            5m               kubelet, k8s-dev   Container image "oomk8s/readiness-check:2.0.0" already present on machine
  Normal   Created           5m               kubelet, k8s-dev   Created container
  Normal   Started           5m               kubelet, k8s-dev   Started container
  Warning  Failed            4m               kubelet, k8s-dev   Error: failed to start container "appc": Error response from daemon: oci runtime error: container_linux.go:247: starting container process caued "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"/var/lib/kubelet/pods/3e3c9094-884f-11e9-884b-02394a5c4c27/volume-subpaths/certs/appc/23\\\" to rootfs \\\"/var/lib/docker/afs/mnt/13cb603827f10995f6afad95b98b77ff1959f6cd5c4ae60253909d0e16155403\\\" at \\\"/var/lib/docker/aufs/mnt/13cb603827f10995f6afad95b98b77ff1959f6cd5c4ae60253909d0e16155403/opt/onap/appc/data/stores/org.onapappc.p12\\\" caused \\\"not a directory\\\"\""
: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
 
I tried to create that directory (oom/kubernetes/appc/resources/config/appc/opt/onap/appc/data/stores/
and locating also the file "org.onapappc.p12" there but the same error happened during helm deploy.

So I finally removed all the steps done in your wiki, undeployed/deployed appc with the option

...
appc:
  enabled: true
  config:
    enableAAF: false
...

in the overriding file. I lost some configuration of course but I only had one VNF in CDT so no issue. No APPC is not using AAF.

Kind regards and thank you for your kind help!
Xoan

Re: #sdc #oom SDC pods are not coming up in ONAP OOM Master setup #sdc #oom

t.puha@...
 

Hi,

 

One thing to note is that the job instances do not wait forever for their pre-requisites, but if they time out a new job will be spawned and eventually it will succeed if it is just a timing issue. I’m running SDC and friends with OOM on my laptop and because it is slower than the timers expect, there are some failures every time I start it again. But retries eventually succeed without any manual intervention. I’m installing every morning and it has succeeded every time eventually after some retries. Here is an output for reference.

 

$ kubectl get pods -n onap

NAME                                         READY   STATUS       RESTARTS   AGE

dev-cassandra-0                              1/1     Running      0          8h

dev-clamp-5b7cb98f88-j85fl                   2/2     Running      6          8h

dev-clamp-dash-es-75b45755cd-r4t89           1/1     Running      1          8h

dev-clamp-dash-kibana-76bd57c94c-tr476       1/1     Running      0          8h

dev-clamp-dash-logstash-68f5bdcfb6-mtprc     1/1     Running      10         8h

dev-clampdb-948bb6897-c6s24                  1/1     Running      0          8h

dev-dbc-pg-0                                 1/1     Running      0          8h

dev-dbc-pg-1                                 1/1     Running      0          8h

dev-dbc-pgpool-69f4cf65fc-25bwh              1/1     Running      0          8h

dev-dbc-pgpool-69f4cf65fc-6r4vm              1/1     Running      0          8h

dev-dmaap-bc-5d9c595c47-6j6hv                0/1     Init:0/2     50         8h

dev-dmaap-bc-post-install-n2qvf              1/1     Running      0          8h

dev-kube2msb-7bd757f666-p7l7h                1/1     Running      0          8h

dev-message-router-0                         1/1     Running      8          8h

dev-message-router-kafka-0                   1/1     Running      2          8h

dev-message-router-kafka-1                   1/1     Running      2          8h

dev-message-router-kafka-2                   1/1     Running      2          8h

dev-message-router-zookeeper-0               1/1     Running      0          8h

dev-message-router-zookeeper-1               1/1     Running      0          8h

dev-message-router-zookeeper-2               1/1     Running      0          8h

dev-msb-consul-56657c465-649pt               1/1     Running      0          8h

dev-msb-discovery-76f58f848d-9rvkm           2/2     Running      0          8h

dev-msb-eag-db4c47c7c-2dzsr                  2/2     Running      0          8h

dev-msb-iag-5678c44574-2cg6r                 2/2     Running      0          8h

dev-sdc-be-5964d4fbdb-x57ts                  2/2     Running      1          8h

dev-sdc-be-config-backend-v65nq              0/1     Completed    0          8h

dev-sdc-cs-config-cassandra-cs6g8            0/1     Completed    0          8h

dev-sdc-dcae-be-586c679996-ncrkq             2/2     Running      0          8h

dev-sdc-dcae-be-tools-th299                  0/1     Completed    0          8h

dev-sdc-dcae-be-tools-vjj5d                  0/1     Init:Error   0          8h

dev-sdc-dcae-be-tools-vpqnm                  0/1     Init:Error   0          8h

dev-sdc-dcae-dt-7d767b7849-tqr95             2/2     Running      0          8h

dev-sdc-dcae-fe-5fbbb5b769-w8526             2/2     Running      0          8h

dev-sdc-dcae-tosca-lab-6bc794b7c9-wwggs      2/2     Running      0          8h

dev-sdc-es-7fff469996-brbwq                  1/1     Running      0          8h

dev-sdc-es-config-elasticsearch-kklbf        0/1     Completed    0          8h

dev-sdc-fe-7d5c9794dd-fntbv                  2/2     Running      0          8h

dev-sdc-kb-5cddb6f7b8-48kk6                  1/1     Running      0          8h

dev-sdc-onboarding-be-68d97cb89f-fhdmh       2/2     Running      0          8h

dev-sdc-onboarding-be-cassandra-init-f6vc6   0/1     Completed    0          8h

dev-sdc-wfd-be-584fbdcb6b-wd788              1/1     Running      7          8h

dev-sdc-wfd-be-workflow-init-khg42           0/1     Completed    0          8h

dev-sdc-wfd-fe-76b85944c4-672zv              2/2     Running      0          8h

dev-webseal-7fdbfb9999-hpr4k                 1/1     Running      0          8h

 

Quite often sdc-be-config-backend-* fails one or two times before succeeding, but this is purely dependent on how much resources you have allocated to your kube. Of course you may have a different problem but getting some errors at startup is often no sign of real trouble.

 

-Timo

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of MALINCONICO ANIELLO PAOLO
Sent: tiistai 4. kesäkuuta 2019 15.08
To: Gopigiri; Sirisha <sirisha.gopigiri@...>; onap-discuss@...
Subject: Re: [onap-discuss] #sdc #oom SDC pods are not coming up in ONAP OOM Master setup

 

You can give a lokk at this: https://lists.onap.org/g/onap-discuss/topic/sdc_be_1_4_0_issue/31822033?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,20,31822033
Remeber to drop sdc-* keyspaces when u undeloy/redeploy the sdc component.

My image versions:

sdc/charts/sdc-dcae-be/values.yaml:30:image: onap/dcae-be:1.3.0

sdc/charts/sdc-dcae-be/values.yaml:32:backendInitImage: onap/dcae-tools:1.3.0

sdc/charts/sdc-wfd-fe/values.yaml:31:image: onap/workflow-frontend:1.4.0

sdc/charts/sdc-wfd-be/values.yaml:31:image: onap/workflow-backend:1.4.0

sdc/charts/sdc-wfd-be/values.yaml:32:configInitImage: onap/workflow-init:1.4.0

sdc/charts/sdc-dcae-dt/values.yaml:30:image: onap/dcae-dt:1.2.0

sdc/charts/sdc-es/values.yaml:34:image: onap/sdc-elasticsearch:1.4.0

sdc/charts/sdc-es/values.yaml:35:elasticInitImage: onap/sdc-init-elasticsearch:1.4.0

sdc/charts/sdc-cs/values.yaml:31:image: onap/sdc-cassandra:1.4.0

sdc/charts/sdc-cs/values.yaml:32:cassandraInitImage: onap/sdc-cassandra-init:1.4.0

sdc/charts/sdc-be/values.yaml:31:image: onap/sdc-backend:1.4.0

sdc/charts/sdc-be/values.yaml:32:backendInitImage: onap/sdc-backend-init:1.4.0

sdc/charts/sdc-onboarding-be/values.yaml:31:image: onap/sdc-onboard-backend:1.4.0

sdc/charts/sdc-onboarding-be/values.yaml:32:onboardingInitImage: onap/sdc-onboard-cassandra-init:1.4.0

sdc/charts/sdc-kb/values.yaml:31:image: onap/sdc-kibana:1.4.0

sdc/charts/sdc-dcae-tosca-lab/values.yaml:30:image: onap/dcae-tosca-app:1.3.0

sdc/charts/sdc-fe/values.yaml:31:image: onap/sdc-frontend:1.4.0

sdc/charts/sdc-dcae-fe/values.yaml:30:image: onap/dcae-fe:1.3.0



My sdc pods:

root@control-plane-1:~/oom_master/kubernetes# kubectl get pods -n onap | grep dev-sdc

dev-sdc-sdc-be-74b5b4d897-rdw82                             2/2     Running            0          168m

dev-sdc-sdc-be-config-backend-6b68w                         0/1     Completed          0          168m

dev-sdc-sdc-cs-config-cassandra-4vrvr                       0/1     Completed          0          168m

dev-sdc-sdc-dcae-be-87bc44ccb-vz88z                         2/2     Running            0          168m

dev-sdc-sdc-dcae-be-tools-nk5g4                             0/1     Completed          0          134m

dev-sdc-sdc-dcae-dt-9f6cdccdf-8ghfk                         2/2     Running            0          168m

dev-sdc-sdc-dcae-fe-8488d8755-vd4h8                         2/2     Running            0          168m

dev-sdc-sdc-dcae-tosca-lab-55d6c76449-dtvgr                 2/2     Running            0          168m

dev-sdc-sdc-es-868875c47d-bmhrw                             1/1     Running            0          168m

dev-sdc-sdc-es-config-elasticsearch-vvbrh                   0/1     Completed          0          168m

dev-sdc-sdc-fe-7bd7f7cb4d-sv92l                             2/2     Running            0          168m

dev-sdc-sdc-kb-57689fbf6-fbr8q                              1/1     Running            0          168m

dev-sdc-sdc-onboarding-be-c7c58696f-mj828                   2/2     Running            0          168m

dev-sdc-sdc-onboarding-be-cassandra-init-sqsll              0/1     Completed          0          168m

dev-sdc-sdc-wfd-be-668b94bf68-c8zgg                         1/1     Running            0          168m

dev-sdc-sdc-wfd-be-workflow-init-kwzgt                      0/1     Completed          0          168m

dev-sdc-sdc-wfd-fe-74dcf95cb7-8cwm2                         2/2     Running            0          168m

 


Aniello Paolo Malinconico

 

  

Re: [SDC] Invoke SDC on-boarding APIs from postman

Brian Freeman
 

Look at robot/testsuite for onboarding/model distribution.

 

./demo-k8s.sh onap init

 

Does API onboarding of the basic models vFWCL, vLB, vCPE

 

Brian

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Syed Atif Husain
Sent: Thursday, June 06, 2019 1:46 AM
To: onap-discuss@...
Subject: [onap-discuss] [SDC] Invoke SDC on-boarding APIs from postman

 

Hi,

 

What user credentials should we use in order to invoke SDC Service On-boarding APIs from Postman?

I tried creating a consumer but I guess that is for SDC’s external APIs only (e.g. Distribution APIs)

 

I am trying to access the internal APIs using postman:

 

createService() in org.openecomp.sdc.be.servlets.ServiceServlet

 

 

Regards,

Atif

 

Re: Need help! - Ability to onboard a VNF and Network Service using API's or CLI's

Brian Freeman
 

Ramesh,

 

I dont think what you want to do has been done before. You would have to reverse engineer the CSAR packages if you dont use SDC. And the re-create the SDC-BE distribution code that does distribution.

 

SDC can be run anywhere as long as it can reach your DMaaP instance (can be via a node port).

 

SDC has API’s for model onboarding that can be used for more items – look at robot / testsuite for examples for a mix of VNF and network types.

 

Perhaps others have better advice.

 

Brian

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Ramesh T
Sent: Thursday, June 06, 2019 1:53 AM
To: Addepalli, Srinivasa R <srinivasa.r.addepalli@...>; onap-discuss@...
Subject: Re: [onap-discuss] Need help! - Ability to onboard a VNF and Network Service using API's or CLI's

 

Hi Srini,

 

Thank you so much!

 

Our intention is not to deploy workloads across multiple K8S clusters at this point. Our intention is to onboard Network services and VNF’s in a single K8S cluster only, but through API’s without using design time framework which helps us achieving the following.

  1. It uses less H/W resources for the cluster.
  2. It helps us with further integration with external tools for onboarding
  3. It helps to test repeatedly and automate the onboarding.

 

Let me know if anyone has tried out. Even no one has tried out, it would be great if you point us to some documentation to start with, so that we can try and contribute the steps back to the community.

 

Regards,

Ramesh

 

From: Addepalli, Srinivasa R [mailto:srinivasa.r.addepalli@...]
Sent: Wednesday, June 5, 2019 8:15 AM
To: onap-discuss@...; Thangamuthu, Ramesh <ramesh.thangamuthu@...>
Subject: RE: Need help! - Ability to onboard a VNF and Network Service using API's or CLI's

 

Hi,

 

It is more involved and I am not sure anybody tried that out before. 

 

But, if you are looking to deploy workloads in multiple K8S based clouds/edges from ONAP, then it is possible to use without SDC and SO as the support is added keeping modularity in mind. Let us know if you are interested in trying that out.

 

Thanks

Srini

 

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Ramesh T
Sent: Tuesday, June 4, 2019 12:27 AM
To: onap-sdc@...; onap-discuss@...
Subject: [onap-discuss] Need help! - Ability to onboard a VNF and Network Service using API's or CLI's

 

Hello,

 

We are in the process of setting up ONAP. We would like to completely disable ONAP Design Time Framework (like SDC) and would like to onboard VNF and Network services using API’s or CLI’s. We would like to clarify the following.

 

  1. Is it possible to onboard a VNF’s and a Network Service without the help of design time framework?
  2. If so, it is through API’s or CLI’s?
  3. If possible, can you point us to the documentation where we can start with?

 

End objective is that, we would like to setup only ONAP Runtime environment and try out.

 

Regards,

Ramesh

Re: [AAF] aaf-sms x509 certificate problem in Casablanca

Brian Freeman
 

The aaf-sms team has a DRAFT procedure on the wiki

 

https://wiki.onap.org/display/DW/Modifying+SMS+helm+Charts+to+override+the+builtin+certificates

 

 

I suspect we need to use Secret instead of ConfigMap for the volumes per :

https://wiki.onap.org/display/DW/Modify+APPC+Helm+Chart+to+override+the+pk12+certificate

 

the APPC method has been tested but obviously the specific name and file references are different for the aaf-sms certificate.

 

Brian

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of harry huang
Sent: Thursday, June 06, 2019 6:34 AM
To: onap-discuss@...
Subject: [onap-discuss] [AAF] aaf-sms x509 certificate problem in Casablanca

 

Hi AAF team,

 

I have observed  health check failure of aaf sms in Casablanca and it seems to be a certificate problem.

Kiran Kamineni has submitted patch https://gerrit.onap.org/r/#/c/oom/+/89190/ to updated certificates for SMS in master.

But this doesn’t work for Casablanca.

Is there a solution to fix problem in Casablanca ? Thanks in advance.

 

Regards,

Harry

 

R: [onap-discuss] R: [onap-discuss] VID certificate problem

Mangiapane Benedetto <benedetto.mangiapane@...>
 

Hi Stern,

Yes I not able to found service model from VID from SDC.

 

Paolo, I tried to change the VID release, and I solve the connection problems but on the VID I

still don't find the Service Models.

 

 

 

Instead with version 3.2.3 it gave no error, but found nothing

 

Benedetto

 

Da: Stern, Ittay <ittay.stern@...>
Inviato: giovedì 6 giugno 2019 14:11
A: onap-discuss@...; aniello.malinconico@...; Mangiapane Benedetto <benedetto.mangiapane@...>
Oggetto: RE: [onap-discuss] R: [onap-discuss] VID certificate problem

 

(1)

VID 4.3.0, 4.2.0, and 3.2.3 are all using the same TLS certificates.

Still I suggest to avoid using Casablanca release with VID 4.x, as it’s not compatible in some use-cases.

 

(2)

It is expected that portal’s certificate is of unknown issuer. These are certificates issues by AAF, not trusted by your regular CA authorities.

 

(3)

Do you experience any usability issue, along with the logging and wget problems?

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of MALINCONICO ANIELLO PAOLO
Sent: Thursday, June 6, 2019 2:55 PM
To: Mangiapane Benedetto <benedetto.mangiapane@...>; onap-discuss@...
Subject: Re: [onap-discuss] R: [onap-discuss] VID certificate problem

 

I am using the image vid:4.2.0 and all works fine.
Try to use the same version .

Aniello Paolo Malinconico

Internet Email Confidentiality Footer ** La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge vigente (ad es. art. 616 C.P., D.Lgs n. 196/2003 Codice Privacy, Regolamento Europeo n. 679/2016/GDPR). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. Al link seguente e' disponibile l'informativa Privacy: http://www.italtel.com/it/about/privacy/ ** This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. Click here to read your privacy notice: http://www.italtel.com/it/about/privacy/

Re: #sdc #oom SDC pods are not coming up in ONAP OOM Master setup #sdc #oom

Gopigiri, Sirisha
 

Thank you Aniello. It worked.

Regards
Sirisha Gopigiri

#oom #aaf AAF Pods not coming up #oom #aaf

Gopigiri, Sirisha
 

Hi All,

I am trying to install ONAP Master using OOM(I am doing a redeploy. first did helm undepoy and then removed the /docker-nfs folder and then did a helm deploy). I could see the aaf-service pod is failing to start as it is unable to connect to cassandra I believe. Here are the log:

2019-06-06 12:12:50,333 WARN [init] 2019-06-06T12:12:50.333+0000 INIT [init] Cassandra is using Default Policy, which is not DC aware
2019-06-06 12:12:50,602 WARN [init] 2019-06-06T12:12:50.602+0000 INIT [init] Instantiating DAOs
com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: localhost/127.0.0.1:9042 (com.datastax.driver.core.exceptions.TransportException: [localhost/127.0.0.1:9042] Cannot connect))
    at com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:268)
    at com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:107)
    at com.datastax.driver.core.Cluster$Manager.negotiateProtocolVersionAndConnect(Cluster.java:1652)
    at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1571)
    at com.datastax.driver.core.Cluster.init(Cluster.java:208)
    at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:376)
    at com.datastax.driver.core.Cluster.connect(Cluster.java:332)
    at org.onap.aaf.auth.dao.AbsCassDAO.getSession(AbsCassDAO.java:434)
    at org.onap.aaf.auth.dao.AbsCassDAO.getSession(AbsCassDAO.java:394)
    at org.onap.aaf.auth.dao.cass.CacheInfoDAO.init(CacheInfoDAO.java:333)
    at org.onap.aaf.auth.dao.cass.CacheInfoDAO.<init>(CacheInfoDAO.java:83)
    at org.onap.aaf.auth.dao.hl.Question.<init>(Question.java:152)
    at org.onap.aaf.auth.service.AAF_Service.<init>(AAF_Service.java:99)
    at org.onap.aaf.auth.service.AAF_Service.main(AAF_Service.java:229)

Am I missing any configuration?

Thank you in advance!

Regards
Sirisha Gopigiri

Re: R: [onap-discuss] VID certificate problem

Ittay Stern
 

(1)

VID 4.3.0, 4.2.0, and 3.2.3 are all using the same TLS certificates.

Still I suggest to avoid using Casablanca release with VID 4.x, as it’s not compatible in some use-cases.

 

(2)

It is expected that portal’s certificate is of unknown issuer. These are certificates issues by AAF, not trusted by your regular CA authorities.

 

(3)

Do you experience any usability issue, along with the logging and wget problems?

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of MALINCONICO ANIELLO PAOLO
Sent: Thursday, June 6, 2019 2:55 PM
To: Mangiapane Benedetto <benedetto.mangiapane@...>; onap-discuss@...
Subject: Re: [onap-discuss] R: [onap-discuss] VID certificate problem

 

I am using the image vid:4.2.0 and all works fine.
Try to use the same version .

Aniello Paolo Malinconico