Release v2.16.0

[jschmidt-icinga]

Aggregation of the changes in master since v2.15 was branched of. If anything is missing, please tell me.

I also need feedback on how (or if) to summarize the changes related to the REST API in the upgrading docs.

TODO

• Add remaining changes that get merged until release
• Update release date
• Add some detail for prominent new features
• Add some introductory text
• Properly add fixes from security releases prepared in private branches
• Re-categorize and polish
• Double-check no contributors were missed
• Finish upgrading docs

[oxzi]

The rest of the file uses * instead of + for list items.

[jschmidt-icinga]

Somehow overlooked this. Will change this on the next push.

[jschmidt-icinga]

• Moved the deprecated section.
• Added an initial version of the upgrading docs containing only a paragraph on the ElasticsearchWriter -> OTLPMetricsWriter migration and the user-defined Namespace deprecation so far.

Questions regarding the upgrading docs:

• Should I mention the other features deprecated earlier that are going to be removed in v2.18 and their migration paths?
• How much detail do we want on the REST API Changes? I'll have to look through the pull-requests again, but I think it's mostly that some commands now return errors for individual objects under several circumstances.
• Anything else relevant?

[julianbrost]

Should I mention the other features deprecated earlier that are going to be removed in v2.18 and their migration paths?

I'd avoid having incomplete lists in the sense that if there's a list, that should list all. But for the things that were deprecated previously, I wouldn't write much more than for example "IDO -> switch to Icinga DB", "ExternalCommandListener -> switch to REST API" (i.e. not going into much details).

How much detail do we want on the REST API Changes? I'll have to look through the pull-requests again, but I think it's mostly that some commands now return errors for individual objects under several circumstances.

Are you referring to the change that when responses are streamed, the HTTP status code can no longer reflect possible errors that happen later on?

[jschmidt-icinga]

Are you referring to the change that when responses are streamed, the HTTP status code can no longer reflect possible errors that happen later on?

It's not only when streaming, but also a 503 code being returned for individual objects when the wait group gets locked on shutdown. This also affects handlers that don't actually stream the results on the fly, like DeleteObjectHandler.

[yhabteab]

Can you please explain your exclusion process? Like, how do PRs in your eyes qualify to be mentioned in the Changelog? I've found here quite a bunch of PRs that IMHO should be mentioned in the Changelog, but they aren't. Also, there should be an introduction to the Changelog, stating that it is not a complete list of all changes, and referring to the milestone for a complete list of changes.

• #9411
• #10609
• #9728
• #9729
• #9730
• #9990
• #10350
• #10481
• #10493
• #10494
• #10499
• #10501
• #10513
• #10514
• #10528, #10561, #10749
• #10531
• #10550 (maybe?)
• #10552
• #10564
• #10619
• #10662
• #10664
• #10683
• #10686
• #10693
• #10702
• #10715
• #10716
• #10720, #10729
• #10726
• #10738
• #10745
• #10753
• #10756
• #10757
• #10767 (maybe?)
• #10776 (maybe?)

[yhabteab]

This also affects handlers that don't actually stream the results on the fly, like DeleteObjectHandler.

Aren't those changes already part of v2.15?

[jschmidt-icinga]

Can you please explain your exclusion process? Like, how do PRs in your eyes qualify to be mentioned in the Changelog?

User facing changes in the released part of the software.

So no fixed compiler warnings, documentation changes, CI-stuff, testing-stuff and things like that. While some previous version entries had "Code Quality Improvements" as a category, I personally don't think that's worthwhile, but I'm happy to add any of these categories back in if that's the consensus.

Also, there should be an introduction to the Changelog, stating that it is not a complete list of all changes, and referring to the milestone for a complete list of changes.

I can do that.

[yhabteab]

So no fixed compiler warnings, documentation changes, CI-stuff, testing-stuff and things like that.

Please re-check the list of PRs I provided above (I don't know why GitHub isn't rending the bullet points nicely with their titles - you can edit that comment of mine and go to the preview tab, and GitHub will render them pretty nice), but there is not a single PR about CI there. Compiler warnings, okay, must not be included, but why aren't docs PRs user facing changes? These changes will be rendered on icinga.com once v2.16 is released 🤷!

[julianbrost]

Are you referring to the change that when responses are streamed, the HTTP status code can no longer reflect possible errors that happen later on?

It's not only when streaming, but also a 503 code being returned for individual objects when the wait group gets locked on shutdown. This also affects handlers that don't actually stream the results on the fly, like DeleteObjectHandler.

A quick mention of that, like briefly saying that there are now new cases where errors will be reported for individual objects and that it's a good idea to check those as well would be helpful. Just don't write the part on the streamed responses in a way that would suggest there was no use for checking individual object errors in other cases.

[yhabteab]

Are you referring to the change that when responses are streamed, the HTTP status code can no longer reflect possible errors that happen later on?

It's not only when streaming, but also a 503 code being returned for individual objects when the wait group gets locked on shutdown. This also affects handlers that don't actually stream the results on the fly, like DeleteObjectHandler.

A quick mention of that, like briefly saying that there are now new cases where errors will be reported for individual objects and that it's a good idea to check those as well would be helpful. Just don't write the part on the streamed responses in a way that would suggest there was no use for checking individual object errors in other cases.

#10760 (comment)?

[julianbrost]

This also affects handlers that don't actually stream the results on the fly, like DeleteObjectHandler.

Aren't those changes already part of v2.15?

Missed that comment. Well if that's not new at all, no need to mention it as a new change, obviously.

[jschmidt-icinga]

@yhabteab

Somehow missed this one, likely because I confused it with the check_smart addition:

• ITL: Enhanced SMART attributes monitoring plugin check configuration to more parameters #10564

For these I was still waiting for a clear indicator that they will get merged when I last went over the list:

• IcingaDB: better config and state update queueing #10619
• Add a check command for NETGEAR monitoring #10753
• CpuBoundWork#CpuBoundWork(): don't spin on atomic int to acquire slot #9990
• SELinux: allow to query attrs of a filesystem #10726

On the others, unless I've missed any other bugfixes among those, the rest should only be code-quality improvements and documentation. I'm happy to add categories for both of those and probably will now, unless anybody shares in the opinion that that would be too verbose.

PS: You might want to try + for lists in markdown instead of - and *. It works a bit better in most cases and confuses fewer parsers. (Also it is shared syntax with org, which is 99% of why I always use it.)

[yhabteab]

On the others, unless I've missed any other bugfixes among those, the rest should only be code-quality improvements and documentation.

I didn't fully check the list again, but these two clearly arn't just docs changes.

• Add plain fping CheckCommand to ITL #10494
• Remove clear variable from disk CheckCommand #10531

PS: You might want to try + for lists in markdown instead of - and *. It works a bit better in most cases and confuses fewer parsers. (Also it is shared syntax with org, which is 99% of why I always use it.)

That didn't help! See my original list of PRs even after editing.

[jschmidt-icinga]

• I've added the remaining PRs under a single bullet point per subcategory (docs, code quality, testing, build) to a new Miscellaneous category.
• Upgrading docs now mentions all deprecated features. I've left out the API changes as discussed in Teams, due to them being very minor edge cases.

Is there anything else to consider for the upgrading docs?

[Al2Klimov]

I consider this a breaking change or deprecation.

[Al2Klimov]

Consider 2.16.0.

[jschmidt-icinga]

• As suggested by @Al2Klimov I've added a commit that changes the version number and renamed the PR Title to reflect the change in scope. This seemed reasonable, since for previous releases we've also updated both the changelog and version number in one PR.
• Moved the Chocolatey thing to deprecations. Kept it in a separate commit for now, but will squash it down if everyone is happy with that.