Skip to content

Deploy ToolHive Operator into OpenShift (#1063) #1253

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

RoddieKieley
Copy link

* Update helm chart resources and seccompProfile type values for OKD environment.
* Update MCPServer Deployment with check for XDG_CONFIG_HOME and HOME env vars being set.
* Add OpenShift environment detection by way of route v1 API availability or OPENSHIFT_OPERATOR env var override.

    * Update helm chart resources and seccompProfile type values for OKD environment.
    * Update MCPServer Deployment with check for XDG_CONFIG_HOME and HOME env vars being set.
    * Add OpenShift environment detection by way of route v1 API availability or OPENSHIFT_OPERATOR env var override.

Signed-off-by: Roddie Kieley <rkieley@redhat.com>
@RoddieKieley
Copy link
Author

When running go-task operator-test I observed the following problem first:

"shell": executable file not found in $PATH

As well as a number of test failures that didn't seem all associated with the changes in this PR. I passed the terminal output through cursor -> o3 with a request to write the content out to markdown which I'm attaching:
1063-cursor-o3-feedback.md

I utilized the 'Option B' Fix for the "shell" issue above and that worked locally for me on Fedora 42. Not sure how other environment friendly that is however so not including it in the PR itself.

Either way feedback welcome and would be curious if you've had any luck with OKD @jhrozek ?

@ChrisJBurns
Copy link
Collaborator

For awareness, I will be deploying OpenShift into our environment next week for @jhrozek to play around with ToolHive installations

@dmartinol
Copy link

Hey @ChrisJBurns could you also suggest a default strategy for the XDG_CONFIG_HOME env vars? ATM we're hardcoding /tmp which is probably not ideal, WDYT?

Copy link
Contributor

@jhrozek jhrozek left a comment

Choose a reason for hiding this comment

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

Thank you for the patch @RoddieKieley ! We'll work with @ChrisJBurns on setting up the OKD cluster so we can test properly.

defaultRetryInterval = 3 * time.Second
)

var isOpenShift *bool = nil
Copy link
Contributor

Choose a reason for hiding this comment

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

(Not needed to include the PR, we can iterate on the patches in subsequent PRs as well)
I wonder if using sync.Once would be cleaner than using a global variable?

break
}

time.Sleep(defaultRetryInterval)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we consider using ExponentialBackoff from k8s.io/apimachinery/pkg/util/wait?
(Again, can be done later)

podTemplateSpec = ensurePodTemplateConfig(podTemplateSpec, containerLabels)
isOpenShift := false
// Get a config to talk to the apiserver
cfg, err := clientconfig.GetConfig()
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we should use rest.InClusterConfig here?

func ensureRequiredEnvVars(env []corev1.EnvVar) []corev1.EnvVar {
// Check for the existence of the XDG_CONFIG_HOME and HOME environment variables
// and set them to /tmp if they don't exist
xdgConfigHomeFound := false
Copy link
Contributor

Choose a reason for hiding this comment

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

@ChrisJBurns do we have a ticket to ensure the proxy runner doesn't write any files? I think in general the proxy runner should be able to run with read-only filesystem

@jhrozek
Copy link
Contributor

jhrozek commented Aug 4, 2025

@RoddieKieley good news! Thanks to @ChrisJBurns we have an OKD cluster now 🚀

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.

4 participants