-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
Status of testing Providers that were prepared on July 15, 2021 #17037
Comments
for the docker provider apache-airflow-providers-docker==2.1.0rc1 still failing for docker in docker I tried with airflow 2.1.2 t3 = DockerOperator(
api_version='auto',
docker_url="unix://var/run/docker.sock",
command='/bin/sleep 30',
image='centos:latest',
network_mode='bridge',
task_id='docker_op_tester',
dag=dag,
) give
the line if self.host_tmp_dir in str(e): is buggy a fix -> #17061 |
for the cncf.kubernetes provider apache-airflow-providers-cncf-kubernetes==2.0.1rc1 still failing with the an arg containing ".json" I tried with airflow 2.1.2 k = KubernetesPodOperator(
namespace=namespace,
image="hello-world",
labels={"foo": "bar"},
arguments=["vivi.json"],
name="airflow-test-pod",
task_id="task-one",
...
) give
|
Indeed - I remove docker provider from this round and prepare a next RC. My mistake :) |
@raphaelauv Are you sure you had |
Not really. With ".json", this is expected behaviour. As I understand it, previously the problem was that |
then it could need a new option to let the user disable the templating on the field But the issue should not be considered done since the OP asked for ".json" |
Sometimes the description is not precise enough. Actually what you propose is a new feature not a bug - would you like to propose PR for that? |
I propose to re-open the issue #16922 since it's still happening. |
otherwise k = KubernetesPodOperator(
namespace=namespace,
image="hello-world",
labels={"foo": "bar"},
arguments=["vivijson"],
...
) do not throw anymore an error with apache-airflow-providers-cncf-kubernetes==2.0.1rc1 |
I will let @kaxil and @eladkal tell here what they think. In here we are very focused on getting community opinions on issues (committers have binding votes). In the meantime, I strongly encourage you @raphaelauv to open a PR with proposed new feature. Due to backwards compatibility this anyhow needs to be discussed and opinion of at least a few people has to be taken into account if we are going to implement such a change, as it impacts ~70 providers and ~600 operators, so it is highly unlikely to be resolved (and issue reopened) with an issue related to one operator. Our community works on reaching consensus and discussing such things, their consequences, backwards compatibilities etc. |
I don't need that feature and not asking for, just caring about the guy that opened the issue and that think that is problem is solved. I just don't want miss communication. |
i started discussion there. Airflow is a community managed project, and it is quite common when you "want" something, you are asked to contribute that, especially if it is not a big fix. A lot of people here who use airflow and comment here, also contribute back fixes and features so this is very common that we are asking people to help with what they think is a good feature. If you make a statement that something "should" be done, I think it is only natural that you "want" this to happen and in open-source world, the natural consequence might be that you are asked to contribute it. |
Again , I don'k ask for anything , just proposing to let know the guy of the issue. I have probably not been clear in my messages, I just wanted to contribute by helping to check the new RC providers. |
This is cool that you want to help. I did not want to discourage it, I just politely asked if you would like to contribute it (which you do not have to). And look what happened - I started the discussion in the original issue #16922 and also asked the author what he thinks :). So I think we are pretty aligned here. My question to you was just the normal thing that happens in open-source - we are asking people who raise concerns and expres opinions, to help. This is how our community works :). Not sure why the frowning faces here, I was just acting with a very good intent here. It's ok to have different opinions and discuss, and it's also OK to ask people who raise concerns, if they are ok to follow up and contribute, I think. |
it's the emoji : confused cause I was not understanding why you explain me all this common sense about OSS , let me remove them. |
Really - what we are here up to is to get help from everyone who participates, and we are gently and politely (I hope) asking people to participate. If my question was understood differently - I think this is more of the medium :). Not everyone understands it - apologies if it created confusion |
Hi, in a virtualenv in which I installed RC1, the apache.drill: 1.0.0rc1 provider does work. I do have two notes of things I didn't expect.
|
Thanks for testing @dzamo! And thanks for being so thorough! Really appreciated!
Yep. Totally expected. Default connections is one thing that is not included in "provider packages". The default connections are part of "airflow" package as they are really only useful during testing and airflow development (so in
Yeah. This is a known issue that will be addressed in 2.1.3. #16579. It's internal webserver logs only (not task logs visible via Airflow UI) so while important to fix, it is not critical. |
Closed by mistake :). @pmalafosse @baolsen @hewe @scottypate @codenamestif @ciancolo @kaxil @Daniel-Han-Yang @namjals @malthe @BKronenbitter @oyarushe @LukeHong @saurasingh @freget @ashb @ciancolo @samgans - it would be great if at least some of those changes are tested :). Appreciate your help with that. |
Tested the MySQL operator and found the issue, could you please review fix #17080. |
Thanks. I will mark it also for rc2 and release together with Docker Provider separately. |
#16820 looks good |
Some more tests would be nice :) |
Regarding the Amazon provider, looks like not all |
Sounds like we might want to release all the packages together with rc2 :D |
Correct, the issue was with |
Verified #16767 and it is working as expected 😃 |
there is a problem with #16365. In the case of With Check #17125 for the bug fix.
|
Tested #16350 on my local Sqoop env and it works as expected |
There were quite a bit too many problems with this wave, I am going to release a second rc2 wave with all the providers with fixes soon (plus few more changes). Closing this one for now. |
Cool. Thanks! |
There is a bug with #16685 I will create a fix by tomorrow |
Ahh. Seems like REALLY buggy release candidate set this time :). I will wait for the fix then with rc2 @pmalafosse !. Thanks for letting me know! |
Thanks! The fix is in that PR #17141 |
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.1.0rc1
Provider apache.hive: 2.0.1rc1
Provider apache.sqoop: 2.0.1rc1
Provider cncf.kubernetes: 2.0.1rc1
json
string in template_field fails with K8s Operators (#16930): @kaxilProvider docker: 2.1.0rc1- [ ] [Adds option to disable mounting temporary folder in DockerOperator (#16932)(https://github.com//pull/16932): @potiuk: bug found.Provider google: 4.1.0rc1
Provider jenkins: 2.0.1rc1
Provider microsoft.azure: 3.1.0rc1
Provider mysql: 2.1.0rc1: Marking for RC2 release- [ ] Added template_fields_renderers for MySQL Operator (#16914): @oyarushe- [ ] Extended template_fields_renderers for MySQL provider (#16987):@oyarusheProvider postgres: 2.1.0rc1
Provider sftp: 2.1.0rc1
Provider snowflake: 2.1.0rc1
Provider ssh: 2.1.0rc1
Provider tableau: 2.1.0rc1
New Providers
The text was updated successfully, but these errors were encountered: