When you have an
agent-state: down that means the bootstrap node can't communicate with the juju-agent. As a result it can't destroy as it can't communicate the next set of events.
This happens sometimes when the machine is destroyed outside of juju, so juju thinks it's still there though the machine has been physically removed. Can you confirm that opnw02.master is indeed still running? If so, try to ssh to it either using
juju ssh 20 or
ssh email@example.com. If you can gain access to the machine try restarting the juju-agents, which are
jujud-unit-<service>-#. So in your case the following commands will restart those services
sudo stop jujud-machine-20
sudo stop jujud-unit-quantum-gateway-0
sudo start jujud-machine-20
sudo start jujud-unit-quantum-gateway-0
At this point juju status should report the unit-agent as started again. You may need to run
juju resolved quantum-gateway/0 a few times as it appears to have stopped during mid-hook execution. Eventually, the service should go par to the course and be removed.
If you are unable to log in to the machine (either it was destroyed outside of juju, or for other reasons) then it'll remain in the juju status for now. There's work to allow "cleanup" of services but it hasn't landed yet (as of 1.13.3). If you want to deploy quantum-gateway again, and the status still has this agent-state down business, then you can deploy it with a different alias like so:
juju deploy quantum-gateway qgateway
Going forward you can make relations to it by issuing
juju add-relation nova-compute qgateway