Cache not enabled after fresh deployments

[phoenix-bjoern]

When deploying a new instance the first time the Magento cache is not enabled in app/etc/env.php and bin/magento cache:enable needs to be executed.
IMHO there is so much cache cleaning but no one thought about to actually enable the cache for Magento. So I think we need another deploy step to enable the cache and add it to the deploy scenario.

[YPyltiai]

@phoenix-bjoern this is a bug in Magento 2.3.2 and higher. It is patched in recent release. Please update ECE-Tools with dependencies (magento/magento-cloud-patches) to see if this helps.

Cache shouldn't be disabled in general - it was a bug of Magento disabling it every time on maintenance:enable.

See: magento/magento-cloud-patches#27

[phoenix-bjoern]

Not sure of this is correct. I mean in env.php not only FPC is disabled, the file looks like this:

    'cache_types' => [
        'compiled_config' => 1,
    ],

Actually it should more look like this:

    'cache_types' => [
        'compiled_config' => 1,
        'config' => 1,
        'layout' => 1,
        'block_html' => 1,
        'collections' => 1,
        'reflection' => 1,
        'db_ddl' => 1,
        'eav' => 1,
        'customer_notification' => 1,
        'config_integration' => 1,
        'config_integration_api' => 1,
        'full_page' => 1,
        'target_rule' => 1,
        'config_webservice' => 1,
        'translate' => 1
    ],

Even if you disable maintenance mode in the scenario you have the same results.

[YPyltiai]

@phoenix-bjoern that's if you get dump of cache configs into env.php AFAIK. If you don't have the dump there, it is taken from DB configs. @NadiyaS , may you please check this issue? You should be familiar with configs merging and flows we have there.

[phoenix-bjoern]

What we currently do to mitigate the problem is to manually execute bin/magento cache:enable. But IMHO this shouldn't be necessary as deploying Magento to production and warm caches in the post deploy step makes only sense if the caches are enabled by default.

[NadiyaS]

@YPyltiai what do you mean under dump of cache configs? if ece-tools config:dump - this command does not touch those cache configs.

@phoenix-bjoern I could not reproduce the issue you described. I have Magento 2.3.4, ece-tools 2002.1.0.
My steps: uninstall magento and run redeployment .
Result: all cache is enabled.

Also, you may have this problem if parent branch has this state of config (with only one cache type in env.php), because creation new branch is like a creating copy of parent environment (including DB and configuration files).

[phoenix-bjoern]

@NadiyaS can you please rm app/etc/env.php and then just run vendor/bin/ece-tools deploy. In all my tests the caches were not enabled in env.php after that.

[NadiyaS]

@phoenix-bjoern just removing env.php is not enough to make ece-tools install Magento. As at the beginning, ece-tools (re)writes DB connection to env.php and then it checks that DB is not empty, so it runs upgrade process (not install).
And even with those steps as you wrote, my deployment was interrupted during Magento upgrade with error "No key available" (but env.php really had only one cache in cache_types after this).

[phoenix-bjoern]

@NadiyaS I don't see this error during deployment. Guess you have to define the environment variable MAGENTO_CLOUD_VARIABLES and MAGENTO_CLOUD_RELATIONSHIPS to get CRYPT_KEY and database credentials.
BTW: With "fresh deployment" I'm not talking about empty databases. I mean a new version of the code (= a new version of the Docker container) where no env.php exists.

As you confirm the caches are not enabled: What is the approach to resolve this? Add another step in deployment or is it a bug which could get fixed in Magento framework/core?

[NadiyaS]

Hi @phoenix-bjoern ,
Oh, you have this error only on docker?
I made those steps on cloud environments, did not try on docker yet.
As I wrote I had error "No key available", and this is expected error as crypt key really does not exist due to removing env.php. This is expected that my env.php may have missed data (in our case it is cache_types) as Magento upgrade process was not finished. So, in my case, I would not consider this as a bug.
Let me clarify your case/steps. You have this problem when you install Magento for the first time on docker, right? Under installation I mean absolutely fresh installation on new environment or after setup:uninstall CLI command. If you just remove env.php (and DB left with whole data) and run vendor/bin/ece-tools deploy - it is possible that you may have a problem in env.php after this. Please check in logs what process was run during that deployment (install or upgrade). If bin/magento setup:install was run, then it is really a bug. And you need to provide more detailed steps as I cannot reproduce it.

[phoenix-bjoern]

@NadiyaS it is setup:upgrade of course.

[NadiyaS]

@phoenix-bjoern then I would not consider this as ece-tools bug.
If you try this not on the cloud project (Magento itself), you will have the same result.
Actually, the problem here is that Magento automatically adds only one cache type if there is no cache_type in env.php

'cache_types' => [
        'compiled_config' => 1
    ]

Even if env.php does not exist at all, Magento creates this file only with one cache_types.
And that is what happened in your case:

• you remove env.php
• magento creates it again with one cache type
• ece-tools adds other configurations.
  If env.php did not exist, ece-tools would create it from env.php.bak and you would have all configurations from the last deployment.

[phoenix-bjoern]

@NadiyaS I perfectly understand this. But the question remains: Why shouldn’t we add the enablement of all caches in the upgrade scenario? It doesn’t make sense to deploy an instance and leave the cache disabled, right?

[NadiyaS]

@phoenix-bjoern
The problem exists because Magento automatically creates empty env.php with only one cache_types. I would create a bug in Magento core - if env.php does not exist do not create it with cache_types only.

Also, ece-tools cannot enable cache after every setup:upgrade because customer could disable it before and expects to have the same after redeployment.

Anyway, as I understood you just removed env.php from existed (deployed before) environment. It is not recommended way. You need to uninstall magento first (or clear DB together with removing env.php) and you will have correct configurations after redeployment.

[NadiyaS]

Hi @phoenix-bjoern,
we added workaround for case when env.php was removed on installed Magento. ece-tools will run setup:upgrade as before + run cache:enable command during the deployment.
See PR #732