-
Notifications
You must be signed in to change notification settings - Fork 74
Update Devfile Endpoint Validation #1049
Copy link
Copy link
Closed
devfile/library
#170Labels
area/apiEnhancement or issue related to the api/devfile specificationEnhancement or issue related to the api/devfile specificationarea/libraryCommon devfile library for interacting with devfilesCommon devfile library for interacting with devfiles
Metadata
Metadata
Assignees
Labels
area/apiEnhancement or issue related to the api/devfile specificationEnhancement or issue related to the api/devfile specificationarea/libraryCommon devfile library for interacting with devfilesCommon devfile library for interacting with devfiles
Type
Fields
Give feedbackNo fields configured for issues without a type.
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. IfdedicatedPodis true then it makes perfect sense that the Container components should be able to reuse the same endpoint target port.