Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fix network plugin detection #1061
Fix network plugin detection #1061
Changes from 7 commits
4295ae9
863f37d
62ba069
62c8624
0dea170
317aaf6
ed9aa37
597bff5
c62e1e5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 is
WATCH_NAMESPACE
and how is it set?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 is set here as an environment variable of the operator pod. I think that this is used by operator-sdk's
GetWatchNamespace
.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.
OK - could you add a comment explaining this? eg "WATCH_NAMESPACE will be present if running in the operator pod".
Another approach is to pass in the NS so we don't rely on the presence of an env var. The operator code implicitly knows its own namespace. I think this would make it clearer and although it would mean passing a param down the chain.
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.
Changed and squashed.
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 prefer this the way you had it, ie not return error here or on L128. This makes it consistent with the other discovery methods and, on join, will result in the user being prompted. But, as I noted earlier, I think it's worth logging a message as the API server didn't behave as expected.
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 callers of
discoverGenericNetwork
are as follows:So, as for command line case, the error is already been passed to
status.QueueWarningMessage
.And, other functions called from
discoverGenericNetwork
, likefindClusterIPRangeFromApiserver
actually returns error and not catching it withstatus.QueueWarningMessage
.Therefore, the code should be already as you expected.
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.
My point was about whether it should return an error in this case, ie should we treat it like we didn't find the data similar to the other discovery methods. So for
subclt join
, this would at least allow it to prompt the user as a last resort. After all, this is just another attempt to find the data. This seems reasonable but it would be beneficial to print a warning. @mangelajo WDYT?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.
Waiting for @mangelajo 's comment. But I'm now inclined to return nil and log error here, only for this case.
Meanwhile, I would like to confirm that it is safe to call
status.QueueWarningMessage
outside CLI's context, or from operator. It looks like a package underpkg/internal/cli
and I'm not familiar with its implementation details.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.
Unfortunately
status.QueueWarningMessage
wouldn't be appropriate in the operator. The operator uses a different logging API. We could pass in a function to log warnings.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.
Added logging code in
controllers/submariner/submariner_networkdiscovery.go
for operator to log it (See the first commit). Also, re-organized and squashed commits to review easier.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 don't return an error above if no error was returned from service creation so we should be consistent here. I think that's the correct behavior as it means we didn't find the desired data. As above I think we should log a message:
status.QueueWarningMessage(fmt.Sprintf"Could not determine the service IP range via service creation - the expected error was not returned. The actual error was %q", msg))