Skip to content

HDDS-15923. Remove old website and Hugo#10829

Open
errose28 wants to merge 3 commits into
apache:masterfrom
errose28:worktree/remove-hugo
Open

HDDS-15923. Remove old website and Hugo#10829
errose28 wants to merge 3 commits into
apache:masterfrom
errose28:worktree/remove-hugo

Conversation

@errose28

@errose28 errose28 commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Generated with Claude Opus 4.8

The old Ozone website is still checked in to the master branch and built with Hugo. Sometimes devs mistakenly update content there thinking it will be published to the new website, which is in the ozone-site repo. This PR completely removes the old website and Hugo since it is now unused. The old content can still be built from past checkouts in git like release branches if needed. As part of this change:

  • Pre-built rendered docs from the old site are still accessible at https://ozone.apache.org/docs/2.0.0, no change in availability to users.
  • Design docs are moved to a top level design directory.
    • This could be located anywhere in the repo, but a top level separate from the source code seems to make sense.
    • rat.sh is the only CI check which will run on changes made here.
  • Web UIs' documentation links were updated to point to https://ozone.apache.org/docs
    • They previously opened a version of the docs bundled with the build, but these docs have been outdated since we switched to the new website.
    • We could also optionally remove this link, or bundle a snapshot of the website with the dist build profile in a follow-up change.
  • The outdated OEP "design" doc was removed since it is intended to be replaced by HDDS-15728. Add OEP doc #10822.
    • We could optionally leave this and remove it after the website PR, but its content is somewhat stale anyways.

What is the link to the Apache JIRA

HDDS-15923

How was this patch tested?

  • Manual review of AI generated changes
  • Manually verified updated links in existing design docs
  • Manually checked OM,SCM,DN web UI docs links in a docker cluster
  • The bats test for selective CI triggering only rat on design requires an existing commit to master targeting the directory, which currently does not exist.
    • The test has been commented out and can be re-enabled when such a commit is merged.

@errose28 errose28 added documentation Improvements or additions to documentation build Pull request that modifies the build process code-cleanup Changes that aim to make code better, without changing functionality. labels Jul 21, 2026

@jojochuang jojochuang left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This will have the the benefit of reducing binary size. Probably not a lot but it helps.

Please wait a few days for folks to chime in. Originally, the idea was to have the docs shipped with the binary so admin can reference even without internet access. But that was a long time ago. In any case, that wouldn't work now given our doc has migrated to the website repo.

@errose28

Copy link
Copy Markdown
Contributor Author

Yeah we can leave this open for a week or two, there's no rush. The only open issues I'm aware of are:

  • New releases ship with outdated docs embedded in them
  • Confusing for devs where to update documentation

Originally, the idea was to have the docs shipped with the binary so admin can reference even without internet access. But that was a long time ago. In any case, that wouldn't work now given our doc has migrated to the website repo.

Yes this was a concern when we started the new website. At the time it was deemed a minor issue, because even though the cluster may be airgapped, the developer working on it almost certainly isn't and can go to ozone.apache.org in their regular browser.

As mentioned in the description, I'm also fine with removing the docs links from the WebUI all together, but I think they are useful in the common case.

I previously advocated for putting the site in a separate repo but to this day I'm not sure it was the right choice. For a myriad of reasons it seems like a mono repo would have been easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Pull request that modifies the build process code-cleanup Changes that aim to make code better, without changing functionality. documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants