#3623 - Notification of non-launches, unauthorized launches

Jaromír Coufal jcoufal at redhat.com
Thu Aug 9 12:19:27 UTC 2012


I am sorry for spamming, but formatting of my last e-mail was messed up 
in Zimbra, so I send it one more time, hopefully formatted in a human 
readable way :)

On 8.8.2012 20:21, Matt Wagner wrote:
> On Wed, Aug 08, 2012 at 10:52:43AM +0200, Jan Provazník wrote:
>> 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.
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.
>>> 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?
>> 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)
> 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?
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.
>> 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
> 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.)
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]
>
>>> Am I overlooking some conditions / use cases here? I'm not finding a
>>> whole lot that needs to be done.
>>>
>> 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.
> Jaromir, I'd love to hear your thoughts here.
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/df93b77d/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/df93b77d/attachment.pdf>


More information about the aeolus-devel mailing list