Hi Jarek
Thank you for surfacing this issue on a discussion. The major hurdle for
managed services apart from the security constraints is on the licensing side.
Previously when the code needed for connection templates was part of Airflow,
we were able to bundle them as a solution as the code wa
Thanks Aizhamal for having taken care of this, it's amazing!
Karolina Rosół
On Mon, Jun 14, 2021 at 9:03 PM Aizhamal Nurmamat kyzy
wrote:
> Thank you so much for your interest! I will set up a session for Airflow
> soon, and most likely there will be a couple folks from other open
> source
Thank you so much! I'm gonna have a look and send it over tomorrow morning.
Anyone else want to add anything? :-)
Let me know.
Thanks,
Karolina Rosół
On Sun, Jun 13, 2021 at 2:42 AM Jarek Potiuk wrote:
> Me too!
>
> On Sat, Jun 12, 2021 at 10:15 AM Tomasz Urbaszek
> wrote:
>
>> Thanks Karo
Thank you so much for your interest! I will set up a session for Airflow
soon, and most likely there will be a couple folks from other open
source groups, which I hope you all don't mind. Will share more details
soon. Stay tuned.
On Thu, Jun 10, 2021 at 8:22 AM Keshav Tyagi
wrote:
> +1
>
>
>
>
Can you elaborate (privately if you have to) on what the security concerns are?
Since as I understand it the web server is powery deployment, so anything
should be limited to one customer/user/deployment.
There is also the new "test connection" feature that will need the provider
code installed
Is at all feasible to deprecate connection UI customization? Then
everything can just use `extra` json where the other params fall short.
Seems like an area where the benefit does not outweigh the complexity. We
could also take the opportunity to deprecate the long `extra` key names
like `extra__
Hi Jarek.
Thanks for the discussion.
The issue with Connections management in the web server that you described
is indeed affected Cloud Composer in the released preview image versions of
Airflow 2.0.1 (link to public issue
https://issuetracker.google.com/issues/190189297). And as you stated, we d
"Jarek Potiuk" (14/06/21 20:06:14):
I never used tools like Reno (so I might be wrong) but I think they
add extra effort and requirements (and confusion) for contributors to
also modify the changelog pretty much always.
IMHO for new contributors it will lead to "default" one more extra
iteratio
Honestly, I also don't particularly LOVE the conventional commits
(mainly the same reason as Ash because of the `git log --oneline`
output and taking the extra space). I am not even sure if we need it
at all. We can easily do without them with the current tooling so if
there is no "universal yes" f
Would it be possible to use the /branch/name for the "conventional"
part -- i.e. fix/my-branch - feat/something? I guess not as once the PR
is merged the name of the branch is not easily accessible anymore,
right?
-ash
On Mon, Jun 14 2021 at 09:08:45 +0100, Ash Berlin-Taylor
wrote:
I also d
I also don't like conventional commits - and ultimately I don't think for
commit logs are the right tool for building a changelog - they are too granular
and also too noisy.
Primary reasons for not liking them: it uses up a lot of space in the already
short commit subject "limit", it's subjecti
11 matches
Mail list logo
