jiebi/CodeConvo huggingface dataset:
Change:
} } <del> func (plugin *kubenetNetworkPlugin) clearBridgeAddressesExcept(keep string) { </del> <ins> func (plugin *kubenetNetworkPlugin) clearBridgeAddressesExcept(keep *net.IPNet) { </ins> bridge, err := netlink.LinkByName(BridgeName) if err != nil { return

Discussion:
This is at least partially responsible for - some tests can't run when dns is down. Logs from just before the crash: It got killed because Kubelet decided to kill it (readiness probe failed): It started happening quite recently - I'm trying to locate a build which caused this. Repro: run "Kubelet should not restart containers across restart" test - it caused this behavior for me multiple times today. cc - I applied the P0/v1.3 label/milestone, as I think it should be a blocker. Feel free to decrease the priority if you disagree
gce-serial 1511 seems to be the first one with this problem.
Or 1510 - hard to tell, as it was a broken run. There's no PR around that looks too suspicious though:/
I locally reverted and it seems that DNS is no longer failing. Sadly I have to run to catch a train, but maybe someone can pick it up here ?
Taking a look now. The PR should be unrelated...I am checking to see if the Federation DNS changes went in yet. Add nethealth container to prepull manifest
I search the restart counts for jobs from 1510-latest and gce-serial Job 1540 is the first one to show a non-zero kubedns restart count. If there is a commit responsible, it would be between 1539 and 1540 (June 21 7 AM -11 AM) 1539 end of run 1540 end of run Latest
The kubedns:1.3 container hasn't been updated since (Sat, 04 Jun 2016 03:29:37.847 GMT). GET
cc The kubedns container code is from June 04th. Dawn suggested that its networking issues that are causing kubedns container to fail its readiness check. I will need to add logic to print kubedns container logs during e2e tests, I am trying to search for any logs that might help, otherwise I will have to debug the next run live.
As reported, a simple kubelet restart triggers this issue - it looks like 10.0.0.1 is unreachable from the kubedns container.

The kubedns container blocks indefinitely waiting for a connection to the kubernetes service at 10.0.0.1 before setting up the healthz handlers - the readiness probe will fail until kubedns successfully connects to the API server.
- you can try reverting and running it again - it worked for me for some reason (it might be by accident though)
I think the root cause is that cbr0 doesn't have an IP address assigned after kubelet restart - all the pods running behind cbr0 are isolated from the network. Not only kube-dns, but after my kubelet restart, the other addon pods are also stuck in a crash loop.
This sounds like a blocker even more now.
Looks like a regression. I am investigating.
Found the root cause. There is a subnet ip mismatch. vs . Hence kubenet thinks they are different and clears the address. Will submit a fix soon.
i found coredns status is CrashLoopBackOff and i check the logs : i got tips from so i restart my docker , i check the logs , there is no error in logs again
Change:
Corefile: | .:53 { errors <del> log stdout </del> <ins> log </ins> health <del> kubernetes __PILLAR__DNS__DOMAIN__ __PILLAR__CLUSTER_CIDR__ </del> <ins> kubernetes __PILLAR__DNS__DOMAIN__ __PILLAR__CLUSTER_CIDR__ { pods insecure } </ins> prometheus proxy . /etc/resolv.conf cache 30

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG What happened: When CoreDNS is deployed by default using feature-gates of kubeadm, it does not log anything when processing a DNS query. That is due to change of log option of CoreDNS in latest version. that version was bumped up in kubeadm, but the manifest was not adapted to the new log option. initial change of 'log stdout' in CoreDNS : version of CoreDNS 1.0.0 bumped into Kubeadm : NOTE: I guess we should also changed manifests for kube-up : see The change in manifest expected is to remove the option "stdout" in the line "log ...". As it is now interpreted as a scope of domain to log. Invalid manifest: Environment: Kubernetes version (use ): 1.9 and MAIN Cloud provider or hardware configuration: any Install tools: kubeadm, kube-up the configmap for coredns kubectl get configmaps -n kube-system coredns -o yaml kubectl replace -f - the coredns deployment kubectl scale deployment --replicas=0 -n kube-system coredns kubectl scale deployment --replicas=1 -n kube-system coredns
/cc /sig network
NOTE: only log is impacted. CoreDNS working as expected.
/cc
I have a question : the initial manifest is done for the image 0.9.10 of CoreDNS. Bumping the version of CoreDNS was done by changing the version in file (see ) which means that the image's version is STILL 0.9.10 in the manifests ... and the corefile config is correct against the version of the manifest. QUESTION: when modifying the , is there a way to upgrade the manifest by program ? I guess at the time the new version number is applied on the manifest ...
thanks for reporting this! I send PR to update the Corefile. I don't think of a way so far. I guess we can't unless there is a way to get the Corefile from some place of upstream (CoreDNS).
Change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/wait"

Discussion:
According to this APIsnoop query, there are still some remaining Endpoints endpoints which are untested. Create a Service in a namespace List all Endpoints in all Namespaces find the created Service(1) Replace/update the Namespaced Endpoint for the Service(1) Patch the Namespaced Endpoint for the Service(1) Get the Namespaced Endpoint for the Service(1) Delete Namespaced Endpoint(1) via a Collection with a LabelSelector Discover useragents: If a test with these calls gets merged, Conformance coverage will go up by 4 points /sig testing /sig architecture /area conformance
When you create a selector, race conditions can occur between controllers and our test code. We have services that test endpoint code, we could do these as explicit tests that are NOT handled by the endpoints controller. Let's try this with are managed by the endpoints controller w/ a selector. Endpoints normally go along with services: we want to create a service sans selector. This keeps it out of the endpoints controller, so we can test directly. Agreed for backlog. Double check that we don't already have test for that, whether it's being done by the endpoints controller that doesn't hit the API. Look at ALL the user agents that hit the endpoint.
/reopen /open Needs promotion!
Reopened this issue. <detailsIn response to : /reopen /open Needs promotion! 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
/retitle Promote CoreV1Endpoints test - +4 coverage
This doesn't have an APISnoop PR because (the exact process wasn't in place properly when the original mock test ticket was made)
/retitle Write CoreV1Endpoints test+promote - +4 coverage
please close this Issue in favour of and place in In Progress Issues on org dashboard
/close Close this Issue in favour of and place in In Progress Issues on org dashboard
Closing this issue. <detailsIn response to : /close Close this Issue in favour of and place in In Progress Issues on org dashboard 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
/close Close this Issue in favour of and place in In Progress Issues on org dashboard
Change:
By("Saturating pet set " + ps.Name) pst.saturate(ps) <ins> By("Verifying petset mounted data directory is usable") ExpectNoError(pst.checkMount(ps, "/data")) </ins> cmd := "echo $(hostname) > /data/hostname; sync;" By("Running " + cmd + " in all pets") <del> pst.execInPets(ps, cmd) </del> <ins> ExpectNoError(pst.execInPets(ps, cmd)) </ins> By("Restarting pet set " + ps.Name) pst.restart(ps) pst.saturate(ps) <ins> By("Verifying petset mounted data directory is usable") ExpectNoError(pst.checkMount(ps, "/data")) </ins> cmd = "if [ "$(cat /data/hostname)" = "$(hostname)" ]; then exit 0; else exit 1; fi" By("Running " + cmd + " in all pets") <del> pst.execInPets(ps, cmd) </del> <ins> ExpectNoError(pst.execInPets(ps, cmd)) </ins> }) It("should handle healthy pet restarts during scale [Feature:PetSet]", func() {

Discussion:
Eg: Suspect it's because of:
If this hasn't been seen in 3 months, okay to close?
Yes we fixed it with
Change:
} func toInternalPodOrError(obj runtime.Object) (*api.Pod, error) { <del> pod := &api.Pod{} </del> switch t := obj.(type) { case *v1.Pod: <del> if err := v1.Convert_v1_Pod_To_api_Pod(t, pod, nil); err != nil { </del> <ins> converted, err := api.Scheme.ConvertToVersion(obj, api.SchemeGroupVersion) if err != nil { </ins> return nil, err } <ins> if pod, ok := converted.(*api.Pod); ok { return pod, nil } else { return nil, fmt.Errorf("expect *api.Pod, got %v", converted) } </ins> case *api.Pod: <del> pod = t </del> <ins> return t, nil </ins> default: return nil, fmt.Errorf("expect *api.Pod or *v1.Pod, got %v", t) } <del> return pod, nil </del> } // podMatchesScopeFunc is a function that knows how to evaluate if a pod matches a scope

Discussion:
The pod evaluator used by the resource quota controller made direct calls to an unsafe pod conversion function which mutates the pod argument. With multiple resource quota controller workers, concurrent processing of the same pod from a shared informer can result in a panic when the conversion code attempts to write to a map field in the pod. Observed in this and discovered through analyzing core dumps from the controller manager. The bug is only present in <=1.7: the conversion code in 1.8 no longer mutates the input. In my branch, I a small unit test to which reliably reproduces the panic: /kind bug
Fixed by
Change:
return err } <del> // Invalidate the cache since we would update it. if err = ss.deleteCacheForNode(vmName); err != nil { return err } </del> <ins> // Invalidate the cache since right after update defer ss.deleteCacheForNode(vmName) </ins> // Update vmssVM with backoff. ctx, cancel := getContextWithCancel()

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: vmss dirty cache issue, caused by What you expected to happen: clean vmss cache should happen after disk attach/detach operation, now it's before those operations, which would lead to dirty cache. 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:
namespace, name, err := namer.Name(req) if err != nil { <del> notFound(w, req.Request) </del> <ins> errorJSON(err, codec, w) </ins> return } ctx := ctxFn(req)

Discussion:
e.g. REST.Update should never return an arbitrary error value. Maybe we should change the return code to something stricter than generic error.
/cc
FYI: is for remaining cases where the API doesn't return JSON/Status errors.
Re-opening this until we
I think etcd errors require more abstraction, also:
There are some admission control plugins that did not always follow that practice which I will resolve as part of
Are there any known instances of this remaining?
None that I know of.
Change:
cd "${KUBE_ROOT}/third_party" if [[ $(uname) == "Darwin" ]]; then download_file="etcd-v${ETCD_VERSION}-darwin-amd64.zip" <del> curl -fsSLO --retry 3 https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/"${download_file}" </del> <ins> curl -fsSLO --retry 3 --keepalive-time 2 https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/"${download_file}" </ins> unzip -o "${download_file}" ln -fns "etcd-v${ETCD_VERSION}-darwin-amd64" etcd rm "${download_file}" else <del> curl -fsSL --retry 3 https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz | tar xzf - </del> <ins> curl -fsSL --retry 3 --keepalive-time 2 https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz | tar xzf - </ins> ln -fns "etcd-v${ETCD_VERSION}-linux-amd64" etcd fi kube::log::info "etcd v${ETCD_VERSION} installed. To use:"

Discussion:
http://pr- Seems like a flake? Could probably retry this, but not sure whether it's worth it.
we most definitely want to retry! Will you send a PR?
I just hit this in PR
We should close this, should be fixed by:
that didn't actually solve the problem. Per the docs, only works on "transient" errors, which the manpage defines as We might want to try passing , which some googling suggests might help. The default is 60s, which may be too long.
Please reactive this if you see it after June 15
Change:
// ExtraArgs are extra arguments provided to the etcd binary // when run inside a static pod. <ins> // A key in this map is the flag name as it appears on the // command line except without leading dash(es). </ins> ExtraArgs map[string]string `json:"extraArgs,omitempty"` // ServerCertSANs sets extra Subject Alternative Names for the etcd server signing cert.

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 --I was reading the doc about NodeRegistration, with an interest in specifying some . I noticed that the doc (e.g., ) does not tell me exactly how to identify each arg: exactly as on the command line (including leading dash(es)), as on the command line but without leading dash(es), or camelCase. I expected the doc to enable me to write some with confidence. 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:
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 cluster-lifecycle
FWIW the answer is flag names as on the command name but without any leading dashes. This also applies to controllerManager.extraArgs, scheduler.extraArgs, etc. which hopefully should all cover this similarly (if not now, after fixing ...)

<!-- 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 --I was reading about how to use kubeadm and noticed a typo in the API documentation. speaks of the "node subnet" where I think "pod subnet" is intended. 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:
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 cluster-lifecycle
/area kubeadm
Change:
return lbStatus.Ingress[0].IP, nil } <del> func (az *Cloud) ensurePublicIPExists(service *v1.Service, pipName string, domainNameLabel string) (*network.PublicIPAddress, error) { </del> <ins> func (az *Cloud) ensurePublicIPExists(service *v1.Service, pipName string, domainNameLabel, clusterName string) (*network.PublicIPAddress, error) { </ins> pipResourceGroup := az.getPublicIPAddressResourceGroup(service) pip, existsPip, err := az.getPublicIPAddress(pipResourceGroup, pipName) if err != nil {

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: We deployed two Kubernetes clusters to the same Azure Resource Group. Created services of load balancer type on both clusters. One of the services never received a public IP. Upon investigation, we noticed that the first Kubernetes cluster deleted the Azure Public IP that was created for the service by the other cluster. Apparently, all public IPs in the resource group are retrieved: then public IPs which don't match this criteria: are deleted. This logic besides the name of the kubernetes service should also consider the K8s cluster where the public IP originated from to avoid stepping on each other's toes when multiple clusters share the same resource group. What you expected to happen: In case multiple clusters run in the same resource group a cluster should delete only resources created by itself. How to reproduce it (as minimally and precisely as possible): Create two Kubernetes clusters (1.14) with different cluster names to the same resource group than create kubernetes services of load balancer type in each cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
thanks for reporting the issue, this is the bug we should fix for sharing resource group. /sig azure /kind bug /assign
Change:
cancelContextAfter int attemptsExpected   int errExpected        error <ins> timer              Timer </ins> }{ { name: "condition successful is only one attempt",

Discussion:
While trying to update to use latest version of package and to migrate away from deprecated , function, our tests fail as it seems new function immediately executes given condition twice, which is not mentioned anywhere. Result of executed test specified below: Since has been deprecated and it recommends using , I expected it to have the equivalent semantics to allow easy migration from deprecated functions, as no changelog or documentation mentions new semantics. Playground: Local: file with the following content: as . No response_ <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
CC since you were involved in
/assign /triage accepted
I'd like to work on this one if it's allowed I think this is a simple fix with few lines removed: i.e.: instead of only wait a loop if immediate is false, we wait a time loop after special execution also if the immediate is true.
/assign
/assign
Change:
v1.ResourceName(v1.ResourceStorage): resource.MustParse("1Gi"), }, }, <ins> StorageClassName: cfg.StorageClassName, </ins> }, } } <del> func CreatePDWithRetry() (string, error) { </del> <ins> func createPDWithRetry(zone string) (string, error) { </ins> var err error for start := time.Now(); time.Since(start) < PDRetryTimeout; time.Sleep(PDRetryPollTime) { <del> newDiskName, err := createPD() </del> <ins> newDiskName, err := createPD(zone) </ins> if err != nil { Logf("Couldn't create a new PD, sleeping 5 seconds: %v", err) continue

Discussion:
For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
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
Change:
cmc.Check(t) } <ins> func TestOnEndpointSliceUpdate(t *testing.T) { _, esController := newController([]string{"node-1"}, time.Duration(0)) ns := metav1.NamespaceDefault serviceName := "testing-1" epSlice1 := &discovery.EndpointSlice{ ObjectMeta: metav1.ObjectMeta{ Name:      "matching-1", Namespace: ns, Labels: map[string]string{ discovery.LabelServiceName: serviceName, discovery.LabelManagedBy:   controllerName, }, }, AddressType: discovery.AddressTypeIPv4, } epSlice2 := epSlice1.DeepCopy() epSlice2.Labels[discovery.LabelManagedBy] = "something else" assert.Equal(t, 0, esController.queue.Len()) esController.onEndpointSliceUpdate(epSlice1, epSlice2) err := wait.PollImmediate(100*time.Millisecond, 3*time.Second, func() (bool, error) { if esController.queue.Len() > 0 { return true, nil } return false, nil }) if err != nil { t.Fatalf("unexpected error waiting for add to queue") } assert.Equal(t, 1, esController.queue.Len()) } </ins> // Ensure SyncService handles a variety of protocols and IPs appropriately. func TestSyncServiceFull(t *testing.T) { client, esController := newController([]string{"node-1"}, time.Duration(0))

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: Mistake use obj as prevObj prevEndpointSlice := obj.(discovery.EndpointSlice) What you expected to happen: prevEndpointSlice := prevObj.(discovery.EndpointSlice) 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: cc
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved PR for fixing it Thanks
Change:
v1 "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" <ins> "k8s.io/apimachinery/pkg/api/resource" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/wait" utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/client-go/kubernetes" featuregatetesting "k8s.io/component-base/featuregate/testing" <ins> "k8s.io/component-helpers/storage/volume" </ins> "k8s.io/kubernetes/pkg/features" st "k8s.io/kubernetes/pkg/scheduler/testing" testutils "k8s.io/kubernetes/test/integration/util"

Discussion:
We need an integration test for the scheduler enforcement of the alpha feature. This is required for beta graduation; we need to collect signal on the current behavior before we can proceed. See this comment for context:
/sig storage /sig scheduler
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
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig storage /sig scheduler 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