Page MenuHomePhabricator

Purge the hhvm fcgi and cli bytecache as part of deployment
Closed, DeclinedPublic

Description

This came up during the deployment of 1.28.0-wmf.19.

We've talked about having scap do something like this before, perhaps related to the depooling and repooling of appservers.

Event Timeline

thcipriani moved this task from Needs triage to Experiments on the Scap board.
mmodell renamed this task from Purge the hhvm fcgi and cli bytecache as part of deployment to Purge the ~~hhvm~~ php7 fcgi and cli bytecache as part of deployment.Oct 2 2017, 4:22 PM
mmodell renamed this task from Purge the ~~hhvm~~ php7 fcgi and cli bytecache as part of deployment to Purge the php7 fcgi and cli bytecache as part of deployment.
mmodell updated the task description. (Show Details)

Blocked, or declined as a result of?

maybe declined, I don't know? We might still want to deal with php7 opcache but I would guess that's a long way off.

I don't see how this task can be blocked by to a switch to php7. I am also not completely sure it makes sense at all.

I'm removing the relationship with the php7/hhvm task

Legoktm renamed this task from Purge the php7 fcgi and cli bytecache as part of deployment to Purge the hhvm fcgi and cli bytecache as part of deployment.Oct 3 2017, 5:16 AM
Legoktm removed a project: Deployments.
Legoktm edited projects, added Deployments; removed Scap.
Legoktm edited projects, added Scap; removed Deployments.
Legoktm subscribed.

Not sure what's wrong with the tags...but anyways, this task should still be about HHVM. *After* we've switched to PHP 7 it should be retitled if it's still relevant.

@Legoktm: scap is a subproject of deployments now. So it can't be in both the parent and the subproject. The subproject implies the parent.