text:
OIDC groupsPrefix can't be set to an empty string

What happened:
If I set features.openidConnect.config.groupsPrefix to an empty string or delete the key. The default value (oidc:) will be used.
What is the expected behavior:
I would expect that an empty string in the KubeOne config would result in an empty string in the manifest. But this is not the case. Maybe you could offer a dash (-) for an empty value like as for usernamePrefix.
Also, I would interpret the doc string to mean that if I omit the key, it should not set a prefix.
# **If provided**, all groups will be prefixed with this value to prevent
# conflicts with other authentication strategies.

How to reproduce the issue:
Look at >What happened<
Anything else we need to know?
null does not work as well -> default used.
Information about the environment:
KubeOne version (kubeone version): 1.4.1
Operating system: Rocky Linux 8.5
Provider you're deploying cluster on: on prem
Operating system you're deploying on: Rocky Linux 8.5

@Schluggi do you want to have the setup where oidc group have no prefix?

@Schluggi do you want to have the setup where oidc group have no prefix?

Yes. Exactly.

@Schluggi

What about usernamePrefix?
does it also need the ability to be set empty? Asking because currently it's also defaulted as "oidc:".
What's the use-case for having no prefix at all?

@Schluggi
* What about `usernamePrefix`?
  does it also need the ability to be set empty? Asking because currently it's also defaulted as "oidc:".

* What's the use-case for having no prefix at all?

usernamePrefix already has the ability. A dash (-) will do this. KubeOne will write the dash into the manifest and k8s will handle this. As the doc say "The value - can be used to disable all prefixing".

We only use OIDC so we have no prefix at all.

The point is k8s allow us to set an empty string. But KubeOne doesn't. That's an issue for us. Using a prefix would work but feels more like a workaround.

repo: kubermatic/kubeone


text:
Add changelogs for v1.6.1 and v1.5.7

What this PR does / why we need it:
Add changelogs for v1.6.1 and v1.5.7.
Which issue(s) this PR fixes:
xref #2739 #2738
What type of PR is this?
/kind documentation
Does this PR introduce a user-facing change? Then add your Release Note here:
NONE

Documentation:
NONE

/lgtm
/approve

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
Missing an "http auth free" health endpoint

Hi,
It would be nice to have a health endpoint at path / which is exposed without http auth even if we use http auth.
For now I can't use my chartmuseum Helm charts with http auth in my Kubernetes cluster with a GCE Ingress because healthcheck fail indefinitely. :/
2017-12-12T16:16:26.486Z        DEBUG   [322] Incoming request: /       {"reqID": "ead60a6a-defe-4450-aa35-0db06b7ba857"}
2017-12-12T16:16:26.486Z        WARN    [322] Request served    {"path": "/", "comment": "", "latency": "127.6µs", "clientIP": "10.240.0.12", "method": "GET", "statusCode": 404, "reqID": "ead60a6a-defe-4450-aa35-0db06b7ba857"}
2017-12-12T16:16:26.616Z        DEBUG   [323] Incoming request: /       {"reqID": "780a8a2e-4faf-4deb-840e-d311db2e5dc6"}
2017-12-12T16:16:26.616Z        WARN    [323] Request served    {"path": "/", "comment": "", "latency": "33.093µs", "clientIP": "10.240.0.17", "method": "GET", "statusCode": 404, "reqID": "780a8a2e-4faf-4deb-840e-d311db2e5dc6"}
2017-12-12T16:16:26.746Z        DEBUG   [324] Incoming request: /       {"reqID": "6fe8e465-30ec-41cd-8687-9b59d39b6e73"}
2017-12-12T16:16:26.746Z        WARN    [324] Request served    {"path": "/", "comment": "", "latency": "37.049µs", "clientIP": "10.240.0.4", "method": "GET", "statusCode": 404, "reqID": "6fe8e465-30ec-41cd-8687-9b59d39b6e73"}

Makes sense to me. I'd be willing to add this, if the maintainers think this is a good idea?

@bonhamjp go for it! @KrustyHack this is definitely needed, thanks for opening

source: gharchive/issue

authors: KrustyHack bonhamjp jdolitsky

repo: kubernetes-helm/chartmuseum


text:
Refactor to make it easier to consume the library

This refactors a few things to make it much easier to consume this library, including simplifying the metrics interface, adding helpers for common tasks, removing some extraneous fields, and simplifying the boilerplate for launching new servers.
It also updates the example for simplicity, and adds a more in-depth walkthrough of how the sample works.

@jsturtevant PTAL

@jsturtevant I think I've addressed all of your comments, and added an additional aside on resources, kinds, scope, and quantities.

@DirectXMan12  Looks great. The section on understanding kinds, resources and quantites is really helpful.  Had one question on the GVK vs GVR.

Fix landed, will merge in the next few days unless there are any objections

Lets good.  The explanations really help.


text:
Local volume provisioner should persist local PV states on the node as a safety measure

Motivation
The metadata stored in Kubernetes w.r.t local PVs is critical in keeping track of local volumes that are in use. They effectively hold the keys to potentially petabytes of critical data. Any loss of data in etcd due to admin or config errors (this has actually happened) of that metadata effectively causes loss of data in disks at scale. While one could argue this issue exists with other forms PVs in Kubernetes, the fact is many of those other forms of scale out storage like ceph and ebs maintain their own metadata on volumes that can potentially be used to track and recover.
This request suggests adding some minimum bookkeeping locally on the node as a safety mechanism. As shown below, by doing this minimal bookkeeping, we not only protect against the above disastrous scenario, but in addition the LV provisioner becomes smarter and is able to alert on PV transitions that happened without its normal (and expected) involvement.
Implementation
The LV provisioner on each node would track the following information in a local file (lets call it "ledger") for all the volumes on that node. This ledger file would be kept simple and human readable.

When a volume  is first discovered and PV is created for it, the PV creation is recorded in the local ledger.
When the PV is bound (something that the provisioner can detect already), the PV information is updated in the ledger.
When a PV is found to be in Released state, this state change is updated in the ledger as part of the cleaning action that provisioner usually initiates at this stage.
When a PV is deleted, the file is again updated to indicate that it was deleted as the provisioner does the PV deletion.

The ledger can be used by the PV provisioner in the following manner:

If the Provisioner is about to create a PV for a volume and  the ledger indicates that the last known state of a PV is "bound", then the provision will refuse to create a new PV for that volume. This is because the provisioner would have certainly updated the file entry to "deleted" state or atleast to "released" state, if the volume had made its way through the regular cleaning and PV deletion process. The fact that a PV does not exist after last being known to be in "bound" state indicates something has gone seriously wrong with the PV metadata and requires investigation by admin.

If the ledger records that the last known state of a PV is "released", and the provisioner discovers that no PV exists for the volume, then it could either (based on configmap setting)

Refuse to create a PV since the normal process was not followed.

Notify through log message or event or metrics that a PV is being created without the normal cleanup process. This option is set for a site if the admin is in the habit of deleting PVs when they are still being cleaned for various reasons (including errors in the cleaning process or due to the process taking too long).

Apart from preventing accidental re-use of PVs as shown in 1 and 2,  the admin can actually recreate PVs (in the event of metadata loss) and use the "bound" information in the ledger file to re-create the PVC bindings either manually or by writing a simple tool to do so (assuming the PVCs still exist or can be recreated).  This metadata is very valuable in threading back applications and the disks they were using before the failure. In case of a widespread loss, one could even implement such a tool to run as a daemonset to execute this recovery process across all nodes. Please note that the scope of this request does not include building such a tool. It only suggests recording the data necessary to build such a tool.

Note that the distributed nature of storage this information (locally on each node) makes the approach fairly robust in terms of avoiding large scale loss of metadata. Also note that these changes are backward compatible - The behavior described above only kicks in when ledger entries are found. If ledger entries are absent (or if the ledger itself is absent), the provisioner behaves the way it currently does.

/area local-volume

cc @msau42

Yes, it will have an in-memory copy, as we assume that LC provisioner is the only write. The disk access will mostly be to persist changes.

/assign @dhirajh

Migrating issue to new repo: https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/issues/11
/close

repo: kubernetes-incubator/external-storage

license_source: bigquery


text:
[WIP] Add Socks Shop example

This is in progress.
Socks Shop is an example microservices applications that weave works uses to demo their products.
It is a fairly complete docker-compose file.
We should make sure kompose can convert it, it is a good example.

Right now I get this error:
$ ./kompose convert -f ./examples/docker-sockshop.yml
WARN[0000] Unsupported network configuration of compose v2 - ignoring
WARN[0000] Unsupported key networks - ignoring
WARN[0000] Unsupported key dns - ignoring
WARN[0000] Unsupported key dns_search - ignoring
WARN[0000] Unsupported key hostname - ignoring
panic: runtime error: index out of range

goroutine 1 [running]:
panic(0x1205580, 0x8223ca050)
	/usr/local/go/src/runtime/panic.go:464 +0x3e6
github.com/skippbox/kompose/vendor/github.com/docker/libcompose/yaml.toMap(0x82286be30, 0x1, 0x1, 0x1481a70, 0x1, 0x40)
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/vendor/github.com/docker/libcompose/yaml/types_yaml.go:223 +0x187
github.com/skippbox/kompose/vendor/github.com/docker/libcompose/yaml.(*MaporEqualSlice).ToMap(0x822428150, 0x822428000)
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/vendor/github.com/docker/libcompose/yaml/types_yaml.go:126 +0x4b
github.com/skippbox/kompose/pkg/loader/compose.(*Compose).LoadFile(0x1f9fc78, 0x82262f3e0, 0x1e, 0x0)
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/pkg/loader/compose/compose.go:155 +0x91d
github.com/skippbox/kompose/cli/app.Convert(0x822567cc0)
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/cli/app/app.go:146 +0x4e8
github.com/skippbox/kompose/cli/command.ConvertCommand.func1(0x822567cc0)
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/cli/command/command.go:32 +0x21
github.com/skippbox/kompose/vendor/github.com/urfave/cli.Command.Run(0x1486fc0, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x82252a9b0, 0x4b, 0x0, ...)
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/vendor/github.com/urfave/cli/command.go:179 +0x1399
github.com/skippbox/kompose/vendor/github.com/urfave/cli.(*App).Run(0x8225326e0, 0x8223c0400, 0x4, 0x4, 0x0, 0x0)
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/vendor/github.com/urfave/cli/app.go:196 +0x137c
main.main()
	/Users/sebastiengoasguen/Documents/go/src/github.com/skippbox/kompose/cli/main/main.go:47 +0x337

thanks. We do need to check it this works OOTB with docker-compose.

hmm that is strange, for me it fails with docker-compose
▶ docker-compose -f  docker-sockshop.yml up
WARNING: The MYSQL_ROOT_PASSWORD variable is not set. Defaulting to a blank string.
ERROR: The Compose file './docker-sockshop.yml' is invalid because:
services.user.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.catalogue-db.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.cart.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.cart-db.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.catalogue.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.edge-router.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.front-end.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.orders.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.orders-db.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.payment.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.queue-master.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.rabbitmq.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.shipping.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string
services.user-db.environment contains {"reschedule": "on-node-failure"}, which is an invalid type, it should be a string

