Document bodhi's expectations for signing tags

[jeremycline]

It would be great for there to be some documentation on Bodhi's expectations with respect to signing tags.

The interaction between Bodhi, Koji, and the autosigning service is done in a somewhat round-about way via AMQP messages and Koji tags that Bodhi and the autosigning service manipulate. I want to ensure the autosigning service is interacting with Koji tags in the way Bodhi expects, so knowing what Bodhi expects would help me.

My understanding

When a user submits an update, Bodhi tags the builds in that update into a -signing-pending koji tag. This will either be something like f45-signing-pending or a tag derived from the side tag like f44-build-side-139920-signing-pending.

Koji emits an AMQP message when it applies the tag.

The autosigning service subscribes to the Koji AMQP messages and uses its application configuration to decide if builds should be signed when a given tag is applied. It is responsible for:

1. Signing the RPMs with the right key and submitting that signature to Koji with addRPMSig.
2. Sending a writeSignedRPM request to Koji to have it write out a copy of the RPM with that signature
3. When all RPMs in the build are signed with the keyid configured, moving the build out of the -signing-pending tag into some other tag.

Open questions

Does my understanding match Bodhi's understanding?

Yesterday, @nirik diagnosing the signing queue getting stuck yesterday because eln-build-side-140508-signing-pending in history of build kruler-26.04.2-1.eln156. What happened was:

1. bodhi tags the stuff into eln-build-side*signing-pending
2. bodhi sees it's signed already. Great! Push to stable and delete sidetag
3. robosignatory sees that message on the message bus from the tagging
4. robosignatory sees that the build is not currently tagged with that tag (because bodhi untagged it when it went stable)
5. robosignatory throws a exception and returns the message to the queue.
6. robosignatory pops the next message off the queue.. and it's that same message!

So a more focused question is: should the autosigning service expect that builds tagged into a -signing-pending tag be moved out of it by Bodhi? For the record I think the autosigner should handle this case smoothly, but having documentation to point to and a general agreement about the "API" would be good.

[mattiaverga]

Yeah, the logic behind Bodhi interaction with Koji tags is really convoluted... There are several paths based on the update being a side-tag or normal, or the release being composed by bodhi or not, and the combination of the two.

For a quick response, the logic behind this specific case is in https://github.com/fedora-infra/bodhi/blob/develop/bodhi-server/bodhi/server/tasks/approve_testing.py
That task only applies to Updates in testing status, so I think it gives for granted that the signing phase has been completed successfully.
The specific case is for an update in a side-tag for a release not composed by Bodhi, so the task does all the work needed to move the update to stable:

bodhi/bodhi-server/bodhi/server/tasks/approve_testing.py

Lines 105 to 137 in be7fc70

	update.add_tag(update.release.stable_tag)
	update.status = UpdateStatus.stable
	update.request = None
	update.pushed = True
	update.date_stable = datetime.datetime.now(datetime.timezone.utc)
	update.comment(db, "This update has been submitted for stable by bodhi",
	author=u'bodhi')
	update.modify_bugs()
	db.commit()
	if update.from_tag:
	# Merging the side tag should happen here
	pending_signing_tag = update.release.get_pending_signing_side_tag(
	update.from_tag)
	testing_tag = update.release.get_pending_testing_side_tag(update.from_tag)
	update.remove_tag(pending_signing_tag)
	update.remove_tag(testing_tag)
	update.remove_tag(update.from_tag)
	# Delete side-tag and its children after Update has enter stable
	# We can't fully rely on Koji's auto-purge-when-empty because
	# there may be older nvrs tagged in the side-tag
	koji = buildsys.get_session()
	koji.multicall = True
	koji.deleteTag(pending_signing_tag)
	koji.deleteTag(testing_tag)
	koji.deleteTag(update.from_tag)
	koji.multiCall()
	else:
	# Non side-tag updates
	update.remove_tag(update.release.pending_testing_tag)
	update.remove_tag(update.release.pending_stable_tag)
	update.remove_tag(update.release.pending_signing_tag)
	update.remove_tag(update.release.testing_tag)
	update.remove_tag(update.release.candidate_tag)

The task also takes care of deleting the specific side-tags in Koji, including the pending_signing_tag. This should not be necessary, as all the builds of the update should already have been signed by robosignatory, but I think it's a safe action to not let stale tags around forever?
AFAIK this is the only place where bodhi deliberately deletes any Koji tag by itself.