Promoter raises PromotionError after successful promotion: candidate hash timestamps are not gathered correctly.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Incomplete
|
High
|
Gabriele Cerami |
Bug Description
logs at
http://
show that promoter fails with
2020-04-23 22:07:02,344 28533 ERROR promoter Dlrn promote 'aggregate: 724a63c3a2f42ab
2020-04-23 22:07:02,344 28533 ERROR promoter Candidate hash 'aggregate: 724a63c3a2f42ab
2020-04-23 22:07:02,344 28533 ERROR promoter API returned different promoted hash
Traceback (most recent call last):
File "/home/
candidate_
File "/home/
candidate_
File "/home/
raise PromotionError("API returned different promoted hash")
PromotionError: API returned different promoted hash
2020-04-23 22:07:02,347 28533 ERROR promoter Error while trying to promote tripleo-ci-testing to current-tripleo
then summary shows:
2020-04-23 22:07:04,994 28533 INFO promoter Summary: Promoted 0 hashes this round
2020-04-23 22:07:04,994 28533 INFO promoter ------- -------- Promoter terminated normally
But if we check dlrn api, the hash is indeed promoted.
Changed in tripleo: | |
milestone: | ussuri-rc1 → ussuri-rc3 |
Changed in tripleo: | |
milestone: | ussuri-rc3 → victoria-1 |
Changed in tripleo: | |
milestone: | victoria-1 → victoria-3 |
Changed in tripleo: | |
milestone: | victoria-3 → wallaby-1 |
Changed in tripleo: | |
milestone: | wallaby-1 → wallaby-2 |
Changed in tripleo: | |
milestone: | wallaby-2 → wallaby-3 |
Changed in tripleo: | |
milestone: | wallaby-3 → wallaby-rc1 |
Changed in tripleo: | |
milestone: | wallaby-rc1 → xena-1 |
This is a problem in a runtime check.
The promoter uses batch promotion API call to promote. This API requires a list of hashes to promote all together. The hashes are then processed in order, and the last hash that promotes, is the one bound to the aggregate hash. The API then returns the aggregate hash with the bound commit/distro hash as proof that the promotion succeeded.
The promoter then checks that the aggregate hash in the request corresponds to the aggregate hash in the response, bound commit/distro included.
In this case we are seeing that requested and promoted aggregate hashes are bound to different commit/distro hashes.
So the error is in the expectation for the runtime check, not in the process itself.