jiebi/CodeConvo huggingface dataset:
Change:
framework.Logf("Pod %s on node %s %s total=%s run=%s execute=%s", pod.Name, pod.Spec.NodeName, scenario, total, v.completeDuration, v.duration) return pod, errs } <del> // findContainerStatusInPod finds a container status by its name in the provided pod func findContainerStatusInPod(pod *v1.Pod, containerName string) *v1.ContainerStatus { for _, container := range pod.Status.InitContainerStatuses { if container.Name == containerName { return &container } } for _, container := range pod.Status.ContainerStatuses { if container.Name == containerName { return &container } } for _, container := range pod.Status.EphemeralContainerStatuses { if container.Name == containerName { return &container } } return nil } </del>

Discussion:
We would like to know early if the behavior is broken on any container runtime implementation. This is motivated by the discussion under the PR:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
/assign
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]:
/remove-lifecycle stale
Change:
importpath = "k8s.io/apimachinery/pkg/util/yaml", deps = [ "//staging/src/k8s.io/apimachinery/pkg/util/json:go_default_library", <del> "//vendor/k8s.io/klog/v2:go_default_library", </del> "//vendor/sigs.k8s.io/yaml:go_default_library", ], )

Discussion:
This bug was privately disclosed and told to open here. What happened: NewYAMLOrJSONDecoder from has an index out of bounds issue which can cause callers to panic. Download attached reproducer file Run golang test: When run with v0.19.3: Additionally, this can be seen in kubectl directly (below is kubectl 1.20.0): Environment: Kubernetes version (use ): Verified with 1.19, 1.20
/sig api-machinery
This piece attempts to find line+column position of a json syntax error. To do that it assumes that full input is available which is not true: is : is only the first data chunk: The subject happens e.g. when syntax error offset is past buffer size and Test to reproduce the panic: I am not sure it is easily possible to find line+column of json syntax error as full input may not be available. Maybe it should only attempt to find line+column if offset is within the first chunk (i.e. below buffer size).
Line number calculation in and updated in
do you want to submit a patch to with a defensive check to avoid the panic ( compare and )
I have raised a discussion on having line number in the . The consensus there is that it should be possible to count lines with a full input at hand and it does not worth to have it in the core library due to performance impact and maintenance costs. The problem of here is that it attempts to find out line number without having full input at hand. I think the defensive patch is not the right approach because line calculation is incorrect anyway even when there is no panic: begins at a value with a syntax error, i.e. in a stream of two values and syntax error in the second value it would contain only the second value and thus new lines in the first value in the stream would not be counted. I think the following options are there: to stream taken from . This is straightforward but changes interface. I can not find any code that uses field, it is only used in the error message that would change: line number only if offset is within the length of the first data chunk (). I am not sure what would be the unknown line number then, perhaps. line number properly during stream decoding, see This has some performance penalty as line number is calculated in any case even if there is no syntax error, i.e.

in the majority of the cases.
cc /triage accepted
This is probably acceptable.
I have opened a PR
Thank you for support.
Change:
"net/url" "os" "reflect" <ins> "runtime" "strings" </ins> "testing" "k8s.io/kubernetes/pkg/util/sets"

Discussion:
When using go 1.7, is failing with the following error:
Emm... I'll need this fix
Wouldn't a full struct copy work if we zero out the fields we don't want retained afterwards? It'll be less fragile as well.
You prefer to re-open my pull request or include that commit in ?
I'm also trouble in the issue when I execute command on release-1.4 branch of Kubernetes. Have someone fixed it? Fails (all fails in ):
, we can not just re-open : in , it did not include & which means build failed in go1.6 if re-open .
BTW, do we still support go1.6 in master? If so, we need upmerge to master.
Is this still a problem? I don't see any test failures on go-1.7.3

