Wrong provider name in answers.conf, exits AtomicApp with readable error by surajssd · Pull Request #563 · projectatomic/atomicapp

surajssd · 2016-02-17T10:00:02Z

When provider name in answers.conf is wrong then AtomicApp fails with stack-trace and no error output which is user understandable. This happened because there was no check for the condition if
given provider_key does not match with any of the providers that are supported for now.

Fixes Issue #562

dustymabe · 2016-02-17T14:54:12Z

+
+import logging
+
+from atomicapp import set_logging


where is this used?

@surajssd remove unused import :)

dustymabe · 2016-02-17T15:00:34Z

@rtnpro @cdrage can you review this? Some questions to answer:

Should this issue be fixed in this way? Is there a better way? Should we sys.exit() straight from the code as is done here?

dustymabe · 2016-02-17T15:06:08Z

@rtnpro should we also write a test for this?

rtnpro · 2016-02-17T16:18:58Z

@@ -1,11 +1,18 @@
 # -*- coding: utf-8 -*-
+import sys
+


Unnecessary new line

rtnpro · 2016-02-17T16:37:48Z

@surajssd could you have a look at https://travis-ci.org/projectatomic/atomicapp/builds/109825603? I think with the suggested refactor, it should be OK.

rtnpro · 2016-02-18T12:14:27Z

@surajssd Mind adding unittests for getProvider?

dustymabe · 2016-02-18T14:51:06Z

+ raise NuleculeException("Invalid Provider - '{}', provided in "
+ "answers.conf (choose from 'docker', "
+ "'kubernetes', 'openshift', 'marathon')"
+ .format(provider_key))


If we choose to tell them what options they can use then we should be using the PROVIDERS constant from constants.py and not a hardcoded list.

yes can do that!

rtnpro · 2016-02-22T08:33:00Z

 return provider
+
+ # importing this on top of file leads to circular import
+ from atomicapp.nulecule.exceptions import NuleculeException


local imports are kind of hacks, and I prefer to avoid them. Let's not reference Nulecule* things in plugin.py at all, because, plugin.py is a dependency for Nulecule* and other things. Does it make sense?

Yes makes sense, but then what exception do I raise here?

So, as I had said earlier, let's raise an exception in nulecule/main.py when provider is None.

No need to raise any exception in plugin.py. It returns None because it's not able to find a provider. Simple, isn't it?

yes makes sense!! :)

rtnpro · 2016-02-22T11:36:00Z

@surajssd One last thing, could you add a unittest for get_provider(), https://github.com/projectatomic/atomicapp/pull/563/files#diff-093821a6e6f49d13d49fdcb4f911695dR91, in tests/units/nulecule/test_lib.py?

rtnpro · 2016-02-23T09:42:41Z

LGTM 👍 @dustymabe shall we merge it in to master?

dustymabe · 2016-02-23T16:15:58Z

@rtnpro I trust you. :) - merge away.

dustymabe · 2016-02-29T23:01:53Z

I think we need to do a better job of commenting the tests. Without knowing mock I should be able to read through the code and get a high level understanding of what it is testing.

surajssd · 2016-03-01T04:10:05Z

Yes sure, its harder for somebody not knowing mock to understand what is actually going on!

dustymabe · 2016-03-01T21:55:01Z

@surajssd - rebase on upstream master so we can merge..

bonus points if you comment the tests :)

When provider name in answers.conf is wrong then AtomicApp fails with stack-trace and no error output which is user understandable. This happened because there was no check for the condition if given provider_key does not match with any of the providers that are supported for now. Fixes Issue projectatomic#562.

surajssd · 2016-03-03T04:09:16Z

@dustymabe I have added comments, was little confused about what all to include into them, share your views.

dustymabe · 2016-03-04T04:51:13Z

@cdrage can you merge this if tests pass and you are satisfied with everything?

cdrage · 2016-03-04T15:28:44Z

Tests pass and code looks good. Thank you for the extensives tests by the way! 💃

dustymabe reviewed Feb 17, 2016
View reviewed changes

rtnpro reviewed Feb 17, 2016
View reviewed changes

Comment threadatomicapp/nulecule/lib.py Outdated
@@ -1,11 +1,18 @@
# -*- coding: utf-8 -*-
import sys

rtnproFeb 17, 2016
Copy link
Copy Markdown
Contributor
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unnecessary new line

surajssd force-pushed the sane-error-on-wrong-provider branch from 0cd8e76 to eae57d1Compare February 18, 2016 06:54

dustymabe reviewed Feb 18, 2016
View reviewed changes

surajssd force-pushed the sane-error-on-wrong-provider branch 4 times, most recently from 0813d76 to 87ed1adCompare February 22, 2016 07:18

rtnpro reviewed Feb 22, 2016
View reviewed changes

surajssd force-pushed the sane-error-on-wrong-provider branch from 87ed1ad to aa9414fCompare February 22, 2016 08:51

surajssd force-pushed the sane-error-on-wrong-provider branch 2 times, most recently from f8cbf5d to ea12f35Compare February 23, 2016 09:02

surajssd force-pushed the sane-error-on-wrong-provider branch from ea12f35 to 063a59bCompare March 2, 2016 12:59

Uh oh!

Conversation

surajssd commented Feb 17, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dustymabe commented Feb 17, 2016

Uh oh!

dustymabe commented Feb 17, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rtnpro commented Feb 17, 2016

Uh oh!

rtnpro commented Feb 18, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rtnpro commented Feb 22, 2016

Uh oh!

rtnpro commented Feb 23, 2016

Uh oh!

dustymabe commented Feb 23, 2016

Uh oh!

dustymabe commented Feb 29, 2016

Uh oh!

surajssd commented Mar 1, 2016

Uh oh!

dustymabe commented Mar 1, 2016

Uh oh!

surajssd commented Mar 3, 2016

Uh oh!

dustymabe commented Mar 4, 2016

Uh oh!

cdrage commented Mar 4, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants