get cmdb returns hash ref and not hash

[VVelox]

trafficstars

This PR is an attempt to fix # by .

Checklist

• [X] based on top of latest source code
• [X] changelog entry included
• [X] tests pass in CI
• [X] git history is clean
• [ ] git commit messages are well-written

[ferki]

Oh, I noticed it now there's no issue this PR could close.

So for the sake of consistency, I'd like to take this chance to kindly link our Contributing guide, specifically the section about GitHub issues and pull requests.

In general, it is expected to open an issue before a PR, and the PR template to be filled out.

[ferki]

So I came back to this PR, and compiled a list of todos to enable merging this:

• [ ] Rebase on top of current default branch

  The default branch was merged back into this PR branch three times, instead of rebasing the PR branch on top of the default branch – which created a bit of a mess in the branch's git history I don't want to carry forward forever by merging back. I can do the rebase, and then push to this PR branch to clean that up.

  @VVelox: since the PR uses the master branch from your fork instead of a feature branch, that means I can push to your master branch – which might be unexpected for you. Please kindly confirm you are OK with that. If not, I can use a separate branch locally, but that's extra work. Next time it may be cleaner to use a feature branch in a fork to send PRs.

• [ ] Squash superfluous commits

  The last two non-merge commits may be squashed together, at least I don't see much value in keeping a separate commit for only fixing a typo in the previous commit in the context of a PR (where we can freely tidy up the history before merging). I can do that too.

• [ ] Deal with misformatted commit messages

  When pushing to this PR, I expect GitHub Actions to complain about the commit message formatting. Let's get to that point first before deciding what to do about that (accept the commit messages with a non-standard formatting, or fix them before merging). I can do that too :)

• [ ] Fix the same error around the proposed fix

  Finally, I can add a few follow-up commits on top to fix the same type of mistakes in related modules for the sake of completeness.

It's possible to do all of the above separately on my own, and due to the circumstances, I may end up doing it like that. But it would be nice to keep at least some of the original contribution work to give proper attribution even in the git commit history, so I'd like to give it at least a try to untangle it here.