Runtime: ReloadOnChange of AddJsonFile is invalid in kubernetes.

[expcat]

Describe the bug

I tried to bind config.json in kubernetes with configmap volumeMounts.
When I modify the config.json in the configmap, the contents of the config.json in the container are the same as those in the configmap (delay about 10 seconds after the modification will be synchronized to the container), but there is no change in the program.

To Reproduce

This is my test code https://github.com/expcat/configmap-test
I use configmap-test.yaml to run it in the internal kubernetes test.

Expected behavior

curl localhost/api/values response value returned should be consistent with the contents of config.json.

Screenshots

When the container is initialized:

After modification the configmap(delay about 10 sec):

Additional context

kubernetes ver: 1.13.3
asp.net core ver: 2.2.2

English is not my native language. Please forgive me if any wrong expression.

[expcat]

I use dotnet run to run on my computer.

PS E:\k8s\configmap> curl http://localhost:5000/api/values | Select Content

Content
-------
["v1"]


PS E:\k8s\configmap> curl http://localhost:5000/api/values | Select Content

Content
-------
["v1.2"]

[expcat]

Only use docker run, the result changes with the modification mapping file config.json.
It seems that the problem is the configmap in kubernetes.

[muratg]

Yeah, as long as the json file is there, it should work the same way it does elsewhere. Were you able to figure out the configmap issue?

[muratg]

You can try this to see if your config.json file is there:

• Run kubectl exec -it PODNAME bash to get a shell at your pod (replace PODNAME with your pod name.)
• Go the the folder with your app and ls to see if the file is there.

[expcat]

@muratg thank you for your reply.
The operation in the screenshot above is to run in the pod.
I use putty to enter the pod again and run ls like this.

The config.json file is there and the content has changed, but the value of getting the binding from the api has not changed.

[fbeltrao]

Hi @ajcvickers, any update on this?
Came across the same issue. Would love an update :)

[ajcvickers]

@fbeltrao This issue is in the Backlog milestone. This means that it is not going to happen for the 3.0 release. We will re-assess the backlog following the 3.0 release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[fbeltrao]

I came up with a solution while we wait for a fix:
https://github.com/fbeltrao/ConfigMapFileProvider

[syedhassaanahmed]

@ajcvickers Now that 3.0 is GA, any update on the fix?

[fstugren]

Ha! I just ran into this issue myself. I built this web application which consumes a configuration file deployed via a configmap. The configuration has to be tweaked often enough to justify adding support for automatic config updates, so that the pod won't have to be redeployed or killed and restarted each time the configuration changes. Setting this up in .NET core 2.2 was easy enough (although I had to work around some issues with singletons), but sadly, after the local testing proved the update model worked fine I deployed the AKS pod with high hopes only to be sorely disappointed. A quick search brought me here. I am sure there's workarounds to this - like the file content monitor mentioned by an earlier comment - but it would be great to have this feature work natively.

Thanks
F.

[expcat]

Is it in 5.0 plan?

[msftbot[bot]]

As part of the migration of components from dotnet/extensions to dotnet/runtime (https://github.com/aspnet/Announcements/issues/411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days.

If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help!

[expcat]

I think this should not be closed.

[msftbot[bot]]

Paging @dotnet/extensions-migration ! This issue has been revived from staleness. Please take a look and route to the appropriate repository.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[peacecwz]

@ajcvickers any update? I got this same issue in .NET Core 3.1. We can't develop Cloud Native Application:(

[RainingNight]

any news?

[btbensoft]

+1

[expcat]

This issue has the most 👀 in the opened issues of this repo.
Is there any plan to fix it in 6.0?

[maryamariyan]

Is there any plan to fix it in 6.0?

Will try to fix this in 6.0

[davidfowl]

This is likely because the file watcher when running in a container is busted. Did you try setting the environment variable DOTNET_USE_POLLING_FILE_WATCHER=true

[expcat]

I tried to add environment variables, the result did not change.
k8s-yaml:

      containers:
        - name: configmap-test
          image: expcat/configmap-test:1.2
          env: 
            - name: DOTNET_USE_POLLING_FILE_WATCHER
              value: "true"

Inside the container:

root@configmap-test-7b8f7b4777-td65r:~# echo $DOTNET_USE_POLLING_FILE_WATCHER
true
root@configmap-test-7b8f7b4777-td65r:~# cat /src/conf/config.json
{
  "config": {
    "message": "v1.1"
  }
}
root@configmap-test-7b8f7b4777-td65r:~# curl localhost/api/values
["v1"]

[jasper-d]

I looked into it a few weeks ago. As far as I remember, the problem is that PollingFileChangeToken relies on FileInfo to check for changes to the file (i.e. last write time). FileInfo internally uses lstat syscall instead of stat (there is actually a call to stat but only to determine if the symlink target is a directory) and hence does not follow symlinks (which are used by Kubernetes for Secrets and ConfigMaps that are mounted as files).

I tried to fix it by providing my own implementation of IPollingChangeToken using Mono.Unix.Native.Syscall.stat, but gave up because currently the entire PhysicalFileProvider would need to be reimplemented (stuff is hard-wired inside there).

There is a related issue for FileSystemWatcher #25078, #24271 would probably help when implementing a fix.

[maryamariyan]

There is a related issue for FileSystemWatcher #25078, #24271 would probably help when implementing a fix.

Also linking to https://github.com/dotnet/runtime/issues/37664
cc: @carlossanlop @Jozkee