ReloadOnChange of AddJsonFile is invalid in kubernetes.

[expcat]

AB#1282969

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?

As part of the migration of components from dotnet/extensions to dotnet/runtime (aspnet/Announcements#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.

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