@de_fraz Happy to collaborate on this with you and help with the content from self-managed side.

FYI @swiskow for .com

Martin Brümmer (9914b420) at 13 Mar 09:10

Hey @manuel.kraft , Support for Valkey 7.2 in Omnibus is the plan for 19.0. We have no visibility of blockers so far, so I don't see a problem committing to this.

The binary has already been added in 18.9 which should give them a path for testing and adoption well ahead of their major upgrade. Does that work for them? Happy to get into a call and discuss specifics, as always.

@IslandChen Since your request, the data had been added: https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-is-new-since/?tab=cves&textSearch=CVE-2024-7586

Please note that data publication of CVEs isn't coordinated fully with our patch releases, so the patch release notes are the authoritative disclosure source, not this tool.

@emchang Unfortunately, we don't have that data in the deprecation files. Here's an example what data those files have attached. As opposed to the features in release post entries, I can't scrape the feature tier from deprecation files and thus I can't annotate them in the tool. There are no "feature ids" in GitLab either, so I cannot simply map the deprecation to the feature it addresses and pull the data from there. Any other fuzzy mapping using documentation would probably be very inaccurate, so I don't want to go there.

Sorry to disappoint the customer. @leeeee-gtlb and his team are working on GitLab detective which should help with impact assessments for breaking changes.

Looks good to me @eread , the breaking change request has been approved by leadership and migration guidance looks adequate. Thank you @grantyoung !

Be sure to link this MR to the relevant deprecation issue(s).

• Deprecation Issue: gitlab-com/Product#14477

If there is no relevant deprecation issue, hit pause and:

• Review the process for deprecating and removing features.
• Connect with the Product Manager DRI.

Deprecation announcements can be created and merged into Docs once approval has been granted to proceed with the change. We encourage confirmed deprecations to be merged as soon as the required reviews are complete, even if weeks ahead of the target milestone's release post. For the announcement to be included in a specific release post and that release's documentation packages, this MR must be reviewed/merged per the due dates below:

10 days (Monday) before the Release Date: Assign this MR to these team members as Reviewer and for Approval (optional unless noted as required):

• Product Marketing: @PMM
• Product Designer(s): @ProductDesigners
• Product Group Manager or Director: @PM - Required
• Engineering Manager: @cjwilburn - Required
• Technical writer: @eread - Required

By 11:59 AM PDT 8 days (Wednesday) before the Release Date: EM/PM assigns this MR to the TW reviewer for final review and merge: @EM/PM

By 11:59 PM PDT 6 days (Friday) before the Release Date: TW Reviewer updates Docs by merging this MR to master: @TW

---

Please review:

• The definitions of "Deprecation", "End of Support", and "Removal".
• The guidelines for deprecations.
• The process for creating a deprecation announcement.

They are frequently updated, and everyone should make sure they are aware of the current standards (PM, PMM, EM, and TW).

EM/PM release post item checklist

• Set yourself as the Assignee, meaning you are the DRI.
• For breaking changes:
  • Add the breaking change label to the MR.
  • If the breaking change affects GitLab.com, add window with a value of 1, 2, or 3. The value represents the planned release window for GitLab.com, typically in the three weeks before the major release date. You should intentionally plan this window ahead of time. If you're not sure, ask @swiskow.
• Confirm this MR is labeled release post itemdeprecation
• Follow the process to create a deprecation YAML file.
• Add reviewers by the 10th.
• Add scoped devops:: and group:: labels as necessary.
• Add the appropriate milestone to this MR.
• If the changes modify log format(addition/deletion/modification) of product feature, tag @gitlab-com/gl-security/engineering-and-research/security-logging team over the GitLab issue/MR.
• When ready to be merged (and no later than the 15th) @mention the TW for final review and merge.

Reviewers

When the content is ready for review, it must be reviewed by a Technical Writer and Engineering Manager, but can also be reviewed by Product Marketing, Product Design, and the Product Leaders for this area. Please use the reviewers feature for all reviews. Reviewers will then approve the MR and remove themselves from Reviewers when their review is complete.

• (Recommended) PMM
• (Optional) Product Designer
• (Optional) Group Manager or Director
• Required review and approval: Technical Writer designated to the corresponding DevOps stage/group.

Tech writer review

After being added as a Reviewer to this merge request, the TW performs their review according to the criteria described below.

Review deprecation MRs with a similar process as regular docs MRs. Add suggestions as needed, @ message the PM to inform them the first review is complete, and remove yourself as a reviewer if it's not ready for merge yet.

Expand for Details

• Title:
  • Length limit: 7 words (not including articles or prepositions).
  • Capitalization: ensure the title is sentence cased.
• Consistency:
  • Ensure that all resources (docs, deprecation, etc.) refer to the feature with the same term / feature name.
