| hach-que | |
| Dec 21 2015, 3:03 AM |
| F1034816: pasted_file | |
| Dec 21 2015, 3:20 AM |
| F1034799: pasted_file | |
| Dec 21 2015, 3:12 AM |
| F1034802: pasted_file | |
| Dec 21 2015, 3:12 AM |
| F1034791: pasted_file | |
| Dec 21 2015, 3:09 AM |
| F1034787: pasted_file | |
| Dec 21 2015, 3:09 AM |
| F1034753: pasted_file | |
| Dec 21 2015, 3:03 AM |
| F1034760: pasted_file | |
| Dec 21 2015, 3:03 AM |
| F1034748: pasted_file | |
| Dec 21 2015, 3:03 AM |
This is what I see on the lease (last activity 2PM):
Clicking through to the blueprint I see this (last activity 12:56PM):
Looking at all the resources made by that blueprint:
Clicking on the latest one shows it was one of the reclaimed resources:
I expect that if a lease is waiting on a resource to become available, that a resource is actually being created.
| rP Phabricator | |||
| D14854 | rP551732b96213 Basic NUX states for Phriction | ||
This is what I see in the daemon page (there are two builds trying to get a lease on this working copy blueprint):
There apparently was a resource worker that completely recently, but I can't actually see the details of those completed tasks:
I just restarted the first build and looked at the lease that was trying to be obtained:
But there's no new resource or new activity on the working copy blueprint:
So I managed to workaround this issue. First I reset all the attributes of the blueprint with:
update drydock_blueprint set details = '[]' where id=11;
Then I restarted a build. When I went to working copy blueprint again, I saw a resource being allocated:
This report does not include reproduction steps that we can use to reproduce the problem. See Contributing Bug Reports.
I don't know what reliable reproduction steps you expect here. Drydock doesn't really give me any indication as to what it's doing or why it's doing nothing. The screenshots clearly indicate the issue at hand, and the accompanying text indicates what I did to reproduce the issue on my install.
Given that this is likely to be some sort or race condition or bug with the way limits are being handled, I'm not sure there are reliable reproduction steps (generally anything that involves high degrees of concurrency are hard to reproduce, e.g. T9724).