Re: [DISCUSS] Add "new version available" indicator to UI/CLI ?

[Jarek Potiuk <ja...@potiuk.com>]

Hello - anyone else thinks this might be useful ?

J.

On Mon, Aug 30, 2021 at 1:29 PM Tomasz Urbaszek <tu...@apache.org>
wrote:

> I think this can be a really useful feature. Especially for those who
> manage Airflow deployments on their own.
>
> > 3) How "annoying" and "how often" should it be shown ? Should you be
> able to dismiss it? For some time maybe ? Till next release?
>
> I think per release update should be enough and users should be able to
> dismiss it. Another thing to consider is the cost of egress and the
> possibility that some environments can be isolated or the traffic can be
> controlled.
>
> > 4) In the UI - should it be visible to all users or just Admins in the
> UI?
> > 5) Should it be "per user" or "per installation" warning UI (dismissible
> for everyone or per each user individually)?
> > 6) Should it be possible to disable it altogether ? How difficult should
> it be? Just a config param or maybe you'd need to write a custom handler to
> disable it?
>
> Personally I would be in favor of configuring this per installation. I
> would do a flag in config (enable_updates or something). This would help
> service providers to disable this by default because they are not always
> able to update asap. Not every user can do the update of the Airflow
> version. So we may want to consider introducing a role/privilege that can
> be granted to users who can do the update and only those users would be
> able to see the info. Otherwise admins/devops may be flooded by engineers
> asking for the update. Regarding dismissing - it should be per user imho.
> In this way it the chance to find someone willing to upgrade would be
> better :D
>
> > 7) Should it be "customizable" (a bit connected to the above) should you
> be able to write a custom handler to decide and display your own upgrade
> information.
>
> Here it would be good to get service providers' opinions. If they don't
> want it I don't see a big advantage in having one more component
> configurable. We can introduce customizability later if requested. Another
> aspect of making this feature customizable is the possibility to use it for
> a multitude of different other purposes. Instead of checking the version I
> can imagine that it could call any service that would have a feasible
> interface.
>
> Cheers,
> Tomek
>
>
> On Mon, 30 Aug 2021 at 12:16, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> Hello everyone,
>>
>> I thought about it and I think that in order to "promote" migrating to a
>> newer version of Airflow, it would be great to add an indication that there
>> is a newer version available (and link to release notes).
>>
>> I discussed it before in a few discussions I had on slack. And I
>> initially thought this is not necessarily part of Airflow as a "product".
>> For example Astronomer has such an indicator in their service and it's
>> great and it feels natural to have it in managed versions of Airflow. So I
>> initially thought this might be one of the things that is not part of the
>> product itself.
>>
>> However, the more I think about it, the more it makes sense to make it as
>> part of "Airflow" itself. Especially the on-premise users might not monitor
>> the devlist or PyPI or announcements we make and when we make them aware
>> there is a new version, this might trigger the migration effort.
>> Especially if we make it "hard to disable" and "a bit annoying" (but just a
>> bit). I believe the users are not yet "aware" how different Airflow 2 is
>> when it comes to backwards compatibility "promise" and they hang-on with
>> the currently installed version of Airlfow 2 longer than they should, I
>> think, so promoting the upgrades is something we want, so this might be a
>> great "communication" tool as well and the message we can put there might
>> be strongly encouraging users to migrate.
>>
>> I think we do not even have to have any kind of "service" for that. It
>> would be enough to check it via PyPI (or GitHub) API whether there is a
>> newer released version (and we can gracefully handle cases where those are
>> unreachable due to firewalls etc.).
>>
>> I would love to get some thoughts and feedback on that. I specifically
>> think about  such questions:
>>
>> 1) Should we do it at all?
>>
>> 2) Should it be in both UI and CLI?
>>
>> 3) How "annoying" and "how often" should it be shown ? Should you be able
>> to dismiss it? For some time maybe ? Till next release?
>>
>> 4) In the UI - should it be visible to all users or just Admins in the UI?
>>
>> 5) Should it be "per user" or "per installation" warning UI (dismissible
>> for everyone or per each user individually)?
>>
>> 6) Should it be possible to disable it altogether ? How difficult should
>> it be? Just a config param or maybe you'd need to write a custom handler to
>> disable it?
>>
>> 7) Should it be "customizable" (a bit connected to the above) should you
>> be able to write a custom handler to decide and display your own upgrade
>> information. Note - this might be great for managed services like
>> Astronomer. MWAA, Composer as they could just plug-in their internal
>> versions check rather than modifying the UI of Airflow and pass their own
>> message/links to upgrade docs etc..
>>
>> I have my thoughts on all of that - but wanted to hear what others think
>> first.
>>
>> J.
>>
>

Re: [DISCUSS] Add "new version available" indicator to UI/CLI ?

[Juan Pablo Salado García <jp...@gmail.com>]

Hi, my thoughts on that:

1) Should we do it at all?
I think this gives value to the product, so yes.

2) Should it be in both UI and CLI?
For the UI 100%, for the CLI I'm not so confident (~80%), as people who
manage the CLI might be more aware of updates already.
I attached a picture below on how it could be shown in the UI (pgadmin has
sth similar)
On the other hand, throwing another line with a noticeable color in the CLI
when running the scheduler or the web server could be an easy way to remind
people of updates.

3) How "annoying" and "how often" should it be shown ? Should you be able
to dismiss it? For some time maybe ? Till next release?
+1 to what Tomasz said about hinting once per release update.

4) In the UI - should it be visible to all users or just Admins in the UI?
Just admins.

5) Should it be "per user" or "per installation" warning UI (dismissible
for everyone or per each user individually)?
Per admin user.

6) Should it be possible to disable it altogether ? How difficult should it
be? Just a config param or maybe you'd need to write a custom handler to
disable it?
Just a config flag could be enough.

7) Should it be "customizable" (a bit connected to the above) should you be
able to write a custom handler to decide and display your own upgrade
information. Note - this might be great for managed services like
Astronomer. MWAA, Composer as they could just plug-in their internal
versions check rather than modifying the UI of Airflow and pass their own
message/links to upgrade docs etc..
It's a great idea, but I would not prioritize this.

Extra: This is a screenshot from pgadmin, they have sth similar to what you
propose.
[image: pgadmin_ui.PNG]

El dom, 12 sept 2021 a las 18:48, Jarek Potiuk (<ja...@potiuk.com>)
escribió:

> Hello - anyone else thinks this might be useful ?
>
> J.
>
> On Mon, Aug 30, 2021 at 1:29 PM Tomasz Urbaszek <tu...@apache.org>
> wrote:
>
>> I think this can be a really useful feature. Especially for those who
>> manage Airflow deployments on their own.
>>
>> > 3) How "annoying" and "how often" should it be shown ? Should you be
>> able to dismiss it? For some time maybe ? Till next release?
>>
>> I think per release update should be enough and users should be able to
>> dismiss it. Another thing to consider is the cost of egress and the
>> possibility that some environments can be isolated or the traffic can be
>> controlled.
>>
>> > 4) In the UI - should it be visible to all users or just Admins in the
>> UI?
>> > 5) Should it be "per user" or "per installation" warning UI
>> (dismissible for everyone or per each user individually)?
>> > 6) Should it be possible to disable it altogether ? How difficult
>> should it be? Just a config param or maybe you'd need to write a custom
>> handler to disable it?
>>
>> Personally I would be in favor of configuring this per installation. I
>> would do a flag in config (enable_updates or something). This would help
>> service providers to disable this by default because they are not always
>> able to update asap. Not every user can do the update of the Airflow
>> version. So we may want to consider introducing a role/privilege that can
>> be granted to users who can do the update and only those users would be
>> able to see the info. Otherwise admins/devops may be flooded by engineers
>> asking for the update. Regarding dismissing - it should be per user imho.
>> In this way it the chance to find someone willing to upgrade would be
>> better :D
>>
>> > 7) Should it be "customizable" (a bit connected to the above) should
>> you be able to write a custom handler to decide and display your own
>> upgrade information.
>>
>> Here it would be good to get service providers' opinions. If they don't
>> want it I don't see a big advantage in having one more component
>> configurable. We can introduce customizability later if requested. Another
>> aspect of making this feature customizable is the possibility to use it for
>> a multitude of different other purposes. Instead of checking the version I
>> can imagine that it could call any service that would have a feasible
>> interface.
>>
>> Cheers,
>> Tomek
>>
>>
>> On Mon, 30 Aug 2021 at 12:16, Jarek Potiuk <ja...@potiuk.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I thought about it and I think that in order to "promote" migrating to a
>>> newer version of Airflow, it would be great to add an indication that there
>>> is a newer version available (and link to release notes).
>>>
>>> I discussed it before in a few discussions I had on slack. And I
>>> initially thought this is not necessarily part of Airflow as a "product".
>>> For example Astronomer has such an indicator in their service and it's
>>> great and it feels natural to have it in managed versions of Airflow. So I
>>> initially thought this might be one of the things that is not part of the
>>> product itself.
>>>
>>> However, the more I think about it, the more it makes sense to make it
>>> as part of "Airflow" itself. Especially the on-premise users might not
>>> monitor the devlist or PyPI or announcements we make and when we make them
>>> aware there is a new version, this might trigger the migration effort.
>>> Especially if we make it "hard to disable" and "a bit annoying" (but just a
>>> bit). I believe the users are not yet "aware" how different Airflow 2 is
>>> when it comes to backwards compatibility "promise" and they hang-on with
>>> the currently installed version of Airlfow 2 longer than they should, I
>>> think, so promoting the upgrades is something we want, so this might be a
>>> great "communication" tool as well and the message we can put there might
>>> be strongly encouraging users to migrate.
>>>
>>> I think we do not even have to have any kind of "service" for that. It
>>> would be enough to check it via PyPI (or GitHub) API whether there is a
>>> newer released version (and we can gracefully handle cases where those are
>>> unreachable due to firewalls etc.).
>>>
>>> I would love to get some thoughts and feedback on that. I specifically
>>> think about  such questions:
>>>
>>> 1) Should we do it at all?
>>>
>>> 2) Should it be in both UI and CLI?
>>>
>>> 3) How "annoying" and "how often" should it be shown ? Should you be
>>> able to dismiss it? For some time maybe ? Till next release?
>>>
>>> 4) In the UI - should it be visible to all users or just Admins in the
>>> UI?
>>>
>>> 5) Should it be "per user" or "per installation" warning UI (dismissible
>>> for everyone or per each user individually)?
>>>
>>> 6) Should it be possible to disable it altogether ? How difficult should
>>> it be? Just a config param or maybe you'd need to write a custom handler to
>>> disable it?
>>>
>>> 7) Should it be "customizable" (a bit connected to the above) should you
>>> be able to write a custom handler to decide and display your own upgrade
>>> information. Note - this might be great for managed services like
>>> Astronomer. MWAA, Composer as they could just plug-in their internal
>>> versions check rather than modifying the UI of Airflow and pass their own
>>> message/links to upgrade docs etc..
>>>
>>> I have my thoughts on all of that - but wanted to hear what others think
>>> first.
>>>
>>> J.
>>>
>>