On startup automatically execute actions with initContainers components about api HOT 13 OPEN

cc @johnmcollier @elsony

from api.

This feature seems to be very valuable in both the devfile and the devworkspace API (which can live under the form of a Kubernetes CR) cases.
And to allow it to be usable in as many use-cases / contexts as possible, I think we should allow abstracting the source of these mappings, so that we do not depend on paths where the file is stored (either on disk or on the network).
Using paths in the case the devfile is stored at a given URI is perfectly fine, as long as it would not be the only way to use this feature.

from api.

can we change permissions of files/directories or use another entrypoint script as well ?

from api.

@davidfestal and @l0rd to provide a new alternative that use the initcontainer approach used for the che plugins.

from api.

Tangentially related question, but is not in context of the feature discussed above:

If I used a query param to pass a dev file to CRW/che like so:
https://<your-che-host>/f?url=https://pastebin.com/raw/ux6iCGaW

If che didn’t have an access token for a private git repo in the devfile already, what would happen? Would it be prompted to authenticate? Obviously we wouldn’t even get to this mapping/path/initialization.

from api.

Review and agreed on the alternative syntax specified in the description.

A couple of comments related to this issue and we will need to discuss on separate issues are:

• Init container that mount projects sources (from git, local, zip) before any other component starts
• Specify components that run in distinct pods or main pod => won't be possible to share volumes

from api.

Tangentially related question, but is not in context of the feature discussed above:

If I used a query param to pass a dev file to CRW/che like so:
https://<your-che-host>/f?url=https://pastebin.com/raw/ux6iCGaW

If che didn’t have an access token for a private git repo in the devfile already, what would happen? Would it be prompted to authenticate? Obviously we wouldn’t even get to this mapping/path/initialization.

@triceam as mentioned on slack git access tokens (and user credentials in general) should not be part of the devfile specification because they are not part of a workspace definition but related to a given user. In other words, how users are prompted for username/password/tokens is an implementation choice of the application that processes the devfile (i.e. che or odo).

from api.

This issue may be affected by #32 that is under review: if we agree that events are better we should probably not support initiContainers anymore.

from api.

One might still find use for the init containers if a tool required for the initialization is not present in the target image of the tooling. For example if you wanted to download something using curl, yet the compiler/build tool image you'd like to use lacked curl in its image.

from api.

What is the status of this issue? initContainer doesn't appear in the schema so has #32 superseded this issue?

from api.

What is the status of this issue? initContainer doesn't appear in the schema so has #32 superseded this issue?

@metacosm correct, I am keeping this open because initContainer can still be interesting in future releases of the spec but it won't be part of 2.0.

from api.

Moving to refinement to revisit and see if this is still needed.

from api.

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.

from api.