#3623 - Notification of non-launches, unauthorized launches

Jan Provazník jprovazn at redhat.com
Wed Aug 8 08:52:43 UTC 2012


On 08/07/2012 06:37 PM, Matt Wagner wrote:
> Hi all,
>
> I had a few questions on
> https://www.aeolusproject.org/redmine/issues/3623 and its implementation
> task, #3624.
>
> It all makes sense on the surface -- if a launch fails, or a user tries
> to launch but doesn't have permission (which is really a subset of
> "a launch fails"), we want to record a notification and display it.
>
> But I find that, as I go to implement this, things become hazier.
>
> For one, if you don't have permission to launch a deployable, the button
> is disabled. We can have the controller log a notification if it refuses
> permission anyway (such as if someone hits the URL directly), but it
> doesn't feel like I'm tackling an urgent customer priority there. Am I
> overlooking a case where a user would be able to go launch a deployable
> but then have it fail with a permissions error after they pressed the
> button?
>

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

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

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

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

> -- Matt
>

Jan


[1] OT: now I realized that we will have to re-check permissions and 
quota  on delayed_job side anyway even though we don't support delayed 
launch (launch requests are now sent immedietly after it's queued) - if 
delayed_job is down for a while, queued launch requests will be executed 
with delay after it's restarted. Anyway this is not part of #3623.



More information about the aeolus-devel mailing list