I didn't end up fixing it. We have a legacy way of logging in to airflow
that bypasses our SSO system and I confirmed that the legacy system worked
but the SSO system didn't work.
On Thu, Aug 17, 2017 at 4:36 PM, Alex Guziel wrote:
> Curious, how did you fix
Curious, how did you fix this? We see this from time-to-time and we also
have a single sign-on system.
On Wed, Aug 16, 2017 at 10:29 AM, George Leslie-Waksman <
geo...@cloverhealth.com.invalid> wrote:
> I have further tracked the issue to our new single-sign-on system. Airflow
> is fine. Please
Thanks for the explanation. We do have an airflow web-server that is
persistent so I wonder if that is causing this issue. For this dag
particularly, we don't have a scheduling thingy. It is just for backfill
only.
On Thu, Aug 17, 2017 at 4:00 PM, Boris Tyukin wrote:
>
hopefully someone chimes in and explain. I just remember I've read to
change the dag name if schedule needs to be changed that's why I suggested
it. I've tried to swap order of tasks but I often add/delete tasks from
dags as I develop and that seems to be working fine without dag renaming.
- Boris, You are right. After I change the dag id to something else, the
dependency holds. I am very curious but why i cannot just switch the order
and don't need to change the dag id. Thanks a lot!
On Wed, Aug 9, 2017 at 10:21 AM, Boris Tyukin wrote:
> Hit refresh
The point of pools is to limit parallelism on a logical set of tasks
instances to a certain number. Overflowing into another pool would break
the only guarantee it provides.
`priority_weigth` works along with pool to define which task should be
scheduled first once slots open up. It won't kill
Hi everybody,
I'd like to come back to this to give you an update on how we've made the
thing work. And of course, thanks for your kind responses.
We found out about Eremetic, a Mesos framework to run one-off jobs in
Docker containers (let's say it's a one-off jobs counterpart to Marathon,
in