I am running 1.1.1 OOM.
With the update to /dockerdata-nfs push-policy script change suggested by Marco
to pull from amsterdam, it didn't work with 1.1. ( ?h=amsterdam change)
I still see the GET error on update policy run after restarting the policy
pods, confirming policy script was updated (BRCM dependency version matches
1.1.1)
Logging into the pdp pod to check /var/log/onap/pdp rest logs, shows a bunch of
errors which seem to indicate policy deployment issues mailed by Hernandez in
the context of 1.1.2 though I am running 1.1.1.
Interesting.
I will just move to OOM 1.1.3 with a pull before retrying since the service
distribution issue along with this issue pointed by Marco has been fixed.
Another thing I wanted to point out that restarting ONAP k8s pods with
/dockerdata-nfs data present takes a long time with create-config.
I know its not required to re-create onap-config if shared data is already
present but I think its better to change the brute force find approach in
config-init scripts to avoid touching database files (huge files when
/dockerdata-nfs already exists) that takes forever to run the config sed update.
Maybe something like this in config-init.sh for all the finds:
find /config-init/$NAMESPACE/ -type f -exec sed -i -e
"s/\.onap-/\.$NAMESPACE-/g" {} \;
Could be changed to:
find /config-init/$NAMESPACE/ -path */conf/* -type f -exec sed -i -e
"s/\.onap-/\.$NAMESPACE-/g" {} \;
so it targets only conf locations.
Anyway will update OOM to the latest amsterdam which I presume moves images to
1.1.3 and retry this.
Regards,
-Karthick
________________________________
From: Alexis de Talhouët <[email protected]>
Sent: Thursday, January 25, 2018 12:00:36 PM
To: HERNANDEZ-HERRERO, JORGE
Cc: Ramanarayanan, Karthick; [email protected]
Subject: [**EXTERNAL**] Re: [onap-discuss] Demo update-vfw policy script when
running without closed loop
Finish testing, it does fix the issue. Thanks,
Alexis
On Jan 25, 2018, at 2:28 PM, Alexis de Talhouët
<[email protected]<mailto:[email protected]>> wrote:
Just put up a fix for this:
https://gerrit.onap.org/r/#/c/29209/<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_c_29209_&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=tSozxmdVdWRPEu-VVg5W8GPZRVdlDF6rNcLEDuI2sT0&s=CD7KkXWCkl21E9HBM4YgVy3zQB04xeBot60UMzmtE6w&e=>
Trying it now.
On Jan 25, 2018, at 2:13 PM, Alexis de Talhouët
<[email protected]<mailto:[email protected]>> wrote:
This is tracked by
https://jira.onap.org/browse/OOM-611<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_OOM-2D611&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=tSozxmdVdWRPEu-VVg5W8GPZRVdlDF6rNcLEDuI2sT0&s=b0i_-u5XHMG1sPVJqAzZQ_uiA3O0Dels6DPu2E1ad_c&e=>
Currently, OOM uses 1.1.1
Alexis
On Jan 25, 2018, at 2:07 PM, HERNANDEZ-HERRERO, JORGE
<[email protected]<mailto:[email protected]>> wrote:
Hi Karthick,
With regards to policy, cannot tell you in the context of kubernetes, but we
had a bug introduced in v1.1.2 policy docker images that was resolved with
v1.1.3. The error shown in the text below indicates that the automated
deployment of operational policies wasn’t successful which was one of the
symptoms of the problems with v1.1.2. First thing to check is if you are
using the latest 1.1.3 images and latest amsterdam policy/docker repo?
Jorge
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Ramanarayanan,
Karthick
Sent: Thursday, January 25, 2018 12:33 PM
To: [email protected]<mailto:[email protected]>
Subject: [onap-discuss] Demo update-vfw policy script when running without
closed loop
Hi,
In my kubernetes setup minus dcae (just vFW without closed loop),
I am trying to mount the appc packetgen interface but I am unable to see the
mounts in appc mounts list.
The policy that was pushed used the kubernetes update-vfw-op-policy.sh script
which seems to be applicable for closed loop.
Though the policy script runs and applies the policy and restarts the policy
pods, the get on controlloop.Params fails at the end.
curl -v --silent --user @1b3rt:31nst31n -X
GEThttp://$<https://urldefense.proofpoint.com/v2/url?u=http-3A__-24&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=AOclne09odx6cmeimzFUhQ&m=Bd5eoa3uty8tqL8D1Fb0okmmu11-xtxLkLjCshykLdc&s=WCU7ohmqRfVOzWP7sz-1iJpYWrm20PbhK4fXhDV_v-Y&e=>{K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
| python -m json.tool
{
"error": "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params
not found"
}
Moving ahead, I configure the packet gen interface with an appc put to network
topology for the packetgen vnf/ip.
Put succeeds but appc mounts doesn't show up.
Wondering if the policy script needs to be changed when executing without
closed loop?
What am I missing?
Thanks,
-Karthick
_______________________________________________
onap-discuss mailing list
[email protected]<mailto:[email protected]>
https://lists.onap.org/mailman/listinfo/onap-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=tSozxmdVdWRPEu-VVg5W8GPZRVdlDF6rNcLEDuI2sT0&s=agWjRKxvLK1ulSwLVPO8SaeCb8WlHdOLi-wvRihyi1g&e=>
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
