vscode-openshift-tools
vscode-openshift-tools copied to clipboard
Status of a component becomes "pushed" before it completes the push
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

Related to #1425.
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.
@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?
so I tried two scenarios -
- 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 Pushedbecause 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
- 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
Pushedas 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
Yes. Thank you for testing this for me! Another questions:
- would consecutive push work for both cases, only for first or only for second?
- would delete work for component in second case?
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.
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.

This logic could apply to other commands, which supposed to be able to recover after errors the same way.
Similar to #1800.
As we are moving to odo dev workflow, we no more show Pushed status. Hence closing.