Date   

#portal (Dublin) Portal Maria DB creation constantly fails #portal

Andreas Geissler
 

Hi all,
in my labs I install every day the ONAP Master build and have always the problem, that the Portal installation fails.
As you see below, the Maria DB is always restarted during the initial startup before the needed portal and user tables are created.
The second start will detect a crash, but cannot repair the DB.
2019-06-06 15:25:15 140122898007936 [Note] Starting crash recovery...
2019-06-06 15:25:15 140122898007936 [Note] Crash recovery finished.
2019-06-06 15:25:15 140122898007936 [Note] Server socket created on IP: '::'.
2019-06-06 15:25:15 140122898007936 [ERROR] mysqld: Table './mysql/user' is marked as crashed and should be repaired
2019-06-06 15:25:15 140122898007936 [ERROR] mysqld: Table 'user' is marked as crashed and should be repaired
2019-06-06 15:25:15 140122898007936 [Warning] Checking table:   './mysql/user'
2019-06-06 15:25:15 140122898007936 [ERROR] mysql.user: 1 client is using or hasn't closed the table properly
2019-06-06 15:25:15 140122898007936 [Warning] 'proxies_priv' entry '@% root@dev-portal-portal-db-5f5c7c957b-j4twh' ignored in --skip-name-resolve mode.
2019-06-06 15:25:15 140122898007936 [ERROR] mysqld: Table './mysql/time_zone_name' is marked as crashed and should be repaired
2019-06-06 15:25:15 140122898007936 [ERROR] mysqld: Table 'time_zone_name' is marked as crashed and should be repaired

Therefor portal-app fails to start...

DB Image is: /onap/portal-db:2.5.0
Readyness and Liveness initial timeouts I already extended to 900s without success.

I had this problem in early days as well, obviously related to timing problems of the NFS share.
In Casablanca the problem disappeared, but now it is back again.

Any help would be appreciated
Best regards
Andreas

root@onap-hp-onap-oom-ci-rancher:~# kubectl get pods -n onap|grep portal
dev-portal-portal-app-5c8879d9df-jh8lw                        0/2     Init:0/1           101        17h
dev-portal-portal-cassandra-75b76758bc-jsgsp                  1/1     Running            0          17h
dev-portal-portal-db-5f5c7c957b-j4twh                         1/1     Running            1          17h
dev-portal-portal-db-config-2spz9                             0/2     Completed          0          16h
dev-portal-portal-db-config-fz56r                             0/2     Completed          0          16h
dev-portal-portal-db-config-gzs7j                             0/2     Init:Error         0          17h
dev-portal-portal-db-config-h2svk                             0/2     Completed          0          17h
dev-portal-portal-db-config-pqvxc                             0/2     Completed          0          16h
dev-portal-portal-db-config-qm2b8                             0/2     Completed          0          16h
dev-portal-portal-db-config-thkg6                             0/2     Completed          0          16h
dev-portal-portal-sdk-cf768557-sks9c                          2/2     Running            0          17h
dev-portal-portal-widget-784b57ff47-s54sr                     1/1     Running            0          17h
dev-portal-portal-zookeeper-57d8fcc5f9-qqwnc                  1/1     Running            0          17h


Instllation of ONAP in RANCHER

David Darbinyan
 

hi Gurus