Hey Guys, When running command on release-1.4 branch, I got the below errors, my GO version is , how to fix it or something else have I missed?
dup of . fixed by . we can close this. /sig api-machinery
Sure, close it.
Change:
// translateMountPropagation transforms v1.MountPropagationMode to // runtimeapi.MountPropagation. func translateMountPropagation(mountMode *v1.MountPropagationMode) (runtimeapi.MountPropagation, error) { <ins> if runtime.GOOS == "windows" { // Windows containers doesn't support mount propagation, use private for it. // Refer https://docs.docker.com/storage/bind-mounts/#configure-bind-propagation. return runtimeapi.MountPropagation_PROPAGATION_PRIVATE, nil } </ins> if !utilfeature.DefaultFeatureGate.Enabled(features.MountPropagation) { // mount propagation is disabled, use private as in the old versions return runtimeapi.MountPropagation_PROPAGATION_PRIVATE, nil

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: Windows containers creation failed because of rslave mounts. What you expected to happen: Windows containers don't support mount propagation, we should disable it for windows. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig windows
What's your pod config for mount?
if you agree with this as a blocker for 1.10, could you go ahead and add "approved-for-milestone" label to this, as well as status? That will help it stay in the milestone.
/status approved-for-milestone
Any pods on Windows would meet same issue. It defaults to rslave now on master branch.
Change:
// TODO: Get rid of [DisabledForLargeClusters] tag when issue #56138 is fixed. It("should have session affinity work for LoadBalancer service with ESIPP on [Slow] [DisabledForLargeClusters]", func() { <ins> // L4 load balancer affinity `ClientIP` is not supported on AWS ELB. framework.SkipIfProviderIs("aws") </ins> svc := getServeHostnameService("service") svc.Spec.Type = v1.ServiceTypeLoadBalancer svc.Spec.ExternalTrafficPolicy = v1.ServiceExternalTrafficPolicyTypeLocal

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: What you expected to happen: The test should either succeed or be skipped on AWS How to reproduce it (as minimally and precisely as possible): Run this test on an AWS cluster with the AWS cloud provider configured Anything else we need to know?: The test sets the service's session affinity to here: The AWS cloud provider specifically only supports : Environment: Kubernetes version (use ): Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
cc
/cc
Thanks for the investigation, given the information so far, we should just skip this test on AWS. Will prepare a PR soon.
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" featuregatetesting "k8s.io/component-base/featuregate/testing" "k8s.io/component-base/metrics/testutil"

Discussion:
While validating nftable mode using conformance test, the following error logs were produced consistently: I thought it was because a known issue described here: However, the error was produced for every run and every kube-proxy instance, which doesn't seem related to the kernel bug. After some investigation, I think it's caused by a bug: in some cases a chain could change from stale to active, but once it's to it will always be deleted once. When the proxier tries to delete a previously stale but currently active chain, it would fail and lead to these errors, though it won't cause real problem thanks to kernel's validation. cc kube-proxy shouldn't try to delete active chains and produce such error logs. The e2e test case can reproduce it consistantly: No response <details</details<details</details<details</details<details</details<details</details<details</details
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 I have a PR to fix it.
/sig network /area proxy
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /area proxy </details
Change:
ss, err := newTestScaleSet(ctrl) assert.NoError(t, err, test.description) <del> expectedVMSS := buildTestVMSS([]string{testLBBackendpoolID0}) </del> <ins> expectedVMSS := buildTestVMSS(testVMSSName, []string{testLBBackendpoolID0}) </ins> mockVMSSClient := ss.cloud.VirtualMachineScaleSetsClient.(*mockvmssclient.MockInterface) mockVMSSClient.EXPECT().List(gomock.Any(), ss.ResourceGroup).Return([]compute.VirtualMachineScaleSet{expectedVMSS}, nil).AnyTimes() mockVMSSClient.EXPECT().Get(gomock.Any(), ss.ResourceGroup, testVMSSName).Return(expectedVMSS, nil).MaxTimes(1)

Discussion:
Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: TestEnsureBackendPoolDeletedConcurrently Testgrid link: Reason for failure: /sig cloud-provider
cc
/assign /area provider/azure
Change:
framework.PodNominator stop  chan struct{} <del> clock util.Clock </del> <ins> clock clock.Clock </ins> // pod initial backoff duration. podInitialBackoffDuration time.Duration

Discussion:
We should use /kind cleanup
/remove-kind feature /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-kind feature /good-first-issue 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
/sig scheduling /triage accepted
/assign
Change:
args = append(args, fmt.Sprintf("--image-type=%s", img)) } _, _, err := RunCmd("gcloud", args...) <del> return err </del> <ins> if err != nil { return err } waitForSSHTunnels() return nil </ins> } // CheckNodesReady waits up to nt for expect nodes accessed by c to be ready,

Discussion:
Upgrade fails with: Error from: https://k8s- Related failures: https://k8s- https://k8s-
/cc
might require how do the GKE tests interact with the defaults you set up?
Looks like are pretty isolated to upgrade tests.
Also we didn't start seeing this until the ABAC default change merged so I think change might help
it will definitely help with the GCE jobs mentioned in the description of
I haven't looked at the logs, so sorry if this is just noise, but the symptom (couldn't get logs b/c pod doesn't exist) looks very similar to what happened when the kubectl taint e2e tests were running in parallel instead of serial.
Judging by the comment and digging into the history , this used to be wrapped in a retry loop. It was removed in PR
it looks like this is limited to gke jobs in the upgrade tests. since getting pod logs depends on master-node communications, it would be affected by the SSH tunnels issue ()
Not blocking under guidance
Change:
ARG BASEIMAGE FROM $BASEIMAGE <del> LABEL image_version="1.29" </del> <ins> LABEL image_version="1.29-1" </ins>

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
Interact with the kubernetes-mesos framework via `kubectl`: ```bash <del> $ bin/kubectl get pods POD        IP        CONTAINER(S)        IMAGE(S)        HOST        LABELS        STATUS </del> <ins> $ kubectl get pods NAME      READY     REASON    RESTARTS   AGE </ins> ``` ```bash <del> $ bin/kubectl get services       # your service IPs will likely differ NAME            LABELS                                    SELECTOR            IP             PORT kubernetes      component=apiserver,provider=kubernetes   <none>              10.10.10.2     443 ``` Lastly, use the Mesos CLI tool to validate the Kubernetes scheduler framework has been registered and running: ```bash $ mesos state | grep "Kubernetes" "name": "Kubernetes", </del> <ins> # NOTE: your service IPs will likely differ $ kubectl get services NAME             LABELS                                    SELECTOR   IP(S)          PORT(S) k8sm-scheduler   component=scheduler,provider=k8sm         <none>     10.10.10.113   10251/TCP kubernetes       component=apiserver,provider=kubernetes   <none>     10.10.10.1     443/TCP </ins> ``` <del> Or, look for Kubernetes in the Mesos web GUI by pointing your browser to `http://${mesos_master}`. Make sure you have an active VPN connection. </del> <ins> Lastly, look for Kubernetes in the Mesos web GUI by pointing your browser to `http://<mesos_master_ip:port>`. Make sure you have an active VPN connection. </ins> Go to the Frameworks tab, and look for an active framework named "Kubernetes". ## Spin up a pod

Discussion:
Hi We are updating docs to v1beta3. v1beta1 and v1beta2 will be abandoned soon. For the examples in getting-started-guides, we tend to use hyperlinks to point to examples instead of letting them have their own individual examples (see ). However, in the mesos guide, the examples contain mesos specific setup and knowledge, so I can't simply remove the texts and point to kubernetes/examples/guestbook, which is updated to v1beta3. My suggestion is that we update the guestbook example in kubernetes-mesos, and use a hyperlink in mesos getting-started-guide to replace the example texts. Could you help to make the changes? Thanks.
cc
We're going to delete v1beta1 and v1beta2 in O(days). See PR .
cc
we've initiated an effort to upstream some components into k8s. as part of that effort, we're upgrading the guestbook examples for k8s-mesos: the getting started guide for mesos will likely have to change in order to align with the move upstream. tracking this issue here: , Brian Grant wrote:
xref , James DeFelice wrote:
Ref
cc
xref
This needs to be moved to the v1 API.
Agreed. We have changes in review right now, should be merged soon. , Brian Grant wrote:
Change:
github.com/google/go-cmp v0.4.0 github.com/gophercloud/gophercloud v0.1.0 github.com/mitchellh/mapstructure v1.1.2 <del> github.com/rubiojr/go-vhd v0.0.0-20160810183302-0bfd3b39853c </del> <ins> github.com/rubiojr/go-vhd v0.0.0-20200706105327-02e210299021 </ins> github.com/satori/go.uuid v1.2.0 // indirect github.com/stretchr/testify v1.4.0 github.com/vmware/govmomi v0.20.3

Discussion:
I ran an OSS license scan of a codebase that has this project as a dependency and came across an interesting hit. This go-vhd dependency specified here: has a snippet of code from StackOverflow which is license under creative commons sharealike. Here's the code in question: I'm not a license expert, so I don't know if there are any real issues/conflicts here or not, but wanted to share to see what you all think. Here's SO's license info for reference: My understanding is that the potential issue would be with this clause: which could potentially require go-vhd and projects that depend on it to use the Creative Commons license as well.
Thanks for the report! can you please take a look if this is concerning? If so, we'll check if we can avoid this dependency (looks unlikely unless we duplicate what it's ) or we'll follow up upstream to update the code. /cc OWNERS for this repo
CC-BY-SA can be problematic in Apache-2.0 projects like k8s because of the ShareAlike aspect as noted. I'd recommend working with upstream to rewrite just that one function particularly since it looks like it's fairly limited.
let's please move this issue to kubernetes/kubernetes?
/provider azure
/sig release /area code-organization
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig release /area code-organization 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
cc /assign
/area code-organization
/assign
/milestone v1.19 /priority important-soon
Not a huge difference, but this is likely actually licensed under , not 4.0. See
the k/k code actually does not reference , since that function is in , do you mean we should remove from k/k totally?
Yes, we would either need to remove from k/k or ask the maintainers of to update . This means that (and k/k if we end up using it) would need to be licensed until CC-BY-SA.
Would this ultimately be backported to older versions of k8s or would you just do it in 1.19?

thanks, Let me remove the code in v1.19, actually that part of functionality is deprecated in Azure cloud provider already. My initial thought is only do this in v1.19
/kind bug /priority important-soon /sig cloud-provider /area provider/azure
Since it isn't trivial to remove as a dependency entirely (), I've created upstream to track updating the code there.
Change:
envVarFiles := os.Getenv(RecommendedConfigPathEnvVar) if len(envVarFiles) != 0 { <del> chain = append(chain, filepath.SplitList(envVarFiles)...) </del> <ins> fileList := filepath.SplitList(envVarFiles) // prevent the same path load multiple times chain = append(chain, deduplicate(fileList)...) </ins> } else { chain = append(chain, RecommendedHomeFile)

Discussion:
/kind bug /sig cli What happened: The same path was multiple times to KUBECONFIG env variable. 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 ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-05T00:40:04Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"darwin/amd64"} Cloud provider or hardware configuration**: Irrelevant OS (e.g. from /etc/os-release): MacOS Sierra 10.12.6 Kernel (e.g. ): Darwin Kernel Version 16.7.0 Install tools: brew install kubernetes-cli Others:
I would help fix it.
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
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 /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
structuralSchemas[v.Name] = s } <del> var openAPIModels proto.Models if utilfeature.DefaultFeatureGate.Enabled(features.ServerSideApply) && r.staticOpenAPISpec != nil { specs := []*spec.Swagger{} for _, v := range crd.Spec.Versions { s, err := builder.BuildSwagger(crd, v.Name, builder.Options{V2: false, StripDefaults: true, StripValueValidation: true}) if err != nil { utilruntime.HandleError(err) return nil, fmt.Errorf("the server could not properly serve the CR schema") } specs = append(specs, s) } mergedOpenAPI, err := builder.MergeSpecs(r.staticOpenAPISpec, specs...) if err != nil { utilruntime.HandleError(err) return nil, fmt.Errorf("the server could not properly merge the CR schema") } openAPIModels, err = utilopenapi.ToProtoModels(mergedOpenAPI) if err != nil { utilruntime.HandleError(err) return nil, fmt.Errorf("the server could not properly serve the CR schema") } </del> <ins> openAPIModels, err := buildOpenAPIModelsForApply(r.staticOpenAPISpec, crd) if err != nil { utilruntime.HandleError(fmt.Errorf("error building openapi models for %s: %v", crd.Name, err)) openAPIModels = nil </ins> } for _, v := range crd.Spec.Versions {

Discussion:
What happened: While upgrading from v1.15 to try out kubernetes v1.16.0-beta.2, kube-apiserver is printing error messages: This also brakes the API server since the user is unable to even delete the "faulty" CR What you expected to happen: Not to print any error message and accept a CR that was already valid in 1.15 How to reproduce it (as minimally and precisely as possible): Install k8s 1.15.x (optional) Create the following CR Upgrade to k8s v1.16.0-beta.2check kube-apiserver for errors:Try delete the faulty CR (Won't be possible) Environment: Kubernetes version (use ): Anything else we need to know?: A quick search sent me to this code path that is being used to compile k8s It seems the problem it known but not yet fixed since this is in the latest commit of : /kind bug /king regression cc
/sig api-machinery
/assign /priority critical-urgent /milestone v1.16
This is caused by compiling the openapi spec for use by server-side apply here: SSA is using the method, which has significant gaps in handling valid openapi specs (see all the TODO comments in ) and until now was only used for client-side kubectl validation (as far as I'm aware). Using it in the server-side path is concerning. /assign
running with , this works as expected and is compatible with 1.15
/assign
fix and covering test is in
this is resolved in , available now