Stackable
[AIRFLOW]: Mounting DAGs via git-sync #20
-
|
Hi, I have to use some certificates to access our repo, which means i either have to reference those certificates in git clone or turn off sslVerify. I tried to do both by setting the config parameters in "--git-config" under "gitSyncConf" but it seems to be ignoring all config parameters i pass into this field. Am i missing something? What is the recommended way to do this? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
|
Hallo Jan-Philip, Many thanks for your question - feedback is always very welcome! Yes, at the moment we only support user/password or a github token for access. We've treated gitsync as an internal implementation rather than passing through all settings that it allows when used in isolation (as we have to set some git-config things ourselves internally). But we can certainly change that going forward. My preference would be to expose further settings as custom resource fields, as far as that is sensible/possible. What git-sync settings would you like to see supported (other than the ones we've already implemented)? Andrew |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reaching out. Just to clarify: i am already using username and password, and it looks like that this is not the problem here. I have problems cloning the repo (we have to use certificates here)... I might be wrong here, but after looking into the operator code it looks like you are overwriting the git-config map with predefined values... shouldn't it be possible to just extend the map with the git-config settings instead of overwriting it on your side? Then we could pass our ssl config params to the git clone statement. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's correct, a technical change would be fairly simple. It's more a question of getting the right balance between offering flexibility (in the sense of passively supporting a config pass-through) on the one hand, and keeping things declarative on the other. But I think that is fine as long as it is clearly documented. I've opened an issue to track this here. |
Beta Was this translation helpful? Give feedback.
-
|
This issue has been addressed here: stackabletech/airflow-operator#332 |
Beta Was this translation helpful? Give feedback.
Yes, that's correct, a technical change would be fairly simple. It's more a question of getting the right balance between offering flexibility (in the sense of passively supporting a config pass-through) on the one hand, and keeping things declarative on the other. But I think that is fine as long as it is clearly documented. I've opened an issue to track this here.