#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