Re: How to #install #policy #drools #drools-applications controller in #production environment #policy #production #kubernetes #install #drools


Jorge Hernandez
 

Hello Samuli,

 

The “beijing” controller is an experimental one that was introduced during the Beijing release to experiment with more efficient ways to bring control loops to live, but it is not the official controller for the use cases as of now.

 

The official one is the “amsterdam” controller (note the naming convention is the release name on which the controller was introduced).   After an install if you query the drools controller for the

 

In an ONAP installation, the “amsterdam” controller should be preloaded, the caveat is that it won’t have “control loop” operational policies preloaded (as they are with a heat-based installation).   It would require an additional step to load them.    See “push-policies” step in https://wiki.onap.org/display/DW/Policy+on+OOM.   This page may shed some light in your questions.

 

If you are playing with the exp. “Beijing” controller,  and not the official “amsterdam” you can enable it by doing “features enable controlloop-beijing” on a drools container, you could embed that line in an initialization script, if you want the drools container/pod to come up with it enabled.

 

Jorge

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Samuli Silvius
Sent: Tuesday, September 04, 2018 8:14 AM
To: onap-discuss@...; rudolf@...
Subject: Re: [onap-discuss] How to #install #policy #drools #drools-applications controller in #production environment #kubernetes

 

Hi,

 

I do not have problems to install drools pod itself. Just looking for way to install “policy controller” e.g. Beijing controller inside drools pod in the official way.

 

Br

-Samuli

 

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Rudolf Amirjanyan
Sent: sunnuntai 2. syyskuuta 2018 22.33
To: onap-discuss@...; s.silvius@...
Subject: Re: [onap-discuss] How to #install #policy #drools #drools-applications controller in #production environment #kubernetes

 

I have same problem when installing the policy component of ONAP.

All other containers () of <Policy> component are normally installed except the <policy-BBBBB-drools-0> 

just in case I am pasting the outup of kubectl describe command. Note instead of BBBB it the name is <bring>

-------------------------------------->

 

root@serv2:/home/noc# kubectl describe pod policy-bring-drools-0
Name:           policy-bring-drools-0
Namespace:      default
Node:           noc3/41.220.208.14
Start Time:     Sat, 01 Sep 2018 23:46:21 +0300
Labels:         app=drools
                controller-revision-hash=policy-bring-drools-57d4bccd5d
                release=policy-bring
                statefulset.kubernetes.io/pod-name=policy-bring-drools-0
Annotations:    <none>
Status:         Running
IP:             10.42.20.107
Controlled By:  StatefulSet/policy-bring-drools
Init Containers:
  drools-readiness:
    Container ID:  docker://b40d5d4b4a031d084607394114fe10267c9e71fdcbc162235651debd798a3355
    Image:         oomk8s/readiness-check:2.0.0
    Image ID:      docker-pullable://oomk8s/readiness-check@sha256:7daa08b81954360a1111d03364febcb3dcfeb723bcc12ce3eb3ed3e53f2323ed
    Port:          <none>
    Command:
      /root/ready.py
    Args:
      --container-name
      policydb
      --container-name
      nexus
    State:          Terminated
      Reason:       Completed
      Exit Code:    0

      Started:      Sun, 02 Sep 2018 01:40:32 +0300
      Finished:     Sun, 02 Sep 2018 01:40:33 +0300
    Ready:          True
    Restart Count:  1
    Environment:
      NAMESPACE:  default (v1:metadata.namespace)
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-25wrf (ro)
Containers:
  drools:
    Container ID:  docker://4b85c59da5abff406afe4057d1ce9150a92d4263173b565ec3dab9e7d96e3955
    Image:         nexus3.onap.org:10001/onap/policy-drools:1.3-SNAPSHOT-latest
    Image ID:      docker-pullable://nexus3.onap.org:10001/onap/policy-drools@sha256:16320bdf545954e8ce8ae8c9064541e924f320cf4aca81f1ca83b1f9ae25e253
    Ports:         6969/TCP, 9696/TCP
    Command:
      /bin/bash
      -c
      ./do-start.sh
    State:          Running
      Started:      Sun, 02 Sep 2018 22:23:16 +0300
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Sun, 02 Sep 2018 22:19:24 +0300
      Finished:     Sun, 02 Sep 2018 22:23:05 +0300
    Ready:          False
    Restart Count:  188
    Liveness:       tcp-socket :6969 delay=180s timeout=1s period=10s #success=1 #failure=3
    Readiness:      tcp-socket :6969 delay=60s timeout=1s period=10s #success=1 #failure=3
    Environment:
      REPLICAS:  1
    Mounts:
      /etc/localtime from localtime (ro)
      /tmp/logback.xml from policy-logback (rw)
      /tmp/policy-install/config/apps-install.sh from drools-config (rw)
      /tmp/policy-install/config/base.conf from drools-config (rw)
      /tmp/policy-install/config/drools-preinstall.sh from drools-config (rw)
      /tmp/policy-install/config/drools-tweaks.sh from drools-config (rw)
      /tmp/policy-install/config/feature-healthcheck.conf from drools-secret (rw)
      /tmp/policy-install/config/feature-pooling-dmaap.conf from drools-config (rw)
      /tmp/policy-install/config/policy-management.conf from drools-config (rw)
      /usr/share/maven/conf/settings.xml from drools-settingsxml (rw)
      /var/log/onap from policy-logs (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-25wrf (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  localtime:
    Type:  HostPath (bare host directory volume)
    Path:  /etc/localtime
  filebeat-conf:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      policy-bring-filebeat-configmap
    Optional:  false
  policy-logs:
    Type:    EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium: 
  policy-data-filebeat:
    Type:    EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium: 
  policy-logback:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      policy-bring-drools-log-configmap
    Optional:  false
  drools-settingsxml:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      policy-bring-drools-settings-configmap
    Optional:  false
  drools-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      policy-bring-drools-configmap
    Optional:  false
  drools-secret:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  policy-bring-drools-secret
    Optional:    false
  default-token-25wrf:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-25wrf
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                  From           Message
  ----     ------     ----                 ----           -------
  Normal   Killing    27m (x184 over 19h)  kubelet, noc3  Killing container with id docker://drools:Container failed liveness probe.. Container will be killed and recreated.
  Warning  BackOff    7m (x2149 over 19h)  kubelet, noc3  Back-off restarting failed container
  Warning  Unhealthy  2m (x3027 over 19h)  kubelet, noc3  Readiness probe failed: dial tcp 10.42.20.107:6969: getsockopt: connection refused
root@serv2:/home/noc#

<-------------------------------------------

 

 

On 08/31/2018 04:39 PM, Samuli Silvius wrote:

Hi,

 

I’m working on Beijing branch of ONAP and looking for a method to install policy controllers in kubernetes (production environment).

 

Policy project has this https://onap.readthedocs.io/en/beijing/submodules/policy/engine.git/docs/platform/installBeijingController.html as an official documentation for installing e.g. Beijing controller.

Modifying running containers is not very sustainable solution as whenever container is created again from image (which happens easily in Kunernetes environment) all changes are lost.

 

Is there a designed way in Kubernetes to do policy controller installation e.g. with some volume mount and install automated at startup? Or should we create own drools image to bundle controller ready installed?

 

Br

-Samuli

 

Image removed by sender.

 

-- 
 

 

 

  

Image removed by sender.

Join onap-discuss@lists.onap.org to automatically receive all group messages.