Don't use config for storing dynamic subscription data or API keys

This introduces another issue as well:

The once exported configuration contains subscription information which might be outdated. Upon updating a site using regular deployment process the old configuration will be imported again (unless the configuration changed by cronjob on production machine will be somehow exported and put back into vcs).

Alternatively the whole configuration needs to be excluded.

use the state api, that's what its for - my 2c

Agreed with #3 - That's what Migrate API does.

Agreed. It seems that very little of what this module is storing in config should actually be stored in config. Using the State API makes the most sense.

This feels like a major to me, given that it disrupts config workflows and makes it easy to accidentally save sensitive data to version control.

How is anyone using this module while also using the config management system in any fashion?

It seems like the only option is to always go to your prod site, export the config, then copy the acquia connector settings file into your local site and commit that along with any other config changes that you're actually making.

Thanks the feedback, everyone, this will be fixed in near future.

Hi irek, I wonder if there's a status update on this? Specifically moving the state data out of configuration and into the state API? If not, are there any known workarounds to prevent this file from constantly being overwritten and modified via config-import / config-export?

@bkosborne, the fix will be released sometime next week.

Hi Irek, I see that the release was put out that removes the API creds from config and migrates them to state API.

Do you still plan on moving all the other stuff into state API, like subscription data? That's the stuff that causes some problems for me since it seems it changes based on things out my control, and things get wiped out during config import/export process.

bkosborne, yes, the plan is to move all other config into the State API. I'm going to close this story as the security concern with the credentials was addressed. Would you like to create a new issue about the subscription_data part?

Done: #2864697: Move subscription and SPI data out of config and into state API