add ability to export non-base config from ui for a certain config file

Carey Black 3:02 PM
I think the “UI config export” function only exports values in the DB?
A: Is that correct?
B: Is that expected?
C: If A=Yes, and B=Yes, then Any chance it could become a comprehensive/“effective values” file instead (in addition)?

Marwan Shaher 3:16 PM
+1 for C
a more definite answer will be from the dev team, but I think A is Yes. B is also Yes because the other parameters would come either from the “base” properties files or from overlay files baked into the image or mapped to the container. Encrypted values like passwords are exported as ****, not as their encrypted values. Again, I think the idea as explained somewhere in the wiki is to be able to save these into version control (edited)

Marwan Shaher 3:22 PM
the comprehensive export may not be used for importing back though unless the import functionality is completely reworked to recognize a parameter/value no matter what file it belongs to

Chris Hyzer 3:29 PM
Everyone please put config in DB :slightly_smiling_face: Yes its expected. I guess we could have an export for non-DB/non-Base configs at some point

Carey Black 3 days ago
It is on my TODO list. I think I am finally at the point that I am comfortable with it.
I would describe my current state as “in progress”.
Very few, but some of the config is in the DB. ( Which is admittedly not an ideal state either. )
:thinking_face:

Chris Hyzer 3 days ago
Its very liberating when you get there :slightly_smiling_face:

Chad Redman 3 days ago
I have a gsh script (of course ) that gets everything if someone is interested. It can filter on patterns and config origin too

Ryan Rumbaugh 3 days ago
I hesitate adding configs to the database because we have refreshed our production Grouper db to our test system and it was almost no impact because our configs are in Docker. If the configs were in the db then we would need to modify them using SQL? before starting the test system.

Erik Coleman 3 days ago
I think the biggest use-case for an export for us is to keep an "escrowed" copy of the current configuration for DR. Although more painful to update, at least before the file-based configs were tracked as Github revisions. But with the "liberating" ability to make on-the-fly database changes, there could be config drift that might not be recoverable if we were to have to re-spawn the database from scratch, not because we don't have a backup, but we might want to replicate our production config for testing. (edited)
:+1:
1

Chris Hyzer 3 days ago
I think some configs you will want to move over. Kind of need to go case by case. Also if external systems come from env vars then that helps too

Chris Hyzer 3 days ago
Dont you keep a DB backup for DR? If its in the DB, it will be there :slightly_smiling_face:

Erik Coleman 3 days ago
We do, I meant if we want to spawn a replica of the config for a brand-new instance for some sort of QA testing or whatnot. That's the cool thing about containers, but we could use an export of the config as a bootstrap for the new instance.

Chris Hyzer 3 days ago
would be nice if we had two buckets for DB config, one that is institution-wide, and one that is env-specific. We do have that flexibility built into the database structure, but need to put that in the UI and import/export. At some point we can flesh that idea out more
:heavy_plus_sign:
3
:grouper:
1

Erik Coleman 2 days ago
We've partially solved that with environment variables, but they only go so far, and it seems like some config entries don't support the Elconfig class to pull variables.

Chris Hyzer 2 days ago
what doesnt support elconfig?

Zachary Hanson-Hart 1 day ago
I've only seen Grouper as a container, and from the moment local prodding got a working config to allow us to log in to the ui, it has been deployed with gitlab-ci to a kubernetes cluster. The config files are deployed as a configMap, and mounted by all of the containers. We update the configmap when changes are made in version control. Changing config through the UI in prod is a no-no for us, because that configuration change is not reflected in version control (and DB value are lower priority than file values for us there!). Chris says it's possible to get the history from Grouper, but that's not our typical config management/version control system :wink: Don't get me wrong, being able to change the config in the UI is a fantastic feature (and the main benefit I see of config in the DB). We use the UI to poke at config changes in dev frequently. It's just that when we're happy with it, we put it in the appropriate config file in version control, and delete the value in the UI. (Being able to spit out the resulting non-default values would be super helpful for our use case). Our automated deployment takes care of the "keeping the files in sync" part that's often touted as the other major win of config in the DB. When the maturity level gets to a point that includes automated deployments, keeping the configuration in files make a lot of sense again.