epinio: Cannot update source from a failed app

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Attempting to update a source from a failed app is not possible

Expected Behavior

It should be possible to source a failed up and have it into a running state

Steps To Reproduce

  1. Install latest epinio-dev commit (Currently: 23d440198092d8ac60089a7d176e041f2b9b68dd (HEAD -> epinio-dev, origin/epinio-dev) )
  2. Deploy a faulty app (ie folder with images)
  3. Try to update to a valid app (ie: source type = file with sample-app.tar.gz)

Observe error: image

Environment

- OS: Linux
- Architecture:amd64
- Epinio Version: v1.8.0-20-g912b8964
- Cluster:
  - Provider: k3d
  - Options:1 node
  - Kubernetes Version: v1.25.4+k3s1

Logs

No response

Anything else?

No response

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 26 (22 by maintainers)

Most upvoted comments

@enrichman, I summarize here the reproduction steps for cli error and the later working part

  • Unzip this faulty-dir: faulty-dir.zip
  • Create app with faulty dir (it will fail at fail: paketo-buildpacks/procfile@5.6.3):
epinio push -n testapp-faulty -p ~/faulty-dir
  • Push the correct folder but with -i 1:
epinio push -n testapp-faulty -p assets/sample-app -i 1
  • Observe error:
❌  error pushing app to server: Internal Server Error: Error parsing reference: "" is not a valid repository/tag
  • Push now without -i 1
epinio push -n testapp-faulty -p assets/sample-app

Now it is ok:

✔️  App is online.
Name: testapp-faulty
Namespace: workspace
Builder Image: 
Routes: 
1: https://testapp-faulty.172.19.0.3.omg.howdoi.website

If this does turn out to be more UI related it might be worth pausing until both https://github.com/rancher/dashboard/pull/8797 and https://github.com/rancher/dashboard/pull/8672 are merged. The first in particular reworks a lot.

@torchiaf @richard-cox

Regarding this issue we need to change the behavior of the update endpoint, and the client will need to handle it with a separate API call. This will break a couple of things that will need to be updated.

We are going to postpone this for the 1.10.0 since it’s not critical, or maybe we can think about a 1.9.1 with just some fixes.

Oh! Create and get an error back when it exists. Ok, then the flow as shown makes sense.

https://github.com/epinio/epinio/issues/2363#issuecomment-1576842871

Does this happen when changing the instance count when just using an app created by the CLI, or does the app need to come from the UI (and also updated by UI)?

@richard-cox, it does not necessarily need to come from UI; it happens when cli updates from the faulty app with the instance count. Having said this the UI shows the error described initially (unable to update if app is faulty). Let’s check if the UI remains affected after the BE team takes a look.

Note: I made sure this only occurs when the app was in previous faulty state. If you deploy a healthy app with -i 1 it works.

Ah, ok. I didn’t understood that this was happening also with the CLI.

There is probably something weird with the parameters validation. @mmartin24 let’s move this on the BE then. Thank you all.

Thanks @torchiaf for the comment. I checked it and I could reproduce what you pointed out in cli. I asked in slack if we could move the item to BE, but the UI flow seemed unclear.

@enrichman the flow in the UI was basically this:

An error appears while doing this

I am not sure if this clarifies the question about the flow followed