I opened a few tickets for INFRA and I am also waiting for answer. I guess
Xmas period got in the way.
J.
On Mon, Dec 30, 2019 at 5:15 AM Kevin Yang wrote:
> +1!
>
> Kaxil Naik 于2019年12月29日 周日下午6:21写道：
>
> > Thanks Max,
> >
> > I will raise a JIRA with the INFRA to add that too.
> >
> > Btw I h
I agree we need more detailed instructions when we release 2.0.
I think however we should wait with describing all details and instructions
until we are closer to 2.0 release and
we close the list of incompatibilities. I think for now just describing
what changed should be enough.
We might yet wa
+1!
Kaxil Naik 于2019年12月29日 周日下午6:21写道：
> Thanks Max,
>
> I will raise a JIRA with the INFRA to add that too.
>
> Btw I had raised a request for the 4 integrations
> https://issues.apache.org/jira/browse/INFRA-19607 but looks like it hasn't
> gained any traction from them yet.
>
>
>
> On Fri, Dec
Hi David,
A few reasons why SubDagOperator was strongly discouraged in the past:
- No concurrency control, e.g. you cannot control the number of parallel
tasks in the subdag via pool or DAG concurrency. SubDagOperator used to
rely on the backfill scheduler which did not have any concurre
Thanks Max,
I will raise a JIRA with the INFRA to add that too.
Btw I had raised a request for the 4 integrations
https://issues.apache.org/jira/browse/INFRA-19607 but looks like it hasn't
gained any traction from them yet.
On Fri, Dec 20, 2019 at 8:29 PM Maxime Beauchemin <
maximebeauche...@g
Hello,
I think that before automatic tools, we should try to improve the manual
process. Some notes in the UPDATIND.md file are laconic, enigmatic and do
not allow you to migrate easily.
I have created PR, which contains some tips
https://github.com/apache/airflow/pull/6960/files
If we develop a p
I find them to be very useful. I think it is an easy way to group a set of
tasks together that have a
one to many to one dependency structure. I find using a subdag to group the
many into a single task makes for a much cleaner dag and makes it easier to see
the status of the dag.
I read many o
I think it's a rare thing for anyone to use a generic DB operations (as
operator). You usually know which database you have as source/target.
Even if in one company you have more than one database, then it is not a
problem to use one hook/operator in Postgres and another in MySQL etc.
IMHO it's be
>
> It's hard to guess how many test sets are required and how many
> extra lines of "marker code" are needed for each category and how the Venn
> diagrams work out.
I believe (but that's mostly gut feeling) that significant majority of our
tests
will fall into "no-marker" camp. @Tomasz Urbaszek
Hi all,
In my opinion we area great community but we are not "Airflow". If someone
finds us, then his or her troubles are probably solved. At least I hope so.
But last survey result includes a few really important "non-technical"
points:
When onboarding new members to Airflow, what is the biggest
The link to
https://docs.pytest.org/en/latest/example/markers.html#custom-marker-and-command-line-option-to-control-test-runs
helps
to clarify some of the customization required to add CLI options that
select test sets based on markers. +1 for a common default with *no
marker*. (It's hard to gues
Hey Jarek,
I really like the points you bring up. While reading your mail I thought about
the same things. For me at the beginning it was really hard to get into this
community and how everything works mostly because of the language. I am not
sure but maybe it would also be a good idea to organ
Hi all,
Apologies if this topic has already been treated.
I want to create a solution for a data pipeline and subdags are perfect due
to it allows me to group the phases / tasks on functional meaning. Reading
documentation and other experiences in internet, strongly recommend to
avoid them, what
Hello everyone,
TL; DR; I wanted to start a non-technical discussion about being (even
more) welcoming community.
It's a long read - following some deep discussions I had recently and you
might not be interested in it, so feel free to skip the entirety of it.
I also believe this might become qui
>
> If I understand correctly, using `pytest -k` might be less work and more
> generalized than a swag of custom makers, unless it entails a lot of
> re-naming things. The work to add markers might be easier if they can be
> applied to entire classes of tests, although what I've mostly seen with
>
Yes definitely, I had thought of something like py2to3 script. We might
want to create something similar.
On Sun, Dec 29, 2019, 14:17 Jarek Potiuk wrote:
> Great Claudio! Once we get closer to starting it, we can start some joined
> work on it :).
>
> I think we also will need the support of a
Great Claudio! Once we get closer to starting it, we can start some joined
work on it :).
I think we also will need the support of a number of "friendly" users with
that.
We can provide some basic migration tool initially but it will take quite a
few iterations to perfect it and handle all edge c
+1 Totally agree.Really would to work on this tool!Have a nice day!Claudio
Messaggio originale Da: Jarek Potiuk
Data: 29/12/19 13:27 (GMT+01:00) A:
dev@airflow.apache.org Oggetto: [PROPOSAL] [FUTURE] Semi-automated tool for
migration to 2.0.0 I thought (and discussed with the
I thought (and discussed with the users at various conferences) that we
should make it super-easy to migrate to Airflow 2.0 when we release it.
There is a number of incompatibilities that we mention in UPDATING.md so we
have quite a good 'base' for the list of incompatibilities but I think
people h
19 matches
Mail list logo
