jiebi/CodeConvo huggingface dataset:
Change:
v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/fields" </ins> "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apimachinery/pkg/watch" <ins> "k8s.io/kubernetes/pkg/kubelet/events" </ins> "k8s.io/kubernetes/test/e2e/framework" e2ekubelet "k8s.io/kubernetes/test/e2e/framework/kubelet" e2epod "k8s.io/kubernetes/test/e2e/framework/pod"

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: For a Pod with , kubelet would attempt to create a new sandbox for it even after all container succeeded. Logs as below: This issue is similar to which fixed the case of pods whose RestartPolicy are Never. It caused unnecessary CRI and CNI calls, confusing logs and conflicts between the routine that creates the new sandbox and the routine that kills the Pod. It's likely also the root cause of because sometimes the routine that creates the second sandbox and the routine that kills unwanted pod run concurrently, then the netns would be gone when calling CNI. What you expected to happen: kubelet shouldn't create a new sandbox for pod with RestartPolicyOnFailure if all containers succeeded How to reproduce it (as minimally and precisely as possible): Create a pod like this: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 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:
/sig node
Created which may fix this.
/assign
Change:
} func TestAzureTokenSourceScenarios(t *testing.T) { <del> configMode := configModeDefault </del> expiredToken := newFakeAzureToken("expired token", time.Now().Add(-time.Second)) extendedToken := newFakeAzureToken("extend token", time.Now().Add(1000*time.Second)) fakeToken := newFakeAzureToken("fake token", time.Now().Add(1000*time.Second))

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: When using kubectl, authentication fails with the below error For some reason kubectl is adding a lot of s to the start of the SPN - this can be observed in What you expected to happen: Authentication works as in previous versions of Kubectl How to reproduce it (as minimally and precisely as possible): Create a cluster using Azure AD authentication. Authenticate from a client and wait until the token expires. Use Kubectl and have it automatically refresh the token; it will fail due to the extra 'spn:' entries. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: on-premise OS (e.g: ): macOS 10.14.6 Kernel (e.g. ): Darwin Hostname 18.7.0 Darwin Kernel Version 18.7.0: Mon Feb 10 21:08:45 PST 2020; root:xnu-4903.278.28~1/RELEASEX8664 x86_64 Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others:
/sig cli
Kubectl version 1.18.0 Kubernetes version 1.16.6
can you confirm whether your original kubeconfig already has in apiserver-id or not? in the mean time, you may try it can convert your kubeconfig from azure module to exec module and do the token thing outside kubectl
At this point if I remove the tokens and try to reauth i get the error described above. I've tried it both ways with apiserver-id having an initially and not, both lead to the same behavior in the end.
i know what's going on now. will prepare a fix. the root cause is that token's target resource (adal.Token.Resource) needs to have prefix and this prefix gets unexpectedly to as well, which gets written back to kubeconfig. So every time kubectl is run, it adds to apiserver-id
/priority important-soon
I'm seeing this with kubectl 1.17.3 and kubernetes 1.16.7.

It's unclear to me what versions are impacted and in what version it is fixed, since only version 1.18 is mentioned.
This still happens on kubectl 1.16.12 and 1.17.8
This still happens on kubectl v1.18.5
same
can you guys share your kubectl version --client and kubeconfig with me? you can find me on kubernetes slack. the slack user name is same as my github handle.
Version 1.17.6 works fine.
Since I was mistaken thinking was still causing this for me, I figured I would just drop a note for others in case it's helpful. Turns out my problem was actually due to and looks to have been resolved as of the v3.3.0 release.
This issue has now reappeared for me - although not necessarily the same root cause. AKS 1.19.0 Authentication works, but it spams frequently.
Change:
--quiet } <ins> # Vars set: #   NODE_SUBNETWORK </ins> function create-subnetworks() { <ins> NODE_SUBNETWORK=$(gcloud beta compute networks subnets list  --network=${NETWORK}  --regions=${REGION}  --project=${PROJECT}  --limit=1  --format='value(name)' 2>/dev/null) if [[ -z ${NODE_SUBNETWORK:-} ]]; then echo "${color_red}Could not find subnetwork with region ${REGION}, network ${NETWORK}, and project ${PROJECT}" exit 1 fi echo "Found subnet for region ${REGION} in network ${NETWORK}: ${NODE_SUBNETWORK}" </ins> case ${ENABLE_IP_ALIASES} in true) echo "IP aliases are enabled. Creating subnetworks.";; false) echo "IP aliases are disabled." <del> if [[ "${ENABLE_BIG_CLUSTER_SUBNETS}" = "true" ]]; then </del> <ins> if [[ "${ENABLE_BIG_CLUSTER_SUBNETS}" = "true" ]]; then </ins> if [[  "${PREEXISTING_NETWORK}" != "true" ]]; then expand-default-subnetwork else

