For example in the UptimeRobotMonitor CRD the field alertContacts is a string... what should go here? I ran the curl request to get my monitors and it returns a JSON object, do I use id, friendlyName or the full object?

curl -X POST \
  -H "Cache-Control: no-cache" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d 'api_key=<redacted>&format=json' \
"https://api.uptimerobot.com/v2/getAlertContacts"

{
  "stat": "ok",
  "offset": 0,
  "limit": 50,
  "total": 3,
  "alert_contacts": [
    {
      "id": "<redacted>",
      "friendly_name": "<redacted>@gmail.com",
      "type": 2,
      "status": 1,
      "value": "<redacted>@gmail.com"
    },
    {
      "id": "<redacted>",
      "friendly_name": "Discord",
      "type": 11,
      "status": 2,
      "value": "https://discord.com/api/webhooks/<redacted>/slack"
    },
    {
      "id": "<redacted>",
      "friendly_name": "Phone",
      "type": 13,
      "status": 2
    }
  ]
}

This is pretty vague for the other fields too, not just alertContacts.

Hi

Thanks a lot for this useful tool!

I tried to add a monitor for a Port:

---
apiVersion: uroperator.brennerm.github.io/v1beta1
kind: UptimeRobotMonitor
metadata:
  name: MYNAME
  namespace: MYNAME
spec:
  friendlyName: "K8S MYNAME"
  url: "MYHOSTNAME"
  type: PORT
  sub_type: "Custom Port"
  port: 22
  interval: 300

This gives me the following error (I'm using Flux v2):

error validating data: ValidationError(UptimeRobotMonitor.spec): unknown field "sub_type" in io.github.brennerm.uroperator.v
1beta1.UptimeRobotMonitor.spec;

If I remove sub_type it passes validation but gets rejected by the UptimeRobot API:

[2021-06-03 09:42:24,986] kopf.objects         [ERROR   ] [MYNAME/MYNAME] Handler 'on_create' failed permanently: failed to create monitor: {'type': 'missing_parameter', 'parameter_name': 'sub_type', 'message': 'sub_type parameter │
│  is missing.'}

According to the API Documentation, sub_type is normally optional, but required for port monitoring.

I use version 0.3.0.

Some users may not want to have monitors created for their Ingress resources but only create monitors using UptimeRobotMonitor resources. That's why there should be a flag to disable the monitoring of ingresses.

Hi there,

I've been trying to create a new Uptime monitor using the following YAML but I'm getting a validation error stating that the httpAuthSecret field is unknown.

My YAML:

apiVersion: uroperator.brennerm.github.io/v1beta1
kind: UptimeRobotMonitor
metadata:
  name: my-application-monitor
  namespace: public
spec:
  url: "https://exampledomain.com"
  type: HTTPS
  interval: 300
  friendlyName: "My Application Monitor"
  alertContacts: "1234_0_0"
  httpAuthType: BASIC_AUTH
  httpAuthSecret: auth-secret

My create command and error:

$ k create -f uptime-monitor-crd.yaml
error: error validating "uptime-monitor-crd.yaml": error validating data: ValidationError(UptimeRobotMonitor.spec): unknown field "httpAuthSecret" in io.github.brennerm.uroperator.v1beta1.UptimeRobotMonitor.spec; if you choose to ignore these errors, turn validation off with --validate=false

I've installed the operator using Helm by cloning the repository and doing it locally, as the steps listed in the installation steps were failing (I've added that snippet below but that's a different issue).

$ helm repo add uptimerobot-operator https://brennerm.github.io/uptimerobot-operator/helm
$ helm upgrade --install uptimerobot-operator uptimerobot-operator --set uptimeRobotApiKey=1234
Release "uptimerobot-operator" does not exist. Installing it now.
Error: failed to download "uptimerobot-operator" (hint: running `helm repo update` may help)

Am I doing something wrong perhaps? If there's additional information I can provide to you please let me know.

I was reviewing your Github workflow and I see you are not building multi-arch images. It's pretty easy to do using the following Github actions:

• https://github.com/docker/setup-qemu-action
• https://github.com/docker/setup-buildx-action

I can try to open a PR if you want :)

👋🏼 It would be cool if you could post the CRDs as YAML to this repo. I am assuming that they are created by kopf when the operator is deployed.

This is kind of an issue when you want to bootstrap a cluster and the CRDs are not present before Flux gets to installed uptimerobot-operator and your manifests for monitoring. It's kind of a chicken and egg situation. Flux will try to install the custom uroperator manifests but not see any CRDs because uptimerobot-operator is not installed quite yet.

I would like to apply the CRDs in a way that forces them to exist before the uptimerobot-operator and my manifests are installed.

Thanks!

To be able retrieve the state of a single UpimeRobotMonitor resource we should send Kubernetes events that indicate whether the creation/update of a monitor at UptimeRobot was successful or failed.