jiebi/CodeConvo huggingface dataset:
Change:
t.Fatal(err) } ss1Rev1.Namespace = ss1.Namespace <del> ss1Rev2, err := NewControllerRevision(ss1, parentKind, ss1.Spec.Template.Labels, rawTemplate(&ss1.Spec.Template), 2, ss1.Status.CollisionCount) </del> <ins> // Create a new revision with the same name and hash label as an existing revision, but with // a different template. This could happen as a result of a hash collision, but in this test // this situation is created by setting name and hash label to values known to be in use by // an existing revision. modTemplate := ss1.Spec.Template.DeepCopy() modTemplate.Labels["foo"] = "not_bar" ss1Rev2, err := NewControllerRevision(ss1, parentKind, ss1.Spec.Template.Labels, rawTemplate(modTemplate), 2, ss1.Status.CollisionCount) ss1Rev2.Name = ss1Rev1.Name ss1Rev2.Labels[ControllerRevisionHashLabel] = ss1Rev1.Labels[ControllerRevisionHashLabel] </ins> if err != nil { t.Fatal(err) }

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: What happened: When a statefulset object is created, a lot of controllerrevisions are created at the same time. the controllerrevisions have differenct hash value but the same Data.Raw. How to fix it: two controllerrevisions are seen as the same , when [ControllerRevisionHashLabel] , Controllerrevision.Data.Raw , Controllerrevision.Data.Object are strictly the same // this line shoud be to fix the bug like below: Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.8 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I would help fix it
/kind bug /sig apps
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. 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
StatefulSet uses the following code to construct its history object (controllerrevision): However, collisionCount shouldn't be blindly increased when there's name collision. Because controller uses a cache store, the name collision could be due to a controllerrevision created but not yet observed by the controller. The right way to handle it is to first check if the controllerrevision with the same name has the same content as the one we're going to create, like how DaemonSet controller handles it:
Change:
echo "== Refreshing package database ==" until apt-get update; do echo "== apt-get update failed, retrying ==" <del> echo sleep 5 </del> <ins> sleep 5 </ins> done }

Discussion:
I noticed that there is a huge regression on node bootup since Wednesday last couple of days: Bad one: vs. good one: Please note that the issue is not related to any kubernetes component. The node hasn't run salt client yet. This explains a lot of node not ready issue we have lately. cc/
cc/
Whoa, it shouldn't even be running at all. That implies someone a package recently.
I didn't see any new package is , and the entire package size is the same. :-(
Can you dump /var/log/apt.history (I think it is) into here?
Sorry, . Hmm. I don't see anything new on a recent-ish head node, either, but YMMV.
Yes, just about to do it ... Here you are, and please note that it is from a different node with the same bad symptom:
Yeah, no issue there. Oh. Hm. Sorry, I forgot the one directly in .
Wait. The one in configure-vm is new, it's from , and we need to take it out.
Oh no - so sorry :-( does add an apt-get update to configure-vm. But you are installing bridge-utils from apt, so I thought it was correct to apt-get update first. I can easily remove the apt-get-update and add it back into the AWS version instead. In my experience, crazy-slow apt-get problems are either due to an IPv6 address being served to an IPv4 only host, or getting a bad mirror. Is there a GCE internal mirror? Could also be the gluster repo as well - not necessarily the debian repo.
Probably the bestest thing would be to make sure bridge-utils is on the base image, only apt-get-install bridge-utils if brctl is not available, and run apt-get-update as part of apt-get-install only once per script invocation. But this isn't actually fixing the problem. Something is seriously wrong if an apt-get update takes 12 minutes.
is actually built-in on (the later is a no-op, sorry). I went through an effort at some point to make sure that never needed to or anything, because we were having troubles like this.
I can work up a PR that will probably work for all parties.
Yes, that is the root cause and we want to remove all external dependencies at bootup time. Assign this to
Thanks & sorry again to all.
Change:
return true } <del> // Case 2: pod has been assumed and pod updates could be skipped. </del> <ins> // Case 2: pod has been assumed could be skipped. </ins> // An assumed pod can be added again to the scheduling queue if it got an update event // during its previous scheduling cycle but before getting assumed. <del> if sched.skipPodUpdate(pod) { return true </del> <ins> isAssumed, err := sched.SchedulerCache.IsAssumedPod(pod) if err != nil { utilruntime.HandleError(fmt.Errorf("failed to check whether pod %s/%s is assumed: %v", pod.Namespace, pod.Name, err)) return false </ins> } <del> return false </del> <ins> return isAssumed </ins> } func defaultAlgorithmSourceProviderName() *string {

