Arvados

21388-arvados-3.0-distros-docs @ 9be3f8238344e3e06f01311e97038361873fbdeb - developer-run-tests: #4266

• All agreed upon points are implemented / addressed.
  • And more. Commands get modernized. Markup gets cleaned up. Python packages get real README files. You're welcome!
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • N/A
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • I built web documentation locally and reviewed major changes. I ran the new Debian repo setup and package install commands on my own laptop to confirm they work.
• Documentation has been updated.
  • N/A, this is already an "update documentation" follow-up to other, larger tickets
• Behaves appropriately at the intended scale (describe intended scale).
  • No change in scale
• Considered backwards and forwards compatibility issues between client and server.
  • The oldest deb-based distribution we support, Ubuntu 20.04, includes the same repo setup documentation as the latest, Debian 12. It's safe to use.
• Follows our coding standards and GUI style guidelines.
  • N/A (we sadly lack a documentation style guide)

Brett Smith wrote in #note-13:

21388-arvados-3.0-distros-docs @ 9be3f8238344e3e06f01311e97038361873fbdeb - developer-run-tests: #4266

• All agreed upon points are implemented / addressed.
  • And more. Commands get modernized. Markup gets cleaned up. Python packages get real README files. You're welcome!
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • N/A
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • I built web documentation locally and reviewed major changes. I ran the new Debian repo setup and package install commands on my own laptop to confirm they work.
• Documentation has been updated.
  • N/A, this is already an "update documentation" follow-up to other, larger tickets
• Behaves appropriately at the intended scale (describe intended scale).
  • No change in scale
• Considered backwards and forwards compatibility issues between client and server.
  • The oldest deb-based distribution we support, Ubuntu 20.04, includes the same repo setup documentation as the latest, Debian 12. It's safe to use.
• Follows our coding standards and GUI style guidelines.
  • N/A (we sadly lack a documentation style guide)

This LGTM.

Separately, a couple discussion points.

We say "Alma/CentOS/Red Hat/Rocky" in various places but maybe it would be clearer to say "Red Hat and derivatives (Alma/CentOS/Rocky)".

The status of CentOS is also weird. Alma and Rocky are explicitly compatible rebuilds of RHEL but CentOS is something else. We also continue to distribute our packages as "CentOS", but that's misleading (since we're currently using Rocky to build packages).

Red Hat has something called a Universal Base Image which seems to include our use case of building RHEL compatible packages without a RHEL license.

Peter Amstutz wrote in #note-15:

We say "Alma/CentOS/Red Hat/Rocky" in various places but maybe it would be clearer to say "Red Hat and derivatives (Alma/CentOS/Rocky)".

I'm open to wordsmithing but this specific suggestion sounds like a wash to me personally. For what it's worth, my experience at other jobs has been that it's not obvious to all users which distros are Red Hat derivatives.

The status of CentOS is also weird. Alma and Rocky are explicitly compatible rebuilds of RHEL but CentOS is something else.

You are right about modern versions, and because of that, I expect CentOS 8 is the last version of CentOS we're going to support for the foreseeable future. Given the change in development focus for CentOS, I don't think there's going to be much user interest in deploying Arvados on it. When we provide packages for the RHEL 9 family of distros, CentOS will get dropped from the list.

We also continue to distribute our packages as "CentOS", but that's misleading (since we're currently using Rocky to build packages).

Yes. It's one of these things, a lot of our package-upload-and-repository-build infrastructure is written to assume rpm packages go under the CentOS directory, and since it's "just" a URL, it doesn't "really" matter. I wouldn't be opposed to cleaning this up, but it's noticeable effort for almost zero technical gain.

Red Hat has something called a Universal Base Image which seems to include our use case of building RHEL compatible packages without a RHEL license.

Agreed, filed #21854.

as discussed at standup, the commit removing mention of CentOS LGTM.