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 <[email protected]> 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. >
