jiebi/CodeConvo huggingface dataset:
Code change:
expected       []string // any of the items is valid }{ { <del> name:           "No node needs preemption", registerPlugin: st.RegisterPluginAsExtensions(noderesources.FitName, noderesources.NewFit, "Filter", "PreFilter"), nodeNames:      []string{"node1"}, pod:            st.MakePod().Name("p").UID("p").Priority(highPriority).Req(largeRes).Obj(), pods: []*v1.Pod{ st.MakePod().Name("p1").UID("p1").Node("node1").Priority(midPriority).Req(smallRes).StartTime(epochTime).Obj(), }, expected: []string{"node1"}, }, { </del> name:           "a pod that fits on both nodes when lower priority pods are preempted", registerPlugin: st.RegisterPluginAsExtensions(noderesources.FitName, noderesources.NewFit, "Filter", "PreFilter"), nodeNames:      []string{"node1", "node2"},

Related discussion:
text: Why do we bother creating a new candidates later? Can it just return candidates?
It can prevent from returning candidates with empty pods, but what about ? It's possible to add nodes without victim pods to candidates if returned by contain such nodes. How about adding the following check to CallExtender?
Updated the PR based on the finding and discussions.
Yes, we can use a flag to mark if all extenders don't support preemption. If yes, simply return the candidates.
Technically this can exist due to faulty extender implementation. If we really want to guard it, instead of logging the error and continue, I'm more inclined to return the error immediately as this is a fatal error - the victimsMap cannot be used either for latter extender or further preemptor nominating.
Is my understanding correct? In , if victimsMap is empty, should it return instead of ?
The only case victimsMap can be empty is empty candidates, and so return either doesn't quite matter, right?
You are right.
As long as one extender returns an invalid victimsMap (with empty pods), s returns an error immediately? What about ? Should it return an error immediately if it returnswith empty pods?
I think so. Because the result it returned is faulty, and we don't want to continue based on it The same. We may don't want to continue the scheduling cycle based on faulty result.
Code change:
# Compare Godep Licenses if ! _out="$(diff -Naupr ${KUBE_ROOT}/Godeps/LICENSES ${_tmpdir}/Godeps/LICENSES)"; then <del> echo "Your godep licenses file is out of date. Run hack/update-godep-licenses.sh and commit the results." echo "${_out}" </del> <ins> echo "Your godep licenses file is out of date. Run hack/update-godep-licenses.sh and commit the results." >&2 echo "${_out}" >&2 </ins> exit 1 fi

Related discussion:
text: <!-- 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?: When running on my commits locally I got the following error: Affected PRs:
/sig testing
/cc
There's likely something up with your local environment. These jobs are running correctly in CI, although you need to look at the build log for output
Code change:
} func checkDiskAttached(volPath string, vmdevices object.VirtualDeviceList, dc *object.Datacenter, client *govmomi.Client) (bool, error) { <del> virtualDiskControllerKey, err := getVirtualDiskControllerKey(volPath, vmdevices, dc, client) </del> <ins> _, err := getVirtualDiskControllerKey(volPath, vmdevices, dc, client) </ins> if err != nil { if err == ErrNoDevicesFound { return false, nil

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): v1.4.x v1.5.x v1.6.x master Environment: vSphere based install with vSphere Cloud Provider enabled. Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): NA Kernel (e.g. ):NA Install tools:kubernetes-anywhere Others: What happened: vSphere Cloud Provider configures additional SCSI adapters to scale the number of volumes that can be attached to a VM (1 adapter = 16 disks). The code within the cloud provider does not handle this correctly. Additional disks attach successfully to the VM but when k8s verifies the attach status it fails leading to k8s retrying the attach that never succeeds. In addition to this when the SCSI adapter is created for the first time the code does not use it to attach the disk leading to a failed attach disk request to the cloud provider. What you expected to happen: Additional disks should be to the VM upto the max number supported. How to reproduce it (as minimally and precisely as possible): Create a single node cluster and create a statefulset with 16 replicas or have a pod with more than 16 disks. Anything else we need to know:
A fix for this is coming up..
cc
Huh, I wonder if something changed between 1.3 and newer?
Code change:
} func checkDiskAttached(volPath string, vmdevices object.VirtualDeviceList, dc *object.Datacenter, client *govmomi.Client) (bool, error) { <del> virtualDiskControllerKey, err := getVirtualDiskControllerKey(volPath, vmdevices, dc, client) </del> <ins> _, err := getVirtualDiskControllerKey(volPath, vmdevices, dc, client) </ins> if err != nil { if err == ErrNoDevicesFound { return false, nil

Related discussion:
text: We had tested up to 40-something volumes on 1.3. There was a fun discussion internally because it would always fail at SCSI ID 7 and I had to explain SCSI to some younger engineers :)
Code change:
for i := range pod.Spec.InitContainers { switch resourceName { case v1.ResourceMemory: <del> containerValue.Add(*pod.Spec.Containers[i].Resources.Requests.Memory()) </del> <ins> if initValue.Cmp(*pod.Spec.InitContainers[i].Resources.Requests.Memory()) < 0 { initValue = *pod.Spec.InitContainers[i].Resources.Requests.Memory() } </ins> case resourceDisk: <del> containerValue.Add(*pod.Spec.Containers[i].Resources.Requests.StorageEphemeral()) </del> <ins> if initValue.Cmp(*pod.Spec.InitContainers[i].Resources.Requests.StorageEphemeral()) < 0 { initValue = *pod.Spec.InitContainers[i].Resources.Requests.StorageEphemeral() } </ins> } } if containerValue.Cmp(initValue) > 0 {

Related discussion:
text: <!-- 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: Kubelet constantly crashes trying to evict pods under memory pressure What you expected to happen: kubelet to be able to evict pods How to reproduce it (as minimally and precisely as possible): Fresh 1.9.1 Kubernetes, installed via kubeadm Here are relevant eviction parameters for kubelet Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"", GitTreeState:"archive", BuildDate:"2018-01-05T20:28:28Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-01-04T11:40:06Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: 8GiB of RAM OS (e.g. from /etc/os-release): Gentoo Kernel (e.g. ): Linux 4.9.34-gentoo SMP Sat Jan 13 23:06:16 MSK 2018 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux Install tools: Others:
contains the following code I think there is a bug in that it is iterating through InitContainers but getting resources of regular containers. I have a pod that has 3 initContainers. Looks like this could be a copy&paste error.
/sig node
indeed there's a mismatch between initContainers and spec containers, I'll take a look.
looks like we need to do the following and the problem was introduced in cc
- Indeed, I'll open a PR for this
reopening until it is cherrypicked to 1.9
It was cherry-picked in 1.9.3.
/close
Code change:
glog.Infof(volumeToMount.GenerateMsgDetailed("MapVolume.WaitForAttach succeeded", fmt.Sprintf("DevicePath %q", devicePath))) <del> // Update actual state of world to reflect volume is globally mounted markDeviceMappedErr := actualStateOfWorld.MarkDeviceAsMounted( volumeToMount.VolumeName, devicePath, globalMapPath) if markDeviceMappedErr != nil { // On failure, return error. Caller will log and retry. return volumeToMount.GenerateError("MapVolume.MarkDeviceAsMounted failed", markDeviceMappedErr) } </del> } // A plugin doesn't have attacher also needs to map device to global map path with SetUpDevice() pluginDevicePath, mapErr := blockVolumeMapper.SetUpDevice()

Related discussion:
text: <!-- 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: A Pod is run with local volume mounted in block mode. When that pod is deleted, the tear down process fails because device unmap fails. The device path appears to be empty, causing the unmap to fail. What you expected to happen: The teardown should have succeeded How to reproduce it (as minimally and precisely as possible): Create a pod with a PV for local volume in block mode. Delete the pod. Look at kubelet log files on the minion node to observe the error messages. Anything else we need to know?: Log messages: Feb 18 09:21:43 kubernetes-minion-group-crj1 kubelet[1510]: E0218 09:21:43. 1510 ] Operation for """ ("-148c-11e8-b315-")" failed. No retries permitted until 2018-02-18 09:21:44. +0000 UTC m=+. (durationBeforeRetry 500ms). Error: "UnmapVolume.UnmapDevice on global map path failed for volume "blkdata" (UniqueName: "") pod "-148c-11e8-b315-" (UID: "-148c-11e8-b315-") : Failed to unmap device from map path. mapPath is empty" Feb 18 09:21:43 kubernetes-minion-group-crj1 kubelet[1510]: I0218 09:21:43. 1510 ] operationExecutor.UnmountVolume started for volume "blkdata" (UniqueName: "") pod "-148c-11e8-b315-" (UID: "-148c-11e8-b315-") Environment: Kubernetes version (use ): 1.10+ Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): "Container-Optimized OS from Google" Kernel (e.g. ): Linux 4.4.86+ Install tools: Others:
/sig storage
This error is returned in this . It same that we set the global mount path to only if the volume plugin is attachable(see ).
Code change:
glog.Infof(volumeToMount.GenerateMsgDetailed("MapVolume.WaitForAttach succeeded", fmt.Sprintf("DevicePath %q", devicePath))) <del> // Update actual state of world to reflect volume is globally mounted markDeviceMappedErr := actualStateOfWorld.MarkDeviceAsMounted( volumeToMount.VolumeName, devicePath, globalMapPath) if markDeviceMappedErr != nil { // On failure, return error. Caller will log and retry. return volumeToMount.GenerateError("MapVolume.MarkDeviceAsMounted failed", markDeviceMappedErr) } </del> } // A plugin doesn't have attacher also needs to map device to global map path with SetUpDevice() pluginDevicePath, mapErr := blockVolumeMapper.SetUpDevice()

Related discussion:
text: However, local volume plugin is not attachable, so will be empty and the operation will fail. I think we should extract the operation from the block, and execute this operation just before we try to map the device to global map path, then this global map path can be cached in for both attachable and non attachable volume plugins. Any comments? If not, I can help to fix this.
Thank you for the investigation. We've discussed this problem by offline yesterday. I proposed same fix which you mentioned above, then tested the fix works correctly with local volume plugin. I'll push a PR soon.
The device path appears to be empty, causing the unmap to fail. Please note, which was stored in is empty. device path isn't related to this problem.
Sorry about that, this is a typo, what I mean is global mount path.
No, no. My above comment is just note for the section. Your investigation is correct.
Code change:
"fmt" "io" "io/ioutil" <ins> "testing" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/latest"

Related discussion:
text: I stumbled across this while experimenting with kubeconfig load order/merging. There are various helpers constructed from a Factory that use , however this always uses the same default ClientConfig because doesn't use the passed in version param: Am I missing something or is this a bug? /cc
Looks like a bug, clientforversion should accept "" (which can provide a default) and SetKubernetesDefaults has the final fallback protection (by using latest.Version). If version != defaultConfig.Version, we should copy defaultConfig, set version, then apply kubedefaults. The reason we take version here is if a resource is specified via file which only exists in a newer version, ie user says: --api-version=v1beta1 -f RESTMapper can handle that newresource is only valid for v1beta3 and apply the right override, then ask for client. --api-version is expected to bubble up via default config.
Code change:
set -o nounset set -o pipefail <del> if [[ -z "$1" ]]; then echo "Usage: $0 <version>" </del> <ins> if [ "$#" -ne 1 ]; then echo "Usage: ${0} <version>" </ins> exit 1 fi <del> if ! gsutil ls gs://kubernetes-release/release/${1}/kubernetes.tar.gz; then echo "Release files don't exist, aborting." exit 2 fi STABLE_FILE_LOCATION="kubernetes-release/release/stable.txt" </del> <ins> KUBE_RELEASE_VERSION="${1-}" </ins> <del> version_file=$(mktemp -t stable.XXXXXX) </del> <ins> KUBE_GCS_MAKE_PUBLIC='y' KUBE_GCS_RELEASE_BUCKET='kubernetes-release' KUBE_GCS_RELEASE_PREFIX="release/${KUBE_RELEASE_VERSION}" KUBE_GCS_PUBLISH_VERSION="${KUBE_RELEASE_VERSION}" </ins> <del> echo $1 >> ${version_file} echo "Uploading stable version $1 to google storage" gsutil cp ${version_file} "gs://${STABLE_FILE_LOCATION}" echo "Making it world readable" gsutil acl ch -R -g all:R "gs://${STABLE_FILE_LOCATION}" </del> <ins> KUBE_ROOT="$(dirname "${BASH_SOURCE}")/.." source "${KUBE_ROOT}/build/common.sh" </ins> <del> rm ${version_file} value=$(curl -s https://storage.googleapis.com/${STABLE_FILE_LOCATION}) echo "Validating version file" if [[ "${value}" != "${1}" ]]; then echo "Error validating upload, :${value}: vs expected :${1}:" </del> <ins> if "${KUBE_ROOT}/cluster/kubectl.sh" 'version' | grep 'Client' | grep 'dirty'; then echo "!!! Tag at invalid point, or something else is bad. Build is dirty. Don't push this build." >&2 </ins> exit 1 fi <ins> kube::release::gcs::publish_official 'stable' </ins>

Related discussion:
text: (cc Despite doing very, very similar things, doesn't rely on . It should, or the logic should otherwise be consolidated. I'm going to maybe work on this to make easier.
Code change:
# See the License for the specific language governing permissions and # limitations under the License. <del> .PHONY: all image push clean </del> <ins> SRCS = nnp ARCH ?= amd64 TARGET ?= $(CURDIR) GOLANG_VERSION ?= latest SRC_DIR = $(notdir $(shell pwd)) export </ins> <del> TAG = 1.2 PREFIX = gcr.io/google_containers </del> <ins> bin: ../image-util.sh bin $(SRCS) </ins> <del> all: push nnp: nnp.c gcc -static -o $@ $@.c image: nnp docker build --pull -t $(PREFIX)/nonewprivs:$(TAG) . push: image gcloud docker -- push $(PREFIX)/nonewprivs:$(TAG) clean: rm -f nnp </del> <ins> .PHONY: bin </ins>

Related discussion:
text: <!-- 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 feature This issue is for creating image as multiarch
/assign
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
/sig testing
Code change:
// volumeConfigName is the configmap passed to bootstrapper and provisioner volumeConfigName = "local-volume-config" // bootstrapper and provisioner images used for e2e tests <del> bootstrapperImageName = "quay.io/external_storage/local-volume-provisioner-bootstrap:v1.0.1" provisionerImageName  = "quay.io/external_storage/local-volume-provisioner:v1.0.1" </del> <ins> bootstrapperImageName = "quay.io/external_storage/local-volume-provisioner-bootstrap:v2.0.0" provisionerImageName  = "quay.io/external_storage/local-volume-provisioner:v2.0.0" </ins> // provisioner daemonSetName name, must match the one defined in bootstrapper daemonSetName = "local-volume-provisioner" // provisioner node/pv cluster role binding, must match the one defined in bootstrapper

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The local-volume bootstrapper/provisioner configuration format changed in kubernetes-incubator/external-storage, and its related e2e tests will fail when the provisioner & bootstrapper images are updated to v2.0.0. What you expected to happen: I'd expect the e2e tests to continue to work properly with the new version of the provisioner and boostrapper. How to reproduce it (as minimally and precisely as possible): Update local-volume provisioner and boostrapper images to v2.0.0, and then the provisioner e2e test will fail.
/sig storage
/assign
Code change:
return o.f.PrintObject(o.cmd, mapper, outputObj, o.out) } <del> cmdutil.PrintSuccess(mapper, false, o.out, info.Mapping.Resource, info.Name, false, "tainted") </del> <ins> cmdutil.PrintSuccess(mapper, false, o.out, info.Mapping.Resource, info.Name, false, operation) </ins> return nil }) } // validateNoTaintOverwrites validates that when overwrite is false, to-be-updated taints don't exist in the node taint list (yet) <del> func validateNoTaintOverwrites(obj runtime.Object, taints []v1.Taint) error { node, ok := obj.(*v1.Node) if !ok { return fmt.Errorf("unexpected type %T, expected Node", obj) } </del> <ins> func validateNoTaintOverwrites(node *v1.Node, taints []v1.Taint) error { </ins> allErrs := []error{} oldTaints := node.Spec.Taints for _, taint := range taints {

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.3.1185+-dirty Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.3.1185+-dirty" What happened: Kubectl is always reporting as node <XYZis tainted irrespective of operation when used with local cluster. taint nodes XYZ dedicated- node "XYZ" tainted What you expected to happen: It should have shown exact operation like tainted, untainted modified and overwritten but because of it is always returning tainted. How to reproduce it (as minimally and precisely as possible): taint nodes XYZ dedicated-
cc/
Regarding Yes I agree we should provide more clearer output/feedback. But providing something that makes output more confusing than existing is something would be even more concerning. So as I stated , it would be good to discuss/decide how the output/feedback should like for various operations for one and multi nodes scenarios.
I think having 1 return values is an exponential improvement on what we have now, even if they aren't perfect for all cases. Rather then a disproportionately long debate over a relatively simple improvement.... Could you guys suggest something simple that you're confident it will be easy to agree on, and we can implement it as a second pass ? we are happy to implement anything with n 1 return values :).
I think we'd be happy to consider any reasonable PR. I'm not sure why was closed; I didn't look at it though so I don't know if it solves the problem.
(hit close accidentally)
, I am not sure why was closed. But I raised a PR around 15 days ago() to address this.
Code change:
pvc, err = c.CoreV1().PersistentVolumeClaims(pvc.Namespace).Create(pvc) Expect(err).NotTo(HaveOccurred()) Expect(pvc).ToNot(Equal(nil)) <del> defer func() { framework.Logf("Deleting claim %q/%q", pvc.Namespace, pvc.Name) framework.ExpectNoError(c.CoreV1().PersistentVolumeClaims(pvc.Namespace).Delete(pvc.Name, nil)) }() </del> claims := []*v1.PersistentVolumeClaim{pvc}

Related discussion:
text: In 1.8, we a new feature to expose PVC information through summary API so user can check the volume belongs to which PVC. We should add e2e test in under test/e2enode.
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/storage: 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/cleanup: Adding tests, refactoring, fixing old bugs. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
/assign
GitHub didn't allow me to assign the following users: vkamra. Note that only can be assigned. <detailsIn response to : /assign 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
Can we please move this out of 1.8 milestone?
- I'm looking into adding this but yes we should move this out of 1.8. I don't have permissions to do that though.
ack Can we please move this out of 1.8?
Sorry am not sure why was this removed from 1.8 milestone. Are we not aiming to add the tests in 1.8? Or Are we disabling the feature or are we fine shipping it without any e2e tests in 1.8?
The test is in . I think we can keep this feature in 1.8
Code change:
buildImageRegistry      = registry.BuildImageRegistry gcAuthenticatedRegistry = registry.GcAuthenticatedRegistry gcEtcdRegistry          = registry.GcEtcdRegistry <del> gcHttpdRegistry         = registry.GcHttpdRegistry </del> gcRegistry              = registry.GcRegistry sigStorageRegistry      = registry.SigStorageRegistry gcrReleaseRegistry      = registry.GcrReleaseRegistry

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --/sig windows /cc After was merged I think.
I agree that looks like the issue. It started failing between the two commits: on this run:
/triage accepted
/assign