jiebi/CodeConvo huggingface dataset:
Change:
var _ volume.Deleter = &cinderVolumeDeleter{} func (r *cinderVolumeDeleter) GetPath() string { <del> name := cinderVolumePluginName return r.plugin.host.GetPodVolumeDir(r.podUID, kstrings.EscapeQualifiedNameForDisk(name), r.volName) </del> <ins> return getPath(r.podUID, r.volName, r.plugin.host) </ins> } func (r *cinderVolumeDeleter) Delete() error {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: I am trying to get metrics working. According this there should be support after 1.8 kube. However, I am now using kube 1.10.1 and still I cannot see anything in ? Should these be there or not? What you expected to happen: I except that kubelet should expose prometheus metrics to /metrics path as well. Then it is easy to read with prometheus. How to reproduce it (as minimally and precisely as possible): Create new cinder volume, attach it to pod and try to query result from in kubelet Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: openstack OS (e.g. from /etc/os-release): centos 7 Kernel (e.g. ): Install tools: Others:
cc
/sig storage
Prometheus metrics should be available on default port of Kubelet. Can you try ? If you are on a RBAC enabled cluster (such as openshift) you may have to use token or key to authenticate for fetching metrics.
returns many metrics but there is not things. There is one pod which have cinder volume attached running in that node. So there should be some metrics right?
It appears that Cinder volume plugin does not implement metric interface necessary for getting those stat metrics - This seems like an oversight and is fairly easy to fix. I can help getting the PR merged if you can open it.
/sig openstack
Kubernetes v1.19.16 there is no kubelet_volume* metrics in //metrics how to fix it???
Change:
* SSLv3, TLS alert, Client hello (1): ``` <del> This shows that the request to `https://104.197.5.247/api/v1beta3/redirect/namespaces/default/services/elasticsearch-logging` is redirected to `http://10.244.2.7:9200`. If we examine the pods on the cluster we can see that `http://10.244.2.7` is the address of a pod that is running the Elasticsearch service. </del> <ins> We can also run the `kubectl get pods` command to view a list of the pods on the cluster and verify that `http://10.244.2.7` is where the Elasticsearch service is running: </ins> ``` $ kubectl get pods POD                                          IP                  CONTAINER(S)            IMAGE(S)                            HOST                                                                  LABELS                                                                      STATUS              CREATED

Discussion:
is out of date. Please update for the current location/contents of the file and v1beta3. Once is submitted we should also update the examples to show to to curl using bearer tokens instead of basic auth credentials.
We're working on scrubbing the docs and examples of references to v1beta1 () prior to deleting that API, so it would be good to have this in soon.
: let me know if you want to punt this back to me -- now that I have some clue again about how to access an cluster (assuming I can create a cluster!).
Punting back to you. Getting the auth credentials is accomplished via But I think you have a better idea how to curl with token auth than I do.
Change:
verbs:     "get,watch,list", resources: "replicasets.extensions/scale", expectedRole: &rbac.Role{ <ins> TypeMeta: v1.TypeMeta{APIVersion: "rbac.authorization.k8s.io/v1", Kind: "Role"}, </ins> ObjectMeta: v1.ObjectMeta{ Name: roleName, },

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Upgraded Kubectl to version 1.10.0 and now the flag on the creation of a docker-registry secret doesn't print out resulting in the following error: What you expected to happen: I expect the output to have a attribute in the YAML output. How to reproduce it (as minimally and precisely as possible): Here is an example you can run in bash of this not working: The output is: My exact shell code I'm running on the CI server is this Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: 3 on AWS managed with KOPS OS (e.g. from /etc/os-release): Alpine Linux on my CI server, MacOS on my main machine Kernel (e.g. ): Darwin Kernel Version 17.4.0
/sig CLI
cc
/status approved-for-milestone
/assign
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
fyi
The issue appears to be with the command, not with : Will look into this
fix is in
No, the output of is missing kind/apiVersion.
thanks, just saw the PR
Change:
return resourceSeries } <del> // Code for getting container name of docker, copied from pkg/kubelet/cm/container_manager_linux.go // since they are not exposed const ( kubeletProcessName    = "kubelet" dockerProcessName     = "docker" dockerPidFile         = "/var/run/docker.pid" containerdProcessName = "docker-containerd" containerdPidFile     = "/run/docker/libcontainerd/docker-containerd.pid" ) </del> <ins> const kubeletProcessName = "kubelet" </ins> func getPidsForProcess(name, pidFile string) ([]int, error) { if len(pidFile) > 0 {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Now, benchmark test make docker as the only runtime. What you expected to happen: benchmark test should be generic to all CRI container runtimes Related to How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area test /area node-e2e
/sig node
Change:
p.SuggestedCmdUsage = fmt.Sprintf("Use '%s describe pod/%s' to see all of the containers in this pod.", p.FullCmdName, p.PodName) } <del> namespace, _, err := f.DefaultNamespace() if err != nil { return err } p.Namespace = namespace </del> config, err := f.ClientConfig() if err != nil { return err

Discussion:
I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.
Change:
package credentialprovider import ( <ins> "encoding/base64" </ins> "encoding/json" "io/ioutil" "os"

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: docker now provides a new favorite way to store the credentials with the variable credsStore in the file it it is set to desktop, which will be using the executable docker-credential-desktop whose source code is docker-credential-desktop doesn't pad the auth field. So, if we use the command k8s credential provider won't be able to decode the field because of the error Failed to pull image "myrepo/myimage:tag": illegal base64 data at input byte What you expected to happen: Image pulled normally How to reproduce it (as minimally and precisely as possible): open docker config file, and have credsStore set to desktop. Run docker login and then use the to create a k8s dockerconfigjson secret, the error will directly show Anything else we need to know?: I wrote a patch that I will submit Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-19T12:38:36Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64" Cloud provider or hardware configuration: minikube version: v1.3.1 commit: OS (e.g: ): Mac Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig Apps
/remove-sig apps /sig auth /sig node cc to triage
Change:
# If using a network plugin, extend the docker configuration to always remove # the network checkpoint to avoid corrupt checkpoints. # (https://github.com/docker/docker/issues/18283). <del> echo "Extend the default docker.service configuration" </del> <ins> echo "Extend the docker.service configuration to remove the network checkpiont" </ins> mkdir -p /etc/systemd/system/docker.service.d cat <<EOF >/etc/systemd/system/docker.service.d/01network.conf [Service] ExecStartPre=/bin/sh -x -c "rm -rf /var/lib/docker/network" EOF <ins> fi </ins> <del> systemctl daemon-reload </del> <ins> # Ensure TasksMax is sufficient for docker. # (https://github.com/kubernetes/kubernetes/issues/51977) echo "Extend the docker.service configuration to set a higher pids limit" mkdir -p /etc/systemd/system/docker.service.d cat <<EOF >/etc/systemd/system/docker.service.d/02tasksmax.conf [Service] TasksMax=infinity EOF </ins> <del> # If using a network plugin, we need to explicitly restart docker daemon, because # kubelet will not do it. </del> <ins> systemctl daemon-reload </ins> echo "Docker command line is updated. Restart docker to pick it up" systemctl restart docker <del> fi </del> } # This function assembles the kubelet systemd service file and starts it

Discussion:
Forked from Since m60, COS set 4000 pids limit for docker.service. However, currently all containerd-shims are also inside the cgroup, and they are per-container. Each containerd-shim has more than 10 threads based on the node size: It's not hard to hit the limit, say 100 3-container pods may hit the limit. We may want to: 1) Either patch kubernetes to change the limit to higher value; 2) Or patch COS directly, since this may be a regression for other COS user, too. /cc
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
cc/ I guess this is the cause for some docker failures you observed.
Change:
"--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt", "--proxy-server-host=__APISERVER_IP__", "--proxy-server-port=8132", <ins> "--sync-interval=5s", "--sync-interval-cap=30s", "--probe-interval=5s", </ins> "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token" ] env:

Discussion:
After the gce-master-scale-performance started failing with errors like: https://k8s- In a sample run I see a lot of errors like: in konnectivity-server logs: Looks like we have to increase QPS limit for konnectivity-server, do we have a flag (kube-env?) for that? /cc /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cloud-provider
/priority critical-urgent
We may need to re-open this, if there are still uncovered problems (or if we need to re-tune) after watching next test runs.
Wow, thanks a lot for such a rapid fix. Much appreciated!
Change:
// including settings for: // // - Networking, that holds configuration for the networking topology of the cluster; use it e.g. to customize <del> // node subnet or services subnet. </del> <ins> // pod subnet or services subnet. </ins> // // - Etcd configurations; use it e.g. to customize the local etcd or to configure the API server // for using an external etcd cluster.

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --I was reading the doc about NodeRegistration, with an interest in specifying some . I noticed that the doc (e.g., ) does not tell me exactly how to identify each arg: exactly as on the command line (including leading dash(es)), as on the command line but without leading dash(es), or camelCase. I expected the doc to enable me to write some with confidence. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle
FWIW the answer is flag names as on the command name but without any leading dashes. This also applies to controllerManager.extraArgs, scheduler.extraArgs, etc. which hopefully should all cover this similarly (if not now, after fixing ...)

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --I was reading about how to use kubeadm and noticed a typo in the API documentation. speaks of the "node subnet" where I think "pod subnet" is intended. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle
/area kubeadm
Change:
}, VirtualServer{}, true, <del> fmt.Sprintf("IPVS Service Flags should be >= %d, got 0x1", FlagHashed), </del> <ins> fmt.Sprintf("IPVS Service Flags should include %x, got 0x1", FlagHashed), </ins> }, { libipvs.Service{

Discussion:
The current support of the load distribution method and in kube-proxy ipvs mode only performs hashing of source IP address to select endpoints. As a result, all connections from a single client (i.e. from a particular source IP) are always forwarded to only one endpoint matching with the hash value of this source IP. If the client opens a vast majority of connections to the k8s cluster, it will result in traffic imbalance as only one endpoint located on one node handles the connections while the remaining endpoints/nodes are idle. Here is an example of the problem when using method for kube-proxy Deploy a service with 4 endpoints located on 4 nodes.Open 200 connections from a client to node IP of any node (e.g. telnet 192.168.1.1 ). All connections receive replies from only one single endpoint.The distribution printout also shows that all connections are forwarded to the endpoint (e.g. 1.0.4.2:5001 in this example)Similar issue is seen with method Connections from a client should be evenly distributed to all endpoints like to avoid unbalanced load distribution between cluster nodes and endpoints. This can be easily done by enabling the source port hash flag that IPVS supports for the methods which performs hashing on both source IP and source port when selecting the target endpoint.
/sig network /area kube-proxy /area ipvs
This issue was raised based on the discussion of the issue
triage/accepted /assign
/triage/accepted
/triage accepted (damn it!)
Change:
assert.Contains(t, x.output, "test-error Run") assert.EqualError(t, x.err, "Server returning error") } <ins> func TestCobraCommandHelp(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command --help") assert.NoError(t, x.err) assert.Contains(t, x.output, "A server named test-cobra-command which uses a cobra command") assert.Contains(t, x.output, cobraMessageDesc) } func TestCobraCommandDefaultMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command") assert.Contains(t, x.output, fmt.Sprintf("msg: %s", defaultCobraMessage)) } func TestCobraCommandMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command --msg foobar") assert.Contains(t, x.output, "msg: foobar") } func TestCobraSubCommandHelp(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand --help") assert.NoError(t, x.err) assert.Contains(t, x.output, cobraSubMessageDesc) } func TestCobraSubCommandDefaultMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand") assert.Contains(t, x.output, fmt.Sprintf("submsg: %s", defaultCobraSubMessage)) } func TestCobraSubCommandMessage(t *testing.T) { x := runFull(t, "hyperkube test-cobra-command subcommand --submsg foobar") assert.Contains(t, x.output, "submsg: foobar") } </ins>

Discussion:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .
Change:
// If we have more than the maximum, sort the update entries by time, oldest first. sort.Slice(updaters, func(i, j int) bool { <del> iTime, jTime, nTime := managed.Times()[updaters[i]], managed.Times()[updaters[j]], &metav1.Time{Time: time.Time{}} if iTime == nil { iTime = nTime </del> <ins> iTime, jTime, iSeconds, jSeconds := managed.Times()[updaters[i]], managed.Times()[updaters[j]], int64(0), int64(0) if iTime != nil { iSeconds = iTime.Unix() </ins> } <del> if jTime == nil { jTime = nTime </del> <ins> if jTime != nil { jSeconds = jTime.Unix() </ins> } <del> if !iTime.Equal(jTime) { return iTime.Before(jTime) </del> <ins> if iSeconds != jSeconds { return iSeconds < jSeconds </ins> } return updaters[i] < updaters[j] })

Discussion:
What happened: On a resource with managedFields populated, a no-op patch modified the serialization order of managedFields. What you expected to happen: No-op patches do not result in a write to etcd. How to reproduce it (as minimally and precisely as possible): contains: the initial ADDED event from kubectl MODIFIED events from kube-controller-manager one MODIFIED event corresponding to the kubectl patch (from resourceVersion 1704 in 1.txt to resourceVersion 1718 in 2.txt) shows the kubectl and kube-controller-manager managed field sets swapped order: second patch was a no-op ( is empty) Anything else we need to know?: This was easiest to reproduce with server-side apply enabled at 100% /assign
/sig api-machinery
/wg apply
Can you print the before/after fieldmanager? I can't quite figure out what the actual values are. The code that sorts these lists is located
updated to unified diff and attached:
If you explicitly set the field manager to something unique, does it happen every time?
hm, no, it's definitely an ordering swap
is not sorted properly, since should come before .
We seem to also sort it in a second place:
Theory: the first time it goes through, the time is accurate to the nanosecond; the second time, it's accurate to the second
Yeah OK I'm pretty sure that's it, both times are the same second. Serialization drops the fractional part.