Migrate from a concatenated pseudo pool ID - #866
Merged
gabriel-samfira merged 1 commit intoSep 4, 2026
Conversation
This change migrates from a pseudo pool ID composed of the entity ID and the name of the scale set, to a stable ID computed from the entity ID and the internal scaleset ID as an UUID V5. Both the entity ID and the internal scaleset ID are immutable. The UUID V5 will always be 36 characters long, regardless of the input data used to compute it. The downside of this change is that we now need to do two ListInstance() provider calls to list both instances tagged with the old shape of the ID and the new shape. Internally we record whether or not ListInstances() returned an empty list. If empty, we don't have instances in the provider for a scale set, so on each subsequent list, we only do one call. So in theory at least, we should only be abusing the IaaS API only as long as there are still old runners tagged with the old shape. Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
gabriel-samfira
force-pushed
the
attempt-fix-for-scaleset-id
branch
from
September 4, 2026 10:47
0484dc1 to
fb659ad
Compare
cbartz
approved these changes
Sep 4, 2026
cbartz
left a comment
cbartz
left a comment
Contributor
There was a problem hiding this comment.
LGTM.
Thank you so much for addressing this issue.
We could mention in the PR description that rollback of the GARM version will not be safe (when new runners are created with the new release and folks switch back to the one before), so we can mention this in the release notes.
Once this is merged, I'll test it and we can close cloudbase/garm-provider-openstack#34 afterwards.
Member
Author
|
@cbartz thanks! Description was updated and merged. Feel free to test and let me know if it works for you. |
12 tasks
cbartz
added a commit
to canonical/github-runner-operators
that referenced
this pull request
Sep 4, 2026
GARM tagged OpenStack instances with a pseudo pool ID built from the scale set name plus the entity UUID (50 fixed characters). A scale set name over 10 characters pushed the garm-pool-id server tag past Nova's 60-character limit, failing every instance creation (cloudbase/garm-provider-openstack#34). Bump the pinned GARM commit to the merge of upstream cloudbase/garm#866, which derives the pool ID as a fixed-length UUIDv5 from the entity ID and the scale set's internal database ID instead. The tag is now a constant 49 characters regardless of scale set name. Claude-Session: https://claude.ai/code/session_01XRYMKHaYKSKYbvg7WfAMVC
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change migrates from a pseudo pool ID composed of the entity ID and the name of the scale set, to a stable ID computed from the entity ID and the internal scaleset ID as an UUID V5.
Both the entity ID and the internal scaleset ID are immutable. The UUID V5 will always be 36 characters long, regardless of the input data used to compute it.
The downside of this change is that we now need to do two ListInstance() provider calls to list both instances tagged with the old shape of the ID and the new shape. Internally we record whether or not ListInstances() returned an empty list. If empty, we don't have instances in the provider for a scale set, so on each subsequent list, we only do one call.
So in theory at least, we should only be abusing the IaaS API only as long as there are still old runners tagged with the old shape.
Note: once you migrate to a version that contains this commit, you will no longer be able to migrate back without losing track of runners in the IaaS.