Default values are not restored when removing custom values #356

New Issue

2022-09-08T16:47:40Z

pat-s commented

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

(Migrated from gitea.com)

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

(Migrated from gitea.com)

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 commented

2023-02-26 15:50:03 +00:00

(Migrated from gitea.com)

Changing the category as this behavior is a regression of #239.

justusbunsi commented

2024-11-28 19:31:35 +00:00

(Migrated from gitea.com)

https://github.com/go-gitea/gitea/pull/32669 will help us extract all values that must be persistent.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunny/helm-chart#356