[NETCONF-605] Support cache refresh without restart of ODL Created: 26/Jan/19 Updated: 07/Jul/21 |
|
| Status: | Confirmed |
| Project: | netconf |
| Component/s: | netconf |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Medium |
| Reporter: | Brian Freeman | Assignee: | Brian Freeman |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
In Kubernetes enivronment side load of yang models from devices that do not support ietf-netconf-monitorinig appears to be imporssible. Copying files into cache/schema on an nfs mount makes the files available in the container but upon restart of ODL a new container is created that does not see the yang files.
Need a mechanism to recreate the cache index so that the side loaded models can be preserved across container re-creates |
| Comments |
| Comment by Manoj Chokka [ 28/Jan/20 ] |
|
Hi Brian, We are not sure what you meant by "new container". Upon ODL restart does it start a new docker container. In that case pointing the new container towards the proper nfs mount should solve the issue. From what i know, ODL restart which is within a docker container does not bring up a new filesystem, because the namespace is not deleted unless the docker container is deleted/removed. Or are you referring to any other container here? Please let us know your view. BR Manoj |
| Comment by Manoj Chokka [ 11/Feb/20 ] |
|
Hi Brian, A gentle reminder. BR Manoj |
| Comment by Brian Freeman [ 11/Feb/20 ] |
|
I tried to work around this problem by making the cache/schema directory part of an NFS mount but restarting ODL seemed to ignore the files in the directory. Perhaps the helm chart wasnt right but it seemed that ODL created the directory on boot rather than seeing one already there. I'll see if I can re-create the problem |
| Comment by Jamo Luhrsen [ 21/May/20 ] |
|
These directories should remain by a simple karaf stop/start, so maybe something extra is happening in your setup? $ ls -altr cache
total 0
drwxr-xr-x@ 21 jamoluhrsen staff 672 May 20 15:21 ..
drwxr-xr-x 2 jamoluhrsen staff 64 May 20 15:21 schema
drwxr-xr-x 4 jamoluhrsen staff 128 May 20 15:22 .
drwxr-xr-x 176 jamoluhrsen staff 5632 May 20 15:35 34.222.248.49
$ ./bin/karaf
Apache Karaf starting up. Press Enter to open the shell now...
100% [========================================================================]
Karaf started in 7s. Bundle stats: 383 active, 385 total
________ ________ .__ .__ .__ __
\_____ \ ______ ____ ____ \______ \ _____ ___.__.| | |__| ____ | |___/ |_
/ | \\____ \_/ __ \ / \ | | \\__ \< | || | | |/ ___\| | \ __\
/ | \ |_> > ___/| | \| ` \/ __ \\___ || |_| / /_/ > Y \ |
\_______ / __/ \___ >___| /_______ (____ / ____||____/__\___ /|___| /__|
\/|__| \/ \/ \/ \/\/ /_____/ \/
Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown OpenDaylight.
opendaylight-user@root>sleep 120
opendaylight-user@root>logout
$ ls -altr cache
total 0
drwxr-xr-x@ 21 jamoluhrsen staff 672 May 20 15:21 ..
drwxr-xr-x 2 jamoluhrsen staff 64 May 20 15:21 schema
drwxr-xr-x 4 jamoluhrsen staff 128 May 20 15:22 .
drwxr-xr-x 176 jamoluhrsen staff 5632 May 20 15:35 34.222.248.49
$
|
| Comment by Robert Varga [ 02/Jul/21 ] |
|
So the problem is that the cache directory is assumed to be a local directory with a single writer (i.e. it is populated through the exposed Cache's implementation). Strictly speaking this needs a lifecycle hook. bdfreeman1421 since Aluminium a refresh should be possible to affect by restarting this guy:
opendaylight-user@root>scr:info org.opendaylight.netconf.sal.connect.impl.OSGiSchemaResourceManager Component Description: org.opendaylight.netconf.sal.connect.impl.OSGiSchemaResourceManager ========================================================================================== Class: org.opendaylight.netconf.sal.connect.impl.OSGiSchemaResourceManager Bundle: 348 (org.opendaylight.netconf.sal-netconf-connector:2.0.0.SNAPSHOT) Enabled: true Immediate: true Services: [org.opendaylight.netconf.sal.connect.api.SchemaResourceManager] Scope: singleton Config PID(s): [org.opendaylight.netconf.sal.connect.impl.OSGiSchemaResourceManager], Policy: optional Base Props: (0 entries) Component Configuration Id: 216 ------------------------------- State: ACTIVE Service: 434 [org.opendaylight.netconf.sal.connect.api.SchemaResourceManager] Config Props: (2 entries) component.id<Long> = 216 component.name<String> = org.opendaylight.netconf.sal.connect.impl.OSGiSchemaResourceManager References: (total 1) - parserFactory: org.opendaylight.yangtools.yang.parser.api.YangParserFactory SATISFIED 1..1 static target=(*) scope=bundle (1 binding): * Bound to [305] from bundle 224 (org.opendaylight.yangtools.yang-parser-impl:7.0.3) via:
opendaylight-user@root>scr:disable org.opendaylight.netconf.sal.connect.impl.OSGiSchemaResourceManager true opendaylight-user@root>scr:enable org.opendaylight.netconf.sal.connect.impl.OSGiSchemaResourceManager true and should be reflected in the log: 2021-07-02T22:38:10,172 | INFO | SCR Component Actor | OSGiSchemaResourceManager | 185 - org.opendaylight.netconf.sal-netconf-connector - 2.0.0.SNAPSHOT | Schema Resource Manager stopped 2021-07-02T22:38:15,228 | INFO | SCR Component Actor | OSGiSchemaResourceManager | 185 - org.opendaylight.netconf.sal-netconf-connector - 2.0.0.SNAPSHOT | Schema Resource Manager started is that a sufficient non-restart? does it produce the desired result? |
| Comment by Brian Freeman [ 07/Jul/21 ] |
|
I think it would satisfy the no-reboot requriement (assuming the container works the way I think it does). Trying to test it now - I'll update the Jira with results.
|