jiebi/CodeConvo huggingface dataset:
Change:
etpLocalNodePredicates []NodeConditionPredicate = []NodeConditionPredicate{ nodeIncludedPredicate, nodeUnTaintedPredicate, <ins> nodeReadyPredicate, </ins> } stableNodeSetPredicates []NodeConditionPredicate = []NodeConditionPredicate{ nodeNotDeletedPredicate,

Discussion:
In 1.26 the service controller in the Kubernetes cloud controller manage (KCCM) introduced a new mechanism for syncing load balancers based on predicates. The predicates applied will depend on "service classes", specifically if it's or , see: This implementation is not well suited for internal GCP load balancers which use InstanceGroups. from Google, feel free to correct me: any cluster has all nodes grouped together into an instance group. Service of have individual GCP load balancers, but these load balancers end up referencing the same instance group (which is the cluster's instance group). This means that the inclusion/exclusion predicates for any service, will trickle down and impact the cluster's global instance group, thereby impacting other services which don't necessarily apply the same set of predicates. Ex: services exclude nodes, whereas do not. A Node going will therefore be removed from all backends for services, however on GCP with load balancer solution based on InstanceGroups: this means that the same node will be removed from all backends for services too. This is NOT a problem on = 1.27 using the feature , because all services on 1.27 using that feature gate will have the same set of predicates. Node updates requiring the removal of the instance from load balancers belonging to services of should not impact other services of . Bring up a cluster using "Internal load balancers" on GCP. Define two services, one being and the other . Have one node go . The instance corresponding to that Node might be removed from the InstanceGroup backend of the service. This will depend on the order the services are synced, if the service is synced last then the instance will be removed. This is actually not really that bad, because the only different predicate between both is the readiness condition - and a node should go back to if all is fine, and finally be included. But I wanted to raise this for issue for completeness sake so that it is known. <details</details<detailsGCP </details<details</details<details</details<details</details<details</details
/sig network /sig cloud-provider /cc
/triage accepted
Change:
logger:               logger, } <ins> if len(f.extenders) > 0 { // Extender doesn't support any kind of requeueing feature like EnqueueExtensions in the scheduling framework. // We register a defaultEnqueueExtension to framework.ExtenderName here. // And, in the scheduling cycle, when Extenders reject some Nodes and the pod ends up being unschedulable, // we put framework.ExtenderName to pInfo.UnschedulablePlugins. f.enqueueExtensions = []framework.EnqueueExtensions{&defaultEnqueueExtension{pluginName: framework.ExtenderName}} } </ins> if profile == nil { return f, nil }

Discussion:
When Extender filters out some Nodes, we don't set any unschedulable plugins at all. It means Extender is completely ignored during the requeueing process. So, what's happening is: If Extender filters out all Nodes during scheduling, this Pod is soon retried because this Pod doesn't have any plugin name in unschedulable plugins. If Extender filters out some Nodes during scheduling and plugins filter out all other Nodes, this Pod is retried based on plugins' QueueingHint. Even if any cluster events happen and it could change Extender's decision (but not any plugins' decision), this Pod won't be requeued to activeQ/backoffQ. The latter case is serious because it could make Pods being stuck in unschedulable pod pool in 5min. We should have a short-term solution for the latter case. We can requeue Pods, which were rejected by Extender, by any kind of cluster events because we cannot know which events make Pods schedulable. Eventually, this issue makes us wonder how Pods rejected by Extender should be requeued. We cannot implement QHint equivalent in Extenders because it'd be too slow to call Extender every time any cluster events happen. Probably, somehow implementing EventsToRegister equivalent in Extender? Use Extender which does something in Filter. No response master <detailsn/a </details<details</details<details</details<details</details<details</details
/assign
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 scheduling
/reopen We'll close it when all cherry-picks are done.
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
/close Cherry-picks are done.
Change:
} mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).RequireNamespace(). FilenameParam(filenames...).

Discussion:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR
Change:
# Install a few things needed by the verification tests. command -v etcd &>/dev/null || ./hack/install-etcd.sh <del> go get -u github.com/tools/godep </del> make verify

