jiebi/CodeConvo huggingface dataset:
Change:
return true }) sortObjects(inFlightClaims) <del> stripObjects(inFlightClaims) </del> return inFlightClaims }

Discussion:
pull-kubernetes-unit dynamicresources unknown multiple failures in tests as seen in n/a /sig scheduling
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
probably cc
/assign
DeepCopy missing here:
Change:
func (m *Master) InstallSwaggerAPI() { // Enable swagger UI and discovery API swaggerConfig := swagger.Config{ <del> WebServices: m.handlerContainer.RegisteredWebServices(), </del> <ins> WebServicesUrl: m.readWriteServer, WebServices:    m.handlerContainer.RegisteredWebServices(), </ins> // TODO: Parameterize the path? ApiPath:         "/swaggerapi/", SwaggerPath:     "/swaggerui/",

Discussion:
It's 127.0.0.1 regardless of the public address. Looks like we need to set WebServicesUrl: where we create the endpoint: using PublicAddress: and ReadWritePort:
/cc
In particular: , bgrant0607 wrote:
Change:
}, ImagePullPolicy: "IfNotPresent", }, <ins> { Name:  "same-host-port-different-protocol", Image: "image", Ports: []api.ContainerPort{ {ContainerPort: 80, HostPort: 80, Protocol: "TCP"}, {ContainerPort: 80, HostPort: 80, Protocol: "UDP"}, }, ImagePullPolicy: "IfNotPresent", }, </ins> {Name: "abc-1234", Image: "image", ImagePullPolicy: "IfNotPresent", SecurityContext: fakeValidSecurityContext(true)}, } if errs := validateContainers(successCase, volumes); len(errs) != 0 {

Discussion:
Pods which use to bind both TCP and UDP sockets to the same port number are rejected with the error: An example pod follows.
Looks like we don't check protocol
The issue was discussed before in , which was closed due to it being low priority.
Hmm, that's 2 pods and the scheduler, this is 2 containers in the same pod and validation at create time. Maybe we should just be more clear about where we stand with hostPort.
Posting here what I posted in the other bug: This can't be worked around when running NFS from a pod. Linux does not allow the NFS port (2049) to be changed, and the Portmap port (111) also cannot be changed. Additionally, you can't separate the UDP from the TCP ports.
Why does NFS need host ports? , Russell Harmon wrote:
Fix is in , Tim Hockin wrote:
Change:
"k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/runtime/schema" </ins> "k8s.io/kube-openapi/pkg/util/proto" "sigs.k8s.io/structured-merge-diff/typed" "sigs.k8s.io/structured-merge-diff/value"

Discussion:
Found by failing TestApplyConvertsManagedFieldsVersion test in () It seems that conversion depends on schema info that is collected from served API versions only. However, managedFields stores data in etcd from REST versions served in previous releases which may no longer be served. That means that we have to be able to deal with managedFields persisted via API calls to versions that are no longer served, but which we still have and understand conversions for. /cc /sig api-machinery /wg apply /priority important-soon
This may be fixed in a more recent version of structured-merge-diff. I'll look into it
/assign
At one point we were using the types registered to the scheme to generate the openAPI definitions used by apply, but we switched to using the installed endpoints instead, because it was less invasive (We needed to expose which types are convertible to which other types, and also a way to skip generating openAPI for internal types). We might want to revisit the first approach, given this use case.
Change:
if size < 0 { return nil, fmt.Errorf("watch cache size cannot be negative: %s", c) } watchCacheSizes[schema.ParseGroupResource(tokens[0])] = size } return watchCacheSizes, nil

Discussion:
Currently we signal undecorated storage by simply affecting the undecoratedStorage to the decorator. This is a blocker for kubernetes/enhancements as we need to enable watch cache for events (which currently hardcoded and not configurable) cc /assign /sig api-machinery
Change:
klog.V(5).Infof("deletePod %s/%s, no node", pod.Namespace, pod.Name) return } klog.V(4).Infof("deletePod %s/%s for node %s", pod.Namespace, pod.Name, pod.Spec.NodeName) <ins> startTime := time.Now() </ins> g.graph.DeletePod(pod.Name, pod.Namespace) <ins> klog.V(5).Infof("deletePod %s/%s for node %s completed in %v", pod.Namespace, pod.Name, pod.Spec.NodeName, time.Since(startTime)) </ins> } func (g *graphPopulator) addPV(obj interface{}) {

Discussion:
Log statements and metrics indicating when the node authorizer graph has be updated for a pod. There is already a log statement for when the graph starts an update, but this is before the graph lock is obtained and doesn't tell when the graph update is completed. We are seeing node authorizer failures which prevent pods from starting for extended periods of time. It is believed that this is caused by a race between: the node authorizer graph being updated the node requesting the secret It is important to have logging that indicates when the graph finished updating in order to reflect lock contention on the graph.
/sig auth
/triage accepted Seems like a reasonable feature request.
Hi, folks I would like to work on this. /assign
Hi Fixed this issue here PTAL!
Change:
timer.Reset(i.timeout) } case <-expired: <del> for _, stream := range i.conn.streams { stream.Reset() } i.conn.Close() break Loop </del> <ins> i.conn.streamCond.L.Lock() streams := i.conn.streams i.conn.streams = make(map[spdy.StreamId]*Stream) i.conn.streamCond.Broadcast() i.conn.streamCond.L.Unlock() go func() { for _, stream := range streams { stream.resetStream() } i.conn.Close() }() </ins> case <-i.conn.closeChan: if timer != nil { timer.Stop()

Discussion:
Hit this while :
cc/ Andy can you take a look at this failure?
looking now
Working with on a fix
Proposed fix:
Change:
} return a.Amount.Cmp(b.Amount) == 0 }, <ins> func(a, b util.Time) bool { return a.Unix() == b.Unix() }, </ins> ) var standardResources = util.NewStringSet(

Discussion:
This tree has a commit that demonstrates two obviously different objects that should not pass the semantic DeepEqual but do.
What shall we do with this issue for triage? Labels? Priority?
P2 for when he returns , Satnam Singh wrote:
OK I am now sufficiently worried about this. Fixes incoming.
Change:
} return false } <del> t.checkDNSRecord(federationDNS, predicate, wait.ForeverTestTimeout) </del> <ins> t.checkDNSRecordFrom(federationDNS, predicate, "cluster-dns", wait.ForeverTestTimeout) </ins> } } } func (t *dnsFederationsConfigMapTest) setConfigMap(cm *v1.ConfigMap, fedMap map[string]string, isValid bool) { <ins> t.fedMap = nil </ins> if isValid { t.fedMap = fedMap }

Discussion:
/kind failing-test /priority critical-urgent /sig network /milestone v1.12 /cc
ping
Also failures on
TLS errors connection refused 503 service unavailable especially around metrics and healthz in ways that make me suspect things didn't start correctly. Or perhaps API mismatch? /cc 've looked at some similar failures in the past. Any chance you might give a look over this and ?
in both and here looks like api mismatch?
Test output shows no DNS server can be reached, but logs say coredns pods are running (https://k8s-): cc
The CoreDNS configmap is incorrectly configured and hence the test fails. I'm working on the fix.
/assign
, , Does it make sense to keep that e2e test ?, knowing that this test is specific for "Federation" and that federation has now merged into "multicluster" and removed all e2e tests about "Federation + Serial" (formerly "ci-federation-e2e-gce-serial") : can you say if that use case is still supported in kubernetes v1.12 ?
I can say that Federation v1 has not been exercised since v1.10. I think a good question for the Federation v2 folks is not only whether they still need the tests, but also whether they need the configmap support specific to what Federation v1 used -- I'll defer to
If ya'll decide the use case is no longer valid, please open an issue / remove the test once 1.13 release opens.
tests are failing
/reopen /cc
Reopening this issue. <detailsIn response to : /reopen /cc 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
More failures:
Looks like this is failing since Kube-dns is now enabled.
Since we'd previously discussed this not being a relevant test case, and it seems less appropriate even if it's this coupled to the dns implementation and we've got the kube-dns to coredns transition happening in the next release most likely....Can we just disable/remove the test?
Opened to disable this test.
Thank you!
Change:
if [[ -n "${VOLUME_PLUGIN_DIR:-}" ]]; then params+=" --flex-volume-plugin-dir=${VOLUME_PLUGIN_DIR}" fi <ins> if [[ -n "${CLUSTER_SIGNING_DURATION:-}" ]]; then params+=" --experimental-cluster-signing-duration=$CLUSTER_SIGNING_DURATION" fi </ins> local -r kube_rc_docker_tag=$(cat /home/kubernetes/kube-docker-files/kube-controller-manager.docker_tag) local container_env="" if [[ -n "${ENABLE_CACHE_MUTATION_DETECTOR:-}" ]]; then

Discussion:
/kind e2e-test-failure GCE serial and GCI GCE serial started failing last evening https://k8s- https://k8s-
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/testing: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. 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
https://k8s- is still green, I would suspect something ~last Friday afternoon gets merged
Here is what I found, after a while, the node lost their authorization to connect to API server. I believe this has the same root cause as
I am going to revert offending pr () to see if it helps. EDIT: Looks like is in the process of reverting it:

ref Test is failing on GCE slow and GCI GCE slow: https://k8s- https://k8s- Example failure https://k8s-
The test nodes appear to lose their authorization for accessing resources about 26m into the test. One of many "Unauthorized" errors starting at
, does this ring any bells ?
The certificates are all expiring:
I believe this is the regression introduced cc/ Can you guys take a look?
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. kind: 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
thanks. I'll open a PR to revert that.
Revert here
Change:
<del> apiVersion: apps/v1beta2 </del> <ins> apiVersion: apps/v1 </ins> kind: StatefulSet metadata: name: web

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: The following issues are observed while running this e2e test case for vSphere CSI Migration feature validation. Issue-1 - test failed with Unexpected error: This is happening because YAML is using version. Issue-2 - After upgrading from . Test executed successfully but reported failure in the cleanup stage. when is called in DeleteAllStatefulSets, it does not find statefulset. moving call to in the defer block helps avoid printing this message. There may be a race between namespace deletion and after each execution. I am not familiar with recent e2e framework changes. What you expected to happen: Test should pass. How to reproduce it (as minimally and precisely as possible): execute using Kubernetes master branch builds. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere Cloud Provider
/sig testing /sig storage
/remove-sig testing The framework and CI are SIG testing. SIG storage owns their tests.
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
Change:
} func runCompletionZsh(out io.Writer, boilerPlate string, kubectl *cobra.Command) error { <del> zshHead := "#compdef kubectlncompdef _kubectl kubectln" </del> <ins> zshHead := fmt.Sprintf("#compdef %[1]sncompdef _%[1]s %[1]sn", kubectl.Name()) </ins> out.Write([]byte(zshHead)) if len(boilerPlate) == 0 {

Discussion:
The command is generating a couple of hardcoded which seemingly causes any commands wrapping this package downstream to break. In this example, the OpenShift client: This should generate the compdef based on the rather than forcing kubectl, for example with : It could be even cleaner with the compdef function removed and the extraneous tag repeated below the boilerplate: compdef command command boilerplate stuff body Such as: generates the same first two lines as There is also a related downstream issue: Ideally, this might get resolved here at the source as it might help anyone else wrapping these commands downstream. I also have a possible solution which involves changing the hardcoded values from to use the which fixes the downstream without changing anything upstream. <details</details<detailsDownstream client-side issue unrelated to a specific cloud provider. </details<details</details<details- Latest </br- OpenShift client = 4.9 </detailsNo response <details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
Change:
cmd.Flags().BoolVar(&options.DeleteAll, "all", options.DeleteAll, "Delete all resources, including uninitialized ones, in the namespace of the specified resource types.") cmd.Flags().BoolVar(&options.IgnoreNotFound, "ignore-not-found", options.IgnoreNotFound, "Treat "resource not found" as a successful delete. Defaults to "true" when --all is specified.") cmd.Flags().BoolVar(&options.Cascade, "cascade", options.Cascade, "If true, cascade the deletion of the resources managed by this resource (e.g. Pods created by a ReplicationController).  Default true.") <del> cmd.Flags().IntVar(&options.GracePeriod, "grace-period", options.GracePeriod, "Period of time in seconds given to the resource to terminate gracefully. Ignored if negative.") </del> <ins> cmd.Flags().IntVar(&options.GracePeriod, "grace-period", options.GracePeriod, "Period of time in seconds given to the resource to terminate gracefully. Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true (force deletion).") </ins> cmd.Flags().BoolVar(&options.DeleteNow, "now", options.DeleteNow, "If true, resources are signaled for immediate shutdown (same as --grace-period=1).") <del> cmd.Flags().BoolVar(&options.ForceDeletion, "force", options.ForceDeletion, "Immediate deletion of some resources may result in inconsistency or data loss and requires confirmation.") </del> <ins> cmd.Flags().BoolVar(&options.ForceDeletion, "force", options.ForceDeletion, "Only used when grace-period=0. If true, immediately remove resources from API and bypass graceful deletion. Note that immediate deletion of some resources may result in inconsistency or data loss and requires confirmation.") </ins> cmd.Flags().DurationVar(&options.Timeout, "timeout", options.Timeout, "The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object") cmdutil.AddOutputVarFlagsForMutation(cmd, &options.Output) cmdutil.AddInclude3rdPartyVarFlags(cmd, &options.Include3rdParty)

Discussion:
IMO it's surprising that does not force delete a resource. only takes effect when . The description of reads this: We should make it more clear what does and even print warnings when is specified without .
Changing the meaning of force to actually break cluster consistency be default could lead to data loss, which is why we haven’t changed it so far. agree we should print more info and clarfiy
Change:
# function kube::util::ensure-bash-version { # shellcheck disable=SC2004 <del> if ((${BASH_VERSINFO[0]}<5)); then echo "ERROR: This script requires a minimum bash version of 5.0" </del> <ins> if ((${BASH_VERSINFO[0]}<4)) || ( ((${BASH_VERSINFO[0]}==4)) && ((${BASH_VERSINFO[1]}<2)) ); then echo "ERROR: This script requires a minimum bash version of 4.2, but got version of ${BASH_VERSINFO[0]}.${BASH_VERSINFO[1]}" </ins> exit 1 fi }

Discussion:
What happened: On our Ubuntu 18.04 build machines(with bash 4.2), build failed with error: What you expected to happen: build succeeds without error. How to reproduce it (as minimally and precisely as possible): On a Ubuntu 18.04 machine with the latest bash installed from official repo, do make by Anything else we need to know?: This is related to PR
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig release
version 5 was forced here:
The support of test was in bash version 4.2. It would be better to limit the mimimum verison to 4.2+, since some people, including us, are using Ubuntu 18.04 with bash 4.x to do the build. Thanks.
Or better yet use another method like; BTW I removed this flawed test and build happily on Ubuntu 18 without any problem.
i do not disagree with that. looks like the right people are already assigned to your PR.
This is breaking downstream CIs, I´ve found this today in one of thems is not possible to relax this to 4.2? /sig-testing
Better to not use the "test -v" options at all since it is completely unnecessary, see It is not very user-friendly to enforce a global upgrade when there is absolutely no need. Ubuntu 18 has 4.2 but others may not.
:)
Heh , that was fast :)
this is actually not an equivilant check, but it is possible to implement one without using -v I left a comment on the original PR with how to do this.
see: reports if the variable was set_, which includes In this case I do think the intent was to check if the variable was set or not. It's still possible to do without but it's a big more ... arcane.

Kubernetes has long required a reasonably up to date bash FWIW, on macOS you cannot use the system bash, and for a while you couldn't use debian stable's bash to build kubernetes as it had an array bug (4.0 IIRC). I don't think we have a clear support policy here, and I think this is a good reason to reconsider writing large volumes of bash
Change:
loadBalancer LoadBalancer mu           sync.Mutex // protects serviceMap serviceMap   map[string]*serviceInfo <ins> address      string </ins> } <del> // NewProxier returns a new Proxier given a LoadBalancer. func NewProxier(loadBalancer LoadBalancer) *Proxier { </del> <ins> // NewProxier returns a new Proxier given a LoadBalancer and an // address on which to listen func NewProxier(loadBalancer LoadBalancer, address string) *Proxier { </ins> return &Proxier{ loadBalancer: loadBalancer, serviceMap:   make(map[string]*serviceInfo), <ins> address:      address, </ins> } }

Discussion:
kube-proxy listens on all ports, but should be configurable. create a flag to specify which interface to listen on. Thanks for finding this bug.
For context, some providers apparently do external IPs by having a whole interface that gets 1:1 NAT without any firewalling. We do not want service ports on those interfaces. , Brian Ketelsen wrote:
Change:
case svc.Interrogate: s <- c.CurrentStatus case svc.Stop, svc.Shutdown: <del> s <- svc.Status{State: svc.Stopped} // TODO: Stop the kubelet gracefully instead of killing the process os.Exit(0) </del> <ins> klog.Infof("Service stopping") // We need to translate this request into a signal that can be handled by the the signal handler // handling shutdowns normally (currently apiserver/pkg/server/signal.go). // If we do not do this, our main threads won't be notified of the upcoming shutdown. // Since Windows services do not use any console, we cannot simply generate a CTRL_BREAK_EVENT // but need a dedicated notification mechanism. graceful := server.RequestShutdown() // Free up the control handler and let us terminate as gracefully as possible. // If that takes too long, the service controller will kill the remaining threads. // As per https://docs.microsoft.com/en-us/windows/desktop/services/service-control-handler-function s <- svc.Status{State: svc.StopPending} // If we cannot exit gracefully, we really only can exit our process, so atleast the // service manager will think that we gracefully exited. At the time of writing this comment this is // needed for applications that do not use signals (e.g. kube-proxy) if !graceful { go func() { // Ensure the SCM was notified (The operation above (send to s) was received and communicated to the // service control manager - so it doesn't look like the service crashes) time.Sleep(1 * time.Second) os.Exit(0) }() } break Loop </ins> } } }

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!--What happened: I configured Kubelet to run as a service on Windows, with a setting to restart on failure (). I noticed that it restarts even when I explicitly stop the service with , even though the documentation states the following (I left it at , the default): What you expected to happen: I expected the Kubelet to only restart when killed unexpectedly, per above docs. Anything else we need to know?: I think the problem might be due to this part of our service control integration, but I'm not really sure: It looks like we send and then , but the official golang example sends and just returns without exiting. (). Is this difference meaningful? Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Windows /cc /sig node /sig windows
The same should apply to kube-proxy as well.
i believe you implemented this functionality. can you please take a look? cc: