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

Only sinceSeconds may be specified as a queryString for LogOptions interface #1673

Open
UltraSive opened this issue May 4, 2024 · 6 comments
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines.

Comments

@UltraSive
Copy link

Description:
The LogOptions interface in the Log class does not allow the sinceTime parameter to be specified. According to the Kubernetes API documentation, either sinceSeconds or sinceTime may be specified, but the current implementation only supports sinceSeconds.

Expected Behavior:
Users should be able to specify sinceTime in addition to sinceSecond in the LogOptions interface.

Current Behavior:
Only sinceSeconds is supported, and attempting to use sinceTime results in an error.

Steps to Reproduce:
Try to use the sinceTime parameter in the LogOptions interface.

Environment:

Kubernetes Client: @kubernetes/client-node
Node.js version: v18.16.0
Proposed Solution:
Allow the sinceTime parameter to be specified in the LogOptions interface, similar to sinceSeconds.

Where to modify:

javascript/src/log.ts

Lines 6 to 45 in b456bfc

export interface LogOptions {
/**
* Follow the log stream of the pod. Defaults to false.
*/
follow?: boolean;
/**
* If set, the number of bytes to read from the server before terminating the log output. This may not display a
* complete final line of logging, and may return slightly more or slightly less than the specified limit.
*/
limitBytes?: number;
/**
* If true, then the output is pretty printed.
*/
pretty?: boolean;
/**
* Return previous terminated container logs. Defaults to false.
*/
previous?: boolean;
/**
* A relative time in seconds before the current time from which to show logs. If this value precedes the time a
* pod was started, only logs since the pod start will be returned. If this value is in the future, no logs will
* be returned. Only one of sinceSeconds or sinceTime may be specified.
*/
sinceSeconds?: number;
/**
* If set, the number of lines from the end of the logs to show. If not specified, logs are shown from the creation
* of the container or sinceSeconds or sinceTime
*/
tailLines?: number;
/**
* If true, add an RFC3339 or RFC3339Nano timestamp at the beginning of every line of log output. Defaults to false.
*/
timestamps?: boolean;
}

@brendandburns
Copy link
Contributor

We'd be happy to take a PR for this.

@brendandburns brendandburns added the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label May 4, 2024
@UltraSive
Copy link
Author

@brendandburns If I simply add the option onto the LogOptions interface the request builder looks like it should take care of it, but in my testing after creating the option it is not added as a query string request or exists as an argument to a method like readNamespacedPodLog(). Am I missing something?

UltraSive@ab16a24

@brendandburns
Copy link
Contributor

@brendandburns
Copy link
Contributor

readNamespacedPodLog doesn't really work right since pod logs are a non-standard API

@VasuDevrani
Copy link

/assign

@VasuDevrani
Copy link

Hey @UltraSive is this whats expected:

  1. In the log method, before constructing the request options, we check if both sinceSeconds and sinceTime are provided in the options object. If both are present, we throw an error indicating that only one of them may be specified.

  2. In the requestOptions object, we include both sinceSeconds and sinceTime properties in the qs (query string) object. If sinceTime is provided, we convert it to string.

cjihrig added a commit to cjihrig/javascript that referenced this issue Sep 27, 2024
This commit adds sinceTime support to LogOptions.

Fixes: kubernetes-client#1673
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines.
Projects
None yet
Development

No branches or pull requests

3 participants