Skip to content

[KCM-3698] Collections: Recommend against using idle 'share by cluster' #1180

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

biancaburtoiu
Copy link
Contributor

@biancaburtoiu biancaburtoiu commented Mar 28, 2025

Related Issue

https://apptio.atlassian.net/browse/KCM-3698

Proposed Changes

Add a note in public docs warning against using idle 'share by cluster' due to risk of potential cost inconsistencies.

Content to be published via manual migration to IBM docs. This PR is only for review purposes.

@biancaburtoiu biancaburtoiu requested a review from a team as a code owner March 28, 2025 17:54
Comment on lines 51 to 53
Costs in the Kubernetes domain have a corresponding idle component. For any Kubernetes costs part of a collection, the idle cost can be optionally configured to be _included_ in the total cost displayed. This can be done from the Settings page under Idle in Collections.

The idle cost can be shared by cluster or by node. We do not recommend sharing idle by cluster as that may lead to cost inconsistencies when deduplicating the Kubernetes costs against the cloud costs for the same resource. By default, idle costs are hidden.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nealormsbee
Copy link
Member

@kwombach12 it looks like Bianca addressed your feedback here, but she won't be allowed to merge until you formally approve. It's a side-effect of using the "Request Changes" formalism. Can you drop a ✅ if everything looks good to you now?

@biancaburtoiu
Copy link
Contributor Author

@nealormsbee - To my knowledge, these changes have to be manually applied on the IBM docs platform. This PR does, indeed, require an approval - although Kai has informally agreed to the proposed change already - but it should not need a merge.

@chipzoller
Copy link
Contributor

Correct, when everything here is approved I will have to (unfortunately) manually incorporate them in the new docs management tool (AEM).

@biancaburtoiu
Copy link
Contributor Author

@chipzoller - You have manually applied some documentation changes on my behalf already. You've also pointed to a process that potential doc editors would have to go through to be able to apply changes themselves, although there are some complications. Do you advise me to go through that process and make the changes myself, or are you willing to ship these changes again? On one hand it would be valuable for me to have access to avoid depending on others when I have new docs to push - e.g. this other piece on Collections, docs on the Builder in the near future - but at the same time I would not contribute as an owner, I would still have to raise my pieces for review. What do you think?

@chipzoller
Copy link
Contributor

I do think it would be valuable to get you onboard to AEM so you can help write docs and so if you wanted to start that process it'd be valuable. However, I'm glad to get these in on your behalf in the near term and until I've had a chance to do some knowledge transfer with all those who want to participate.

@biancaburtoiu
Copy link
Contributor Author

Thank you @chipzoller - then I will rely on you to transfer both the contents of this PR and of #1182 once they are approved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants