jiebi/CodeConvo huggingface dataset:
Change:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug /sig azure What happened: When performing a rolling update of my nodes (i.e., cordon, drain, delete VM on Azure side) one after the other the corresponding objects of the deleted VMs are not being deleted from etcd. This affects all patch versions while it is working fine with . What you expected to happen: The objects are removed from etcd when the backing virtual machine does not exist any more. How to reproduce it (as minimally and precisely as possible): Create a Kubernetes cluster with version on Azure, cordon and drain the node and delete the backing VM afterwards. Anything else we need to know?: No. Environment: Kubernetes version (use ): 1.9.X Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): CoreOS Stable 1632.3.0 Others: machine type
It requires some time for controller manager to detect the removed VM on Azure. Could you share the logs of kube-controller-manager?
Hi thank's for taking a a look. Well, sure, it may take some time, however, it's really fast for Kubernetes clusters on Azure with versions prior than and also for clusters on other cloud providers (even with ). I have waited more than 30 minutes, but the "old" objects are still there (which leads to a weird state/view on pods, etc.). I've seen this problem only with Azure . I just reproduced the problem: At this point in time the backing VMs for and are already gone/do not exist any more. The relevant logs of the kube-controller-manager:
Thanks of providing the information. I'm checking whether there is something wrong inside cloud provider
confirmed it's a bug in azure cloud provider
Thank you for investigating. Do you already know whether the fix will be backported or only part of 1.10?
By the way, have you configured backoff with azure cloud provider? what params have you configured?
This is the relevant part of the current cloud provider configuration: Does it look good to you?
There is a problem in backoff logic which results in retrying even the VM has already removed from Azure. With the params you set, the backoff timeout will be about 40 hours. I recommend setting a smaller cloudProviderBackoffDuration (ensure 1) since this is an exponential backoff.
Okay, thank's a lot!

Discussion:
"k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/wait" <ins> "k8s.io/kubernetes/pkg/cloudprovider" </ins> ) // requestBackoff if backoff is disabled in cloud provider it

var retryErr error err := wait.ExponentialBackoff(az.requestBackoff(), func() (bool, error) { machine, retryErr = az.getVirtualMachine(name) <ins> if retryErr == cloudprovider.InstanceNotFound { return true, cloudprovider.InstanceNotFound } </ins> if retryErr != nil { glog.Errorf("backoff: failure, will retry,err=%v", retryErr) return false, nil

var err error machine, err = as.getVirtualMachine(types.NodeName(name)) <ins> if err == cloudprovider.InstanceNotFound { return "", cloudprovider.InstanceNotFound } </ins> if err != nil { if as.CloudProviderBackoff { glog.V(2).Infof("InstanceID(%s) backing off", name)
Change:
https://k8s- /kind bug /sig cluster-lifecycle /milestone v1.10 /priority failing-test cc also cc should this even be in 1.10 blocking dashboard?
/priority critical-urgent (who owns this?)
(also https://k8s-)
Is this actually running now? /cc
It looks like it's failing to up the cluster, I don't remember what the previous status of this job was, I thought all kubeadm 1.10 jobs were running previously...
The reason this failed was the cross CI job was failing to push the images that are used by that job. /cc
/subscribe
the latest cross build for 1.9 is as following We seem to have only one job that does cross builds on master : https://k8s-*build&i=nope&files=&repos=test-infra So the job fails ( for example in )
/status approved-for-milestone
[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

Discussion:
switch { case strings.HasPrefix(subs[0][2], "ci"): <del> // Special case. CI images populated only by ci-cross area urlSuffix = "ci-cross" </del> <ins> // Just use whichever the user specified urlSuffix = subs[0][2] </ins> default: urlSuffix = "release" }

{"release/v1.7.0", "https://dl.k8s.io/release", "v1.7.0", true}, {"release/latest-1.7", "https://dl.k8s.io/release", "latest-1.7", true}, // CI builds area, lookup actual builds at ci-cross/*.txt <ins> {"ci/latest", "https://dl.k8s.io/ci", "latest", true}, </ins> {"ci-cross/latest", "https://dl.k8s.io/ci-cross", "latest", true}, <del> {"ci/latest-1.7", "https://dl.k8s.io/ci-cross", "latest-1.7", true}, </del> <ins> {"ci/latest-1.7", "https://dl.k8s.io/ci", "latest-1.7", true}, {"ci-cross/latest-1.7", "https://dl.k8s.io/ci-cross", "latest-1.7", true}, </ins> // unknown label in default (release) area: splitVersion validate only areas. {"unknown-1", "https://dl.k8s.io/release", "unknown-1", true}, // unknown area, not valid input.
Change:
https://k8s- /kind bug /sig testing /milestone v1.10 /priority failing-test cc /assign I'll dig into it and see if I can find any clue
/priority critical-urgent
/status approved-for-milestone the tests were timing out, I'll bump the timeout a bit
[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
(will watch the next runs)
(looks like 2h is not enough, I'll give it a bit more time, and I'll diff the test output)
https://k8s- green run now, took 10h, the previous cluster was somehow bad on beforesuite. I'll close this.

Discussion:
List Kubernetes kubectl get pods <del> kubectl grt minions </del> <ins> kubectl get minions </ins> Kill all pods:
Change:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: GKE tests are failing. They are trying to check that the dashboard is alive, but the dashboard is disabled by default in GKE in Kubernetes 1.10. What you expected to happen: The test should either not run, or start the dashboard. Ideally, it would start the dashboard so we could see that it works, for now we'll just disable the test. How to reproduce it (as minimally and precisely as possible): https://k8s- Anything else we need to know?: Environment: Kubernetes version (use ): 1.10 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: cc
/priority critical-urgent That's probably not true, but please change it to appropriate.
[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
Is this different from ?
we have enabled the plugin from all the blocking jobs so it's not a blocker, but in the long run this need to be in it's own feature.

Discussion:
) var _ = SIGDescribe("Kubernetes Dashboard", func() { <ins> BeforeEach(func() { // TODO(kubernetes/kubernetes#61559): Enable dashboard here rather than skip the test. framework.SkipIfProviderIs("gke") }) </ins> const ( uiServiceName = "kubernetes-dashboard" uiAppName     = uiServiceName
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: unit tests fail on osx. What you expected to happen: How to reproduce it (as minimally and precisely as possible): To see this unit test fail, you need to run go test on an osx machine. Environment: OS: macOS High Sierra v10.13.3
/sig storage /assign

Discussion:
import ( "fmt" "os" <ins> "runtime" </ins> "strconv" "strings" "testing"

} func Test_ConstructVolumeSpec(t *testing.T) { <ins> if runtime.GOOS == "darwin" { t.Skipf("Test_ConstructVolumeSpec is not supported on GOOS=%s", runtime.GOOS) } </ins> fm := &mount.FakeMounter{ MountPoints: []mount.MountPoint{ {Device: "/dev/sdb", Path: "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod1"},

"os" "path/filepath" "reflect" <ins> "runtime" </ins> "strings" "sync" "testing"

// https://github.com/kubernetes/kubernetes/issues/57744 func TestConstructVolumeSpec(t *testing.T) { <ins> if runtime.GOOS == "darwin" { t.Skipf("TestConstructVolumeSpec is not supported on GOOS=%s", runtime.GOOS) } </ins> tmpDir, err := utiltesting.MkTmpdir("rbd_test") if err != nil { t.Fatalf("error creating temp dir: %v", err)
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We need to update local volume provisioner used in local PV e2e tests for k8s 1.10, by leveraging a new provisioner image (v2.1.0). Environment: Kubernetes version: v1.10
/sig storage /assign
should this block the 1.10 release in your opinion?
No not a blocker

Discussion:
// volumeConfigName is the configmap passed to bootstrapper and provisioner volumeConfigName = "local-volume-config" // provisioner image used for e2e tests <del> provisionerImageName = "quay.io/external_storage/local-volume-provisioner:v2.0.0" </del> <ins> provisionerImageName = "quay.io/external_storage/local-volume-provisioner:v2.1.0" </ins> // provisioner daemonSetName name daemonSetName = "local-volume-provisioner" // provisioner default mount point folder
Change:
Subpath unix socket tests can flake because of long socket path. On Linux the path limit should be 108 chars or less. /sig storage

Discussion:
expectError: false, }, { <del> name: "subpath-mounting-unix-socket", </del> <ins> name: "mount-unix-socket", </ins> prepare: func(base string) ([]string, string, string, error) { volpath, subpathMount := getTestPaths(base) mounts := []string{subpathMount}

return nil, "", "", err } <del> testSocketFile := filepath.Join(volpath, "mount_test.sock") _, err := net.Listen("unix", testSocketFile) return mounts, volpath, testSocketFile, err </del> <ins> socketFile, socketCreateError := createSocketFile(volpath) return mounts, volpath, socketFile, socketCreateError </ins> }, expectError: false, },

if err != nil { t.Fatalf(err.Error()) } mounts, volPath, subPath, err := test.prepare(base) if err != nil { os.RemoveAll(base)

true, }, { <del> "mounting-unix-socket", </del> <ins> "mount-unix-socket", </ins> func(base string) error { <del> testSocketFile := filepath.Join(base, "mount_test.sock") _, err := net.Listen("unix", testSocketFile) if err != nil { return fmt.Errorf("Error preparing socket file %s with %v", testSocketFile, err) </del> <ins> socketFile, socketError := createSocketFile(base) if socketError != nil { return fmt.Errorf("Error preparing socket file %s with %v", socketFile, socketError) </ins> } return nil }, <del> "mount_test.sock", </del> <ins> "mt.sock", </ins> false, }, { "mounting-unix-socket-in-middle", func(base string) error { <del> testSocketFile := filepath.Join(base, "mount_test.sock") _, err := net.Listen("unix", testSocketFile) if err != nil { return fmt.Errorf("Error preparing socket file %s with %v", testSocketFile, err) </del> <ins> testSocketFile, socketError := createSocketFile(base) if socketError != nil { return fmt.Errorf("Error preparing socket file %s with %v", testSocketFile, socketError) </ins> } return nil }, <del> "mount_test.sock/bar", </del> <ins> "mt.sock/bar", </ins> true, }, }

if err != nil { t.Fatalf(err.Error()) } test.prepare(base) pathToCreate := filepath.Join(base, test.path) fd, err := doSafeOpen(pathToCreate, base)

} } <ins> func createSocketFile(socketDir string) (string, error) { testSocketFile := filepath.Join(socketDir, "mt.sock") // Switch to volume path and create the socket file // socket file can not have length of more than 108 character // and hence we must use relative path oldDir, _ := os.Getwd() err := os.Chdir(socketDir) if err != nil { return "", err } defer func() { os.Chdir(oldDir) }() _, socketCreateError := net.Listen("unix", "mt.sock") return testSocketFile, socketCreateError } </ins> func TestFindExistingPrefix(t *testing.T) { defaultPerm := os.FileMode(0750) tests := []struct {
Change:
https://k8s- example run from https://k8s- which just edits a md file.
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
timeout is 120s, set 360s can fix this in my local env, not sure what happened.
tracked it down to introduced in
can you take a look at
i tried the posted by a few times and noticed variations of time taken, then removed the last few commits and ran them again and saw they were stable. then all the commits back until they failed which was the last commit. Then i looked inside and noticed the random which has caused pain before (in openstack). Ack looking

Discussion:
set -o pipefail KUBE_ROOT=${KUBE_ROOT:-$(dirname "${BASH_SOURCE}")/..} <del> source "${KUBE_ROOT}/cluster/kube-util.sh" </del> source "${KUBE_ROOT}/cluster/clientbin.sh" # If KUBEADM_PATH isn't set, gather up the list of likely places and use ls
Change:
<!-- 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: namespace disappears in the output of What you expected to happen: namespace exists How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It is related to Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli

Discussion:
# Command kubectl get pods --all-namespaces --namespace=default <ins> ### Check --all-namespaces option shows namespaces # Create objects in multiple namespaces kubectl create "${kube_flags[@]}" namespace all-ns-test-1 kubectl create "${kube_flags[@]}" serviceaccount test -n all-ns-test-1 kubectl create "${kube_flags[@]}" namespace all-ns-test-2 kubectl create "${kube_flags[@]}" serviceaccount test -n all-ns-test-2 # Ensure listing across namespaces displays the namespace output_message=$(kubectl get serviceaccounts --all-namespaces "${kube_flags[@]}") kube::test::if_has_string "${output_message}" "all-ns-test-1" kube::test::if_has_string "${output_message}" "all-ns-test-2" # Clean up kubectl delete "${kube_flags[@]}" namespace all-ns-test-1 kubectl delete "${kube_flags[@]}" namespace all-ns-test-2 </ins> ### Clean up # Pre-condition: valid-pod exists kube::test::get_object_assert pods "{{range.items}}{{$id_field}}:{{end}}" 'valid-pod:'

return nil, err } <ins> for i := range table.Rows { row := &table.Rows[i] if row.Object.Raw == nil || row.Object.Object != nil { //if row already has Object.Object //we don't change it continue } converted, err := runtime.Decode(unstructured.UnstructuredJSONScheme, row.Object.Raw) if err != nil { //if error happens, we just continue continue } row.Object.Object = converted } </ins> return table, nil }
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In my test setup I allocate POD CIDRs manually, bridge is configured before starts. Important settings: on example node: on master: Then I see confusing entries in logs (): Fortunately everything keeps working, thanks to this condition: , i.e. it is not propagated to CNI plugin. It appears that this very line tries to set the CIDR to whatever the master returns during node status update: What you expected to happen: / use the pod CIDR given at command line and never mess with it Actually I'm a bit confused if manual per-node pod CIDR assignment is supported at all, and if I'm doing it correctly. I'm aware it's unusual thing to do in production environment, yet for testing it seems perfectly legitimate. Environment: Kubernetes version (use ): v1.10.0 Cloud provider or hardware configuration: bare metal OS (e.g. from /etc/os-release): Ubuntu 17.10 Kernel (e.g. ): Install tools:
/sig network
Kubelet need to make a check of CIDR before
/assign

Discussion:
func (*RemoveImageResponse) Descriptor() ([]byte, []int) { return fileDescriptorApi, []int{76} } type NetworkConfig struct { <del> // CIDR to use for pod IP addresses. </del> <ins> // CIDR to use for pod IP addresses. If the CIDR is empty, runtimes // should omit it. </ins> PodCidr string `protobuf:"bytes,1,opt,name=pod_cidr,json=podCidr,proto3" json:"pod_cidr,omitempty"` }

message RemoveImageResponse {} message NetworkConfig { <del> // CIDR to use for pod IP addresses. </del> <ins> // CIDR to use for pod IP addresses. If the CIDR is empty, runtimes // should omit it. </ins> string pod_cidr = 1; }

return fmt.Errorf("nil %q node object", kl.nodeName) } <del> kl.updatePodCIDR(node.Spec.PodCIDR) </del> <ins> if node.Spec.PodCIDR != "" { kl.updatePodCIDR(node.Spec.PodCIDR) } </ins> kl.setNodeStatus(node) // Patch the current status on the API server
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Current instruction state that Kubernetes requires 3GB to build in Docker on osx. Attempting to build () with 3GB, 3.5GB, and 4.0GB fail. What you expected to happen: I expect osx users to be able to build Kubernetes, and the instructions to indicate that at least 4.5GB of memory are required. How to reproduce it (as minimally and precisely as possible): On osx setup docker with 3GB memory, and then attempt to build Kubernetes () and it will fail. Anything else we need to know?: Environment: Kubernetes version (use ): upstream/master OS (e.g. from /etc/os-release): osx - 10.13.4
/sig contributor-experience
/sig docs

Discussion:
1. Docker, using one of the following configurations: * **macOS** You can either use Docker for Mac or docker-machine. See installation instructions [here](https://docs.docker.com/docker-for-mac/). <del> **Note**: You will want to set the Docker VM to have at least 3GB of initial memory or building will likely fail. (See: [#11852]( http://issue.k8s.io/11852)). </del> <ins> **Note**: You will want to set the Docker VM to have at least 4.5GB of initial memory or building will likely fail. (See: [#11852]( http://issue.k8s.io/11852)). </ins> * **Linux with local Docker**  Install Docker according to the [instructions](https://docs.docker.com/installation/#installation) for your OS. * **Remote Docker engine** Use a big machine in the cloud to build faster. This is a little trickier so look at the section later on. 2. **Optional** [Google Cloud SDK](https://developers.google.com/cloud/sdk/)
Change:
<!-- 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: Pulled master and ran: $ make test I get test failure for TestDeleteEdges_locked in What you expected to happen: I expected all tests to run successfully How to reproduce it (as minimally and precisely as possible): Run $ make test, using the most recent version of master (head at commit ), observe that test fails. Anything else we need to know?: This is my first issue, so please let me know if I need to provide any other information! Environment: Kubernetes version (use ): upstream/master (head at commit ) OS (e.g. from /etc/os-release): macOs 10.13.3
/sig testing
/assign
/priority failing-test
This looks like a flaky test. I wonder if the ordering is no longer guaranteed stable in go1.10?
nope, typo in the sorting the test did. fix incoming
/assign

Discussion:
return expectNodes[i].ID() < expectNodes[j].ID() }) startNodes := c.start.graph.Nodes() <del> sort.Slice(expectNodes, func(i, j int) bool { </del> <ins> sort.Slice(startNodes, func(i, j int) bool { </ins> return startNodes[i].ID() < startNodes[j].ID() }) assert.Equal(t, expectNodes, startNodes)

return expectEdges[i].From().ID() < expectEdges[j].From().ID() }) startEdges := c.start.graph.Edges() <del> sort.Slice(expectEdges, func(i, j int) bool { </del> <ins> sort.Slice(startEdges, func(i, j int) bool { </ins> if startEdges[i].From().ID() == startEdges[j].From().ID() { return startEdges[i].To().ID() < startEdges[j].To().ID() }
Change:
<!-- 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: When a pod with disk mount PVC is already moved from a node, the PVC is always be in node.volumesInUse, makes StatefulSet pod stuck in ContainerCreating forever. Although I found this issue on Azure, I think it's a common issue. What you expected to happen: How to reproduce it (as minimally and precisely as possible): You could find detailed steps up a k8s cluster with 2 agent nodes(node, node) cordon node up 3 statefulsets (1 replica) with azure disk mount each, and all pods will be scheduled to node uncordon node drain node, and then all 3 pods will be scheduled to node some condition, these all 3 pods will be stuck in ContainerCreating forever I have check status of node, node, the is incorrect in node since all pods have been moved to node, in node should be empty, while all 3 volumes are still in node. Actually there are also ghost volumes in node after I Anything else we need to know?: restart kubelet manually in both node, node would work Environment: Kubernetes version (use ): v1.9.6 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig node
cc
Hi in v1.9.6, we found volume in is not removed even after pod with that volume has already been moved from the node for a very long time. Have you hit that kind of issue before? Thanks.
Finally I have verified this is cuased by issue in nsenter_mount.GetFileType func, with above PR, the node.volumesInUse list will be correct below are the test result with & without this fix Before fix(it costs 9 min for rescheduling 3 pods with disk mount from one node to another) After fix: (it costs 3 min for rescheduling 3 pods with disk mount from one node to another)

Discussion:
func (mounter *NsenterMounter) GetFileType(pathname string) (FileType, error) { var pathType FileType <del> outputBytes, err := mounter.ne.Exec("stat", []string{"-L", `--printf "%F"`, pathname}).CombinedOutput() </del> <ins> outputBytes, err := mounter.ne.Exec("stat", []string{"-L", "--printf=%F", pathname}).CombinedOutput() </ins> if err != nil { <ins> if strings.Contains(string(outputBytes), "No such file") { err = fmt.Errorf("%s does not exist", pathname) } else { err = fmt.Errorf("stat %s error: %v", pathname, string(outputBytes)) } </ins> return pathType, err }