Decommissioning a worker

[lk...@fbmail1.ml]

Hello

Our setup is based on Celery and is made up of one worker per customer 
project plus one central scheduler. We find this setup quite convenient as 
it enables us to get a global view of all workflows while still enforcing 
an isolated execution context through the use of queues. Unfortunately, due 
a defection, we would like to take off one now unused Airflow worker. Is 
there a procedure to do so ? We have powered off the worker but it still 
shows up in Celery Flower.

I'd be please to get some suggestions.


At moment, I want my privacy to be protected.
https://mytemp.email/

Re: Decommissioning a worker

[Laura Lorenz <ll...@industrydive.com>]

This is a pretty naive shut off/turn on again type of suggestion but we,
despite starting flower with the airflow CLI which AFAIK leaves the
`auto_refresh`
<http://flower.readthedocs.io/en/latest/config.html?highlight=refresh#auto-refresh>
at its default True configuration, have had to force a refresh of the
flower dashboard to update outdated broker information in the past so for
your case it might be as simple as that. There is a dropdown in the Flower
UI to do so.

[image: Inline image 1]

On Wed, Oct 12, 2016 at 12:00 PM, <lk...@fbmail1.ml> wrote:

> Hello
>
> Our setup is based on Celery and is made up of one worker per customer
> project plus one central scheduler. We find this setup quite convenient as
> it enables us to get a global view of all workflows while still enforcing
> an isolated execution context through the use of queues. Unfortunately, due
> a defection, we would like to take off one now unused Airflow worker. Is
> there a procedure to do so ? We have powered off the worker but it still
> shows up in Celery Flower.
>
> I'd be please to get some suggestions.
>
>
> At moment, I want my privacy to be protected.
> https://mytemp.email/
>