-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reasons for queueing proposals should be exposed in the UI #1182
Comments
Here's some debug I added to this code, just for reference. |
Reasons for queuing are part of the flash messages, aren't they? (e.g. waiting for nodes x, y to become ready). |
Yeah maybe the flash is good enough, but are all the cases are already covered? |
Good point. I don't think they are. Only 'node missing' is. 'Another role is in the queue', IMHO. |
A better flash message should be cool. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A proposal can be queued rather than immediately applied for a number of reasons, e.g. one of the required nodes is not ready, or one of the dependent barclamps is already queued, or has never run successfully. These reasons should bubble up in the UI (web and CLI / REST API), otherwise proposals can remain stuck in the queued state for no obvious reason.
This will require modifications to the following methods in
app/models/service_object.rb
:elements_not_ready
add_pending_elements
queue_proposal
process_queue
I could probably fix this myself, but am somewhat hampered by lack of explanation in the code regarding what certain variables / data structures which get passed around are supposed to contain, in particular
delay
andpre_cached_nodes
. If someone could shed light on these, I'm more likely to be able to fix it. Thanks!The text was updated successfully, but these errors were encountered: