profile
viewpoint
Benoit Gagnon bgagnon Ubisoft Entertainment Montreal Technical Architect @ Ubisoft Montreal

jsonnet-bundler/jsonnet-bundler 232

A jsonnet package manager.

bgagnon/blackbox_exporter 0

Blackbox prober exporter

bgagnon/contour 0

Contour is a Kubernetes ingress controller using Lyft's Envoy proxy.

bgagnon/dockbeat 0

Dockbeat - the elastic Beat for docker daemon monitoring

bgagnon/jsonnet-bundler 0

A jsonnet package manager.

bgagnon/kube-prometheus 0

Use Prometheus to monitor Kubernetes and applications running on Kubernetes

bgagnon/kubernetes-mixin 0

A set of Grafana dashboards and Prometheus alerts for Kubernetes.

bgagnon/metacontroller 0

Lightweight Kubernetes controllers as a service

issue commentkubernetes/cloud-provider-openstack

Missing git tags for v1.18.1, v1.18.2

Related issue: #1184

bgagnon

comment created time in 4 days

issue openedkubernetes/cloud-provider-openstack

Missing git tags for v1.18.1, v1.18.2

According to the release procedure, Git tags should be pushed to GitHub before the container images are pushed to DockerHub.

On https://hub.docker.com/r/k8scloudprovider/openstack-cloud-controller-manager/tags, there are Docker image tags for v1.18.1 and v1.18.2 but no tags in Git.

Furthermore, there are no Docker LABEL entries on the images themselves that could help identify the Git SHA1 that was used to build them.

created time in 4 days

startedpulumi/pulumi-kubernetesx

started time in 5 days

issue commentrancher/rancher

Ability to add labels and annotations at node pool and node template level.

Another concrete use case for this is to set the node.kubernetes.io/exclude-from-load-balancer=true label on nodes which influences their inclusion/exclusion from a load balancer pool. This requires feature flag ServiceNodeExclusion which is Alpha in K8S <1.18 and Beta in 1.18+.

Without this feature in Rancher, nodes need to be labeled after they are provisioned by Rancher (eg. via a DaemonSet), which introduces a race condition of them being included in the load balancer pool only to be removed later.

sangeethah

comment created time in 6 days

startednfrumkin/forecast-prometheus

started time in 6 days

issue openedprymitive/karma

Ability to shorten/disable collapse animations

The fadeouts and collapse animation are great, but are a little slow. Once you get accustomed to the UI and want it to be reactive, the animations cause friction.

created time in 10 days

startedguyta-essence/rna

started time in 18 days

issue openedForkIssues/Tracker

Search does not consider lost commits (reflog)

When View > Show Lost Commits (reflog) is active, I would expect commit search to include those lost commits in the results. It does not seem like it does that in the current version (1.0.98.4).

created time in a month

issue commentrancher/terraform-provider-rancher2

Cannot clear rke_config.cloud_provider.openstack_config from Terraform

For reference, support for external cloud provider was added in #364 and resolved #319

bgagnon

comment created time in a month

issue openedrancher/terraform-provider-rancher2

Cannot clear rke_config.cloud_provider.openstack_config from Terraform

Assuming this starting Terraform resource:

resource "rancher2_cluster" "default" {
  name = var.cluster_name

  rke_config {
    kubernetes_version = "v1.17.5-rancher1-1"

    cloud_provider {
      name = "openstack"
      openstack_cloud_provider {
        global {
          auth_url    = var.os_auth_url
          region      = var.os_region_name
          domain_name = "Default"
          tenant_name = var.os_tenant_name
          tenant_id   = ""
          username    = var.os_username
          password    = var.os_password
        }

        load_balancer {
          use_octavia = true
          monitor_max_retries = 0
          monitor_delay   = "0s"
          monitor_timeout = "0s"
        }
      }
    }
}

transitioning to:

resource "rancher2_cluster" "default" {
  name = var.cluster_name

  rke_config {
    kubernetes_version = "v1.17.5-rancher1-1"

    cloud_provider {
      name = "external"
    }
}

the Terraform plan is as expected, clearing every field in rke_config.cloud_provider.openstack_config:

          ~ cloud_provider {
               ~ name = "openstack" -> "external"
              - openstack_cloud_provider {
                  - block_storage {
                      - ignore_volume_az  = false -> null
                      - trust_device_path = false -> null
                    }
                  - global {
                      - auth_url    = "<redacted>" -> null
                      - domain_name = "Default" -> null
                      - region      = "<redacted>" -> null
                      - tenant_name = "<redacted>" -> null
                      - username    = (sensitive value)
                    }
                  - load_balancer {
                      - create_monitor         = false -> null
                      - manage_security_groups = false -> null
                      - monitor_delay          = "0s" -> null
                      - monitor_max_retries    = 0 -> null
                      - monitor_timeout        = "0s" -> null
                      - use_octavia            = true -> null
                    }
                  - metadata {}
                  - route {}
                }
            }

After the operation however, the API object on the Rancher side still contains the unmodified openstack_cloud_provider contents.

A subsequent terraform plan shows the exact same changes (except cloud_provider.name which sticks), creating an infinite loop.

Editing the cluster YAML from the Rancher UI is the only way I have found to strip the unwanted openstack_cloud_provider attribute block. Even so, it merely replaces the values by their default; the object sticks around.

created time in a month

startedplanetlabs/kostanza

started time in a month

issue commentprojectcontour/contour

Support Access Log Service (ALS)

FWIW, for our use case, we don't need this to be configurable at the HTTPProxy or route level -- we'd be satisfied with a global ALS config in Contour's YAML config, for example.

But if we can leverage ExtensionService for a more dynamic experience, that's cool too. Our current implementation works like this:

  • HttpConnectionManager is updated on the :80 and :443 listeners through an LDS proxy
  • the ALS cluster is statically injected in the Envoy bootstrap config, and has single cluster member (127.0.0.1, since it's a sidecar) -- no EDS or DNS needed

Now, for status propagation all the way to the HTTPProxy.status objects, I'm not sure exactly how that would work. For one thing, it's Envoy that talks to the gRPC ALS service, not Contour. Any errors sending logs to it would be visible only from Envoy logs and/or metrics.

Are you thinking that Contour would initiate its own gRPC checks against the ALS service before handing it off to Envoy? Does it do that just once or continuously? Would the fallback to STDOUT also be dynamic?

If Contour really wants to go down that path...

  • Contour would ship its own ALS sidecar for Envoy
  • this ALS server would output to STDOUT unless given a working destination, in which case it can forward the gRPC messages verbatim
  • the status can be reflected in the HTTPProxy

IMO, it's a lot of moving parts, and likely out of scope for Contour.

bgagnon

comment created time in a month

issue commentprojectcontour/contour

Tracing Configuration

I'm not sure if this should be a global Contour config, a global default overridable in HTTPProxy, or a per HTTPproxy virtualhost config. I'd love to hear from people using this right now what you'd prefer.

Per-namespace is how I would envision it for our use case (multi-tenant cluster). Variations I can think of at the namespace level:

  • on/off switch
  • sampling controls
  • destination jaeger receiver -- since jaeger isn't multi-tenant aware, we'll likely have a receiver in every namespace
  • static tags on traces -- if Envoy allows such thing; otherwise I believe the receiver can handle that

I suppose a per-HTTPProxy design also works; we could inherit from a namespace config through an admission controller.

bobbytables

comment created time in a month

startedstreamnative/pulsar-beat-output

started time in a month

issue commentprometheus-operator/prometheus-operator

How to setup HA using prometheus operator

See earlier discussion in #2491

nandeeshb09

comment created time in a month

issue commentprometheus-operator/prometheus-operator

HA Prometheus Operator

We've run into this.

When prometheus-operator is crash looping, it might become unavailable, but the pod will continue running on the same node with a restarting container. There is nothing that will magically "heal" this prometheus operator on the cluster. The idea that "15 seconds" or "30 seconds" is an upper bound on unavailability is inaccurate, IMO.

For such situation, HA through leader election would have come in handy:

  • one active replica, one hot standby replica
  • only one replica holds the leader lock
  • if the lock cannot be renewed for any reason, the hot standby takes over
  • the damaged replica still needs healing, but the operator's duties are still being fulfilled until that happens

In our multi-tenant platform, we provide monitoring-as-a-service to our namespace tenants exclusively via the Prometheus Operator CRDs. Availability of the Operator is directly linked to the availability of this service.

tushar00jain

comment created time in a month

issue openedprojectcontour/contour

Expose X-Request-Id header in downstream responses

This is the issue described in envoyproxy/envoy#5828. The simple solution is to set always_set_request_id_in_response: true on the HttpConnectionManager filter, but I think this is only available in xDS API v3 (see #1898).

This may not be desirable in all installations of Contour and could be configurable at various levels:

  • globally, via Contour config
  • locally, via HTTPProxy

Conceptually, I'd say in belongs in the same API vicinity as HeadersPolicy.

created time in a month

issue openedkubernetes/cloud-provider-openstack

[occm] concurrent creation of listeners, pools and pool members

/kind feature

What happened: For a large cluster and a Service[type=LoadBalancer] with multiple ports (ex: :80, :443), the full EnsureLoadBalancer process takes several minutes. Some of this delay is caused by the sequential creation of listeners, pools and pool members.

What you expected to happen:

  • creation of independent listeners can happen concurrently
  • creation of independent pools can happen concurrently
  • creation of pool members can happen concurrently

The critical path should roughly define the overall e2e latency:

  • provision load balancer
  • create listener
  • create pool member

Maximum concurrency can be capped via the OCCM configuration.

created time in a month

issue commentkubernetes/cloud-provider-openstack

[occm] LB Pool not updated when proxy-protocol service annotation changed

I would classify this as a bug, not a missing feature.

seanschneeweiss

comment created time in a month

startedkubernetes-csi/csi-driver-smb

started time in a month

Pull request review commentprojectcontour/contour

cmd/shutdownmanager: /shutdown handler fixes

 func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // file to understand if it is safe to terminate. The file-based approach is used since the process in which // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) {+	// For testing, the filepath and check period can be overridden in the context+	// Otherwise, use the module constants+	var signalFilepath string+	if s.shutdownReadyFile != "" {+		signalFilepath = s.shutdownReadyFile+	} else {+		signalFilepath = shutdownReadyFile+	}+	var signalFileCheckDuration time.Duration+	if s.shutdownReadyCheckInterval != 0 {+		signalFileCheckDuration = s.shutdownReadyCheckInterval+	} else {+		signalFileCheckDuration = shutdownReadyCheckInterval+	}++	l := s.WithField("context", "shutdownReadyHandler")+	ctx := r.Context() 	for {-		_, err := os.Stat(shutdownReadyFile)-		if err != nil {+		_, err := os.Stat(signalFilepath)+		if err == nil {

Not exactly what you suggested, but I reordered the if cases.

bgagnon

comment created time in a month

PullRequestReviewEvent

push eventbgagnon/contour

Benoit Gagnon

commit sha 872e59cfddf152f9fcafcbb00325e83162ad11f2

reorder cases for os.Stat() in shutdownReadyHandler Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in a month

Pull request review commentprojectcontour/contour

cmd/shutdownmanager: /shutdown handler fixes

 const (  // File path used in the /shutdown endpoint. const shutdownReadyFile = "/ok"+const shutdownReadyCheckInterval = time.Second * 1

Done.

bgagnon

comment created time in a month

PullRequestReviewEvent

Pull request review commentprojectcontour/contour

cmd/shutdownmanager: /shutdown handler fixes

 func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // file to understand if it is safe to terminate. The file-based approach is used since the process in which // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) {+	// For testing, the filepath and check period can be overridden in the context+	// Otherwise, use the module constants+	var signalFilepath string+	if s.shutdownReadyFile != "" {+		signalFilepath = s.shutdownReadyFile+	} else {+		signalFilepath = shutdownReadyFile+	}+	var signalFileCheckDuration time.Duration+	if s.shutdownReadyCheckInterval != 0 {+		signalFileCheckDuration = s.shutdownReadyCheckInterval+	} else {+		signalFileCheckDuration = shutdownReadyCheckInterval+	}

Done!

bgagnon

comment created time in a month

PullRequestReviewEvent

push eventbgagnon/contour

Benoit Gagnon

commit sha 73a59172a7ad54f33d2554dccd7395c48bc924d2

simplify defaults assignment for shutdownmanagerContext Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

Benoit Gagnon

commit sha 2026ecc93d1aff1e3ff02bc58406d78b2de79231

reorder cases for os.Stat() in shutdownReadyHandler Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in a month

startedgin-gonic/gin

started time in a month

push eventbgagnon/contour

Benoit Gagnon

commit sha 6f856b5ed57aad4d2cc18908b8bed8e641059215

cmd/shutdownmanager: /shutdown handler fixes - shutdownReady filepath ("/ok") is configurable - os.Stat() interval is configurable - detect client disconnection and stop check loop - add test coverage for success and client disconnect cases Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in a month

push eventbgagnon/contour

Benoit Gagnon

commit sha 7e4a7ec87d528607d65433e4ecf46b531b4f99e4

remove redundant return Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in a month

push eventbgagnon/contour

Benoit Gagnon

commit sha f7bf871e0f9aabfe361dd583bab05f482990b7c0

call cancel functions when using context.WithTimeout() Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in a month

Pull request review commentprojectcontour/contour

Update linter configuration.

 func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) { 	for {-		if _, err := os.Stat(shutdownReadyFile); err == nil {+		_, err := os.Stat(shutdownReadyFile)+		if err != nil { 			http.StatusText(http.StatusOK) 			if _, err := w.Write([]byte("OK")); err != nil { 				s.WithField("context", "shutdownReadyHandler").Error(err) 			} 			return-		} else {-			s.WithField("context", "shutdownReadyHandler").Errorf("error checking for file: %v", err) 		}+		s.WithField("context", "shutdownReadyHandler").Errorf("error checking for file: %v", err)

Fixed in #2899

jpeach

comment created time in a month

PullRequestReviewEvent

Pull request review commentprojectcontour/contour

cmd/shutdownmanager: /shutdown handler fixes

 func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // file to understand if it is safe to terminate. The file-based approach is used since the process in which // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) {+	// For testing, the filepath and check period can be overridden in the context+	// Otherwise, use the module constants+	var signalFilepath string+	if s.shutdownReadyFile != "" {+		signalFilepath = s.shutdownReadyFile+	} else {+		signalFilepath = shutdownReadyFile+	}+	var signalFileCheckDuration time.Duration+	if s.shutdownReadyCheckInterval != 0 {+		signalFileCheckDuration = s.shutdownReadyCheckInterval+	} else {+		signalFileCheckDuration = shutdownReadyCheckInterval+	}

Not too happy with the location of this logic... maybe the defaults assignment should move to newShutdownManagerContext().

bgagnon

comment created time in a month

PullRequestReviewEvent

PR opened projectcontour/contour

cmd/shutdownmanager: /shutdown handler fixes

Fixes #2896 , #2897

  • shutdownReady filepath ("/ok") is configurable
  • os.Stat() interval is configurable
  • detect client disconnection and stop check loop
  • don't use error logging level when os.Stat() tells us the file does not yet exist
  • add test coverage for success and client disconnect cases
+113 -6

0 comment

2 changed files

pr created time in a month

create barnchbgagnon/contour

branch : shutdown-handler-2896-2897

created branch time in a month

issue commentprojectcontour/contour

Shutdown manager "error checking for file" log messages shouldn't be at ERROR level

@skriss I can work on this, yes.

BTW, I think commit 2fb8de3e from @jpeach introduced a regression in the error checking condition in this very handler function.

bgagnon

comment created time in a month

startedoperator-framework/operator-sdk

started time in a month

startedoperatify/operatify

started time in a month

issue openedprojectcontour/contour

ShutdownManager's /shutdown loop does not exit when client cancels request

The /shutdown handler in the shutdown-manager container has an infinite loop. If the HTTP client aborts the request and closes the connection, the goroutine performing that infinite loop will continue indefinitely (unless the the /ok file shows up).

I think the handler should use the CloseNotifier channel to exit if the client gives up: https://golang.org/pkg/net/http/#CloseNotifier

This can be combined with the 1 second sleep.

This issue was discovered while investigating #2896

Environment:

  • Contour version: v1.8.1
  • Kubernetes version: 1.17.1

created time in a month

issue openedprojectcontour/contour

Shutdown manager "error checking for file" log messages shouldn't be at ERROR level

After upgrading to Contour 0.8.1, I was surprised to find these entries in the shutdown-manager container logs:

envoy-m2trt shutdown-manager time="2020-09-10T02:11:58Z" level=error msg="error checking for file: stat /ok: no such file or directory" context=shutdownReadyHandler
envoy-m2trt shutdown-manager time="2020-09-10T02:11:59Z" level=error msg="error checking for file: stat /ok: no such file or directory" context=shutdownReadyHandler
envoy-m2trt shutdown-manager time="2020-09-10T02:12:00Z" level=error msg="error checking for file: stat /ok: no such file or directory" context=shutdownReadyHandler
envoy-m2trt shutdown-manager time="2020-09-10T02:12:01Z" level=error msg="error checking for file: stat /ok: no such file or directory" context=shutdownReadyHandler

My initial thought was that something was not configured correctly. But further investigation leads me to believe this is the normal behavior for the shutdown manager.

It polls a file continuously until it exists. Since it expects not to find it, I would argue errors from os.Stat() that relate to the file not existing are not to be logged at level=error, but rather level=info.

A minor detail for sure, but since we cannot see the pre stop hook logs from the Envoy side, it's best if normal things are reported as normal events from the shutdown-manager side.

created time in a month

issue commentprojectcontour/contour

Add support for Envoy xDS v3.

According to https://www.envoyproxy.io/docs/envoy/latest/api/api_supported_versions, the V2 API will stop being supported at the end of this year.

jpeach

comment created time in a month

issue commentprojectcontour/contour

High memory after upgrading to Contour v1.2

Our latest stats:

  • Version: docker.io/projectcontour/contour:v1.2.1
  • Envoy pods: 3
  • HTTPProxies: 455
  • Ingress: 0
  • Services: 590
    • 352 referenced by HTTPProxies
  • tls secrets: 1217
    • 408 referenced by HTTPProxies

Contour memory consumption:

  • leader: 380MB
  • follower: 170MB

We've seen a drop in memory consumption when we scaled down Envoy from 20 pods to 3 pods. That seems to be the biggest impacting factor, though it was not linear.

Meanwhile, every other quantity (proxies, secrets, services) has increased without a big impact on Contour memory consumption.

Since our Contour is now so far behind, I think it's best if I report back after we've upgraded to the latest release.

stevesloka

comment created time in 2 months

startedterraform-providers/terraform-provider-aws

started time in 2 months

startedchop-dbhi/prometheus-sql

started time in 2 months

startedloft-sh/loft

started time in 2 months

startedmeilisearch/MeiliSearch

started time in 2 months

startedCrunchyData/postgres-operator

started time in 2 months

startedk14s/kapp-controller

started time in 2 months

issue openedarminc/k8s-platform-lcm

Support docker.elastic.co registry

This popular registry hosts all official images for Elastic products: https://docker.elastic.co

It looks like it supports a standard V2 API, for example: https://docker.elastic.co/v2/elasticsearch/elasticsearch/tags/list

created time in 2 months

issue openedvmware-tanzu/velero

Expose controller metrics

Describe the problem/challenge you have We have log entries indicating that an Backup object references a BackupStorageLocation that no longer exists:

{
  "controller":"gc-controller",
  "error":"error getting backup storage location: backupstoragelocation.velero.io \"default\" not found", 
  "error.file":"/go/src/github.com/vmware-tanzu/velero/pkg/controller/gc_controller.go:144", 
  "error.function":"github.com/vmware-tanzu/velero/pkg/controller.(*gcController).processQueueItem",
  "key":"runway-backup/default-20200718080037",
  "level":"error",
  "logSource":"pkg/controller/generic_controller.go:137",
  "msg":"Error in syncHandler, re-adding item to queue",
  "time":"2020-08-27T15:59:44Z"
}

There is no corresponding counter metric that would allow us to alert on this condition. This issue is not so much about this particular error conditions above, but a general point about the lack of metrics for internal controller behavior.

Describe the solution you'd like Standard controller metrics (HTTP calls and status codes made to the K8S API) could suffice, otherwise some specialized velero_ time series for each handled error:

  • attempts
  • failures

That way, a rate can be computed and a threshold can be set for alerting.

created time in 2 months

startedcorneliusweig/konfig

started time in 2 months

issue commentrancher/rancher

Create kube config for ALL clusters user has access to

This would be useful both from the Rancher UI and the Rancher CLI.

For the CLI, it's somewhat achievable today by taking the outputs ofrancher clusters kubeconfig on every cluster, then using something like https://github.com/corneliusweig/konfig to merge them.

cjellick

comment created time in 2 months

issue commentrancher/rancher

[UI] Rancher UI multi download of kubeconfig files of clusters

An archive of multiple kubeconfig YAML files is less usable then the merged approach described in #13853.

asemen2608

comment created time in 2 months

startedjrockway/ekglue

started time in 2 months

startedmicrosoft/cpprestsdk

started time in 2 months

Pull request review commentprojectcontour/contour

add Gatekeeper guide and sample configs

+---+title: Using Gatekeeper as a validating admission controller with Contour+layout: page+---++This tutorial demonstrates how to use [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) as a validating admission controller for Contour.++Gatekeeper is a project that enables users to define flexible policies for Kubernetes resources using [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) that are enforced when those resources are created/updated via the Kubernetes API.++The benefits of using Gatekeeper with Contour are:+- Immediate feedback for the user when they try to create an `HTTPProxy` with an invalid spec. Instead of having to check the `HTTPProxy`'s status after creation for a possible error message, the create is rejected and the user is immediately provided with a reason for the rejection.+- User-defined policies for `HTTPProxy` specs. For example, the Contour admin can define policies to enforce maximum limits on timeouts and retries, disallow certain FQDNs, etc.++## Prerequisites++- A Kubernetes cluster with a minimum version of 1.14 (to enable webhook timeouts for Gatekeeper).+- Cluster-admin permissions++## Deploy Contour++Run:++```bash+$ kubectl apply -f {{ site.url }}/quickstart/contour.yaml+```++This creates a `projectcontour` namespace and sets up Contour as a deployment and Envoy as a daemonset, with communication between them secured by mutual TLS.++Check the status of the Contour pods with this command:++```bash+$ kubectl -n projectcontour get pods -l app=contour+NAME                           READY   STATUS      RESTARTS   AGE+contour-8596d6dbd7-9nrg2       1/1     Running     0          32m+contour-8596d6dbd7-mmtc8       1/1     Running     0          32m+```++If installation was successful, all pods should reach `Running` status shortly.++## Deploy Gatekeeper++The following instructions are summarized from the [Gatekeeper documentation](https://github.com/open-policy-agent/gatekeeper#installation-instructions).++Run:++```bash+$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml+```++This creates a `gatekeeper-system` namespace and sets up the Gatekeeper controller manager and audit deployments using the latest Gatekeeper release.++Check the status of the Gatekeeper pods with this command:++```bash+$ kubectl -n gatekeeper-system get pods+NAME                                             READY   STATUS    RESTARTS   AGE+gatekeeper-audit-67dfc46db6-kjcmc                1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-64hhn   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-c4dkd   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-xv9jn   1/1     Running   0          40m+```++If installation was successful, all pods should reach `Running` status shortly.++## Configure Gatekeeper++### Background++Gatekeeper uses the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to define and enforce policies.+This framework has two key types: `ConstraintTemplate` and `Constraint`.+A `ConstraintTemplate` defines a reusable OPA policy, along with the parameters that can be passed to it when it is instantiated.+When a `ConstraintTemplate` is created, Gatekeeper automatically creates a custom resource definition (CRD) to represent it in the cluster.++A `Constraint` is an instantiation of a `ConstraintTemplate`, which tells Gatekeeper to apply it to specific Kubernetes resource types (e.g. `HTTPProxy`) and provides any relevant parameter values.+A `Constraint` is defined as an instance of the CRD representing the associated `ConstraintTemplate`.++We'll now look at some examples to make these concepts concrete.++### Configure resource caching++First, Gatekeeper needs to be configured to store all `HTTPProxy` resources in its internal cache, so that existing `HTTPProxy` resources can be referenced within constraint template policies.+This is essential for being able to define constraints that look across all `HTTPProxies` -- for example, to verify FQDN uniqueness.++Create a file called `config.yml` containing the following YAML:++```yaml+apiVersion: config.gatekeeper.sh/v1alpha1+kind: Config+metadata:+  name: config+  namespace: "gatekeeper-system"+spec:+  sync:+    syncOnly:+      - group: "projectcontour.io"+        version: "v1"+        kind: "HTTPProxy"+```++Apply it to the cluster:++```bash+$ kubectl apply -f config.yml+```++### Configure HTTPProxy validations++The first constraint template and constraint that we'll define are what we'll refer to as a **validation**.+These are rules for `HTTPProxy` specs that Contour universally requires to be true.+In this example, we'll define a constraint template and constraint to enforce that all `HTTPProxies` must have a unique FQDN.++Create a file called `unique-fqdn-template.yml` containing the following YAML:++```yaml+apiVersion: templates.gatekeeper.sh/v1beta1+kind: ConstraintTemplate+metadata:+  name: httpproxyuniquefqdn+spec:+  crd:+    spec:+      names:+        kind: HTTPProxyUniqueFQDN+        listKind: HTTPProxyUniqueFQDNList+        plural: HTTPProxyUniqueFQDNs+        singular: HTTPProxyUniqueFQDN+  targets:+    - target: admission.k8s.gatekeeper.sh+      rego: |+        package httpproxy.uniquefqdn++        violation[{"msg": msg, "other": sprintf("%v/%v", [other.metadata.namespace, other.metadata.name])}] {+          got := input.review.object.spec.virtualhost.fqdn+          other := data.inventory.namespace[_]["projectcontour.io/v1"]["HTTPProxy"][_]+          other.spec.virtualhost.fqdn = got++          not same(other, input.review.object)+          msg := "HTTPProxy must have a unique spec.virtualhost.fqdn"+        }++        same(a, b) {+          a.metadata.namespace == b.metadata.namespace+          a.metadata.name == b.metadata.name+        }+```++Apply it to the cluster:++```bash+$ kubectl apply -f unique-fqdn-template.yml+```++Within a few seconds, you'll see that a corresponding CRD has been created in the cluster:++```bash+$ kubectl get crd httpproxyuniquefqdn.constraints.gatekeeper.sh+NAME                                            CREATED AT+httpproxyuniquefqdn.constraints.gatekeeper.sh   2020-08-13T16:08:57Z+```++Now, create a file called `unique-fqdn-constraint.yml` containing the following YAML:++```yaml+apiVersion: constraints.gatekeeper.sh/v1beta1+kind: HTTPProxyUniqueFQDN+metadata:+  name: httpproxy-unique-fqdn+spec:+  match:+    kinds:+      - apiGroups: ["projectcontour.io"]+        kinds: ["HTTPProxy"]+```++Note that the `Kind` of this resource corresponds to the new CRD.++Apply it to the cluster:++```bash+$ kubectl apply -f unique-fqdn-constraint.yml+```++Now, let's create some `HTTPProxies` to see the validation in action.++Create a file called `httpproxies.yml` containing the following YAML:++```yaml+apiVersion: projectcontour.io/v1+kind: HTTPProxy+metadata:+  name: demo+  namespace: default+spec:+  virtualhost:+    fqdn: demo.projectcontour.io+---+apiVersion: projectcontour.io/v1+kind: HTTPProxy+metadata:+  name: demo2+  namespace: default+spec:+  virtualhost:+    fqdn: demo.projectcontour.io+```++Note that both `HTTPProxies` have the same FQDN.++Apply the YAML:++```bash+$ kubectl apply -f httpproxies.yml+```++You should see something like:+```+httpproxy.projectcontour.io/demo created+Error from server ([denied by httpproxy-unique-fqdn] HTTPProxy must have a unique FQDN): error when creating "httpproxies.yml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by httpproxy-unique-fqdn] HTTPProxy must have a unique FQDN+```++The first `HTTPProxy` was created successfully, because there was not already an existing proxy with the `demo.projectcontour.io` FQDN.+However, when the second `HTTPProxy` was submitted, Gatekeeper rejected its creation because it used the same FQDN as the first one.++### Configure HTTPProxy policies++The next constraint template and constraint that we'll create are what we refer to as a **policy**.+These are rules for `HTTPProxy` specs that an individual Contour administrator may want to enforce for their cluster, but that are not explicitly required by Contour itself.+In this example, we'll define a constraint template and constraint to enforce that all `HTTPProxies` can be configured with at most five retries for any route.++Create a file called `retry-count-range-template.yml` containing the following YAML:++```yaml+apiVersion: templates.gatekeeper.sh/v1beta1+kind: ConstraintTemplate+metadata:+  name: httpproxyretrycountrange+spec:+  crd:+    spec:+      names:+        kind: HTTPProxyRetryCountRange+        listKind: HTTPProxyRetryCountRangeList+        plural: HTTPProxyRetryCountRanges+        singular: HTTPProxyRetryCountRange+      scope: Namespaced+      validation:+        openAPIV3Schema:+          properties:+            min:+              type: integer+            max: +              type: integer+  targets:+    - target: admission.k8s.gatekeeper.sh+      rego: |+        package httpproxy.retrycountrange++        violation[{"msg": msg}] {+          got := input.review.object.spec.routes[_].retryPolicy.count++          got > input.parameters.max+          msg := sprintf("retry policy count must be less than/equal to %v", [input.parameters.max])+        }++        violation[{"msg": msg}] {+          got := input.review.object.spec.routes[_].retryPolicy.count++          got < input.parameters.min+          msg := sprintf("retry policy count must be greater than/equal to %v", [input.parameters.min])+        }+```++Apply it to the cluster:++```bash+$ kubectl apply -f retry-count-range-template.yml+```++Again, within a few seconds, you'll see that a corresponding CRD has been created in the cluster:++```bash+$ kubectl get crd httpproxyretrycountrange.constraints.gatekeeper.sh+NAME                                                 CREATED AT+httpproxyretrycountrange.constraints.gatekeeper.sh   2020-08-13T16:12:10Z+```++Now, create a file called `retry-count-range-constraint.yml` containing the following YAML:++```yaml+apiVersion: constraints.gatekeeper.sh/v1beta1+kind: HTTPProxyRetryCountRange+metadata:+  name: httpproxy-retry-count-range

I think the example should specify metadata.namespace field explicitly and a comment below should make the scoping of the constraint extra clear. In other words, if I create this HTTPProxyRetryCountRange in namespace foo, does it only apply to HTTPProxy objects in that namespace? Does it depend on the content of the policy?

skriss

comment created time in 2 months

Pull request review commentprojectcontour/contour

add Gatekeeper guide and sample configs

+---+title: Using Gatekeeper as a validating admission controller with Contour+layout: page+---++This tutorial demonstrates how to use [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) as a validating admission controller for Contour.++Gatekeeper is a project that enables users to define flexible policies for Kubernetes resources using [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) that are enforced when those resources are created/updated via the Kubernetes API.++The benefits of using Gatekeeper with Contour are:+- Immediate feedback for the user when they try to create an `HTTPProxy` with an invalid spec. Instead of having to check the `HTTPProxy`'s status after creation for a possible error message, the create is rejected and the user is immediately provided with a reason for the rejection.+- User-defined policies for `HTTPProxy` specs. For example, the Contour admin can define policies to enforce maximum limits on timeouts and retries, disallow certain FQDNs, etc.++## Prerequisites++- A Kubernetes cluster with a minimum version of 1.14 (to enable webhook timeouts for Gatekeeper).+- Cluster-admin permissions++## Deploy Contour++Run:++```bash+$ kubectl apply -f {{ site.url }}/quickstart/contour.yaml+```++This creates a `projectcontour` namespace and sets up Contour as a deployment and Envoy as a daemonset, with communication between them secured by mutual TLS.++Check the status of the Contour pods with this command:++```bash+$ kubectl -n projectcontour get pods -l app=contour+NAME                           READY   STATUS      RESTARTS   AGE+contour-8596d6dbd7-9nrg2       1/1     Running     0          32m+contour-8596d6dbd7-mmtc8       1/1     Running     0          32m+```++If installation was successful, all pods should reach `Running` status shortly.++## Deploy Gatekeeper++The following instructions are summarized from the [Gatekeeper documentation](https://github.com/open-policy-agent/gatekeeper#installation-instructions).++Run:++```bash+$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml+```++This creates a `gatekeeper-system` namespace and sets up the Gatekeeper controller manager and audit deployments using the latest Gatekeeper release.++Check the status of the Gatekeeper pods with this command:++```bash+$ kubectl -n gatekeeper-system get pods+NAME                                             READY   STATUS    RESTARTS   AGE+gatekeeper-audit-67dfc46db6-kjcmc                1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-64hhn   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-c4dkd   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-xv9jn   1/1     Running   0          40m+```++If installation was successful, all pods should reach `Running` status shortly.++## Configure Gatekeeper++### Background++Gatekeeper uses the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to define and enforce policies.+This framework has two key types: `ConstraintTemplate` and `Constraint`.+A `ConstraintTemplate` defines a reusable OPA policy, along with the parameters that can be passed to it when it is instantiated.+When a `ConstraintTemplate` is created, Gatekeeper automatically creates a custom resource definition (CRD) to represent it in the cluster.++A `Constraint` is an instantiation of a `ConstraintTemplate`, which tells Gatekeeper to apply it to specific Kubernetes resource types (e.g. `HTTPProxy`) and provides any relevant parameter values.+A `Constraint` is defined as an instance of the CRD representing the associated `ConstraintTemplate`.++We'll now look at some examples to make these concepts concrete.++### Configure resource caching++First, Gatekeeper needs to be configured to store all `HTTPProxy` resources in its internal cache, so that existing `HTTPProxy` resources can be referenced within constraint template policies.+This is essential for being able to define constraints that look across all `HTTPProxies` -- for example, to verify FQDN uniqueness.++Create a file called `config.yml` containing the following YAML:++```yaml+apiVersion: config.gatekeeper.sh/v1alpha1+kind: Config+metadata:+  name: config+  namespace: "gatekeeper-system"+spec:+  sync:+    syncOnly:+      - group: "projectcontour.io"+        version: "v1"+        kind: "HTTPProxy"+```++Apply it to the cluster:++```bash+$ kubectl apply -f config.yml+```++### Configure HTTPProxy validations++The first constraint template and constraint that we'll define are what we'll refer to as a **validation**.+These are rules for `HTTPProxy` specs that Contour universally requires to be true.+In this example, we'll define a constraint template and constraint to enforce that all `HTTPProxies` must have a unique FQDN.++Create a file called `unique-fqdn-template.yml` containing the following YAML:++```yaml+apiVersion: templates.gatekeeper.sh/v1beta1+kind: ConstraintTemplate+metadata:+  name: httpproxyuniquefqdn+spec:+  crd:+    spec:+      names:+        kind: HTTPProxyUniqueFQDN+        listKind: HTTPProxyUniqueFQDNList+        plural: HTTPProxyUniqueFQDNs+        singular: HTTPProxyUniqueFQDN+  targets:+    - target: admission.k8s.gatekeeper.sh+      rego: |+        package httpproxy.uniquefqdn++        violation[{"msg": msg, "other": sprintf("%v/%v", [other.metadata.namespace, other.metadata.name])}] {+          got := input.review.object.spec.virtualhost.fqdn+          other := data.inventory.namespace[_]["projectcontour.io/v1"]["HTTPProxy"][_]

Since Contour is especially good in multi-tenant situations, I'd be interested to see more mentions of namespaces in the Gatekeeper/Contour presentation.

  • are constraints namespace-specific by default; can they be made cluster wide
  • how constraints at the cluster level interact with namespace-level ones
  • what is the order of precedence
  • etc.
skriss

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentprojectcontour/contour

add Gatekeeper guide and sample configs

+---+title: Using Gatekeeper as a validating admission controller with Contour+layout: page+---++This tutorial demonstrates how to use [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) as a validating admission controller for Contour.++Gatekeeper is a project that enables users to define flexible policies for Kubernetes resources using [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) that are enforced when those resources are created/updated via the Kubernetes API.++The benefits of using Gatekeeper with Contour are:+- Immediate feedback for the user when they try to create an `HTTPProxy` with an invalid spec. Instead of having to check the `HTTPProxy`'s status after creation for a possible error message, the create is rejected and the user is immediately provided with a reason for the rejection.+- User-defined policies for `HTTPProxy` specs. For example, the Contour admin can define policies to enforce maximum limits on timeouts and retries, disallow certain FQDNs, etc.++## Prerequisites++- A Kubernetes cluster with a minimum version of 1.14 (to enable webhook timeouts for Gatekeeper).+- Cluster-admin permissions++## Deploy Contour++Run:++```bash+$ kubectl apply -f {{ site.url }}/quickstart/contour.yaml+```++This creates a `projectcontour` namespace and sets up Contour as a deployment and Envoy as a daemonset, with communication between them secured by mutual TLS.++Check the status of the Contour pods with this command:++```bash+$ kubectl -n projectcontour get pods -l app=contour+NAME                           READY   STATUS      RESTARTS   AGE+contour-8596d6dbd7-9nrg2       1/1     Running     0          32m+contour-8596d6dbd7-mmtc8       1/1     Running     0          32m+```++If installation was successful, all pods should reach `Running` status shortly.++## Deploy Gatekeeper++The following instructions are summarized from the [Gatekeeper documentation](https://github.com/open-policy-agent/gatekeeper#installation-instructions).++Run:++```bash+$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml+```++This creates a `gatekeeper-system` namespace and sets up the Gatekeeper controller manager and audit deployments using the latest Gatekeeper release.++Check the status of the Gatekeeper pods with this command:++```bash+$ kubectl -n gatekeeper-system get pods+NAME                                             READY   STATUS    RESTARTS   AGE+gatekeeper-audit-67dfc46db6-kjcmc                1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-64hhn   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-c4dkd   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-xv9jn   1/1     Running   0          40m+```++If installation was successful, all pods should reach `Running` status shortly.++## Configure Gatekeeper++### Background++Gatekeeper uses the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to define and enforce policies.+This framework has two key types: `ConstraintTemplate` and `Constraint`.+A `ConstraintTemplate` defines a reusable OPA policy, along with the parameters that can be passed to it when it is instantiated.+When a `ConstraintTemplate` is created, Gatekeeper automatically creates a custom resource definition (CRD) to represent it in the cluster.++A `Constraint` is an instantiation of a `ConstraintTemplate`, which tells Gatekeeper to apply it to specific Kubernetes resource types (e.g. `HTTPProxy`) and provides any relevant parameter values.+A `Constraint` is defined as an instance of the CRD representing the associated `ConstraintTemplate`.++We'll now look at some examples to make these concepts concrete.++### Configure resource caching++First, Gatekeeper needs to be configured to store all `HTTPProxy` resources in its internal cache, so that existing `HTTPProxy` resources can be referenced within constraint template policies.+This is essential for being able to define constraints that look across all `HTTPProxies` -- for example, to verify FQDN uniqueness.

This is really interesting! I had assumed that Gatekeeper could only see the resource being admitted, plus some contextual data needed for ACLs. This idea of caching resources opens up a whole world of possibilities.

skriss

comment created time in 2 months

PullRequestReviewEvent

starteddghubble/oauth1

started time in 2 months

issue openedprometheus-community/jiralert

Support OAuth 1.0a for authenticating to JIRA

As an alternative to Basic auth with username and password, offer OAuth 1.0a integration:<br> https://developer.atlassian.com/server/jira/platform/oauth/

created time in 2 months

issue commentkubernetes/cloud-provider-openstack

LB not working with externalTrafficPolicy set to Local

@lingxiankong can you please reopen? thanks!

JrCs

comment created time in 2 months

issue commentkubernetes/cloud-provider-openstack

LB not working with externalTrafficPolicy set to Local

/reopen /remove-lifecycle rotten

JrCs

comment created time in 2 months

startedcodyc1515/homebridge-panasonic-air-conditioner

started time in 2 months

startedfuturewei-cloud/arktos

started time in 2 months

startedpomerium/pomerium

started time in 2 months

startedarminc/k8s-platform-lcm

started time in 2 months

startedilhaan/kubeCDN

started time in 2 months

pull request commentvmware-tanzu/velero

Override logrus.ErrorKey when json logging is enabled

I'm a little uneasy with the mutation of global variables, but I don't see any better way given the logrus API.

bgagnon

comment created time in 2 months

push eventbgagnon/velero

Benoit Gagnon

commit sha 40ea942402f66ed33baa10826adef4d2f83160a8

add changelog entry Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in 2 months

PR opened vmware-tanzu/velero

Override logrus.ErrorKey when json logging is enabled

When JSON logging format is enabled, set logrus.ErrorKey module var to "error.message" instead of "error".

Fixes #2829

+17 -0

0 comment

1 changed file

pr created time in 2 months

push eventbgagnon/velero

Benoit Gagnon

commit sha a07acc11f105bb95c76949f9d0778b6a37f96cb8

document the logrus.ErrorKey override Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in 2 months

create barnchbgagnon/velero

branch : fix-error-logging-subfields

created branch time in 2 months

issue openedvmware-tanzu/velero

Irreconcilable error, error.file and error.function logging fields

What steps did you take and what happened: Enabled structured logging (log.format=json) to index Velero logs in Elasticsearch. This produces mapping exceptions such as:

{
  "type":"illegal_argument_exception",
  "reason":"Can't merge a non object mapping [json.error] with an object mapping [json.error]"
}

What did you expect to happen: Velero log event fields should be consistent with each other and allow a JSON representation compatible with Elasticsearch to exist.

Anything else you would like to add: This is similar to a previous issue I reported and fixed -- see #2795.

The problem is is in the logrus hook for errors (error_location_hook.go) which contains the following field name constants:

const (
	errorFileField     = "error.file"
	errorFunctionField = "error.function"
)

Since an error also produces a message and stores it underfield error, we end up with:

{
  "error": "the message",
  "error.file": "file.go",
  "error.function": "foo"
}

Now, this is valid JSON, but recent Elasticsearch versions (7.x ?) no longer supports dots in field names and automatically expand to nested objects:

{
  "error": {
    "file": "file.go",
    "function": "foo",
  }
}

The problem, at this point, is that field error cannot be a string and an object at the same time, so Elasticsearch throws an error:

Can't merge a non object mapping [json.error] with an object mapping [json.error]"

Environment: master (c663ce15ab468b21a19336dcc38acf3280853361)

created time in 2 months

startedkubernetes-sigs/multi-tenancy

started time in 2 months

startedmingrammer/diagrams

started time in 2 months

issue commentopendistro-for-elasticsearch/community

APM UI Missing

some time ago the module was paid, thanks for their wonderful product, now the security is free without ldap, maybe it will be the same with the APM

APM is free, but it's under the Elastic license, not the Apache license. It's included in the Basic subscription: https://www.elastic.co/subscriptions

Open Distro works with the Apache (OSS) version of Elasticsearch, not the Elastic license version (also known as "X-Pack"). So you can use APM today, just not with OpenDistro.

kristianpaul

comment created time in 2 months

startedalerta/alerta

started time in 2 months

startedstreamnative/kop

started time in 2 months

startedForkIssues/Tracker

started time in 2 months

startedbraedon/prometheus-es-exporter

started time in 2 months

startedtimberio/vector

started time in 2 months

push eventbgagnon/velero

Benoit Gagnon

commit sha 610cafa1b77ea3ef6e635986418ab243ea0ca8f3

always use groupResource.String() when logging (fixes #2795) Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in 2 months

push eventbgagnon/velero

Benoit Gagnon

commit sha 0abe8af6f4a2f980e6d079ee0aafdad84bdb56a4

add changelog entry Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in 2 months

push eventbgagnon/velero

Benoit Gagnon

commit sha 7050612f06bd88011dcc0c4a0c0d165ea2251e89

always use groupResource.String() when logging (fixes #2795) Signed-off-by: Benoit Gagnon <benoit.gagnon@ubisoft.com>

view details

push time in 2 months

PR opened vmware-tanzu/velero

Always use groupResource.String() when logging (fixes #2795)

This aligns this resource logging field injection with the rest of the code base, and fixes #2795.

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchbgagnon/velero

branch : fix-resource-logging-field

created branch time in 2 months

fork bgagnon/velero

Backup and migrate Kubernetes applications and their persistent volumes

https://velero.io

fork in 2 months

issue openedvmware-tanzu/velero

Inconsistent schema for logging field "resource" in Velero server logs

What steps did you take and what happened: Enabled JSON logs for Velero to index them in Elasticsearch.

What did you expect to happen: Consistent mapping (ie. always a string) for logging fields:

  • progress
  • name
  • namespace
  • resource
  • persistentVolume
  • etc.

When schema.GroupResource is passed directly like this:

log.WithField("resource", groupResource)

It produces a nested object string map for the value of resource. The problem is that Elasticsearch cannot reconcile this nested JSON object for this log entry with a previous string value for the same resource field.

Here is the Filebeat representation:

"resource":common.MapStr{"Group":"rbac.authorization.k8s.io", "Resource":"rolebindings"}

And the (abbreviated) Elasticsearch error:

Cannot index event publisher.Event{
  Content:beat.Event{Timestamp:time.Time{wall:0xe82ed55, ext:63732240105, loc:(*time.Location)(nil)},
  [...],
"json":common.MapStr{
  "backup":"runway-backup/default-runway-uks-ncsa-east-ne1-20200805160050",
  "group":"rbac.authorization.k8s.io/v1",
  "level":"debug",
  "logSource":"pkg/backup/item_backupper.go:311",
  "message":"",
  "msg":"Skipping action because it does not apply to this resource",
  "name":"clusterrolebinding-wwrfq",
  "namespace":"jirafixer-prod",
  "resource":common.MapStr{
    "Group":"rbac.authorization.k8s.io",
    "Resource":"rolebindings"
  },
  "time":"2020-08-05T16:01:45Z"
},
[...]
, Flags:0x1} (status=400): {
  "type":"mapper_parsing_exception",
  "reason":"failed to parse field [json.resource] of type [keyword] in document with id 'xxpiv3MB-zhVy2yjOYRu'.
  Preview of field's value: '{Group=rbac.authorization.k8s.io, Resource=rolebindings}'",
  "caused_by":{"type":"illegal_state_exception",
  "reason":"Can't get text on a START_OBJECT at 1:1196"
  }
}
--

**Suggested fix**

Always output `resource` as a string by calling `groupResource.String()` which adds a dot between the two parts.

created time in 2 months

startedjimmidyson/configmap-reload

started time in 2 months

issue commentprojectcontour/contour

Some admission control support for validating local issues

@youngnick I brought this up in the last community meeting, actually.

There was a discussion about the upcoming timeout range feature and it reminded me of LimitRange, ResourceQuota and PodSecurityPolicy objects which are enforced at admission time.

Arguably, Kubernetes itself is not perfect with those due to the asynchronous admission of Deployment -> ReplicaSet -> Pod.

On our side, we've been considering adding admission control hooks for Contour via our controller built on controller-runtime that handles our custom DNS and TLA provisioning. We have environment specific constraints on top of what Contour allows.

This portion could be done with OPA and Gatekeeper but it might be a little silly considering we can just add a few lines of Go to our existing controller.

Anyhow, it feels to me like a portion (perhaps very small) of the validation needed in Contour could be done at admission, leaving the more complex bits to the eventually consistent DAG evaluator.

I should mention this reflection happened in the context of an old 1.14 cluster (now 1.15!) that does not even validate CRD payloads.

With OpenAPI / JSON schema, it's perhaps less necessary, but there are still validations influenced by Contour configs and CLI flags.

If that's a growing trend in the project, it's worth considering, IMO.

bgagnon

comment created time in 3 months

issue openedams0/kubernetes-json-schema

Missing Jsonnet recipe

Running jsonnet on a JSON file simply outputs back that same file. Is there a .jsonnet file missing from this repository and from the instructions in the README?

created time in 3 months

startedsharkdp/bat

started time in 3 months

startedvvanholl/elasticsearch-prometheus-exporter

started time in 3 months

startedplanetlabs/draino

started time in 3 months

startedwayfair-tremor/tremor-runtime

started time in 3 months

more