You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm setting up a new test clearinghouse at the moment. My donating install transitions nodestates alright at first, and counts towards my user's credits correctly, but the clearinghouse never gets to see any vessels donated.
Setting the clearinghouse's DEBUG = True reveals that the clearinghouse tries to split the node into vessels larger than what the node could provide. Trying to split this way is a NMClientException in the CH API (and a BadRequest in the node's nmAPI.py).
No entry in the vessel database is made, neither for the attempted split vessel, nor the original one. Despite this, the node is marked with the twopercent key to signify "all set up correctly". That's bad because with no entry in the DB, the CH can never assign this unsplittable vessel to a user.
And indeed, when the node has sufficient resources, the clearinghouse makes vessels out of it! The node at hand now has v2, the service vessel, and v16, v18, v20, v22 as publicly available vessels.
Now, v21 remains as the thing that's smaller than the split size which the CH wants, and thus isn't added to the database. Note that it is still advertised, has a proper resource file, its sandbox dir, etc.!
Grepping through the transition script logs reveals the split / join action that leads to the final vessels:
$ pbpaste | grep "Successfully split vessel"
[2015-07-22 10:17:16.370742] INFO 501433424 Successfully split vessel: v1 into vessels: v3 and v4
[2015-07-22 10:17:42.303067] INFO 501433424 Successfully split vessel: v3 into vessels: v5 and v6
[2015-07-22 10:18:07.205756] INFO 501433424 Successfully split vessel: v5 into vessels: v7 and v8
[2015-07-22 10:18:33.305296] INFO 501433424 Successfully split vessel: v7 into vessels: v9 and v10
[2015-07-22 10:21:55.195078] INFO 992914479 Successfully split vessel: v14 into vessels: v15 and v16
[2015-07-22 10:22:10.511091] INFO 992914479 Successfully split vessel: v15 into vessels: v17 and v18
[2015-07-22 10:22:35.191658] INFO 992914479 Successfully split vessel: v17 into vessels: v19 and v20
[2015-07-22 10:23:02.734442] INFO 992914479 Successfully split vessel: v19 into vessels: v21 and v22
$ pbpaste | grep "Combined vessel"
[2015-07-22 10:19:27.222187] INFO 945190750 Combined vessel v9 and v10 into v11
[2015-07-22 10:19:45.981188] INFO 945190750 Combined vessel v11 and v4 into v12
[2015-07-22 10:19:54.088218] INFO 945190750 Combined vessel v12 and v6 into v13
[2015-07-22 10:20:01.953274] INFO 945190750 Combined vessel v13 and v8 into v14
I'm setting up a new test clearinghouse at the moment. My donating install transitions nodestates alright at first, and counts towards my user's credits correctly, but the clearinghouse never gets to see any vessels donated.
Setting the clearinghouse's
DEBUG = True
reveals that the clearinghouse tries to split the node into vessels larger than what the node could provide. Trying to split this way is aNMClientException
in the CH API (and aBadRequest
in the node'snmAPI.py
).No entry in the vessel database is made, neither for the attempted split vessel, nor the original one. Despite this, the node is marked with the
twopercent
key to signify "all set up correctly". That's bad because with no entry in the DB, the CH can never assign this unsplittable vessel to a user.To fix this,
transition_canonical_to_twopercent.py
should detect / handle errors between advancing nodes states.Below follows the rather large transition script log, redacted so as to replace the unwiedly pubkeys logged. The overall flow of events is
canonical
state that needs to be transitionedmovingto_twopercent
, i.e. it's being worked onmovingto_twopercent
state that needs to be transitionedProposed vessel is too large. Insufficient quantity: Resource 'diskused' has a negative quantity
.Successfully changed the node state to
twopercent, which it shouldn't do after the error aboveThe text was updated successfully, but these errors were encountered: