Hello - anyone else thinks this might be useful ? J.
On Mon, Aug 30, 2021 at 1:29 PM Tomasz Urbaszek <[email protected]> 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 <[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. >> >
