Support persistent volume last phase transition time feature gate field last phase transition time in persistent volume status #2417
Conversation
|
|
…ime-feature-gate-field-lastPhaseTransitionTime-in-PersistentVolumeStatus
| statusMessage := fmt.Sprintf("%v", out.Status.Message) | ||
| if statusMessage == "" { | ||
| log.Printf("[DEBUG] Persistent volume %s status received: %#v", out.Name, statusPhase) | ||
| } else { |
There was a problem hiding this comment.
if message is not None add it to log.
out.Status.Reason is a CamelCase string so does not make sense to display in log
| return out, statusPhase, nil | ||
| }, | ||
| } | ||
| _, err = stateConf.WaitForStateContext(ctx) | ||
| if err != nil { | ||
| return diag.FromErr(err) | ||
| } | ||
| if out.Status.LastPhaseTransitionTime != nil { |
There was a problem hiding this comment.
this was added for create, read and delete
There was a problem hiding this comment.
Looking over this it seems like the use of out.Status.LastPhaseTransitionTime would make sense to have in retry.StateChangeConf since that's where the Phase is being updated. What was the reason to include this outside of retry?
There was a problem hiding this comment.
I put it here because I thought it will report the transition time between pending and available/bound.
During my test I have difficulty of trick pv into pending status (so the retry never happened), so my test is not comprehensive. I will dig a bit more and get back with an updated PR!
There was a problem hiding this comment.
Having a cluster with only 1 node makes it difficult to have that Pending status show up. I was able to get it to show by setting up a 3 node cluster using minikube by running minikube start --nodes 3 multinode-cluster
There was a problem hiding this comment.
Hi @BBBmau ,
I've been caught up with personal commitments lately. Appreciate your recommendation on minikube; it worked wonders! Here are the logs I managed to generate:
2024-03-07T18:37:59.947+1100 [DEBUG] provider.terraform-provider-kubernetes: 2024/03/07 18:37:59 [DEBUG] Persistent volume example-pv status received: "Pending"
2024-03-07T18:37:59.947+1100 [DEBUG] provider.terraform-provider-kubernetes: 2024/03/07 18:37:59 [DEBUG] Persistent volume last phrase transition time: 2024-03-07 18:37:59 +1100 AEDT
...
2024-03-07T18:57:04.439+1100 [DEBUG] provider.terraform-provider-kubernetes: 2024/03/07 18:57:04 [DEBUG] Persistent volume example-pv status received: "Available"
2024-03-07T18:57:04.439+1100 [DEBUG] provider.terraform-provider-kubernetes: 2024/03/07 18:57:04 [DEBUG] Persistent volume last phrase transition time: 2024-03-07 18:57:04 +1100 AEDT
I foresee a potential issue where if the refresh code block triggers the sequence PENDING->PENDING->PENDING->AVAILABLE, it might record the same last phrase transition time thrice during the PENDING state. Could this pose a problem? Otherwise, I hope the PR is working as expected 😃
…ime-feature-gate-field-lastPhaseTransitionTime-in-PersistentVolumeStatus
…ime-feature-gate-field-lastPhaseTransitionTime-in-PersistentVolumeStatus
|
Hi @BBBmau I have updated the PR, please take a look 😊 |
…ime-feature-gate-field-lastPhaseTransitionTime-in-PersistentVolumeStatus
Description
resolve #2399
Acceptance tests
Output from acceptance testing:
Release Note
Release note for CHANGELOG:
References
Community Note