vscode-openshift-tools icon indicating copy to clipboard operation
vscode-openshift-tools copied to clipboard

Status of a component becomes "pushed" before it completes the push

Open girishramnani opened this issue 5 years ago • 8 comments

Issue

When a component was pushed using the Push action, it instantaneously changed to pushed even before the push process started. This becomes as issue if someone stops the push process in the middle, they would end up in pushed component state even if the component is not pushed. I did that and had to reload the tree to get into correct state.

Screenshot

image

girishramnani avatar Mar 16 '20 20:03 girishramnani

Related to #1425.

dgolovin avatar Mar 16 '20 21:03 dgolovin

The reason it's been done that way is because we are using terminal to run push to make output visible, but that blocks us from getting any information back like process instance or process return code. We are going to run it differently so we can reflect real status for push: not pushed, pushing, pushed.

dgolovin avatar Mar 16 '20 21:03 dgolovin

@girishramnani is that possible for component to get in failed state when push command failed for some reason? Let say push failed because some of resources related to component were not created, storage or something else. What state would appear in odo list for component like that?

dgolovin avatar Mar 17 '20 20:03 dgolovin

so I tried two scenarios -

  1. fails before or while creating a component on the cluster e.g. maybe due to validation check failure, duplicate component name. In such cases the state comes as Not Pushed because the deployment config is not present on the cluster. e.g.
$ odo push
Validation
 ✓  Checking component [822ms]

Configuration changes
 ✓  Initializing component
 ◑  Creating component^C   # forcefully emulated the behavior
(base) [gramnani@girishpc r2t]
$ odo list --context .
APP     NAME      PROJECT        TYPE       SOURCE        STATE
app     hello     drahwxuemx     nodejs     file://./     Not Pushed
  1. fails after the component is created but before push is completed e.g. due to s2i build failures or timeouts. In such cases the state stays as Pushed as the DC is present on the cluster. e.g.
$ odo push
Validation
 ✓  Checking component [827ms]

Configuration changes
 ✓  Initializing component
 ✓  Creating component [2s]

Pushing to component hello of type local
 ✓  Checking files for pushing [7ms]
 ◓  Waiting for component to start^C # forcefully emulated a failure
(base) [gramnani@girishpc r2t]
$ odo list --context .
APP     NAME      PROJECT        TYPE       SOURCE        STATE
app     hello     drahwxuemx     nodejs     file://./     Pushed

does this answer your question @dgolovin

girishramnani avatar Mar 17 '20 21:03 girishramnani

Yes. Thank you for testing this for me! Another questions:

  1. would consecutive push work for both cases, only for first or only for second?
  2. would delete work for component in second case?

dgolovin avatar Mar 17 '20 21:03 dgolovin

1 - consecutive push works flawlessly with first case but second case I see an error in the immediate push

$ odo push
Validation
 ✓  Checking component [799ms]

Configuration changes
 ✓  Retrieving component data [1s]
 ✗  Applying configuration [1s]
 ✗  Failed To Update Config To Component Deployed.
Error: unable to update DeploymentConfig for t2r component: unable to update the current DeploymentConfig t2r-app: unable to update DeploymentConfig t2r-app: Operation cannot be fulfilled on deploymentconfigs.apps.openshift.io "t2r-app": the object has been modified; please apply your changes to the latest version and try again

which gets resolved after another odo push

2 - yes, delete works for the second case.

girishramnani avatar Mar 17 '20 21:03 girishramnani

So after odo push failed for component in 'not pushed' state it can transition to 'pushed' state or stay in 'not pushed' state.

While odo push is running we can show 'being pushed' (could be a better name) as a state and refresh the node after odo push exits. While state for component is 'being pushed' we disable all the commands for component until odo exits or force them to wait. After odo push exits without errors we can transition component to 'pushed' state right away. If it exits with error, we have to find out state based on odo list or odo describe output and show error message.

image

This logic could apply to other commands, which supposed to be able to recover after errors the same way.

dgolovin avatar Mar 18 '20 07:03 dgolovin

Similar to #1800.

dgolovin avatar Oct 21 '20 08:10 dgolovin

As we are moving to odo dev workflow, we no more show Pushed status. Hence closing.

mohitsuman avatar Oct 27 '22 11:10 mohitsuman