#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