jiebi/CodeConvo huggingface dataset:
Change:
# If the URL is for GCS and the node has dev storage scope, add the # service account OAuth2 bearer token to the request headers. # https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#applications <del> if (($Url -match "^https://storage`.googleapis`.com.*") -And $(Check-StorageScope)) { </del> <ins> if (($Url -match "^https://storage`.googleapis`.com.*") -and $(Check-StorageScope)) { </ins> $httpClient.DefaultRequestHeaders.Add("Authorization", "Bearer $(Get-Credentials)") } # Attempt to download the file $httpResponseMessage = $httpClient.GetAsync([System.Uri]::new($Url)) $httpResponseMessage.Wait() <del> if (-Not $httpResponseMessage.IsCanceled) { </del> <ins> if (-not $httpResponseMessage.IsCanceled) { </ins> # Check if the request was successful. # # DO NOT replace with EnsureSuccessStatusCode(), it prints the # OAuth2 bearer token. <del> if (-Not $httpResponseMessage.Result.IsSuccessStatusCode) { </del> <ins> if (-not $httpResponseMessage.Result.IsSuccessStatusCode) { </ins> $statusCode = $httpResponseMessage.Result.StatusCode throw "Downloading ${Url} returned status code ${statusCode}, retrying." }

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: GCE Windows cluster bring up fails on some versions of Windows. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This is a regression caused by 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: /assign jeremyje /sig windows
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
/assign pjh
/unassign pjh
Change:
"kubeproxy_iptables_localhost_nodeports_accepted_packets_total", "Number of packets accepted on nodeports of loopback interface", nil, nil, metrics.ALPHA, "") <del> LocalhostNodePortAcceptedNFAcctCounter     = "localhost_nps_accepted_pkts" localhostNodePortsAcceptedMetricsCollector = newNFAcctMetricCollector(LocalhostNodePortAcceptedNFAcctCounter, localhostNodePortsAcceptedPacketsDescription) </del> <ins> LocalhostNodePortAcceptedNFAcctCounter = "localhost_nps_accepted_pkts" </ins> ) var registerMetricsOnce sync.Once

Discussion:
The module now logs two errors during module initialization. Simply loading the module will cause two errors to be printed to stderr if the code is not run as root, or is run on a node without nfacct support. This is due to being used when creating Prometheus metrics during module variable initialization, which calls if the nfacct client cannot be initialized. This regression was introduced by: K3s ships all the various Kubernetes components bundled in a single multicall binary, which means that our now logs these errors when it is run as a non-root user. No error logs on module init cc <details</detailsn/a n/a n/a n/a n/a area/proxy sig/network
/sig network
/triage accepted /assign
I was about to fix this, this initialization happens in the unit tests as well .
thanks for the quick response! Do you think you'll have a patch that we could use temporarily for k3s until v1.31.1 is out? We were considering just removing the call for our initial 1.31 release, unless you have a better suggestion.
can you confirm is fine?
Change:
PREPULL_E2E_IMAGES="${PREPULL_E2E_IMAGES:-true}" # Evict pods whenever compute resource availability on the nodes gets below a threshold. <del> EVICTION_HARD="${EVICTION_HARD:-memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%}" </del> <ins> EVICTION_HARD="${EVICTION_HARD:-memory.available<250Mi,nodefs.available<10%,nodefs.inodesFree<5%}" </ins> # Optional: custom scheduling algorithm SCHEDULING_ALGORITHM_PROVIDER="${SCHEDULING_ALGORITHM_PROVIDER:-}"

