epinio: Access Key doesn't exist after updating via helm chart

Describe the bug When pushing the 12factor app, I get 500 error presented:


Uploading application code ...
error pushing app to server: can't upload archive: server status code: Internal Server Error
{"errors":[{"status":500,"title":"ensuring bucket: The Access Key Id you provided does not exist in our records.","details":"uploading the application sources blob\nServer Backtrace: The Access Key Id you provided does not exist in our records.\nensuring bucket\ngithub.com/epinio/epinio/internal/s3manager.(*Manager).Upload\n\t/go/src/github.com/epinio/internal/s3manager/s3manager.go:176\ngithub.com/epinio/epinio/internal/api/v1/application.Controller.Upload\n\t/go/src/github.com/epinio/internal/api/v1/application/upload.go:73\ngithub.com/epinio/epinio/internal/api/v1.errorHandler.func1\n\t/go/src/github.com/epinio/internal/api/v1/router.go:36\ngithub.com/gin-gonic/gin.(*Context).Next\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\ngithub.com/gin-gonic/gin.LoggerWithConfig.func1\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/logger.go:241\ngithub.com/gin-gonic/gin.(*Context).Next\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\ngithub.com/gin-contrib/sessions.Sessions.func1\n\t/go/pkg/mod/github.com/gin-contrib/sessions@v0.0.4/sessions.go:54\ngithub.com/gin-gonic/gin.(*Context).Next\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\ngithub.com/gin-gonic/gin.CustomRecoveryWithWriter.func1\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/recovery.go:99\ngithub.com/gin-gonic/gin.(*Context).Next\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\ngithub.com/gin-gonic/gin.(*Engine).handleHTTPRequest\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:489\ngithub.com/gin-gonic/gin.(*Engine).ServeHTTP\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:445\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2879\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1930\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1581"}]}

To Reproduce Steps to reproduce the behavior, e.g.:

  1. Install epinio-installer chart (skip traefik, skip linkerd, set domain)
  2. Upgrade epinio-installer chart (changing CORS setting) – I might have done this too fast and created a race condition?
  3. Run epinio config update
  4. Push sample application
  5. Fails fast

Expected behavior A clear and concise description of what you expected to happen.

Logs Log shown above. Will put into debug and edit to include if additional details are shown.

Cluster (please complete the following information):

  • Provider: k3s
  • Options: 1 master 4 worker
  • Kubernetes Version: 1.21.2

Desktop/CLI (please complete the following information):

  • OS: linux
  • Epinio Version: 3.0
  • Epinio Install Options: helm-install
containerRegistryChart: >-
  https://github.com/epinio/epinio-helm-chart/releases/download/container-registry-0.1.0/container-registry-0.1.0.tgz
domain: ***
email: epinio@suse.com
epinioChart: >-
  https://github.com/epinio/epinio-helm-chart/releases/download/epinio-0.2.0/epinio-0.2.0.tgz
tlsIssuer: epinio-ca
traceLevel: '2'
traefikChart: https://helm.traefik.io/traefik/traefik-10.3.4.tgz
accessControlAllowOrigin: https://rancher.gracey.home
password: ***
skipLinkerd: true
skipTraefik: true
useExternalRegistry: false
useS3Storage: false
user: ***

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 23 (23 by maintainers)

Most upvoted comments

One can use lookup to get the old keys from the secret in the cluster: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function