Add changelog for release v0.44.0

[lunkan93]

Warning

This is a public repository, ensure not to disclose:

• personal data beyond what is necessary for interacting with this pull request, nor
• business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• kind/feature
• kind/improvement
• kind/deprecation
• kind/documentation
• kind/clean-up
• kind/bug
• kind/other

Optional: Mark one or more of the following that are applicable:

Important

Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

• kind/admin-change
• kind/dev-change
• kind/security
• [kind/adr](set-me)

What does this PR do / why do we need this PR?

...

• Fixes #

Information to reviewers

Checklist

• Proper commit message prefix on all commits
• Change checks:
  • The change is transparent
  • The change is disruptive
  • The change requires no migration steps
  • The change requires migration steps
  • The change updates CRDs
  • The change updates the config and the schema
• Documentation checks:
  • The public documentation required no updates
  • The public documentation required an update - [link to change](set-me)
• Metrics checks:
  • The metrics are still exposed and present in Grafana after the change
  • The metrics names didn't change (Grafana dashboards and Prometheus alerts required no updates)
  • The metrics names did change (Grafana dashboards and Prometheus alerts required an update)
• Logs checks:
  • The logs do not show any errors after the change
• PodSecurityPolicy checks:
  • Any changed Pod is covered by Kubernetes Pod Security Standards
  • Any changed Pod is covered by Gatekeeper Pod Security Policies
  • The change does not cause any Pods to be blocked by Pod Security Standards or Policies
• NetworkPolicy checks:
  • Any changed Pod is covered by Network Policies
  • The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • The change does not cause any unnecessary Kubernetes audit events
  • The change requires changes to Kubernetes audit policy
• Falco checks:
  • The change does not cause any alerts to be generated by Falco
• Bug checks:
  • The bug fix is covered by regression tests

[simonklb]

I realize that the release process isn't clear on this but I think that if something as big as having to upgrade a component is found as a release blocker it should be made as a separate PR.

Otherwise the review process risks being compromised just to get the release out the door.

Honestly, I'd like to see us change our release process in a way where all fixes are made on main and backported to the release branch. @aarnq WDYT?

[anders-elastisys]

Nice that this is finally addressed! 🙌

[anders-elastisys]

Do we maybe want to highlight more things for this release? E.g. addition of GPU operator chart

[lunkan93]

I realize that the release process isn't clear on this but I think that if something as big as having to upgrade a component is found as a release blocker it should be made as a separate PR.

Otherwise the review process risks being compromised just to get the release out the door.

Honestly, I'd like to see us change our release process in a way where all fixes are made on main and backported to the release branch. @aarnq WDYT?

I do agree with what you're saying, the problem that prompted this was discussed with @aarnq and we decided that the best course of action would be to upgrade, as it was a relatively small one, and the bug it fixes had potential to be pretty bad.

Unfortunately @aarnq is away so he can't weigh in, and it is quite important that this release is finished this week. I agree that we should probably have a process in place for how we handle these types of outliers where an actual upgrade is needed.

Tagging some people to get more thoughts on this @viktor-f @OlleLarsson @davidumea @Xartos

[simonklb]

I realize that the release process isn't clear on this but I think that if something as big as having to upgrade a component is found as a release blocker it should be made as a separate PR.
Otherwise the review process risks being compromised just to get the release out the door.
Honestly, I'd like to see us change our release process in a way where all fixes are made on main and backported to the release branch. @aarnq WDYT?

I do agree with what you're saying, the problem that prompted this was discussed with @aarnq and we decided that the best course of action would be to upgrade, as it was a relatively small one, and the bug it fixes had potential to be pretty bad.

Unfortunately @aarnq is away so he can't weigh in, and it is quite important that this release is finished this week. I agree that we should probably have a process in place for how we handle these types of outliers where an actual upgrade is needed.

Tagging some people to get more thoughts on this @viktor-f @OlleLarsson @davidumea @Xartos

If it has been cleared by @aarnq I'm fine with going ahead with this! Food for thought though. Releases should not feel rushed, especially if we allow fixes instead of backports.

Dismissing so that I don't block if it gets approved before I have the time to review it.

[davidumea]

I realize that the release process isn't clear on this but I think that if something as big as having to upgrade a component is found as a release blocker it should be made as a separate PR.
Otherwise the review process risks being compromised just to get the release out the door.
Honestly, I'd like to see us change our release process in a way where all fixes are made on main and backported to the release branch. @aarnq WDYT?

I do agree with what you're saying, the problem that prompted this was discussed with @aarnq and we decided that the best course of action would be to upgrade, as it was a relatively small one, and the bug it fixes had potential to be pretty bad.
Unfortunately @aarnq is away so he can't weigh in, and it is quite important that this release is finished this week. I agree that we should probably have a process in place for how we handle these types of outliers where an actual upgrade is needed.
Tagging some people to get more thoughts on this @viktor-f @OlleLarsson @davidumea @Xartos

If it has been cleared by @aarnq I'm fine with going ahead with this! Food for thought though. Releases should not feel rushed, especially if we allow fixes instead of backports.

I think that fixes being done on main and backported to the release is better, to get it properly reviewed. Great suggestion 👍

I think it's fine to do the upgrade here in this case since we don't have any process in place for doing it differently.

Releases should not feel rushed

Unfortunately there were some pressure from other parties for a feature in this release to be available next week, so this time we were a bit rushed.