-
Notifications
You must be signed in to change notification settings - Fork 66
Clarification on container mountSources
behavior when "projects" volume is defined in devfile
#290
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
Labels
lifecycle/rotten
Rotten items. These items have been stale for 60 days and are now closed.
lifecycle/stale
Stale items. These items have not been updated for 90 days.
Comments
cc: @l0rd @davidfestal your input here is appreciated. I'm leaning towards option 2. |
amisevsk
added a commit
to amisevsk/devworkspace-operator
that referenced
this issue
Jan 15, 2021
This avoids an issue where a container can mount the projects volume directly and have `mountSources: true`, which results in a duplicate mount and invalid deployment. Related to issue devfile/api#290 and how projects volume should be handled with `mountSources`. Signed-off-by: Angel Misevski <[email protected]>
amisevsk
added a commit
to amisevsk/devworkspace-operator
that referenced
this issue
Jan 20, 2021
This avoids an issue where a container can mount the projects volume directly and have `mountSources: true`, which results in a duplicate mount and invalid deployment. Related to issue devfile/api#290 and how projects volume should be handled with `mountSources`. Signed-off-by: Angel Misevski <[email protected]>
amisevsk
added a commit
to devfile/devworkspace-operator
that referenced
this issue
Jan 21, 2021
This avoids an issue where a container can mount the projects volume directly and have `mountSources: true`, which results in a duplicate mount and invalid deployment. Related to issue devfile/api#290 and how projects volume should be handled with `mountSources`. Signed-off-by: Angel Misevski <[email protected]>
amisevsk
added a commit
to amisevsk/devworkspace-operator
that referenced
this issue
Jan 27, 2021
This avoids an issue where a container can mount the projects volume directly and have `mountSources: true`, which results in a duplicate mount and invalid deployment. Related to issue devfile/api#290 and how projects volume should be handled with `mountSources`. Signed-off-by: Angel Misevski <[email protected]>
This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
lifecycle/rotten
Rotten items. These items have been stale for 60 days and are now closed.
lifecycle/stale
Stale items. These items have not been updated for 90 days.
Uh oh!
There was an error while loading. Please reload this page.
Description
Currently, container components can set the field
mountSources: true
to enable mounting of project sources inside the pod and defaults totrue
for most user defined sources. Typically this would be done by generating a k8s volumeMount and k8s volume for the container that is mounting sources. However, as volumes can be defined as components, how k8s volumes are generated is unclear -- what behavior is expected if a devfile has a "projects" component already defined?Note: I'm assuming that an explicit "projects" volume component isn't required in devfiles, since
mountSources
is by defaulttrue
for many containers. Generating the required k8s volume is a sensible default since otherwise devfiles require a bit of arbitrary boilerplate.Potential solutions
1. Implicit "projects" volume component, can be overridden in devfile
We assume there is a volume component named
projects
with a default configuration in every devfile, available in casemountSources
istrue
for any component. The devfile writer can define an explicit "projects" volume to override default behavior. However, if this approach is taken, it's unclear how to handle devfiles that contain a non-volume component named "projects" -- is this an error or should we assume the devfile does not override the default projects volume?Required updates to devfile API in this case
mountSources
2. Unique "projects" volume component that cannot be overridden
We generate a unique volume (e.g. keyed to workspace UID) that stores project sources, avoiding any potential name collisions. Users can define a "projects" volume and mount it manually for other use. However, this approach leaves to clear path for e.g. increasing the storage allocated for projects.
Required updates to devfile API in this case
Additional info
The API documentation for
mountSources
:Related: #291
The text was updated successfully, but these errors were encountered: