#3623 - Notification of non-launches, unauthorized launches

Matt Wagner matt.wagner at redhat.com
Wed Aug 8 18:21:51 UTC 2012


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.

> >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?

> 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.)

> >For failures that _are_ on the cloud provider, those will already show
> >up in our "Alerts" section, which lists failed instances.
> >
> 
> Well, not exactly - a failed instance will show up there but w/o a
> reason why the instance failed because last_error is not set when:
> - launch request fails
> - deployment rollback is done and all instances which were not
> launched are marked as create_failed.

Ah, good point. So we need to expand this a bit, too.

> 
> >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.



More information about the aeolus-devel mailing list