Skip to content
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: exception when retrieving logs from helm resource #1086

Merged
merged 1 commit into from
Aug 13, 2019

Conversation

10ko
Copy link
Member

@10ko 10ko commented Aug 8, 2019

What this PR does / why we need it:
Whenever we retrieve logs with garden logs we assume the resource has a selector. This is not always true when we deal with Helm charts. This PR introduce a new function to determine a selector in case of an Helm chart.

Please @edvald or @eysi09, do a sanity check to see if it makes sense. I did some tests with stable/mysql and some other charts and it "looks" like it's working but yeah, maybe you have some specific scenarios/charts in mind.

Which issue(s) this PR fixes:

Fixes #1068

Special notes for your reviewer:

Does this PR introduce a user-facing change?:
Well, it fixes an exception.

@10ko 10ko requested review from edvald and eysi09 August 8, 2019 10:19
@10ko 10ko force-pushed the fix-unhandled-exception-viewing-logs branch from 641c18c to f6ef5dc Compare August 8, 2019 11:05
* NOTE: selector: {} matches all the pods for the resource, when using the k8s APIs.
*/
export function getSelectorFromResource(resource: KubernetesWorkload) {
let selector = {}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess my only concern would be the case where the function returns {}. Wondering if no pods are a better default than all the pods. Might also be useful to add a log.debug statement for that case, regardless of how we handle it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On point. I am open to both tbh. I am not extremely familiar with selectors and I don't know what's the "expected" default.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the function to return undefined instead.
Thanks @eysi09

@10ko 10ko force-pushed the fix-unhandled-exception-viewing-logs branch from f6ef5dc to e00693d Compare August 8, 2019 12:59
Copy link
Collaborator

@eysi09 eysi09 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

* NOTE: { selector: undefined } matches no pods for the resource, when using the k8s APIs.
*/
export function getSelectorFromResource(resource: KubernetesWorkload) {
const logger = getLogger()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a good idea, we should pass a LogEntry instance to the function.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am going to remove this since we'll throw further down.
I am wondering why this is a bad idea thou?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because this completely ignores any nesting and structure in the logs. With garden dev, for example, this would print the log line at the bottom of the terminal and not next to the relevant task log.

}
// No selector found, return.
logger.debug(`No selector found for ${resource.metadata.name}: returning empty selector.`)
return
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, if we return undefined here, how does that play with the getPods? Shouldn't we rather just throw? We don't want to get all of the Pods from a namespace if we're missing a selector.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it looks like the k8s javascript library has a class V1LabelSelector which is used in various resources and matches everything if it's empty but nothing if it's undefined.
The function listNamespacedPod(...) called by getPods(...) has a parameter called labelSelector which is, of course, not of type V1LabelSelector and defaults to "all the pods".

I thought the getPods would follow the same behaviour, hence my decision of either returning empty object or undefined.

I'd also rather throw.

@10ko 10ko force-pushed the fix-unhandled-exception-viewing-logs branch from b7da6ff to 1faa48d Compare August 9, 2019 08:42
@eysi09
Copy link
Collaborator

eysi09 commented Aug 12, 2019

@edvald, is this one ready?

@eysi09 eysi09 added this to the 0.10.5 milestone Aug 12, 2019
app: resource.metadata.labels.app,
}
}
}
Copy link
Collaborator

@edvald edvald Aug 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, could have thought of this earlier, but... Wouldn't it make sense to just use the exact labels from the Pod template (spec.template.metadata.labels)? And maybe leave the last Helm-specific clause as a 3rd fallback? Because if the Pod spec explicitly specifies labels, those will work fine as a selector.

@10ko 10ko force-pushed the fix-unhandled-exception-viewing-logs branch from 1faa48d to 5e65447 Compare August 13, 2019 15:08
return resource.spec.selector.matchLabels
}
// We check if the pod template has labels
if (resource.spec.template.metadata.labels) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may error if one of the variables doesn't exist. Actually the same applies above as well, even though it's less likely to occur IRL.

@10ko 10ko force-pushed the fix-unhandled-exception-viewing-logs branch from 5e65447 to 5aa4e95 Compare August 13, 2019 15:32
@10ko
Copy link
Member Author

10ko commented Aug 13, 2019

Really looking forward to this.

@eysi09 eysi09 merged commit b4e7538 into master Aug 13, 2019
@eysi09 eysi09 deleted the fix-unhandled-exception-viewing-logs branch August 13, 2019 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unhandled exception viewing logs
3 participants