Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
6.5.0
-
2019-10-17 build form source, Enterprise Edition 6.5.0 build 000
Description
While in Eventing for any given function/handler
- When I hit a Deploy button the UI shows first a status of "undeploy..." and then a final status of "deployed"
- When I hit a Deploy button the UI shows first a status of "undeploying..." and then a final status of "undeployed"
There seem to be issues with reporting status in the UI when doing a Pause and Resume:
- ISSUE: When I hit a Pause button the UI shows first a status of "pausing..." and then a final status of either "undeployed" or "paused" (some sort of race condition) I have seen both status messages.
- ISSUE: When I hit a Resume button the UI shows first a status of "deploying..." and then a final status of "deployed". For consistency after hitting the Resume button case the UI should first show a status of "resuming..." and then a final status of "deployed" when the resume is complete.
Attachments
Gerrit Reviews
| For Gerrit Dashboard: MB-36552 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 141087,4 | MB-36552: Fix calculation of apps pausing status | unstable | eventing | Status: NEW | 0 | 0 |
Activity
Moving to CC as refresh of UI solves the inconsistencies. We may still pull this back into Mad-Hatter if other higher priority hard bugs get fixed soon. Labelled the ticket accordingly.
Jon Strabala With all the recent fixes to UI, do you still these issues? I believe the resuming... part is still true.
I did see one more occurrence of a similar issue this last Monday on a source build (6.5.1 made on Feb 24, 2020) in my testing (I'm talking hours of testting) where it was showing "deployed..." and the UI was incapable of fixing the issue [ this was different form the wacky mixed up buttons as per the images I posted ].
A REST call however worked to get it unstuck (I did not need to resort to "cbevent -flush") and since it was a 6.5.1 UI I didn't need to hit refresh - I think I only ran the first command below:
curl -X POST -d '{"deployment_status":false,"processing_status":false}' -s 'http://'${CB_USERNAME}:${CB_PASSWORD}'@localhost:8096/api/v1/functions/<<YOUR_FUNCTION_NAME>>/settings'
curl -X POST -d '{"deployment_status":true,"processing_status":true}' -s 'http://'${CB_USERNAME}:${CB_PASSWORD}'@localhost:8096/api/v1/functions/<<YOUR_FUNCTION_NAME>>/settings'
If we prematurely indicate that we are paused it is possible that a customer might decide it is safe to perform a rebalance and have a potential hang. Granted this is a small window of time for this to happen.
Seems like the Deploy button also has a race where the incorrect status is shown.
Sometime when I hit a Deploy button the UI showed a final status of "undeployed" until I refresh the browser (see image A_ and also image B_ after a refresh to correct the GUI display). Thus I imaging that (some sort of race condition) exists for the Deploy button also.
Note in the above instance (e.g. with the pictures attached) I had a error in the function I deployed where it called a non-existant function, it did process all mutations and showed the failure.
I tried to recreate the same sequence but it is intermittent and rarely reproduces.