Discussion:
Currently the scheduler may add an assumed pod back to the queue if the update didn't include specific fields (see ). There doesn't seem to be a reason why we can't simply ignore all updates of assumed pods. Assumed pods are waiting to be bound, if binding succeeded then the pod is scheduled. If binding fails, the pod's latest version will be put back into the unschedulable queue anyways. Performance: we save on unnecessary scheduling attempts. This is a followup on the discussion we had in /sig scheduling /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : #### What would you like to be : /triage accepted /help 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
What we basically need to do is: 1) remove function 2) in the places where we call , we should simply call
/assign
Change:
# config-default.sh. readonly GCE_MAX_LOCAL_SSD=8 <ins> BASE64_HELP=$(base64 --help) BASE64_INPUT_FLAG="" if [[ $BASE64_HELP =~ "--input" ]]; then BASE64_INPUT_FLAG="--input" else BASE64_INPUT_FLAG="" fi </ins> KUBE_ROOT=$(dirname "${BASH_SOURCE[0]}")/../.. source "${KUBE_ROOT}/cluster/gce/${KUBE_CONFIG_FILE-"config-default.sh"}" source "${KUBE_ROOT}/cluster/common.sh"

Discussion:
under kubernetes project and running get error: ! I am running on darwin arm64 running get this: if running on linux:
/area test
/sig cli
/sig testing /area test-infra /remove-sig cli /remove-area test
FWIW You pretty much have to install gnu coreutils to develop here, many scripts will actually refuse to run if the gnu version of utils are not available. That said, we should fix this.
/triage accepted
Change:
v1helper "k8s.io/kubernetes/pkg/api/v1/helper" "k8s.io/kubernetes/pkg/cloudprovider" "k8s.io/kubernetes/pkg/controller" <ins> kubefeatures "k8s.io/kubernetes/pkg/features" </ins> "k8s.io/kubernetes/pkg/util/metrics" )

Discussion:
For various reasons (network topology, heterogenous nodes, etc) a user may want to control the addition of a node to a cloud load balancer. A specific issue with the Azure Container Instances connector which introduces a virtual node can be found here: The right way to do this is via a node annotation, e.g.
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. 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
/reopen This is still a problem.. any word on when feature gate goes out of alpha?
Setup the enhancement tracking issue for this Still discussing with sig-network on how we want to move forward with this.
Change:
nginx "$@" oldcksum=`cksum /etc/nginx/conf.d/default.conf` <del> inotifywait -mr --timefmt '%d/%m/%y %H:%M' --format '%T'  </del> <ins> inotifywait -e modify,move,create,delete -mr --timefmt '%d/%m/%y %H:%M' --format '%T'  </ins> /etc/nginx/conf.d/ | while read date time; do newcksum=`cksum /etc/nginx/conf.d/default.conf`

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT on sample file I was using the /examples/https-nginx sample application for some small testing purposes and was surprised by the relative high load it kept having in the nginx pods. After some inspection I found out that kubernetes/examples/https-nginx/auto-reload- is basically running a busy loop. the command doesn't filter out some of the events it should filter out. At least on my system with just this sample config I always get a OPEN on basically immediately so I would recommend adding as arguments to the inotifywait command
I can take this.
I already have a PR in flight for this.
OK thanks for info
Change:
}, }, Sync:       false, <del> PollPeriod: time.Second * 20, </del> <ins> PollPeriod: time.Second * 2, </ins> Timeout:    time.Second * 20, } }

Discussion:
I'd like to make the case for moving the check out of the Storage interface and put that responsibility at a higher level. It was introduced . The case for moving it up 1) the interface it's implemented under already provides the primitives necessary to reproduce the check (GetPod) 2) it couples creation storage tightly to the (unreliable) infrastructure, which means consumers of the interface must anticipate both apiserver, storage, and infrastructure issues (vs just apiserver and storage) 3) as an API consumer I may want to know when my pod moves to pending, vs to started (which could be multiple orders of mangnitude longer) Would there be strong disagreement if I opened a pull moving the async wait to above the interface? Or is there a strong design reason to couple this here that I missed?
Hey Clayton, I think in general, I was trying to have it only return when it was "done" but as you point out, there are lots of problems with this, I think that falling back to "in our control" is perhaps the correct semantic. We've been thinking along similar lines, namely that we should only do acceptance testing (e.g. "is this pod feasible") before returning 200 and stopping waiting, instead of waiting for the task to go fully running. I took a rough design that proposed, and pasted it into: So if that design makes sense to you, and achieves the the same goals as what you are suggesting (I think it does) let's move towards that. The first thing might to roll back the other PR, and then move forward from the previous state. Thanks --brendan
Agree that we're "done" when the pod is accepted and stored in the system, and needn't wait until it's running. Ultimately, one should be able to wait on events (i.e., we'd wrap etcd's watch); one such event would be the state change from assigned to running, and that's how clients should get this behavior if they need it.
Agreed
This is fixed
Change:
if len(namespace) == 0 { namespace = metav1.NamespaceDefault } <del> selfLink = fmt.Sprintf("/api/"+api.Registry.GroupOrDie(api.GroupName).GroupVersion.Version+"/pods/namespaces/%s/%s", name, namespace) </del> <ins> selfLink = fmt.Sprintf("/api/"+api.Registry.GroupOrDie(api.GroupName).GroupVersion.Version+"/namespaces/%s/pods/%s", namespace, name) </ins> return selfLink }

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): selflink kubelet selflink default selflink manifest selflink Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): admin kubectl version Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-04-27T10:00:30Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-04-27T09:42:05Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: AWS OS: Debian GNU/Linux 8 (jessie) Kernel: Linux ip-10-150-109-115 4.4.41-k8s SMP Mon Jan 9 15:34:39 UTC 2017 x86_64 GNU/Linux Install tools: kops 1.5.3 Others: What happened: When running the selfLink for pods started from manifests were incorrect. Example: What you expected to happen: To receive a correct selfLink: Example: How to reproduce it (as minimally and precisely as possible): I believe simply using a pod manifest to start a pod will cause this issue as kubelet seems to rely on defaults when starting pods from manifests. Anything else we need to know: I believe the below linked line needs to be corrected:
/assign I reproduced it. Will fix. Thanks for reporting!
GitHub didn't allow me to assign the following users: xiangpengzhao. Note that only can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. I understand the commands that are listed . </details
Change:
:KUBE-NODEPORTS - [0:0] :KUBE-POSTROUTING - [0:0] :KUBE-MARK-MASQ - [0:0] <del> :KUBE-MARK-DROP - [0:0] </del> :KUBE-SVC-AHZNAGK3SCETOS2T - [0:0] :KUBE-SEP-PXD6POUVGD2I37UY - [0:0] :KUBE-SEP-SOKZUIT7SCEVIP33 - [0:0]

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-cos-master-alpha-features Which test(s) are failing: [sig-network] Networking should recreate its iptables rules if they are deleted [Disruptive] Since when has it been failing: as far as testgrid can see, since forever, it's like ... 10% flake Testgrid link: Reason for failure: Anything else we need to know: /cc /sig network /priority important-soon /milestone v1.17
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
FTR, I'm pretty sure that the feature is working fine and it's only the test that is broken. The kubelet logs (eg, ) show that it is noticing the deleted chains and reloading: I1119 10:56:23. 1325 ] iptables canary mangle/KUBE-KUBELET-CANARY deleted I1119 10:56:23. 1325 ] Reloading after iptables flush And if it failed to recreate any of the rules, it would log errors about it: if _, err := kl.iptClient.EnsureRule(utiliptables.Append, utiliptables.TableNAT, KubeMarkDropChain, "-j", "MARK", "--set-xmark", dropMark); err != nil { klog.Errorf("Failed to ensure marking rule for %v: %v", KubeMarkDropChain, err) return } and we don't see those errors in the logs. So I think there's just a bug in the test case. Trying to reproduce now in a debug PR...
my apologies, this is the cause of the flakiness The test tries to find the KUBE-MARK-DROP rule but kube-proxy deletes the rule because we are not recreating it as we are doing with the KUBE-MARK-MASK Since is only needed for kube-proxy with dual stack in iptables mode and that PR is not merged we can revert it. The other option is making the the chains in kubelet and kube-proxy different
Change:
// no configuration is an error, some parameters are required if len(data) == 0 { <del> return nil, fmt.Errorf(errfmt, fmt.Errorf("config file was empty, but some parameters are required")) </del> <ins> return nil, fmt.Errorf("init config file %q was empty, but some parameters are required", path) </ins> } return utilcodec.DecodeKubeletConfiguration(loader.kubeletCodecs, data)

Discussion:
From in The most important things I want to see through node e2e tests: 1) the kubelet is started from last-known-good-config file 2) kubelet can download the new config properly to the node; and restart itself from the new config file 3) kubelet can mark the config bad properly after several round of crashing caused the bad config 4) Kubelet can roll back the last-known-good-config and restart itself from that good one 5) kubelet can properly reports its configuration status Note: (2) is covered by existing e2enode tests (1, 4, 5) were covered by the , all of which I plan to turn into automated tests after this PR merges - but I'm trying not to increase the size of this PR any further ~(3) we need to figure out how to test this. I don't want to rely on a "valid" config that causes a crash loop - because the very existence of such a config should be viewed as a bug. I also don't want to include a "please crash loop for our tests" field in the config, because that's an ugly API. The best solution is not clear here.~ We decided to remove crash-loop detection, see . Filing this issue to track this work: into e2e_node tests [x] remote config [x] local (from file) config [x] ~test the crash-loop detection~ removed, see above /cc
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.8 milestone for more than 7 days: kind: Must specify exactly one of [, , ]. priority: Must specify exactly one of [, , ]. Removing it from the milestone. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
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
/remove-lifecycle stale
The test cases in the OP have been covered by our e2e_node tests for a while.
Change:
internalELB := false internalAnnotation := apiService.Annotations[ServiceAnnotationLoadBalancerInternal] if internalAnnotation != "" { <del> if internalAnnotation != "0.0.0.0/0" { return nil, fmt.Errorf("annotation %q=%q detected, but the only value supported currently is 0.0.0.0/0", ServiceAnnotationLoadBalancerInternal, internalAnnotation) } if !service.IsAllowAll(sourceRanges) { // TODO: Unify the two annotations return nil, fmt.Errorf("source-range annotation cannot be combined with the internal-elb annotation") } </del> internalELB = true }

Discussion:
Kubernetes version (use ): v1.4.6 Environment: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CoreOS v1235.2.0 Kernel (e.g. ): 6-coreos-r1 SMP Wed Dec 7 00:29:42 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux What happened: When creating a service-type loadBalancer, adding creates an internal ELB, but the only allowed value for is 0.0.0.0/0. This limitation prevents you from specifying custom CIDR range for your hybrid cloud (Direct Connect to private data center) What you expected to happen: The limitation is unnecessary. Even in an AWS only scenario (no hybrid cloud), it makes sense to allow a CIDR range for a subnet where your calling services are deployed. How to reproduce it (as minimally and precisely as possible): Create a service-type loadBalancer and set loadBalancerSourceRanges to a value other than 0.0.0.0/0
Any update on this? Also, is anyone working on adding support for securityGroup?
any progress on this? I also really would like to have this flexibility in place for integrating k8s into an existing VPC.
Change:
// This error is ok, beacuse we will delete the pod before it completes initialization framework.Logf("error from create uninitialized namespace: %v", err) }() <del> podB = waitForPodInNamespace(f.ClientSet, podB.Namespace, podB.Name) </del> <ins> podB = waitForPodInNamespace(f.ClientSet, namespace.Name, podB.Name) </ins> By("Deleting the namespace") err = f.ClientSet.Core().Namespaces().Delete(namespace.Name, nil)

Discussion:
Test is constantly failing. https://k8s- https://k8s- /cc
After was manually merged last Friday, serial tests is back to normal flaky stage except this test which is constantly failing. Raise the priority.
i will take a look.
Is supposed to fix this?
they seem like different issues. is about slow namespace deletion. This seems to be an issue with the namespace objects being created?
spotted a bug in the tests. Sent
-- i think this is a separate issue.. for some reason, an empty namespace name is being passed into client which doesnt appear possible at first glance.
I'm going to necro this bug because I figured out why it's failing pod starts trying to get pod namespace starts trying to get the service account secret, but it's been deleted keeps trying and trying and trying to mount, but goes into backoff ~80s later it finally gives up and unmounts the secret it never mounted Logs above are from 1.12. When a pod is detected as deleted, we're trying to unmount a secret that can't / doesn't exist. The fact that the pod is deleted should abort mount much faster, even if mount is in backoff. this is a flaky conformance test (and fixing this should have an impact on other failure modes like this).
It is different than the other cause, so probably deserves a second issue, but we should assess which linked issues are actually this problem and link those into the final fix.
cc fixed a secret teardown issue in the past
/area conformance
I am not sure if it is a bug as such. It is true that when pod is removed, volumemanager tries to mount the volume anyways and since it fails to fetch secret, it keeps failing. to fetch secret is a non-fatal error and volumemamanger is right in retrying that operation. think bit that is problematic is - mount and unmount operation basically share the exponential backoff . I have filed to track this. A workaround might be to increase the wait period in following code: But I can see how having this shared exp. backoff may have domino effect on other tests and may be pod teardown time can be improved in general if mount and unmount did not share the exp. backoff.

/assign
As far as I can see the issue has now been resolved; on test grid I see only green for this test: https://k8s- https://k8s- was the PR that seems to have fixed this. /close
Closing this issue. <detailsIn response to : As far as I can see the issue has now been resolved; on test grid I see only green for this test: https://k8s- https://k8s- 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