Add prominent sticky alerts for important task state error messages

[mrmachine]

Is your feature request related to a problem? Please describe.
Docker Swarm does not provide a solution for auto scaling infrastructure (worker nodes) based on task resource reservations. We are expected to just have a swarm of sufficient capacity to execute all tasks, or create our own auto-scaling based on custom monitoring and alerts.

If a developer goes to Portainer to deploy a new stack, or increase the number of replicas on an existing service, they might find that their task is pending indefinitely. This is not even obvious as you need to be looking at a task list to notice it, and then you need to click into a task detail page to see the reason (error message) why it is pending.

So it's very easy for a developer who is not already keenly aware of the dynamic between creating and scaling services and scaling infrastructure (all manually), to miss, and for tasks to just not execute for some time.

Describe the solution you'd like
I'd like a persistent sticky alert to appear in the top right, just like the errors (red) and warnings (orange) we already have for things like "failed to retrieve ..." or "failed to create stack", etc.

This should happen no matter which page you are viewing in the Portainer UI, for important task states and error messages (such as the one described in #888, "no suitable node (insufficient resources on 1 node)"). It should persist until you dismiss it, and if you click it should take you to the relevant task detail page for more information.

The error message could also be displayed in task lists as a column next to Status, or at least as a tooltop when you hover over the Pending badge.

And for bonus points, the ability to configure alerts via email or or webhook. The webhook could allow us to automatically scale up infrastructure as tasks are scheduled.

Describe alternatives you've considered
Capturing the number of pending tasks somehow (maybe something like https://stackstorm.com/2017/06/22/autoscaling-swarm-aws-stackstorm/) and sending to DataDog as a custom metric, configuring alerts from there to email/slack/webhook for manual or automated infrastructure scaling.

But for our use case, this problem should only be an issue when a developer is manually deploying stacks or scaling services via Portainer UI. It makes sense for this information to be immediately and directly relayed to the developer who is doing that work, so that they know their change has not been successful and can immediately fix it manually.

[deviantony]

@ncresswell thoughts? Wonder if this should be discussed in #943 instead ?

[mrmachine]

@deviantony I think this ticket is about notifying the developer who is using Portainer immediately, as they are right at that very moment attempting to deploy a stack or scale a service. #943 sounds like my "bonus points" wish for a webhook so we could think about automating our response to various errors, but I don't think that should delay or supersede this.

[ncresswell]

I like the idea of this, but i dont see how we are going to be able to address it in the near future given current development load. Happy to accept a pr for it tho. Rgds, Neil Cresswell On 5/05/2018, at 6:37 PM, Anthony Lapenna <notifications@github.com<mailto:notifications@github.com>> wrote: @ncresswell<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ncresswell&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=EhqiPvBfYLqfmDP69dCmpZBnI8J5Ea8gZqBGMhSb6E0&s=FxTwQQnz5EMFhSX4X1UeqDfFsLiG8jwokP7wmWBYQS4&e=> thoughts? Wonder if this should be discussed in #943<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_943&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=EhqiPvBfYLqfmDP69dCmpZBnI8J5Ea8gZqBGMhSb6E0&s=2KQsC9GDm96_iBiXTPKDWBWWjPzM1V6Qp76njEY1whE&e=> instead ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_1864-23issuecomment-2D386783975&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=EhqiPvBfYLqfmDP69dCmpZBnI8J5Ea8gZqBGMhSb6E0&s=SNOnoFpESdb0yavpmeO8Z_NSh0FgGFpuz2PNROfES0k&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AWGrlZO1VlIWLPWadyncEbNmTw8ApfOCks5tvUi8gaJpZM4TzhPv&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=EhqiPvBfYLqfmDP69dCmpZBnI8J5Ea8gZqBGMhSb6E0&s=tAxHfUYROJXlyCFCxIQTxWovGRH7oGgGZQcP4L7wbtA&e=>.

[deviantony]

As a first step, I believe that we could display this information to the user at service creation time.