errose28 commented on PR #6916:
URL: https://github.com/apache/ozone/pull/6916#issuecomment-2364595812
Thanks for the continued work on this @sarvekshayr. Looks like the PAT
approach is working well on your fork. I'll file an infra ticket to get a PAT
for the ozone-site repo, and we can continue work here in the mean time.
After reviewing the auto generated PRs, here are some high level suggestions:
---
## PR Message
- It would be nice to have the PR messages follow the PR template. We can
just hardcode that into the code that is generating it.
- It would also be good to have the branch and workflow names as actual
links.
- For branches, insert `<branchname>` into this template:
`[branchname](https://github.com/apache/ozone-site/tree/<branchname>)`.
- For workflows, GitHub has some
[contexts](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#github-context)
we might be able to use.
- Ideally we would be able to extract the Jira ID from the commit message,
and use that in the PR message as well. I think we do a similar thing in our
existing title CI check.
- We can use the short version of the hash for the branch name. This can be
obtained by passing the current hash to `git rev-parse --short`.
Overall I'm thinking the PR message could look like this, where HDDS-1234 is
the hypothetical Ozone change that made the config modification:
source branch: config-doc-update-from-22ddfb951a
# HDDS-1234. Update configurations.md page with changes from HDDS-1234
## What changes were proposed in this pull request?
This is an automated pull request triggered by the workflow build-branch run
from
[test-branch-2](https://github.com/sarvekshayr/ozone-site/tree/test-branch-2).
Please delete the
[config-doc-update-from-22ddfb951a](https://github.com/sarvekshayr/ozone-site/tree/config-doc-update-from-22ddfb951a)
branch after this PR is merged or closed.
## What is the link to the Apache Jira?
HDDS-1234
## How was this patch tested?
Reviewers should manually verify the correctness of this change.
---
## Webpage
- Right now each config key is rendered as it's own table. We should make
them one big table with a header row.
- When a config key references another config key in its description, it
would be nice to wrap it in single ticks.
- This will render them as inline code and prevent the new website's spell
checker from flagging them as errors.
- Since we have the config key map stored in memory when building the
page, we can check if a description contains a config key that needs to be
wrapped by checking if a whitespace-delimited word in the description is also a
key in the map.
- This will probably slow down the runtime but since this is happening
in the background I think that's ok.
- We can put each tag on a new line for readability. I have an example below.
- There are some concatenation errors in the existing code descriptions that
the new website's spell checker is correctly flagging. We can fix those in a
follow up task, don't worry about it for now.
Overall I'm thinking the webpage could look like this:
### Unrendered:
```md
---
sidebar_label: Appendix
---
# Configuration Key Appendix
This page provides a comprehensive overview of all configuration keys
available in Ozone.
## Configuration Keys
| **Name** | **Value** | **Tags** | **Description** |
|-|-|-|-|
| `hadoop.hdds.db.rocksdb.WAL_size_limit_MB` | 0MB |
`OM`<br/>`SCM`<br/>`DATANODE` | The total size limit of WAL log files. Once the
total log file size exceeds this limit, the earliest files will be
deleted.Default 0 means no limit. |
| `hadoop.hdds.db.rocksdb.WAL_ttl_seconds` | 1200 |
`OM`<br/>`SCM`<br/>`DATANODE` | The lifetime of WAL log files. Default 1200
seconds. |
| `hdds.container.balancer.move.replication.timeout` | 50m | `BALANCER` |
The amount of time to allow a single container's replication from source to
target as part of container move. For example, if
`hdds.container.balancer.move.timeout` is 65 minutes, then out of those 65
minutes 50 minutes will be the deadline for replication to complete. |
```
### Rendered:
# Configuration Key Appendix
This page provides a comprehensive overview of all configuration keys
available in Ozone.
## Configuration Keys
| **Name** | **Value** | **Tags** | **Description** |
|-|-|-|-|
| `hadoop.hdds.db.rocksdb.WAL_size_limit_MB` | 0MB |
`OM`<br/>`SCM`<br/>`DATANODE` | The total size limit of WAL log files. Once the
total log file size exceeds this limit, the earliest files will be
deleted.Default 0 means no limit. |
| `hadoop.hdds.db.rocksdb.WAL_ttl_seconds` | 1200 |
`OM`<br/>`SCM`<br/>`DATANODE` | The lifetime of WAL log files. Default 1200
seconds. |
| `hdds.container.balancer.move.replication.timeout` | 50m | `BALANCER` |
The amount of time to allow a single container's replication from source to
target as part of container move. For example, if
`hdds.container.balancer.move.timeout` is 65 minutes, then out of those 65
minutes 50 minutes will be the deadline for replication to complete. |
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
