jiebi/CodeConvo huggingface dataset:
Change:
// CurrentSuite represents current test suite. var CurrentSuite Suite <del> // CommonImageWhiteList is the list of images used in common test. These images should be prepulled // before a tests starts, so that the tests won't fail due image pulling flakes. Currently, this is // only used by node e2e test. </del> <ins> // PrePulledImages are a list of images used in e2e/common tests. These images should be prepulled // before tests starts, so that the tests won't fail due image pulling flakes. // Currently, this is only used by node e2e test. // See also updateImageWhiteList() in ../../e2e_node/image_list.go </ins> // TODO(random-liu): Change the image puller pod to use similar mechanism. <del> var CommonImageWhiteList = sets.NewString( </del> <ins> var PrePulledImages = sets.NewString( </ins> imageutils.GetE2EImage(imageutils.Agnhost), imageutils.GetE2EImage(imageutils.BusyBox), imageutils.GetE2EImage(imageutils.IpcUtils),

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should come up with a better name for : Why is this needed: From /sig testing /priority important-soon /cleanup /help /good-first-issue
/assign
/lifecycle active /remove-help
what happened with ?
I redid it here There was a bit of confusion I'll fix it up.
/wg naming
Change:
<ins> # Copy of pod.yaml without file extension for test apiVersion: v1 kind: Pod metadata: name: nginx labels: name: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 </ins>

Discussion:
It works when I pipe but not with filename.
broke in this commit cc
Did you try to add an extension .json to the file? We filter for file extensions
ahhh ok. so working as intended. it used to autodetect :( ... thanks
That was unintended. The file extensions should only be used for deciding which files in a directory to process. For a single file, any extension should be allowed. We don't actually infer the content type from the extensions. For stdin and http sources, for instance, there are no extensions. cc
Fix is pretty straightforward (ignore file extensions when dealing with single file); I have it working with manual test, just adding unit test. Will send shortly.
Thanks, but this is v1.0-post, so no rush
Change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/util/intstr" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/kubernetes/test/e2e/framework" e2enetwork "k8s.io/kubernetes/test/e2e/framework/network"

Discussion:
What happened: indicates that we're missing an e2e test for. This specific issue is just a tracker to create a new E2E test that demonstrated .
/sig network
/assign
btw, should this be a part of conformance?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
I can start working on this.
Sure/ are you working full time on it ? If so I'll drop the issue from my work ... Otherwise we can collaborate as I already have some code for this. Let me know. Was hoping to have this done in the next week or so.
I would love to collaborate, especially if you already have some code. But if you want to drop this from your work, I don't mind taking it on full time either. I can pick up from where ever you left off.
ok, if youve got full bandwidth go for it. if make progress on it this wk ill just drop it . I actually dont know where my old branch is for this :), so i guess youll have to start from scratch. One thing to note ~ Might be seeing if any tests can be reused for this or extended in a simple way by just adding a secondary service, rather then writing a full blown test from scratch. Let me know how it goes thanks !
I will let you know how it progresses. Thanks !
thanks for getting this taken care of :) looks like the PR is LGTM.
Thanks for letting me take a stab at it!
Change:
spec: containers: - name: zeppelin <del> image: gcr.io/google_containers/zeppelin:v0.5.5_v1 </del> <ins> image: gcr.io/google_containers/zeppelin:v0.5.5_v2 </ins> ports: - containerPort: 8080 resources:

Discussion:
The image by is over a gig. Investigate how to trim this down. (Cut out interpretters? Make them more modular somehow, possibly composing them once we have some solution like ?) It's not even clear there's upstream support for making this more modular, though.
cc
remove mvn tooling and all the extra steps, once upstream releases 's like the rest of apache.
I can look at that, but I think I can actually just strip the image of the dev tooling right now. Right now I think the Zeppelin deps themselves are a ridiculous portion of this, though. (I'll poke at it.)
(3) is an install of [bzr git mercurial openssh-client subversion] in the base java image, which seems wasteful to me. you'll have to switch base images to get rid of this. (2) is your install of [curl net-tools build-essential git wget unzip python python-setuptools python-dev python-numpy libfontconfig]. i expect curl is at least redundant, as is git if your using the java image. you should merge this layer w/ (1) and do an uninstall of [python-setuptools python-dev etc] & deps at the end. of course, those are less significant than (1), which is the mvn build. the long term solution here is to use the upstream binaries, when they exist. in the meantime, you should clone zeppelin into tmp, copy out the resulting build artifact and delete the clone. that should at least cut the size of this layer in half, as all the intermediate build artifacts are likely still present and in the final tarball/jar.
I can trim it down some by cutting out the build machinery (and I'll put up a PR shortly), but here's what the looks like: And expanded: (Instead of just deleting, it's actually easy to build, copy out, compose, too.)
Is it me or are all the containers rather large. For example, does spark itself need to be a gig? 1.5.1v3 6 weeks ago 989.7 MB There's some spark binary package that's 73M uncompressed:
Java runtime + baseimage + transitive closer is what is causing most of the bloat. But as we have discussed on other tickets, these images need to move out of the main repository.

I'm afraid I don't understand "transitive closer". For example I see my JDK is around 280M, and the Spark binary is 73M. Then that leaves another 636M for base + whatever. I guess I'll have to look at the imagelayers if I'm really curious.
he means all the dependencies and their dependencies. if you'd like to tackle shrinking the spark image, please open an issue for it. we've done some work on this and you can use the example investigation above to help improve image sizes.
Change:
} for _, p := range poolsList { for _, l := range p.Listeners { <del> lbPools[l.ID] = p </del> <ins> // Double check this Pool belongs to the LB we're deleting. Neutron's API filtering // can't be counted on in older releases (i.e Liberty). for _, val := range lbListeners { if val.ID == l.ID { lbPools[l.ID] = p break } } </ins> } } return true, nil

Discussion:
Kubernetes version: $ kubectl version Client Version: version.Info{Major:"1", Minor:"3+", GitVersion:"v1.3.8-hpe.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-22T23:27:29Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"3+", GitVersion:"v1.3.8-hpe.1.3+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-09-29T14:43:35Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: OpenStack Liberty, Neutron LBaaS V2 using Octavia OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A What happened: Deleting a LoadBalancer service results in the deletion of all LoadBalancer service's LBaaS Pools and Monitors. What you expected to happen: The Pools and Monitors for unrelated services should not be deleted How to reproduce it (as minimally and precisely as possible): 2 services with type=LoadBalancer for LBaaS resources to be created 1 of the 2 services created earlier output, all pools will have been deleted. Anything else do we need to know: Neutron's API ignores unknown paramaters. When listing pools etc, K8 attempts to filter on "LoadBalancerID", which is not a valid filter. As such, it is ignored by Neutron, and a list of all pools is returned. K8 then proceeds to delete each of the pools.
We're still experiencing this problem, or at least one with very similar symptoms -- having launched services of type LoadBalancer and then deleting one of them, it deletes all of the pools of all services. As the original report, we're also using OpenStack Liberty, Neutron LBaaS V2, and just updated to K8s 1.5.1 (from 1.4.5) hoping that this fixed our issue, but we are still experiencing the same problem after the upgrade.

Is there any other way in which we can help to debug the issue, without delving into the code? (On a side note, the commit which is supposed to fix this is included as part of the 1.5.0 release, so I am not sure if this issue has not been closed for some reason).
it is possible I missed a case in the original fix, the simplest test I found for this issue we had was to create 2x services with type=loadbalancer, wait for all the LBaaS resources to be provisioned, then delete one of the services and ensure the other's resources are still present. If this is failing, either these been a regression, or something else has gone horribly wrong :)
Hi thanks for coming back to this issue. Apparently not all cases deleting the LoadBalancers in OpenStack/liberty were doing the extra step of filtering. We were working on a fix, and submitted a pull request, which is being considered right now:
has merged. closing this issue /close
Change:
github.com/fsnotify/fsnotify v1.4.7 h1:IXs+QLmnXW2CcXuY+8Mzv/fWEsPGWxqefPtCP5CnV9I= github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo= github.com/ghodss/yaml v0.0.0-20150909031657-73d445a93680/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04= <ins> github.com/ghodss/yaml v0.0.0-20180820084758-c7ce16629ff4 h1:bRzFpEzvausOAt4va+I/22BZ1vXDtERngp0BNYDKej0= github.com/ghodss/yaml v0.0.0-20180820084758-c7ce16629ff4/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04= </ins> github.com/globalsign/mgo v0.0.0-20180905125535-1ca0a4f7cbcb/go.mod h1:xkRDCp4j0OGD1HRkm4kmhM+pmpv3AKq5SU7GMg4oO/Q= github.com/globalsign/mgo v0.0.0-20181015135952-eeefdecb41b8 h1:DujepqpGd1hyOd7aW59XpK7Qymp8iy83xq74fLr21is= github.com/globalsign/mgo v0.0.0-20181015135952-eeefdecb41b8/go.mod h1:xkRDCp4j0OGD1HRkm4kmhM+pmpv3AKq5SU7GMg4oO/Q=

Discussion:
What happened: Created a CRD with a group/version/kind that defines a CustomResourceDefinition type overlapping with the in-tree kubernetes type (WARNING: do not create this CRD on a cluster you care about, see ) Note that two definitions for the group/version/kind appear in openapi: What you expected to happen: published openapi only includes the in-tree type, which has precedence /cc /area custom-resources /priority important-soon /sig api-machinery
/cc
haven't looked into the code yet. I'd expect the naming controller / apiextensions server to prevent conflicting CR GVK, but they are unaware of builtin API groups
CRD handling is isolated to the apiextensions server... it does not have information about all other built-in and aggregated APIs
mentioned something he was working on to make the aggregation layer honor APIService priorities (so that later definitions would not be included if something had already defined a GVK) edit: possibly
a naive idea is to reserve k8s groups in a hard code way that sounds good the CRD in defines a but the kubectl results are about . Did I miss something?
oops... fixed. I started with an API type under but the issue only surfaces for specific APIs (due to the generated definition name colliding for some types)
that wouldn't address duplicate GVKs from aggregated APIs
Three kinds of openapi paths/definitions that we want to prevent CRDs from overwriting: CRD API the spec aggregation in apiextensions-apiserver allows overwriting. I will send a fix native APIs well protected. The spec aggregation in kube-aggregator: 1) ignores duplicated paths and renames duplicated definitions; 2) treats kube-apiserver with than apiextensions-apiserver APIs the spec aggregation in kube-aggregator allows overwriting. The spec aggregation in kube-aggregator treats aggregated APIs with than apiextensions-apiserver. I'm thinking about giving apiextensions-apiserver the lowest priority, but then the problem is aggregated APIs can potentially overwrite the CRD API Note that none of the above prevents CRDs from adding new subpaths to existing APIs. E.g. a CRD can add a path to the CRD API, or to a aggregated API if it didn't have one
Change:
} if s.BootstrapToken != nil { <del> ret.BootstrapToken = s.BootstrapToken.Allow </del> <ins> ret.BootstrapToken = s.BootstrapToken.Enable </ins> } if s.ClientCert != nil {

Discussion:
/kind feature As part of , the flag on the API server should be renamed to something like . We'll leave deprecated (should it be a no-op or not?) for v1.8. Or we should consider adding an explicit flag to the API server in the same way we have  flag on controller-manager. Right now, it enables/disables most authn plugins implicitely based on other flags (often pointing to various files on disk; if you specified a path to that file, you also want to enable this authn module) What way do you prefer?
/assign
Rough plan: (1.8) Add (1.8) Make it an error to specify both and (so we don't have to decide on precedence) (1.8) Add a warning if is used. (1.9) Drop
is: Mark deprecated. cc Approve?
/reopen Re-opening because there's a little bit left to do in 1.9 (ready to go in ).
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 6 days, the issue will be moved out of the v1.8 milestone. priority: Must specify exactly one of [, , ]. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
svc.ObjectMeta.Namespace == ns && svc.Annotations["patchedstatus"] == "true" if !found { <del> framework.Logf("Observed Service %v in namespace %v with annotations: %v & Conditions: %v", svc.ObjectMeta.Name, svc.ObjectMeta.Namespace, svc.Annotations, svc.Status.LoadBalancer) </del> <ins> framework.Logf("Observed Service %v in namespace %v with annotations: %v & Conditions: %v", svc.ObjectMeta.Name, svc.ObjectMeta.Namespace, svc.Annotations, svc.Status.Conditions) </ins> return false, nil } for _, cond := range svc.Status.Conditions {

Discussion:
Test: Reason for failure: The test fails if there already exists some condition in the service's status. The test patches the service appending the test condtition to existing conditions but while checking seems to never go past the first condition (L3490 below). The status field in a case where the test fails: Relevant SIG(s): /sig network
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
what conditions is ? Where did you find these error? is this in a existing CI job?
This is not from a CI job, but from tests run on a local cluster with ACI-CNI, which sets the conditions for LoadBalancer services.
/sig testing
sig testing does not own tests :) each sig owns its own tests, in this case is sig network /remove-sig testing I think your analysis is correct, the test should iterate over the other conditions , I think that something like this will do it, but it will be nice to test it this seems a good opportunity to contribute /help
This request has been marked as needing help from a contributor. 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 : /sig testing 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
/assign
Change:
}) } <del> func verifyUnsupportedControllerEventEmitted(t *testing.T, dc *disruptionController) { // Verify that an UnmanagedPod event is generated found := false for e := range dc.recorder.(*record.FakeRecorder).Events { if strings.Contains(e, "managed by an unsupported controller") { found = true break </del> <ins> func verifyEventEmitted(t *testing.T, dc *disruptionController, expectedEvent string) { ticker := time.NewTicker(500 * time.Millisecond) for { select { case e := <-dc.recorder.(*record.FakeRecorder).Events: if strings.Contains(e, expectedEvent) { return } case <-ticker.C: t.Fatalf("Timed out: expected event not generated: %v", expectedEvent) </ins> } } <del> if !found { t.Fatalf("UnmanagedPod event not generated") } </del> } // TestMain adds klog flags to make debugging tests easier.

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
Reopened this issue. <detailsIn response to : /reopen 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:
}, stopCh) } <ins> // Takes a snapshot of all currently used services by known APIServices and // purges the cache entries of those not present in the snapshot. func (dm *discoveryManager) removeUnusedServices() { usedServiceKeys := sets.Set[serviceKey]{} func() { dm.servicesLock.Lock() defer dm.servicesLock.Unlock() // Mark all non-local APIServices as dirty for _, info := range dm.apiServices { usedServiceKeys.Insert(info.service) } }() // Avoids double lock. It is okay if a service is added/removed between these // functions. This is just a cache and that should be infrequent. func() { dm.resultsLock.Lock() defer dm.resultsLock.Unlock() for key := range dm.cachedResults { if !usedServiceKeys.Has(key) { delete(dm.cachedResults, key) } } }() } </ins> // Adds an APIService to be tracked by the discovery manager. If the APIService // is already known func (dm *discoveryManager) AddAPIService(apiService *apiregistrationv1.APIService, handler http.Handler) {

Discussion:
The in apiserver grows infinitely without ever purging serviceKeys which are not referenced by any APIServices. /sig api-machinery /cc /assign a limited size cache APIService your services Spec.Service field to a new address step 2 and watch the list grow No response_ <details26-1.27 </details<detailsN/A </details<details</details<detailsN/A </details<detailsN/A </details<detailsN/A </details
/triage accepted
/assign
what do we want to the limit the cache size by?
the cache currently doesn't purge s which are not being used by an
is this still an issue? should it be resolved before enabling by default?
Can you elaborate? I am not sure what you mean by enabling by default?
Yes That's the cache for the downloaded discovery for each apiservice. The list probably doesn't grow very large. Fix is in . Considering the pain of non-aggregated discovery on some users, and the time they have had to wait to get the feature, I'd say the trade-off is that this isn't nearly as bad.
It's also worth noting that the cache should only grow for Aggregated APIServices that themselves expose aggregated discovery endpoint. We don't store a cache entry here otherwise. The list doesn't grow unless the aggregated discovery document was successfully fetched. This is a very rare case and especially at release a minuscule number of people on the bleeding edge might run into it. And even then it is not likely to be changing the so often once it is working enough to store a cache entry.
Change:
func TestReflectorResync(t *testing.T) { iteration := 0 stopCh := make(chan struct{}) <ins> rerr := errors.New("expected resync reached") </ins> s := &FakeCustomStore{ ResyncFunc: func() error { iteration++ if iteration == 2 { <del> close(stopCh) </del> <ins> return rerr </ins> } return nil },

Discussion:
I saw this as well. Log: Brief discussion in
I think I have a fix for this
Just submitted a PR that I believe fixes this. I was able to get the flakes locally w/o my PR and haven't seen any with it. PTAL!
how did you repro locally? I tried ran this test 1,000 times last night and it passed 1,000 times.
Change the resync period from 1 milli to 1 microsecond. You can also add 'stress -c 8' to the mix. On Friday, May 20, 2016, Matt Liggett wrote:
- FYI
sent which should fix this
Change:
"experimentalsresourcesusagestracking" # Expect --max-pods=100 ) <ins> # Tests which kills or restarts components and/or nodes. DISRUPTIVE_TESTS=( "DaemonRestart" "Etcdsfailure" "NodessResize" "Reboot" "Services.*restarting" ) </ins> # The following tests are known to be flaky, and are thus run only in their own # -flaky- build variants. GCE_FLAKY_TESTS=(

Discussion:
We should be testing the reliability of a long-running cluster. These tests kill/restart components or nodes in the cluster, defeating the purpose of a soak cluster.
Example tests: NodessResize Services.restarting DaemonRestart NodessResize Reboot Etcd failure
Agreed. Some of them already seem to be skipped: GCESOAKCONTINUOUSSKIPTESTS=( "Density.30spods" "Elasticsearch" "Etcd.SIGKILL" "externalsloadsbalancer" "identicallysnamedsservices" "networkspartition" "Services.Typesgoessfrom" ) Q
FYI
It'd be hard to prevent regression as more tests are . It might be better if we explicitly define a set of DISRUPTIVETESTS, and include them wherever needed, e.g., GCEPARALLELSKIPTESTS and GCESOAKCONTINUOUSSKIPTESTS. That way, people who are adding tests will be aware of the category. WDYT?
Agreed, that seems like a good idea. Want to send in a PR? Or at least open an issue?