install: add service monitor manifest #214
Conversation
|
@paulfantom: GitHub didn't allow me to request PR reviews from the following users: brancz. Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci-robot
added
the
size/S
|
/lgtm |
|
@brancz: changing LGTM is restricted to collaborators In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/approve |
openshift-ci-robot
added
the
approved
|
@abhinavdahiya could you also |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, brancz, paulfantom The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
the `manifests` directory on the bootstrap is used by the cluster-bootstrap to push to the cluster. `servicemonitor` for cvo was added by openshift#214 `servicemonitor` api is created by the cluster-monitoring-operator and therefore this causes the bootstrapping to get stuck until we get the monitoring operator running. This skips the `servicemonitor` in the bootstrap render as it is not required for the bootstrap cvo pod.
the `manifests` directory on the bootstrap is used by the cluster-bootstrap to push to the cluster. `servicemonitor` for cvo was added by openshift#214 `servicemonitor` api is created by the cluster-monitoring-operator and therefore this causes the bootstrapping to get stuck until we get the monitoring operator running. This skips the `servicemonitor` in the bootstrap render as it is not required for the bootstrap cvo pod.
the `manifests` directory on the bootstrap is used by the cluster-bootstrap to push to the cluster. `servicemonitor` for cvo was added by openshift#214 `servicemonitor` api is created by the cluster-monitoring-operator and therefore this causes the bootstrapping to get stuck until we get the monitoring operator running. This skips the `servicemonitor` in the bootstrap render as it is not required for the bootstrap cvo pod.
the `manifests` directory on the bootstrap is used by the cluster-bootstrap to push to the cluster. `servicemonitor` for cvo was added by openshift#214 `servicemonitor` api is created by the cluster-monitoring-operator and therefore this causes the bootstrapping to get stuck until we get the monitoring operator running. This skips the `servicemonitor` in the bootstrap render as it is not required for the bootstrap cvo pod.
the `manifests` directory on the bootstrap is used by the cluster-bootstrap to push to the cluster. `servicemonitor` for cvo was added by openshift#214 `servicemonitor` api is created by the cluster-monitoring-operator and therefore this causes the bootstrapping to get stuck until we get the monitoring operator running. This skips the `servicemonitor` in the bootstrap render as it is not required for the bootstrap cvo pod.
Since each team should own their monitoring configuration we are removing ServiceMonitor manifests from cluster-monitoring-operator.
Related to openshift/cluster-monitoring-operator#390
/cc @brancz @smarterclayton