Status of testing Providers that were prepared on October 30, 2021 #19328
Comments
|
for cncf.kubernetes: 2.1.0rc1 it's all good add more information to PodLauncher timeout error (#17953) -> is working Add more type hints to PodLauncher (#18928) > just typing , so OK |
|
I think #18733 was released in 2.3.0 |
|
for google: 6.1.0rc1 Google provider catch invalid secret name (#18790) -> is working the error about secrets with a non valid char is now catch |
Good spot @codenamestif ! It turned out that after last month's release of 2.3.0 as rc2 I set the "2.3.0" tag wrongly to rc1 - so the changes added between rc1 and rc2 were duplicated in the issue and changelog (and I missed that when I prepared it today). Those are the duplicated issues:
I already corrected the tag, the issue and I will also correct the Changelog (and in docs those entries will be missing), but unless there are other, more serious changes that make it rc1, it will remain in the package README (and tecchnically those changes ARE in 2.4.0 as well as 2.3.0), In the future packages changelog will corrected. Sorry everyone involved for spamming! |
|
… On Sat, 30 Oct 2021 at 20:39, Aakcht ***@***.***> wrote:
Tested #18854 <#18854> - all good.
#18331 <#18331> is already present
in 2.1.1 ( it was tested in #18638
<#18638>) , so I don't think hdfs
2.1.1rc1 should be present here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19328 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWQK7CHD5D4NJINYNXVWSLUJQ3WBANCNFSM5HBDLQLQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
#18990 tested and working |
|
#18872 I tested this PR and it is not working as expected. task = DockerSwarmOperator(
task_id="task",
image="python:3.9",
enable_logging=True,
tty=True,
command=["echo", "hello world !"]
) |
How serious / how much of a regression change is it @mariotadeucci ? |
|
| #18872 I tested this PR and it is not working as expected. @RyanSiu1995 can you please double check if you have the same problem ? |
Correct - exasol is not being released (same bug as with hdfs when generating issue only). I will fix it. Sorry for spam. |
|
I removed the few other providers which suffered from the same issue - sorry :( |
|
I have validated that both changes for pagerduty work as intended!
|
|
#18447 tested and working |
|
#18807 tested and verified both single + multiple s3 prefix matches. |
|
tested #18676 and working |
|
Good progress so far :)! |
@potiuk Happend on |
|
Tested #19048, works correctly :) |
|
Tested #19276 MongoSensor picking up the new db param |
It is a breaking change, so
It is breaking change also.
I am not sure here, but when we changed the minimum requirements of the google libraries, we always bumped the major version. Airflow is a thin layer between libraries and user, so breaking changes propagate to Airflow very easily. |
Thanks @mik-laj I will take a look and decide |
|
regarding #18992 I've tested this change in our environment with the DataflowCreateJavaJobOperator. I haven't had a chance to set up test jobs for the other operators but based on the similarities in implementation I think that this fix should be applicable to all of them. This PR introduced a change in behaviour, but I don't think it should be considered a breaking change as it is simply returning to the original / documented behaviour. |
Hey @mik-laj - thanks for raising your concenrs. i looked closer, and I do not see those changes as really "breaking" (or at least not really breaking enough and under our control to justify major version change (but I am open to hear to arguments if others disagree). Facebook API does not follow SemVer. AT ALL. They mostly introduce new features and bugfixes when they bump the version. More interestingly, they even CHANGE behaviour of old versions of APIs when this behaviour is working for quite some time in the new versions. Here are the changes to insights features we are using for example:
and:
and:
This means that the version 6.0 of "insights" we were using so far has anyway changed behaviour on Sep 6th this year to match the current 11+ behaviour 😱 So from what we see here, Facebook has chosen a "move fast break things" approach for their APIs. I assume Facebook users know it and I think the approach we took is a good one - we should not really try to keep compatibilty with version vN of Facebook, because even they don't do/recommend it (and we won't be able to actually do that because they can anyhow change the behaviour without us knowing it). So keeping the approach where by default API version is "latest" seems like a good approach and I do not see it really breaking anything. Cosmos
I looked at the changes again, and I do not see any breaking change. We indeed sometimes (but not always) bumped major versions for our providers when underlying libraries changed but only when they changed the Airflow API of that provider (format of data returned and similar). The sheer fact of library upgrading it's version does not automatically invalidates and forces bump to new version of all the applications and libraries using it. In this particular case, we simply adapted our implementation so that the API remained the same (the breaking change which affected us was simply throwing a different exception - in our case we caught it and returned None, and this behaviour remained so there is no reason to bump the major version here. |
|
Closing this one. As described in https://lists.apache.org/thread/6tzsq6xkm5r1q6pqtyq5yhvr5p1jqd13 I am releasing the wave now and we are removing the Amazon Provider from that release due to Redshift regression (and I will release fixed version soon). Thanks @mariotaddeucci for testing and spotting the problem (it was not obvious in the initial change and it's great you tested this case!) Thanks everyone who helped! |
Body
I have a kind request for all the contributors to the latest provider packages release.
Could you help us to test the RC versions of the providers and let us know in the comment,
if the issue is addressed there.
Providers that need testing
Those are providers that require testing as there were some substantial changes introduced:
Provider amazon: 2.4.0rc1
Provider apache.hive: 2.0.3rc1
Provider cncf.kubernetes: 2.1.0rc1
Provider docker: 2.3.0rc1
Provider elasticsearch: 2.1.0rc1
Provider facebook: 2.1.0rc1
Provider google: 6.1.0rc1
Provider jenkins: 2.0.3rc1
Provider microsoft.azure: 3.3.0rc1
Provider mongo: 2.2.0rc1
Provider pagerduty: 2.1.0rc1
Provider salesforce: 3.3.0rc1
Provider samba: 3.0.1rc1
Provider sftp: 2.2.0rc1
Provider snowflake: 2.3.0rc1
Provider ssh: 2.3.0rc1
Provider tableau: 2.1.2rc1
Provider trino: 2.0.2rc1
Providers that do not need testing
Those are providers that were either doc-only or had changes that do not require testing.
Thanks to all who contributed to those provider's release
@sreenath-kamath @jarfgit @frankcash @deedmitrij @enima2684 @uranusjr @peter-volkov @mariotaddeucci @potatochip @malthe @msumit @dimberman @jameslamb @Brooke-white @GuidoTournois @minu7 @ashb @shadrus @ignaski @eladkal @ephraimbuddy @eskarimov @JavierLopezT @keze @josh-fell @raphaelauv @blag @Aakcht @guotongfei @SamWheating @danarwix
@subkanthi @alexbegg @bhavaniravi @tnyz @Goodkat @fredthomsen @SayTen @kaxil @lwyszomi @ReadytoRocc @baolsen @30blay @nathadfield @xuan616 @RyanSiu1995
Committer
The text was updated successfully, but these errors were encountered: