jiebi/CodeConvo huggingface dataset:
Change:
if len(az) < 1 { return "", fmt.Errorf("invalid (empty) AZ") } <del> region := az[:len(az)-1] </del> <ins> r := regexp.MustCompile(`^([a-zA-Z]+-)+d+`) region := r.FindString(az) if region == "" { return "", fmt.Errorf("invalid AZ: %s", az) } </ins> return region, nil }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : AWS release [Local Zones] (). One user enable local zones, using us-west-2 as an example, there's AZ and AWS right now uses method here to infer to region. This won't work for local zone region. Why is this needed: Update to cover this case
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/area provider/aws
Change:
exit 0; } <ins> kube::golang::build_binaries_for_platform() { local platform=$1 local use_go_build=${2-} local -a statics=() local -a nonstatics=() for binary in "${binaries[@]}"; do if kube::golang::is_statically_linked_library "${binary}"; then kube::golang::exit_if_stdlib_not_installed; statics+=($binary) else nonstatics+=($binary) fi done if [[ -n ${use_go_build:-} ]]; then # Try and replicate the native binary placement of go install without # calling go install.  This means we have to iterate each binary. local output_path="${KUBE_GOPATH}/bin" if [[ $platform != $host_platform ]]; then output_path="${output_path}/${platform////_}" fi for binary in "${binaries[@]}"; do local bin=$(basename "${binary}") if [[ ${GOOS} == "windows" ]]; then bin="${bin}.exe" fi if kube::golang::is_statically_linked_library "${binary}"; then kube::golang::exit_if_stdlib_not_installed; CGO_ENABLED=0 go build -installsuffix cgo -o "${output_path}/${bin}"  "${goflags[@]:+${goflags[@]}}"  -ldflags "${version_ldflags}"  "${binary}" else go build -o "${output_path}/${bin}"  "${goflags[@]:+${goflags[@]}}"  -ldflags "${version_ldflags}"  "${binary}" fi done else # Use go install. if [[ "${#nonstatics[@]}" != 0 ]]; then go install "${goflags[@]:+${goflags[@]}}"  -ldflags "${version_ldflags}"  "${nonstatics[@]:+${nonstatics[@]}}" fi if [[ "${#statics[@]}" != 0 ]]; then CGO_ENABLED=0 go install -installsuffix cgo "${goflags[@]:+${goflags[@]}}"  -ldflags "${version_ldflags}"  "${statics[@]:+${statics[@]}}" fi fi } # Return approximate physical memory in gigabytes. kube::golang::get_physmem() { local mem # Linux, in kb if mem=$(grep MemTotal /proc/meminfo | awk '{ print $2 }'); then echo $(( ${mem} / 1048576 )) return fi # OS X, in bytes. Note that get_physmem, as used, should only ever # run in a Linux container (because it's only used in the multiple # platform case, which is a Dockerized build), but this is provided # for completeness. if mem=$(sysctl -n hw.memsize 2>/dev/null); then echo $(( ${mem} / 1073741824 )) return fi # If we can't infer it, just give up and assume a low memory system echo 1 } </ins> # Build binaries targets specified # # Input:

Discussion:
Filing for This code is wrong The local needs to be on a separate line from the command execution, and we need to be resilient to not existing on OS X, like:
For once I was actually watching the output of a build and noticed that I was seeing an error about md5sum not being found. I'm building on a mac using boot2docker. The short_hash function () works fine on my mac as md5 does exist.
Actually, I'm just going to fix this as a follow-on to .
Thank you!
Change:
// verifyRunAsNonRoot verifies RunAsNonRoot. func verifyRunAsNonRoot(pod *v1.Pod, container *v1.Container, uid int64) error { effectiveSc := securitycontext.DetermineEffectiveSecurityContext(pod, container) <del> if effectiveSc == nil || effectiveSc.RunAsNonRoot == nil { </del> <ins> // If the option is not set, or if running as root is allowed, return nil. if effectiveSc == nil || effectiveSc.RunAsNonRoot == nil || !*effectiveSc.RunAsNonRoot { </ins> return nil }

Discussion:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubelet securitycontext 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 ): 1.7.0-beta/1.8.0 (HEAD) Environment: Cloud provider or hardware configuration: gce OS (e.g. from /etc/os-release): gci Kernel (e.g. ): Install tools: Others: docker runtime (rkt seems to have a different code path, but I haven't checked it) What happened: containers could not run as root when "RunAsNonRoot=false" What you expected to happen: containers could run as root How to reproduce it (as minimally and precisely as possible): add a securitycontext to a container, don't set privileged, do set RunAsNonRoot, use an image that runs as root. The PodSecurityPolicy admission controller will always set a securitycontext if it's not specified, and cause this to be hit more often. Anything else we need to know: The bug is in the checks here: I have a fix in but that going in depends on an extension being granted. We may want to fix the bug regardless.
/sig node
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
I'll send a fix shortly.
Change:
utilexec "k8s.io/utils/exec" ) <del> // exclude those used by azure as resource and OS root in /dev/disk/azure </del> <ins> // exclude those used by azure as resource and OS root in /dev/disk/azure, /dev/disk/azure/scsi0 // "/dev/disk/azure/scsi0" dir is populated in Standard_DC4s/DC2s on Ubuntu 18.04 </ins> func listAzureDiskPath(io ioHandler) []string { <del> azureDiskPath := "/dev/disk/azure/" </del> var azureDiskList []string <del> if dirs, err := io.ReadDir(azureDiskPath); err == nil { for _, f := range dirs { name := f.Name() diskPath := azureDiskPath + name if link, linkErr := io.Readlink(diskPath); linkErr == nil { sd := link[(libstrings.LastIndex(link, "/") + 1):] azureDiskList = append(azureDiskList, sd) </del> <ins> azureResourcePaths := []string{"/dev/disk/azure/", "/dev/disk/azure/scsi0/"} for _, azureDiskPath := range azureResourcePaths { if dirs, err := io.ReadDir(azureDiskPath); err == nil { for _, f := range dirs { name := f.Name() diskPath := filepath.Join(azureDiskPath, name) if link, linkErr := io.Readlink(diskPath); linkErr == nil { sd := link[(libstrings.LastIndex(link, "/") + 1):] azureDiskList = append(azureDiskList, sd) } </ins> } } }

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: Cannot mount azure disk on Standard_DC4s/DC2s instances details: What you expected to happen: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
"path" rt "runtime" "strconv" <ins> "strings" </ins> "time" "k8s.io/kubernetes/pkg/admission"

