text:
Release v0.8.2

Ref https://github.com/kubernetes-sigs/security-profiles-operator/pull/2030
Release notes
# Release notes

Welcome to our glorious v0.8.2 release of the **security-profiles-operator**! The general usage and setup can be found [in our documentation][0]. :partying_face: :dancers:

To install the operator, run:

```
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/v0.8.2/deploy/operator.yaml
```

You can also verify the container image signature by using [cosign][1]:

```
$ cosign verify \
    --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
    --certificate-oidc-issuer https://accounts.google.com \
    registry.k8s.io/security-profiles-operator/security-profiles-operator:v0.8.2
```

Beside the operator image, we now also ship `spoc`, the official Security Profiles Operator Command Line Interface! Binaries for `amd64` and `arm64` are attached to this release.

To verify the signature of `spoc`. download all release artifacts and run for `amd64` (works in the same way for `arm64`:

```
$ cosign verify-blob \
    --certificate-identity sgrunert@redhat.com \
    --certificate-oidc-issuer https://github.com/login/oauth \
    --certificate spoc.amd64.cert \
    --signature spoc.amd64.sig \
    spoc.amd64
```

To verify the Bill of Materials (BOM) using the [`bom`](https://github.com/kubernetes-sigs/bom) tool, download the artifacts into a `build` directory and run:

```
> bom validate -e spoc.spdx -d build/
+-------------------+-------+-----------------------------+----------------+
|     FILENAME      | VALID |           MESSAGE           | INVALID HASHES |
+-------------------+-------+-----------------------------+----------------+
| spoc.amd64        | OK    | File validated successfully | -              |
| spoc.amd64.cert   | OK    | File validated successfully | -              |
| spoc.amd64.sha512 | OK    | File validated successfully | -              |
| spoc.amd64.sig    | OK    | File validated successfully | -              |
| spoc.arm64        | OK    | File validated successfully | -              |
| spoc.arm64.cert   | OK    | File validated successfully | -              |
| spoc.arm64.sha512 | OK    | File validated successfully | -              |
| spoc.arm64.sig    | OK    | File validated successfully | -              |
+-------------------+-------+-----------------------------+----------------+
```

The `.spdx` file is signed as well and we also provide `.sha512` sum files for the binaries.

Feel free to provide us any kind of feedback in the official [Kubernetes Slack #security-profiles-operator channel][2].

[0]: https://github.com/kubernetes-sigs/security-profiles-operator/blob/v0.8.2/installation-usage.md
[1]: https://github.com/sigstore/cosign
[2]: https://app.slack.com/client/T09NY5SBT/C013FQNB0A2

## Changes by Kind

### Failing Test

- Fixed upgrade issue introduced in v0.8.1. (#2023, @yuumasato)

## Dependencies

### Added
- github.com/DATA-DOG/go-sqlmock: [v1.5.0](https://github.com/DATA-DOG/go-sqlmock/tree/v1.5.0)
- github.com/Khan/genqlient: [v0.6.0](https://github.com/Khan/genqlient/tree/v0.6.0)
- github.com/alexflint/go-arg: [v1.4.2](https://github.com/alexflint/go-arg/tree/v1.4.2)
- github.com/alexflint/go-scalar: [v1.0.0](https://github.com/alexflint/go-scalar/tree/v1.0.0)
- github.com/aws/aws-sdk-go-v2/feature/s3/manager: [v1.11.76](https://github.com/aws/aws-sdk-go-v2/feature/s3/manager/tree/v1.11.76)
- github.com/buildkite/go-pipeline: [v0.2.0](https://github.com/buildkite/go-pipeline/tree/v0.2.0)

### Changed
- cloud.google.com/go/compute: v1.23.2 → v1.23.3
- cloud.google.com/go/iam: v1.1.4 → v1.1.5
- cloud.google.com/go/kms: v1.15.4 → v1.15.5
- cloud.google.com/go: v0.110.9 → v0.110.10
- github.com/Azure/azure-sdk-for-go/sdk/azcore: [v1.8.0 → v1.9.0](https://github.com/Azure/azure-sdk-for-go/sdk/azcore/compare/v1.8.0...v1.9.0)
- github.com/Azure/azure-sdk-for-go/sdk/internal: [v1.4.0 → v1.5.0](https://github.com/Azure/azure-sdk-for-go/sdk/internal/compare/v1.4.0...v1.5.0)
- github.com/DataDog/datadog-agent/pkg/obfuscate: [v0.48.1 → v0.48.0](https://github.com/DataDog/datadog-agent/pkg/obfuscate/compare/v0.48.1...v0.48.0)
- github.com/DataDog/datadog-agent/pkg/remoteconfig/state: [v0.48.1 → 2549ba9](https://github.com/DataDog/datadog-agent/pkg/remoteconfig/state/compare/v0.48.1...2549ba9)
- github.com/DataDog/sketches-go: [v1.4.3 → v1.4.2](https://github.com/DataDog/sketches-go/compare/v1.4.3...v1.4.2)
- github.com/andybalholm/brotli: [v1.0.6 → v1.0.1](https://github.com/andybalholm/brotli/compare/v1.0.6...v1.0.1)
- github.com/aws/aws-sdk-go-v2/config: [v1.19.1 → v1.25.11](https://github.com/aws/aws-sdk-go-v2/config/compare/v1.19.1...v1.25.11)
- github.com/aws/aws-sdk-go-v2/credentials: [v1.13.43 → v1.16.9](https://github.com/aws/aws-sdk-go-v2/credentials/compare/v1.13.43...v1.16.9)
- github.com/aws/aws-sdk-go-v2/feature/ec2/imds: [v1.13.13 → v1.14.9](https://github.com/aws/aws-sdk-go-v2/feature/ec2/imds/compare/v1.13.13...v1.14.9)
- github.com/aws/aws-sdk-go-v2/internal/configsources: [v1.1.43 → v1.2.8](https://github.com/aws/aws-sdk-go-v2/internal/configsources/compare/v1.1.43...v1.2.8)
- github.com/aws/aws-sdk-go-v2/internal/endpoints/v2: [v2.4.37 → v2.5.8](https://github.com/aws/aws-sdk-go-v2/internal/endpoints/v2/compare/v2.4.37...v2.5.8)
- github.com/aws/aws-sdk-go-v2/internal/ini: [v1.3.45 → v1.7.1](https://github.com/aws/aws-sdk-go-v2/internal/ini/compare/v1.3.45...v1.7.1)
- github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding: [v1.9.14 → v1.10.3](https://github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding/compare/v1.9.14...v1.10.3)
- github.com/aws/aws-sdk-go-v2/service/internal/presigned-url: [v1.9.37 → v1.10.8](https://github.com/aws/aws-sdk-go-v2/service/internal/presigned-url/compare/v1.9.37...v1.10.8)
- github.com/aws/aws-sdk-go-v2/service/kms: [v1.24.7 → v1.27.2](https://github.com/aws/aws-sdk-go-v2/service/kms/compare/v1.24.7...v1.27.2)
- github.com/aws/aws-sdk-go-v2/service/sso: [v1.15.2 → v1.18.2](https://github.com/aws/aws-sdk-go-v2/service/sso/compare/v1.15.2...v1.18.2)
- github.com/aws/aws-sdk-go-v2/service/ssooidc: [v1.17.3 → v1.21.2](https://github.com/aws/aws-sdk-go-v2/service/ssooidc/compare/v1.17.3...v1.21.2)
- github.com/aws/aws-sdk-go-v2/service/sts: [v1.23.2 → v1.26.2](https://github.com/aws/aws-sdk-go-v2/service/sts/compare/v1.23.2...v1.26.2)
- github.com/aws/aws-sdk-go-v2: [v1.21.2 → v1.23.5](https://github.com/aws/aws-sdk-go-v2/compare/v1.21.2...v1.23.5)
- github.com/aws/aws-sdk-go: [v1.47.0 → v1.48.11](https://github.com/aws/aws-sdk-go/compare/v1.47.0...v1.48.11)
- github.com/aws/smithy-go: [v1.15.0 → v1.18.1](https://github.com/aws/smithy-go/compare/v1.15.0...v1.18.1)
- github.com/buildkite/agent/v3: [v3.58.0 → v3.59.0](https://github.com/buildkite/agent/v3/compare/v3.58.0...v3.59.0)
- github.com/buildkite/bintest/v3: [v3.1.1 → v3.2.0](https://github.com/buildkite/bintest/v3/compare/v3.1.1...v3.2.0)
- github.com/cert-manager/cert-manager: [v1.13.2 → v1.13.3](https://github.com/cert-manager/cert-manager/compare/v1.13.2...v1.13.3)
- github.com/containers/common: [v0.57.0 → v0.57.1](https://github.com/containers/common/compare/v0.57.0...v0.57.1)
- github.com/ebitengine/purego: [v0.5.0 → v0.5.0-alpha.1](https://github.com/ebitengine/purego/compare/v0.5.0...v0.5.0-alpha.1)
- github.com/felixge/httpsnoop: [v1.0.3 → v1.0.4](https://github.com/felixge/httpsnoop/compare/v1.0.3...v1.0.4)
- github.com/gabriel-vasile/mimetype: [v1.4.3 → v1.4.2](https://github.com/gabriel-vasile/mimetype/compare/v1.4.3...v1.4.2)
- github.com/go-openapi/spec: [v0.20.9 → v0.20.11](https://github.com/go-openapi/spec/compare/v0.20.9...v0.20.11)
- github.com/go-openapi/strfmt: [v0.21.7 → v0.21.8](https://github.com/go-openapi/strfmt/compare/v0.21.7...v0.21.8)
- github.com/go-openapi/validate: [v0.22.1 → v0.22.3](https://github.com/go-openapi/validate/compare/v0.22.1...v0.22.3)
- github.com/go-rod/rod: [v0.114.4 → v0.114.5](https://github.com/go-rod/rod/compare/v0.114.4...v0.114.5)
- github.com/google/go-tpm-tools: [v0.4.1 → v0.4.2](https://github.com/google/go-tpm-tools/compare/v0.4.1...v0.4.2)
- github.com/gorilla/mux: [v1.8.0 → v1.8.1](https://github.com/gorilla/mux/compare/v1.8.0...v1.8.1)
- github.com/hashicorp/go-retryablehttp: [v0.7.4 → v0.7.5](https://github.com/hashicorp/go-retryablehttp/compare/v0.7.4...v0.7.5)
- github.com/jellydator/ttlcache/v3: [v3.1.0 → v3.1.1](https://github.com/jellydator/ttlcache/v3/compare/v3.1.0...v3.1.1)
- github.com/montanaflynn/stats: [v0.6.6 → 1bf9dbc](https://github.com/montanaflynn/stats/compare/v0.6.6...1bf9dbc)
- github.com/open-policy-agent/opa: [v0.58.0 → v0.59.0](https://github.com/open-policy-agent/opa/compare/v0.58.0...v0.59.0)
- github.com/pierrec/lz4/v4: [v4.1.18 → v4.1.2](https://github.com/pierrec/lz4/v4/compare/v4.1.18...v4.1.2)
- github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring: [v0.69.1 → v0.70.0](https://github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring/compare/v0.69.1...v0.70.0)
- github.com/sigstore/cosign/v2: [v2.2.1 → v2.2.2](https://github.com/sigstore/cosign/v2/compare/v2.2.1...v2.2.2)
- github.com/sigstore/rekor: [v1.3.3 → v1.3.4](https://github.com/sigstore/rekor/compare/v1.3.3...v1.3.4)
- github.com/sigstore/sigstore/pkg/signature/kms/aws: [v1.7.5 → v1.7.6](https://github.com/sigstore/sigstore/pkg/signature/kms/aws/compare/v1.7.5...v1.7.6)
- github.com/sigstore/sigstore/pkg/signature/kms/azure: [v1.7.5 → v1.7.6](https://github.com/sigstore/sigstore/pkg/signature/kms/azure/compare/v1.7.5...v1.7.6)
- github.com/sigstore/sigstore/pkg/signature/kms/gcp: [v1.7.5 → v1.7.6](https://github.com/sigstore/sigstore/pkg/signature/kms/gcp/compare/v1.7.5...v1.7.6)
- github.com/sigstore/sigstore/pkg/signature/kms/hashivault: [v1.7.5 → v1.7.6](https://github.com/sigstore/sigstore/pkg/signature/kms/hashivault/compare/v1.7.5...v1.7.6)
- github.com/sigstore/sigstore: [v1.7.5 → v1.7.6](https://github.com/sigstore/sigstore/compare/v1.7.5...v1.7.6)
- github.com/stretchr/objx: [v0.5.1 → v0.5.0](https://github.com/stretchr/objx/compare/v0.5.1...v0.5.0)
- github.com/theupdateframework/go-tuf: [v0.6.1 → v0.7.0](https://github.com/theupdateframework/go-tuf/compare/v0.6.1...v0.7.0)
- github.com/tidwall/pretty: [v1.2.1 → v1.2.0](https://github.com/tidwall/pretty/compare/v1.2.1...v1.2.0)
- github.com/urfave/cli/v2: [v2.25.7 → v2.26.0](https://github.com/urfave/cli/v2/compare/v2.25.7...v2.26.0)
- github.com/xanzy/go-gitlab: [v0.93.2 → v0.94.0](https://github.com/xanzy/go-gitlab/compare/v0.93.2...v0.94.0)
- go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc: v0.45.0 → v0.46.0
- go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp: v0.45.0 → v0.46.1
- go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc: v1.19.0 → v1.21.0
- go.opentelemetry.io/otel/exporters/otlp/otlptrace: v1.19.0 → v1.21.0
- go.opentelemetry.io/otel/metric: v1.19.0 → v1.21.0
- go.opentelemetry.io/otel/sdk: v1.19.0 → v1.21.0
- go.opentelemetry.io/otel/trace: v1.19.0 → v1.21.0
- go.opentelemetry.io/otel: v1.19.0 → v1.21.0
- go.step.sm/crypto: v0.36.1 → v0.38.0
- golang.org/x/crypto: v0.16.0 → v0.17.0
- golang.org/x/exp: 7918f67 → 2478ac8
- golang.org/x/oauth2: v0.13.0 → v0.15.0
- golang.org/x/time: v0.3.0 → v0.5.0
- golang.org/x/tools: v0.14.0 → v0.15.0
- google.golang.org/api: v0.149.0 → v0.152.0
- google.golang.org/genproto/googleapis/api: 49dd2c1 → bbf56f3
- google.golang.org/genproto/googleapis/bytestream: d783a09 → 83a465c
- google.golang.org/genproto/googleapis/rpc: 49dd2c1 → 83a465c
- google.golang.org/genproto: 49dd2c1 → bbf56f3
- google.golang.org/grpc: v1.59.0 → v1.60.1
- k8s.io/api: v0.28.4 → v0.29.0
- k8s.io/apiextensions-apiserver: v0.28.3 → v0.28.4
- k8s.io/apimachinery: v0.28.4 → v0.29.0
- k8s.io/apiserver: v0.28.3 → v0.28.4
- k8s.io/cli-runtime: v0.28.4 → v0.29.0
- k8s.io/client-go: v0.28.4 → v0.29.0
- k8s.io/code-generator: v0.28.3 → v0.28.4
- k8s.io/component-base: v0.28.3 → v0.28.4
- k8s.io/kms: v0.28.3 → v0.28.4
- k8s.io/utils: 3b25d92 → b307cd5
- sigs.k8s.io/structured-merge-diff/v4: v4.3.0 → v4.4.1

### Removed
- github.com/99designs/gqlgen: [v0.17.36](https://github.com/99designs/gqlgen/tree/v0.17.36)
- github.com/DataDog/gostackparse: [v0.7.0](https://github.com/DataDog/gostackparse/tree/v0.7.0)
- github.com/IBM/sarama: [v1.40.0](https://github.com/IBM/sarama/tree/v1.40.0)
- github.com/Shopify/sarama: [v1.38.1](https://github.com/Shopify/sarama/tree/v1.38.1)
- github.com/aws/aws-sdk-go-v2/service/dynamodb: [v1.21.4](https://github.com/aws/aws-sdk-go-v2/service/dynamodb/tree/v1.21.4)
- github.com/aws/aws-sdk-go-v2/service/ec2: [v1.93.2](https://github.com/aws/aws-sdk-go-v2/service/ec2/tree/v1.93.2)
- github.com/aws/aws-sdk-go-v2/service/eventbridge: [v1.20.4](https://github.com/aws/aws-sdk-go-v2/service/eventbridge/tree/v1.20.4)
- github.com/aws/aws-sdk-go-v2/service/internal/endpoint-discovery: [v1.7.34](https://github.com/aws/aws-sdk-go-v2/service/internal/endpoint-discovery/tree/v1.7.34)
- github.com/aws/aws-sdk-go-v2/service/kinesis: [v1.18.4](https://github.com/aws/aws-sdk-go-v2/service/kinesis/tree/v1.18.4)
- github.com/aws/aws-sdk-go-v2/service/sfn: [v1.19.4](https://github.com/aws/aws-sdk-go-v2/service/sfn/tree/v1.19.4)
- github.com/aws/aws-sdk-go-v2/service/sns: [v1.21.4](https://github.com/aws/aws-sdk-go-v2/service/sns/tree/v1.21.4)
- github.com/aws/aws-sdk-go-v2/service/sqs: [v1.24.4](https://github.com/aws/aws-sdk-go-v2/service/sqs/tree/v1.24.4)
- github.com/bradfitz/gomemcache: [acc6962](https://github.com/bradfitz/gomemcache/tree/acc6962)
- github.com/bytedance/sonic: [v1.10.0](https://github.com/bytedance/sonic/tree/v1.10.0)
- github.com/chenzhuoyu/base64x: [296ad89](https://github.com/chenzhuoyu/base64x/tree/296ad89)
- github.com/chenzhuoyu/iasm: [v0.9.0](https://github.com/chenzhuoyu/iasm/tree/v0.9.0)
- github.com/confluentinc/confluent-kafka-go/v2: [v2.2.0](https://github.com/confluentinc/confluent-kafka-go/v2/tree/v2.2.0)
- github.com/confluentinc/confluent-kafka-go: [v1.9.2](https://github.com/confluentinc/confluent-kafka-go/tree/v1.9.2)
- github.com/decred/dcrd/crypto/blake256: [v1.0.1](https://github.com/decred/dcrd/crypto/blake256/tree/v1.0.1)
- github.com/denisenkom/go-mssqldb: [v0.11.0](https://github.com/denisenkom/go-mssqldb/tree/v0.11.0)
- github.com/dimfeld/httptreemux/v5: [v5.5.0](https://github.com/dimfeld/httptreemux/v5/tree/v5.5.0)
- github.com/dvyukov/go-fuzz: [6a8e9d1](https://github.com/dvyukov/go-fuzz/tree/6a8e9d1)
- github.com/eapache/go-resiliency: [v1.4.0](https://github.com/eapache/go-resiliency/tree/v1.4.0)
- github.com/eapache/go-xerial-snappy: [c322873](https://github.com/eapache/go-xerial-snappy/tree/c322873)
- github.com/eapache/queue: [v1.1.0](https://github.com/eapache/queue/tree/v1.1.0)
- github.com/elastic/elastic-transport-go/v8: [v8.1.0](https://github.com/elastic/elastic-transport-go/v8/tree/v8.1.0)
- github.com/elastic/go-elasticsearch/v6: [v6.8.5](https://github.com/elastic/go-elasticsearch/v6/tree/v6.8.5)
- github.com/elastic/go-elasticsearch/v7: [v7.17.1](https://github.com/elastic/go-elasticsearch/v7/tree/v7.17.1)
- github.com/elastic/go-elasticsearch/v8: [v8.4.0](https://github.com/elastic/go-elasticsearch/v8/tree/v8.4.0)
- github.com/emicklei/go-restful: [v2.16.0+incompatible](https://github.com/emicklei/go-restful/tree/v2.16.0)
- github.com/garyburd/redigo: [v1.6.4](https://github.com/garyburd/redigo/tree/v1.6.4)
- github.com/gin-contrib/sse: [v0.1.0](https://github.com/gin-contrib/sse/tree/v0.1.0)
- github.com/gin-gonic/gin: [v1.9.1](https://github.com/gin-gonic/gin/tree/v1.9.1)
- github.com/globalsign/mgo: [eeefdec](https://github.com/globalsign/mgo/tree/eeefdec)
- github.com/go-pg/pg/v10: [v10.11.1](https://github.com/go-pg/pg/v10/tree/v10.11.1)
- github.com/go-pg/zerochecker: [v0.2.0](https://github.com/go-pg/zerochecker/tree/v0.2.0)
- github.com/go-playground/assert/v2: [v2.2.0](https://github.com/go-playground/assert/v2/tree/v2.2.0)
- github.com/go-redis/redis/v7: [v7.4.1](https://github.com/go-redis/redis/v7/tree/v7.4.1)
- github.com/go-redis/redis/v8: [v8.11.5](https://github.com/go-redis/redis/v8/tree/v8.11.5)
- github.com/go-redis/redis: [v6.15.9+incompatible](https://github.com/go-redis/redis/tree/v6.15.9)
- github.com/go-stack/stack: [v1.8.0](https://github.com/go-stack/stack/tree/v1.8.0)
- github.com/gobuffalo/attrs: [a9411de](https://github.com/gobuffalo/attrs/tree/a9411de)
- github.com/gobuffalo/depgen: [v0.1.0](https://github.com/gobuffalo/depgen/tree/v0.1.0)
- github.com/gobuffalo/envy: [v1.7.0](https://github.com/gobuffalo/envy/tree/v1.7.0)
- github.com/gobuffalo/genny: [v0.1.1](https://github.com/gobuffalo/genny/tree/v0.1.1)
- github.com/gobuffalo/gitgen: [cc08618](https://github.com/gobuffalo/gitgen/tree/cc08618)
- github.com/gobuffalo/gogen: [v0.1.1](https://github.com/gobuffalo/gogen/tree/v0.1.1)
- github.com/gobuffalo/logger: [86e12af](https://github.com/gobuffalo/logger/tree/86e12af)
- github.com/gobuffalo/mapi: [v1.0.2](https://github.com/gobuffalo/mapi/tree/v1.0.2)
- github.com/gobuffalo/packd: [v0.1.0](https://github.com/gobuffalo/packd/tree/v0.1.0)
- github.com/gobuffalo/packr/v2: [v2.2.0](https://github.com/gobuffalo/packr/v2/tree/v2.2.0)
- github.com/gobuffalo/syncx: [33c2958](https://github.com/gobuffalo/syncx/tree/33c2958)
- github.com/gocql/gocql: [0eacd31](https://github.com/gocql/gocql/tree/0eacd31)
- github.com/gofiber/fiber/v2: [v2.50.0](https://github.com/gofiber/fiber/v2/tree/v2.50.0)
- github.com/gofrs/uuid: [v4.4.0+incompatible](https://github.com/gofrs/uuid/tree/v4.4.0)
- github.com/golang-sql/civil: [b832511](https://github.com/golang-sql/civil/tree/b832511)
- github.com/golang-sql/sqlexp: [v0.1.0](https://github.com/golang-sql/sqlexp/tree/v0.1.0)
- github.com/gomodule/redigo: [v1.8.9](https://github.com/gomodule/redigo/tree/v1.8.9)
- github.com/googleapis/gnostic: [v0.5.5](https://github.com/googleapis/gnostic/tree/v0.5.5)
- github.com/graph-gophers/graphql-go: [v1.5.0](https://github.com/graph-gophers/graphql-go/tree/v1.5.0)
- github.com/hailocab/go-hostpool: [e80d13c](https://github.com/hailocab/go-hostpool/tree/e80d13c)
- github.com/hashicorp/go-uuid: [v1.0.3](https://github.com/hashicorp/go-uuid/tree/v1.0.3)
- github.com/hashicorp/golang-lru/v2: [v2.0.3](https://github.com/hashicorp/golang-lru/v2/tree/v2.0.3)
- github.com/jackc/pgpassfile: [v1.0.0](https://github.com/jackc/pgpassfile/tree/v1.0.0)
- github.com/jackc/pgservicefile: [091c0ba](https://github.com/jackc/pgservicefile/tree/091c0ba)
- github.com/jackc/pgx/v5: [v5.3.1](https://github.com/jackc/pgx/v5/tree/v5.3.1)
- github.com/jcmturner/aescts/v2: [v2.0.0](https://github.com/jcmturner/aescts/v2/tree/v2.0.0)
- github.com/jcmturner/dnsutils/v2: [v2.0.0](https://github.com/jcmturner/dnsutils/v2/tree/v2.0.0)
- github.com/jcmturner/gofork: [v1.7.6](https://github.com/jcmturner/gofork/tree/v1.7.6)
- github.com/jcmturner/gokrb5/v8: [v8.4.4](https://github.com/jcmturner/gokrb5/v8/tree/v8.4.4)
- github.com/jcmturner/rpc/v2: [v2.0.3](https://github.com/jcmturner/rpc/v2/tree/v2.0.3)
- github.com/jinzhu/gorm: [v1.9.16](https://github.com/jinzhu/gorm/tree/v1.9.16)
- github.com/jinzhu/inflection: [v1.0.0](https://github.com/jinzhu/inflection/tree/v1.0.0)
- github.com/jinzhu/now: [v1.1.5](https://github.com/jinzhu/now/tree/v1.1.5)
- github.com/joho/godotenv: [v1.3.0](https://github.com/joho/godotenv/tree/v1.3.0)
- github.com/karrick/godirwalk: [v1.10.3](https://github.com/karrick/godirwalk/tree/v1.10.3)
- github.com/klauspost/cpuid/v2: [v2.2.5](https://github.com/klauspost/cpuid/v2/tree/v2.2.5)
- github.com/konsorten/go-windows-terminal-sequences: [v1.0.2](https://github.com/konsorten/go-windows-terminal-sequences/tree/v1.0.2)
- github.com/labstack/echo/v4: [v4.11.1](https://github.com/labstack/echo/v4/tree/v4.11.1)
- github.com/labstack/echo: [v3.3.10+incompatible](https://github.com/labstack/echo/tree/v3.3.10)
- github.com/labstack/gommon: [v0.4.0](https://github.com/labstack/gommon/tree/v0.4.0)
- github.com/markbates/oncer: [bf2de49](https://github.com/markbates/oncer/tree/bf2de49)
- github.com/markbates/safe: [v1.0.1](https://github.com/markbates/safe/tree/v1.0.1)
- github.com/microsoft/go-mssqldb: [v0.21.0](https://github.com/microsoft/go-mssqldb/tree/v0.21.0)
- github.com/richardartoul/molecule: [32cfee0](https://github.com/richardartoul/molecule/tree/32cfee0)
- github.com/segmentio/kafka-go: [v0.4.42](https://github.com/segmentio/kafka-go/tree/v0.4.42)
- github.com/spaolacci/murmur3: [v1.1.0](https://github.com/spaolacci/murmur3/tree/v1.1.0)
- github.com/tidwall/btree: [v1.6.0](https://github.com/tidwall/btree/tree/v1.6.0)
- github.com/tidwall/buntdb: [v1.3.0](https://github.com/tidwall/buntdb/tree/v1.3.0)
- github.com/tidwall/gjson: [v1.16.0](https://github.com/tidwall/gjson/tree/v1.16.0)
- github.com/tidwall/grect: [v0.1.4](https://github.com/tidwall/grect/tree/v0.1.4)
- github.com/tidwall/match: [v1.1.1](https://github.com/tidwall/match/tree/v1.1.1)
- github.com/tidwall/rtred: [v0.1.2](https://github.com/tidwall/rtred/tree/v0.1.2)
- github.com/tidwall/tinyqueue: [v0.1.1](https://github.com/tidwall/tinyqueue/tree/v0.1.1)
- github.com/tmthrgd/go-hex: [447a304](https://github.com/tmthrgd/go-hex/tree/447a304)
- github.com/twitchtv/twirp: [v8.1.3+incompatible](https://github.com/twitchtv/twirp/tree/v8.1.3)
- github.com/twitchyliquid64/golang-asm: [v0.15.1](https://github.com/twitchyliquid64/golang-asm/tree/v0.15.1)
- github.com/ugorji/go/codec: [v1.2.11](https://github.com/ugorji/go/codec/tree/v1.2.11)
- github.com/valyala/bytebufferpool: [v1.0.0](https://github.com/valyala/bytebufferpool/tree/v1.0.0)
- github.com/valyala/fasthttp: [v1.50.0](https://github.com/valyala/fasthttp/tree/v1.50.0)
- github.com/valyala/fasttemplate: [v1.2.2](https://github.com/valyala/fasttemplate/tree/v1.2.2)
- github.com/valyala/tcplisten: [v1.0.0](https://github.com/valyala/tcplisten/tree/v1.0.0)
- github.com/vmihailenco/bufpool: [v0.1.11](https://github.com/vmihailenco/bufpool/tree/v0.1.11)
- github.com/vmihailenco/msgpack/v5: [v5.3.5](https://github.com/vmihailenco/msgpack/v5/tree/v5.3.5)
- github.com/vmihailenco/tagparser/v2: [v2.0.0](https://github.com/vmihailenco/tagparser/v2/tree/v2.0.0)
- github.com/vmihailenco/tagparser: [v0.1.2](https://github.com/vmihailenco/tagparser/tree/v0.1.2)
- github.com/zenazn/goji: [v1.0.1](https://github.com/zenazn/goji/tree/v1.0.1)
- golang.org/x/arch: v0.4.0
- gopkg.in/jinzhu/gorm.v1: v1.9.2
- gopkg.in/olivere/elastic.v3: v3.0.75
- gopkg.in/olivere/elastic.v5: v5.0.84
- gorm.io/driver/mysql: v1.0.1
- gorm.io/driver/postgres: v1.4.6
- gorm.io/driver/sqlserver: v1.4.2
- gorm.io/gorm: v1.25.3
- honnef.co/go/gotraceui: v0.2.0
- mellium.im/sasl: v0.3.1

Done


text:
Update readme to reflect move from incubator to stable for cockroachdb

CockroachDB is now in stable. Updated the install section, and one more place referring to the incubator.
/cc @a-robinson Does this look ok?

/assign @mattfarina

The build failed because I didn't bump the chart version. I've only updated README.md should I still update the chart version? If I do, I'll wait for #3769 to be merged first.

Thanks @hvaara! This LGTM. Feel free to use the same version number as #3769, I can update that one if this gets in first.
/ok-to-test
/lgtm
/approve

@a-robinson Thanks a lot for taking a look! I've updated the chart version.

/lgtm

source: gharchive/pull-request

authors: a-robinson hvaara unguiculus

repo: kubernetes/charts

license_type: permissive

license_source: github-api


text:
[occm] Node ExternalIP not being added

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
Attempting to switch from in-tree cloud provider to occm. The nodes don't have external IP's as revealed with kubectl get nodes -o wide:
NAME                             STATUS   ROLES                      AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION     CONTAINER-RUNTIME
tf-rancher-cluster-demo-test-1   Ready    controlplane,etcd,worker   58m   v1.21.5   10.0.0.9      <none>        Ubuntu 18.04.6 LTS   5.4.0-91-generic   docker://20.10.11
tf-rancher-cluster-demo-test-2   Ready    controlplane,etcd,worker   27d   v1.21.5   10.0.0.13     <none>        Ubuntu 18.04.6 LTS   5.4.0-91-generic   docker://20.10.11
tf-rancher-cluster-demo-test-3   Ready    controlplane,etcd,worker   27d   v1.21.5   10.0.0.18     <none>        Ubuntu 18.04.6 LTS   5.4.0-91-generic   docker://20.10.11

The name of the single floating network is specified under public-network-name in the cloud.conf and when logging verbosity is increase to --v=4, occm is detecting the floating IPs (relevant instances.go entries):
...
I0324 19:55:31.297534       1 instances.go:72] openstack.Instances() called
I0324 19:55:31.297569       1 instances.go:131] NodeAddressesByProviderID () called
I0324 19:55:31.297898       1 instances.go:116] NodeAddresses(tf-rancher-cluster-demo-test-1) called
I0324 19:55:31.633329       1 instances.go:123] NodeAddresses(tf-rancher-cluster-demo-test-1) => [{InternalIP 10.0.0.9} {ExternalIP 10.102.2.147}]
...

What you expected to happen:
The actual node resources have external IPs
How to reproduce it:
I don't believe I'm doing anything out of the ordinary. This is a plain install from scratch with no other workloads.
Anything else we need to know?:
N/A
Environment:

openstack-cloud-controller-manager(or other related binary) version: 1.23 (using the chart)
OpenStack version: Queens
Others: k8s, os, and kernel versions are in the above snippets

do you have floating ip set and which version you are using ?
$ kubectl get nodes -o wide
NAME   STATUS   ROLES                  AGE   VERSION   INTERNAL-IP   EXTERNAL-IP    OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
m2     Ready    control-plane,master   16d   v1.23.4   10.0.0.40     172.24.4.241   Ubuntu 18.04.6 LTS   4.15.0-167-generic   docker://20.10.12

# nova list

`...
| f40cf042-3788-414d-8f06-efbd58e09da5 | m2   | ACTIVE | -          | Running     | private=10.0.0.40, fd81:d720:65dd:0:f816:3eff:fe85:4f98, 172.24.4.241
...

$ kubectl get pod openstack-cloud-controller-manager-5n8fg -n kube-system -o yaml | grep image
    image: docker.io/k8scloudprovider/openstack-cloud-controller-manager:latest

I was on 1.23, but I just switched to latest and there is no change.
Yes, the nodes have floating IPs:
+--------------------------------------+--------------------------------+--------+------------+-------------+----------------------------------------------------------+
| ID                                   | Name                           | Status | Task State | Power State | Networks                                                 |
+--------------------------------------+--------------------------------+--------+------------+-------------+----------------------------------------------------------+
| e5817584-7fc5-4900-a1ff-d6c7f01227e9 | tf-rancher-cluster-demo-test-1 | ACTIVE | -          | Running     | tf-rancher-cluster-demo-test-net=10.0.0.9, 10.102.2.147  |
| 816972e2-3b6e-4b9f-b69e-ec834573db2f | tf-rancher-cluster-demo-test-2 | ACTIVE | -          | Running     | tf-rancher-cluster-demo-test-net=10.0.0.13, 10.102.2.100 |
| 1815fbe4-5a8e-4a78-a256-b022c3435e66 | tf-rancher-cluster-demo-test-3 | ACTIVE | -          | Running     | tf-rancher-cluster-demo-test-net=10.0.0.18, 10.102.2.84  |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+

And in horizon:

um... I think there might be some pre-condition not satisfied
can you enable v==5 first then check whether there are any suspected logs might worth a look?
https://github.com/kubernetes/cloud-provider/blob/master/controllers/node/node_controller.go#L323
is the code that set the node address, there are multiple checks and I guess some might break the logic in updating the ip...

@vowywowy so, can you help paste full log of OCCM with --v = 4 so it might contains more info? Thanks

Thanks for these messages! They ended up sending me down a rabbit hole to the solution.
As you can probably guess based on the naming, everything here is terraform/rancher/rke. When I switched the cluster resource to stop using the in-tree cloud provider, somehow kubelet ended up with the flag --cloud-provider= which is obviously not correct.
For anyone in the same position as me, instead of doing this to the rancher_cluster resource:
resource "rancher_cluster" "example" {
  rke_config {
	cloud_provider {}
	# cloud_provider {
	#   openstack_cloud_provider {
	#     ...
	#   }
	# }
    ...
  }
  ...
}

do this:
resource "rancher_cluster" "example" {
  rke_config {
	cloud_provider { name = "external" } # <-- very important "name" attribute
	# cloud_provider {
	#   openstack_cloud_provider {
	#     ...
	#   }
	# }
    ...
  }
  ...
}

The name field has poor documentation, and is only semi-alluded to in the rke provider (not the rancher2 provider). If you want to use an out-of-tree cloud provider, you have to name it external.
Thanks again @jichenjc! Closing, since this was just user error.

ok, glad it's solved :)  and yes, seems it's user input instead of OCCM

source: gharchive/issue

authors: jichenjc vowywowy

repo: kubernetes/cloud-provider-openstack

license_source: bigquery


text:
cluster-autoscaler assumes kube-system as its namespace

I'm trying to run cluster-autoscaler in a namespace other than kube-system and get below error:
leaderelection.go:210] failed to renew lease kube-system/cluster-autoscaler
The leaderElection section assumes that cluster-autoscaler is running in kube-system namespace. It should lookup the namespace OR at-least update the ReadMe to mention that this will only run in kube-system namespace.

Hi @dhawal55!
AFAIK, there's --namespace flag as of today, to override the namespace to which CA is scheduled, to whatever you'd like.
Would it solve your problem?

Oh great, that's what I was looking for. Closing the issue

repo: kubernetes/contrib


text:
Update deploy of grafana with version 4.4.1.

Upgrade grafana version to 4.4.1 in the deploy file.

This change is

/assign @piosz

SGTM

/lgtm
Thanks a lot for the fix!

authors: andyxning k8s-reviewable loburm piosz

repo: kubernetes/heapster


text:
Upgrade fails with "already exists"

This happens occasionally:
$ helm upgrade [...] picaxe-staging
Error: UPGRADE FAILED: release: already exists

Log:
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:15 storage.go:94: Listing all releases with filter
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:19 storage.go:133: Getting release history for 'picaxe-staging'
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:19 release_server.go:936: Executing pre-upgrade hooks for picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:19 release_server.go:965: Hooks complete for pre-upgrade picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:19 client.go:398: generating strategic merge patch for *runtime.Unstructured
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:19 client.go:398: generating strategic merge patch for *runtime.Unstructured
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:19 client.go:592: beginning wait for resources with timeout of 5m0s
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 release_server.go:936: Executing post-upgrade hooks for picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 release_server.go:965: Hooks complete for post-upgrade picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 storage.go:53: Updating "picaxe-staging" (v51) in storage
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 storage.go:45: Create release "picaxe-staging" (v52) in storage
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 release_server.go:936: Executing post-upgrade hooks for picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 release_server.go:965: Hooks complete for post-upgrade picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 storage.go:53: Updating "picaxe-staging" (v51) in storage
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 storage.go:45: Create release "picaxe-staging" (v52) in storage
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 release_server.go:936: Executing post-upgrade hooks for picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 release_server.go:965: Hooks complete for post-upgrade picaxe-staging
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 storage.go:53: Updating "picaxe-staging" (v51) in storage
[tiller-deploy-3161650477-5jj7b] 2017/05/04 20:07:31 storage.go:45: Create release "picaxe-staging" (v52) in storage

We don't use any hooks.
Helm 2.3.0, Kubernetes 1.5.6.

Thank you for providing the logs on this. A few questions. How "occasionally" does this occur? Have you tried with helm 2.3.1 or 2.4.1 to see if it solves the problem?

It's only happened 2 times out of about 51 times so far, and it's not consistently reproducible, although I could of course write a stress-test script.
Only tried 2.3.0. Just installed 2.4.1, will let you know if it happens again.

That typically happens if the release name is already present and being used. Do you have the --install flag set? Does the error only happen after an upgrade fails (or when the last upgrade is still in progres)?

Yes, we started using helm upgrade --install. And the release already exists when this happens.

@thomastaylor312  @technosophos  I'm facing the same issue here, I can't do an upgrade over an existing resource, even thought I used hooks.
For instance, I already installed a release named myproject that had a secret
kind: Secret
metadata:
  name: secret
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
  labels:
    app: {{ .Values.global.environment.app }}
    environment: {{ $env }}
type: Opaque
{{- end }}

when I do   helm upgrade --install --force project --tiller-namespace dev dev/ I got this as result
Error: UPGRADE FAILED: secrets "secret" already exists
Logs of Tiller:
[tiller] 2019/03/20 10:51:39 creating updated release for project
[storage] 2019/03/20 10:51:39 creating release "project.v2"
[tiller] 2019/03/20 10:51:39 performing update for project
[tiller] 2019/03/20 10:51:39 executing 2 pre-upgrade hooks for project
[kube] 2019/03/20 10:51:39 building resources from manifest
[kube] 2019/03/20 10:51:40 creating 1 resource(s)
[tiller] 2019/03/20 10:51:40 warning: Release project pre-upgrade project/templates/secret.yaml failed: secrets "secret" already exists
[storage] 2019/03/20 10:58:34 listing all releases with filter

Any help for this issue ?
Thank you

I have encountered the same issue in Helm 3:
client.go:87: [debug] creating 377 resource(s)
Error: secrets "helm3-test-rabbitmq" already exists
helm.go:76: [debug] secrets "helm3-test-rabbitmq" already exists

I have run helm upgrade --install, so the namespace is nearly empty...

@tomislater We need a little more information to debug that. Is the secret managed as a hook, or as a regular resource? If you can give us content of the secret's metadata, that might be helpful in figuring out why it is not upgrading. But if it is a hook, its behavior is subject to all the caveats described in the manual. Attempting to install over an existing secret that was created by a hook will still not work.
Again, though, I'm guessing about what your chart is trying to do... we really need more info to be able to provide any meaningful feedback. I would recommend opening a new issue with complete details, because I do not think it is the same issue as the one marked Closed here.

@technosophos You are right, my issue is connected to https://github.com/helm/helm/issues/7093
Sorry for interruption!

repo: kubernetes/helm


text:
Expandybird choking on replicatedservice-3.tgz

jackgr@jackgr-macbookpro:~/gopath/src/github.com/kubernetes/helm> helm deploy --name test1 gs://kubernetes-charts-testing/replicatedservice-v3.tgz
[ERROR] {"status":"Bad Request","message":"cannot expand configuration:expandybird response:\nerror expanding chart: test1: ExpandyBird cannot do this kind of expansion: %!!(MISSING)(EXTRA string=Expandybird)\n\u0026{[0xc2080824e0]}\n"}

/cc @sparkprime

We should probably just remove that check, as it allows deploying several versions of expandybird with different "names".  The expansion service should just assume that the thing it's given is of the kind it's designed to deal with.

Sounds like a good approach. Probably best if you do it, since you know that code better than I do.

Delete this code
    if chartFile.Expander.Name != "ExpandyBird" {
        message := fmt.Sprintf("ExpandyBird cannot do this kind of expansion: ", chartFile.Expander.Name)
        return nil, fmt.Errorf("%s: %s", chartInv.Name, message)
    }

in cmd/expandybird/expander/expander.go

Fixed by #486.

authors: jackgr sparkprime


text:
Add the possibility to delete a full table from values

We had an where users wanted to delete some default configuration from the values.yaml, but it wasn't possible, this fix overcomes that issue, of course, I'm not 100%-ly sure in this implementation, but it is a good topic starter.

@bonifaido would you mind adding unit tests and docs here to cover this use case? Thanks!

authors: bacongobbler bonifaido


text:
fix two doc issues in nginx/README

As discussed with @aledbf , these two doc issues are confirmed, and I'm fixing them smoothly.
Link to issue #1296
Plus, there's another doc issue as described in issue1296 (the 3rd one), we can't really tell differences with or without default-ssl-certificate according to those two curl output examples. They are the almost the same, should be fixed at spare time.

This change is

Coverage remained the same at 43.484% when pulling f6946738f893b35de527ac64f3f32da4b52e64a5 on dunjut:master into 85e1a650090b79c1dc53ce41835f65bc33d81e76 on kubernetes:master.

/lgtm

@dunjut thanks!

authors: aledbf coveralls dunjut k8s-reviewable

repo: kubernetes/ingress


text:
kubectl diff does not report missing ConfigMap keys

I have noticed that when using kubectl diff to compare a YAML file containing a ConfigMap to the current state of the ConfigMap in the cluster, missing key-value pairs in the YAML file that exist in the current state of the ConfigMap are not reported as differences. This can lead to unexpected changes to the ConfigMap when applying the YAML file with kubectl apply.
For example, if a key-value pair exists in the current ConfigMap in the cluster but is not present in the YAML file, and I apply the YAML file with kubectl apply, the key-value pair will be removed from the ConfigMap. However, kubectl diff does not report this as a difference, even though it would result in a change to the ConfigMap. It'll only be listed as changed if the key exist in the file but has a different value than what's in the cluster.
I believe that removing a key-value pair from a ConfigMap is just as much a change as modifying its value. Therefore, I suggest that kubectl diff should report missing ConfigMap keys in the same way that it reports modified values. This would make it easier to identify situations where a key-value pair would be removed from the ConfigMap if the YAML file were applied.
Thank you for your attention to this issue.

@mbehm in which version are you using?, could you please provide steps for reproducing this issue?. Thanks.

Tried to create a small test case to reproduce it and my bad it seems if the key doesn't exist in the new ConfigMap then apply will leave the current value in the cluster as is, I must have accidentally used create or done something to completely overwrite the existing one.
Sorry for the inconvenience, closing the issue.

authors: ardaguclu mbehm

repo: kubernetes/kubectl


text:
Add log-counter plugin written in go

This PR adds a new binary to the node-problem-detector repository: log-counter.
The new binary uses the kmsg log watcher to get kmsg log events, and checks the number of events that occurred.
The binary accepts command-line flags for the pattern, count, and period of time to look back.
It sets the condition NodeRecreationRequired when it sees the unregister_netdevice error 3 times in 20 minutes, and runs every 10 minutes.
/assign @Random-Liu

can you tripple check the changes to the Makefile?  I am not really sure what the proper structure is.  This set of changes is mostly a guess.

This is working now!

/lgtm

authors: Random-Liu dashpole

repo: kubernetes/node-problem-detector


text:
Validate config before running test

What would you like to be added:
Validate if config is correct before running test.
Why is this needed:
Currently, step can be either measurement step or phase step (modules are being added in #1634)
https://github.com/kubernetes/perf-tests/blob/18e90fc65c6b95c0bff96938458a77d74e19b27a/clusterloader2/api/types.go#L60
Unfortunately, this behaviour is not well implemented:
https://github.com/kubernetes/perf-tests/blob/14afe3828ba8d9eaa98aa8a9f5ddd0cdc5f8eebf/clusterloader2/api/extensions.go#L54
https://github.com/kubernetes/perf-tests/blob/14afe3828ba8d9eaa98aa8a9f5ddd0cdc5f8eebf/clusterloader2/pkg/test/simple_test_executor.go#L143
Current implementation does not validate if config is correct before running test.
From user experience perspective it would be much better to return error right after test starts.
Also, If I'm not wrong, if user specifies both measurements and phases, only measurements will be executed.

@marseel could I help out with this one?

@marseel could I help out with this one?

@lyzs90  Yes sure, I would appreciate it :)
If you will have some PR I can help with reviewing.

@lyzs90  Yes sure, I would appreciate it :)
If you will have some PR I can help with reviewing.

@lyzs90 - this long-standing PR is relevant to this one:
https://github.com/kubernetes/perf-tests/pull/142
It shows how should probably approach this problem - feel free to pick it up and continue working on that.

@lyzs90 - this long-standing PR is relevant to this one:
https://github.com/kubernetes/perf-tests/pull/142
It shows how should probably approach this problem - feel free to pick it up and continue working on that.

Thanks @wojtek-t I'll check it out
/assign

Thanks @wojtek-t I'll check it out
/assign

@wojtek-t I had a look at https://github.com/kubernetes/perf-tests/pull/142 and had some thoughts:

Currently Modules are being recursively compiled into steps at runtime. Correct me if I am wrong but the mapping passed to the Module seems static and there is no use case where runtime variables are passed in (unlike Objects). Hence to support validation of Modules, may I suggest to move loading of modules before test execution - after https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/test/test.go#L66, so that validation of the entire Config (less Objects) can be validated ahead of time
I understand that the current style of validation used to keep consistent with k8s, and I'm happy to stick with it. Just wanted to find out what are your thoughts on using a declarative approach like json schema? https://github.com/xeipuuv/gojsonschema

Checks like this and this could be simplified with https://json-schema.org/understanding-json-schema/reference/combining.html#combining-schemas
Basically cuts down on boilerplate, but we may still have to implement some custom validation for things like IsDNS1123Subdomain, file exists at objectTemplatePath, referenced tuning set has been declared etc.

@wojtek-t I had a look at https://github.com/kubernetes/perf-tests/pull/142 and had some thoughts:

Currently Modules are being recursively compiled into steps at runtime. Correct me if I am wrong but the mapping passed to the Module seems static and there is no use case where runtime variables are passed in (unlike Objects). Hence to support validation of Modules, may I suggest to move loading of modules before test execution - after https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/test/test.go#L66, so that validation of the entire Config (less Objects) can be validated ahead of time
I understand that the current style of validation used to keep consistent with k8s, and I'm happy to stick with it. Just wanted to find out what are your thoughts on using a declarative approach like json schema? https://github.com/xeipuuv/gojsonschema

Checks like this and this could be simplified with https://json-schema.org/understanding-json-schema/reference/combining.html#combining-schemas
Basically cuts down on boilerplate, but we may still have to implement some custom validation for things like IsDNS1123Subdomain, file exists at objectTemplatePath, referenced tuning set has been declared etc.

Currently Modules are being recursively compiled into steps at runtime. Correct me if I am wrong but the mapping passed to the Module seems static and there is no use case where runtime variables are passed in (unlike Objects). Hence to support validation of Modules, may I suggest to move loading of modules before test execution - after https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/test/test.go#L66, so that validation of the entire Config (less Objects) can be validated ahead of time

@mm4tt - for thoughts

I understand that the current style of validation used to keep consistent with k8s, and I'm happy to stick with it. Just wanted to find out what are your thoughts on using a declarative approach like json schema? https://github.com/xeipuuv/gojsonschema

The consistency with k8s has a benefit that you don't have to learn new stuff when you're operating in a single k8s ecosystem. I agree that this can reduce the boilerplate, but (a) this boilerplate is well-separated (b) it's fairly trivial, so I don't think it's actually that huge advantage. So I would rather stick to that for now.

Currently Modules are being recursively compiled into steps at runtime. Correct me if I am wrong but the mapping passed to the Module seems static and there is no use case where runtime variables are passed in (unlike Objects). Hence to support validation of Modules, may I suggest to move loading of modules before test execution - after https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/test/test.go#L66, so that validation of the entire Config (less Objects) can be validated ahead of time

@mm4tt - for thoughts

I understand that the current style of validation used to keep consistent with k8s, and I'm happy to stick with it. Just wanted to find out what are your thoughts on using a declarative approach like json schema? https://github.com/xeipuuv/gojsonschema

The consistency with k8s has a benefit that you don't have to learn new stuff when you're operating in a single k8s ecosystem. I agree that this can reduce the boilerplate, but (a) this boilerplate is well-separated (b) it's fairly trivial, so I don't think it's actually that huge advantage. So I would rather stick to that for now.

The consistency with k8s has a benefit that you don't have to learn new stuff when you're operating in a single k8s ecosystem. I agree that this can reduce the boilerplate, but (a) this boilerplate is well-separated (b) it's fairly trivial, so I don't think it's actually that huge advantage. So I would rather stick to that for now.

Noted on this 👍

The consistency with k8s has a benefit that you don't have to learn new stuff when you're operating in a single k8s ecosystem. I agree that this can reduce the boilerplate, but (a) this boilerplate is well-separated (b) it's fairly trivial, so I don't think it's actually that huge advantage. So I would rather stick to that for now.

Noted on this 👍

Currently Modules are being recursively compiled into steps at runtime. Correct me if I am wrong but the mapping passed to the Module seems static and there is no use case where runtime variables are passed in (unlike Objects). Hence to support validation of Modules, may I suggest to move loading of modules before test execution - after https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/test/test.go#L66, so that validation of the entire Config (less Objects) can be validated ahead of time
I think it makes sense, but let's double check with @mm4tt

Currently Modules are being recursively compiled into steps at runtime. Correct me if I am wrong but the mapping passed to the Module seems static and there is no use case where runtime variables are passed in (unlike Objects). Hence to support validation of Modules, may I suggest to move loading of modules before test execution - after https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/test/test.go#L66, so that validation of the entire Config (less Objects) can be validated ahead of time
I think it makes sense, but let's double check with @mm4tt

It makes a lot of sense :) Just a nit, you should move it after this to make sure that the config is valid after a custom modifications have been applied. There is also testConfig.Validate here that we could probably reuse or remove - it doesn't make sense to have two "validate" components.
In general, big +1 for extracting things out of ExecuteTest method. In my opinion, this method is too big. It does too many things and doesn't adhere to the single principle rule - it should just execute the test that is prepared and validated.

It makes a lot of sense :) Just a nit, you should move it after this to make sure that the config is valid after a custom modifications have been applied. There is also testConfig.Validate here that we could probably reuse or remove - it doesn't make sense to have two "validate" components.
In general, big +1 for extracting things out of ExecuteTest method. In my opinion, this method is too big. It does too many things and doesn't adhere to the single principle rule - it should just execute the test that is prepared and validated.

@mm4tt gotcha, I'll first submit a PR to extract module compilation out of ExecuteTest

@mm4tt gotcha, I'll first submit a PR to extract module compilation out of ExecuteTest

@mm4tt Actually since there might be multiple tests (via test suite / config paths), would it be worth moving the compilation and validation logic even higher up eg. before https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/cmd/clusterloader.go#L317 and https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/cmd/clusterloader.go#L323.
That way we can fail faster if any config is invalid. This would mean RunTest would only be left with basic checks, namespace deletion and test execution

@mm4tt Actually since there might be multiple tests (via test suite / config paths), would it be worth moving the compilation and validation logic even higher up eg. before https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/cmd/clusterloader.go#L317 and https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/cmd/clusterloader.go#L323.
That way we can fail faster if any config is invalid. This would mean RunTest would only be left with basic checks, namespace deletion and test execution

Sounds good. Let me know if there is anything I can help you with. Thanks!

Sounds good. Let me know if there is anything I can help you with. Thanks!

repo: kubernetes/perf-tests


text:
Move Eviction Policy into Scheduling & Eviction section

This is a Feature Request

What would you like to be added
Migrate the content from https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy into somewhere inside https://kubernetes.io/docs/concepts/scheduling-eviction/
Why is this needed
https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy is not task documentation; instead, it's conceptual background.
Comments
/language en
/kind cleanup
Initially, a straightforward cut-and-paste would be fine, so I'll mark this as:
/good-first-issue

/assign

@sftim do I need to move all the page content or only the eviction-policy section?

Just the Eviction Policy section. Overall, https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy is a task page and can stay as a task page.

@sftim
Eviction Policy is a kind of a separate concept. I guess it should be an entirely new page in Scheduling and Eviction section, such that it adds an entry in accordion menu as well.

entirely new page in Scheduling and Eviction section

There's more than one way to do this, and that's one of the viable approaches.

If anyone's ready to tackle this: feel free!

/assign

@sftim i am interested to do pick this up.. let me know if these changes are still required?

This work still needs doing. The changes in https://github.com/kubernetes/website/pull/20724/commits/032a7ea337978697dda435e0950fc53d83113695 looked like a good starting point.

/close

@sftim Is this issue ready to close?

Yep
/close

repo: kubernetes/website


text:
Clarify the explanation when environment variables refer to each other

This is a Feature Request

What would you like to be added

Why is this needed
If the environment variables started by the pod are cyclically dependent and mutually referenced, the resulting environment variable values will not be what we expected. At present, there is no detailed description about this in the official document, it is recommended to reopen a page to describe it in detail
Comments

https://github.com/kubernetes/website/pull/21553
https://github.com/kubernetes/kubernetes/issues/90466

/kind feature

/assign

authors: Cweiping sftim wawa0210


text:
Remove docker from Node-pressure Eviction

URL: https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
File: /docs/concepts/scheduling-eviction/node-pressure-eviction.md
Umbrella issue: #30771
Partially fixes: #30921
What to do
On line 238, remove docker from the examples of system daemons.
How to do it
Refer to the Contributor Guide for instructions.
Do the following:

Fork k/website and switch to a new branch
Remove docker from line 238 of the /docs/concepts/scheduling-eviction/node-pressure-eviction.md file
Open a PR for the change and mention this issue to close it when the PR is merged

/triage accepted
/sig docs
/help-wanted
/language en

I would like to work on this

/assign @killerkc12

@killerkc12 do you intend to work on this? If not I'd like to reassign it to someone who will. No hard feelings either way!

@celestehorgan I think this issue has been resolved in this PR here #30913

/close

authors: PurneswarPrasad celestehorgan jihoon-seo killerkc12 shannonxtreme


text:
Pos OS spec description is not clear.

While reading the documentation about the OS spec for Pods it states:

Pod OS
FEATURE STATE: Kubernetes v1.25 [stable]
You should set the .spec.os.name field to either windows or linux to indicate the OS on which you want the pod to run. These two are the only operating systems supported for now by Kubernetes. In future, this list may be expanded.

In Kubernetes v1.26, the value you set for this field has no effect on scheduling of the pods. Setting the .spec.os.name helps to identify the pod OS authoratitively and is used for validation. The kubelet refuses to run a Pod where you have specified a Pod OS, if this isn't the same as the operating system for the node where that kubelet is running. The Pod security standards also use this field to avoid enforcing policies that aren't relevant to that operating system.

The second paragraph mentions 1.26 doesn't take this field into consideration to schedule the pod but later in the same paragraph it states kubelet will take this field in consideration to schedule the pod (assigning the pod to a matching OS node). Am I reading it incorrectly or the paragraph should read "In Kubernetes v1.25, the vaule you set for this field has no effect on scheduling" ?

In Kubernetes v1.26, the value you set for this field has no effect on scheduling of the pods

is correct, but perhaps misleading.
How about changing the order round:
Kubernetes v1.26 uses the value of .spec.os.name to validate Pods (the kubelet checks that the Pod OS matches the operating system that the kubelet is running on). If you create (or try to create a Pod) in a namespace that uses Pod security admission, the control plane also uses the value of .spec.os.name to work out what restrictions to verify and / or enforce.
In Kubernetes v1.26, the value of  .spec.os.name does not affect how the kube-scheduler picks a Pod to run a node. In any cluster where there is more than one operating system for nodes, you should set the kubernetes.io/os label correctly on each nodes, and define Pods with a nodeSelector than matches the correct operating system.
If you set .spec.os.name  anddo not specify a nodeSelector based on the operating system label, the scheduler assigns your pod to a node based on other criteria and may or may not succeed in picking a suitable node placement where the node OS is right for the containers in that Pod.
?

We could link to a task page that explains how to assign Linux Pods to Linux nodes, and Windows Pods to Windows nodes (if we had such a task page).

/sig node

Hi @sftim by your message I understand that:

Kubelet will fail to run a pod with a non matching .spec.os.name in the node that is running (as if a Linux pod is assigned to a Windows Node for example)
Kube-Scheduler will not take into account .spec.os.name to define in which node to run a pod (unless a kubernetes.io/os label is specified) so it would potentially scheduling a Linux pod in a Windows node.

Am I getting it right? if so I believe your message is great to be a replacement of the one in the current documentation.
Just there is a missing space in this paragraph (getting a bit picky sorry 😂 )

If you set .spec.os.name anddo not specify a nodeSelector based on the operating system label, the scheduler assigns your pod to a node based on other criteria and may or may not succeed in picking a suitable node placement where the node OS is right for the containers in that Pod.

This could warrant a PR since the fix is clear.
/help

/triage accepted

/assign

Also see https://github.com/kubernetes/website/issues/40825
/retitle Pod OS spec description is not clear

/assign

authors: javiermarasco madhumita-kundo mrgiles sftim tengqm


text:
[fr] Inactive interactive tutorial in "Deploying an application" page

Tutorial description :

Pour interagir avec le terminal, veuillez utiliser la version bureau / tablette.

Though I am using my desktop.

Page reported in issue (based on issue title): https://kubernetes.io/fr/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/
/language fr

/retitle [fr] Inactive interactive tutorial in "Deploying an application" page
/kind bug
/area localization

@polocto Katacoda environment for the Kubernetes tutorial has been shut down. Refer the announcement here.
We have an umbrella issue raised https://github.com/kubernetes/website/issues/41496 to remove tutorials that rely on Katacoda for all localized documents.

authors: dipesh-rawat polocto


text:
Issue with k8s.io/docs/concepts/storage/dynamic-provisioning/

Requirement is to have new filesystem created on top of the provisioned volumes. Since while we created containers, we need to have say a folder by name "license" where we need to store the license key. Hence my container will expect me to create a folder by name "license". Details of this is not available any where. I guess it should be a feature request

[ x ] Feature Request
[ ] Bug Report

Problem:
Option to create new file and directory under provisioned volumes is missing. Container need this flexibility since the packaged container will have a requirement to have some file and directory available in the host environment
Proposed Solution:
YAML fie should support mkdir and create file option
Page to Update:
https://kubernetes.io/...

hostpath and mountpath needs to be same...as of now , I am not able to create a directory..Hope I am not missing out anything..


text:
Change RedSpread link

Fix #10103
RedSpread was acquired by CoreOS.
The site does not exist. Therefore, I changed to GitHub repository.

I signed CLA.

Preview https://deploy-preview-10124--kubernetes-io-master-staging.netlify.com/docs/setup/minikube/#design

Nice catch! Thank you!
/lgtm
/approve


text:
cluster-myfirst.html

creating new cluster

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.
For 1.14 Features: set Milestone to 1.14 and Base Branch to dev-1.14
For Chinese localization, base branch to release-1.12
For Korean Localization: set Base Branch to dev-1.13-ko.
Help editing and submitting pull requests:
https://kubernetes.io/docs/contribute/start/#improve-existing-content.
Help choosing which branch to use:
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/check-cla

Thanks for the PR @fauwazalijdpro !!!!
Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.
It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

Hey there! @fauwazalijdpro, looks like you haven't signed the CLA yet. Could I please have you do that? https://github.com/kubernetes/community/blob/master/CLA.md

/close
@fauwazalijdpro Thanks for your PR, but we need you to take a few additional steps. if you want to re-open it, or start a new one, please first sign the CLA. It's also not clear why the proposed change is needed. It's true that the topic is pretty generic, but it does also address Minikube specifically and if the issue is the tangle around starting the interactive tutorial vs starting with Minikube, changing the title only does not clear up any confusion.


text:
Update the fine-parallel-processing-work-queue.md task file to remove $ and remvoe text not appropiate for end user

this PR address one task mentioned in https://github.com/kubernetes/website/issues/12740 which is

[ ] https://kubernetes.io/docs/tasks/job/fine-parallel-processing-work-queue/

remove the section about

If you are working from the website source tree, you can go to the following directory and start a temporary Pod running Redis and a service so we can find it.

End user doesn't work from git repo

/assign @steveperry-53

any help here with reviewing please ?

reduced the scope to keep it isolated as per @zacharysarah comment on another PR

/assign @zparnold
/unassign @steveperry-53

/lgtm
/approve


text:
Update minikube.md

It is minor, but I think it is more readable by moving the comments out of the code blocks since it is the document not code.
This is how it looks currently here https://kubernetes.io/docs/setup/minikube/:

@yzhong52 could you please sign the CLA?

@DanyC97 Just signed. Sorry for the delay.

/lgtm

/approve


text:
Update node glossary page

When reviewing the spanish localization for this page #14360, we spotted minor issues with the content.
This PR:

Removes the services tooltip as it points to the Service object and in this context, refers to Kubernetes processes and agents running on the nodes.
Replaces Docker for the Container Runtime interface, as Kubernetes supports other CRI, not only Docker.
Adds the tooltip for each kubernetes service: cri, kubelet, kube-proxy

I just saw your PR #14317 that aims the same thing and the conversation already started there, we can close this PR.
Thanks @sftim !!


text:
Added logo change for blog site

Currently on blog site (https://kubernetes.io/blog/) if you scroll down the page, logo (top left corner) disappears because the background is being changed to white. On the main page, this is fixed by changing the logo to the blue version on scroll down but it wasn't working on blog site. Added the same behaviour.

/retest

/approve
/lgtm


text:
[ko] Update outdated in dev-1.21-ko.8 (M10-M12)

Ref #29253
Task: M10 - M12
M10. content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md | 3(+XS) 3(-)
M11. content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md | 3(+XS) 3(-)
M12. content/en/docs/concepts/services-networking/ingress-controllers.md | 1(+XS) 0(-)

/assign

@pjhwa 리뷰 감사합니다!
리뷰 의견을 반영 (살짝 수정) 하여 PR 업데이트 하였습니다.

/lgtm

/approve

authors: ClaudiaJKang pjhwa seokho-son


text:
removed hyperlink in restrict a container

Removed invalid link in Restrict a container
Under
Securing a Pod  in note Upgrade path to GA
There is no valid link that can be replaced with it

This PR Resolves issue #40865

/lgtm

/lgtm
Please mind our policy on trivial edits @AmarNathChary This is OK to accept; a review of the whole page would be even more helpful

@sftim I understand the importance of the policy and I will make sure to comply. Thanks for the approve.

authors: AmarNathChary tengqm


text:
Add kirkonru to sig-docs-ru

Since we have @kirkonru in the organisation, we can add him to the reviewers and owners list for the Russian localisation :tada:
Related PR: https://github.com/kubernetes/org/pull/4846

Waiting for confirmation from Russian localization approvers

Currently, our approvers' list has me & @Arhell only (that's why we need Kirill so much). Ihor, please assist :pray:

As an ru approver, @Arhell confirmed
/approve

authors: reylejano sftim shurup


text:
Fix NodePodSelector annotation name

Resubmitted to master branch.

I can't tell whether I'm nitpicking or catching an issue here. Should the annotation key be the same wherever you use it? If so, should it be scheduler.alpha.kubernetes.io/node-selector? Or scheduler.alpha.kubernetes.io/nodeSelector?

/assign

@tengqm 👋 looks like this needs a rebase, and I didn't see any answer to @Bradamant3 question about the content.
/assign

Closing because the master branch already has this fix.

authors: Bradamant3 heckj tengqm


text:
panic: runtime error: index out of range [3] with length 3

Using the version installed today using brew on a MAC M1 (seems that brew version is not the latest)
kubescape scan .
[info] ARMO security scanner starting
[warning] current version 'v2.0.166' is not updated to the latest release: 'v2.0.170'
panic: runtime error: index out of range [3] with length 3

goroutine 1 [running]:
github.com/armosec/go-git-url/gitlabparser/v1.(*GitLabURL).Parse(0x140003fc1c0, {0x1400005bc20?, 0x1046a5ce0?})
        github.com/armosec/go-git-url@v0.0.15/gitlabparser/v1/parser.go:89 +0x33c
github.com/armosec/go-git-url/gitlabparser/v1.NewGitLabParserWithURL({0x1400005bc20, 0x3e})
        github.com/armosec/go-git-url@v0.0.15/gitlabparser/v1/parser.go:28 +0x98
github.com/armosec/go-git-url.NewGitURL({0x1400005bc20, 0x3e})
        github.com/armosec/go-git-url@v0.0.15/init.go:28 +0x1b0
github.com/armosec/kubescape/v2/core/cautils.metadataGitLocal({0x16d837657?, 0x3?})
        github.com/armosec/kubescape/v2/core/cautils/scaninfo.go:405 +0xe8
github.com/armosec/kubescape/v2/core/cautils.setContextMetadata(0x14000c3d3f0, {0x16d837657, 0x3})
        github.com/armosec/kubescape/v2/core/cautils/scaninfo.go:358 +0x364
github.com/armosec/kubescape/v2/core/cautils.scanInfoToScanMetadata(0x140002fc4e0)
        github.com/armosec/kubescape/v2/core/cautils/scaninfo.go:289 +0x328
github.com/armosec/kubescape/v2/core/cautils.NewOPASessionObj({0x0, 0x0, 0x0}, 0x0, 0x140002fc4e0)
        github.com/armosec/kubescape/v2/core/cautils/datastructures.go:43 +0x5c
github.com/armosec/kubescape/v2/core/pkg/policyhandler.(*PolicyHandler).CollectResources(0x14000b9b808, {0x14000611500, 0x5, 0x8}, 0x140002fc4e0)
        github.com/armosec/kubescape/v2/core/pkg/policyhandler/handlenotification.go:26 +0x40
github.com/armosec/kubescape/v2/core/core.(*Kubescape).Scan(0x103f05b60?, 0x140002fc4e0)
        github.com/armosec/kubescape/v2/core/core/scan.go:142 +0x618
github.com/armosec/kubescape/v2/cmd/scan.getFrameworkCmd.func2(0x1045bd120?, {0x14000427680, 0x2, 0x140006b1560?})
        github.com/armosec/kubescape/v2/cmd/scan/framework.go:102 +0x3ac
github.com/armosec/kubescape/v2/cmd/scan.GetScanCommand.func1(0x140000ff680?, {0x140006b1560, 0x1, 0x1?})
        github.com/armosec/kubescape/v2/cmd/scan/scan.go:45 +0x180
github.com/spf13/cobra.(*Command).ValidateArgs(...)
        github.com/spf13/cobra@v1.5.0/command.go:1018
github.com/spf13/cobra.(*Command).execute(0x140000ff680?, {0x140006b1540?, 0x1?, 0x1?})
        github.com/spf13/cobra@v1.5.0/command.go:841 +0x3a4
github.com/spf13/cobra.(*Command).ExecuteC(0x140000ff400)
        github.com/spf13/cobra@v1.5.0/command.go:990 +0x354
github.com/spf13/cobra.(*Command).Execute(...)
        github.com/spf13/cobra@v1.5.0/command.go:918
github.com/armosec/kubescape/v2/cmd.Execute()
        github.com/armosec/kubescape/v2/cmd/root.go:84 +0x34
main.main()
        github.com/armosec/kubescape/v2/main.go:9 +0x1c

This also happens with the latest v2.0.170 release as well.

origin	git@gitlab.com:foobar/machine-learning/cluster-manifests.git (fetch)
origin	git@gitlab.com:foobar/machine-learning/cluster-manifests.git (push)

This bug occurs on GitLab with versions v2.0.165-172. Version v2.0.164 seems to work, so until patch is ready will resort to use that.

@dazzag24 Have you done here any progress?

@dazzag24 Have you done here any progress?

I think Aman123lug volunteered to work on this.

@Aman123lug Any updates?

@dwertent hello. I've looked at it briefly and the offending line is: https://github.com/kubescape/go-git-url/blame/master/gitlabparser/v1/parser.go#L86
Wrapping it with a check on the "-" particular path part is enough to avoid a panic:
	if splittedRepo[index] == "-" {
		index += 1 // skip "-" symbol in URL
	}

However, I am not really sure about the consistency of the eventual result. This parser obviously is not designed in the first place to support general URLs.

@Aman123lug Any updates?

I think @dazzag24 working on it

Also I've detected that there are 2 versions of this go-git-url repo being used: one under the kubescape owner, one under the armosec owner: while the armosec version is still being pulled as a direct dependency, the other version is pulled indirectly...

I have a small patch ready if you guys are interested. This assumes a few things. I'd need a piece of advice to be sure I am heading in the right direction.  I wouldn't want to interfere with some other people's work. Let me know if you want a PR (actually 2 since 2 repos are concerned).

kubescape/go-git-url: added the simple check above. In the case of such "scp-like" git-urls, it no longer panics if the input is not exactly as expected. However, the OP-provided remote ```````````git@gitlab.com:foobar/machine-learning/cluster-manifests.git`  won't really work as expected: in this example, "foobar" is considered the owner, "machine learning" the repo and "cluster..." the branch.
With a correct origin like so  "git@gitlab.com:gitlab-tests/sample-project.git", the owner & repo are inferred correctly.
I am not sure that this is acceptable behavior.
Parsed "pseudo-URL" results in :

=== RUN   TestFred
    fred_test.go:26: remote: git@gitlab.com:foobar/gitlab-tests/sample-project.git
(*v1.GitLabURL)(0xc00030a380)({
 host: (string) (len=10) "gitlab.com",
 owner: (string) (len=6) "foobar",
 repo: (string) (len=12) "gitlab-tests",
 project: (string) "",
 branch: (string) (len=18) "sample-project.git",
 path: (string) "",
 token: (string) ""
})
--- PASS: TestFred (0.00s)
PASS

kubescape/kubescape: replaced deps on github.com/armosec/go-git-url by github.com/kubescape/go-git-url (both repos are the same right now).  I assume this is the right repo to look into. Will need to upgrade dep on go-git-url.

@dwertent  here is a proposal for a fix. @dazzag24, @Aman123lug  feel free to discard this if you've already started something better. For sure, the fix is not perfect: just assuring that wrong/unexpected input doesn't panic the CLI.

repo: kubescape/kubescape


text:
Create separate Form editor for common metadata properties

Since every Resource Kind has a metadata section with the same properties we can put these in a separate Form in the Form Editor - this form would be in a collapsable "Resource Metadata" section at the top of the panel - with the unique resource properties shown in a separate Form below

as discussed - lets move this into a separate tab instead of a section on top of the existing form editor

https://user-images.githubusercontent.com/20525304/151196553-2818d44a-eb41-42d3-aa3b-ae53c765a838.mp4

authors: mortada-codes olensmar

repo: kubeshop/monokle

license: MIT


text:
Docs: add instructions about chartmuseum

Signed-off-by: Charlie Chiang charlie_c_0129@outlook.com

Updated Build your Own Registry with ChartMuseum and addon push command
Use addon init command in Build Your Own Addon

Corresponding feature PR: https://github.com/kubevela/kubevela/pull/4261

does this doc for 1.5 only?

Yes, 1.5 or later


text:
Bug 2158550: Display MigrationPolicy page after renaming correctly

📝 Description
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=2158550
Display MigrationPolicy details page or MigrationPolicies list correctly with no error, after changing the name of some MigrationPolicy resource (depending on the actual location while renaming the policy).
More details:
The core of the problem was here where the original name of the policy was searched in the WHOLE URL and not at its end, where it belongs, so it was only logical that the first occurence of "a" was found "earlier" in the url string than expected and replaces by the new name, so "migraations" occurred in the url, that lead to the error, as such page wasn't found.
🎥 Screenshots
Before:
Error after renaming MigrationPolicy and incorrect url, especially if MigrationPolicy had a very simple name like "a":
URL: /k8s/cluster/migraations.kubevirt.io~v1alpha1~MigrationPolicy/a

After:
No error after renaming MigrationPolicy (to 'aa'), page rendered correctly:
URL: /k8s/cluster/migrations.kubevirt.io~v1alpha1~MigrationPolicy/aa

/lgtm

/retest

/retest

/retest

authors: hstastna metalice pcbailey

repo: kubevirt-ui/kubevirt-plugin


text:
Make overview page namespace aware

📝 Description
This PR adds the namespace bar to the overview page and modifies its extension to make it namespace aware.
🎥 Screenshot

@avivtur @hstastna @metalice @upalatucci @vojtechszocs PTAL

/lgtm

authors: pcbailey upalatucci


text:
node-labeller: Remove obsolete functionalities

What this PR does
Before this PR:
node labeller supported deprecated annotations (since v0.40 release).
After this PR:
node labeller will not support these annotations, as kubevirt does not support upgrade from this release anymore.

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[x] Design: A design document was considered and is present (link) or not required
[x] PR: The PR description is expressive enough and will help future contributors
[x] Code: Write code that humans can understand and Keep it simple
[x] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[x] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[x] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[x] Community: Announcement to kubevirt-dev was considered

Release note

node-labeller: Remove obsolete functionalities

It's strange that the unit test lane failed, as I didn't add/remove any in this PR..
/test pull-kubevirt-unit-test-arm64

Hey, I have a question ^^

Thanks for asking! Please see answer

/test pull-kubevirt-e2e-arm64

/hold cancel

repo: kubevirt/kubevirt


text:
test: move execute functions from utils

Move execute command on pod functions from utils to a new package,
and also move CopyFromPod from utils to imageupload to make utils shorter.
Signed-off-by: Ben Oukhanov boukhanov@redhat.com
Release note:
NONE

/sig code-quality

/retest-required

It's ready for review, and previous discussion was resolved. @dankenigsberg Please let me know if we can remove hold label.

Hey @codingben! Good job!
I like the direction this PR is going towards, but still have a few concerns.
I don't really understand why we need 2 (or 3 in the current PR implementation) different functions to execute a command on a Pod. Let me explain why:
First of all, the only difference between ExecuteCommandOnPod() and ExecuteCommandOnPodV2() is that the the first one returns stdout only, while V2 returns stdout and stderr. Even if we set aside the horrible naming for these functions, I don't really see what is the motivation for having them two. Performance-wise there is no difference at all since V2 calls "V1" and simply does not return the stderr part (or more accurately returns it as an error).
Secondly, ExecCommandOnPod() was a private helper function, now it is public. I can't see why we need it to be public, or even need it at all.
What I would do is keep one function, ExecuteCommandOnPod(). This function should have V2's signature, or IOW, should return stdout, stderr and an error. This is how it would be used:
// If we need stderr
stdout, stderr, err := ExecuteCommandOnPod(virtCli, pod, containerName, command)

// If we don't need stderr
stdout, _, err := ExecuteCommandOnPod(virtCli, pod, containerName, command)

Please note again that under the hood nothing is really changed, since stderr is fetched either way (whether you use V1 or V2).
Implementation-wise, this new function needs to have the code of current ExecCommandOnPod() inside it. So eventually we end up with only one unified function.

Another small note: please squash the last commit with spaces only. I would make life difficult for rebases / backports, etc.

Another small note: please squash the last commit with spaces only. I would make life difficult for rebases / backports, etc.

Sorry, do you mean to not have that style commit and make it as part of previous commit?

Yes, exactly

By the way, I'd choose squash commits option when merging this PR. Is there any reason why kubevirt-bot isn't doing it? It's popular approach in other open source projects, for example in Angular.

Not sure who made the decision for Kubevirt, but tbh I don't like squash commits :) I think it's valuable to be able to view commits history as they were originally. For many PRs, if all of their commits were squashed, the changes were very difficult to grasp when looking through history.

Secondly, ExecCommandOnPod() was a private helper function, now it is public. I can't see why we need it to be public, or even need it at all.

It's public because it's used here, and it's giving to ExecuteCommandOnPodWithOptions custom options. In your example, there's no options parameter. WDYT?

Secondly, ExecCommandOnPod() was a private helper function, now it is public. I can't see why we need it to be public, or even need it at all.

It's public because it's used here, and it's giving to ExecuteCommandOnPodWithOptions custom options. In your example, there's no options parameter. WDYT?
We can have ExecuteCommandOnPod and ExecuteCommandOnPodWithOptions. ExecuteCommandOnPod will be merged into ExecuteCommandOnPodV2.

Aha! Got you :)
Sounds good to me, I also like your naming.
Also, if that's the case, I guess ExecuteCommandOnPod would internally call ExecuteCommandOnPodWithOptions, providing default options.

/test pull-kubevirt-e2e-k8s-1.22-sig-compute

/test pull-kubevirt-e2e-k8s-1.22-sig-compute

@codingben why is it DRAFT? Are you still experimenting? If the design is final and you expect review please change from draft to final with the use of "Ready for Review". I looks final to me. It looks good.
I like it now, after you implemented @iholder-redhat suggestions.

@brybacki Hi, yes, it's final design. It's on Draft to not trigger all CI tests. I tried to run pull-kubevirt-e2e-k8s-1.22-sig-compute twice here and it's failing - I tried to run locally and it's failing on this error:
Delete "https://127.0.0.1:49178/api/v1/namespaces/kubevirt-test-default1/serviceaccounts/kubevirt-subresource-test-sa": dial tcp 127.0.0.1:49178: connect: connection refused

I think I didn't setup something properly. I'd like to try to execute another test to make sure some local tests passed before we'll execute all CI tests.

I'm going to make cluster-up :) I'll remove Draft once I'll verify tests locally.

@codingben  I think You need to rebase, then change the PR to ready for review, so all the tests run, and we can finalize the review process

I'll open another PR to just move execute functions from utils without refactoring them.

authors: brybacki codingben iholder-redhat


text:
api: Move the core API storage version to v1 and deprecate v1alpha3

What this PR does / why we need it:
This change moves the storage version for all core API CRDs to v1. This does not impact existing objects that will continue to be stored using their original v1alpha3 version while being served as v1alpha3 or v1, as was the case previously.
Work will be required in the future to ensure all stored v1alpha3 objects are read and updated to v1 but for the time being this isn't required as part of this PR.
For more context please review the following k8s documentation:
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning
Additionally the following KubeVirt dev ML thread covers this topic:
https://groups.google.com/g/kubevirt-dev/c/bSayedthHmY
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Interested in this PR? Then you will love https://github.com/kubevirt/kubevirt/pull/9575 !
Release note:

* The `kubevirt.io/v1` `apiVersion` is now the default storage version for newly created objects
* The `kubevirt.io/v1alpha3` `apiVersion` is now deprecated and will be removed in a future release

/test pull-kubevirt-apidocs
/test pull-kubevirt-generate
/test pull-kubevirt-e2e-k8s-1.26-sig-compute

/retest-required

/retest-required

/retest

/retest

/retest

/retest-required

/hold
Need to create the runbook for the alert first

@sradco
Moved https://github.com/kubevirt/kubevirt/pull/9724/commits/91a2b7a002c957995036e5543f2b92a674324e7b to separate PR https://github.com/kubevirt/kubevirt/pull/9724

/unhold


text:
Removes dependency on go-ps

What this PR does / why we need it:
What it does: $subject
Why we need: 1) the library isn't updated since a while, 2) KubeVirt needs only UNIX part of the code from the original repo
Which issue(s) this PR fixes:
Fixes #9671
Special notes for your reviewer:
Release note:

NONE

/cc @alicefr

/ok-to-test

@dharmit it will be nice to have a couple of unit tests checking the new functions

@dharmit it will be nice to have a couple of unit tests checking the new functions

Sure, I'll add them and ping back.

Please, if you copied the functions from the original library, please write a comment with the reference to it

Please, if you copied the functions from the original library, please write a comment with the reference to it

I'd like to take a step back and confirm if it's OK to copy from the original library? Or do you recommend I implement it afresh. I don't mind doing the latter (and would even prefer going that route, as that would help me learn).

Please, if you copied the functions from the original library, please write a comment with the reference to it

I'd like to take a step back and confirm if it's OK to copy from the original library? Or do you recommend I implement it afresh. I don't mind doing the latter (and would even prefer going that route, as that would help me learn).

The original library is under the MIT license. Under the license is possible to take and modify the code. The only thing is we need to include the copyright not. Hence, you could put a comment before the code and adding the link to the library and the comment with license note

Please, if you copied the functions from the original library, please write a comment with the reference to it

I'd like to take a step back and confirm if it's OK to copy from the original library? Or do you recommend I implement it afresh. I don't mind doing the latter (and would even prefer going that route, as that would help me learn).

The original library is under the MIT license. Under the license is possible to take and modify the code. The only thing is we need to include the copyright not. Hence, you could put a comment before the code and adding the link to the library and the comment with license note

What this PR does / why we need it:
$subject

The subject does not state why we need this. Please take a few seconds to write a sentence about what problem this PR is solving. Thank you

What this PR does / why we need it:
$subject

The subject does not state why we need this. Please take a few seconds to write a sentence about what problem this PR is solving. Thank you

Thanks @jean-edouard. I've updated it.

What this PR does / why we need it: What it does: $subject Why we need:

the library isn't updated since a while

Does it need updating? Can't we submit pull requests to them for what needs to be updated?

KubeVirt needs only UNIX part of the code from the original repo

It is normal not to use every aspect of the things we import, we could probably make similar statements about virtually every other library we use!
Importing a bunch of code into KubeVirt increases the maintenance burden/cost, which I guess is fine if there's a good reason for it, but I don't see it here...

What this PR does / why we need it: What it does: $subject Why we need:

the library isn't updated since a while

Does it need updating? Can't we submit pull requests to them for what needs to be updated?

We can, I think. At least, I can't think of why we can't. :)

KubeVirt needs only UNIX part of the code from the original repo

It is normal not to use every aspect of the things we import, we could probably make similar statements about virtually every other library we use!

👍🏾   I take it back.

Importing a bunch of code into KubeVirt increases the maintenance burden/cost, which I guess is fine if there's a good reason for it, but I don't see it here...

@alicefr can you PTAL?

@jean-edouard This was my suggestion, there are a couple of go libraries that implement this. We could fix it in their repo, but since they are just a couple of functions, I thought it would be better to get rid of the dependency. At least, it was my thought about it. Please, let me know what you think

No fixes are needed so far. It was a suggestion for refactoring. If we want to keep it, then we can open fixes there

I'm closing this since it looks like we have an agreement to open PRs on the original repo, if need be.
Thanks for your help @alicefr @0xFelix, and for the discussion @jean-edouard. :)
/close

authors: alicefr dharmit jean-edouard


text:
Allow running vm-console-proxy on Kubernetes

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:
/kind bug

/kind enhancement
What happened:
With the current configuration supplied vm-console-proxy is only able to run on OKD / OpenShift.
What you expected to happen:
I expected vm-console-proxy to be available on upstream Kubernetes too.
E.g. there is at least documentation on how to run it without OpenShift.
How to reproduce it:
Run make deploy.

/remove-lifecycle stale

repo: kubevirt/vm-console-proxy


text:
feat: policy optimizer

This PR introduces a new cli tool called policy-optimizer. This binary will download the policies and optimize them. The goal is to implement what is described inside of this RFC.
Currently the code doesn't do any download/optimization. It just leverages the Lease primitive declared by Kubernetes to ensure only one process can have write access to the directory where the optimized policies are going to be written.
The actual code similates the download & optimize work with a simple sleep.
The change is pretty invasive as you can see, I don't want to merge it in the main branch yet.

Closing in favor of https://github.com/kubewarden/policy-server/pull/519, which is open against a feature branch of policy-server

repo: kubewarden/policy-server


text:
Fix policy metadata

The policy metadata was broken:

The free form key/value section requires the values to be strings, the policy was trying to use an array
There was an indexing error inside of the description

I think we should just tag 0.1.1 once this is merged

Reopening, the metadata in hub doesn't seem to be updated:
https://github.com/kubewarden/policy-hub/blob/main/web/policies/kubewarden:verify-image-signatures.json

Fixed, it's all good now

authors: flavio viccuad

repo: kubewarden/verify-image-signatures