Fix oncefrom with MachineConfig #483
Conversation
|
@runcom: GitHub didn't allow me to request PR reviews from the following users: ptal. Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/hold holding cause it requires #464 |
openshift-ci-robot
added
do-not-merge/hold
runcom
force-pushed
the
fix-oncefrom
branch
2 times, most recently
from
a7b1490
to
0a9d1cb
Compare
openshift-ci-robot
added
size/XXL
runcom
force-pushed
the
fix-oncefrom
branch
3 times, most recently
from
5f511a5
to
aed3d11
Compare
|
🤔 /retest |
openshift-ci-robot
added
the
needs-rebase
openshift-ci-robot
removed
the
needs-rebase
|
/hold cancel rebased and ready to be reviewed @vrutkovs is testing this out wrt rhel scaleup tests |
openshift-ci-robot
removed
the
do-not-merge/hold
|
origin flakes /retest |
|
/retest |
|
openshift-sdn error (https://paste.fedoraproject.org/paste/U~ffhpHPrpSZvvZUzf3t7g) - reported /retest |
runcom
force-pushed
the
fix-oncefrom
branch
3 times, most recently
from
ea2b4aa
to
66c332c
Compare
|
/retest |
| cb, err := common.NewClientBuilder(startOpts.kubeconfig) | ||
| if err != nil { | ||
| if startOpts.onceFrom != "" { | ||
| glog.Info("Cannot initialize ClientBuilder, likely in onceFrom mode with Ignition") |
There was a problem hiding this comment.
"likely"? We just checked it 😉
Why not just
if startopts.onceFrom == "" {
glog.Fatalf(...)
}
There was a problem hiding this comment.
we haven't checked that we're in onceFrom with ignition, that's why, the log is confusing though, need to reword it
| if cb != nil { | ||
| kubeClient, err = cb.KubeClient(componentName) | ||
| if err != nil { | ||
| glog.Info("Cannot initialize kubeClient, likely in onceFrom mode with Ignition") |
There was a problem hiding this comment.
Confused by this, won't cb == nil if we're in oncefrom?
Signed-off-by: Antonio Murdaca <runcom@linux.com>
|
I rebased this 🏄♂️ |
|
@vrutkovs One thing that would help us...are there use cases for both oncefrom with raw Ignition and from a MachineConfig object pulled from the cluster? Why do we need both? |
In scaleup we only use Ignition, can't think of a case where MachineConfig + --once-from would be used |
|
/retest |
|
/retest |
|
We can address the nits above in followup. /lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ashcrow, cgwalters, runcom The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
- What I did
Builds on top of #464 so we can be sure the node calls are at a minimum required. Looks like onceFrom with a MachineConfig still requires a cluster to be around (not the case for raw ignition).
The patch makes sure a kube and mc clients are around when running in onceFrom with a machineconfig avoiding any panic.
This also incorporates #476 and it's now correctly passing.
/cc @ashcrow ptal
- How to verify it
- Description for the changelog