Discussion:
Is this expected? Does it mean that we cannot drop and replace alpha api without waiting for the new gcloud version?
cc:
cc
cc:
My money is on the TPR discovery code that is trying to identify TPR versions and hacks them into the list of registered APIs.
I guess it's not on HEAD? Do you have the PR#?
had a PR moving StatefulSet from v1alpha1 to v1beta1 and she didn't have the same problem. It's interesting why graduating PDB will have the problem
My PR has similar failure but different symptom. I created a GCE cluster locally. doesn't give me that error, but addon-manager isn't working properly. From addon-manager container log, I saw similar error:
Ah, I was using new kubectl
was using the newly built kubectl so we didn't see the problem at first. Addon-manager is using 1.4.4 kubectl, so we observed problem later.
Hmm, if the problem is the old versions of kubectl unable to dealing with new REST endpoints, then the problem is hard. I'll take a look.
is correct. See this .
I thought the TPR code was inert by default and required a flag to kick in
It seems the flag is enabled for most commands:
We need to support 1 minor version skew for kubectl, so we have to workaround in the server. We can hide those new APIVersions in the discovery API from old kubectl. I'm going to send a PR. In the mean time, if someone can come up with a better idea.
kubectl bug is fixed in , need to cherrypick the change to 1.4. is working on server side temp fix
should fix the problem.
The issue was "fixed" because the "unable to register" error was ignored (not returned, just logged), see:
that line in doesn't seem like a fix... it seems like it's leaving the client restmapper in an unknown state, which seems bad to me
Yeah it's not really a fix
Looks like kubectl should try to register the version to the existing group. IMO this isn't a blocker for
can you make sure there's a 1.5 issue tracking the failure to register the new versions into existing groups correctly, or we'll have a related issue in the future
Filed to track this
Change:
func TestApiserverMetrics(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> // Make a request to the apiserver to ensure there's at least one data point // for the metrics we're expecting -- otherwise, they won't be exported.

Discussion:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.
Change:
import ( "context" <ins> "fmt" </ins> apiequality "k8s.io/apimachinery/pkg/api/equality" "k8s.io/apimachinery/pkg/runtime"

Discussion:
An ingress resource with both annotation and set cannot be created. Ingress resources can be updated to include both the annotation and the without issue. Kubernetes response: The ingress should be deployed with both annotation and set, as it is supported by updating an existing ingress. Apply this resource: The code causing this issue is here: <details</details<details</details<detailsLinux, Mac, mulitple OSs with the same issue. It's caused by code as linked above </details<details</details<details</details<details</details
/sig network
that code referenced is only used on Create update has a different path is this based on an observation of the code or are you hitting this problem?
, correct. This only happens on create. Our work around now is to create an ingress resource with the annotation, and then update the resource, adding the . This involves 2 MRs and approval processes We are hitting this problem regularly as we scale out the number of kubernetes clusters we operate, and create new ingress resources. It's quite painful as we're starting to use , but cannot drop the ingressClass annotation yet as some third party services have not ported over to use the .
but why do you create it with the annotaiton?
Sorry, I don't understand your question. I need to be able to create an ingress resource with both the ingressClass annotation () and both set
yeah, that is my question, if you are creating the ingress with v1 you don't need the annotation, it was deprecated by the field, the annotation has to be there for the people that upgrades from v1beta1 to v1
As far as I know, External DNS still requires the annotation. We use external DNS, and thus cannot drop the annotation yet
I think what you're doing as a workaround is a valid approach . A better fix would be for the ingress controller you're using to migrate to properly use the v1 API for Ingress and IngressClass. Please consider filing a bug against that ingress controller or other component. We could also return a header when someone sets the annotation on an Ingress that already has set, to make it clear that this is not recommended.
It seems that PR got stuck , but is not a kubernets bug
IMO we should probably not hard-fail if these are both set, but a warning would be appropriate.

, i'd completely agree. Kubernetes is happy to have both set side by side, but the logic linked in the first comment blocks it. Seemingly needlessly.
Discussed at sig-net. We don't object to loosening this rule - an API warning seems sufficient. PRs welcome /triage accepted
Hi , I'm willing to help with this issue. I'm not familiar with , I read the relevant code and I think it seems that to add an API warning, I just need to implement for in . Am I right? And in the same time, don't check these two fields in validation?
Pretty much! See how Service works (though you probably don't need to put it into a different package, not sure why we did that..) kidddddddddddddddddddddd <
/assign
Change:
"fmt" "os" <ins> "github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2019-07-01/compute" </ins> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
I am trying to run Azure e2e tests: The test creates a volume in the cloud + runs a pod with the volume as in-line. The pod never starts: The test creates a "blob" disk, while the Azure machine expects "managed" disk. Does anyone run storage e2e tests on Azure regularly? Was it ever working? Managed disks are provisioned . Should the test suite create "managed" disks by default too? Environment: Kubernetes version (use ): v1.17.0-alpha.0.1089+-dirty
/sig azure
/sig cloud-provider
managed disk should be the default, the azure disk storage class in the test case may have
The volume is created outside of kubernetes dynamic provisioning to test pre-provisioned and inline volumes: I wonder if anyone actually runs the tests.
Change:
}) } } <ins> func Test_getDeprecatedTopologyNodeNames(t *testing.T) { testcases := []struct { name              string endpointSlice     *discovery.EndpointSlice expectedNodeNames sets.String }{ { name: "2 nodes", endpointSlice: &discovery.EndpointSlice{ Endpoints: []discovery.Endpoint{ {DeprecatedTopology: map[string]string{corev1.LabelHostname: "node-1"}}, {DeprecatedTopology: map[string]string{corev1.LabelHostname: "node-2"}}, }, }, expectedNodeNames: sets.NewString("node-1", "node-2"), }, { name: "duplicate values", endpointSlice: &discovery.EndpointSlice{ Endpoints: []discovery.Endpoint{ {DeprecatedTopology: map[string]string{corev1.LabelHostname: "node-1"}}, {DeprecatedTopology: map[string]string{corev1.LabelHostname: "node-3"}}, {DeprecatedTopology: map[string]string{corev1.LabelHostname: "node-3"}}, }, }, expectedNodeNames: sets.NewString("node-1", "node-3"), }, { name: "unset", endpointSlice: &discovery.EndpointSlice{ Endpoints: []discovery.Endpoint{ {DeprecatedTopology: map[string]string{"other": "value"}}, {DeprecatedTopology: map[string]string{"foo": "bar"}}, {DeprecatedTopology: nil}, }, }, expectedNodeNames: sets.NewString(), }, } for _, tc := range testcases { t.Run(tc.name, func(t *testing.T) { actualNames := getDeprecatedTopologyNodeNames(tc.endpointSlice) if !tc.expectedNodeNames.Equal(actualNames) { t.Errorf("Expected %+v node names, got %+v", tc.expectedNodeNames, actualNames) } }) } } </ins>

Discussion:
On the first update of an EndpointSlice using the v1 API, we drop deprecatedTopology with EndpointSlice strategy. Although we only do this if at least 1 endpoint has been modified, there is no guarantee that node name has been populated for all endpoints within the EndpointSlice. This is most noticeable if the first update using the v1 API is only adding endpoint(s). In that case the EndpointSlice controller does not update EndpointSlices and instead just adds the new endpoint(s). That will cause node names to be dropped from the deprecated topology field without having the newer node name field populated. Node name to be retained in deprecated topology until the new field was populated. an EndpointSlice with the v1beta1 API. an endpoint in that EndpointSlice: No response This is most notable after upgrading a 1.20 cluster to 1.21, but can technically occur in any 1.21 or newer cluster. Any Any Any N/A N/A
I'm working on a fix for this, hoping to have it out later today. /triage accepted /sig network /cc
I think this is better characterized as a controller bug, but is the safest mitigation I can think of in the short term, since we don't want to rewrite 100% of endpointslices on startup. Can you open a separate issue to work through the controller reconciliation so that v1 clients can depend on the nodeName field more reliably?
Change:
`)) Expect(err.Error()).To(Equal("[kind not set, apiVersion not set]")) }) <ins> It("is fine with crd resource with List as a suffix kind name, which may not be a list of resources", func() { err := validator.ValidateBytes([]byte(` apiVersion: fake.com/v1 kind: FakeList metadata: name: fake spec: foo: bar `)) Expect(err).To(BeNil()) }) </ins> })

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: I've created a CRD with the name . There is no validation specified on the CRD object. Creating the CRD itself succeeds, but attempting to create CRD resources with of that type fails with a validation error. What you expected to happen: I expect to be able to create CRD resources of type without a validation error. How to reproduce it (as minimally and precisely as possible): A normal working CRD example, : Applying this succeeds as expected: Simply changing the name of the CRD kind to breaks however, : CRD creates, but the actual resource fails validation: If you supply the object does create correctly. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Digitalocean VM cluster OS (e.g. from /etc/os-release): Server (Ubuntu 14.04.5) Client (Ubuntu 16.04.4) Kernel (e.g. ): Server (4.4.0-111-generic) Client (4.13.0-38-generic) Install tools: Others:
/sig api-machinery /area custom-resources
is a special suffix for name. When you create a object using , which will be render as instead of plain . That's why error occurs due to missing item list.
This sounds like a bug in , not a thing that should be "fixed" by restricting names.
I think the magic suffix is somewhat unexpected, but in the case that it doesn't change -- I would expect a warning or error when creating a CRD with that name. As for this specific behavior, I would consider it a bug -- there's no indication that the kubectl validation is against a different than the one explicitly specified in the resource, and confusingly disabling validation causes the operation to succeed normally (creating the explicitly defined resource , regardless of magic suffix).
cc
cc
PTAL . It is a kubectl bug.
Thanks! Fix works for me
Change:
# must make sure the output from parallel runs is not mixed. To achieve this, # we spawn a subshell for each parallel process, redirecting the output to # separate files. <del> printf "%sn" "${@}" | xargs -I{} -n1 -P${KUBE_COVERPROCS}  </del> <ins> # cmd/libs/go2idl/generator is fragile when run under coverage, so ignore it for now. # see: https://github.com/kubernetes/kubernetes/issues/24967 printf "%sn" "${@}" | grep -v "cmd/libs/go2idl/generator"| xargs -I{} -n1 -P${KUBE_COVERPROCS}  </ins> bash -c "set -o pipefail; _pkg="{}"; _pkg_out=${_pkg////_};  go test ${goflags[@]:+${goflags[@]}}  ${KUBE_RACE} 

Discussion:
I can reproduce it every time. and /cc
It show passes when doing this patch:
I do not know the detail, but it looks like the test actually report error at line 77 and not 78.
What go version are you using?
If I remember correctly, it could be reproduced when running with go1.5.3 and go1.6.1. To be more specific, the go test passes, and this issue only happened when enabled with .
Interesting. I guess code coverage changes the behavior of line reporting? I'm willing to take a PR to fix this!
the coverage tool rewrites source code. Seems like a bug that it changes line numbers in the files. Skipping it wasn't the right fix IMO, we should file a bug with them.
Closing due to age, reopen if this is re-creatable.
Change:
<del> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Launches a container and verifies it can be reached. Assumes that # we're being called by hack/e2e-test.sh (we use some env vars it sets up). set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. : ${KUBE_VERSION_ROOT:=${KUBE_ROOT}} : ${KUBECTL:="${KUBE_VERSION_ROOT}/cluster/kubectl.sh"} : ${KUBE_CONFIG_FILE:="config-test.sh"} export KUBECTL KUBE_CONFIG_FILE source "${KUBE_ROOT}/cluster/kube-env.sh" source "${KUBE_VERSION_ROOT}/cluster/${KUBERNETES_PROVIDER}/util.sh" prepare-e2e if [[ "${KUBERNETES_PROVIDER}" != "gce" ]] && [[ "${KUBERNETES_PROVIDER}" != "gke" ]]; then echo "WARNING: Skipping certs.sh for cloud provider: ${KUBERNETES_PROVIDER}." exit 0 fi # Set KUBE_MASTER detect-master # IMPORTANT: there are upstream things that rely on these files. # Do *not* fix this test by changing this path, unless you _really_ know # what you are doing. for file in kubecfg.key kubecfg.crt ca.crt; do echo "Checking for ${file}" "${GCLOUD}" compute ssh --zone="${ZONE}" "${KUBE_MASTER}" --command "ls /srv/kubernetes/${file}" done </del>

Discussion:
Part of umbrella issue . cc But this is my favorite shell test; it's so fast!
Change:
} } <del> apiPodStatus := kl.generatePodStatus(pod, podStatus) </del> <ins> apiPodStatus := kl.generateAPIPodStatus(pod, podStatus) </ins> // Record the time it takes for the pod to become running. existingStatus, ok := kl.statusManager.GetPodStatus(pod.UID) if !ok || existingStatus.Phase == api.PodPending && apiPodStatus.Phase == api.PodRunning &&

Discussion:
We moved reason cache and status convert function from to by , , and . After this, we should also migrate related old unit test to kubelet level. For we should add test for: [x] Different image pull policy. [x] Pod creation failure. [x] Pod image failure. For we should add test for: [x] ContainerStatuses order. [x] Last termination state. [x] How reason cache will affect the PodPhase: [x] Pull image failure reason [x] Pod creation failure reason
Time to close this issue? :)
Not yet, The last 3 tests are in . :)