search

ezsystems / launchpad

CLI tool to bootstrap an eZ Platform project Docker stack | #justcode
https://ezsystems.github.io/launchpad
MIT License
22 stars 26 forks source link

Purge type not correctly set in prod mode right after install #63

Open raupie opened 5 years ago

raupie commented 5 years ago
Q A
Bug report? yes
Feature request? no
BC Break report? yes
RFC? yes/no
Version ezplatform 2.4
Environment Linux

Varnish does not work with ezplatform enterprise edition. Particularly with admin ui purge events. I've tested this using ezlaunchpad by initializing a ezplatform project and an ezplatform-ee project.

Test 1: ezplatform standard edition. Works as expected.

  1. ~/ez init
  2. Open homepage in tab 1, Varnish cache reports a miss. Refresh again to test that next reload is a hit.
  3. Open admin ui in tab 2
  4. Edit content
  5. Refresh tab 1, Varnish cache has been purged and varnish is a MISS and X-Count-Hits is reset.

Test 2: ezplatform-ee edition. Varnish is broken. Purge not working. Logged in session is being cached.

  1. ~/ez init ezystems/ezplatform-ee
  2. Open Homepage in tab 1, Varnish cache reports a miss. X-Varnish: 123
  3. Open Homepage in tab 2, Varnish cache reports hit. X-Varnish: 123
  4. Open admin ui in tab 3
  5. Edit ezplatform folder object
  6. Refresh Homepage in tab 2, Varnish cache does not purge. Tab 2 cache using different X-Varnish ID. X-Varnish: 789, X-Cache-Hits: 1
  7. Repeat step 5, X-Cache-Hits: 2
  8. Log out of Admin UI in tab 3
  9. Refresh tab 2, Varnish cache returns to same as tab 1. X-Varnish: 123

So it appears to me that ezplatform-ee is not purging content. When logged into the admin ui I can see that varnish is caching the homepage when in ezplatform project that is not happening as expected since Varnish shouldn't be caching content containing cookies. When I log out of admin ui the varnish cache returns to the original cache without the new content.

The other side affect I'm noticing ONLY when using the ezplatform-ee project is when running an ~/ez down && ~/ez create to rebuild the environments that leaving the admin ui logged in will cause varnish to cache a composer error message. If I log out of admin_ui then run the ez commands varnish doensn't cache that error. I believe it has something to do with the admin ui notifications trying to hit the site while it's down and varnish turns on it sees that request and caches it. However I've tested this on the ezplatform project and it doesn't happen there. Seems isolated to enterprise edition only.

Plopix commented 5 years ago

Ok I dive a bit on this one.

This is not an easy fix, and there is no diff between Enterprise or Standard. This is a cache issue.

Key is the env var HTTPCACHE_PURGE_TYPE this env var is set on the Vhost (nginx) so in CLI (during the install process) the cache is set without it to local

Then when you go on your browser the purge does not work. If you clean the cache it works.

Complexity is that, if we put the HTTPCACHE_PURGE_TYPE env var in the env of the container, the opposite will happen, dev mode will try to purge in http and not in local.

cc @andrerom not sure we have a simple fix here. Maybe we could just provide that information in the doc.

Any other idea?

andrerom commented 5 years ago

Well.. Typically we try to share cache between dev and prod if they share db, to make sure it stays in sync on changes, but I know you have misc reasons to not do that.