Skip to content

feat(db): add a table for each member's last applied RGW frontend - #881

Open
johnramsden wants to merge 2 commits into
mainfrom
rgw-stack/01-frontend-table
Open

johnramsden wants to merge 2 commits into
mainfrom
rgw-stack/01-frontend-table

Conversation

@johnramsden

@johnramsden johnramsden commented Sep 23, 2026 •

Copy link
Copy Markdown
Member

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. 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.

Stack: PR 1 of 13. Merge in order. Each PR is one logical change on top of the one before it.

  1. feat(db): add a table for each member's last applied RGW frontend #881 feat(db): add a table for each member's last applied RGW frontend (this PR)
  2. fix(services): keep error classes through the service enable path #882 fix(services): keep error classes through the service enable path
  3. feat(api): describe an RGW placement as an object with explicit TLS intent #883 feat(api): describe an RGW placement as an object with explicit TLS intent
  4. feat(rgw): make the member-side RGW apply safe to repeat #884 feat(rgw): make the member-side RGW apply safe to repeat
  5. feat(rgw): wait until the gateway really serves the requested frontend #885 feat(rgw): wait until the gateway really serves the requested frontend
  6. feat(rgw): reuse the member's own pair when TLS is asked for without one #886 feat(rgw): reuse the member's own pair when TLS is asked for without one
  7. fix(rgw): make RGW disable converge when repeated or interrupted #887 fix(rgw): make RGW disable converge when repeated or interrupted
  8. feat(placement): accept the RGW object in the policy and keep its secrets out #888 feat(placement): accept the RGW object in the policy and keep its secrets out
  9. feat(placement): reconcile RGW across the cluster #889 feat(placement): reconcile RGW across the cluster
  10. test(robot): add the single-VM RGW placement suite #890 test(robot): add the single-VM RGW placement suite
  11. test(robot): add the three-VM RGW placement suite #891 test(robot): add the three-VM RGW placement suite
  12. docs: keep the RGW placement contract in HACKING.md for now #892 docs: keep the RGW placement contract in HACKING.md for now
  13. fix(rgw): do not trust a pending-apply marker the operator completed by hand #893 fix(rgw): do not trust a pending-apply marker the operator completed by hand

Type of change

  • New feature (non-breaking change which adds functionality)

How has this been tested?

  • Unit tests pass at this stack's cumulative tip

Contributor checklist

Please check that you have:

  • self-reviewed the code in this PR
  • added code comments, particularly in less straightforward areas
  • checked and added or updated relevant documentation
  • checked and added or updated relevant release notes
  • added tests to verify effectiveness of this change

@johnramsden
johnramsden added this pull request to stack #894 September 23, 2026 04:20
@johnramsden johnramsden changed the title rgw stack/01 frontend table feat(db): add a table for each member's last applied RGW frontend Sep 23, 2026
@johnramsden
johnramsden marked this pull request as ready for review September 23, 2026 04:29
@johnramsden johnramsden mentioned this pull request Sep 23, 2026
5 tasks done
@johnramsden
johnramsden force-pushed the rgw-stack/01-frontend-table branch 2 times, most recently from bac708a to dfc3505 Compare September 24, 2026 19:32

@sabaini sabaini left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: testing weakness, not a blocker though

Comment thread microceph/database/rgw_frontend_extras_test.go Outdated

@sabaini sabaini left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

johnramsden and others added 2 commits October 5, 2026 17:46
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
johnramsden force-pushed the rgw-stack/01-frontend-table branch from 79225fa to e783dba Compare October 6, 2026 00:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants