-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New syntax to mount Docker volumes with --mount #15815
Comments
DockerOperator is part of Docker Provider. We are not too concerned about the compatibiliy of providers to be honest, because those can be rather easily updated on provider-by-provider case (and in most cases you can downgrade the provider). So I think this is perfectly ok to make breaking change in Docker Provider and bump major version for the provider. |
In that case I think I’ll go with Option A, but removing |
Works for me! |
PR created 🙂 |
Hi @eladkal Thanks for pinging me. I had a look at the PR & left some comments. Hope that helps. :) |
I had this after reading #12537 and #9047. Currently
DockerOperator
’svolumes
argument is passed directly to docker-py’sbind
(akadocker -v
). But-v
’s behaviour has long been problematic, and Docker has been pushing users to the new--mount
syntax instead. With #12537, it seems like-v
’s behaviour is also confusing to some Airflow users, so I want to migrate Airflow’s internals to--mount
.However,
--mount
has a different syntax to-v
, and the behaviour is also slightly different, so for compatibility reasons we can’t just do it under the hood. I can think of two possible solutions to this:A. Deprecate
volumes
altogether and introduceDockerOperator(mounts=...)
This will emit a deprecation warning when the user passes
DockerOperator(volumes=...)
to tell them to convert toDockerOperator(mounts=...)
instead.volumes
will stay unchanged otherwise, and continue to be passed to bind mounts.mounts
will take a list ofdocker.types.Mount
to describe the mounts. They will be passed directly to the mounts API. Some shorthands could be useful as well, for example:B. Reuse
volumes
and do introspection to choose between binds and mountsThe
volumes
argument can be augmented to also acceptdocker.types.Mount
instances, and internally we’ll do something likeand pass the collected lists to binds and mounts respectively.
I’m very interested in hearing thoughts on this.
Are you willing to submit a PR?
Yes
Related Issues
DockerSwarmOperator
(it’s a subclass ofDockerOperator
, but thevolumes
option is currently unused).The text was updated successfully, but these errors were encountered: