You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2022. It is now read-only.
For a user who is only dealing with Kubernetes and has no clue of OpenShift, how do we facilitate that she does not mix the OpenShift artifacts in between? Right now there is no way to know which config is meant for which cluster. We will only find that out when we are trying to deploy the configs using oc and oc binary is not available.
The text was updated successfully, but these errors were encountered:
Currently, everything is structured in a provider agnostic manner, the same config can take both Kubernetes and OpenShift specific definitions.
Do you see a problem with the current approach where we don't take the provider into account? If the end user is writing OpenShift definitions using Kedge, then we expect them to have the oc binary anyway.
For a user who is only dealing with Kubernetes and has no clue of OpenShift, how do we facilitate that she does not mix the OpenShift artifacts in between?
If the users is dealing with only Kubernetes and doesn't have a clue about OpenShift that he will use just Kubernetes types in his Kedgefile. I don't see any problem there.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For a user who is only dealing with Kubernetes and has no clue of OpenShift, how do we facilitate that she does not mix the OpenShift artifacts in between? Right now there is no way to know which config is meant for which cluster. We will only find that out when we are trying to deploy the configs using
oc
and oc binary is not available.The text was updated successfully, but these errors were encountered: