-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkg/ansible - update status to include failure message on the status. #639
pkg/ansible - update status to include failure message on the status. #639
Conversation
90ee205
to
c470efe
Compare
@@ -21,12 +21,14 @@ import ( | |||
"os" | |||
"time" | |||
|
|||
ansiblestatus "github.com/operator-framework/operator-sdk/pkg/ansible/controller/status" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name is not super great but status seems to be overused.
c470efe
to
9a1acbb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm interested in thinking about how to re-organize the status module to better use namespaces, so we don't end up doing things like:
status := ansiblestatus.NewAnsibleStatusFromStatusJobEvent(...)
I had to type "ansible" twice and "status" an impressive four times. :)
Also, the difference between a Status
and an AnsibleStatus
could be a little confusing, and it certainly contributes to the naming ambiguity. Maybe there's another way. But for the moment I'll need to sleep on it and take a second look tomorrow.
} | ||
|
||
// GetCondition returns the condition with the provided type. | ||
func GetCondition(status Status, condType ConditionType) *Condition { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of making this, plus Set and Remove below, methods on Status?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upstream generally avoids adding methods to the API types, so I think it's generally preferable to use functions. Plus, everything they're messing with is public, so there's not really a reason for it to be a method.
9a1acbb
to
4b842d7
Compare
4b842d7
to
93cae11
Compare
93cae11
to
6d2b845
Compare
logrus.Debugf("status was not found") | ||
u.Object["status"] = map[string]interface{}{} | ||
statusInterface := u.Object["status"] | ||
statusMap, _ := statusInterface.(map[string]interface{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We no longer need to check if Object["status"]
exists or is of type map[string]interface{}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The below func CreateFromMap
will check this and handle the edge cases.
v1.ConditionTrue, | ||
ansibleStatus, | ||
ansiblestatus.SuccessfulReason, | ||
ansiblestatus.SuccessfulMessage, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be useful to record what you did to some degree in the message? Or perhaps you just want that to be in the logs/events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that events would be more useful for this.
Description of the change:
Updates the ansible operator status to align better conventions
Motivation for the change: