Keel doesn't seem to be polling the images without a notification enabled

[wilmardo]

The title might be wrong but my suspicion is that Keel isn't polling without a notification enabled. In the logs I see that the watchers are made and I see the images as tacked in the webinterface. But there never appears a pending approval in the webinterface while there are newer images available upstream.

If my suspicion is correct, I would love a feature where I can approve changes in the webinterface.

Helm values:

---
# Default values for keel.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
image:
  repository: keelhq/keel
  tag: 0.15.0-rc2
  pullPolicy: IfNotPresent

# Enable insecure registries
insecureRegistry: false

# Polling is enabled by default,
# you can disable it setting value below to false
polling:
  enabled: true

# Helm provider support
helmProvider:
  enabled: false
  tillerNamespace: "kube-system"
  # optional Tiller address (if portforwarder tunnel doesn't work),
  # if you are using default configuration, setting it to
  # 'tiller-deploy:44134' is usually fine
  tillerAddress: ''

# Google Container Registry
# GCP Project ID
gcr:
  enabled: false
  projectId: ""
  clusterName: ""
  pubSub:
    enabled: false

# Notification level (debug, info, success, warn, error, fatal)
notificationLevel: info

# AWS Elastic Container Registry
# https://keel.sh/v1/guide/documentation.html#Polling-with-AWS-ECR
ecr:
  enabled: false
  accessKeyId: ""
  secretAccessKey: ""
  region: ""

# Webhook Notification
# Remote webhook endpoint for notification delivery
webhook:
  enabled: false
  endpoint: ""

# Slack Notification
# bot name (default keel) must exist!
slack:
  enabled: false
  botName: ""
  token: ""
  channel: ""
  approvalsChannel: ""

# Hipchat notification and approvals
hipchat:
  enabled: false
  token: ""
  channel: ""
  approvalsChannel: ""
  botName: ""
  userName: ""
  password: ""

mattermost:
  enabled: false
  endpoint: ""

# Basic auth on approvals
basicauth:
  enabled: true
  user: admin
  password: <nope>

# Keel service
# Enable to receive webhooks from Docker registries
service:
  enabled: true
  type: ClusterIP

# Webhook Relay service
# If you don’t want to expose your Keel service, you can use https://webhookrelay.com/
# which can deliver webhooks to your internal Keel service through Keel sidecar container.
webhookRelay:
  enabled: false
  bucket: ""
  # webhookrelay.com credentials
  # Set the key and secret values here to create the keel-webhookrelay secret with this
  # chart -or- leave key and secret blank and create the keel-webhookrelay secret separately.
  key: ""
  secret: ""
  # webhookrelay docker image
  image:
    repository: webhookrelay/webhookrelayd
    tag: latest
    pullPolicy: IfNotPresent

# Use a secret file to define passwords and tokens of third parties.
secret:
  # Leave blank to use `keel.fullname`
  name: ""
  # Set to false to manage your own secret file, with terraform for example.
  create: true

# Keel self-update
# uncomment lines below if you want Keel to automaticly
# self-update to the latest release version
keel:
  # keel policy (all/major/minor/patch/force)
  policy: patch
  # trigger type, defaults to events such as pubsub, webhooks
  trigger: poll
  # polling schedule
  # pollSchedule: "@every 3m"
  # images to track and update
  # images:
  #   - repository: image.repository
  #     tag: image.tag

# RBAC manifests management
rbac:
  enabled: true

# Resources
resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 50m
    memory: 64Mi

# NodeSelector
nodeSelector: {}

affinity: {}

tolerations: {}

# base64 encoded json of GCP service account
# more info available here: https://cloud.google.com/kubernetes-engine/docs/tutorials/authenticating-to-cloud-platform
# e.g. --set googleApplicationCredentials=$(cat <JSON_KEY_FIEL> | base64)
googleApplicationCredentials: ""

# Enable DEBUG logging
debug: false

# This is used by the static manifest generator in order to create a static
# namespace manifest for the namespace that keel is being installed
# within. It should **not** be used if you are using Helm for deployment.
createNamespaceResource: false

podAnnotations: {}

serviceAnnotations: {}
# Useful for making the load balancer internal
# serviceAnnotations:
#    cloud.google.com/load-balancer-type: Internal

aws:
  region: null

podDisruptionBudget:
  enabled: false
  maxUnavailable: 1
  minAvailable: null

# Google Cloud Certificates
gcloud:
  managedCertificates:
    enabled: false
    domains:
      - ""

ingress:
  enabled: true
  hosts:
    - host: test.test
      paths:
        - /

dockerRegistry:
  enabled: false
  name: ""
  key: ""

persistance:
  enable: false
  storageClass: "-"
  size: 1Gi

Keel log:

time="2019-09-09T13:45:48Z" level=info msg="extension.credentialshelper: helper registered" name=aws
time="2019-09-09T13:45:48Z" level=info msg="extension.credentialshelper: helper registered" name=gcr
time="2019-09-09T13:45:48Z" level=info msg="bot: registered" name=slack
time="2019-09-09T13:45:48Z" level=info msg="keel starting..." arch=amd64 build_date=2019-09-04T151710Z go_version=go1.12 os=linux revision=2e60104e version=0.15.0-rc2
time="2019-09-09T13:45:49Z" level=info msg="initializing database" database_path=/data/keel.db type=sqlite3
time="2019-09-09T13:45:49Z" level=info msg="extension.notification.auditor: audit logger configured" name=auditor
time="2019-09-09T13:45:49Z" level=info msg="notificationSender: sender configured" sender name=auditor
time="2019-09-09T13:45:49Z" level=info msg="provider.kubernetes: using in-cluster configuration"
time="2019-09-09T13:45:49Z" level=info msg="provider.defaultProviders: provider 'kubernetes' registered"
time="2019-09-09T13:45:49Z" level=info msg="extension.credentialshelper: helper registered" name=secrets
time="2019-09-09T13:45:49Z" level=info msg="bot.slack.Configure(): Slack approval bot is not configured"
time="2019-09-09T13:45:49Z" level=error msg="bot.Run(): can not get configuration for bot [slack]"
time="2019-09-09T13:45:49Z" level=info msg="trigger.poll.manager: polling trigger configured"
time="2019-09-09T13:45:49Z" level=info msg=started context=buffer
time="2019-09-09T13:45:49Z" level=info msg=started context=watch resource=deployments
time="2019-09-09T13:45:49Z" level=info msg="authentication enabled, setting up admin HTTP handlers"
time="2019-09-09T13:45:49Z" level=info msg=started context=watch resource=daemonsets
time="2019-09-09T13:45:49Z" level=info msg=started context=watch resource=statefulsets
time="2019-09-09T13:45:49Z" level=info msg=started context=watch resource=cronjobs
time="2019-09-09T13:45:49Z" level=info msg="webhook trigger server starting..." port=9300
time="2019-09-09T13:45:55Z" level=info msg="trigger.poll.RepositoryWatcher: new watch tag digest job added" digest="sha256:b9557bc811699bd43e9faaecd5dfc76b32a9435bf31cbf9f7e4885ccc3217aa6" image="linuxserver/nzbget:v21.0-ls24" job_name="index.docker.io/linuxserver/nzbget:v21.0-ls24" schedule="@every 10m"
time="2019-09-09T13:45:57Z" level=info msg="trigger.poll.RepositoryWatcher: new watch tag digest job added" digest="sha256:17cbfde5c1398b2db25a07c68a9fba96fca6f68caacad36a110afcdf7b61e1e5" image="linuxserver/sonarr:3.0.2.587-ls123" job_name="index.docker.io/linuxserver/sonarr:3.0.2.587-ls123" schedule="@every 1m"
time="2019-09-09T13:45:59Z" level=info msg="trigger.poll.RepositoryWatcher: new watch tag digest job added" digest="sha256:5872dab7e9e4342908411ca306b4db6bddb878cb609306c304109c7bfe2235c6" image="haugene/transmission-openvpn:2.7-alpine" job_name="index.docker.io/haugene/transmission-openvpn:2.7-alpine" schedule="@every 10m"

[rusenask]

Hello, none of these images seem to be using semver. If you are not using semver images, please use webhooks :) Otherwise it's just looking for the same linuxserver/nzbget:v21.0-ls24 tag with a new digest.

[wilmardo]

Thanks for the fast response! Was looking for the exact semver spec needed in the docs but it needs the whole tag as semver? These tags are semver before the dash ;)

Tried a bit further and now have annotated with:

  annotations:
    keel.sh/policy: "glob:3.*"
    keel.sh/force: "true"
    keel.sh/trigger: poll
    keel.sh/pollSchedule: "@every 1m"
    keel.sh/approvals: "1"

If I read the docs correctly this should match the tag 3.0.3.624-ls135 but it still does not show pending approvals. What am I missing?

[rusenask]

Registry polling only works with semver tags when it's clear that 3.1.0 > 3.0.0. When using glob, regex, force policies - you should use webhooks :) Which registry are you using?

[wilmardo]

Docker Hub but the those are community images, not made by me. For example: https://hub.docker.com/r/linuxserver/sonarr/tags

So I cannot setup webhooks to notify Keel. Is it an idea to introduce a semver regexp? To extract semver from a tag? For example plex does the same with some build-sha: https://hub.docker.com/r/plexinc/pms-docker/tags

[rusenask]

Ahh, good point, let's think about how to add it

[wilmardo]

Cool! Can I contribute in some way?

[wilmardo]

@rusenask Sorry to bother but I just remembered that this is the reason why I am editing all the configs by had :')

Is there any way how I could contribute to this issue?

[rusenask]

hey, no worries! :) Could you check whether dockerhub provides dates when the tags were pushed? If yes, we might be able to check the timing

[cilindrox]

Resurrecting this a bit, since I've got a similar use case. Seems the webhook payloads from Docker Hub include a push_data.pushed_at posix that can be used for comparison

[Ulrar]

Webhooks on dockerhub are only available for your own images, so you can't use that for community images like sonarr that was mentioned here