remove persistent volume from pre-migration-job

Question

remove persistent volume from pre-migration-job

tobiasgiese opened this issue 4 years ago · comments

Bug Report

What happened:

We noticed, that the pre-migration-job uses a persistent volume for the migration.
As not all Kubernetes customers have persistent volumes available, the migration could fail.
It should be possible to change this behavior from 2 jobs to only 1 job with an initContainer and an emptyDir.

What you expected to happen:

Migration should not fail because of completely used storage quota (i.e. cinder).

How to reproduce it (as minimally and precisely as possible):

Run the migration jobs.

Anything else we need to know?:

Environment:

Kubernetes version (use kubectl version): v1.18.6
service-catalog version: catalog-0.3.0
Cloud provider or hardware configuration: OpenStack
Do you have api aggregation enabled? yes
- Do you see the configmap in kube-system? yes
- Does it have all the necessary fields? yes
  - kubectl get cm -n kube-system extension-apiserver-authentication -o yaml and look for requestheader-XXX fields

Install tools:

Did you use helm? What were the helm arguments? Did you --set any extra values?

helm upgrade dhc "files/service-catalog/chart" \
        --namespace caas-system \
        --kubeconfig kubeconfig \
        --values "catalog-values.yaml" \
        --post-renderer "files/service-catalog/kustomize.sh" \
        -v 5 \
        --wait \
        --timeout 30m

Are you trying to use ALPHA features? Did you enable them? no

^{Tobias Giese , Daimler TSS GmbH,
Imprint}

fejta-bot · Answer 1 · Tue Dec 01 2020 22:11:21 GMT+0800 (China Standard Time)

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Tobias Giese · Answer 2 · Mon Dec 14 2020 15:55:02 GMT+0800 (China Standard Time)

We have removed the migration-job from our deployment, as the job is only for the update from 0.2.x to 0.3.x (see design proposal).
Will the migration-job be removed from the repo (i.e. helm chart) in the future?
Or is it possible, that the migration-job will be reused for feature migrations?

fejta-bot · Answer 3 · Wed Jan 13 2021 16:54:49 GMT+0800 (China Standard Time)

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

Konstantin Semenov · Answer 4 · Wed Jan 13 2021 17:52:27 GMT+0800 (China Standard Time)

/remove-lifecycle rotten

Tobias Giese · Answer 5 · Thu Mar 04 2021 16:25:16 GMT+0800 (China Standard Time)

closed by accident

fejta-bot · Answer 6 · Wed Jun 02 2021 17:00:28 GMT+0800 (China Standard Time)

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

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

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

fejta-bot · Answer 7 · Fri Jul 02 2021 17:41:13 GMT+0800 (China Standard Time)

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

Tobias Giese · Answer 8 · Mon Jul 19 2021 17:15:27 GMT+0800 (China Standard Time)

/remove-lifecycle rotten

Kubernetes Triage Robot · Answer 9 · Sun Oct 17 2021 17:18:43 GMT+0800 (China Standard Time)

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

Kubernetes Triage Robot · Answer 10 · Tue Nov 16 2021 17:52:32 GMT+0800 (China Standard Time)

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten