Reconfigure overwrites Mattermost settings made in System Console

On the Mattermost side I think what we need is a command line option for GitLab to inject in just the settings it needs rather than overwriting config.json.

Let me circle back to see if I can find a ticket.

Okay, we just created a Help Wanted ticket for the updates to the Mattermost CLI tool that can help with this.

We have from now until late December to get this in for Mattermost 3.6 releasing Jan 16th.

@it33 I've linked an existing issue that you created on GitHub in the description: https://github.com/mattermost/platform/issues/4178

@marin What do you think about the CLI option?

Ah, sorry, yeah, I thought we had a ticket for this. The idea of GitLab trying to parse config.json makes less sense in my mind than Mattermost just adding support for config params via our CLI.

We already talked about the CLI option as the way to go but I cannot find the issue where we discussed this. I think that is the best move forward, pass flags at start and let omnibus-gitlab not manage config.json.

Mentioned in issue #1704 (closed)

mentioned in issue #1919 (closed)

Comment from @it33 on #1919 (closed)

Possible Fixes:

Instead of discarding Mattermost's config.json file when GitLab omnibus upgrades Mattermost, follow the embedded install and upgrade procedure in Mattermost documentation to backup and restore Mattermost config.json settings using a common tool like sed, with updates to only the gitlab.rb settings (e.g. database, GitLab SSO, etc.) needed for maintaining connectivity.

Until this is implemented can someone add a warning to https://docs.gitlab.com/omnibus/gitlab-mattermost/?

@marin, we talked about the CLI option at Mattermost and it was declined on account of people considering the parsing of configuration files as standard, with sed for example.

The procedure for upgrading embedded versions of Mattermost is now part of a program we're creating to certify installers that deploy and upgrade Mattermost: https://docs.mattermost.com/guides/orchestration.html#upgrade

Could you share more on the issues with using a sed command or similar tool for updating config.json from omnibus?

mentioned in issue #2062 (closed)

Personally I ensure gitlab.rb has all the Mattermost settings I want to persist between upgrades, so this is not an issue for me.

That said, for retaining GUI settings in config.json, have the omnibus team considered injecting values from gitlab.rb into config.json with Augeas? That's what I do with my Mattermost Puppet module here: https://gitlab.com/harbottle/puppet-mattermost/blob/master/templates/config.json.erb

Any values in the override_options hash are injected into config.json by Augeas without disturbing other values that are already in there.

After every omnibus package upgrade we have to skim trough all settings in Mattermost and set up almost everything anew. My proposition is this: maybe Mattermost team could add an option to parse two configuration files. Let's say config.json and config-local.json. Settings from config-local.json would overwrite those from config.json. That way, user settings from system console would go to config.json and applications like GitLab could write their own values to config-local.json. Or the other way around - system console writes to config-local.json and default settings stay in config.json (GitLab could then write settings from gitlab.rb to config.json). That's how usually this problem is solved.

added Awaiting Feedback Mattermost SP2 customer labels

https://gitlab.zendesk.com/agent/tickets/75064

I'd rather not have GitLab be responsible for understanding, parsing, and manipulating Mattermost configuration files. That seems pretty brittle, rather than a defined interface especially if Mattermost itself is also writing back to these same files.

@it33 what are your thoughts on having a separate config file like @kumashiro1 has mentioned? This would contain just the settings GitLab needs to pass, and therefore would not interfere with the broader persistence of configuration.

Hi @joshlambert, @kumashiro1 thanks for the questions.

Mattermost recently added the ability for Environment Variables to override settings in config.json.

Would this work?

@it33 I don't think this is a good solution. If I understand correctly, this method makes System Console useless, because environment will override any changes on restart. There are installations, where system admin and Mattermost admin are not the same person and the latter has no access to the system, that would allow him/her to apply settings from System Console to environment variables.

Thanks @kumashiro1, I need some help understanding more about your feedback. For the case you describe, what is the difference of using environment variables and config-local as proposed previously? https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1688#note_26452121

@it33 System Console has no control over environment variables set at server startup and cannot change them. It can change contents of config-local. When Mattermost admin makes changes in System Console, they are written to a file, but environment will revert them back to whatever was set by system admin. That is, of course, if I understand that mechanism correctly.

mentioned in issue #2377

Environment variables should work for us. I have opened https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2377 to track that.

@stanhu it sounds like we have a plan to make this work now that Mattermost has added support for Environment Variables so GitLab can apply the settings it needs without deleting changes made with Mattermost's System Console UI.

Are you okay closing this ticket now that we have https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2377 to track the solution?

closed

@it33 Yes, closing in favor of #2377.

Reconfigure overwrites Mattermost settings made in System Console

Designs

Child items ...

Activity

Admin message

Admin message

Reconfigure overwrites Mattermost settings made in System Console

Activity