-
Notifications
You must be signed in to change notification settings - Fork 103
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
Simplify waiting for the instance to be done #1636
Conversation
Summary: previous logic relied on figuring out the plan in progress and the plan status from the instance status. However, since 1.15 this can be simplified by using the `Spec.PlanExecution` which already has the relevant information. Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
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.
Still have couple of questions before I am ready to approve :)
pkg/kudoctl/cmd/plan/plan_status.go
Outdated
@@ -120,7 +120,7 @@ func status(kc *kudo.Client, options *Options, ns string) error { | |||
} else { | |||
break | |||
} | |||
done, err := kc.IsInstanceDone(instance, nil) | |||
done, err := kc.IsInstanceDone(instance, instance.Spec.PlanExecution.PlanName) |
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.
why are you passing in instance as well as field on that instance? 🤔 should we just pass in an instance?
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.
Good eye ;) basically, because I don't know how this method will be used:
- the passed instance has to be the one returned by
Create/Update/Patch
method because it has thePlanExecution.PlanName
field set to the right plan - if you simply fetch the instance later, the plan might be already done (which is not a big deal), or there might be already another plan (from a later update) in progress
Passing a plan explicitly was an attempt to make the usage of this method slightly safer.
@@ -73,12 +73,13 @@ func Package( | |||
return nil | |||
} | |||
|
|||
if err := install.Instance(client, resources.Instance); err != nil { | |||
installed, err := install.Instance(client, resources.Instance) |
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.
hmm why is this better than what was here before? 🤔
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 ok with this, tbh, it enforces the "always use the returned object if you create one" pattern... It allows you to update the object later one:
pod := corev1.Pod{ ... }
pod := client.Create(pod)
pod.metadata.Labels["something"] = "addedlabel"
pod := client.Update(pod)
This won't work if you try to do:
pod := corev1.Pod{ ... }
client.Create(pod)
pod.metadata.Labels["something"] = "addedlabel"
client.Update(pod)
because of the added fields from the api-server...
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.
see my comment above
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.
Looks generally good, needs a bit of cleanup though
pkg/kudoctl/util/kudo/kudo.go
Outdated
status := lastPlanStatus.Status | ||
if status.IsFinished() { | ||
clog.V(2).Printf("plan status for %q is finished\n", instance.Name) | ||
func (c *Client) IsInstanceDone(instance *v1beta1.Instance, plan string) (bool, error) { |
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 think this func should move to the "instance_helpers.go" and have the instance as the receiver. I'm not sure why it's part of the kudo.Client
..
And then it should probably be something like
func (i *v1beta1.Instance) IsPlanDone(plan string) (bool, error) {
Maybe with an additional
func ( i *v1beta1.Instance) IsCurrentPlanDone() (bool, error) {
@@ -73,12 +73,13 @@ func Package( | |||
return nil | |||
} | |||
|
|||
if err := install.Instance(client, resources.Instance); err != nil { | |||
installed, err := install.Instance(client, resources.Instance) |
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 ok with this, tbh, it enforces the "always use the returned object if you create one" pattern... It allows you to update the object later one:
pod := corev1.Pod{ ... }
pod := client.Create(pod)
pod.metadata.Labels["something"] = "addedlabel"
pod := client.Update(pod)
This won't work if you try to do:
pod := corev1.Pod{ ... }
client.Create(pod)
pod.metadata.Labels["something"] = "addedlabel"
client.Update(pod)
because of the added fields from the api-server...
pkg/kudoctl/util/kudo/kudo.go
Outdated
// IsInstanceDone provides a check on instance to see if it is "finished" without retries | ||
// oldInstance is nil if there is no previous instance |
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 comment should probably be adjusted. I have no idea what "finished" means in the context here... Also, oldInstance isn't a parameter anymore
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.
TBH I'm not a big fan of using spec
for holding status information, and still hope this can be changed at some point. This change seems to move us further away from that...
The introduced logic relies on |
Well, if it was purely intent, then we would not be able to determine state from it, but yet we do :-) |
…o instance Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>
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.
lgtm 🚢
We discussed this offline with @ANeumann82 a while ago and I don't remember the exact reasoning but we were both not happy with this PR. Something about handling the "edginess" of waiting for a plan to be over. |
Summary:
previous logic relied on figuring out the plan in progress and the plan status from the instance status. However, since 1.15 this can be simplified by using the
Spec.PlanExecution
which already has the relevant information.Signed-off-by: Aleksey Dukhovniy alex.dukhovniy@googlemail.com