Silo configured "half way" after an error about lack of test plan
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | CI Train [cu2d] |
Fix Released
|
Undecided
|
Robert Bruce Park | |
Bug Description
After this errored out prepare-silo:
https:/
Bileto started thinking the request:
https:/
Even though it does not actually look like so if looking at the request https:/
But then, 014 silo does seem to be assigned according to running another prepare-silo for a new identical request: https:/
So it seems it both is and isn't assigned.
Related branches
- PS Jenkins bot: Approve (continuous-integration) on 2015-09-11
- Robert Bruce Park (community): Approve on 2015-09-11
-
Diff: 114 lines (+17/-25)2 files modifiedcupstream2distro/silomanager.py (+16/-16)
tests/unit/test_silomanager.py (+1/-9)
| description: | updated |
| description: | updated |
| Robert Bruce Park (robru) wrote : | #1 |
| affects: | bileto → cupstream2distro |
| Changed in cupstream2distro: | |
| status: | New → In Progress |
| Timo Jyrinki (timo-jyrinki) wrote : | #2 |
Thanks! Freed up the silo/request now.
| PS Jenkins bot (ps-jenkins) wrote : | #3 |
Fix committed into lp:cupstream2distro at revision 1095, scheduled for release in cupstream2distro, milestone Unknown
| Changed in cupstream2distro: | |
| status: | In Progress → Fix Committed |
| Changed in cupstream2distro: | |
| status: | Fix Committed → Fix Released |
| assignee: | nobody → Robert Bruce Park (robru) |

Well, I couldn't sleep and decided to work on this, found a simple solution ;-)
My branch should prevent this situation from happening again, however to fix your existing request in an inconsistent state, you'll need to manually set the siloname field in bileto to ubuntu/landing-NNN and then it should work just fine, from there you can either free it (since you already have the identical other one) or use it.