Oh noooo, sorry. My bad.
It really works :-) I have modified file with space. And that fails with docker-compose.
You are right your original file works with docker-compose.

In that case, something is wrong  in Kompose

here is the source https://github.com/microservices-demo/microservices-demo

ok so if we switch to:
    environment:
      - reschedule=on-node-failure

Then it works just fine (no need for space).
The faulty code seems to be in:
https://github.com/skippbox/kompose/blob/6cbdec444b06d9c0905b7c6fcc03b7b849b15a29/vendor/github.com/docker/libcompose/yaml/types_yaml.go#L124

I think this is actually a docker-compose problem.
Docker-compose parses the yaml without errors and starts the containers but the environment variable does not get set.
for example if we look at this service:
  user:
    image: weaveworksdemos/user
    hostname: user
    dns: 172.17.0.1
    dns_search: weave.local
    restart: always
    environment:
      - MONGO_HOST=user-db:27017
      - reschedule:on-node-failure

the set environment looks like
$ docker exec -ti c74c4846b571 env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=user
MONGO_HOST=user-db:27017
no_proxy=*.local,169.254/16
HATEAOS=user
USER_DATABASE=mongodb
HOME=/root

So the reschedule env is not set. If we use equal sign it gets set.

docker-compose in 1.8 version is still in Python and doesn't use libcompose.
This might be reason why it gets silently ignored there and Kompose panics.
I'm confused from all this. If this supposed to set reschedule env it should be like this:
environment:
  reschedule: on-node-failure

(environment as dict so no -)
environment:
  - reschedule=on-node-failure

(environment as array)
I think that reschedule:on-node-failure is wrong and source of this is swarm documentation.
They say: "You can do this with the reschedule environment variable "
and later on again: "To set the on-node-failure policy with a reschedule environment variable:
$ docker run -d -e reschedule:on-node-failure redis

"
But his command doesn't set reschedule env variable.
▶ docker run -it -e reschedule:on-node-failure  busybox env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=a1ce60e6b16d
TERM=xterm
HOME=/root

There should be = instead of :

agreed. and I filed a bug with the microservices demo guys to let them know...I don't think they tested this.

Investigating the compose file, I found that currently we can't make the sock shop app running on kubernetes via kompose. The reason is that there are some services have not been created due to lack of ports configuration in the compose file, so "micro-services" can not find each other. Running the app with docker-compose would be very handy but kompose at this moment can not detect opened ports in images metadata until we resolve https://github.com/skippbox/kompose/issues/146

@sebgoa Should we close this PR?

Hey @sebgoa I'm just going to close this PR for now :)

authors: cdrage kadel ngtuna runseb sebgoa

repo: kubernetes-incubator/kompose


text:
add missing 'io.kompose.service' label to Route and Ingress

This was caussing 'kompose down' not to delete Route and Ingress
fixes #510

@kadel I tried this out but seems it doesn't delete the route in OpenShift :(

really?
I just tried that again, and it is working for me.

@kadel , @procrypt I tried this and it works for me :)
@procrypt , I think you created route manually.

ping @cdrage @procrypt @surajssd

Ah this works for me now, tested again, @kadel LGTM.

LGTM :+1:

authors: cdrage kadel procrypt surajnarwade


text:
Adding Pensu as owners

CC: @mbbroberg

@mbbroberg I am member of Kubernetes github org. I assumed that covered kubernetes-sigs as well. Do I need to do that separately?

@mbbroberg I am member of Kubernetes github org. I assumed that covered kubernetes-sigs as well. Do I need to do that separately? CC: @rajula96reddy

I think we are good. Once we merge this, you will have access.

You will need to be added to the k-sigs org via the k/org repo. As a member of Kubernetes, you're implicitly allowed to join the other orgs, its just not automatic.

@Pensu +1 to what Bob said -- we can get the overall org in the other repo. Post nit this lgtm too.

@palnabarun Sorted! PTAL.

/lgtm

authors: Pensu mbbroberg mrbobbytables rajula96reddy

repo: kubernetes-sigs/contributor-tweets


text:
Exclude namespace is invalid

Hi：
kubernetes version:  v1.16.9
descheduler version:  v0.20.0
Exclude namespace is invalid
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler-policy-configmap
  namespace: kube-system
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha1"
    kind: "DeschedulerPolicy"
    strategies:
      "PodLifeTime":
         enabled: true
         params:
            podLifeTime:
              maxPodLifeTimeSeconds: 86400
            namespaces:
              include:
              - "dev"
              exclude:
              - "kube-system"
      "RemoveDuplicates":
         enabled: true
      "RemovePodsViolatingInterPodAntiAffinity":
         enabled: true
      "LowNodeUtilization":
         enabled: true
         params:
           nodeResourceUtilizationThresholds:
             thresholds:
               "cpu" : 50
               "memory": 20
               "pods": 20
             targetThresholds:
               "cpu" : 70
               "memory": 30
               "pods": 20

Hi @1032231418 ,
from the logs you posted, I see that the pod in kube-system was evicted due to the LowNodeUtilization strategy, which does not have the ability to filter specific namespaces.
For critical pods which should never be evicted, you should consider using a system-critical priority class or your own priority class and set priority thresholds on each strategy. Both of these options are supported by all strategies
/remove-kind bug
/kind support

@damemi
My purpose is to perform migration in one namespace, and isolate the other namespace, because it acts on the entire cluster and causes business exceptions.

@damemi
LowNodeUtilization strategy, is there a way to migrate only pods in the specified namespace

@1032231418 the namespace parameters are set per-strategy, and we intentionally do not provide it for LowNodeUtilization due to the fact that LowNodeUtilization is meant to balance an entire node, so running it only against a small number of namespaces defeats the purpose of the strategy.
There is some more discussion on this in https://github.com/kubernetes-sigs/descheduler/issues/391, but the general idea is that unless your specific namespace is consuming a majority of your cluster's resources, the LowNodeUtilization strategy will never be able to successfully balance the node's utilization. For many cases, the other strategies are sufficient to achieve the balance most users are actually seeking within a namespace.
We can continue the discussion on adding this ability in that issue, so I'm going to close this one as a duplicate of that.
/close

repo: kubernetes-sigs/descheduler


text:
Flags support seems broken when test binary generated

The framework is designed to work with or without flags. As such flags are not parsed early to avoid forcing test writers to deal with unnecessary CLI flag parsing.  However, it seems that flags are broken when binary is generated.
go test -c -o test.test .

When the binary is executed, it generated an error:
./test.test --kubeconfig /Users/vivienv/.kube/config
 no configuration has been provided, try setting KUBERNETES_MASTER environment variable

https://github.com/kubernetes-sigs/e2e-framework/blob/5ae53752fa86bf5a00b5ca32ce877c9c4e6cd277/pkg/envconf/config.go#L80
This is the culprit here. Even though kind cluster is not required for the example written still the above code tries to connect with k8s cluster.
Even for k8s related tests before creating cluster itself envconf.NewFromFlags() will  try to make a k8s client connection which is again lead to the above issue.
I think we need to add creation of  k8s client connection only k8s related tests(after creating cluster).

authors: ShwethaKumbla vladimirvivien


text:
chore: update cloudbuild paths to match push-etcd-manager script

I had put an extra slash in there which was causing the push to fail.

/lgtm

authors: justinsb rifelpet

repo: kubernetes-sigs/etcd-manager


text:
Add a success message to verify-boilerplate

I fooled myself into thinking this wasn't actually doing anything, so I figure it would be good to add a reassuring success message:
$ ./hack/verify-boilerplate.sh
Verified 111 file headers match boilerplate

It's arguable this change should go into k/k first, but perhaps a little laziness can be forgiven!
/kind cleanup

Thanks @markmc!
/ok-to-test
/lgtm
/approve

authors: markmc robscott

repo: kubernetes-sigs/gateway-api


text:
promote HTTPRoute backend protocol from experimental to  extended

What type of PR is this?
/kind gep
/area conformance
What this PR does / why we need it:
This promotes backend protocol selection as part of Gateway v1.2 release
Which issue(s) this PR fixes:
Part of https://github.com/kubernetes-sigs/gateway-api/issues/1911
Does this PR introduce a user-facing change?:

Backend Protocol Selection is no longer experimental and is now part of HTTPRoute Extended Conformance

Is there any website documentation we need to update for this as well?
Aside from that, lgtm, I'll approve.
/approve

Sorry yeah - I need to drop this notice

done

Thanks @dprotaso! This LGTM, but I think we need to have some kind of solution for https://github.com/kubernetes-sigs/gateway-api/issues/3115 before we accept docs updates for unreleased changes. I don't really have a great solution yet, but open to ideas.

Pulled the docs changes into a separate PR - https://github.com/kubernetes-sigs/gateway-api/pull/3120

weird verify took 2h
/retest

Thanks @dprotaso!
/lgtm
/approve

authors: dprotaso robscott youngnick


text:
Refactor small sections of code and tests

What type of PR is this?

/kind cleanup
What this PR does / why we need it:
This PR contains changes that clean up certain function definitions.
Release note:
none

Hi @yussufsh,
Rebased the PR with main and addressed the review comment.
Thanks!

/ok-to-test

authors: kishen-v yussufsh


text:
add dependabot

Fixes #13
Add dependabot and follow same configuration as Kueue.

/lgtm

Thanks Kevin, can you pls explain a bit what will that do? which dependencies will be updated and how the update will be triggered?

So this is the exact same config that we are using in Kueue for updating dependencies.
version: 2
updates:

  # Maintain dependencies for go
  - package-ecosystem: "gomod" // Look at gomodules
    directory: "/"
    schedule:
      interval: "weekly" // Check on a weekly cadence and see if anything needs an update
    labels:
      - "ok-to-test" // Adds the "ok-to-test" label to every PR
    ignore:
      # Ignore major and minor versions for dependencies updates
      # Allow patches and security updates.
// Generally only update major.minor upgrades for K8 dependencies.
      - dependency-name: k8s.io/*
        update-types: ["version-update:semver-major", "version-update:semver-minor"]

I figured the Kueue config you all are happy with as I don't believe it has changed much since I added it.

/approve

authors: ahg-g danielvegamyhre kannon92

repo: kubernetes-sigs/jobset


text:
[WIP] Adding e2e tests for kube-scheduler-simulator

What type of PR is this?
/kind feature

What this PR does / why we need it:
As part of this change, we are adding e2e testing for kube-scheduler-simulator
Which issue(s) this PR fixes:

Fixes #52
Special notes for your reviewer:
/label tide/merge-method-squash

/remove-lifecycle rotten

/reopen


text:
Error from server (Forbidden): pods.custom.metrics.k8s.io

What happened?:
I got forbidden error messsage when try to get a custom mot metric
What did you expect to happen?:
Error from server (Forbidden): pods.custom.metrics.k8s.io "*" is forbidden: User "u-ckvrz" cannot get resource "pods/memory_usage_bytes" in API group "custom.metrics.k8s.io" in the namespace "metrictest"
kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/metrictest/pods/*/memory_usage_bytes
Error from server (Forbidden): pods.custom.metrics.k8s.io "*" is forbidden: User "u-ckvrz" cannot get resource "pods/memory_usage_bytes" in API group "custom.metrics.k8s.io" in the namespace "metrictest"

Custom.metrics.k8s.io looks ok:
kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/ |jq
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "custom.metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "namespaces/kube_endpoint_address_available",
      "singularName": "",
      "namespaced": false,
      "kind": "MetricValueList",
      "verbs": [
        "get"
      ]
    },
    ...
    ...
    {
      "name": "pods/node_memory_CommitLimit_bytes",
      "singularName": "",
      "namespaced": true,
      "kind": "MetricValueList",
      "verbs": [
        "get"
      ]
    }
  ]
}

Metrics.k8s-io apiservices looks ok:
kubectl get --raw /apis/metrics.k8s.io/v1beta1/ | jq
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "nodes",
      "singularName": "",
      "namespaced": false,
      "kind": "NodeMetrics",
      "verbs": [
        "get",
        "list"
      ]
    },
    {
      "name": "pods",
      "singularName": "",
      "namespaced": true,
      "kind": "PodMetrics",
      "verbs": [
        "get",
        "list"
      ]
    }
  ]
}

Get from metrics.k8s.io i working properly.
kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/metrictest/pods/ | jq
{
  "kind": "PodMetricsList",
  "apiVersion": "metrics.k8s.io/v1beta1",
  "metadata": {},
  "items": [
    {
      "metadata": {
        "name": "ubuntu-76868c99b-8r8nz",
        "namespace": "metrictest",
        "creationTimestamp": "2021-12-02T10:57:20Z",
        "labels": {
          "pod-template-hash": "76868c99b",
          "workload.user.cattle.io/workloadselector": "deployment-metrictest-ubuntu"
        }
      },
      "timestamp": "2021-12-02T10:57:20Z",
      "window": "3m0s",
      "containers": [
        {
          "name": "ubuntu",
          "usage": {
            "cpu": "0",
            "memory": "7240Ki"
          }
        }
      ]
    }
  ]
}

K8S version: 1.19.12
kube-prometheus-stack chart version: 17.1.0
Prometheus-adapter chart version: 3.0.0 and 2.1.7.1 also affected
Please provide the prometheus-adapter config:

prometheus-adapter config
Chart install command:
helm upgrade --install prometheus-adapter prometheus-community/prometheus-adapter -n monitoring -f prometheus-adapter.yaml --version 2.17.1

Adapter chart config:
# Default values for k8s-prometheus-adapter..
affinity: #{}
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: role
          operator: In
          values:
          - infra

#image:
#  repository: k8s.gcr.io/prometheus-adapter/prometheus-adapter
#  tag: v0.9.1
#  pullPolicy: IfNotPresent

logLevel: 6

metricsRelistInterval: 1m

listenPort: 6443

nodeSelector: {}

priorityClassName: ""

## Additional annotations to add to all resources
customAnnotations: {}
  # role: custom-metrics

## Additional labels to add to all resources
customLabels: {}
  # monitoring: prometheus-adapter

# Url to access prometheus
prometheus:
  # Value is templated
  url: http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local
  port: 9090
  path: ""

replicas: 1

# k8s 1.21 needs fsGroup to be set for non root deployments
# ref: https://github.com/kubernetes/kubernetes/issues/70679
podSecurityContext:
  fsGroup: 10001

rbac:
  # Specifies whether RBAC resources should be created
  create: true

psp:
  # Specifies whether PSP resources should be created
  create: false

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name:
  # ServiceAccount annotations.
  # Use case: AWS EKS IAM roles for service accounts
  # ref: https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html
  annotations: {}

# Custom DNS configuration to be added to prometheus-adapter pods
dnsConfig: {}
# nameservers:
#   - 1.2.3.4
# searches:
#   - ns1.svc.cluster-domain.example
#   - my.dns.search.suffix
# options:
#   - name: ndots
#     value: "2"
#   - name: edns0
resources: {}
  # requests:
  #   cpu: 100m
  #   memory: 128Mi
  # limits:
  #   cpu: 100m
  #   memory: 128Mi

rules:
  default: true
  custom: []
# - seriesQuery: '{__name__=~"^some_metric_count$"}'
#   resources:
#     template: <<.Resource>>
#   name:
#     matches: ""
#     as: "my_custom_metric"
#   metricsQuery: sum(<<.Series>>{<<.LabelMatchers>>}) by (<<.GroupBy>>)
  # Mounts a configMap with pre-generated rules for use. Overrides the
  # default, custom, external and resource entries
  existing:
  external: []
# - seriesQuery: '{__name__=~"^some_metric_count$"}'
#   resources:
#     template: <<.Resource>>
#   name:
#     matches: ""
#     as: "my_external_metric"
#   metricsQuery: sum(<<.Series>>{<<.LabelMatchers>>}) by (<<.GroupBy>>)
  resource: #{}
    cpu:
      containerQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, container!=""}[3m])) by (<<.GroupBy>>)
      nodeQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, id='/'}[3m])) by (<<.GroupBy>>)
      resources:
        overrides:
          node:
            resource: node
          namespace:
            resource: namespace
          pod:
            resource: pod
      containerLabel: container
    memory:
      containerQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>, container!=""}) by (<<.GroupBy>>)
      nodeQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>,id='/'}) by (<<.GroupBy>>)
      resources:
        overrides:
          node:
            resource: node
          namespace:
            resource: namespace
          pod:
            resource: pod
      containerLabel: container
    window: 3m

service:
  annotations: {}
  port: 443
  type: ClusterIP
# clusterIP: 1.2.3.4

tls:
  enable: false
  ca: |-
    # Public CA file that signed the APIService
  key: |-
    # Private key of the APIService
  certificate: |-
    # Public key of the APIService

# Any extra arguments
extraArguments: []
  # - --tls-private-key-file=/etc/tls/tls.key
  # - --tls-cert-file=/etc/tls/tls.crt

# Any extra volumes
extraVolumes: []
  # - name: example-name
  #   hostPath:
  #     path: /path/on/host
  #     type: DirectoryOrCreate
  # - name: ssl-certs
  #   hostPath:
  #     path: /etc/ssl/certs/ca-bundle.crt
  #     type: File

# Any extra volume mounts
extraVolumeMounts: []
  #   - name: example-name
  #     mountPath: /path/in/container
  #   - name: ssl-certs
  #     mountPath: /etc/ssl/certs/ca-certificates.crt
  #     readOnly: true

tolerations: #[]
- effect: NoSchedule
  key: infra
  operator: Equal
  value: "true"
- effect: NoExecute
  key: infra
  operator: Equal
  value: "true"

# Labels added to the pod
podLabels: {}

# Annotations added to the pod
podAnnotations: {}

hostNetwork:
  # Specifies if prometheus-adapter should be started in hostNetwork mode.
  #
  # You would require this enabled if you use alternate overlay networking for pods and
  # API server unable to communicate with metrics-server. As an example, this is required
  # if you use Weave network on EKS. See also dnsPolicy
  enabled: false

# When hostNetwork is enabled, you probably want to set this to ClusterFirstWithHostNet
# dnsPolicy: ClusterFirstWithHostNet

# Deployment strategy type
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 25%
    maxSurge: 25%

podDisruptionBudget:
  # Specifies if PodDisruptionBudget should be enabled
  # When enabled, minAvailable or maxUnavailable should also be defined.
  enabled: false
  minAvailable:
  maxUnavailable: 1

certManager:
  enabled: false
  caCertDuration: 43800h
  certDuration: 8760h

CRD and clusterrole, what is use:
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-adapter-resource-reader-custom
rules:
- apiGroups:
  - metrics.k8s.io
  - custom.metrics.k8s.io
  resources:
  - nodes
  - namespaces
  - pods
  - services
  - configmaps
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-adapter-resource-reader-custom
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-adapter-resource-reader-custom
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:authenticated

Please provide the HPA resource used for autoscaling:

HPA yaml

Please provide the HPA status:
Please provide the prometheus-adapter logs with -v=6 around the time the issue happened:

prometheus-adapter logs
I1202 11:07:09.070064       1 round_trippers.go:454] POST https://10.96.0.1:443/apis/authorization.k8s.io/v1/subjectaccessreviews?timeout=10s 201 Created in 4 milliseconds
I1202 11:07:09.070382       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/metrics.k8s.io/v1beta1/namespaces/metrictest/pods/" satisfied by gorestful with webservice /apis/metrics.k8s.io/v1beta1
I1202 11:07:09.073046       1 api.go:76] GET http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090/api/v1/query?query=sum%28container_memory_working_set_bytes%7Bnamespace%3D%22metrictest%22%2Cpod%3D%22ubuntu-76868c99b-8r8nz%22%2C+container%21%3D%22%22%7D%29+by+%28pod%2Ccontainer%29&time=1638443229.07 200 OK
I1202 11:07:09.073694       1 api.go:76] GET http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090/api/v1/query?query=sum%28rate%28container_cpu_usage_seconds_total%7Bnamespace%3D%22metrictest%22%2Cpod%3D%22ubuntu-76868c99b-8r8nz%22%2C+container%21%3D%22%22%7D%5B3m%5D%29%29+by+%28pod%2Ccontainer%29&time=1638443229.07 200 OK
I1202 11:07:09.074392       1 httplog.go:104] "HTTP" verb="LIST" URI="/apis/metrics.k8s.io/v1beta1/namespaces/metrictest/pods/" latency="11.266463ms" userAgent="kubectl/v1.22.4 (linux/amd64) kubernetes/b695d79" audit-ID="00b85723-813f-4910-a45c-90370eb031c6" srcIP="10.244.165.129:46242" resp=200
I1202 11:07:09.906893       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/custom.metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/custom.metrics.k8s.io/v1beta1
I1202 11:07:09.906941       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/metrics.k8s.io/v1beta1
I1202 11:07:09.906946       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/custom.metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/custom.metrics.k8s.io/v1beta1
I1202 11:07:09.907298       1 httplog.go:104] "HTTP" verb="GET" URI="/apis/metrics.k8s.io/v1beta1" latency="908.847µs" userAgent="Go-http-client/2.0" audit-ID="46ea6016-33f2-4bf2-9c4e-20b2b2fa5c82" srcIP="10.244.15.65:1930" resp=200
I1202 11:07:09.907417       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/metrics.k8s.io/v1beta1
I1202 11:07:09.907569       1 httplog.go:104] "HTTP" verb="GET" URI="/apis/metrics.k8s.io/v1beta1" latency="1.098527ms" userAgent="Go-http-client/2.0" audit-ID="1a093341-a68f-4b62-8aff-21df4aca538e" srcIP="10.244.15.65:1930" resp=200
I1202 11:07:09.907725       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/metrics.k8s.io/v1beta1
I1202 11:07:09.907788       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/metrics.k8s.io/v1beta1
I1202 11:07:09.907872       1 httplog.go:104] "HTTP" verb="GET" URI="/apis/metrics.k8s.io/v1beta1" latency="244.201µs" userAgent="Go-http-client/2.0" audit-ID="f06b901f-cb17-4f44-b9aa-13fad3d9dca7" srcIP="10.244.15.65:1930" resp=200
I1202 11:07:09.907995       1 httplog.go:104] "HTTP" verb="GET" URI="/apis/metrics.k8s.io/v1beta1" latency="756.101µs" userAgent="Go-http-client/2.0" audit-ID="42e84464-0347-4165-a38c-adf26333ffbf" srcIP="10.244.15.65:1930" resp=200
I1202 11:07:09.908235       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/custom.metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/custom.metrics.k8s.io/v1beta1
I1202 11:07:09.908320       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/custom.metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/custom.metrics.k8s.io/v1beta1
I1202 11:07:09.909118       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/custom.metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/custom.metrics.k8s.io/v1beta1
I1202 11:07:09.911456       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/metrics.k8s.io/v1beta1" satisfied by gorestful with webservice /apis/metrics.k8s.io/v1beta1
I1202 11:07:09.912062       1 httplog.go:104] "HTTP" verb="GET" URI="/apis/metrics.k8s.io/v1beta1" latency="5.713701ms" userAgent="Go-http-client/2.0" audit-ID="660c269e-a856-4542-92fa-03b6b2701975" srcIP="10.244.15.65:1930" resp=200
I1202 11:07:09.917223       1 panic.go:965] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1" latency="10.704915ms" userAgent="Go-http-client/2.0" audit-ID="9b224052-60ab-4dbd-bdf3-dc669f6ebe02" srcIP="10.244.15.65:1930" resp=200
E1202 11:07:09.917356       1 wrap.go:54] timeout or abort while handling: method=GET URI="/apis/custom.metrics.k8s.io/v1beta1" audit-ID="9b224052-60ab-4dbd-bdf3-dc669f6ebe02"
E1202 11:07:09.919767       1 writers.go:117] apiserver was unable to write a JSON response: http: Handler timeout
E1202 11:07:09.919792       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http: Handler timeout"}: http: Handler timeout
E1202 11:07:09.921138       1 writers.go:130] apiserver was unable to write a fallback JSON response: http: Handler timeout
E1202 11:07:09.922464       1 timeout.go:135] post-timeout activity - time-elapsed: 5.269246ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
I1202 11:07:09.923495       1 panic.go:965] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1" latency="17.018894ms" userAgent="Go-http-client/2.0" audit-ID="74c4bd21-00e4-42d2-8d08-f3a50ef87f56" srcIP="10.244.15.65:1930" resp=200
E1202 11:07:09.923768       1 wrap.go:54] timeout or abort while handling: method=GET URI="/apis/custom.metrics.k8s.io/v1beta1" audit-ID="74c4bd21-00e4-42d2-8d08-f3a50ef87f56"
E1202 11:07:09.923563       1 writers.go:117] apiserver was unable to write a JSON response: http2: stream closed
I1202 11:07:09.925280       1 panic.go:965] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1" latency="17.342289ms" userAgent="Go-http-client/2.0" audit-ID="41fc5e4e-e675-49a3-a4b3-fb9ae585b990" srcIP="10.244.15.65:1930" resp=200
E1202 11:07:09.925315       1 wrap.go:54] timeout or abort while handling: method=GET URI="/apis/custom.metrics.k8s.io/v1beta1" audit-ID="41fc5e4e-e675-49a3-a4b3-fb9ae585b990"
E1202 11:07:09.925623       1 writers.go:117] apiserver was unable to write a JSON response: http2: stream closed
E1202 11:07:09.925779       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}: http2: stream closed
E1202 11:07:09.926792       1 writers.go:130] apiserver was unable to write a fallback JSON response: http2: stream closed
E1202 11:07:09.927279       1 writers.go:117] apiserver was unable to write a JSON response: http: Handler timeout
I1202 11:07:09.927288       1 panic.go:965] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1" latency="20.89346ms" userAgent="Go-http-client/2.0" audit-ID="7bca9bd4-ccdc-4710-97ac-b70606642be4" srcIP="10.244.15.65:1930" resp=200
E1202 11:07:09.927339       1 wrap.go:54] timeout or abort while handling: method=GET URI="/apis/custom.metrics.k8s.io/v1beta1" audit-ID="7bca9bd4-ccdc-4710-97ac-b70606642be4"
E1202 11:07:09.928867       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}: http2: stream closed
I1202 11:07:09.928940       1 panic.go:965] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1" latency="22.486459ms" userAgent="Go-http-client/2.0" audit-ID="2322817b-e5a0-46de-8884-cc30cfde766d" srcIP="10.244.15.65:1930" resp=200
E1202 11:07:09.928979       1 wrap.go:54] timeout or abort while handling: method=GET URI="/apis/custom.metrics.k8s.io/v1beta1" audit-ID="2322817b-e5a0-46de-8884-cc30cfde766d"
E1202 11:07:09.930517       1 writers.go:130] apiserver was unable to write a fallback JSON response: http2: stream closed
E1202 11:07:09.931717       1 timeout.go:135] post-timeout activity - time-elapsed: 8.063433ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E1202 11:07:09.931869       1 writers.go:117] apiserver was unable to write a JSON response: http: Handler timeout
E1202 11:07:09.932693       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http: Handler timeout"}: http: Handler timeout
E1202 11:07:09.936316       1 timeout.go:135] post-timeout activity - time-elapsed: 10.966862ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E1202 11:07:09.938603       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http: Handler timeout"}: http: Handler timeout
E1202 11:07:09.939741       1 writers.go:130] apiserver was unable to write a fallback JSON response: http: Handler timeout
E1202 11:07:09.942043       1 writers.go:130] apiserver was unable to write a fallback JSON response: http: Handler timeout
E1202 11:07:09.943399       1 timeout.go:135] post-timeout activity - time-elapsed: 16.03289ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E1202 11:07:09.944501       1 timeout.go:135] post-timeout activity - time-elapsed: 15.514882ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>

Anything else we need to know?:
Environment:

prometheus-adapter version:
prometheus version:
Kubernetes version (use kubectl version):
Cloud provider or hardware configuration:
Other info:

I can confirm that I have a similar issue on prometheus adapter too for HPA metrics:
I0124 08:07:03.695175       1 panic.go:965] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1" latency="13.121083ms" userAgent="Go-http-client/2.0" audit-ID="00852b29-ee12-4ca5-a3a0-7ac409030676" srcIP="10.10.83.8:37028" resp=200
E0124 08:07:03.695228       1 wrap.go:54] timeout or abort while handling: method=GET URI="/apis/custom.metrics.k8s.io/v1beta1" audit-ID="00852b29-ee12-4ca5-a3a0-7ac409030676"
E0124 08:07:03.699733       1 timeout.go:135] post-timeout activity - time-elapsed: 8.391775ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E0124 08:07:03.701850       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}: http2: stream closed
E0124 08:07:03.705776       1 writers.go:130] apiserver was unable to write a fallback JSON response: http2: stream closed
E0124 08:07:03.706976       1 timeout.go:135] post-timeout activity - time-elapsed: 11.711232ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>

And this is another sample:
I0124 08:07:24.439214       1 panic.go:965] "HTTP" verb="GET" URI="/apis/custom.metrics.k8s.io/v1beta1" latency="7.400871ms" userAgent="Go-http-client/2.0" audit-ID="238e4a59-3f27-42a0-9419-693c28c612fc" srcIP="10.10.86.133:40270" resp=200
E0124 08:07:24.439241       1 wrap.go:54] timeout or abort while handling: method=GET URI="/apis/custom.metrics.k8s.io/v1beta1" audit-ID="238e4a59-3f27-42a0-9419-693c28c612fc"
E0124 08:07:24.440844       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}: http2: stream closed
E0124 08:07:24.441032       1 writers.go:111] apiserver was unable to close cleanly the response writer: http: Handler timeout
E0124 08:07:24.441919       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}: http2: stream closed
E0124 08:07:24.444057       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http: Handler timeout"}: http: Handler timeout
E0124 08:07:24.447290       1 writers.go:130] apiserver was unable to write a fallback JSON response: http2: stream closed
E0124 08:07:24.448400       1 timeout.go:135] post-timeout activity - time-elapsed: 9.134867ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E0124 08:07:24.449509       1 writers.go:130] apiserver was unable to write a fallback JSON response: http2: stream closed
E0124 08:07:24.450578       1 writers.go:130] apiserver was unable to write a fallback JSON response: http: Handler timeout
E0124 08:07:24.451721       1 timeout.go:135] post-timeout activity - time-elapsed: 18.32554ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E0124 08:07:24.453869       1 timeout.go:135] post-timeout activity - time-elapsed: 19.8471ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E0124 08:07:24.454927       1 timeout.go:135] post-timeout activity - time-elapsed: 21.345959ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>

prometheus-adapter version: v0.9.1
prometheus version: 2.31.1
Kubernetes version (use kubectl version): v1.21.2-eks-06eac09
Cloud provider or hardware configuration: AWS EKS
Node OS: Bottlerocket OS 1.5.2 (aws-k8s-1.21)

Did you ever find a solution to the problems you were experiencing? @razorxster @AhmadMS1988

/reopen

I have exactly the same issue, I get timed out when trying to get custom metric. All the other resource metrics are working but my custom one is getting timed out.

repo: kubernetes-sigs/prometheus-adapter


text:
Images with SBOMs attached report as signed with sign.IsSigned()

If an image is not signed but has an sbom attached, passing it to sign.IsSigned() will return a false positive.
Can be rproduced with this reference :
gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20
# Download its signature
cosign download signature gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20
Error: no signatures associated with gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20
main.go:46: error during command execution: no signatures associated with gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20

# Download its SBOM:
cosign download sbom gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20
Found SBOM of media type: text/spdx
SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: github.com/puerco/supply-chain-demo
DocumentNamespace: http://spdx.org/spdxpackages/github.com/puerco/supply-chain-demo
Creator: Tool: ko 0.11.0
....

Upon further investigation I think i found the source for this bug and it is in the promoter code, not here. Fixing now → sorry for the noise :)
/close

repo: kubernetes-sigs/release-sdk


text:
Limit log enricher ttl cache size

What type of PR is this?
/kind feature
What this PR does / why we need it:
Limiting the cache sizes to not overflow the memory.
Which issue(s) this PR fixes:

None
Does this PR have test?
None

Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

Codecov Report

Merging #745 (5f01ffc) into main (e1231d2) will increase coverage by 0.01%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main     #745      +/-   ##
==========================================
+ Coverage   53.94%   53.95%   +0.01%
==========================================
  Files          41       41
  Lines        4121     4122       +1
==========================================
+ Hits         2223     2224       +1
  Misses       1831     1831
  Partials       67       67

Tide seems to have trouble with merging this PR…

@pjbgf I think this requires GitHub approval now.

Tide seems to have trouble with merging this PR…

Yes, we need to "github approve" as well as "/lgtm"

authors: codecov-commenter pjbgf saschagrunert


text:
Gateway Scheduling Constraints

What would you like to be added:
As a cluster operator, I need the ability to ensure a Gateway is scheduled to specific nodes.
Why is this needed:
My large cluster has been designed to constrain ingress connections to a specific group of nodes for security and performance purposes. I would like the ability to set a field that ensures the Gateway is scheduled to these nodes.

/kind user-story

Closing based on the consensus that Gateway scheduling is implementation specific.
cc: @ironcladlou @Miciah

authors: danehans jpeach

repo: kubernetes-sigs/service-apis


text:
Fix ClusterRoleBinding for kubeless chart

What this PR does / why we need it:
Enabling RBAC for incubator/kubeless causes the following error:
    Error: release kubeless failed: ClusterRoleBinding.rbac.authorization.k8s.io "kubeless-kubeless-controller-deployer" is invalid: subjects[0].namespace: Required value

This is caused by referencing invalid value from the ClusterRoleBinding.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:

/assign @prydonius @tompizmor @sameersbn

/ok-to-test

It seems good to me and all the tests have passed correctly.
@sameersbn, it would be ready to /lgtm

/lgtm

authors: carrodher faizhasim prydonius sameersbn

repo: kubernetes/charts


text:
Typo fix in unbound/README.md

fix some typos:
23: ip->IP
line 7: clusterip->ClusterIP
line 95: cluster IP->ClusterIP

/assign @foxish

/assign
/ok-to-test

/lgtm

@timstoop
Hello, This typo is very obvious, Please can you aprove it? It's here already one week.
Thanks a lot!

/lgtm

authors: AdamDang rjkernick unguiculus


text:
stable/fluent-bit: Add labels to all objects

Also: restrict the Service selector somewhat to include the release
name.
Fixes: #6672
See: https://github.com/kubernetes/charts/issues/6672

/assign @linki
CC @kfox1111 @edsiper

lgtm

/assign @kfox1111

/assign @edsiper

/lgtm

another 0.7 was merged recently. please bump the version again.

/lgtm

authors: NicolasT kfox1111 unguiculus


text:
[cinder-csi-plugin] csi-cinder-controllerplugin-0 CrashLoopBackOff always failed to running

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened:
csi-cinder-controllerplugin-0 always CrashLoopBackOff 3/5
csi-cinder-controllerplugin-0              3/5     CrashLoopBackOff   199        9h
csi-cinder-nodeplugin-5clsk                2/2     Running            0          9h
openstack-cloud-controller-manager-t5gzm   1/1     Running            1          12h

I had issue when install cinder-csi-plugin with error message
error: a container name must be specified for pod csi-cinder-controllerplugin-0, choose one of: [csi-attacher csi-provisioner csi-snapshotter csi-resizer cinder-csi-plugin]

already change branch repo with master or release-1.17 the error are same.
What you expected to happen:

no errors. k8s can integrate with cinder openstack

How to reproduce it:

Install external cloud provider
Install cinder-csi-plugin

Anything else we need to know?:

I have tried install with 2 different method  kubectl -f manifests/cinder-csi-plugin apply and helm install --namespace kube-system --generate-name ./charts/cinder-csi-plugin the errors are same

error: a container name must be specified for pod csi-cinder-controllerplugin-0, choose one of: [csi-attacher csi-provisioner csi-snapshotter csi-resizer cinder-csi-plugin]

Environment:

openstack-cloud-controller-manager(or other related binary) version:docker.io/k8scloudprovider/openstack-cloud-controller-manager:latest
OpenStack version: Train / rhosp16
K8s : v1.17.3
Others: Ubuntu 18.04 (1 master 1 worker)

@aryulianto Could you describe the pod and provide the o/p
kubectl describe pod csi-cinder-controllerplugin-0 -n kube-system
Looks like 2 containers are failing to start , need the container logs of those 2 containers.

@ramineni thank you for your prompt response, here is describing of csi-cinder-controllerplugin-0
root@k8s-master1:~/cloud-provider-openstack# kubectl describe pod csi-cinder-controllerplugin-0 -n kube-system
Name:         csi-cinder-controllerplugin-0
Namespace:    kube-system
Priority:     0
Node:         k8s-worker1/192.168.1.19
Start Time:   Wed, 22 Jul 2020 08:00:31 +0000
Labels:       app=csi-cinder-controllerplugin
              controller-revision-hash=csi-cinder-controllerplugin-89f46b78
              statefulset.kubernetes.io/pod-name=csi-cinder-controllerplugin-0
Annotations:  cni.projectcalico.org/podIP: 192.168.194.72/32
              cni.projectcalico.org/podIPs: 192.168.194.72/32
Status:       Running
IP:           192.168.194.72
IPs:
  IP:           192.168.194.72
Controlled By:  StatefulSet/csi-cinder-controllerplugin
Containers:
  csi-attacher:
    Container ID:  docker://e69abc8a77acab8232382befe2b62107dd2329484ab3866dc4fca4580cf93121
    Image:         quay.io/k8scsi/csi-attacher:v2.2.0
    Image ID:      docker-pullable://quay.io/k8scsi/csi-attacher@sha256:2ffa647e8107cfd39e5f464e738dce014c9f5e51b108da36c3ab621048d0bbab
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --timeout=3m
    State:          Running
      Started:      Wed, 22 Jul 2020 08:00:39 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:  /var/lib/csi/sockets/pluginproxy/csi.sock
    Mounts:
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from csi-cinder-controller-sa-token-v5qkm (ro)
  csi-provisioner:
    Container ID:  docker://7cee2a106b3b085c9a8e234e33b77c3c7e379a89c50efa1a8eed9062e432875a
    Image:         quay.io/k8scsi/csi-provisioner:v1.6.0
    Image ID:      docker-pullable://quay.io/k8scsi/csi-provisioner@sha256:78e3393f5fd5ff6c1e5dada2478cfa456fb7164929e573cf9a87bf6532730679
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --timeout=3m
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    255
      Started:      Wed, 22 Jul 2020 08:02:03 +0000
      Finished:     Wed, 22 Jul 2020 08:02:33 +0000
    Ready:          False
    Restart Count:  2
    Environment:
      ADDRESS:  /var/lib/csi/sockets/pluginproxy/csi.sock
    Mounts:
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from csi-cinder-controller-sa-token-v5qkm (ro)
  csi-snapshotter:
    Container ID:  docker://a9500220d9a923fc157fe8eec89a1a9d9472c5e657f8d178cf39f27a72c358d2
    Image:         quay.io/k8scsi/csi-snapshotter:v1.2.2
    Image ID:      docker-pullable://quay.io/k8scsi/csi-snapshotter@sha256:fbef4d21ec79c9c5aced2e0e0396b9272e69ffe4cc718c3602ae6a466f682d41
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
    State:          Terminated
      Reason:       Error
      Exit Code:    255
      Started:      Wed, 22 Jul 2020 08:02:08 +0000
      Finished:     Wed, 22 Jul 2020 08:02:38 +0000
    Last State:     Terminated
      Reason:       Error
      Exit Code:    255
      Started:      Wed, 22 Jul 2020 08:01:20 +0000
      Finished:     Wed, 22 Jul 2020 08:01:50 +0000
    Ready:          False
    Restart Count:  2
    Environment:
      ADDRESS:  /var/lib/csi/sockets/pluginproxy/csi.sock
    Mounts:
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from csi-cinder-controller-sa-token-v5qkm (ro)
  csi-resizer:
    Container ID:  docker://db446910732e66007977da5e00267e43911ce2e5ad0161141183058a75dde1eb
    Image:         quay.io/k8scsi/csi-resizer:v0.4.0
    Image ID:      docker-pullable://quay.io/k8scsi/csi-resizer@sha256:6883482c4c4bd0eabb83315b5a9e8d9c0f34357980489a679a56441ec74c24c9
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
    State:          Running
      Started:      Wed, 22 Jul 2020 08:00:45 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:  /var/lib/csi/sockets/pluginproxy/csi.sock
    Mounts:
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from csi-cinder-controller-sa-token-v5qkm (ro)
  cinder-csi-plugin:
    Container ID:  docker://39e1c8db6ca8e6f47fef1a98d8186903c5b31bd8d27064b352dc44a8a94323ce
    Image:         docker.io/k8scloudprovider/cinder-csi-plugin:latest
    Image ID:      docker-pullable://k8scloudprovider/cinder-csi-plugin@sha256:4f938045198e45ef69e2d7700991fcc455424e9b45ec0cde367d02bc9a52a1c5
    Port:          <none>
    Host Port:     <none>
    Args:
      /bin/cinder-csi-plugin
      --nodeid=$(NODE_ID)
      --endpoint=$(CSI_ENDPOINT)
      --cloud-config=$(CLOUD_CONFIG)
      --cluster=$(CLUSTER_NAME)
    State:          Running
      Started:      Wed, 22 Jul 2020 08:00:46 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      NODE_ID:        (v1:spec.nodeName)
      CSI_ENDPOINT:  unix://csi/csi.sock
      CLOUD_CONFIG:  /etc/config/cloud.conf
      CLUSTER_NAME:  kubernetes
    Mounts:
      /csi from socket-dir (rw)
      /etc/config from secret-cinderplugin (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from csi-cinder-controller-sa-token-v5qkm (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  socket-dir:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  secret-cinderplugin:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  cloud-config
    Optional:    false
  csi-cinder-controller-sa-token-v5qkm:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  csi-cinder-controller-sa-token-v5qkm
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                   From                  Message
  ----     ------     ----                  ----                  -------
  Normal   Scheduled  2m21s                 default-scheduler     Successfully assigned kube-system/csi-cinder-controllerplugin-0 to k8s-worker1
  Normal   Pulled     2m16s                 kubelet, k8s-worker1  Container image "quay.io/k8scsi/csi-attacher:v2.2.0" already present on machine
  Normal   Created    2m13s                 kubelet, k8s-worker1  Created container csi-attacher
  Normal   Started    2m12s                 kubelet, k8s-worker1  Started container csi-attacher
  Normal   Started    2m7s                  kubelet, k8s-worker1  Started container csi-resizer
  Normal   Created    2m7s                  kubelet, k8s-worker1  Created container csi-resizer
  Normal   Pulled     2m7s                  kubelet, k8s-worker1  Container image "quay.io/k8scsi/csi-resizer:v0.4.0" already present on machine
  Normal   Pulled     2m7s                  kubelet, k8s-worker1  Container image "docker.io/k8scloudprovider/cinder-csi-plugin:latest" already present on machine
  Normal   Started    2m6s                  kubelet, k8s-worker1  Started container cinder-csi-plugin
  Normal   Created    2m6s                  kubelet, k8s-worker1  Created container cinder-csi-plugin
  Normal   Pulled     101s (x2 over 2m12s)  kubelet, k8s-worker1  Container image "quay.io/k8scsi/csi-provisioner:v1.6.0" already present on machine
  Normal   Created    100s (x2 over 2m12s)  kubelet, k8s-worker1  Created container csi-provisioner
  Normal   Started    98s (x2 over 2m12s)   kubelet, k8s-worker1  Started container csi-provisioner
  Normal   Pulling    96s (x2 over 2m12s)   kubelet, k8s-worker1  Pulling image "quay.io/k8scsi/csi-snapshotter:v1.2.2"
  Normal   Pulled     93s (x2 over 2m8s)    kubelet, k8s-worker1  Successfully pulled image "quay.io/k8scsi/csi-snapshotter:v1.2.2"
  Normal   Created    92s (x2 over 2m8s)    kubelet, k8s-worker1  Created container csi-snapshotter
  Normal   Started    92s (x2 over 2m7s)    kubelet, k8s-worker1  Started container csi-snapshotter
  Warning  BackOff    69s                   kubelet, k8s-worker1  Back-off restarting failed container
  Warning  BackOff    61s                   kubelet, k8s-worker1  Back-off restarting failed container

root@k8s-master1:~/cloud-provider-openstack# kubectl logs csi-cinder-controllerplugin-0 -n kube-system
error: a container name must be specified for pod csi-cinder-controllerplugin-0, choose one of: [csi-attacher csi-provisioner csi-snapshotter csi-resizer cinder-csi-plugin]

@aryulianto looks like 2 containers csi-provisioner , csi-snapshotter are failing . For logs ,  you need to specify container name as well here
kubectl logs csi-cinder-controllerplugin-0 -c csi-provisioner  -n kube-system
kubectl logs csi-cinder-controllerplugin-0 -c csi-snapshotter  -n kube-system

@ramineni thank you, I got the error. any suggestions for my case?
kubectl logs csi-cinder-controllerplugin-0 -n kube-system
error: a container name must be specified for pod csi-cinder-controllerplugin-0, choose one of: [csi-attacher csi-provisioner csi-snapshotter csi-resizer cinder-csi-plugin]
root@ar-master:/etc/ssl/certs# kubectl logs csi-cinder-controllerplugin-0 -n kube-system -c cinder-csi-plugin
I0723 04:23:21.527201       1 driver.go:69] Driver: cinder.csi.openstack.org
I0723 04:23:21.527252       1 driver.go:70] Driver version: 1.2.0@latest
I0723 04:23:21.527256       1 driver.go:71] CSI Spec version: 1.2.0
I0723 04:23:21.527263       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES
I0723 04:23:21.527268       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_VOLUME
I0723 04:23:21.527271       1 driver.go:100] Enabling controller service capability: PUBLISH_UNPUBLISH_VOLUME
I0723 04:23:21.527274       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_SNAPSHOT
I0723 04:23:21.527277       1 driver.go:100] Enabling controller service capability: LIST_SNAPSHOTS
I0723 04:23:21.527280       1 driver.go:100] Enabling controller service capability: EXPAND_VOLUME
I0723 04:23:21.527288       1 driver.go:100] Enabling controller service capability: CLONE_VOLUME
I0723 04:23:21.527291       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES_PUBLISHED_NODES
I0723 04:23:21.527298       1 driver.go:112] Enabling volume access mode: SINGLE_NODE_WRITER
I0723 04:23:21.527301       1 driver.go:122] Enabling node service capability: STAGE_UNSTAGE_VOLUME
I0723 04:23:21.527307       1 driver.go:122] Enabling node service capability: EXPAND_VOLUME
I0723 04:23:21.527310       1 driver.go:122] Enabling node service capability: GET_VOLUME_STATS
I0723 04:23:21.527780       1 openstack.go:87] Block storage opts: {0 false}
W0723 04:23:21.527985       1 main.go:108] Failed to GetOpenStackProvider: failed to read and parse /etc/ssl/certs/ca.pem certificate: open /etc/ssl/certs/ca.pem: no such file or directory

root@k8s-master1:/etc/ssl/certs# ls -la /etc/ssl/certs/ca.pem
-rwxr-xr-x 1 root root 1229 Jul 23 04:22 /etc/ssl/certs/ca.pem

cloud.conf config
[Global]
auth-url=https://xxxxxxxxxxxxx:443/v3
username=xxxxxxxxxx
password=xxxxxxxxxxxx
region=xxxxxx
tenant-name=xxxxxxx
domain-name=xxxxxx
ca-file=/etc/ssl/certs/ca.pem

[BlockStorage]
bs-version=v2

cinder csi config
cat manifests/cinder-csi-plugin/cinder-csi-controllerplugin.yaml  |grep volumes -A10
      volumes:
        - name: socket-dir
          emptyDir:
        - name: secret-cinderplugin
          secret:
            secretName: cloud-config
        - name: cacert
          hostPath:
            path: /etc/ssl/certs/
            type: Directory

cat manifests/cinder-csi-plugin/cinder-csi-nodeplugin.yaml |grep volumes -A30
      volumes:
        - name: socket-dir
          hostPath:
            path: /var/lib/kubelet/plugins/cinder.csi.openstack.org
            type: DirectoryOrCreate
        - name: registration-dir
          hostPath:
            path: /var/lib/kubelet/plugins_registry/
            type: Directory
        - name: kubelet-dir
          hostPath:
            path: /var/lib/kubelet
            type: Directory
        - name: pods-cloud-data
          hostPath:
            path: /var/lib/cloud/data
            type: Directory
        - name: pods-probe-dir
          hostPath:
            path: /dev
            type: Directory
        - name: secret-cinderplugin
          secret:
            secretName: cloud-config
        - name: cacert
          hostPath:
            path: /etc/ssl/certs/
            type: Directory

@aryulianto could u show me the part it is mounted in container as well, make sure it is on /etc/ssl/certs

@ramineni I got it, I miss add it to volumeMounts
But after recreate. I still got error:
NAME                                       READY   STATUS             RESTARTS   AGE
csi-cinder-controllerplugin-0              4/5     CrashLoopBackOff   5          7m14s

Logs
kubectl logs csi-cinder-controllerplugin-0 -n kube-system -c cinder-csi-plugin
I0723 05:44:03.180236       1 driver.go:69] Driver: cinder.csi.openstack.org
I0723 05:44:03.180300       1 driver.go:70] Driver version: 1.2.0@latest
I0723 05:44:03.180304       1 driver.go:71] CSI Spec version: 1.2.0
I0723 05:44:03.180311       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES
I0723 05:44:03.180315       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_VOLUME
I0723 05:44:03.180319       1 driver.go:100] Enabling controller service capability: PUBLISH_UNPUBLISH_VOLUME
I0723 05:44:03.180321       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_SNAPSHOT
I0723 05:44:03.180324       1 driver.go:100] Enabling controller service capability: LIST_SNAPSHOTS
I0723 05:44:03.180349       1 driver.go:100] Enabling controller service capability: EXPAND_VOLUME
I0723 05:44:03.180353       1 driver.go:100] Enabling controller service capability: CLONE_VOLUME
I0723 05:44:03.180355       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES_PUBLISHED_NODES
I0723 05:44:03.180366       1 driver.go:112] Enabling volume access mode: SINGLE_NODE_WRITER
I0723 05:44:03.180369       1 driver.go:122] Enabling node service capability: STAGE_UNSTAGE_VOLUME
I0723 05:44:03.180376       1 driver.go:122] Enabling node service capability: EXPAND_VOLUME
I0723 05:44:03.180379       1 driver.go:122] Enabling node service capability: GET_VOLUME_STATS
I0723 05:44:03.181050       1 openstack.go:87] Block storage opts: {0 false}
W0723 05:44:33.182257       1 main.go:108] Failed to GetOpenStackProvider: Post "https://xxxxxxxxxx:443/v3/auth/tokens": dial tcp: i/o timeout

@aryulianto hmm, could you check connection to openstack keystone from controller node works fine. You could also increase verbose level to 6 and get the logs

@ramineni I had made sure the connection from the controller to the keystone works fine with curl.
while :;do curl https://keystone.xxxxxxxxxxxxx:443/v3/;sleep 1; echo "";done
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}

Logs with verbose 6
kubectl logs csi-cinder-controllerplugin-0 -n kube-system -c cinder-csi-plugin -v 6
I0723 06:28:35.516530    1784 loader.go:375] Config loaded from file:  /root/.kube/config
I0723 06:28:35.533298    1784 round_trippers.go:443] GET https://10.10.10.13:6443/api/v1/namespaces/kube-system/pods/csi-cinder-controllerplugin-0 200 OK in 11 milliseconds
I0723 06:28:35.564295    1784 round_trippers.go:443] GET https://10.10.10.13:6443/api/v1/namespaces/kube-system/pods/csi-cinder-controllerplugin-0/log?container=cinder-csi-plugin 200 OK in 18 milliseconds
I0723 06:26:52.470380       1 driver.go:69] Driver: cinder.csi.openstack.org
I0723 06:26:52.470436       1 driver.go:70] Driver version: 1.2.0@latest
I0723 06:26:52.470443       1 driver.go:71] CSI Spec version: 1.2.0
I0723 06:26:52.470454       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES
I0723 06:26:52.470462       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_VOLUME
I0723 06:26:52.470466       1 driver.go:100] Enabling controller service capability: PUBLISH_UNPUBLISH_VOLUME
I0723 06:26:52.470480       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_SNAPSHOT
I0723 06:26:52.470485       1 driver.go:100] Enabling controller service capability: LIST_SNAPSHOTS
I0723 06:26:52.470491       1 driver.go:100] Enabling controller service capability: EXPAND_VOLUME
I0723 06:26:52.470501       1 driver.go:100] Enabling controller service capability: CLONE_VOLUME
I0723 06:26:52.470506       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES_PUBLISHED_NODES
I0723 06:26:52.470525       1 driver.go:112] Enabling volume access mode: SINGLE_NODE_WRITER
I0723 06:26:52.470532       1 driver.go:122] Enabling node service capability: STAGE_UNSTAGE_VOLUME
I0723 06:26:52.470543       1 driver.go:122] Enabling node service capability: EXPAND_VOLUME
I0723 06:26:52.470551       1 driver.go:122] Enabling node service capability: GET_VOLUME_STATS
I0723 06:26:52.470995       1 openstack.go:87] Block storage opts: {0 false}
W0723 06:27:22.472216       1 main.go:108] Failed to GetOpenStackProvider: Post "https://keystone.jkt-1.neo.id:443/v3/auth/tokens": dial tcp: i/o timeout

@ramineni I had made sure the connection from the controller to the keystone works fine with curl.
while :;do curl https://keystone.xxxxxxxxxxxxx:443/v3/;sleep 1; echo "";done
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}
{"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "https://keystone.xxxxxxxxxxxxx:443/v3/", "rel": "self"}]}}

Logs with verbose 6
kubectl logs csi-cinder-controllerplugin-0 -n kube-system -c cinder-csi-plugin -v 6
I0723 06:28:35.516530    1784 loader.go:375] Config loaded from file:  /root/.kube/config
I0723 06:28:35.533298    1784 round_trippers.go:443] GET https://10.10.10.13:6443/api/v1/namespaces/kube-system/pods/csi-cinder-controllerplugin-0 200 OK in 11 milliseconds
I0723 06:28:35.564295    1784 round_trippers.go:443] GET https://10.10.10.13:6443/api/v1/namespaces/kube-system/pods/csi-cinder-controllerplugin-0/log?container=cinder-csi-plugin 200 OK in 18 milliseconds
I0723 06:26:52.470380       1 driver.go:69] Driver: cinder.csi.openstack.org
I0723 06:26:52.470436       1 driver.go:70] Driver version: 1.2.0@latest
I0723 06:26:52.470443       1 driver.go:71] CSI Spec version: 1.2.0
I0723 06:26:52.470454       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES
I0723 06:26:52.470462       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_VOLUME
I0723 06:26:52.470466       1 driver.go:100] Enabling controller service capability: PUBLISH_UNPUBLISH_VOLUME
I0723 06:26:52.470480       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_SNAPSHOT
I0723 06:26:52.470485       1 driver.go:100] Enabling controller service capability: LIST_SNAPSHOTS
I0723 06:26:52.470491       1 driver.go:100] Enabling controller service capability: EXPAND_VOLUME
I0723 06:26:52.470501       1 driver.go:100] Enabling controller service capability: CLONE_VOLUME
I0723 06:26:52.470506       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES_PUBLISHED_NODES
I0723 06:26:52.470525       1 driver.go:112] Enabling volume access mode: SINGLE_NODE_WRITER
I0723 06:26:52.470532       1 driver.go:122] Enabling node service capability: STAGE_UNSTAGE_VOLUME
I0723 06:26:52.470543       1 driver.go:122] Enabling node service capability: EXPAND_VOLUME
I0723 06:26:52.470551       1 driver.go:122] Enabling node service capability: GET_VOLUME_STATS
I0723 06:26:52.470995       1 openstack.go:87] Block storage opts: {0 false}
W0723 06:27:22.472216       1 main.go:108] Failed to GetOpenStackProvider: Post "https://keystone.xxxxxxxxxxxxx:443/v3/auth/tokens": dial tcp: i/o timeout

@aryulianto you need to add the flag here, https://github.com/kubernetes/cloud-provider-openstack/blob/master/manifests/cinder-csi-plugin/cinder-csi-controllerplugin.yaml#L90 , - --v=6 , and recreate the manifests

@ramineni already added. my cloud.conf at https://github.com/kubernetes/cloud-provider-openstack/issues/1126#issuecomment-662814285
kubectl logs -f csi-cinder-controllerplugin-0 -n kube-system -c cinder-csi-plugin
I0723 06:55:21.247962       1 driver.go:69] Driver: cinder.csi.openstack.org
I0723 06:55:21.248032       1 driver.go:70] Driver version: 1.2.0@latest
I0723 06:55:21.248038       1 driver.go:71] CSI Spec version: 1.2.0
I0723 06:55:21.248046       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES
I0723 06:55:21.248050       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_VOLUME
I0723 06:55:21.248054       1 driver.go:100] Enabling controller service capability: PUBLISH_UNPUBLISH_VOLUME
I0723 06:55:21.248060       1 driver.go:100] Enabling controller service capability: CREATE_DELETE_SNAPSHOT
I0723 06:55:21.248063       1 driver.go:100] Enabling controller service capability: LIST_SNAPSHOTS
I0723 06:55:21.248074       1 driver.go:100] Enabling controller service capability: EXPAND_VOLUME
I0723 06:55:21.248077       1 driver.go:100] Enabling controller service capability: CLONE_VOLUME
I0723 06:55:21.248081       1 driver.go:100] Enabling controller service capability: LIST_VOLUMES_PUBLISHED_NODES
I0723 06:55:21.248085       1 driver.go:112] Enabling volume access mode: SINGLE_NODE_WRITER
I0723 06:55:21.248088       1 driver.go:122] Enabling node service capability: STAGE_UNSTAGE_VOLUME
I0723 06:55:21.248094       1 driver.go:122] Enabling node service capability: EXPAND_VOLUME
I0723 06:55:21.248097       1 driver.go:122] Enabling node service capability: GET_VOLUME_STATS
I0723 06:55:21.248105       1 openstack.go:117] InitOpenStackProvider configFile: /etc/config/cloud.conf
I0723 06:55:21.248566       1 openstack.go:234] AuthURL: https://keystone.xxxxxxxxxxxxx:443/v3
I0723 06:55:21.248579       1 openstack.go:235] UserID:
I0723 06:55:21.248583       1 openstack.go:236] Username: username
I0723 06:55:21.248587       1 openstack.go:237] TenantID:
I0723 06:55:21.248590       1 openstack.go:238] TenantName: xxxxx
I0723 06:55:21.248594       1 openstack.go:239] TrustID:
I0723 06:55:21.248597       1 openstack.go:240] DomainID:
I0723 06:55:21.248601       1 openstack.go:241] DomainName: xxxxx
I0723 06:55:21.248604       1 openstack.go:242] TenantDomainID:
I0723 06:55:21.248608       1 openstack.go:243] TenantDomainName:
I0723 06:55:21.248613       1 openstack.go:244] UserDomainID:
I0723 06:55:21.248616       1 openstack.go:245] UserDomainName:
I0723 06:55:21.248620       1 openstack.go:246] Region: xxxxxx
I0723 06:55:21.248624       1 openstack.go:247] CAFile: /etc/ssl/certs/ca.pem
I0723 06:55:21.248628       1 openstack.go:248] UseClouds: false
I0723 06:55:21.248633       1 openstack.go:249] CloudsFile:
I0723 06:55:21.248637       1 openstack.go:250] Cloud:
I0723 06:55:21.248641       1 openstack.go:251] ApplicationCredentialID:
I0723 06:55:21.248645       1 openstack.go:252] ApplicationCredentialName:
I0723 06:55:21.248648       1 openstack.go:87] Block storage opts: {0 false}
I0723 06:55:21.248749       1 openstack.go:505] Using user-agent cinder-csi-plugin/latest gophercloud/2.0.0
I0723 06:55:21.249641       1 openstack.go:556] OpenStack Request URL: POST https://keystone.xxxxxxxxxxxxx:443/v3/auth/tokens
I0723 06:55:21.249685       1 openstack.go:556] OpenStack Request Headers:
I0723 06:55:21.249691       1 openstack.go:556] Accept: application/json
I0723 06:55:21.249697       1 openstack.go:556] Content-Type: application/json
I0723 06:55:21.249703       1 openstack.go:556] User-Agent: cinder-csi-plugin/latest gophercloud/2.0.0
I0723 06:55:21.249780       1 openstack.go:556] OpenStack Request Body: {
I0723 06:55:21.249794       1 openstack.go:556]   "auth": {
I0723 06:55:21.249801       1 openstack.go:556]     "identity": {
I0723 06:55:21.249807       1 openstack.go:556]       "methods": [
I0723 06:55:21.249817       1 openstack.go:556]         "password"
I0723 06:55:21.249841       1 openstack.go:556]       ],
I0723 06:55:21.249849       1 openstack.go:556]       "password": {
I0723 06:55:21.249855       1 openstack.go:556]         "user": {
I0723 06:55:21.249864       1 openstack.go:556]           "domain": {
I0723 06:55:21.249870       1 openstack.go:556]             "name": "xxxxx"
I0723 06:55:21.249876       1 openstack.go:556]           },
I0723 06:55:21.249883       1 openstack.go:556]           "name": "xxxxxx",
I0723 06:55:21.249890       1 openstack.go:556]           "password": "***"
I0723 06:55:21.249896       1 openstack.go:556]         }
I0723 06:55:21.249902       1 openstack.go:556]       }
I0723 06:55:21.249908       1 openstack.go:556]     },
I0723 06:55:21.249915       1 openstack.go:556]     "scope": {
I0723 06:55:21.249921       1 openstack.go:556]       "project": {
I0723 06:55:21.249927       1 openstack.go:556]         "domain": {
I0723 06:55:21.249933       1 openstack.go:556]           "name": "xxxxxx"
I0723 06:55:21.249939       1 openstack.go:556]         },
I0723 06:55:21.249945       1 openstack.go:556]         "name": "xxxxxxxx"
I0723 06:55:21.249951       1 openstack.go:556]       }
I0723 06:55:21.249957       1 openstack.go:556]     }
I0723 06:55:21.249963       1 openstack.go:556]   }
I0723 06:55:21.249969       1 openstack.go:556] }
I0723 06:55:51.254283       1 openstack.go:556] OpenStack connection error, retries exhausted. Aborting
W0723 06:55:51.255210       1 main.go:108] Failed to GetOpenStackProvider: Post "https://keystone.xxxxxxxxxxxxx:443/v3/auth/tokens": OpenStack connection error, retries exhausted. Aborting. Last error was: dial tcp: i/o timeout

@aryulianto is the issue resolved?
@lingxiankong @kayrus any idea on the error?

hi @ramineni not yet. I still experience this issue

@aryulianto you only defined the volume in the manifest file, but you didn't mount it
here's my configuration which works fine on my env: you might want to replicate to your env with your special settings
....
     volumeMounts:
            ...
            - name: cacert
              mountPath: /etc/cacert
              readOnly: true
      volumes:
        .....
        - name: cacert
          hostPath:
            path: /etc/cacert
            type: Directory

hi @jichenjc I already did that
...
          volumeMounts:
            - name: socket-dir
              mountPath: /csi
            - name: secret-cinderplugin
              mountPath: /etc/config
              readOnly: true
            - name: cacert
              mountPath: /etc/ssl/certs
              readOnly: true
      volumes:
        - name: socket-dir
          emptyDir:
        - name: secret-cinderplugin
          secret:
            secretName: cloud-config
        - name: cacert
          hostPath:
            path: /etc/ssl/certs
            type: Directory

ok so originally issue is
 failed to read and parse /etc/ssl/certs/ca.pem certificate: open /etc/ssl/certs/ca.pem: no such file or directory
and now the error is
Failed to GetOpenStackProvider: Post "https://keystone.xxxxxxxxxxxxx:443/v3/auth/tokens": OpenStack connection error, retries exhausted. Aborting. Last error was: dial tcp: i/o timeout
so the cert issue should be fixed
when you say
I had made sure the connection from the controller to the keystone works fine with curl.
where did you run this ? in the container or somewhere?
I used to suffer this kind of issue as well, the root cause is my DNS has some problem
I can access from the node running cloud provider correctly but inside the container it's not able to parse the DNS
I updated the DNS in the new created pod (CSI controller and node controller) and fixed the problem

yes right, cert issue has been fixed.

when you say
I had made sure the connection from the controller to the keystone works fine with curl.
where did you run this ? in the container or somewhere?

I test on my k8s master and worker nodes
Will do to check my DNS.

@aryulianto has this issue been fixed? if so , we can close this issue

/close
we haven't get feedback until now

authors: aryulianto jichenjc ramineni

repo: kubernetes/cloud-provider-openstack


text:
Add CI jobs for Manila CSI Driver

/kind Feature
What happened:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

openstack-cloud-controller-manager version:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

cc @gman0

@adisky yes, CI tests are in the plan

/assign

@adisky can you assign me please?

/assign @gman0

@gman0 Please apply for k8s community membership
https://github.com/kubernetes/community/blob/master/community-membership.md

xref for csi-sanity tests https://github.com/kubernetes/cloud-provider-openstack/issues/714

xref for Zuul acceptance job https://github.com/theopenlab/openlab-zuul-jobs/pull/624

/remove-lifecycle stale

/assign


text:
[manila-csi-plugin] bumped snapshot.storage.k8s.io API to v1

What this PR does / why we need it:
This PR bumps snapshot.storage.k8s.io API to v1 in manila-csi-plugin snapshot examples.
Release note:

NONE

@ramineni @jichenjc I've noticed v1beta1 is used in snapshot examples for cinder-csi. Do you want me to update them (in a separate PR) too?

@ramineni @jichenjc I've noticed v1beta1 is used in snapshot examples for cinder-csi. Do you want me to update them (in a separate PR) too?

sure, that should be helpful , curious why our CI didn't find it , will do a quick check

looks like the original issue is
"CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1" so guess my comments originially might mislead (I realized that just now as well)
so your v2.1 version CRD apiextensions.k8s.io/v1beta1 is not valid anymore
but if we bump to 4.1 then apiextensions.k8s.io/v1 exist so eveything fine
and external controller   v1/v1beta1 both still exist so that's why csi-cinder is ok with test

@Fedosin ah, thanks! I'm closing this then.


text:
Distributors Removal for Weaveworks

Given the closing of Weaveworks, I've reached out to see if we can remove Weave from the Kubernetes distributors list. The last posted conformance tests for Weave was Kubernetes 1.27, and now that Kubernetes 1.27 is EOL (as of June 28, 2024), we won’t be issuing any more patches for old versions.
I'll give it a week, and remove if we don't get positive verification of current distributions or confirmation of removal.

/reopen
/lifecycle frozen
We shouldn't auto-close this kind of issue.

authors: micahhausler sftim

repo: kubernetes/committee-security-response


text:
handle closed & duplicate issues

Fixes #1060. Running this against my test repo now.

Everything works except that it doesn't find closed issues. I will fix that.

wow, i'll have to take a look.  But walking all open and closed issues, even once, is a non-starter...

Only need to get titles from the closed issues. Should be like 250 extra
calls or something?
On May 24, 2016 7:22 PM, "Eric Paris" notifications@github.com wrote:

wow, i'll have to take a look. But walking all open and closed issues,
even once, is a non-starter...
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/contrib/pull/1061#issuecomment-221456608

Actually it's even better than that-- just need to get titles of closed issues labeled kind/flake. Should just be a few calls.

...and implemented. Super easy. Example issue referencing closed issues here: https://github.com/lavalamp/issue-testing/issues/22
Example closed dup here: https://github.com/lavalamp/issue-testing/issues/5#issuecomment-221447391

Hm, I've introduced a bug. Don't merge yet, it's filing extra issues.

I'll take a look in the morning at what you're doing. The only way cherry-pick queue works is by looking at cherrypick-candidate which keeps the list small.   kind/flake is ok I guess, so I'll check out the mechanism you are using.

I'll give you time to review before I merge it :)
I want to let it go overnight against my test repo anyway.

OK, cleaned up. Running against my test repo. Should be ready to go as long as @eparis approves. Example with lots of old issues: https://github.com/lavalamp/issue-testing/issues/28

Hm, spoke too soon. let me debug some more before you merge this.

Oh, I didn't speak too soon. There were just a ton of similar but actually different tests that failed at once, and I mistook it for it filing duplicates.

OK, if I change the dup logic to pick the oldest issue, is that sufficient? I want to get this train moving because it's blocking a couple others...

@eparis PTAL really want to get this in production.

authors: eparis lavalamp

repo: kubernetes/contrib


text:
error upgrading connection: unable to upgrade connection: Forbidden (user=system:anonymous

when I run "helm install fabric8/fabric8-platform  ",it outputs:
Error: forwarding ports: error upgrading connection: unable to upgrade connection: Forbidden (user=system:anonymous, verb=create, resource=nodes, subresource=proxy)
I have bind the role as below,but it does not work:
kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

@zzq392342084
Sorry you are having trouble. I successfully installed the "fabric8/fabric8-platform" chart. My tiller service account was created the same way but my Tiller was installed using helm init --service-account tilller. It appears that its more of a connection problem. Can you run other helm commands like installing a different chart?

@zzq392342084 If you haven't already, can you delete the Tiller pod and let it re-spawn?

I have tried that ,but the problem is still :
kubectl -n kube-system port-forward tiller-deploy-3720707438-ljqpr   :44134
error: error upgrading connection: unable to upgrade connection: Forbidden (user=system:anonymous, verb=create, resource=nodes, subresource=proxy)

/remove-lifecycle rotten
got the same issue after upgrading azure AKS cluster to 1.9.6
the error also appears when using kubectl logs and exec or in general anything that calls nodes:proxy. why is my user system:anonymous?

as as temporary workaround i logged into the node and changed /etc/defaults/kubelet to --authorization-mode=AllowAll instead of WebHook, then i reinstalled tiller, now the error disappeared from helm, but that doesn't feel like a real solution.

https://github.com/Azure/AKS/issues/418

i managed to create a workaround by applying this yaml:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: anonymous-logs-role
rules:
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["create", "get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: anonymous-logs-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: anonymous-logs-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: system:anonymous

this way logs, exec and attach work and the api server doesn't expose any information. are there any drawbacks to this solution?

Thanks @markusdresch your solution works if you update the User name field in the following stanza to match your user that the helm client is using.

apiGroup: rbac.authorization.k8s.io
kind: User
name: system:anonymous

The user name is this part of the error you got:
Error: forwarding ports: error upgrading connection: unable to upgrade connection: Forbidden (user=system:node:master1, verb=create, resource=nodes, subresource=proxy)

Closing as answered.

repo: kubernetes/helm


text:
update google.golang.org/grpc to 1.7.2

Versions after 13 July 2017 of grpc-go require context to be explicitly set to outgoing or incoming, for security reasons.  This is a breaking change, and the only one preventing from bumping to 1.7.2.
This PR allows repositories that flatten all their dependencies (e.g., with Bazel) to depend on the latest versions of gRPC and Helm in a sane way.
See https://github.com/grpc/grpc-go/issues/1219 for an explanation

I signed it!

I pulled this into the bugfix branch because #3129 needs this work

Because this is a critical library that we are updating, I'd like at least one other maintainer sign off before merging. cc @adamreese or @bacongobbler
Also, thanks @hchauvin for doing the work on updating this!

code LGTM, but we should probably give this a spin to make sure everything's fine.

@bacongobbler Feel free to give it a spin. This code is in #3129 and people are battle testing that to make sure it works, so when the others finish testing it, I'll feel fairly confident

I am going to merge this to unblock a few other PRs. @helgi has done some testing, so I am pretty confident. However, I am moving this to 2.8.0 because we've had previous experiences of gRPC interop between versions, and 2.7.3 must be compatible with 2.7.0.

authors: bacongobbler hchauvin technosophos thomastaylor312


text:
refactor controllers.go

remove duplicate code, and fmt some code

This change is

Coverage increased (+0.03%) to 44.024% when pulling a61017ae4e9debd41913c4c63d18a66db4a2f66a on hzxuzhonghu:example into 8033c1f8de80ba4f9aa7636d216f907528103eca on kubernetes:master.

/lgtm

@hzxuzhonghu thanks!

@hzxuzhonghu I had to revert this PR because it brakes with several panics

@aledbf I will check it

I know why panic. I will fix it as soon as possible

authors: aledbf coveralls hzxuzhonghu k8s-reviewable

repo: kubernetes/ingress


text:
cmd.Flags().Set() accepts invalid configurations in create_service_test.go

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Bug report

Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.0.644+2ddde09a6ca650-dirty", GitCommit:"2ddde09a6ca6504f200572b44282dc9983641618", GitTreeState:"dirty", BuildDate:"2017-06-16T20:43:23Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"d6f433224538d4f9ca2f7ae19b252e6fcb66a3ae", GitTreeState:"clean", BuildDate:"2017-05-30T22:03:41Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"}
Environment:

Cloud provider or hardware configuration:  MacBook Pro mid 2015
OS (e.g. from /etc/os-release): OS X 10.11.6 (15G1510)
Kernel (e.g. uname -a): 15.6.0 Darwin Kernel Version 15.6.0

What happened:
cmd.Flags().Set() accepts invalid configurations in pkg/kubectl/cmd/create_service_test.go, e.g. cmd.Flags().Set("tcp", "8080:X")
What you expected to happen:
Invalid configs should fail in tests
How to reproduce it (as minimally and precisely as possible):
Change cmd.Flags().Set("tcp", "8080:8080") to cmd.Flags().Set("tcp", "8080:X") in pkg/kubectl/cmd/create_service_test.go and run go test

@sandoracs Interested in filing a PR to fix?

Sure, why not! I'll take a look at it.

I was wrong, the second port (targetPort) can be a string. Therefore, cmd.Flags().Set("tcp", "8080:X") is valid. However, I've found other issues (int32 allowed as port) but I could fixed them.

authors: pwittrock sandoracs

repo: kubernetes/kubectl


text:
[feature request] Netlify bot should link to pages changed.

It's great to have @k8sio-netlify-preview-bot leave the preview URL for the staged website as comment: https://github.com/kubernetes/kubernetes.github.io/pull/4655#issuecomment-320484631
It would be much more useful if this actually figured out which pages has changed (it's not difficult to find out the files updated via a few git commands) and link to a list of URLs that's updated.
Can we request this feature from Netlify? (I am assuming k8sio-netlify-preview-bot is something Netlify develops. If not, it might be too much work for us.)

cc: @chenopis

@ahmetb Yes, I agree that this would be ideal. I'll ask Netlify. However, what about the cases when the PR modifies several dozen files, like the ones generated by the auto-generated docs updates?

Simplest fix I can think of is if its >10, just drop.
More difficult fix I can think of is, use the following struct:

click here to expand

hello
world

code for this:

click here to expand

hello

world

I am also looking into this. Is there anybody from https://github.com/orgs/netlify/people here?
I suppose one more problem is forward mapping from source .md to target .html page.

I think that needs to be handled via URL rewrites or redirects separate from preview. Right now, we are using a less than ideal client side Javascript solution to redirect anything.md to anything/.

I think transformation engine should give out build graph for tracing ouputs from sources.

cc @calavera

Hey sorry for the late reply.
This is a feature we're considering implementing, but there are a few reasons why we haven't done it yet.
Knowns:

Netlify knows which files and pages are changed for each deploy.
Netlify knows which files are html and which are not.

Unknowns:

Netlify doesn't know if a file deployed has side effects for any page. For example, if you deploy a change in a CSS file, we don't know which files it affects, it could affect a single page or the whole site.

We could send a list of "known" updated pages, as @ahmetb points out, GitHub allows you to use the details tag for expand/collapse comments.
We would not be able to send any information about "unknown" updated pages, like the case of updating CSS, JS, images and so on.
I also know that GitHub is working on more extension points for PR workflows that might report a lot of information in comments, like in this case, but I don't have much more information besides that.
All in all, this is something we'll do at some point, but unfortunately, we don't have a timeline for it yet.

Knowns:
Netlify knows which files and pages are changed for each deploy.
Netlify knows which files are html and which are not.

@calavera I think these are good enough for us. We mostly don't have patches modifying 10+ files, and would love to have a best-effort bot just posting about which HTMLs are changed.

Links to HTMLs pages changed sorted by distance from the patch filename and content.

Given that we have no control over Netlify's development priorities or schedule, I think we should just close this Issue since it's not actionable.

/kind feature

authors: abitrolly ahmetb calavera chenopis sftim