Is there a plan to use a storage backend that would persist code between successive "odo push" executions?

[dharmit]

Which functionality do you think we should add?

While working on #2920, we found that since we use emptyDir as backing storage volume, the k8s Deployment fails to come up after linking.

A bit about linking. Linking (odo link) creates a Service Binding Request (SBR) using the APIs provided by Service Binding Operator (SBO). A SBR creates a k8s Secret and injects this Secret's information into the envFrom field of the run container. It does this by modifying the Deployment's YAML definition.

As a result of this change in Deployment's definition, the underling pod is restarted. Upon restart, the application fails to get reloaded since the code is not stored anywhere.

Why is this needed?

As a result of our inability to store the code on cluster and bring the application back to running state, we need to do odo push after doing odo link for an Operator backed service. OTOH, we didn't have this requirement when linking Service Catalog backed service.

Thus, there's a different UX:

1. Linking service backed by Service Catalog doesn't require user to do odo push. (needs to be verified when working with devfile component.)
2. Linking service backed by an Operator requires user to do odo push.

/kind feature
/kind discussion
/area UX

[dharmit]

@johnmcollier I was told that you did some research on using a persistent backend for components.

@kadel the issue description is largely based on what you explained me when I was stuck while implementing odo link. If there's some mistake on my part in describing our discussion, let me know.

[johnmcollier]

@dharmit Yah, our earlier "kdo" poc used persistent volumes instead of emptyDir volumes for components

[dharmit]

@kadel @johnmcollier out of curiosity, why did we go with emptyDir if there was an implementation using persistent volumes? IIRC, earlier implementation of s2i based components also had persistent volumes.

[johnmcollier]

@dharmit I don't fully remember the reasons why but I believe we had a couple concerns around mandating persistent volumes for all components:

• Concerns around volume attach times on some cloud providers (e.g. on IBM Cloud, volume provision and attach can be over 2 minutes)
• Wanted users be able to run Odo without volumes if desired, especially if dynamic provisioning of volumes isn't available

[johnmcollier]

We discussed this on today's call, we decided on minimally supporting a toggle to enable users to switch between ephemeral emptyDir volumes and PersistentVolumes. We didn't decide on a default however.

#3775

[dharmit]

We didn't decide on a default however.

Since using persistent volumes would help solve more than just odo link, I would request we make persistent volumes default.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[dharmit]

Closing since this was addressed by #4316

/close

[openshift-ci-robot]

@dharmit: Closing this issue.

In response to this:

Closing since this was addressed by #4316

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.