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

UCP: support monitor mount external configuration #2294

Merged
merged 72 commits into from
May 29, 2020

Conversation

mikechengwei
Copy link
Contributor

@mikechengwei mikechengwei commented Apr 26, 2020

What problem does this PR solve?

UCP: #2180
Close: #2180

What is changed and how does it work?

support monitor mount external config map.
user can create an external configMap contains prometheus-config and dashboard-config which replace default monitor config.

Check List

Tests

  • Unit test
  • E2E test

Code changes

  • Has Go code change

Side effects

None

@sre-bot
Copy link
Contributor

sre-bot commented Apr 26, 2020

Thanks for your contribution. If your PR get merged, you will be rewarded 100 points.

Copy link
Contributor

@Yisaer Yisaer left a comment

Choose a reason for hiding this comment

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

The whole structures seems LGTM. What about prometheus start args?

@mikechengwei
Copy link
Contributor Author

@Yisaer I think we can put the command configuration in the external configMap too.
for example

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-monitor
  labels:
    app.kubernetes.io/name: tidb-cluster
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/instance: test
    app.kubernetes.io/component: monitor
    helm.sh/chart: tidb-cluster-dev
data:
  prometheus-config: |-
  command-config: |-
  dashboard-config: |-

What do you think?

@Yisaer
Copy link
Contributor

Yisaer commented Apr 26, 2020

@Yisaer I think we can put the command configuration in the external configMap too.
for example

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-monitor
  labels:
    app.kubernetes.io/name: tidb-cluster
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/instance: test
    app.kubernetes.io/component: monitor
    helm.sh/chart: tidb-cluster-dev
data:
  prometheus-config: |-
  command-config: |-
  dashboard-config: |-

What do you think?

This LGTM. I think we could use a more easy understanding name for user instead of command-config.


// Config is the the desired state of Prometheus Configuration
type Configuration struct {
ExternalConfigMap string `json:"externalConfigMap,omitempty"`
Copy link
Contributor

@Yisaer Yisaer Apr 26, 2020

Choose a reason for hiding this comment

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

What about use ConfigMapRef here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

@Yisaer
Copy link
Contributor

Yisaer commented Apr 26, 2020

When this pr is merged, please also update the monitor document to show how to use this feature for community.

@Yisaer
Copy link
Contributor

Yisaer commented Apr 26, 2020

@mikechengwei It seems the document check failed in github action test. Please remove the ./output/bin/gen-crd-api-references-docs and re-execute the ./hack/update-crd-groups.sh.

Recently we have update the document tool.

@Yisaer Yisaer requested a review from yeya24 April 26, 2020 07:55
@@ -79,6 +79,13 @@ type PrometheusSpec struct {
Service ServiceSpec `json:"service,omitempty"`
// +optional
ReserveDays int `json:"reserveDays,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

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

@Yisaer Not related to this pr, but I am curious about this field. So we only support retention with unit d? Not support other time like h?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think you are right. Maybe we would create a new proper property for this in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have support custom command ,so I think reserveDays or other time field is not necessary.

"folder": "",
"name": "0",
"options": {
"path": "/grafana-dashboard-definitions/tidb"
Copy link
Contributor

@yeya24 yeya24 Apr 26, 2020

Choose a reason for hiding this comment

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

How to support additional dashboards for tidb monitor in this pr? We should support this as well

Copy link
Contributor

Choose a reason for hiding this comment

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

It seems we could also export grafana config in the configmap.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we support custom dashboards by configMap , we will need to append extra configMap to volumes and VolumeMounts . reference

VolumeMounts: []core.VolumeMount{
.
And I think users can dynamically add dashboard in Grafana.So, this feature is not important.

}
]
}
start-command: |-
Copy link
Contributor

@yeya24 yeya24 Apr 27, 2020

Choose a reason for hiding this comment

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

IMO the start-command is neither flexible nor scalable. A possible way is to do something like Prometheus-operator https://github.com/coreos/prometheus-operator/blob/87a7bea9f028c62396bef665f2887df326fa97f7/pkg/apis/monitoring/v1/types.go#L244. We can have a containers field in the tidb monitor spec. Then in the real generating phase, we do a patch to containers like here.

This approach is more recommended since it can help specify something other than the start commands for Prometheus, like env vars, volumes, etc

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have only support command field patch in container, other field patch I think is not important now.

@yeya24
Copy link
Contributor

yeya24 commented May 11, 2020

Any updates @mikechengwei

@mikechengwei
Copy link
Contributor Author

Sorry,I am busy recently. Now I will continue .

@mikechengwei
Copy link
Contributor Author

/merge @Yisaer can you help me merge this pr?

@Yisaer
Copy link
Contributor

Yisaer commented May 28, 2020

@mikechengwei Currently we are releasing the new version. so please update the base branch tonight or tomorrow. or you can enable the maintainer edit so that I can update the base branch myself when newly-releases finished.

@mikechengwei
Copy link
Contributor Author

I don't find button which enable the maintainer edit . I think be able to enable it only when creating pr . So you can tell me I will update branch myself. @Yisaer

@Yisaer
Copy link
Contributor

Yisaer commented May 29, 2020

/merge

@sre-bot
Copy link
Contributor

sre-bot commented May 29, 2020

/run-all-tests

@sre-bot
Copy link
Contributor

sre-bot commented May 29, 2020

@mikechengwei merge failed.

@mikechengwei
Copy link
Contributor Author

This e2e test error may not be caused by my code.

@Yisaer
Copy link
Contributor

Yisaer commented May 29, 2020

/merge

@sre-bot
Copy link
Contributor

sre-bot commented May 29, 2020

Your auto merge job has been accepted, waiting for:

  • 2445

@Yisaer
Copy link
Contributor

Yisaer commented May 29, 2020

@mikechengwei could you update the base branch? or you can enable maintainers edit like following.

image

@mikechengwei
Copy link
Contributor Author

image
@Yisaer

@mikechengwei
Copy link
Contributor Author

@Yisaer I have update base branch

@Yisaer
Copy link
Contributor

Yisaer commented May 29, 2020

/merge

@sre-bot
Copy link
Contributor

sre-bot commented May 29, 2020

/run-all-tests

@cofyc
Copy link
Contributor

cofyc commented May 29, 2020

I guess it's the limitation of Github. This feature requires the PR is from a user-owned repo, but your PR is from a team org.
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork

@cofyc
Copy link
Contributor

cofyc commented May 29, 2020

Maybe we can merge the PR onto the base branch in CI and don't require the PR branch to be up to date before merging. (ref: #396)

Because all PRs are merged by sre-bot sequentially, no broken state can happen on the master.

@mikechengwei
Copy link
Contributor Author

I agree, frequently up to date is a trouble

@sre-bot sre-bot merged commit 8ef0a99 into pingcap:master May 29, 2020
@sre-bot
Copy link
Contributor

sre-bot commented May 29, 2020

Congratulation! You have awarded a badge for usability challenge program! Please fill the form to get your reward! http://tidbcommunity.mikecrm.com/QMCv4QL

@sre-bot
Copy link
Contributor

sre-bot commented May 29, 2020

Team bigger complete task #2180 and get 300 score, current score 100

@sre-bot
Copy link
Contributor

sre-bot commented May 29, 2020

cherry pick to release-1.1 in PR #2594

Yisaer pushed a commit that referenced this pull request May 29, 2020
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.

UCP: support mount external prometheus configs in TidbMonitor
6 participants