Cannot create more than two components with OpenShift Online Pro

[dgolovin]

Every new component create 1Gi storage. Pro account has 2Gi storage quota, thus user can create only two components.

Is that possible for components to share the same storage rather than create 1Gi additional storage for every component?

[kadel]

I'm afraid that that won't be possible :-( Component that could modify each data of other components that won't be good.

We could make the size of the PVC configurable to allow creation of the smaller volumes.

[dgolovin]

I would say odo create should use smaller PVC's size by default, if that is possible and let override that with --pvc-size option.
Being limited to two components only for something I pay $50 per month does not feel right to me.

[dgolovin]

--pvc-size would not help here, because in OpenShift Online Pro pvc cannot be less that 1Gi.

[jorgemoralespou]

Online is limited to 1 GB because of the storage backend used. Adding Jake Lucky (@luciddreamz) PM for it so he can potentially help with options.

[luciddreamz]

OpenShift Online uses AWS EBS volumes. They are block storage volumes (read-write once) with a minimum volume size of 1GiB (min volume size dictated by Amazon).

Note: You can buy more storage on OSO Pro ;)

[veillard]

Based on Denis feedback, with Pro you are still 2GB and that means at most 2 volumes, and if each component has a volume that means 2 components, at 50$ per months let's say it's not a good deal if we are stuck with storage for all component in the model of odo

[luciddreamz]

You can add up to 148GiB of additional storage for $1/month per GiB.

[jorgemoralespou]

@luciddreamz the thing is that odo uses a PV for iterative development, and it would not be nice that because how the tool works, we limit what the user can do. We're exploring if in the future we're better of using CRDs which would give us some additional capabilities on the server side, but for now we need to stick to not use CRDs or any server side component.

We would love to promote the tool for developers on Online, but I can envision how customers would complain about the restriction the tool makes on them or that in order to use it and still being able to create 2 PVs in their Online account they would have to raise the bill.

In any case, I understand the limitations that blocks storage provides and we need to think of a solution.

Adding @sspeiche for awareness, as he's PM for odo.

[sspeiche]

I don't know enough why it needs to be a PV and not emptyDir volume. Also, I'm not we need to optimize for Pro.

How long are PVs retained for odo's use case ?

[luciddreamz]

@jorgemoralespou - Note also that creating CRDs require cluster-admin, which OSO end-users aren't going to be able to do. If you're talking about something involving CRDs we create and then are utilized by end-users that might be ok, but there are still some permission-related questions there we need to answer for multi-tenant.

[jorgemoralespou]

@sspeiche mostly because we can not guarantee that a redeployment will land the pod on the same host.

@luciddreamz that's why I said in the future. There's ongoing work to allow per namespace CRDs, which should be able to work in pro, AFAIK. But yes, I was referring about providing the functionality in PRO (ourselves) and then let users create resources defined by the CRD. In any case, that's a conversation to have in the future. For now, we need to understand and document the limitations :-D

[kadel]

I don't know enough why it needs to be a PV and not emptyDir volume. Also, I'm not we need to optimize for Pro.

How long are PVs retained for odo's use case ?

odo needs to store component source code in PV, to persist it over pod restarts.
Otherwise once pod is restarted user will have to push the source code again (using odo push).
The pod gets restarted when env variable or storage is added to the component.

Empty dir (at least on minishift) gets deleted every deployment gets redeployed

[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

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/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.