Default values are not restored when removing custom values #356

New Issue

pat-s · 2022-09-08T16:47:40Z

pat-s commented

2022-09-08 16:47:40 +00:00

I've got bitten by the following behavior recently and I think this might be something the helm chart could (eventually) take care of:

Change/define an arbitrary (disclaimer: I did not test others than the one reported below) value in app.ini that is different from the defaults
Remove that definition again

At this point I would expect the value to be removed from app.ini. Instead it stays in app.ini (after (2)) and is (silently) applied to the instance.

In particular I found out about this via service.ENABLE_BASIC_AUTHENTICATION while going crazy why user/pass auth did not work for git auth.
I finally found that in my app.ini in the running instance there was ENABLE_BASIC_AUTHENTICATION=false set even though this setting was not applied in the helm chart values (anymore) and it defaults to TRUE actually.

I could then reproduce the behavior from above. In fact the only thing that helped was manually entering the pod and deleting ENABLE_BASIC_AUTHENTICATION = false to get rid of it. An alternative is to actively set it back to the default again.

In summary: removing an app.ini that was once changed does not restore it's default. Looks like a bug to me? Should be easily reproducible for others using the description above.

TODO list for fixing this: (probably incomplete)

Drop explicit default resets from #585
Consider values coming from additionalConfigSources

I've got bitten by the following behavior recently and I think this might be something the helm chart could (eventually) take care of: 1. Change/define an arbitrary (disclaimer: I did not test others than the one reported below) value in `app.ini` that is different from the [defaults](https://docs.gitea.io/en-us/config-cheat-sheet/) 1. Remove that definition again At this point I would expect the value to be removed from `app.ini`. Instead it stays in `app.ini` (after (2)) and is (silently) applied to the instance. In particular I found out about this via `service.ENABLE_BASIC_AUTHENTICATION` while going crazy why user/pass auth did not work for git auth. I finally found that in my `app.ini` in the running instance there was `ENABLE_BASIC_AUTHENTICATION=false` set even though this setting was *not* applied in the helm chart values (anymore) and it defaults to `TRUE` actually. I could then reproduce the behavior from above. In fact the only thing that helped was manually entering the pod and deleting `ENABLE_BASIC_AUTHENTICATION = false` to get rid of it. An alternative is to actively set it back to the default again. In summary: removing an `app.ini` that was once changed does not restore it's default. Looks like a bug to me? Should be easily reproducible for others using the description above. --- TODO list for fixing this: (probably incomplete) - [ ] Drop explicit default resets from #585 - [ ] Consider values coming from `additionalConfigSources`

justusbunsi commented

2022-09-08 18:21:46 +00:00

I've reproduced it a few times in the past. To me it seems like a regression from #239. Prior to this PR the app.ini got fully recreated. Now it persists to keep some important immutable settings. I see two ways to fix this:

Implement a ini-to-environment script (other direction than the existing environment-to-ini) that allows us to extract the immutable fields and recreate the whole app.ini from scratch using these values
Store the immutable values inside an automatically created Kubernetes secret and create the app.ini from scratch using these values

The second one would require a migration to extract those values from app.ini, if not provided via values.yaml. Which sounds like we would need option 1 to get 2. ?

I've reproduced it a few times in the past. To me it seems like a regression from #239. Prior to this PR the app.ini got fully recreated. Now it persists to keep some important immutable settings. I see two ways to fix this: - Implement a ini-to-environment script (other direction than the existing environment-to-ini) that allows us to extract the immutable fields and recreate the whole app.ini from scratch using these values - Store the immutable values inside an automatically created Kubernetes secret and create the app.ini from scratch using these values The second one would require a migration to extract those values from app.ini, if not provided via values.yaml. Which sounds like we would need option 1 to get 2. ?

justusbunsi added the

kind

enhancement

label 2022-09-23 13:01:36 +00:00

justusbunsi referenced this issue

2023-02-26 15:48:43 +00:00

Unable to switch gitea.config.server.PROTOCOL back to http from https without deleting pod #344

justusbunsi added

kind

bug

and removed

kind