Discussion:
Clusters on GCE set eviction thresholds for disk and inodes. Given that reclaiming disk and inodes is slow, we should set minimum reclaim thresholds too. Essentially, set . I assume percentages are supported for min reclaims too. Do we have system tests for min reclaim? cc
I just took a glance at the parser for eviction minimum reclaim, it doesn't look like it tries to parse percentages. can you confirm?
did percentage support, and we did not extend it to min reclaim. It's a good idea to do though. On Tuesday, September 13, 2016, Michael Taufen wrote:
Hmm.. In that case for v1.4, can we set the min reclaim to ? What values are you planning on using in Open Shift ?
This should fix this issue to avoid node condition being flip-flop, but I think it shouldn't block 1.4 release.
More than flip-flop, it will help the node recover from disk pressure condition sooner. , Dawn Chen wrote:
/cc
Spawned to add percentage support for min reclaim. I will follow up with our proposed default for nodefs later
This needs to be triaged as a release-blocker or not for 1.5
can you check if we have set default values for disk and inode based evictions in kubelet? If not, we should add them.
I believe our current default value for the --eviction-hard flag is "memory.available<100Mi", found in Our tests currently run using: "memory.available<250Mi,nodefs.available<10%,nodefs.inodesFree<5%", found in What should I change the default to? This issue is about minimum reclaim, should I look into changing those flags as well?
It doesn't appear that we have defaults for minimum reclaim, should I add minimum reclaim for memory in addition to disk and inodes?
I think GCE defaults do not apply globally, we should change what GCE does, and handle setting global defaults in 1.6.
the global defaults are expected to be based on our OSS tests. Our original plan was to roll out disk eviction by default in v1.5. This is not specific to GCE.
Can you make a call on if this is a blocker or non-blocker for 1.5 by EOD Friday please
Change:
// TestRegions does basic checking of region verification / addition func TestRegions(t *testing.T) { <del> RecognizeWellKnownRegions() </del> <ins> recognizeWellKnownRegions() </ins> tests := []struct { Add            string

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: From /kind cleanup What happened: What you expected to happen: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cloud-provider /assign
Change:
func TestAnonymous(t *testing.T) { var a authenticator.Request = NewAuthenticator() <del> r, ok, err := a.AuthenticateRequest(nil) </del> <ins> r, ok, err := a.AuthenticateRequest(&http.Request{}) </ins> if err != nil { t.Fatalf("Unexpected error %v", err) }

Discussion:
Semantics are going to vary. We need to cross off these authenticators: [x] if ctx has an audience limitation, verify the token audience and echo in the response [x] take implicit audiences at WebhookTokenAuthenticator construction time if ctx is audience-limited, add into the tokenreview object if the tokenreview returns with an audience set that matches the ctx, copy into the response and return success if the tokenreview returns without an audience set, ensure the ctx audiences intersect with the implicit audiences taken at WebhookTokenAuthenticator construction time, and pick one to add into the response [x] echo audience in response if present in ctx [x] echo audience in response if present in ctx [x] check that the the order of (audience in the context) ∩ ( (implicit api audiences) ∪ (clientids) ) 0 Take implicit audiences at Authenticator construction time, and if ctx is audience-limited, ensure it intersects with the implicit audiences, and echo an audience in the response. [x] [x] [x] [x] [x] [x] Do nothing? [x] [x] [x] [x] [x] [x] [x] note: we already keyed the cache with the audience. [x]
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
/close
Closing this issue. <detailsIn response to : /close 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:
gcloud compute firewall-rules delete   --project "${PROJECT}"  --quiet  <del> "${MASTER_NAME}-https" || true </del> <ins> "${MASTER_NAME}-https" </ins> # Delete firewall rule for minions. gcloud compute firewall-rules delete   --project "${PROJECT}"  --quiet  <del> "${MINION_TAG}-all" || true </del> <ins> "${MINION_TAG}-all" </ins> # Delete routes. local -a routes

Discussion:
'kubernetes-soak-weekly-deploy' sometimes fails to deploy because the clean-up cluster step fails to delete the template: Then the subsequent cluster step fails to create the template, because it already exists: It keeps retrying and failing, because the template already exists, until it times out and the deployment fails. Suggested fixes: Cluster down should try harder to delete the template (maybe wait/retry). Cluster up should recognize that the template exists, and try to delete/recreate, or just re-use the existing.
Looks like ran in to this on Monday, May 11, 2015 around 1:00 PM PST. I'll assign this to my self and take a crack at fixing it.
This is causing most of our e2e tests to fail in continuous integration as well as users private e2e test clusters. Bumping to priority/p0 and v1.0 milestone. Saad thinks he's figured it out, and is working on a fix as we speak.
In essence... Saad: "I think what's happening is the previous clean up step to delete the managed instance group happens asynchronously, therefore there is a race condition to delete the template. Working on a fix".
Change:
DNSDomain      string } <ins> // NewWindowsModel returns a model specific to windows testing. func NewWindowsModel(namespaces []string, podNames []string, ports []int32, dnsDomain string) *Model { return NewModel(namespaces, podNames, ports, []v1.Protocol{v1.ProtocolTCP}, dnsDomain) } // GetProbeTimeoutSeconds returns a timeout for how long the probe should work before failing a check, and takes windows heuristics into account, where requests can take longer sometimes. func (m *Model) GetProbeTimeoutSeconds() int { timeoutSeconds := 1 if framework.NodeOSDistroIs("windows") { timeoutSeconds = 3 } return timeoutSeconds } // GetWorkers returns the number of workers suggested to run when testing, taking windows heuristics into account, where parallel probing is flakier. func (m *Model) GetWorkers() int { numberOfWorkers := 3 if framework.NodeOSDistroIs("windows") { numberOfWorkers = 1 // See https://github.com/kubernetes/kubernetes/pull/97690 } return numberOfWorkers } </ins> // NewModel instantiates a model based on: // - namespaces // - pods

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Ive done preliminary testing with on calico powered clusters on some windows variants and found that the probing seems to work. Can we add wrapper to netpol suite so that we can run it on windows clusters ? Why is this needed: We need this because otherwise, CNIs such as EKS will give us This error is caused when, for example, pods that are landing on a windows node havent defined their target platform. Somehow i guess pods which are landing on linux nodes dont have this issue. Its also needed for the obvious reason that we probably want separate linux and windows test suites for policies, in general, even though we expect the logic to be identical (modulo hostports , which we dont currently test)
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 windows
/assign
grepping around, I can't figure out where those are supposed to go. Can you give me pointers?
(resolved in slack, matts digging into this)
ok, these are running now on eks, lots of failures. will dig
/assign
the netpol are not being applied for the ns: Instead of failing because should not be able to access , the connection succeeds.
Change:
} return obj, nil } creating = false <ins> newVersion, err := e.Helper.ResourceVersioner.ResourceVersion(obj) if err != nil { return nil, err } if newVersion != version { // TODO: return the most recent version to a client? return nil, kubeerr.NewConflict(e.EndpointName, name, fmt.Errorf("the resource was updated to %d", version)) } </ins> if err := rest.BeforeUpdate(e.UpdateStrategy, ctx, obj, existing); err != nil { return nil, err } <del> // TODO: expose TTL </del> return obj, nil }) if err != nil { if creating { err = etcderr.InterpretCreateError(err, e.EndpointName, name)

Discussion:
The use of AtomicUpdate by genericetcd doesn't handle conflicting writes by rejecting that to a user. It should. Eventually, we may want to hide write conflicts to /pods when status has changed, and to spec when /pods/status changes, but that requires us to have two version counters and that's not worth the effort. Fix incoming.
Also we need a unit/integration test for this.
Change:
) var onlyOneSignalHandler = make(chan struct{}) <ins> var shutdownHandler chan os.Signal </ins> // SetupSignalHandler registered for SIGTERM and SIGINT. A stop channel is returned // which is closed on one of these signals. If a second signal is caught, the program

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:
Change:
<del> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package service import ( "context" "encoding/json" "fmt" v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/strategicpatch" v1core "k8s.io/client-go/kubernetes/typed/core/v1" ) // patch patches service's Status or ObjectMeta given the origin and // updated ones. Change to spec will be ignored. func patch(c v1core.CoreV1Interface, oldSvc *v1.Service, newSvc *v1.Service) (*v1.Service, error) { // Reset spec to make sure only patch for Status or ObjectMeta. newSvc.Spec = oldSvc.Spec patchBytes, err := getPatchBytes(oldSvc, newSvc) if err != nil { return nil, err } return c.Services(oldSvc.Namespace).Patch(context.TODO(), oldSvc.Name, types.StrategicMergePatchType, patchBytes, metav1.PatchOptions{}, "status") } func getPatchBytes(oldSvc *v1.Service, newSvc *v1.Service) ([]byte, error) { oldData, err := json.Marshal(oldSvc) if err != nil { return nil, fmt.Errorf("failed to Marshal oldData for svc %s/%s: %v", oldSvc.Namespace, oldSvc.Name, err) } newData, err := json.Marshal(newSvc) if err != nil { return nil, fmt.Errorf("failed to Marshal newData for svc %s/%s: %v", newSvc.Namespace, newSvc.Name, err) } patchBytes, err := strategicpatch.CreateTwoWayMergePatch(oldData, newData, v1.Service{}) if err != nil { return nil, fmt.Errorf("failed to CreateTwoWayMergePatch for svc %s/%s: %v", oldSvc.Namespace, oldSvc.Name, err) } return patchBytes, nil } </del>

Discussion:
PR service patch methods to Once there is a release with that PR included, the code in service-controller and legacy-cloud-providers/gce can be updated to use those. /area platform/gce /assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
Created a PR to use these new functions in Service-controllers.
Change:
if mapping.Kind != "ReplicationController" { usageError(cmd, "%s does not specify a valid ReplicationController", filename) } <ins> if oldName == newName { usageError(cmd, "%s cannot have the same name as the existing ReplicationController %s", filename, oldName) } </ins> err = CompareNamespaceFromFile(cmd, namespace) checkErr(err)

Discussion:
I believe the problem is that requires a schema of but that Kubernetes does not have the ability to handle that schema yet. I just want to confirm this is true however. So with a schema like: It fails when used like so: If I try a schema that looks like: then the error is: The error generation comes from: Am I correct that it is impossible to use the command against ?
For clarity's sake here is my version info:
Rename cloud-delivery-test to cloud-delivery-test2 or something else. kubectl rollingupdate doesn't update an existing ReplicationController, it replaces it with a new one.
Doc:
Looking into this now. I am able to run kubectl rollingupdate against a 0.8.0 cluster using a v1beta1 schema. So it may just be broken for v1beta2/v1beta3.
Also, v1beta3 isn't enabled by default. Here's a message about how to enable it: !topic/kubernetes-dev/ZqbLnrg5--8 It's user error. I think we need a clearer error message when the 2 replication controllers have the same name.
good catch. can you confirm the command works with a distinctly named controller?
I see guys, ok, thank-you. Until patch I don't think this was made clear anywhere : ) I will try this out tomorrow and confirm but surely it will work. Thanks again.
Thanks It works differently from kubecfg rollingupdate, so I'm sure other people will encounter the same issue.
Change:
pod := createDNSPod(f.Namespace.Name, wheezyProbeCmd, jessieProbeCmd, dnsTestPodHostName, dnsTestServiceName) pod.Spec.DNSPolicy = v1.DNSClusterFirst pod.Spec.DNSConfig = &v1.PodDNSConfig{ <del> Nameservers: []string{kubednsIP}, Searches:    testSearchPaths, </del> <ins> Searches: testSearchPaths, </ins> Options: []v1.PodDNSConfigOption{ { Name:  "ndots",

Discussion:
an E2E test that assumes that a service named "kube-dns" exists in the "kube-system" namespace. This is a kubeadm-ism, and the test fails if the cluster DNS is not configured the way kubeadm configures it. Although this E2E test isn't a conformance test, making it functional on non-kubeadm clusters would increase its utility for distributors that may wish to run this E2E test as a conformance test. [sig-network] DNS HostNetwork should resolve DNS of partial qualified names for services on hostNetwork pods with dnsPolicy: ClusterFirstWithHostNet Since we ran it on an OpenShift cluster. No response The test makes assumptions about how the cluster DNS is configured. The test uses (not ), so it does not need to specify , as far as I can tell. Omitting obviates the need to look up the service. I believe that the service lookup was left in as an oversight during the development of the test when it was changed from specifying "None" to specifying "ClusterFirst": Cc: /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
responded on the pr.
It seems kubeadm inherited the status-quo, I can't find any place that mandates the Service name for DNS Asking for double checking, but the docs seems to mention that this is more a recommendation than a preescription If it seems that the test can be done in a more portable way we should do it