<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#333333" bgcolor="#FFFFFF">
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 :)<br>
<div class="moz-cite-prefix"><br>
On 8.8.2012 20:21, Matt Wagner wrote:<br>
</div>
<blockquote
cite="mid:20120808182151.GD11756@mawagner-desktop.usersys.redhat.com"
type="cite">
<pre wrap="">On Wed, Aug 08, 2012 at 10:52:43AM +0200, Jan Provazník wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</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.
<div><br>
</div>
<div>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.
</div>
<blockquote
cite="mid:20120808182151.GD11756@mawagner-desktop.usersys.redhat.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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)
</pre>
</blockquote>
<pre wrap="">
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?</pre>
</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
cite="mid:20120808182151.GD11756@mawagner-desktop.usersys.redhat.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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.)
</pre>
</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.<br>
<br>
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.<br>
<br>
[snip]
<blockquote
cite="mid:20120808182151.GD11756@mawagner-desktop.usersys.redhat.com"
type="cite"><br>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Am I overlooking some conditions / use cases here? I'm not finding a
whole lot that needs to be done.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
Jaromir, I'd love to hear your thoughts here.
</pre>
</blockquote>
I am sorry, I was on NHO, so I got to this mail just now.<br>
<br>
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.
<div><br>
</div>
In conclusion, I think that we should wait with implementation after
we have some design prepared.<br>
<br>
--Jarda
<pre class="moz-signature" cols="72">--
Jaromír Coufal
Interaction Designer
Red Hat Czech s.r.o.
Mobile: +420 724 595 508
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:jcoufal@redhat.com">jcoufal@redhat.com</a>
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno</pre>
</body>
</html>