Jarek,

No worries (: 🍻
--
,,,^..^,,,


On Tue, Nov 22, 2022 at 3:42 PM Jarek Potiuk <[email protected]> wrote:

> Cool. I understand. Good example. Might contribute to the discussion.
> But let's not discuss in this thread if you can /cannot run workers. I
> started this and that was a mistake - as it diverges from the main
> topic. So the comment was mainly to myself as I was diverging from the
> main topic.
>
> On Tue, Nov 22, 2022 at 1:34 PM Alexander Shorin <[email protected]> wrote:
> >
> > Jarek,
> >
> > I'm probably not ready to introduce this topic and push it forward, but
> I just wanted to clarify what are the borders of breaking changes and how
> they are applied to Airflow itself. Practice shows they are not, so it's
> may be a problem that you raised on the topic. Or may be not. It's
> discussion anyway (:
> >
> > --
> > ,,,^..^,,,
> >
> >
> > On Tue, Nov 22, 2022 at 3:00 PM Jarek Potiuk <[email protected]> wrote:
> >>
> >> I propose let's not "diverge" the discussion with this specific case
> >> and whether it's easy or not. Let's focus on general approach and
> >> whether the approach to make a policy makes sense in this (or
> >> different way) but let's not argue if it is easy to deploy airflow
> >> with mutliple different versions or not - this is a different topic
> >> and if you think you have a case where you would like to introduce the
> >> capabiliy of running airflow this way (which is a new and first time
> >> raised feature) - i propose you start different thread Alexander.
> >>
> >> On Tue, Nov 22, 2022 at 12:39 PM Abhishek Bhakat
> >> <[email protected]> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I Beg to differ with Alexander and agree with Jarek. There are
> multiple ways to deploy Airflow. Mostly commonly used is docker images, in
> that case using one image for all components is standard practice. If using
> native pip installations, airflow components are launched by a single pip
> module. So, to have different versions of components (as you mentioned) is
> adding extra work just to keep them out of sync. A basic common sense would
> be not to take extra steps to self sabotage.
> >> >
> >> > Thanks,
> >> > Abhishek
> >> >
> >> > On 22-Nov-2022 at 4:35:09 PM, Alexander Shorin <[email protected]>
> wrote:
> >> >>
> >> >> On Tue, Nov 22, 2022 at 1:37 PM Jarek Potiuk <[email protected]>
> wrote:
> >> >>>
> >> >>> BTW. "Workers from 2.2" used with "Airflow 2.4" is not even a thing.
> >> >>> This is something that you should never, ever, try to do.
> >> >>> This is even more common sense, and there are of course limits of
> what
> >> >>> you can describe in the docs (whatever you come up with, someone
> might
> >> >>> have a super crazy idea that you have not thought about and - for
> >> >>> example - run Airflow 1.10 worker With Airflow 2 (why not? We have
> not
> >> >>> written it should not happen).
> >> >>
> >> >>
> >> >> At scale, you cannot upgrade all the versions and keep them in sync
> all the time. For minor versions compatibility is expected. Obviously, it
> doesn't for major one. It is common sense and practice in the real world,
> sorry.
> >> >>
> >> >> --
> >> >> ,,,^..^,,,
> >> >>
> >> >>
>

Reply via email to