Discussion:
Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign
Change:
Skip ) <ins> const ( // MaxNodeScore is the maximum score a Score plugin is expected to return. MaxNodeScore int = schedulerapi.MaxPriority // MinNodeScore is the minimum score a Score plugin is expected to return. MinNodeScore int = 0 ) </ins> // Status indicates the result of running a plugin. It consists of a code and a // message. When the status code is not `Success`, the status message should // explain why.

Discussion:
What would you like to be : a default normalize score function in the scheduling framework. the plugin and log an error when the normalizing phase returns an invalid range of scores. Why is this needed: Per discussion in , we should enforce the range of score returned by the scoring plugin. /sig scheduling /priority important-soon /assign
Change:
kubetypes "k8s.io/kubernetes/pkg/kubelet/types" ) <ins> var ( defaultCFSQuota = metav1.Duration{Duration: 100 * time.Millisecond} ) </ins> // ValidateKubeletConfiguration validates `kc` and returns an error if it is invalid func ValidateKubeletConfiguration(kc *kubeletconfig.KubeletConfiguration) error { allErrors := []error{}

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 --See for more context. What happened: When you set and , you'd expect container cfs quota period to be . However, unless you also set in the feature flags, the quota value will be silently ignored. What you expected to happen: At least a warning be logged if the feature is not enabled but is set. 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:
/sig node /assign karan
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig node 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:
"testing" "k8s.io/kubernetes/pkg/api" <ins> "k8s.io/kubernetes/pkg/api/errors" </ins> "k8s.io/kubernetes/pkg/api/unversioned" "k8s.io/kubernetes/pkg/client/cache" "k8s.io/kubernetes/pkg/runtime"

Discussion:
We sorta fixed this-- now it's a real status error, but we left the status code 500, so it still produces stack traces and potentially confuses clients. we should figure out the correct status code.
I think there is a lot more going on related to this in . Clients are re-listing after the error but not rewatching.
/sub
It turned out this was not causing job e2e flakes. Just sending 500s that were confusing. So lowering priority.
How about a NewBadRequest error?
that certainly sounds like an improvement.
Change:
"description": "Selects the pods to which this NetworkPolicy object applies. The array of ingress rules is applied to any pods selected by this field. Multiple network policies can select the same set of pods. In this case, the ingress rules for each are combined additively. This field is NOT optional and follows standard label selector semantics. An empty podSelector matches all pods in this namespace." }, "policyTypes": { <del> "description": "List of rule types that the NetworkPolicy relates to. Valid options are Ingress, Egress, or Ingress,Egress. If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]). This field is beta-level in 1.8", </del> <ins> "description": "List of rule types that the NetworkPolicy relates to. Valid options are "Ingress", "Egress", or "Ingress,Egress". If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]). This field is beta-level in 1.8", </ins> "items": { "type": "string" },

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: bug report /kind bug What happened: I was reading the documentation for as defined What you expected to happen: To have clear documentation How to reproduce it (as minimally and precisely as possible): Read the following, as seen in the 1.12 docs: Anything else we need to know?: Nope Environment: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
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
Is it a case whereby only can be specified as , or only , or both (note the ) ? If that's the case, do you think the following would make it clearer?
It is confusing to have commas used for English grammar and array element delineation in the same sentence. What about simply this?
sounds like a great fix! Putting out a quick pr with this change now :)
Change:
cloudController, } <del> makeSymlinksFlag := false </del> cmd := &cobra.Command{ Use:   "hyperkube", Short: "Request a new project", Run: func(cmd *cobra.Command, args []string) { <del> if len(args) != 0 || !makeSymlinksFlag { </del> <ins> if len(args) != 0 { </ins> cmd.Help() os.Exit(1) } <del> if err := makeSymlinks(os.Args[0], commandFns); err != nil { fmt.Fprintf(os.Stderr, "%vn", err.Error()) } </del> }, } <del> cmd.Flags().BoolVar(&makeSymlinksFlag, "make-symlinks", makeSymlinksFlag, "create a symlink for each server in current directory") cmd.Flags().MarkHidden("make-symlinks") // hide this flag from appearing in servers' usage output cmd.Flags().MarkDeprecated("make-symlinks", "This feature will be removed in a later release.") </del> for i := range commandFns { cmd.AddCommand(commandFns[i]())

Discussion:
Follow up for the deprecation we did in 1.14:
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
/remove-lifecycle stale /good-first-issue
This request has been marked as suitable for new contributors. 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 : /remove-lifecycle stale /good-first-issue 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 release
I am willing to take this, if it is available :)
go for it. All you need to do is remove and associated code -
I ended up getting hit with the removal of the --make-symlinks flag. I looked at the threads linked to the original PR, but I did not find the actual reason behind the removal. Do you recall was the reason behind removing that capability?
the original request was from
Change:
import ( "context" <ins> "errors" </ins> "time" authentication "k8s.io/api/authentication/v1beta1"

Discussion:
What happened: I configured my API server with a Webhook token authentication server by way of the "authentication-token-webhook-config-file" command-line flag, and confirmed that the API server does pass bearer tokens through, issuing HTTP POST requests with a JSON-encoded body. When my Webhook server indicates authentication failure, it responds with HTTP status code 200 and a JSON-encoded in the body, this time with the object's "Error" field populated. Here's an example: When the API server receives this response, it refuses the original motivating request with an HTTP status code 401 response, but the API server writes the following into its log file: This use of this default error message is due to an omission in file , where , and . What you expected to happen: The API server should instead log a message that includes the value from . Per a brief discussion with , he agreed that the API server log message should include such an error message from the Webhook server, provided it's present and nonempty. How to reproduce it (as minimally and precisely as possible): Configure an API server to delegate to a Webhook token authentication server. Force that Webhook server to respond "successfully" with an HTTP 200 response, but with the "Authenticated" field set to false (or omitted) and with a particular error message in the "Error" field. Make an HTTP request of the API server with an HTTP "Authentication" header with a value starting with the string "Bearer " followed by at least one more character. Inspect the logs from the API server, looking for a message that begins with "Unable to authenticate the request due to an error." Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS EC2 OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: kubeadm_
/sig auth
/assign
Change:
fieldSelector: fields.ParseSelectorOrDie("status.phase=Pending"), expectMatch:   false, }, <ins> { in: &api.Pod{ Status: api.PodStatus{PodIP: "1.2.3.4"}, }, fieldSelector: fields.ParseSelectorOrDie("status.podIP=1.2.3.4"), expectMatch:   true, }, { in: &api.Pod{ Status: api.PodStatus{PodIP: "1.2.3.4"}, }, fieldSelector: fields.ParseSelectorOrDie("status.podIP=4.3.2.1"), expectMatch:   false, }, </ins> } for _, testCase := range testCases { m := MatchPod(labels.Everything(), testCase.fieldSelector)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I was attempting to filter pods with a using client-go selecting by its . I tried multiple variations until I ended up with . When filtering by , list of pod(s) came back empty even if pod with the IP we are filtering by was running. Then I tried reproducing it by calling the Kubernetes API directly which had the same result, list of pods came back empty: What you expected to happen: When passing the IP of the previously retrieved running Pod, I expected to get that Pod returned in the result. How to reproduce it (as minimally and precisely as possible): create a simple , get its IP (For example using - query Kubernetes: Anything else we need to know?: If I leave out the pod IP, I get all the pods back. I also tried using different formats when doing the curl, not one of them return anything. Also it seems like field is . As a side note I retrieved the URL which I used from debugging which calls client-go made. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: minikube version: v0.20.0 OS (e.g. from /etc/os-release): minikube OS Kernel (e.g. ): minikube kernel: Install tools: minikube Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
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
Currently the for only support , , , and . I've already submitted a PR in . PTAL.
cc
Change:
glog.Warningf("No API client: %v", err) } <ins> credentialprovider.SetPreferredDockercfgPath(*rootDirectory) </ins> kcfg := standalone.KubeletConfig{ Address:                 address, AllowPrivileged:         *allowPrivileged,

Discussion:
As per We should look for the .dockercfg in three places: ./.dockercfg, ~/.dockercfg, and $rootDir/.dockercfg
I'll tackle this.
Bunch of questions: we also add a flag that overrides the search mechanism suggested in this issue? Perhaps, ? to the user's homedir requires we use os/user [0] . The os/user package and cross-compiling don't play nice [1]. So, if we add to the search path, cross-compiled kubelet binaries will not actually be able to take advantage of it. Is this an issue? is the proper lookup order? I suggest: if provided, , , . walking through the lookups, do we stop at the first file that exists, or the first file that exists and is parsed as a valid ? [0] [1] /cc
I would absolutely love a --dockercfg option, and it would also be helpful if it logged which .dockercfg it ultimately used.
1) Seems like YAGNI to me 2) Is all of os/user broken? We will eventually want actual user support. I'm fine with dropping it for now. 3) I would say $rootDir/.dockercfg, ./.dockercfg (assuming we drop ~) 4) First successful parse sounds good to me. And can we NOT log errors if files don't exist :)
would it make sense to default to the kubelet config directory if provided rather than the working directory of the kubelet process? then no extra flag required.
What ever happened with this idea?
/cc
It never got high enough on my weekend TODO list :( I can keep telling myself that I need to do it, or we can find someone who has a bit more time than me.
I can probably get to this today.
Cool, thank you! , Mike Danese wrote: