Update release notes draft to version v1.34.0-alpha.2

[Urvashi0109]

What type of PR is this?
/kind documentation

What this PR does / why we need it:
This PR updates the Release Notes Draft to k/k v1.34.0-alpha.2

Which issue(s) this PR fixes:

Special notes for your reviewer:
This is an automated PR generated from krel The Kubernetes Release Toolbox

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Urvashi0109
Once this PR has been reviewed and has the lgtm label, please assign fsmunoz for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• releases/release-1.34/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Vyom-Yadav]

@michellengnx @Urvashi0109 @ArvindParekh I'm confused about the procedure the docs team is following for generating/editing release notes, can y'all please clarify/correct me on that.

In this PR, the following release note has been edited using a map file: https://github.com/kubernetes/sig-release/pull/2809/files#diff-8b2e03503a6361c4c7c386629b92cbf09c0ab36eb95b21c2d50162d124d870e6

i.e.

pr: 132305
releasenote:
  text: Changed Job controller to use the controller UID index for Pod lookups to improve performance.
pr_body: ""

However, looking at both json and md file in this PR:

  "132305": {
    "commit": "8f1f17a04f62ab64ebe4f0b9d7f5f799bf56a0d9",
    "text": "Job controller used the controller UID index for Pod lookups.",
    "markdown": "Job controller used the controller UID index for Pod lookups. ([#132305](https://github.com/kubernetes/kubernetes/pull/132305), [@xigang](https://github.com/xigang))",
    "author": "xigang",
    "author_url": "https://github.com/xigang",
    "pr_url": "https://github.com/kubernetes/kubernetes/pull/132305",
    "pr_number": 132305,
    "kinds": [
      "cleanup"
    ],
    "sigs": [
      "apps"
    ],
    "is_mapped": true
  },

- Job controller used the controller UID index for Pod lookups. ([#132305](https://github.com/kubernetes/kubernetes/pull/132305), [@xigang](https://github.com/xigang))

I think the actual markdown/json file should have these changes as well. I know when you do alpha 3, these changes would be reflected then. The tool would pickup the notes file and update the md and json, but I don't think that is correct as that makes alpha2 notes not up to date.

I'm also not sure if we should be directly updating the md and json file (without a corresponding map). I'm unsure if that has some side affects (technically I don't think there will be, but still).

I was looking at a few past v1.33 PRs as well, and I've noticed this pattern there as well i.e. a maps file was added but the json and md weren't updated again and then in the next subsequent release cuts when krel was run again, it updated json and md to reflect those changed files in the last release notes. Which I don't think is correct.

I think the correct procedure to follow is: https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/docs/editing-flow.md

(I fully understand that editing files using a CLI might not be what everyone is used to and this should be clearer. I see maps as patches that are applied to edit the source release notes file)

[Vyom-Yadav]

In the krel logic I see the function fixReleaseNotes: (which is triggered by the --fix flag)

https://github.com/kubernetes/release/blob/3c696bde3c0cf41421ba18269641fc819b3b2501/cmd/krel/cmd/release_notes.go#L1214-L1222

		if noteMaps != nil {
			fmt.Println("✨ Note contents was previously modified with a map")

			for _, noteMap := range noteMaps {
				if err := note.ApplyMap(noteMap, true); err != nil {
					return fmt.Errorf("applying notemap for PR #%d: %w", pr, err)
				}
			}
		}

But I think this should be something in the linter rather than something for the next release notes PR. This is also an item on how to improve the experience with krel (or just even log that somewhere) so we can be more accurate.

[rashansmith]

https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/docs/editing-flow.md

Hey @Vyom-Yadav! These are great questions around the krel editing process. We currently use the cli to create the PRs, and also follow the editing flow guide. We should bring this topic up in the Release Notes channel for more insight into why this current flow exists, and maybe what we can do to improve it. I'll also tag @npolshakova @puerco @ramrodo @fsmunoz as well here for input, and remember to add this as a release retro item for continued discussion.

In the meantime, to keep the release notes drafts on schedule, I would recommend to continue with the PR approval process, unless this is viewed as something to be resolved immediately. Let me know if you have any questions!

[Vyom-Yadav]

Hey @rashansmith

Map != Release Note md/json. That is a blocking thing in my opinion. Alpha 2 release notes should be reflect the changes made for alpha 2 which is not the case right now as I mentioned in the above comment.

To move ahead with this PR, I'd recommend just running krel once more with --fix so that the current map changes are propagated to the markdown and json.

I'm ok with discussing the matter of directly editing md/json later.

[wendy-ha18]

This PR is LGTM except what @Vyom-Yadav pointed out about the updates in individual map PRs didn't reflect in release-notes-draft.json and release-notes-draft.md.

If we have a look in release notes draft to version v1.34.0-alpha.1, we can see how the next PR (which is the one) updates the Json and Mardown file.