Repository navigation
Draft KubernetesProvider implementing the ContainerProvider contract #1153
Description
OpenReconcile has a small draft KubernetesProvider that implements the documented ContainerProvider surface:
start_container(image) -> base_urlwait_for_ready(base_url, timeout_s)stop_container()
Docs still list Kubernetes as planned / a non-instantiable placeholder. We are not proposing Pool/BatchSandbox CRs (OpenSandbox already occupies that). One provider instance starts one Pod + Service, matching how LocalDockerProvider treats one container.
Sketch (not a pin of your internals): https://github.com/openreconcile/community — we can send a PR against src/openenv/core if this shape is still wanted.
Related: #441 (JetBrains orchestrator discussion). Happy to stay out-of-tree if you already have a design.
No affiliation claimed.
Activity
k21993 commentedon Sep 18, 2026
@rohitrsh are you still planning to open the PR for this? I am interested in the same area, so I would rather ask than duplicate your work. Happy to review yours if it is coming, or to pick it up if you would rather not carry it.
A few design points look worth settling before anyone writes code, since they change the shape of the provider:
ModalProviderandACASandboxProviderboth enforce https/wss on the returnedbase_url, and there is no in-cluster exemption today, so plain http between pods needs an explicit decision rather than a silent bypass.LocalDockerProviderowns one container, or a Deployment.runtimeClassNamefor gVisor,imagePullSecrets, and labels that make leaked pods collectable.kubernetesclient as an optional extra alongsidemodal,acaanddaytona, or shelling out to kubectl the wayLocalDockerProvidershells out to docker.@burtenshaw is a Kubernetes provider still wanted in core?
KubernetesProvideris a placeholder inproviders.pythat cannot be instantiated, whilesrc/openenv/core/README.mdand the getting started guide both describe it as planned, so it would help to know whether the intent still stands before someone builds it.burtenshaw commentedon Sep 18, 2026
Thanks for taking this on @k21993 !
Yes. Just a matter of resources. We're not using K8S for training, so we haven't prioritized it.
bypass for incluster http is ok
this
start off with only the functional set, and go from there. it's ok to go heavy on kwargs.
yes. optional.
rohitrsh commentedon Sep 21, 2026
Yes, still opening the PR , thanks @k21993 for checking, and @burtenshaw for the decisions.
Building exactly to what you specified: one Pod + Service per provider instance, in-cluster HTTP, optional
openenv[kubernetes], functional constructor with kwargs for the rest.Anything not specified I'll take from existing providers rather than invent
LocalDockerProviderfor /health readiness and cleanup,ModalProviderfor the lazy SDK import and mocked tests.Will draft against
src/openenv/corethis week or early next week, linked here and to #441. @k21993 happy to have you review.k21993 commentedon Sep 22, 2026
Thanks for confirming. That scope matches the decisions above. Happy to review the draft; please tag me when it is ready. I will pay particular attention to failure cleanup, idempotent shutdown, Kubernetes naming and ownership labels, readiness timeouts, and the in-cluster URL and security behavior.
rohitrsh commentedon Sep 26, 2026
Hey @k21993, Draft is up: #1254 please review when you have a chance. It follows the decisions above.
burtenshaw commentedon Oct 26, 2026
For #1254, which Kubernetes version and live Pod/Service lifecycle smoke test should gate acceptance?
rohitrsh commentedon Oct 26, 2026
Hey @burtenshaw , The gate is the Kind smoke already run on dacf113:
kubernetes client >=29(35.0.0 on that run), one Pod and one Service, in-cluster /health, then stop until both are gone. No pinned cluster version.burtenshaw commentedon Oct 27, 2026
Ok. I think we can close this issue. Feel free to add more examples in a follow up PR?