Repository navigation
Status of testing Providers that were prepared on February 05, 2022 #21348
Copy link
Copy link
Closed
Labels
kind:metaHigh-level information important to the communityHigh-level information important to the communitytesting statusStatus of testing releasesStatus of testing releases
Description
Body
I have a kind request for all the contributors to the latest provider packages release.
Could you please help us to test the RC versions of the providers?
Let us know in the comment, whether the issue is addressed.
Those are providers that require testing as there were some substantial changes introduced:
Provider amazon: 3.0.0rc1
- Rename params to cloudformation_parameter in CloudFormation operators. (#20989): @potiuk
- [SQSSensor] Add opt-in to disable auto-delete messages (#21159): @LaPetiteSouris
- Create a generic operator SqlToS3Operator and deprecate the MySqlToS3Operator. (#20807): @mariotaddeucci
- Move some base_aws logging from info to debug level (#20858): @o-nikolas
- Adds support for optional kwargs in the EKS Operators (#20819): @ferruzzi
- AwsAthenaOperator: do not generate client_request_token if not provided (#20854): @XD-DENG
- Add more SQL template fields renderers (#21237): @josh-fell
- fix: cloudwatch logs fetch logic (#20814): @ayushchauhan0811
- Alleviate import warning for
EmrClusterLinkin deprecated AWS module (#21195): @josh-fell - Rename amazon EMR hook name (#20767): @vinitpayal
- Standardize AWS SQS classes names (#20732): @eladkal
- Standardize AWS Batch naming (#20369): @ferruzzi
- Standardize AWS Redshift naming (#20374): @ferruzzi
- Standardize DynamoDB naming (#20360): @ferruzzi
- Standardize AWS ECS naming (#20332): @ferruzzi
- Refactor operator links to not create ad hoc TaskInstances (#21285): @josh-fell
Provider apache.druid: 2.3.0rc1
Provider apache.hive: 2.2.0rc1
Provider apache.spark: 2.1.0rc1
Provider apache.sqoop: 2.1.0rc1
Provider cncf.kubernetes: 3.0.2rc1
Provider docker: 2.4.1rc1
Provider exasol: 2.1.0rc1
Provider google: 6.4.0rc1
- [Part 1]: Add hook for integrating with Google Calendar (#20542): @rsg17
- Add encoding parameter to
GCSToLocalFilesystemOperatorto fix #20901 (#20919): @danneaves-ee - batch as templated field in DataprocCreateBatchOperator (#20905): @wsmolak
- Make timeout Optional for wait_for_operation (#20981): @MaksYermak
- Add more SQL template fields renderers (#21237): @josh-fell
- Cloudsql import links fix. (#21199): @subkanthi
- Refactor operator links to not create ad hoc TaskInstances (#21285): @josh-fell
Provider http: 2.0.3rc1
Provider imap: 2.2.0rc1
Provider jdbc: 2.1.0rc1
Provider microsoft.azure: 3.6.0rc1
Provider microsoft.mssql: 2.1.0rc1
Provider microsoft.psrp: 1.1.0rc1
Provider mysql: 2.2.0rc1
- Add more SQL template fields renderers (#21237): @josh-fell
(Refactor vertica_to_mysql to make it more 'mypy' friendly #20618): @potiuk
Provider oracle: 2.2.0rc1
- Add more SQL template fields renderers (#21237): @josh-fell
- Fix handling of Oracle bindvars in stored procedure call when parameters are not provided (#20720): @malthe
Provider postgres: 3.0.0rc1
- Replaces the usage of postgres:// with postgresql:// (#21205): @potiuk
- Add more SQL template fields renderers (#21237): @josh-fell
- Remove
:typelines now sphinx-autoapi supports typehints (#20951): @ashb - 19489 - Pass client_encoding for postgres connections (#19827): @subkanthi
- Amazon provider remove deprecation, second try (#19815): @uranusjr
Provider qubole: 2.1.0rc1
Provider slack: 4.2.0rc1
- Return slack api call response in slack_hook (#21107): @pingzh
(Fix template_fields type to have MyPy friendly Sequence type #20571): @potiuk
Provider snowflake: 2.5.0rc1
- Add more SQL template fields renderers (#21237): @josh-fell
- Fix #21096: Support boolean in extra__snowflake__insecure_mode (#21155): @mik-laj
Provider sqlite: 2.1.0rc1
Provider ssh: 2.4.0rc1
- Add a retry with wait interval for SSH operator (#14489): @Gaurang033
- Add banner_timeout feature to SSH Hook/Operator (#21262): @potiuk
Provider tableau: 2.1.4rc1
Provider vertica: 2.1.0rc1
Committer
- I acknowledge that I am a maintainer/committer of the Apache Airflow project.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
kind:metaHigh-level information important to the communityHigh-level information important to the communitytesting statusStatus of testing releasesStatus of testing releases
Activity
raphaelauv commentedon Feb 5, 2022
#21175: @ferruzzi
docker operator is buggy even with
do_xcom_push=Falseit failfail
with
kazanzhy commentedon Feb 5, 2022
Changes in Qubole provider was in documentation (#20058) and typing (#21074)
There are no code changes, therefore seems everything is OK.
Ritika-Singhal commentedon Feb 6, 2022
#19787 requires one additional fix in here:
https://github.com/apache/airflow/blob/providers-amazon/3.0.0rc1/airflow/providers/amazon/aws/operators/glue.py
Need to modify the default value of
num_of_dpustoNone(which is currently set to 6).Without this fix, it becomes inconsistent with the logic changed in the airflow/providers/amazon/aws/hooks/glue.py. It then gives the error to the user if user doesn't specify
num_of_dpus=Nonewhile calling theAWSGlueJobOperatorFile "/Users/ritika/opt/anaconda3/lib/python3.7/site-packages/airflow/models/taskinstance.py", line 1511, in _execute_task result = execute_callable(context=context) File "/Users/ritika/opt/anaconda3/lib/python3.7/site-packages/airflow/providers/amazon/aws/operators/glue.py", line 123, in execute create_job_kwargs=self.create_job_kwargs, File "/Users/ritika/opt/anaconda3/lib/python3.7/site-packages/airflow/providers/amazon/aws/hooks/glue.py", line 74, in __init__ raise ValueError("Cannot specify num_of_dpus with custom WorkerType") ValueError: Cannot specify num_of_dpus with custom WorkerType [2022-02-05, 16:57:41 UTC] {local_task_job.py:154} INFO - Task exited with return code 1mariotaddeucci commentedon Feb 6, 2022
#20807 all good.
#20506 was tested on #20615
(amazon 2.6.0)Ritika-Singhal commentedon Feb 6, 2022
For an additional fix for #19787, I have created another pull request #21353
All other functionalities in #19787 works as expected.
potiuk commentedon Feb 6, 2022
Ok. Still worth testing Amazon changes on this version but I will remove Amazon + Docker (if confirmed) and prepare RC2 right after we release all others and get fixes merged. Thanks @Ritika-Singhal @raphaelauv !
potiuk commentedon Feb 6, 2022
I also removed some of the "no-need-to-test" changes (and 2.6.0 amazon changes - which was a bug in generation of the issue - sorry for that.
rsg17 commentedon Feb 6, 2022
Hi @potiuk - It is my first time doing this testing: Are there any specific steps we follow?
My PR adds a hook for Google Calendar.
potiuk commentedon Feb 7, 2022
Good question. Depends on your "local" environment. But what I would do, is to use:
This will start our dockerized development environment with Airflow 2.2.3 installed and open 4 terminals: triggerer, scheduler, webserver and "bash console".
In the console:
Then restarting scheduler/webserver (by Ctrl+C) followed by "up cursor" to go back and run previous command
For that you likely need to configure the "google_default_connection" to include your credentials. You can put your dags in "files/dags" folder of your Airlfow sources (the "files" folder is mounted to inside the docker) and they should be scanned/visible in webserver
malthe commentedon Feb 7, 2022
@potiuk – Oracle and PSRP providers all good.
josh-fell commentedon Feb 7, 2022
@potiuk Part of #21237 was adding 3 new lexers for the SQL rendering in the UI. For the providers that use the new lexers, the rendering won't be as readable as it could be because the configured lexer doesn't exist yet (i.e. the rendering becomes a Python type rendering). Do we want to wait on releasing #21237 at all until those lexers are available or not push the SQL
template_fields_rendererschange for those particular providers yet?For example, there is a new

postgresqllexer and added to theRedshiftSqlOperator(among others). Without the new lexer in core Airflow, the rendering of the SQL statement looks like this:Instead of:

potiuk commentedon Feb 7, 2022
Good point Josh. I think this one might be a bit tricky, I do not think it is "blocker" - the rendering is not nice but it does not "break" anything.
However I thought it might be a nice way to incentivize people to migrate to 2.2.4 if we also cherry-pick the lexer to 2.2.4. Then we could telll them "migrate to 2.2.4 to get it nicer". This is a new feature - of course - so technically we shoud add it in 2.3.0. So I am a bit torn here.
There are quite a number of those providers that are only released because of this renderer so we can easily skip them from this release and release them when we release 2.3.0
@jedcunningham @josh-fell @wdyt?
potiuk commentedon Feb 7, 2022
The second option is to indeed drop all the "21237" providers an release them in RC2 with some "conditional" code that will check if the lexer is there. After thinking a bit I think that would be much "cleaner" solution and I am leaning towards this option.
smth like:
jedcunningham commentedon Feb 7, 2022
I'd rather not include it for 2.2.4 since, as you said, it's a new feature. Doing it conditionally, until the next lower bound bump, I think makes sense.
potiuk commentedon Feb 7, 2022
Yeah. It's easy enough to fix and I agree it's better.
I think - due to the the number of those affected, it makes more sense to cancel the whole release and re-release all providers as RC2 with that fix to not mess with two releases. there are no super-urgent changes in this wave.
potiuk commentedon Feb 7, 2022
As discussed above ^^ I will cancel the whole vote/release and will make an RC2 as soon as we release the conditonally working SQL renderer. Thanks @josh-fell for spotting this and raising it!