Discussion:
The "Services should be able to create an internal type load balancer [Slow]" e2e test is failing on our 2k-node gce clusters - https://k8s- with the following error: We're using custom subnets for our large cluster tests, and seems like the glbc controller is not able to handle them. cc
Seems similar to Assigning to you as you seem to have the context already :) Also, is this expected to be fixed in 1.8 timeframe?
doesn't set the necessary variables for the GCE cloud provider. Will throw you a PR.
Cool - thanks a lot!
Ref
I see the last test on 09/09 failed, but I can't see the build log due to exceeding memory. Any other way I can see the log, /reopen
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/network sig/scalability: 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/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
nevermind - went directly to raw log.
Friendly ping. This e2e is still failing (https://k8s-) and it's part of release-blocking suite.
/close
Change:
echo "OPTIONS='-b=kbr0 --selinux-enabled ${DOCKER_OPTS}'" >/etc/sysconfig/docker systemctl daemon-reload systemctl start docker <ins> systemctl restart kubelet </ins> } EOF

Discussion:
Self-assigning as I work out a reliable fix.
cc
Running into a few issues. On GCE, did you guys block somewhere to wait for etcd to be running before reporting success on kube-up?
No, except there is a race between addson services, dns and etcd container. We introduced a retry logic on those services.
I assume pulling the image is just so fast that you don't run into e2e errors, it looks like you guys block on wait-for-minions that uses glcloud, so I guess when minions are reported in etcd, then you know you are good...
Change:
create_and_use_new_namespace kube::log::status "Testing secrets" <ins> # Ensure dry run succeeds and includes kind, apiVersion and data output_message=$(kubectl create secret generic test --from-literal=key1=value1 --dry-run -o yaml) kube::test::if_has_string "${output_message}" 'kind: Secret' kube::test::if_has_string "${output_message}" 'apiVersion: v1' kube::test::if_has_string "${output_message}" 'key1: dmFsdWUx' </ins> ### Create a new namespace # Pre-condition: the test-secrets namespace does not exist kube::test::get_object_assert 'namespaces' '{{range.items}}{{ if eq $id_field "test-secrets" }}found{{end}}{{end}}:' ':'

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?: /kind bug What happened: Upgraded Kubectl to version 1.10.0 and now the flag on the creation of a docker-registry secret doesn't print out resulting in the following error: What you expected to happen: I expect the output to have a attribute in the YAML output. How to reproduce it (as minimally and precisely as possible): Here is an example you can run in bash of this not working: The output is: My exact shell code I'm running on the CI server is this Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: 3 on AWS managed with KOPS OS (e.g. from /etc/os-release): Alpine Linux on my CI server, MacOS on my main machine Kernel (e.g. ): Darwin Kernel Version 17.4.0
/sig CLI
cc
/status approved-for-milestone
/assign
[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
fyi
The issue appears to be with the command, not with : Will look into this
fix is in
No, the output of is missing kind/apiVersion.
thanks, just saw the PR
Change:
BootID:                  "1b3", KernelVersion:           "3.16.0-0.bpo.4-amd64", OSImage:                 "Debian GNU/Linux 7 (wheezy)", <del> OperatingSystem:         "linux", Architecture:            "amd64", </del> <ins> OperatingSystem:         goruntime.GOOS, Architecture:            goruntime.GOARCH, </ins> ContainerRuntimeVersion: "test://1.5.0", KubeletVersion:          version.Get().String(), KubeProxyVersion:        version.Get().String(),

Discussion:
TestUpdateNewNodeStatus TestUpdateExistingNodeStatus TestUpdateNodeStatusWithRuntimeStateError The above tests seem to be architecture specific now (and fail on unexpected objects "linux" vs "darwin"). Per I would expect unit tests to still pass on OSX
Change:
} func upgradeComponent(component string, waiter apiclient.Waiter, pathMgr StaticPodPathManager, cfg *kubeadmapi.MasterConfiguration, beforePodHash string, recoverManifests map[string]string) error { <ins> // Special treatment is required for etcd case, when rollbackOldManifests should roll back etcd // manifests only for the case when component is Etcd recoverEtcd := false if component == constants.Etcd { recoverEtcd = true } </ins> // The old manifest is here; in the /etc/kubernetes/manifests/ currentManifestPath := pathMgr.RealManifestPath(component) // The new, upgraded manifest will be written here

Discussion:
kubeadm etcd upgrade modifying recovery steps /assign /sig cluster-lifecycle /kind bug
Change:
var badMetrics []LatencyMetric for _, metric := range metrics { if !ignoredResources.Has(metric.resource) && <del> metric.verb != "WATCHLIST" && </del> <ins> !ignoredVerbs.Has(metric.verb) && </ins> // We are only interested in 99%tile, but for logging purposes // it's useful to have all the offending percentiles. metric.quantile <= 0.99 &&

Discussion:
I saw the below failure in [Performance suite] should allow starting 30 pods per node. Some requests with verb:PROXY took more than 10 seconds, and are causing the test to fail. I think that proxy issues are a different test, right? (maybe testMonitoringUsingHeapsterInfluxdb?) And that this taking 10 seconds could be very reasonable, depending on what we're proxying. There is this note in If that is the case, sounds like we should either clear the metrics, or if that is hard, record them before we run our test and ignore the pre-existing ones.
Yeah we should clearly exclude proxy from those metrics. This test is still being actively worked on :)
+1 for excluding proxy metrics This should be very simple fix, because we're already exluding all "watches" from the metrics. Reassigning it to me - will fix it today.
is sent out for review.
thanks for fixing!
Change:
return printModelInfo(w, pointedModel, pointedModelAsProp) } <ins> func splitGroupFromResource(resource string) (string, string) { seg := strings.SplitN(resource, "/", 2) if len(seg) == 1 { return "", seg[0] } else { return seg[0], seg[1] } } </ins> func splitDotNotation(model string) (string, []string) { var fieldsPath []string dotModel := strings.Split(model, ".")

Discussion:
It would be nice if let me explain experimental resources to aid users ability to experiment.
It's possible this works today, but it was non-obvious how to use. Attempts:
cc
cc
No, this isn't supported, since current implementation only use v1 Client but not experimental Client.
do we need to fix this for 1.1?
How difficult do you think it would be to fix?
It has dependency on ServerAPIVersions(), for which we plan to make a clean-up PR. I guess it needs 3-4 days to get two PRs merged.
With , this can be fixed now. What's the expected behavior of ? I assume in case of , it should search hpa in both v1 and extensions/v1bata1, and determines hpa as a resource in the extensions group? BTW, the use of "api-version" flag is problematic It adds extra meaning to the generic "api-version" flag.
Change:
fs.BoolVar(&s.AllowPrivileged, "allow_privileged", s.AllowPrivileged, "If true, allow privileged containers.") fs.Var(&s.PortalNet, "portal_net", "A CIDR notation IP range from which to assign portal IPs. This must not overlap with any IP ranges assigned to nodes for pods.") fs.StringVar(&s.MasterServiceNamespace, "master_service_namespace", s.MasterServiceNamespace, "The namespace from which the kubernetes master services should be injected into pods") <ins> fs.BoolVar(&s.SyncPodStatus, "sync_pod_status", s.SyncPodStatus, "If true, periodically fetch pods statuses from kubelets.") </ins> fs.Var(&s.RuntimeConfig, "runtime_config", "A set of key=value pairs that describe runtime configuration that may be passed to the apiserver.") client.BindKubeletClientConfigFlags(fs, &s.KubeletConfig) fs.StringVar(&s.ClusterName, "cluster_name", s.ClusterName, "The instance prefix for the cluster")

Discussion:
Split off as a smaller more specific work item. Apiserver should have a flag that makes it not attempt to GET from kubelets. This would be used in conjunction with . After we have converted the top N Getting-started-guides to the new style, we can rip out the kubelet client from the apiserver altogether.
This is tightly related to so I'll take it.
Change:
} } <del> // ensure the subnet is properly configured subnet, err := az.SubnetsClient.Get(az.ResourceGroup, az.VnetName, az.SubnetName, "") if err != nil { // 404 is fatal here return err } if subnet.RouteTable != nil { if *subnet.RouteTable.ID != *routeTable.ID { return fmt.Errorf("The subnet has a route table, but it was unrecognized. Refusing to modify it. active_routetable=%q expected_routetable=%q", *subnet.RouteTable.ID, *routeTable.ID) } } else { subnet.RouteTable = &network.RouteTable{ ID: routeTable.ID, } glog.V(3).Info("create: updating subnet") _, err := az.SubnetsClient.CreateOrUpdate(az.ResourceGroup, az.VnetName, az.SubnetName, subnet, nil) if err != nil { return err } } </del> targetIP, err := az.getIPForMachine(kubeRoute.TargetNode) if err != nil { return err

Discussion:
Feature Request Currently the Kubernetes Azure assumes kubernetes is deployed to the same Azure Resource Group as all of the dependencies. In my case our case we're interested in deploying kubernetes to a Virtual Network that sits in a different resource group to the cluster itself, this will enable us to deploy kubernetes to a subnet in a locked down vnet. I think there might be a few ways to do this. can add a field to , and if the need arises to do the same for the NetworkSecurityGroup or RouteTable then we could do the same there. We could assume that if the isn't provided then the cluster is in the same RG as the VNET. support for Resource IDs (). I think this is a substantial change, looking at the code. I'm inclined to think the first option is best for now, as it's the path of least resistance. What do you think? When we decide what's needed I'm happy to muck in and make the changes :) Cheers,
I'm curious for thoughts on this. I laid out the three options here: The easiest one is to simply remove the check where we inspect the subnet to make sure the route table is set correctly - the subnet/vnet references aren't used anywhere else. The second easiest is to add . The hardest, but most correct is the third option of using full identifiers. I'm leaning towards the first one in the short term, and the full identifier option in the longer-run; there are some platform improvements that will tie-in nicely with supporting full identifiers, but without requiring reving/versioning the config file.
Hadn't thought of the first option, quickly knocked together the . At least I think that's all is needed anyway, but i could be missing something. I agree with you on the third option, especially about not having a breaking change. If we choose two then I'll raise a PR for the above change. But i'll hold off for now :)
cc:
Is there any chance you'd be willing to remove the subnet-routetable check instead of the second option and see if that meets your needs? I think that's what we want to go with short-term. Chances are, if people aren't configuring the route table / subnet correctly, then they likely won't find their way to the error message anyway.

(Longer term we hope to move away from needing the config file at all, similar to other clouds.)
Yeah sure, I'll knock it up this evening then tag you in the PR :)
Change:
contentType:  "text/html", forwardedURI: "/proxy/minion/minion1:10250/logs/log.log", }, <ins> "full document": { input:        `<html><header></header><body><pre><a href="kubelet.log">kubelet.log</a><a href="/google.log">google.log</a></pre></body></html>`, sourceURL:    "http://myminion.com/logs/log.log", transport:    testTransport, output:       `<html><header></header><body><pre><a href="kubelet.log">kubelet.log</a><a href="http://foo.com/proxy/minion/minion1:10250/google.log">google.log</a></pre></body></html>`, contentType:  "text/html", forwardedURI: "/proxy/minion/minion1:10250/logs/log.log", }, </ins> "trailing slash": { input:        `<pre><a href="kubelet.log">kubelet.log</a><a href="/google.log/">google.log</a></pre>`, sourceURL:    "http://myminion.com/logs/log.log",

Discussion:
The ApiServer proxy wraps partial HTML responses to serve a complete HTML document in the proxy response. This is problematic for applications which expect HTML fragments, such as with AngularJS templates. Example: This is the response for a from the unproxied server: But the proxied response is: This issue is blocking
Change:
var ( nilRs *apps.ReplicaSet <ins> // DeploymentGroupVersionResource identifies a Deployment resource. DeploymentGroupVersionResource = schema.GroupVersionResource{Group: extensions.GroupName, Version: "v1beta1", Resource: "deployments"} </ins> ) var _ = SIGDescribe("Deployment", func() {

Discussion:
Which jobs are failing: ci-kubernetes-e2e-gce-new-master-upgrade-master-parallel Which test(s) are failing: [sig-apps] Deployment deployment should support rollback Since when has it been failing: 06-22 - 17:13 PDT Testgrid link: Reason for failure: Anything else we need to know: /priority critical-urgent /kind failing-test /sig apps
I will look in test together with
/milestone v1.16
stopped serving those APIs in 1.16. The test in the release-1.15 branch should skip if the server it is testing against does not serve the deprecated extensions/v1beta1 API
closing
and did not completely resolve the failing tests here or in /reopen
Reopened this issue. <detailsIn response to : and did not completely resolve the failing tests here or in /reopen </details
this job is running 1.14-level tests against master (1.16). the test should be updated to run 1.15 against master
Possible issue here is that we may have misconfigured upgrade/downgrade jobs (upgrading/downgrading to incorrect k8s versions). For full discussion see
/assign
Ultimately, the issue with this and was the the Kubernetes release markers did not point to the releases we expected. This was fixed during the recent 1.16 alpha release. /close
Closing this issue. <detailsIn response to : Ultimately, the issue with this and was the the Kubernetes release markers did not point to the releases we expected. This was fixed during the recent 1.16 alpha release. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
} } } <ins> func TestStaticPodNameGenerate(t *testing.T) { testCases := []struct { nodeName  types.NodeName podName   string expected  string overwrite string shouldErr bool }{ { "node1", "static-pod1", "static-pod1-node1", "", false, }, { "Node1", "static-pod1", "static-pod1-node1", "", false, }, { "NODE1", "static-pod1", "static-pod1-node1", "static-pod1-NODE1", true, }, } for _, c := range testCases { assert.Equal(t, c.expected, generatePodName(c.podName, c.nodeName), "wrong pod name generated") pod := &core.Pod{} pod.Name = c.podName if c.overwrite != "" { pod.Name = c.overwrite } errs := validation.ValidatePod(pod) if c.shouldErr { specNameErrored := false for _, err := range errs { if err.Field == "metadata.name" { specNameErrored = true } } assert.NotEmpty(t, specNameErrored, "expecting error") } else { for _, err := range errs { if err.Field == "metadata.name" { t.Fail() } } } } } </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 created a static pod for etcd as following with vsphere as cloud provider: But the hostname is using upper name, and when kubelet start the etcd static pod, it will report error as follows: I think that the vsphere should not return upper case hostname, but only lower case hostname. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area cloudprovider
Here is a quick
/sig node