Repository navigation
feat(db): add a table for each member's last applied RGW frontend - #881
Open
johnramsden wants to merge 2 commits into
Open
johnramsden wants to merge 2 commits into
johnramsden wants to merge 2 commits into
Conversation
johnramsden
added this pull request to stack #894
September 23, 2026 04:20
This was referenced Sep 23, 2026
johnramsden
marked this pull request as ready for review
September 23, 2026 04:29
5 tasks done
johnramsden
force-pushed
the
rgw-stack/01-frontend-table
branch
2 times, most recently
from
September 24, 2026 19:32
bac708a to
dfc3505
Compare
sabaini
approved these changes
Sep 29, 2026
sabaini
left a comment
Collaborator
There was a problem hiding this comment.
nit: testing weakness, not a blocker though
This was referenced Oct 2, 2026
Open
This is scaffolding: the table and its helpers land now, unused, so later commits in this series build on a settled schema instead of bundling a migration with the feature that needs it. Each member applies its own RGW settings, so the cluster needs one place that remembers what every member last applied, including while that member is down. schemaUpdate10 adds the rgw_frontends table with the columns member_id, port, ssl_port and ssl. It never holds certificate material, so leaking a row leaks nothing secret, and a row is deleted together with its core_cluster_members row so it can never outlive the member it describes. UpsertRGWFrontend and DeleteRGWFrontendByMember will be called from the member-side apply and disable paths added later in this series, to record and clear a member's settings as they change. GetRGWFrontends will be used by the placement status read path added later, to report what each member is actually serving. The three helpers are hand-written rather than generated by the lxd-generate mapper because every caller identifies a member by name, not by its internal database id, and the mapper codegen does not support that lookup. Co-authored-by: Peter Sabaini <peter.sabaini@canonical.com> Assisted-by: claude-code:claude-fable-5-1 Assisted-by: pi:gpt-6-astra Signed-off-by: John Ramsden <john.ramsden@canonical.com>
Assisted-by: omp:openai/gpt-6-astra Signed-off-by: John Ramsden <john.ramsden@canonical.com>
johnramsden
force-pushed
the
rgw-stack/01-frontend-table
branch
from
October 6, 2026 00:47
79225fa to
e783dba
Compare
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
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.
Description
This is scaffolding: the table and its helpers land now, unused, so later commits in this series build on a settled schema instead of bundling a migration with the feature that needs it.
Each member applies its own RGW settings, so the cluster needs one place that remembers what every member last applied, including while that member is down.
schemaUpdate10adds thergw_frontendstable with the columnsmember_id,port,ssl_portandssl. It never holds certificate material, so leaking a row leaks nothing secret, and a row is deleted together with itscore_cluster_membersrow so it can never outlive the member it describes.UpsertRGWFrontendandDeleteRGWFrontendByMemberwill be called from the member-side apply and disable paths added later in this series, to record and clear a member's settings as they change.GetRGWFrontendswill be used by the placement status read path added later, to report what each member is actually serving.The three helpers are hand-written rather than generated by the
lxd-generatemapper because every caller identifies a member by name, not by its internal database id, and the mapper codegen does not support that lookup.Stack: PR 1 of 13. Merge in order. Each PR is one logical change on top of the one before it.
Type of change
How has this been tested?
Contributor checklist
Please check that you have: