jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/watch" <ins> "k8s.io/apiserver/pkg/authentication/group" </ins> "k8s.io/apiserver/pkg/authentication/request/bearertoken" "k8s.io/apiserver/pkg/authentication/token/tokenfile" "k8s.io/apiserver/pkg/authentication/user"

Discussion:
While moving APF to beta (see comments on ), we discovered that the integration tests commonly present users which are not members of any groups. We had thought that the system enforced membership in either the authenticated or unauthenticated group. If this is supposed to be a system invariant (as we thought), we'd like to ask SIG Auth: Please fix the integration tests Please add e.g. logging so that if real, operational clusters hit this there's at least a log message and people will file bugs. /sig auth
Can I suggest also, if this is a real invariant, that it be documented in some place(s) likely to be read?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /priority important-longterm /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen
fixes the authenticator configured in one of the integration test API server startup helpers which resolved this issue for . Remaining tests that still need fixing that are encountering unexpected users look to be ones set up to specifically test auth paths:
open to fix remaining integration test users
Change:
prometheus.NewGoCollector(), prometheus.NewProcessCollector(os.Getpid(), ""), ) <del> mux.Handle(prometheusEndpoint, promhttp.HandlerFor(r, promhttp.HandlerOpts{})) </del> <ins> mux.Handle(prometheusEndpoint, promhttp.HandlerFor(r, promhttp.HandlerOpts{ErrorHandling: promhttp.ContinueOnError})) </ins> } func staticHandlerNoAuth(w http.ResponseWriter, r *http.Request) {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug report Kubernetes version (use ): Environment: Cloud provider or hardware configuration: vsphere OS (e.g. from /etc/os-release):Kernel (e.g. ): 4.9.24-coreos Install tools: Others: What happened: After bringing a cluster up, there are no container metrics in the kubelet at /metrics What you expected to happen: I expect to see the metrics, but there are none How to reproduce it (as minimally and precisely as possible): Anything else we need to know: If I try and access the metrics in cAdvisor directly on port 4194 instead of on port then I see the following type of error for all of the metrics:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig node
This appears to be a v1.7 issue. If I run 1.6.6 I get these metrics. Seems like something has happened in 1.7. I'm running the 1.7 beta because I need nodePort for cni, so now I'm stuck.
Can you triage the issue since?
cc/
Can you help verifying is this is a new regression introduced in 1.7 cadvisor through node-e2e? Thanks!
I've tried this on both cos and cvm in 1.7 cluster, and no container metrics show up. However, I created a 1.6.4 GKE cluster, and container metrics are there. This is a regression in 1.7. Will figure out what is wrong here.
Here is a corresponding cadvisor issue
Even the user still can get the container metrics / stats from kubelet /summary api (recommended way), but since this is a regression introduced in 1.7 release, and we aren't dropping prometheus support, let's fix this for 1.7. Thanks!
Fixed in Will close this issue after building new cadvisor release and cherrypick into 1.7
Thanks for the quick find everyone! I'll be happy to give this a go on the next release!

I'm still facing this same issue. My kubernetes cluster is deployed with kubeadm on Centos 7. I run a k8S v1.8.1 cluster. When I try to fetch containers metrics this way: http://localhost:8001/api/v1/proxy/nodes/node1:0/metrics http://localhost:8001/api/v1/proxy/nodes/node1:/metrics http://localhost:8001/api/v1/proxy/nodes/node1:/metrics I find no metrics. kubelet is started with . If I start kubelet with . metrics are available through .
Change:
return m.configuration.Load().([]webhook.WebhookAccessor) } <ins> // HasSynced returns true when the manager is synced with existing webhookconfig // objects at startup-- which means the informer is synced and either has no items // or updateConfiguration() has completed. </ins> func (m *mutatingWebhookConfigurationManager) HasSynced() bool { <del> return m.hasSynced() </del> <ins> if !m.hasSynced() { return false } if m.initialConfigurationSynced.Load().(bool) { // the informer has synced and configuration has been updated return true } if configurations, err := m.lister.List(labels.Everything()); err == nil && len(configurations) == 0 { // the empty list we initially stored is valid to use. // Setting initialConfigurationSynced to true, so subsequent checks // would be able to take the fast path on the atomic boolean in a // cluster without any admission webhooks configured. m.initialConfigurationSynced.Store(true) // the informer has synced and we don't have any items return true } return false </ins> } func (m *mutatingWebhookConfigurationManager) updateConfiguration() {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: Instructions 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
Change:
}{ { mode: kubeproxyconfig.ProxyMode("non-existing"), <del> msg:  "or blank (blank means the best-available proxy (currently iptables)", </del> <ins> msg:  "or blank (blank means the", </ins> }, } for _, errorCase := range errorCases { if errs := validateProxyMode(errorCase.mode, newPath.Child("ProxyMode")); len(errs) == 0 { <del> t.Errorf("expected failure for %s", errorCase.msg) </del> <ins> t.Errorf("expected failure %s for %v", errorCase.msg, errorCase.mode) </ins> } else if !strings.Contains(errs[0].Error(), errorCase.msg) { t.Errorf("unexpected error: %v, expected: %s", errs[0], errorCase.msg) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When running , and passing the flag which was introduced in , the following error occurs: What you expected to happen: The proxy should work as it used to, supporting this mode. How to reproduce it (as minimally and precisely as possible): ./kube- --proxy-mode=kernelspace Anything else we need to know?: This was introduced after the validation was refactored in which regressed validation for . IPVS validation (and thus support) was later , but we need another mode for Windows. Environment: Kubernetes version (use ): v1.10.0-alpha.0.684+ Cloud provider or hardware configuration: n/a OS (e.g. from ): Windows Server Core 1709 Kernel (e.g. ): Install tools: Others:
/sig windows /sig network
Tentatively adding milestone so we can track getting consensus on release-blocking status.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <details<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
Change:
start program = "/etc/init.d/docker start" stop program = "/etc/init.d/docker stop" if does not exist then restart <ins> if failed unixsocket /var/run/docker.sock protocol HTTP request "/version" then restart </ins>

Discussion:
During our Jenkins run, a cluster failed to initialize with a pattern like so: I logged into the second node to see what was going on, and found the kubelet logs seemed to be repeating themselves every couple of minutes: Checking monit, yup: Jenkins is currently disabled to allow live debugging of the issue. Raising to P0 until we get Jenkins back. cc
I can login to the node and working on it now.
Here is what happened: Docker daemon is hung during startup phase: But nono docker CLI calls return, including 'docker version'. Monit now does healthcheck on kubelet, which in turns to query docker version, which never response and timeout, and cause a kubelet restart. Looking into why docker daemon hang forever.
Ok, that docker daemon on a terrible state, and all docker API requests hang. This is known issue from docker since I personally reported twice. The current active one is docker/docker/issues/9605. 1) I tried to strace docker process for about 20 seconds, and nothing is interesting except one thread stucking at read syscall forever: 2) I sent SIGQUIT to docker daemon. Docker is shutdown, and restart by monit. From below log, one can notice that there is a huge gap between time="2015-03-11T17:58:25Z" and time="2015-03-11T21:06:06Z" 3) Monit now restart docker daemon: Assuming there are always docker API request hang issues, we should detect such issue, and restart docker like what I did for kubelet. Meanwhile, we shouldn't fail kubelet's healthcheck when docker API hang.
This is part of
Thanks for the quick fix!
Change:
sudo docker ps ``` <del> And see the actual task.  (note that initial ```docker pull``` may take a few minutes, depending on network conditions. </del> <ins> And see the actual task.  (Note that initial ```docker pull``` may take a few minutes, depending on network conditions.) </ins> ### Step Two: Turn up the master service. A Kubernetes 'service' is named load balancer that proxies traffic to one or more containers.  The services in a Kubernetes cluster are discoverable inside other containers via environment variables.  Services find the containers to load balance based on task labels.  The task that you created in Step One has the label "name=redis-master", so the corresponding service is defined by that label.  Create a file named redis-master-service.json that contains:

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: The image () used to run the per-pod infra/pause container logs to stdout about once per second. What you expected to happen: Pause container not logging anything. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet does not expose, nor manage these logs. Writing the logs wastes resources and takes up disk space, which may not be properly accounted by kubelet. The pause image used for the e2e tests seems much better: Environment: 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:
/assign Will also rebuild with
Change:
} } <del> // This is the spec for the volume that this plugin wraps. var wrappedVolumeSpec = volume.Spec{ // This should be on a tmpfs instead of the local disk; the problem is // charging the memory for the tmpfs to the right cgroup.  We should make // this a tmpfs when we can do the accounting correctly. Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{}}}, </del> <ins> func wrappedVolumeSpec() volume.Spec { // This is the spec for the volume that this plugin wraps. return volume.Spec{ // This should be on a tmpfs instead of the local disk; the problem is // charging the memory for the tmpfs to the right cgroup.  We should make // this a tmpfs when we can do the accounting correctly. Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{}}}, } </ins> } func (b *configMapVolumeMounter) SetUp(fsGroup *int64) error {

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: Instructions 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
set -o errexit set -o nounset <del> set -o pipefailscript_dir=$(cd $(dirname "${BASH_SOURCE}") && pwd -P) </del> <ins> set -o pipefail script_dir=$(cd $(dirname "${BASH_SOURCE}") && pwd -P) </ins> cd "${script_dir}"

Discussion:
after was merged It seems to be related to the machine type. /cc /sig scalability k8s-infra
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
/cc
I'll fix this now
Change:
} } <ins> func TestWatchCacheBypass(t *testing.T) { backingStorage := &dummyStorage{} cacher, _, err := newTestCacher(backingStorage) if err != nil { t.Fatalf("Couldn't create cacher: %v", err) } defer cacher.Stop() // Wait until cacher is initialized. if err := cacher.ready.wait(); err != nil { t.Fatalf("unexpected error waiting for the cache to be ready") } // Inject error to underlying layer and check if cacher is not bypassed. backingStorage.injectError(errDummy) _, err = cacher.Watch(context.TODO(), "pod/ns", storage.ListOptions{ ResourceVersion: "0", }) if err != nil { t.Errorf("Watch with RV=0 should be served from cache: %v", err) } // With unset RV, check if cacher is bypassed. _, err = cacher.Watch(context.TODO(), "pod/ns", storage.ListOptions{ ResourceVersion: "", }) if err != errDummy { t.Errorf("Watch with unset RV should bypass cacher: %v", err) } } </ins> func TestWatcherNotGoingBackInTime(t *testing.T) { backingStorage := &dummyStorage{} cacher, _, err := newTestCacher(backingStorage)

Discussion:
As Jordan pointed out in: watchcache treats RV=0 and RV="" the same way, even though it's not what we document: This should be fixed. /kind bug /sig api-machinery /priority important-soon
/assign
/triage accepted
Change:
podStatus.Host = kl.GetHostname() hostIP, err := kl.GetHostIP() if err != nil { <del> return api.PodStatus{}, fmt.Errorf("Cannot get host IP: %v", err) </del> <ins> glog.Errorf("Cannot get host IP: %v", err) } else { podStatus.HostIP = hostIP.String() </ins> } <del> podStatus.HostIP = hostIP.String() </del> return *podStatus, nil }

Discussion:
I suspected this is a regression introduced by . I observed a pod was restarted and stuck at PENDING phase for a long time (Don't know the reason why it is restarted at the first place, but that is a separate issue) ssh to the machine, I found both containers are running happily on the machine: Checked kubelet's log, I found kubelet bailed out on generating PodStatus because the failure of retrieving HostIP: I didn't look into with more detail yet. If no one pick up this tonight, I will take a look tomorrow morning.
cc
That' interesting. kubelet bug comes from GetHostIP() function. It reads cached Node and parse it's addresses. Apparently Nodes does not have any addresses reported in status field. Is that expected? Pod_cache just ignored missing HostIP, so I'll send a PR to have a similar logic in kubelet.
I sync-ed, but still observed the same issue: Here is the error from
The issue here is that NodeStatus.Address is empty. I am closing this one, and filing a separate one for cloud provider.
I'm seeing this problem with v0.15.0. What is the new tracking issue?
at the end I didn't file a separate issue because I couldn't reproduce the issue later. Feel free to file a new issue with detail please.
I'm also seeing this, but don't have a repro case yet unfortunately. what did you mean when you said you sync-ed?
- where are you running your cluster, and how did you create it?
I’m running the Master related process in one Docker container and the Node related process in another Docker container. All the Nodes are connected using OpenVSwitch GRE tunnels. The Nodes register with the Master using this script
I am receiving this same error running master and node on separate coreos images with vagrant on parallels. I am able to register the node, but then health check fails and results in this error.
Change:
} } <ins> if filterTags[TagNameKubernetesCluster] == "" { glog.Errorf("Tag %q not found; Kuberentes may behave unexpectedly.", TagNameKubernetesCluster) } </ins> awsCloud.filterTags = filterTags if len(filterTags) > 0 { glog.Infof("AWS cloud filtering on tags: %v", filterTags)

Discussion:
If there are two security groups on an instance, we currently make an arbitrary choice. We should choose based on tags, as we normally do. For back-compat, we need to cope if there is one security group and it is not tagged. We should make sure kube-up tags our security groups, though it isn't really required for kube-up, but it is just good behaviour. cf
Change:
// Install func registers the logs handler. func (l Logs) Install(c *restful.Container) { // use restful: ws.Route(ws.GET("/logs/{logpath:*}").To(fileHandler)) <del> // See github.com/emicklei/go-restful/blob/master/examples/restful-serve-static.go </del> <ins> // See github.com/emicklei/go-restful/blob/master/examples/static/restful-serve-static.go </ins> ws := new(restful.WebService) ws.Path("/logs") ws.Doc("get log files")

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : // See right address of restful-serve- in the comment of Why is this needed: the address of restful-serve- in the comment of is wrong now
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
/assign
/sig Docs
/kind cleanup /remove-kind feature
Change:
fi append_or_replace_prefixed_line "${basic_auth_csv}" "${KUBE_PASSWORD},${KUBE_USER},"      "admin,system:masters" fi local -r known_tokens_csv="${auth_dir}/known_tokens.csv" <ins> if [[ -e "${known_tokens_csv}" && "${METADATA_CLOBBERS_CONFIG:-false}" == "true" ]]; then rm "${known_tokens_csv}" fi </ins> if [[ -n "${KUBE_BEARER_TOKEN:-}" ]]; then append_or_replace_prefixed_line "${known_tokens_csv}" "${KUBE_BEARER_TOKEN},"             "admin,admin,system:masters" fi

Discussion:
/sig cluster-lifecycle
Very rarely we are seeing known tokens files filled with the NULL character, with ASCII value 000. Restarting the master doesn't fix the issue because the is saved between restarts.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
// jitter factor for resyncInterval workerResyncIntervalJitterFactor = 0.5 <del> // jitter factor for backOffPeriod </del> <ins> // jitter factor for backOffPeriod and backOffOnTransientErrorPeriod </ins> workerBackOffPeriodJitterFactor = 0.5 <ins> // backoff period when transient error occurred. backOffOnTransientErrorPeriod = time.Second </ins> ) type podWorkers struct {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods are synchronized by kubelet before network is ready. Synchronization in such case fails and pod is synchronized after 10 seconds. What you expected to happen: Kubelet should wait until network is ready before starting synchronizing pods. How to reproduce it (as minimally and precisely as possible): Configure cluster with Cluster Autoscaler enabled. Start pod so cluster is scaled up. In logs you might find following error: E0907 13:18:49. 972 ] Error syncing pod xxxxxx ("xxxxxxxxx(xxxxxxxxxxx)"), skipping: network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: Kubenet does not have netConfig. This is most likely due to lack of PodCIDR] Environment: Build from HEAD Cloud provider or hardware configuration: GKE
/kind bug /sig node