BLT's Config management nuance questions

[dpagini]

I have been using BLT for quite a long time now, and have been stuck in the features workflow. Time after time there are issues with features, especially with multisite that have me evaluating a switch to core-only or config-split methods.

Due to using features, I have a whole bunch of modules that provide config. I have unit testing in these modules as well. We try to build our modules like they are going to be contributed back to the community, and our test coverage ensures our application stays well tested.

So I begin looking into the other two BLT config management options of core-only and config-split. Core only seems pretty straightforward... you export ALL your sites config to a folder, and then import it as part of setup or update procedures, there's nothing I'm missing here, right? Then Config Split seems like it's become a favorite of the community recently. It seems config-split lets you activate certain config groupings based on things like environment or site or feature, to name a few. This seems pretty great... with one caveat. It seems that BLT requires you to use the full config import/export feature of core-only in order to use config-split at all.

These lines ensure that your config splits only run/work if you have the core.extension.yml file in your main site config directory.

  if (in_array($strategy, ['core-only', 'config-split'])) {
    $core_config_file = $this->getConfigValue('docroot') . '/' . $this->getConfigValue("cm.core.dirs.$cm_core_key.path") . '/core.extension.yml';
    [...]
    return 0;

By using the full core-only config split, I'm afraid I'm going to lose a lot of that desired test coverage we have built into our site. Now config files in the config/ directory can change and break something and the tests won't catch it, because they are only testing the default config provided by the module.
I would really like to use config-split for only a small subset of my config files... for example, providing a google_analytics.settings.yml file per site that has the account ID in config/code. I don't want to then export my entire core.extension.yml file and ALL configuration for the site in order to have to use the config-split method.

Thoughts? Does this make sense at all? Am I missing something basic in my understanding here and I can already do all of this?

[wu-edward]

I don't think config-split will work the way you want.
You're probably better off creating separate feature modules per environment and put the environment-specific config in the respective features.
Then use BLT's toggle-modules to turn on/off correct features per environment.

[dpagini]

Why do you say that @wu-edward?
I really want to get away from features as it just gives us too many problems. For instance, we have a multisite with 2 sites, let's say. In sticking with the google_analytics.settings.yml example, I have the config that is provided by that module, then I have 2 site specific features, both providing the analytics account in a google_analytics.settings.yml file in config/install directory. When I run $ drush fra, no matter which site I'm on, it will always take the config file from the 2nd module, alphabetically. I know this is a features BUG, but it's something they're not interested in fixing, and I just want to move away from that module completely.
Could I not do something like a config-split that represents only some of the config I want to import? It would be very similar to core-only "partial" import, which BLT does not support either. You can only do a partial import if you are using features, oddly enough. I'm not sure why that is?

[greylabel]

@dpagini Do you have a link to that bug on d.o?

[mikemadison13]

@dpagini have you considered setting up a CI specific split that has all of the configuration in it that you want to test? i've done that on a few projects where i have competing things that i wouldn't normally have configured in all environments, but for CI we do it all so that we can run automation against it.

just a thought.

what else can we do to help on this issue?

[dpagini]

Sorry, I have been meaning to get back to @greylabel's question here, and still intend to.

@mikemadison13 I guess I'm wondering if there is some logic behind requiring a user who wants to use the config-split method to ALSO use the core-only method. It seems like BLT's config-split strategy is expecting an entire sites config to live in config/default (b/c if core.extension is not present, you can't use the config-split strategy).
Is there a reason I can't use config-split on its own?

[mikemadison13]

i "think" that you can do so... i haven't personally, but i believe there are some folks who are doing just this, where config/default basically has next to nothing in it and everything lives inside a split.

@msherron i think showed me an example of this once, Michael do you have any docs we could share with @dpagini to help him out? i don't remember the nuance of getting config to import without a core.extension (or maybe it's just that there IS a core.extension but it's super duper minimal???)

[dpagini]

Hey just want to revisit this one again... I hadn't heard anything back after @mikemadison13's last post.

@greylabel - Here is a d.o issue that highlights the problem in the google_analytics.settings.yml example I gave above. I also had posted myself an issue about a year ago with a problem with optional config that got closed. I'm probably a little jaded in saying they won't fix it, but these two issues together, along with the fact that the module's response rate over the last 6 months has dipped to almost 0, AND couple all of that with the countless articles online about not using features, and I hope you can understand why my end goal is to move away from features.

So anyways, I did not intend the thread to turn into a features bashing session, but I'm looking for alternatives for using BLT without exporting the entire config of my site. @mikemadison13 mentioned above there might be users using BLT without exporting the entire site into config/default folder...? I know I can use the cm.strategy = 'none' setting, but even that has it's drawbacks in BLT. If I set cm.strategy = 'none' I lose my ability to have Acquia Cloud Hooks run my $ drush updb command out of the box, as well as some cache clears, that UUID issue added to the config:import command, and any future additions in there.

I guess just as a basic question... if I set cm.strategy = 'none', should I really not have my database updates run on a blt sync command?

[danepowell]

This discussion has been interesting to follow and has produced a few potential ideas but no clear feature request except for #3345 (which was fixed), so I'm closing for now.

[dpagini]

With this issue, I suppose I'm still wondering if there is any reason that BLT requires a core.extension.yml file to be present in order to use a config method...? Is that necessary?

[danepowell]

@grasmash added the check for core.extension.yml in #1275. Presumably it was just a basic sanity check that configuration exists on disk prior to running an import. My understanding is that with a full config import (whether using config split or not), you need to have core.extension.yml (that file never gets "split").

If you can provide a valid use case for not requiring core.extension.yml to be present and some other way of gracefully handling the situation where configuration doesn't exist on disk, feel free to open a new issue or PR.

[dpagini]

So I imagine it makes sense to check for it with a full config import, right? But you cannot use config-split in BLT without also using full config export, right? Shouldn't those functions be independent of each other?

Thanks for checking this closed issue.. I didn't quite think my comment would be acknowledged, but wanted to get it out there.