• Content:
  • Make sure the deprecation is accurate based on your understanding. Look for typos or grammar mistakes. Work with PM and PMM to ensure a consistent GitLab style and tone for messaging, based on other features and deprecations.
  • Review use of whitespace and bullet lists. Will the deprecation item be easily scannable when published? Consider adding line breaks or breaking content into bullets if you have more than a few sentences.
  • Make sure there aren't acronyms readers may not understand per our Writing style guidelines.
• Links:
  • All links must be full URLs, as the deprecation YAML files are used in two different projects. Do not use relative links. The generated doc is an exception to the relative link rule and currently uses absolute links only.
  • Make sure all links and anchors are correct. Do not link to the H1 (top) anchor on a docs page.
• Code. Make sure any included code is wrapped in code blocks.
• Capitalization. Make sure to capitalize feature names. Stay consistent with the Documentation Style Guidance on Capitalization.

When the PM indicates it is ready for merge and all issues have been addressed, start the merge process.

Technical writer merge process

Remove unnecessary spaces and text, and update the deprecations doc's .md file:

1. Check out the MR's branch (in the gitlab-org/gitlab project).
2. Remove unnecessary spaces (end of line spaces, double spaces, extra blank lines, lines with only spaces).
3. Remove unnecessary text (template and commented out text).
4. Update the deprecations.md file:
   1. From the command line (in the branch), run bin/rake gitlab:docs:compile_deprecations.
   2. To double check that it worked, you can run bin/rake gitlab:docs:check_deprecations to verify that the doc is up to date.
5. Update the breaking_windows.md file:
   1. From the command line (in the branch), run bin/rake gitlab:docs:compile_windows.
6. Commit the updated files and push the changes.
7. Set the merge request to auto-merge, or if the pipeline is already complete, merge.

If you have trouble running the Rake task, check the troubleshooting steps.

Martin Brümmer (84a91066) at 06 Mar 09:11

@jrandazzo Once you have identified these customers, can you compile a list? The current Operator doesn't have a lot of adoption and isn't a suitable model for future expansion really, so I don't want to invest in it without clear business reason.

This looks good to me @grantyoung. @eread Can you give a review?

FYI @jessie We are making modifications to the S3 support page, following a customer call requesting Nutanix S3 support. Reasoning is that as long as the vendor can guarantee S3 API support, this should work from our side and wouldn't require specific fog library extension

@jdrumtra GitLab Delivery is working on OAK, an orchestration that allows continued use of Omnibus while adding an adjacent Kubernetes cluster for new components. I would be happy to talk to your customer about this pattern and get their feedback directly.

What does this MR do?

Update cert-manager from 1.17.4 to 1.19.4

Update cert-manager to a supported version. Also changes to pull cert-manager from the OCI registry, which is the recommended way to pull/install the cert-manager chart.

• OCI docs: https://cert-manager.io/docs/installation/helm/#installing-from-the-oci-registry
• Upgrade to 1.18: https://cert-manager.io/docs/releases/upgrading/upgrading-1.17-1.18
• Upgrade to 1.19: https://cert-manager.io/docs/releases/upgrading/upgrading-1.18-1.19

Changelog: changed

Background

Certmanager 1.17 is EOL and does not match our supported K8s releases. By updating to 1.19 we jump to the latest supported version and align with our supported K8s releases.

⚠️ The upgrade has small potentially breaking changes (1, 2 which are not expected to break common usage with GitLab. Such small breaking changes caused by third-party dependencies is covered by the dependency statement in our breaking change policy: https://docs.gitlab.com/update/terminology/#third-party-dependencies.

Related issues

Relates #6257

Test Plan

1. Install GitLab with certmanager 1.17
2. Confirm certificates are issued as expected
3. Upgrade to GitLab with certmanager 1.19
4. Confirm TLS continues to work
5. Trigger a Certificate renew (cmctl renew --namespace gitlab --all)
6. Confirms certicates have been renewed and continue to work

Author checklist

For general guidance, please follow our Contributing guide.

Required

For anything in this list which will not be completed, please provide a reason in the MR discussion.

• Merge Request Title and Description are up to date, accurate, and descriptive.
• MR targeting the appropriate branch.
• MR has a green pipeline.
• Documentation created/updated.
• Tests added/updated, and test plan for scenarios not covered by automated tests.
• Equivalent MR/issue for omnibus-gitlab opened.

Reviewers checklist

• MR has a green pipeline on https://gitlab.com/gitlab-org/charts/gitlab.
• Consider downstream impact to the Operator, as per evaluating impact from changes to GitLab chart.

Approved as per #6257 (comment 3123863020)

@jtoto-gtl We didn't have KTLO updates for 2 weeks now, could you add that? Thank you!

Martin Brümmer (bdd693fb) at 27 Feb 09:10