Dokku reports "zero downtime is disabled" when it is in fact enabled about dokku

[josegonzalez]

Do you have the output of a deploy with trace mode enabled?

Also, it looks like the value of the checks disabled list is _all_, meaning all checks are disabled. Did you set that somehow, or did you perhaps upgrade an install with a config value for DOKKU_CHECKS_ENABLED previously?

[swrobel]

Also, it looks like the value of the checks disabled list is _all_, meaning all checks are disabled. Did you set that somehow, or did you perhaps upgrade an install with a config value for DOKKU_CHECKS_ENABLED previously?

I've been using dokku for years, so perhaps it's some legacy setting, as I don't recall messing with anything related to zero downtime until now. Here are the dokku keys that come up when I run dokku config metasurf:

DOKKU_APP_RESTORE:         1
DOKKU_APP_TYPE:            herokuish
DOKKU_CHECKS_DISABLED:     _all_
DOKKU_PROXY_PORT:          80
DOKKU_PROXY_SSL_PORT:      443

Should I just dokku config:unset metasurf DOKKU_CHECKS_DISABLED?

[swrobel]

Adding output of a deploy with trace on

[josegonzalez]

Yeah or use the checks subcommand for it.

[swrobel]

use the checks subcommand for it.

Which would that be?

root@metasurf:~# dokku checks
Usage: dokku checks[:COMMAND]

Manage zero-downtime settings

Additional commands:
    checks:disable <app> [process-type(s)]   Disable zero-downtime deployment for all processes (or comma-separated process-type list) ***WARNING: this will cause downtime during deployments***
    checks:enable <app> [process-type(s)]    Enable zero-downtime deployment for all processes (or comma-separated process-type list)
    checks:report [<app>] [<flag>]           Displays a checks report for one or more apps
    checks:run <app> [process-type(s)]       Runs zero-downtime checks for all processes (or comma-separated process-type list)
    checks:skip <app> [process-type(s)]      Skip zero-downtime checks for all processes (or comma-separated process-type list)

None of them seem to fit the bill. I've used checks:enable already and checks:run metasurf web returns "Zero downtime is disabled for app (metasurf.web). Skipping checks"

[josegonzalez]

I feel like checks:enable should work... for now, unset the variable.

Is there a test for this 🤔

[swrobel]

I feel like checks:enable should work

Ok, that did work, just not when I specified the process type that I wanted to enable, ex:

root@metasurf:~# dokku checks:enable metasurf web
-----> Enabling zero downtime for app's (metasurf) proctypes (web)
DOKKU_CHECKS_DISABLED is still _all_

root@metasurf:~# dokku checks:enable metasurf
-----> Enabling zero downtime for app's (metasurf)
DOKKU_CHECKS_DISABLED is now unset

root@metasurf:~# dokku checks:disable metasurf buoy,forecast
-----> Disabling zero downtime for app's (metasurf) proctypes (buoy,forecast)
DOKKU_CHECKS_DISABLED is now "buoy,forecast" and deploy behavior is as expected, as indicated by the deploy log below:

=====> Processing deployment checks
 !     No healthchecks found in app.json for web process type
       No web healthchecks found in app.json. Simple container checks will be performed.
       For more efficient zero downtime deployments, add healthchecks to your app.json. See https://dokku.com/docs/deployment/zero-downtime-deploys/ for examples
-----> Deploying metasurf via the docker-local scheduler...
-----> Deploying web (count=1)
       Attempting pre-flight checks (web.1)
-----> Executing 2 healthchecks
       Running healthcheck name='default' type='uptime' uptime=10
       Running healthcheck name='port listening check' attempts=3 port=5000 retries=2 timeout=5 type='listening' wait=5
       Healthcheck succeeded name='port listening check'
       Healthcheck succeeded name='default'
       All checks successful (web.1)
=====> Start of metasurf container output (web.1)
       => Booting Puma
       => Rails 7.1.3 application starting in production
       => Run `bin/rails server --help` for more startup options
       [12] Puma starting in cluster mode...
       [12] * Puma version: 6.4.2 (ruby 3.3.0-p0) ("The Eagle of Durango")
       [12] *  Min threads: 0
       [12] *  Max threads: 5
       [12] *  Environment: production
       [12] *   Master PID: 12
       [12] *      Workers: 4
       [12] *     Restarts: (✔) hot (✖) phased
       [12] * Preloading application
       [12] * Listening on http://0.0.0.0:5000
       [12] Use Ctrl-C to stop
       [12] - Worker 2 (PID: 217) booted in 0.01s, phase: 0
       [12] - Worker 0 (PID: 212) booted in 0.02s, phase: 0
       [12] - Worker 1 (PID: 214) booted in 0.02s, phase: 0
       [12] - Worker 3 (PID: 220) booted in 0.02s, phase: 0
=====> End of metasurf container output (web.1)
       Scheduling old container shutdown in 15 seconds (web.1)
=====> Triggering early nginx proxy rebuild
-----> Ensuring network configuration is in sync for metasurf
-----> Configuring metasurfforecast.com...(using built-in template)
-----> Creating https nginx.conf
       Enabling HSTS
       Reloading nginx
-----> Deploying buoy (count=1)
       Zero downtime is disabled, stopping currently running containers  (buoy)
       Stopping 9c0297224aca79ef22ea976fc1f175352983ccc6a1f34bc0227a52998c52fd83 (buoy)
       Scheduling old container shutdown in 15 seconds (buoy.1)
-----> Deploying forecast (count=1)
       Zero downtime is disabled, stopping currently running containers  (forecast)
       Stopping b05d9a283bbf5c4b5fae6d23efdd6630f47793beff449831df779f231314d1ce (forecast)
       Scheduling old container shutdown in 15 seconds (forecast.1)

[josegonzalez]

Hmm I wonder if there is a way to do "all except this" or something?

[swrobel]

Hmm I wonder if there is a way to do "all except this" or something?

Now, with knowledge of how this feature actually works (a blacklist as opposed to a whitelist), I figure checks:enable [process_type] when going from __all__ should disable all other types besides the specified process_type(s)

[josegonzalez]

But what happens when you add a new process type?

[swrobel]

But what happens when you add a new process type?

Like I said, this seems like a special case when the current value of DOKKU_CHECKS_DISABLED is __all__

[josegonzalez]

Maybe enabling with all disabled will just add a minus sign in front of the enabled?