seems with Dublin version the installation of ONAP using Rancher is not in list of "recommended" if I want to use clustering on my own hardware servers?
Is Openstack the only way for that type? I cannot find requirement for Rancher version (if it's still actual) .
Pls advice







все
adjective: все, весь, целый, всякий, возможный
noun: все, целое, все имущество
pronoun: все, весь, вся
adverb: совершенно, всецело, вполне


Integration lab

Yang Xu
 

Dear all,


Integration runs into serious lab resource constraints during the past two weeks, and now is the critical time to keep a reliable testing environment before final Dublin delivery. If you can release some lab resource for the next two weeks, that would be greatly appreciated. You can still run tests using Integration tenants as always.


Below are the heavy users in Integration lab, please try your best to reduce your resource usage.  


wrs_sgooch@pod-onap-01-vjhost:~$ openstack usage list

Usage from 2019-05-08 to 2019-06-06:

+--------------------------------+---------+--------------+-----------+---------------+

| Project                        | Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours |

+--------------------------------+---------+--------------+-----------+---------------+

| CC-SDK                         |      15 | 163372661.23 |  49995.11 |     999902.15 |

| DCAE                           |      23 | 235339585.53 |  88031.93 |    1760638.58 |

| APPC                           |      20 | 170655605.88 |  83327.93 |    1666558.65 |

| Integration-SB-04              |      42 |  35951456.26 |  17554.42 |     351088.44 |

| A & AI                         |       7 | 110100390.89 |  37631.97 |     752639.39 |

| Infrastructure                 |       2 |   4764953.82 |   2326.64 |      46532.75 |

| Integration-SB-01              |      25 | 125009922.83 |   61040.0 |    1220800.03 |

| DMaaP                          |      14 | 220200781.78 |  75263.94 |    1505278.78 |

| VIM                            |      19 |  42947155.14 |  15594.29 |     285005.92 |

| Integration-HEAT-Staging-Daily |       2 |  44040156.36 |  10751.99 |     215039.83 |

| admin                          |       7 |  22327019.86 |  10901.87 |         893.3 |

| PFPP                           |       2 |  27525097.72 |   8063.99 |     161279.87 |

| AAF                            |       9 | 132120469.07 |  48383.96 |     967679.22 |

| OOF                            |      16 | 111889131.07 |  54633.36 |     1092667.3 |

| Microservices                  |       5 |  41287646.58 |  14783.99 |     295679.76 |

| vCPE                           |       7 |  35782627.04 |  17471.99 |     349439.72 |

| Integration-SB-02              |      27 |   28720008.3 |  14023.44 |     280468.83 |

| SO                             |       3 |  33030117.27 |  16127.99 |     322559.74 |

| Logging                        |       5 |   99090351.8 |  26879.98 |     537599.56 |

| SDC                            |       1 |  11010039.09 |    5376.0 |     107519.91 |

| Integration-SB-00              |      32 | 112568163.02 |  54964.92 |    1099298.47 |

| policy-k8s                     |       8 |   99090351.8 |  32255.97 |     645119.48 |

| Holmes                         |       1 |  11010039.09 |    5376.0 |     107519.91 |

| VFC                            |      16 | 154140547.25 |  75263.94 |    1505278.78 |

| OOM-deploy                     |       4 |  19083264.57 |  12263.71 |     186360.01 |

| OOM                            |      28 | 368836309.48 | 137087.89 |    2741757.78 |

+--------------------------------+---------+--------------+-----------+---------------+


Regards,

-Yang






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

Ulas Kozat
 

Hi Gil,

 

I think I understand your examples and definition from “use experience” point of view. Though, I find it a bit constrained in terms of reusability of the same network function in different scenarios.

 

To have a further thought exercise, consider an OpenFlow switch with a single instance of a flow table (or cascade of tables). Consider another function external to the switch implementation (e.g., FlowVisor) that can partition the switch ports and/or flow space to provide distinct virtual OpenFlow switches to distinct network controllers. Each network controller thinks that it has its own dedicated OpenFlow switch.

 

From the “use experience” point of view, I can instantiate:

(1)    an OpenFlow network for Coke as a dedicated network with a group of OpenFlow switches and Coke controller.

Or,

(2)    an OpenFlow network as a shared network between Coke and Pepsi with a group of shared OpenFlow switches, a shared FlowVisor function and one controller for Coke, another controller for Pepsi. To make this a bit more complicated, we can also configure the FlowVisor dynamically via a close-loop optimization in ONAP to change the share of the network among the controllers.

 

Clearly, OpenFlow switches as network functions are only usable by a single experience in (1) while they can be used by multiple experiences in (2). Thus, it was not the implementation but how I bundled that function in a network service made it “shareable”. If I have to follow your definitions, then I must expose OpenFlow switches and FlowVisor as a single shareable VNF which looks very coarse grain to me.

 

Similar examples can be given in 5G context as well.

 

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: BULLARD, GIL [mailto:wb5674@...]
Sent: Thursday, June 6, 2019 2:34 PM
To: Ulas Kozat <ukozat@...>; onap-discuss@...; fernando.oliveira@...; Srini <srinivasa.r.addepalli@...>
Cc: onap-arc@...
Subject: RE: [onap-discuss] [E] [Onap-arc] Shared VNFs and Services

 

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

 

 


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 <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