Skip to content

Support multi disk space #18413

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

Conversation

polarbear567
Copy link
Contributor

No description provided.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 29, 2019
@polarbear567
Copy link
Contributor Author

polarbear567 commented Sep 29, 2019

Hi, @philwebb It will show up like this:

{
  "status":"UP",
  "components": {
    "diskSpace": {
      "status":"UP","
      details": {
        "/etc": {
          "total":499963174912, "free":391009861632
        }, 
        "/bin":{
          "total":499963174912,"free":391009861632
        },
        "threshold":10485760}
  },
  "ping":{"status":"UP"}}}

I don't know what you want to show, but it's completely modifiable, such as the definition of the key in some maps. Maybe you can give some advice?

@philwebb
Copy link
Member

philwebb commented Sep 29, 2019

In order to remain back compatible we'll probably need to leave the existing "total", "free" and "threshold" values at the root. I think we should probably provide a further breakdown for the individual files. Something like:

{
  "status" : "UP",
  "components" : {
    "diskSpace" : {
      "status" : "UP",
      "details" : {
        "total" : 123,
        "free" : 123,
        "threshold" :123,
        "paths" : {
          "/etc" : {
            "total" : 123,
            "free" : 123
          },
          "/bin" : {
            "total" : 123,
            "free" : 123
          }
        }
    }
 }

@philwebb
Copy link
Member

philwebb commented Sep 29, 2019

incidentally, I'm afraid we had some issues with the repository over the weekend so you might need to rest your local branch and do a force push. Something like this:

$ git checkout feature/support_multi_disk
$ git reset --hard upstream/master
$ git cherry-pick bb5b359eb6db680baa297f13910d6a9345303e06
$ git push origin feature/support_multi_disk -f

Sorry about that.

@polarbear567
Copy link
Contributor Author

@philwebb Got it, I'm going to rewrite PR in your format. I'm surprised at the repository issue. I've submitted a branch before, but it's also happening :), and I'll try these git commands you gave me.
Thanks for the advice.

@polarbear567 polarbear567 force-pushed the feature/support_multi_disk branch from bb5b359 to f82020b Compare September 30, 2019 12:42
@polarbear567
Copy link
Contributor Author

polarbear567 commented Sep 30, 2019

Hi, @philwebb Now the format will like this:

{
    "status":"UP",
    "components":{
        "diskSpace":{
            "status":"UP",
            "details":{
                "total":499963174912,
                "free":392189550592,
                "threshold":10485760,
                "paths":{
                    "/etc":{
                        "total":499963174912,
                        "free":392189550592
                    },
                    "/bin":{
                        "total":499963174912,
                        "free":392189550592
                    }
                }
            }
        },
        "ping":{
            "status":"UP"
        }
    }
}

When the user opens the port, the project root path to disk information will be displayed by default. If the user configures the management.health.diskspace.path, the path disk information will be displayed under the paths node.

Another question I have is, do we need to consider how users configure project root paths in management.health.diskspace.path (not ".", like this: /Users/xxx/project /yyy/.)? This way, the disk information of the root path will be displayed twice in the result, once under the details node and once under the path node, although I don't think it should cause any misunderstanding.

@wilkinsona
Copy link
Member

As suggested by @eddumelendez in #18359 (comment), I think we should consider allowing the threshold to be configured on a per-path basis. That'll require a bit of thought to maintain backwards compatibility in the properties.

@wilkinsona wilkinsona added for: team-attention An issue we'd like other members of the team to review status: pending-design-work Needs design work before any code can be developed type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 29, 2019
@polarbear567
Copy link
Contributor Author

I will continue to fix it here, if you have any good ideas :)

@philwebb philwebb added for: merge-with-amendments Needs some changes when we merge and removed for: team-attention An issue we'd like other members of the team to review status: pending-design-work Needs design work before any code can be developed labels Dec 13, 2019
@philwebb philwebb added this to the 2.3.x milestone Dec 20, 2019
@mbhave mbhave self-assigned this Jan 29, 2020
@mbhave
Copy link
Contributor

mbhave commented Jan 30, 2020

@polarbear567 Thank you for your work on this PR. We discussed this at length on our team call and it appears that there isn't a good way to support this without making a breaking change. The total, free and threshold keys at the top level do not really mean anything when multiple paths are configured. Those cannot always represent the root path because the user might have configured management.health.diskspace.path to a different value and might not want the root path to contribute to the health status.

Given that this isn't a widely requested feature, we don't think it justifies a breaking change at this time. I'll leave the original issue open so that we can consider it in the future. Thanks again.

@mbhave mbhave closed this Jan 30, 2020
@mbhave mbhave added status: declined A suggestion or change that we don't feel we should currently apply and removed for: merge-with-amendments Needs some changes when we merge type: enhancement A general enhancement labels Jan 30, 2020
@mbhave mbhave removed their assignment Jan 30, 2020
@mbhave mbhave removed this from the 2.3.x milestone Jan 30, 2020
@polarbear567 polarbear567 deleted the feature/support_multi_disk branch November 23, 2021 03:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants