#3623 - Notification of non-launches, unauthorized launches

Jaromir Coufal jcoufal at redhat.com
Thu Aug 9 12:06:57 UTC 2012



On 8.8.2012 20:21, Matt Wagner wrote: 


On Wed, Aug 08, 2012 at 10:52:43AM +0200, Jan Provazník wrote: 
<blockquote>
On 08/07/2012 06:37 PM, Matt Wagner wrote:

No, you can't have failed deployment because of permissions check
[1]. I think that by "...or are not authorised" in #3623 description
Angus meant not-yet-implemented declined approval (a user asks for
launch approval which is declined). 

I was talking to Scott this morning about this as well. It seems like
this feature largely refers to the "Launch at XYZ time" and "Let this
user launch this, but only with an admin's approval" use cases. But
those features aren't yet implemented, so it's not terribly sane to go
about trying to implement notifications there yet. 
</blockquote>
Yes, you are right, this task should refer to these two use cases. They might not be implemented yet but we need to think how to display them. In my opinion we have time for implementation till we decide how to display these features in UI. 


Unfortunately I have lot of work to do in fixes for 1.1 (currently forms) so I guess that we will discuss it on UI meeting further. I had on my mind to create special section for notification as well as dashboard, but as I said it is for longer run and I hope that we will discuss it in Westford. 
<blockquote>

<blockquote>

<blockquote>
Second, I'm having a hard time even finding a way to intentionally cause
a launch failure. For the most part, if it's something not on the cloud
provider itself, we seem to detect it and disable the Launch button.
Is there any obvious use case I'm overlooking? 
</blockquote>
The launch process has two phases:
1) transaction in which we create a deployment and do all possible
checks. If something goes wrong, rollback is done, deployment is not
created and a user stays on deployment new page with descriptive
error message (see app/models/deployment.rb#launch! method) 
</blockquote>
Is it safe to say that we shouldn't create a notification here? Or is
there some weird case where an admin might want to see that a user got
such-and-such an error here? 
</blockquote>
Well thinking about this - there might be case that admin wants to see what happened. For example let's imagine situation where as a user I have prepared deployable which I am allowed to use and I need to launch it. It fails to create a deployment, but I am not allowed to manipulate with deployable to fix it. Of course I probably contact admin that I can't continue in work, but he should be able to track this situation in system as well. 
<blockquote>

<blockquote>
2) sending of launch requests - this is done on background by
delayed_job because it may take more time. If something goes wrong,
deployment (and instances) stays created and create_failed state is
set. You are right that these are mostly errors returned by dc-api or
config server.
(see app/models/deployment.rb#send_launch_requests)
These are use cases Justin and Joe mentioned. Another examples:
- provider is not accessible
- provider account doesn't work (wrong credentials, disabled)
- dc-api is not running (well, we check this every 5 minutes)
- hw profile mismatch 
</blockquote>
This part sounds doable -- putting in sane/detailed error messages here.

I looked at whether we could just use the existing Event model here,
though I think Mainn was right in suggesting that it wasn't a good idea
and that we should just create a new model.

I did have one of those "Why didn't I think of this earlier?" ideas
here, though. For Events, one problem we have is that we record an
English string when it occurs, which obviously breaks translation,
since it's a string in the database. I think the sanest thing to do here
might be to just put the i18n _key_ in the database, and interpret that
at display time. That seems like it would solve the issue of translating
errors while showing adequate detail, and avoid us the headache of
having to try to map "Error 575" or something to a useful string. We
could do this in a new Notifications model.

But at some point, shouldn't Notifications reference an Event? They seem
somewhat similar.

Also: should Notifications be dismissable? (Dismissible?) It sort of
seems like we should, but this really complicates things, since now you
need to keep track of who should see a given notification, and record
who has dismissed them. Or can we say that the first person to dismiss a
notification gets rid of it for everyone? (This is all from the
"thinking out loud" category, obviously.) 
</blockquote>
I would say YES for dismissable notifications and NO for the last one (general dismiss). It's not safe to dismiss notification by first person who has seen it. 

I would suggest such system, that each person has his own notification system based on permissions which he has assigned. So if he can manipulate with concrete objects he will receive notifications about these objects and dismiss them by seeing on his own. When he displays the notification message, it would not appear in his notification area anymore, but it still would be kept in all notification list. Very briefly is this idea captured in my attached mock-up, but it's just really first thoughts and it will need a discussion. 

[snip] 


<blockquote>

<blockquote>

<blockquote>
Am I overlooking some conditions / use cases here? I'm not finding a
whole lot that needs to be done. 
</blockquote>
I think this task is mostly about improving notification UI
(currently represented by 'Alerts' section) and about what
information should be there. I had a call about this with Scott,
Angus and Jaromir - It would be best to contact Jaromir and discuss
this with him too (CCing him) - he has some ideas about this. 
</blockquote>
Jaromir, I'd love to hear your thoughts here. 
</blockquote>
I am sorry, I was on NHO, so I got to this mail just now. 

I think that this task would be solved by improving notifications in general and I would like to suggest a little bit different model than Alerts which are used now. It also refers to the question "how to display different states of instances". I would like to create wiki page about all of this but I think that I will prepare it after meeting in Westford when we have more discussions. At least you can go through attached mock-up if you are interested, but it is my very first brief idea of notifications - almost not discussed with anybody so it might look very differently in the end. 


In conclusion, I think that we should wait with implementation after we have some design prepared. 

--Jarda 
-- 
Jaromír Coufal

Interaction Designer
Red Hat Czech s.r.o.

Mobile: +420 724 595 508
E-mail: jcoufal at redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120809/af8180b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: notifications_mock-up.pdf
Type: application/pdf
Size: 70488 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120809/af8180b2/attachment.pdf>


More information about the aeolus-devel mailing list