jiebi/CodeConvo huggingface dataset:
Change:
// This flag enables or disables reconcile.  Is false by default, and thus enabled. DisableAttachDetachReconcilerSync bool // ReconcilerSyncLoopPeriod is the amount of time the reconciler sync states loop <del> // wait between successive executions. Is set to 5 sec by default. </del> <ins> // wait between successive executions. Is set to 60 sec by default. </ins> ReconcilerSyncLoopPeriod metav1.Duration }

Discussion:
// RecommendedDefaultAttachDetachControllerConfiguration defaults a pointer to a // AttachDetachControllerConfiguration struct. This will set the recommended default // values, but they may be subject to change between API versions. This function // is intentionally not registered in the scheme as a "normal" // function to allow consumers of this type to set whatever defaults for their // embedded configs. Forcing consumers to use these defaults would be problematic // as defaulting in the scheme is done as part of the conversion, and there would // be no easy way to opt-out. Instead, if you want to use this defaulting method // run it in your wrapper struct of this type in its method. func RecommendedDefaultAttachDetachControllerConfiguration(obj kubectrlmgrconfigv1alpha1.AttachDetachControllerConfiguration) { zero := metav1.Duration{} if obj.ReconcilerSyncLoopPeriod == zero { obj.ReconcilerSyncLoopPeriod = metav1.Duration{Duration: 60 time.Second} } } Default is set to 60 second. but, the comment said is 5 seconds. // AttachDetachControllerConfiguration contains elements describing AttachDetachController. type AttachDetachControllerConfiguration struct { // Reconciler runs a periodic loop to reconcile the desired state of the with // the actual state of the world by triggering attach detach operations. // This flag enables or disables reconcile. Is false by default, and thus enabled. DisableAttachDetachReconcilerSync bool // ReconcilerSyncLoopPeriod is the amount of time the reconciler sync states loop // wait between successive executions. Is set to 5 sec by default. ReconcilerSyncLoopPeriod metav1.Duration } default should change to 60 seconds. comment errror None <detailsall version until now </details<detailsnot relevent </details<details</details<details</details<details</details<details</details
/sig storage
/remove-kind api-change /kind cleanup
Those labels are not set on the issue: <detailsIn response to : /remove-kind api-change /kind cleanup 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
/triage accepted
Change:
event.InvolvedObject.FieldPath, event.Type, event.Reason, <del> event.Source, </del> <ins> formatEventSource(event.Source), </ins> event.Message, ); err != nil { return err

Discussion:
Greetings, currently, when doing then in column, the ui result is maybe can do something like this instead? remove then join it with
How about something like ?
Greetings, thanks for the interest, I thought I may throw hacking on it. btw, how about for ?
For we can just print since it's master's component.
Hi looks like there is the same issue reported on the OpenShift Origin github: It would make more sense to solve that upstream. Should we do something together to solve it?
There is a pull request for that:
Change:
cmd.Flags().DurationVar(&options.Timeout, "timeout", 0, "Only relevant during a force apply. The length of time to wait before giving up on a delete of the old resource, zero means determine a timeout from the size of the object. Any other values should contain a corresponding time unit (e.g. 1s, 2m, 3h).") cmdutil.AddValidateFlags(cmd) cmd.Flags().StringVarP(&options.Selector, "selector", "l", "", "Selector (label query) to filter on, supports '=', '==', and '!='.") <del> cmd.Flags().Bool("all", false, "[-all] to select all the specified resources.") </del> <ins> cmd.Flags().Bool("all", false, "select all resources in the namespace of the specified resource types.") </ins> cmd.Flags().StringArray("prune-whitelist", []string{}, "Overwrite the default whitelist with <group/version/kind> for --prune") cmdutil.AddDryRunFlag(cmd) cmdutil.AddPrinterFlags(cmd)

Discussion:
It actually doesn't support --all.
/assign
ohh, thanks, will make a pr to address that right now..
Change:
fmt.Fprintf(out, "Labels:t%sn", formatLabels(pod.Labels)) fmt.Fprintf(out, "Status:t%sn", string(pod.Status.Phase)) fmt.Fprintf(out, "Replication Controllers:t%sn", printReplicationControllersByLabels(rcs)) <ins> fmt.Fprintf(out, "Containers:n") describeContainers(pod.Status.ContainerStatuses, out) </ins> if len(pod.Status.Conditions) > 0 { fmt.Fprint(out, "Conditions:n  TypetStatusn") for _, c := range pod.Status.Conditions {

Discussion:
Kubectl describe pods id only has top level pod information, without any information related to containers. Taking kube-dns pod as an example, which has 3 containers specified: If a pod with RestartAlways policy, but all contianers are in crashloop, the user cannot interpret the true state based on above information. Proposed to include ContainerStatus here.
Why isn't this redundant with ?
is for kubectl get pods id.
Change:
return nil, []error{err} } if proxy != nil { <del> return []error{fmt.Errorf("Connection to %q uses proxy %q. If that is not intended, adjust your proxy settings", url, proxy)}, nil </del> <ins> return []error{fmt.Errorf("Connection to %q uses proxy %q. If that is not intended, adjust your proxy settings", u, proxy)}, nil </ins> } return nil, nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When setting an HTTPPROXY with an IPv6 address, the is no HTTPProxy warning. What you expected to happen: There should be a warning that a proxy is being used. How to reproduce it (as minimally and precisely as possible): Use Kubeadm with IPv6 addresses, and IPv6 proxy in the environment. Such as: NOPROXY=2001:420:2c50:2021::/64 Anything else we need to know?: Environment: Kubernetes version (use ): 9 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign rpothier
/sig cluster-lifecycle
/area ipv6
Change:
metadata, _ := meta.Accessor(info.Object) annotationMap := metadata.GetAnnotations() if _, ok := annotationMap[corev1.LastAppliedConfigAnnotation]; !ok { <del> fmt.Fprintf(o.ErrOut, warningNoLastAppliedConfigAnnotation, o.cmdBaseName) </del> <ins> fmt.Fprintf(o.ErrOut, warningNoLastAppliedConfigAnnotation, info.ObjectName(), corev1.LastAppliedConfigAnnotation, o.cmdBaseName) </ins> } patcher, err := newPatcher(o, info, helper)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : show a clearer message that better informs the user of a potential conflict between changes done declaratively vs imperatively on the same object, inform whether the changes have been applied, what may have been overwritten based on closed issue resource that has been directly modified imperatively (for example via a kubectl edit command) try to update it again declaratively (for example by kubectl apply -f yamlfile) The following confusing info message appears: "Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply... " Why is this needed: the error message is confusing. is it really an error message or just an informative message? Did the command successfully execute the changes being asked? Were the changes applied successfully? Was there anything overwritten? If changes were successfully applied, what is the reason for this message to show?
/sig cli
background references: and
/assign
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
Agree that this is a confusing message. Could probably use some love. First-round search indexing brought me here.
Change:
`), }, }, <ins> { Description: "$deleteFromPrimitiveList should delete item from a list with merge patch strategy", StrategicMergePatchRawTestCaseData: StrategicMergePatchRawTestCaseData{ Original: []byte(` mergingIntList: - 1 - 2 - 3 `), TwoWay: []byte(` $deleteFromPrimitiveList/mergingIntList: - 2 `), Modified: []byte(` mergingIntList: - 1 - 3 `), }, }, { Description: "$deleteFromPrimitiveList should delete item from a list without merge patch strategy", StrategicMergePatchRawTestCaseData: StrategicMergePatchRawTestCaseData{ Original: []byte(` nonMergingIntList: - 1 - 2 - 3 `), TwoWay: []byte(` $deleteFromPrimitiveList/nonMergingIntList: - 2 `), Modified: []byte(` nonMergingIntList: - 1 - 3 `), }, }, </ins> } func TestCustomStrategicMergePatch(t *testing.T) {

Discussion:
This page explains that the deleteFromPrimitiveList should delete the specified items, but the specified items are kept, and the other items are deleted. The specified items in the deleteFromPrimitiveList should be removed. The result should be instead: No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
Related:
/assign Could you take a look Antoine please? Thanks! /triage accepted
Simplest way to reproduce: It doesn't work with any kubectl version from 1.18 to 1.23 that I've tested.
I tried the exact same object, changing the finalizers works like a charm.
cc Want to give this one a try? :-)
Sure, I'll take a look at it... /assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
<ins> #!/usr/bin/env bash # Copyright 2017 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. DEB_ARCH=$(dpkg --print-architecture) # http://security.debian.org/debian-security/dists/jessie/updates/InRelease is missing # entries for some platforms, so we just remove the last line in sources.list in # /etc/apt/sources.list which is "deb http://deb.debian.org/debian jessie-updates main" case ${DEB_ARCH} in arm64|ppc64el) sed -i '/debian-security/d' /etc/apt/sources.list ;; esac exit 0 </ins>

Discussion:
[X] "goproxy" to "" [X] "jessie-dnsutils" to "" [X] "redis" to "" [X] "serve-hostname" to ""
/assign /assign
we can use to iterate
/sig testing
tip for uploading is here -
should be published to now. I'm rerunning for the other 3 images.
I think the and images were published successfully this time. :
can you please try ?
should now be published too thanks to PR.
related to
Change:
// We omit creation of pretty much everything if we run in cleanup mode if cleanupAndExit { <del> return &ProxyServer{IptInterface: iptInterface}, nil </del> <ins> return &ProxyServer{IptInterface: iptInterface, CleanupAndExit: cleanupAndExit}, nil </ins> } client, eventClient, err := createClients(config.ClientConnection, master)

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?: bug What happened: Got panic after running: Panic: What you expected to happen: No panic and exit successfully. How to reproduce it (as minimally and precisely as possible): Run the following command on both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Happened with the following versions: v1.7.0-alpha.3 v1.7.0-alpha.4 v1.7.0-beta.0 v1.7.0-beta.1 v1.7.0-beta.2 v1.7.0-rc.1 v1.8.0-alpha.0 v1.8.0-alpha.1 Anything else we need to know?: I guess it caused by . Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Kernel (e.g. ): CoreOS v1298.7.0: Linux node- 4.9.16-coreos-r1 SMP Tue Apr 4 19:09:38 UTC 2017 x8664 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz GenuineIntel GNU/Linux Ubuntu 16.04.2 LTS: Linux ubuntu- 4.4.0-62-generic -Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig network /area kube-proxy
/cc
cc/ Looks like there is a new regression in v1.7. Please triage this to decide if it is a release blocker. If not, please provide the workaround for the users. Thanks!

cc/
Digging into the code, will send a PR.
PR sent. Folks review it please.
Added the release-blocker label. We got a PR for it very fast so it won't delay the release anyway, thanks
Change:
if m.invoked <= 1+m.failures+m.successes { return &m.configurationList, nil } <del> m.t.Fatalf("unexpected call to List, stopCh has been closed at the %d time call", 1+m.successes+m.failures) </del> <ins> m.t.Fatalf("unexpected call to List, should only be called %d times", 1+m.successes+m.failures) </ins> return nil, nil }

Discussion:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.
Change:
# Enable metadata concealment by firewalling pod traffic to the metadata server # and run a proxy daemonset on nodes. ENABLE_METADATA_CONCEALMENT="${ENABLE_METADATA_CONCEALMENT:-true}" # true, false <ins> METADATA_CONCEALMENT_NO_FIREWALL="${METADATA_CONCEALMENT_NO_FIREWALL:-false}" # true, false </ins> if [[ ${ENABLE_METADATA_CONCEALMENT:-} == "true" ]]; then # Put the necessary label on the node so the daemonset gets scheduled. NODE_LABELS="${NODE_LABELS},beta.kubernetes.io/metadata-proxy-ready=true"

Discussion:
you this variable - PTAL
/sig gcp
Ping? I see that in all failure log messages for . Not sure if thats the cause or just an error message I can ignore?
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 /assign since I bumped into this
Change:
fmt.Fprintf(out, "Name:t%sn", pv.Name) fmt.Fprintf(out, "Labels:t%sn", formatLabels(pv.Labels)) fmt.Fprintf(out, "Status:t%dn", pv.Status.Phase) <del> fmt.Fprintf(out, "Claim:t%dn", pv.Spec.ClaimRef.UID) </del> <ins> if pv.Spec.ClaimRef != nil { fmt.Fprintf(out, "Claim:t%dn", pv.Spec.ClaimRef.Namespace+"/"+pv.Spec.ClaimRef.Name) } else { fmt.Fprintf(out, "Claim:t%dn", "") } </ins> return nil }) }

Discussion:
After I created a persistent volume, it throws an error on "describe".
Thanks for reporting this. will fix this nil pointer bug. The problem is your volume is not yet bound, but the command line wants to show you some info from the bound claim, except there isn't one.
do you want to break out as a separate pr to fix this, since the nil deref sort of a standalone bug?
done. .
Change:
- ./hack/build-go.sh script: <del> - KUBE_RACE="-race" KUBE_COVER="-cover -covermode=atomic" KUBE_TIMEOUT='-timeout 60s' ./hack/test-go.sh "" -p=4 </del> <ins> - KUBE_RACE="-race" KUBE_COVER="y" KUBE_GOVERALLS_BIN="$HOME/gopath/bin/goveralls" KUBE_TIMEOUT='-timeout 60s' KUBE_COVERPROCS=8 ./hack/test-go.sh -- -p=2 </ins> - PATH=$HOME/gopath/bin:./third_party/etcd:$PATH ./hack/test-cmd.sh - PATH=$HOME/gopath/bin:./third_party/etcd:$PATH ./hack/verify-gendocs.sh - PATH=$HOME/gopath/bin:./third_party/etcd:$PATH ./hack/test-integration.sh

Discussion:
Our test- script invokes 'go test' serially for each pkg - currently taking 2 minutes on my laptop. Running a single 'go test' for all pkgs cuts the time down to 45 seconds. Even running with -race is only 1:15. As far as I can tell, the only time we HAVE to run serially is when coverage is on. Does anyone have time to fix this?
I'd created on Friday to fix this, though it's not yet been reviewed.
I cobbled together but I'll review yours since it is probably better :) , Jeff Grafton wrote:
Change:
} }, "required": [ <del> "replicas", "availableReplicas" </del> <ins> "replicas" </ins> ], "type": "object" },

Discussion:
Looking at the for , it defines as a required attribute. But looking at the of , it states . Should this in fact be a required attribute? I come about this from using , a python package that generates models from the swagger definitions and thus builds a that requires an attribute that is not enabled. That only truly required attributes be required in the swagger definition Reproduction is not applicable as this is an issue with a spec No response Appeared in 1.22 (I believe) and affects current versions. Does not affect 1.21 n/a No response No response No response No response
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
alpha: has that is planned for removal in beta. ( results in fields as non-required in the OpenAPI) beta: removes the this might be a question whether feature gate controlled fields must remain until the feature gate is removed (and how would validation work in that case). ~old feature gates graduations to beta enabled a feature by default.~ a topic related to ? but it does not apply to feature gates. /kind documentation /sig apps
cc (since you are the author)
new fields to existing types must always be marked as +optional, since clients are not required to specify them
please open a PR adding back the +optional tag, regenerate openapi, and open picks back to 1.23 and 1.22
Change:
const ( requestKind   = "request_kind" <del> priorityLevel = "priorityLevel" flowSchema    = "flowSchema" </del> <ins> priorityLevel = "priority_level" flowSchema    = "flow_schema" </ins> phase         = "phase" mark          = "mark" )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : API priority and fairness metrics have labels such as "priorityLevel" and "flowSchema". These should be "prioritylevel" and "flowschema" respectively. These metrics have been to an exception list: Why is this needed: snake_case is consistent with other metrics. /sig api-machinery /kind cleanup /cc Do we want to do this before 1.20 beta?
yes, lets do that.
/triage accepted Yes, we do not want to go to beta with known wrongness in the metrics.
Change:
const noConnectionToDelete = "0 flow entries have been deleted" <del> func isIPv6(ip string) bool { netIP := net.ParseIP(ip) </del> <ins> func IsIPv6(netIP net.IP) bool { </ins> return netIP != nil && netIP.To4() == nil } <ins> func IsIPv6String(ip string) bool { netIP := net.ParseIP(ip) return IsIPv6(netIP) } </ins> func parametersWithFamily(isIPv6 bool, parameters ...string) []string { if isIPv6 { parameters = append(parameters, "-f", "ipv6")

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?: /kind bug What happened: There is a bug in ipv6, see: What you expected to happen: The judgement logic should be: 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 network /area ipv6
/assign cc
Change:
} for _, c := range cases { <del> ssName, instanceID, err := ss.extractVmssVMName(c.vmName) </del> <ins> ssName, instanceID, err := extractVmssVMName(c.vmName) </ins> if c.expectError { assert.Error(t, err, c.description) continue

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: When useInstanceMetadata is set to true for vmss nodes, their providerID is wrong. What you expected to happen: Their providerID should be in format azure:///subscriptions/&lt;subscription-id/resourceGroups/&lt;rg-name/providers/Microsoft.Compute/virtualMachineScaleSets/&lt;scaleset-name/virtualMachines/&lt;instance-id 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 azure
adding priority important-soon so that this issue can stay in 1.10. Please update if incorrect. /priority important-soon