Skip to content
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

RFE: Add a new Xready field to the CR status to indicates its ready for consumption. #2

Open
Madhu-1 opened this issue May 27, 2024 · 2 comments

Comments

@Madhu-1
Copy link
Collaborator

Madhu-1 commented May 27, 2024

          I usually see phase/message/reason in resource Conditions, but it seems to me that Conditions have been going out of vogue. I think this is probable because they are incredibly hard to deal with in code and user scripts compared to having typed fields for status.

Many of the recent sig-storage KEPs use a someResourceReady: bool (e.g., bucketReady: bool, snapshotReady: bool) as well, so that users can know with a boolean whether their resource is ready.

Personally, I don't have a preference between message and reason. Both are alphabetically close to phase which should mean users see the outputs near each other as status items are added.

But I would suggest some sort of xReady bool that indicates when config is ready.

Originally posted by @BlaineEXE in #1 (comment)

iamniting pushed a commit to iamniting/ceph-csi-operator that referenced this issue Jul 12, 2024
sync downstream with upstream main
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the wontfix This will not be worked on label Oct 17, 2024
@nb-ohad
Copy link
Collaborator

nb-ohad commented Oct 20, 2024

@Madhu-1 We need to reopen the discussion about the status section on our CR. As the status section is user-facing, I think we need to do some research and thinking. Existing designs used in some of our other projects proved to create pain points, and I will object to a "copy-paste" approach without having a discussion first.

@github-actions github-actions bot removed the wontfix This will not be worked on label Oct 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants