Thanks for taking the time to looking at the proposal and leaving a feedback Nathan ^^!

Regarding the GitHub action, the reason we wanted it to be optional is for two reasons:

I totally understand the concern that making it non-optional would mean increased chances of missing the documentation of a configuration option, but I think we can reduce the probability of this happening by adding the label (say, "release-note-update-maybe" - I'll come up with better name!) to the PR in addition to the PR comments to make the author and reviewers aware of the extra check of ensuring release notes are updated whenever necessary. Please let me know if you have any other suggestion ^^

Thanks,
Naveen

From: Nathan Hoad (BLOOMBERG/ 120 PARK) <nhoad@bloomberg.net>
Sent: Thursday, March 13, 2025 8:53 PM
To: Naveen Naidu <naveen.naidu@ibm.com>
Cc: dev@ceph.io <dev@ceph.io>
Subject: [EXTERNAL] Re:Ceph Configuration Diff Tool - Request for comments
 
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious
 
Hi Naveen,

This is a great idea! +1 on both parts of the proposal. This exact problem has definitely caught people off guard in the past when performing upgrades, so having a quick and easy way to verify changes will help reduce some friction for sure :)

For the Github action, would you consider making the check non-optional to enforce that the release notes have been updated? I'm trying to imagine a scenario where we would want to change the defaults/add new options and not have that documented and I'm drawing a blank.

Thank you,

Nathan

From: naveen.naidu@ibm.com At: 03/13/25 10:09:34 UTC-4:00
To: dev@ceph.io
Subject: Ceph Configuration Diff Tool - Request for comments

Hi all,

We are planning to introduce a new tool/script which would help with the problem of visibility of the changes done to Ceph configuration options. Currently there are two main limitations:

Some context on ceph configuration management system:
 
The default values for all the configuration options for a ceph cluster when starting up are in the yaml files present in the `src/common/options` directory. 

For example: `osd.yaml.in` file tells us all the configuration options available for `ceph-osd` daemon. 

The config options from yaml files are directly injected to the `CephContext` and these files are the sole source of truth to know about the configurations present for all the systems of ceph. It is important to note that, the values in the yaml files only represent the default values with which the cluster starts with, any changes made to these config options are not reflected in the yaml files.

The detailed information about the configuration management is present here: https://docs.ceph.com/en/latest/dev/config/

Proposal to solve this problem is two fold:

1. Tool to compare configuration options between releases or commit hashes

2.  A Github action runs on every PR (it only executes when the yaml files are updated). This will be added as an optional check.

I believe, these two options should help solve the current visibility problems in ceph configuration system.

Please let us know your thoughts about this feature. All inputs are welcome.

Thanks,
Naveen



_______________________________________________
Dev mailing list -- dev@ceph.io
To unsubscribe send an email to dev-leave@ceph.io