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

feat(operator): add custom printcolumns for seldon-specific CRs #5736

Merged
merged 3 commits into from
Jul 5, 2024

Conversation

lc525
Copy link
Member

@lc525 lc525 commented Jul 2, 2024

Additional printcolumns for CRs covered in this change:

  • Models: ModelReady, Replicas, Age
    CR-printfields-models

  • Pipelines: Ready, ModelsReady*, PipelineReady*, Message, Age
    CR-printfields-pipelines

  • Servers: Ready, Replicas, Loaded Models, Age
    CR-printfields-servers

  • Experiments: ExperimentReady, CandidatesReady*, MirrorReady*, Message, Age
    CR-printfields-experiments

The additional columns show up when getting the list of objects of a given type via kubectl get, and subsequently also show up in k9s.

Printcolumns marked with * above only show up when running kubectl get ... -o wide

Which issue(s) this PR fixes:
Fixes #INFRA-1058 (internal): Print additional fields for seldon-specific CRDs

Special notes for your reviewer:
PR contains automatically-generated files, will mark those with a comment

Additional printcolumns for CRs covered in this change:
 - Models: ModelReady, Replicas, Age
 - Pipelines: Ready, ModelsReady, PipelineReady, Message, Age
 - Servers: Ready, Replicas, Loaded Models, Age
 - Experiments: ExperimentReady, CandidatesReady, MirrorReady, Message, Age
@lc525 lc525 added the v2 label Jul 2, 2024
@lc525 lc525 requested a review from sakoush as a code owner July 2, 2024 09:49
Copy link
Member Author

Choose a reason for hiding this comment

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

generated

Copy link
Member Author

Choose a reason for hiding this comment

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

generated

Copy link
Member Author

Choose a reason for hiding this comment

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

generated

Copy link
Member Author

Choose a reason for hiding this comment

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

generated

Copy link
Member Author

Choose a reason for hiding this comment

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

generated

Copy link
Member Author

Choose a reason for hiding this comment

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

generated

Copy link
Member

@sakoush sakoush left a comment

Choose a reason for hiding this comment

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

LGTM! I left a comment on whether it is possible to add any testing, guardrails in the cases of a change in the current fields that are used.

@@ -54,6 +54,11 @@ type ExperimentStatus struct {
//+kubebuilder:object:root=true
//+kubebuilder:subresource:status
//+kubebuilder:resource:shortName=mlx
//+kubebuilder:printcolumn:name="Experiment ready",type=string,JSONPath=`.status.conditions[?(@.type=='ExperimentReady')].status`,description="Experiment ready status"
Copy link
Member

Choose a reason for hiding this comment

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

how can we maintain these settings, eg. if we change some of these conditions that we are returning?

Copy link
Member Author

Choose a reason for hiding this comment

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

They are quite difficult to directly test, mostly because this is an added comment used by kubebuilder when generating the CRDs (yaml files), rather than executable code. The failure mode here is quite lenient though, with any printcolumn referencing nonexistent data showing as empty.

Thinking outside the box a bit, we could imagine a test using the exact same fields as the kubebuilder comments, which will start failing when we change any of the status conditions. The failing test should contain a message explaining that one needs to change the comments here, and only update the test itself afterwards.

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 have accepted the challenge :-) and added tests. I might have exaggerated a bit, actually.

Copy link
Member

Choose a reason for hiding this comment

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

thanks for finding a way to test it.

lc525 added 2 commits July 4, 2024 12:01
Those tests fail if we modify the CRDs in a way which changes the names
of the fields printed in kubebuilder:printcolumn
@lc525 lc525 requested a review from sakoush July 4, 2024 11:09
Copy link
Member

@sakoush sakoush left a comment

Choose a reason for hiding this comment

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

LGTM. thanks for adding the tests.

@lc525 lc525 merged commit 99f1e40 into SeldonIO:v2 Jul 5, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants