-
Notifications
You must be signed in to change notification settings - Fork 61
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
Update Devfile Endpoint Validation #1049
Labels
area/api
Enhancement or issue related to the api/devfile specification
area/library
Common devfile library for interacting with devfiles
Comments
openshift-ci
bot
added
the
area/api
Enhancement or issue related to the api/devfile specification
label
Mar 7, 2023
openshift-ci
bot
added
the
area/library
Common devfile library for interacting with devfiles
label
Mar 7, 2023
This was referenced Apr 11, 2023
ehsavoie
added a commit
to ehsavoie/new-registry
that referenced
this issue
Sep 5, 2023
devfile/api#1049 has been fixed Signed-off-by: Emmanuel Hugonnet <ehugonne@redhat.com>
4 tasks
ehsavoie
added a commit
to ehsavoie/new-registry
that referenced
this issue
Sep 5, 2023
devfile/api#1049 has been fixed Signed-off-by: Emmanuel Hugonnet <ehugonne@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/api
Enhancement or issue related to the api/devfile specification
area/library
Common devfile library for interacting with devfiles
Which area/kind this issue is related to?
/area api
/area library
Issue Description
When working on Stone Soup, we discovered that the Devfile validation for endpoints in a devfile.yaml was very strict. For instance, when a Container component and a Kuberntees component are present in a devfile.yaml, they cannot have the endpoint target port.
This restriction is too strict and is hampering the UX on Stone Soup. Innerloop development and Outerloop development are two different phases in the lifecycle of a component/application and it would make sense if they were running on the same target port. They would also not be running on the same pod, so it would make sense they should be able to run on the same target port.
Initially we are going to relax the rules for a Container and Kubernetes/Openshift component but after a period of trial and monitoring, we may probably want to relax the validation rules between 2 Container components as well. At this stage, we should also be considering the Container component property
dedicatedPod
. IfdedicatedPod
is true then it makes perfect sense that the Container components should be able to reuse the same endpoint target port.The text was updated successfully, but these errors were encountered: