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

Add prometheus-operator app #7

Merged
merged 1 commit into from
Oct 10, 2019
Merged

Conversation

akosveres
Copy link
Contributor

  • The configuration for the prometheus-operator may change based on the
    cluster size, I could look in to what the posibilities are now or for a
    future version.

@akosveres
Copy link
Contributor Author

I might add, this is still WIP as I did not get a working installation as I believe I have issues on my cluster.

Copy link
Contributor

@andyjeffries andyjeffries left a comment

Choose a reason for hiding this comment

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

Other than setting it to a version where possible and adding the uninstall.sh, it's all good for me.

A better way might be to download those YAML files, concatenate them in to a single app.yaml and then it's easy to unapply the same file, then run the uninstall.sh (or just run the uninstall.sh?).

@@ -0,0 +1 @@
uninstall.sh
Copy link
Contributor

Choose a reason for hiding this comment

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

If you have an uninstall.sh (that takes no parameters), please feel free to commit it - this is exactly the mechanism we are going to be using to uninstall applications, other than just reversing the kubectl apply -f app.yaml if one exists.

kubectl apply -f https://raw.githubusercontent.com/coreos/prometheus-operator/master/example/prometheus-operator-crd/prometheus.crd.yaml
kubectl apply -f https://raw.githubusercontent.com/coreos/prometheus-operator/master/example/prometheus-operator-crd/prometheusrule.crd.yaml
kubectl apply -f https://raw.githubusercontent.com/coreos/prometheus-operator/master/example/prometheus-operator-crd/servicemonitor.crd.yaml
kubectl apply -f https://raw.githubusercontent.com/coreos/prometheus-operator/master/example/prometheus-operator-crd/podmonitor.crd.yaml
Copy link
Contributor

Choose a reason for hiding this comment

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

These should at least use versions of these files from a commit/release. Otherwise we have an unstable application in the marketplace (something breaks on master, customers install it here and it doesn't work, etc).

--name prometheus-operator \
--namespace ${NAMESPACE} \
--set prometheusOperator.createCustomResource=false \
stable/prometheus-operator
Copy link
Contributor

Choose a reason for hiding this comment

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

Likewise is there a way of using a particular version? I know it means maintenance work when it's time to upgrade, but at least it means we have a tested/known-working version.

---
name: prometheus-operator
title: "Prometheus Operator"
version: Stable
Copy link
Contributor

Choose a reason for hiding this comment

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

As above - version locking :-)

* The configuration for the prometheus-operator may change based on the
cluster size, I could look in to what the posibilities are now or for a
future version.
@akosveres
Copy link
Contributor Author

Other than setting it to a version where possible and adding the uninstall.sh, it's all good for me.

A better way might be to download those YAML files, concatenate them in to a single app.yaml and then it's easy to unapply the same file, then run the uninstall.sh (or just run the uninstall.sh?).

As requested addressed. Wasn't sure about the version as I can lock the helm chart version, not the app version. Or do we have a way of locking to the specific app version we want to install with helm (I don't have that much experience with helm)?

@andyjeffries
Copy link
Contributor

That's completely fine as you've done. We've not hopefully got a static version that should always work (may need upgrading, but less chance of it unexpectedly breaking one day). I'll merge it in. Just for next time, we tend to give about 10% total padding around the logos (e.g. 5% of image width either side). We go by feel, but that's a good starting point. I'll adjust the logo after merge. Thanks for doing this :-)

@andyjeffries andyjeffries merged commit 1d26925 into civo:master Oct 10, 2019
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

Successfully merging this pull request may close these issues.

2 participants