jiebi/CodeConvo huggingface dataset:
Code change:
// WithDeprecatedPasswordFlag enables the username and password config flags func (f *ConfigFlags) WithDeprecatedPasswordFlag() *ConfigFlags { <del> f.Username = stringptr("") f.Password = stringptr("") </del> <ins> f.Username = utilpointer.String("") f.Password = utilpointer.String("") </ins> return f }

Related discussion:
text: The discovery cache for kubectl is defaulted to 10 minutes: That means that every 10 minutes of using against a cluster, it runs API requests against all group versions, which can take quite some time on clusters with many operators installed (like , , , etc.). I previously wrote that shows that every 10 minutes a simple makes 170 API requests against a test cluster, vs 4 API requests when the cache exists. That results in significant productivity implications against such clusters. Here is a time comparison between a request that runs the discovery cache vs one that doesn't: The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers. This issue is raised to change the discovery cache default to 24 hours and also to make the discovery cache ttl configurable. Running the discovery cache every 10 minutes has a significant productivity impact on using on clusters with many CRDs as it is taking time to run these unnecessary requests. The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers.
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
I would like to work on this issue.
/assign
Code change:
value: "0" - name: net.ipv4.ping_group_range value: 1 0 <ins> - name: net.ipv4.ip_unprivileged_port_start value: "1024" </ins>

Related discussion:
text: Is the sysctl namespaced? If so, can we include this in the set of "safe" sysctls? If we allow this, we would: add to permit in PodSecurity baseline profile cc So that containers can bind to low ports without needing to bake CAPNETBINDSERVICE into the files in the image doesn't help hostNetwork pods since they don't have their own namespace and you likely wouldn't want to change the system-wide sysctl also, pods that schedule to arbitrary nodes likely shouldn't start taking advantage of this until 2+ releases after it merges into the kubelet, because of potential node skew
/sig network security node auth
xref: for actually potentially setting this by default even.
/assign
Yes, it is network-namespaced and :+1: to adding it to safe list. From
/triage accepted
Code change:
want:    netip.MustParseAddr("192.168.0.128"), }, { <ins> name:    "IPv4 with leading zeros", address: netip.MustParseAddr("0.0.1.8"), offset:  138, want:    netip.MustParseAddr("0.0.1.146"), }, { name:    "IPv6 with leading zeros", address: netip.MustParseAddr("00fc::1"), offset:  255, want:    netip.MustParseAddr("fc::100"), }, { </ins> name:    "IPv6 offset 255", address: netip.MustParseAddr("2001:db8:1::101"), offset:  255,

Related discussion:
text: We ran into an issue with an old version of k8s 1.18 that we were running where subnet for cluster IP is given as . The control plane comes up just fine but then when you try to create a k8s service, it fails due to a broken behavior with the IP Allocator Since this is not really a supported version of the k8s, I went around digging up a bit more to see what is the regular behavior and found this to be very inconsistent across a few release branches. bash go test -timeout 30m -run ^TestAllocateNextFC$ -v === RUN TestAllocateNextFC ? --- PASS: TestAllocateNextFC (0.00s) PASS ok 0.566s go func TestAllocateNextFC(t *testing.T) { , cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } // Need to be replaced with the suitable handler for that version of the branch r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("%s", err.Error()) } fmt.Println(ip.String()) } Add the above Test case under the IP allocator test case No response_ <detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details
/sig network /assign /kind bug
Thanks for helping me with this issue.
/triage accepted /assign
Code change:
encryption_provider_config_path=${ENCRYPTION_PROVIDER_CONFIG_PATH:-/etc/srv/kubernetes/encryption-provider-config.yml} echo "${ENCRYPTION_PROVIDER_CONFIG}" | base64 --decode > "${encryption_provider_config_path}" <del> kube_api_server_params+=" --experimental-encryption-provider-config=${encryption_provider_config_path}" </del> <ins> kube_api_server_params+=" --encryption-provider-config=${encryption_provider_config_path}" </ins> default_encryption_provider_config_vol=$(echo "{ "name": "encryptionconfig", "hostPath": {"path": "${encryption_provider_config_path}", "type": "File"}}" | base64 | tr -d 'rn') default_encryption_provider_config_vol_mnt=$(echo "{ "name": "encryptionconfig", "mountPath": "${encryption_provider_config_path}", "readOnly": true}" | base64 | tr -d 'rn')

Related discussion:
text: Ref Ref ref /sig auth /kind feature /milestone v1.11 /priority important-longterm /status approved-for-milestone cc
What's need to be done here? I can think only about renaming to and updating the docs. What else?
What's required to promote encryption at rest with static configs to beta?
an example of promoting flags is here: If there's a feature gate, we're going to want to enable it by default too.
/assign
submitted PRs for that: and
[MILESTONENOTIFIER] Milestone Removed From Issue Important: Code freeze is in effect and only issues with may remain in the v1.11 milestone. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Will this make it to Beta in 1.12? From sig-auth on 7/11, it sounded like this was missing a release shepherd. Is anyone owning pushing this forward?
I'll do my best to push this. edit: I did not realize that 1.12 feature freeze is today (or so I heard), I don't think I'll be able to make it :slightlyfrowningface:
Ack - that's what I was wondering (with the feature freeze). Thanks
- Is this making it to the 1.12 ?
The current plan is 1.13
Code change:
// keyFunc is used to get a key in the underyling storage for a given object. keyFunc func(runtime.Object) (string, error) <del> // Whether to serve Lists from in-memory cache. // // NOTE: DO NOT SET TO TRUE IN PRODUCTION CODE! ListFromCache bool </del> } // Create a new Cacher responsible from service WATCH and LIST requests from its

Related discussion:
text: The label(s) cannot be applied. These labels are supported: <detailsIn response to : This one is trying to use with a generator to create an rc. This was deprecated and now is removed, so the test is failing now. /label sig/undefined 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
/label failing-test
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label failing-test 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
/kind failing-test
At first I thought this was because generators were removed from . That still might be the cause of this, but I'm not 100% sure off-hand.
/sig cli
/assign
Funny thing about this is if you look in the build logs it is not immediately obvious that it is caused by generators being removed from because actually has sort of an unexpected behavior, where it tells you it is deprecated and gives you a pod instead... For example: Output:
/reopen should fix this is one of the affected jobs
Reopened this issue. <detailsIn response to : /reopen should fix this 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
Since it's been a few weeks, I wanted to provide an update on this. I'm still waiting to confirm this is resolved by It looks like it is still running the old tests not marked as . Since 1.17.9 was released 14 days ago, and k8s-ci-robot only merged the PR 13 days ago, I'm guessing we need to wait until there is a 1.17.10 to see it skip the deprecated 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.
Code change:
// keyFunc is used to get a key in the underyling storage for a given object. keyFunc func(runtime.Object) (string, error) <del> // Whether to serve Lists from in-memory cache. // // NOTE: DO NOT SET TO TRUE IN PRODUCTION CODE! ListFromCache bool </del> } // Create a new Cacher responsible from service WATCH and LIST requests from its

Related discussion:
text: 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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
Code change:
# # $1 - server architecture kube::build::get_docker_wrapped_binaries() { <del> local debian_iptables_version=v12.1.2 </del> <ins> local debian_iptables_version=buster-v1.3.0 </ins> local go_runner_version=buster-v2.0.1 ### If you change any of these lists, please also update DOCKERIZED_BINARIES ### in build/BUILD. And kube::golang::server_image_targets

Related discussion:
text: What would you like to be : Have debian-iptables with iptables 1.8.5+ Why is this needed: To fix (nodelocaldns + iptables-nft) More informations Found a bug in iptables-nft, fixed in iptables 1.8.5, and now available in buster-backports https://alioth-
/sig api-machinery
ping as you did the last 2 updates
Yep, this is on my list. Will take of it next week. /sig release network /area release-eng /milestone v1.20 /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Opened to bump the debian-iptables images in kubernetes/kubernetes. /remove-triage unresolved
Here are the digests for the new image ():
Please reopen if you run into any issues with the new images. /close
Closing this issue. <detailsIn response to : Please reopen if you run into any issues with the new images. /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
Code change:
labels: k8s-app: fluentd-es kubernetes.io/cluster-service: "true" <del> version: v2.0.0 </del> <ins> version: v2.0.1 </ins> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573).

Related discussion:
text: <!-- 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: [root EFK]# kubectl logs -f fluentd-es-jrsf7 -n kube-system /var/lib/gems/2.1.0/gems/ffi- block in ffilib': Could not open library '': cannot open shared object file: No such file or directory. (LoadError) Could not open library '': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': libsystemd- cannot open shared object file: No such file or directory from /var/lib/gems/2.1.0/gems/ffi-map' from /var/lib/gems/2.1.0/gems/ffi- ffilib' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Native' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;module:Id128' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Systemd' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/systemd-journal-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;top (required)' fromrequire' from rescue in require' fromrequire' from /var/lib/gems/2.1.0/gems/fluent-plugin-systemd- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/fluentd-block in tryloadplugin' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-tryloadplugin' from /var/lib/gems/2.1.
Code change:
labels: k8s-app: fluentd-es kubernetes.io/cluster-service: "true" <del> version: v2.0.0 </del> <ins> version: v2.0.1 </ins> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573).

Related discussion:
text: 0/gems/fluentd- newimpl' from /var/lib/gems/2.1.0/gems/fluentd-newinput' from /var/lib/gems/2.1.0/gems/fluentd- addsource' from /var/lib/gems/2.1.0/gems/fluentd-block in configure' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-configure' from /var/lib/gems/2.1.0/gems/fluentd- configure' from /var/lib/gems/2.1.0/gems/fluentd-runconfigure' from /var/lib/gems/2.1.0/gems/fluentd- runconfigure' from /var/lib/gems/2.1.0/gems/fluentd-block in start' from /var/lib/gems/2.1.0/gems/fluentd- call' from /var/lib/gems/2.1.0/gems/fluentd-mainprocess' from /var/lib/gems/2.1.0/gems/fluentd- start' from /var/lib/gems/2.1.0/gems/fluentd-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.0/gems/fluentd-0.12.39/bin/fluentd:5:in &lt;top (required)' from /usr/local/bin/fluentd:23:inload' from /usr/local/bin/fluentd:23:in &lt;main' What you expected to happen: fluentd-es run success How to reproduce it (as minimally and precisely as possible): kubectl create -f fluentd-es- the image is google-containers/fluentd-elasticsearch:v2.0.0 Anything else we need to know?
Code change:
labels: k8s-app: fluentd-es kubernetes.io/cluster-service: "true" <del> version: v2.0.0 </del> <ins> version: v2.0.1 </ins> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573).

Related discussion:
text: : Environment: Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-21T08:23:22Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-21T08:08:00Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release):centos 7.3 Kernel (e.g. ):Linux node-21.46 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: 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
Yup, the situation with fluentd on the system with systemd is very sloppy. There's a hack to make it works sometimes, but it seems that it doesn't work. I'll look into it
/sig instrumentation /assign
Facing same issue.
Code change:
labels: k8s-app: fluentd-es kubernetes.io/cluster-service: "true" <del> version: v2.0.0 </del> <ins> version: v2.0.1 </ins> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573).

Related discussion:
text: Environment Details:kubectl version Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} OS (e.g. from /etc/os-release):Centos 7 (Core) Kernel (e.g. uname -a): Linux xxxx 3.10.0-327.el7.x8664 Error for reference /var/lib/gems/2.1.0/gems/ffi- block in ffilib': Could not open library '': cannot open shared object file: No such file or directory. (LoadError) Could not open library '': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': libsystemd- cannot open shared object file: No such file or directory from /var/lib/gems/2.1.0/gems/ffi-map' from /var/lib/gems/2.1.0/gems/ffi- ffilib' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Native' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;module:Id128' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Systemd' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/systemd-journal-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.
Code change:
labels: k8s-app: fluentd-es kubernetes.io/cluster-service: "true" <del> version: v2.0.0 </del> <ins> version: v2.0.1 </ins> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573).

Related discussion:
text: 0/gems/systemd-journal- &lt;top (required)' fromrequire' from rescue in require' fromrequire' from /var/lib/gems/2.1.0/gems/fluent-plugin-systemd- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/fluentd-block in tryloadplugin' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-tryloadplugin' from /var/lib/gems/2.1.0/gems/fluentd- newimpl' from /var/lib/gems/2.1.0/gems/fluentd-newinput' from /var/lib/gems/2.1.0/gems/fluentd- addsource' from /var/lib/gems/2.1.0/gems/fluentd-block in configure' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-configure' from /var/lib/gems/2.1.0/gems/fluentd- configure' from /var/lib/gems/2.1.0/gems/fluentd-runconfigure' from /var/lib/gems/2.1.0/gems/fluentd- runconfigure' from /var/lib/gems/2.1.0/gems/fluentd-block in start' from /var/lib/gems/2.1.0/gems/fluentd- call' from /var/lib/gems/2.1.0/gems/fluentd-mainprocess' from /var/lib/gems/2.1.0/gems/fluentd- start' from /var/lib/gems/2.1.0/gems/fluentd-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.0/gems/fluentd-0.12.39/bin/fluentd:5:in &lt;top (required)' from /usr/local/bin/fluentd:23:inload' from /usr/local/bin/fluentd:23:in &lt;
Code change:
labels: k8s-app: fluentd-es kubernetes.io/cluster-service: "true" <del> version: v2.0.0 </del> <ins> version: v2.0.1 </ins> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573).

Related discussion:
text: main'
You can solve it temporary by removing I'm working on the solution
A solution here might be to base fluentd-es off an image with journald supporting XZ and LZ4 compression. I'm looking :)
Thanks
Code change:
} if err := os.MkdirAll(dir, 0750); err != nil { <del> // TODO: we should really eject the attach/detach out into its own control loop. </del> glog.V(4).Infof("Could not create directory %s: %v", dir, err) <del> detachDiskLogError(b.cinderVolume) </del> return err }

Related discussion:
text: while reading some cinder code, i came accross , we try to detach disk even if we didn't try to mount. Is this call mandatory ? (from what i recall AWS EBS do not have such mecanism) Also ping
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 openstack
cc
that's was before attach/detach controller, a revisit is necessary
Sure i'll take care of it /assign
Code change:
<del> { "id": "influx-grafana", "kind": "Pod", "apiVersion": "v1beta1", "desiredState": { "manifest": { "version": "v1beta1", "id": "influx-grafana", "containers": [ { "name": "influxdb", "image": "kubernetes/heapster_influxdb", "ports": [ { "containerPort": 8083, "hostPort": 8083 }, { "containerPort": 8086, "hostPort": 8086 }, { "containerPort": 8090, "hostPort": 8090 }, { "containerPort": 8099, "hostPort": 8099 } ] }, { "name": "grafana", "image": "kubernetes/heapster_grafana", "ports": [ { "containerPort": 80, "hostPort": 80 } ], "env": [ { "name": "HTTP_USER", "value": "{KUBE_USER}" }, { "name": "HTTP_PASS", "value": "{KUBE_PASSWORD}" } ] }, { "name": "elasticsearch", "image": "dockerfile/elasticsearch", "ports": [ { "containerPort": 9200, "hostPort": 9200 }, { "containerPort": 9300 } ] } ] } }, "labels": { "name": "influxdb" } } </del>

Related discussion:
text: examples/monitoring/influx-grafana- and friends NEED to be replaced by a replication controller ASAP. As it stands they are bad examples. Also, they should probably move to contrib/monitoring to match contrib/logging and contrib/dns
Code change:
# # We specify -X to avoid a race condition that can cause minion failure to # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 <del> curl -sS -L http://bootstrap.saltstack.com | sh -s -- -X </del> <ins> curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s -- -X </ins> ## TODO this only works on systemd distros, need to find a work-around as removing -X above fails to start the services installed systemctl enable salt-minion

Related discussion:
text: Salt was failing to install on the master vagrant instance. The change noted by the FIXME solved it.
It's possible the required merge in the upstream repo occurred, will take a look.
I just attempted to install a new cluster from upstream/master and was not able to reproduce the issue described. Was there an issue with curl-ing that specific version of salt-bootstrap? I guess more details on what the failure you encountered appeared as would help know how to proceed.
I will submit a PR to revert back to using the default non-versioned bootstrap URL. Salt-stack PR: Fixed the errors in install that were previously encountered around salt-api not being found.
See , thanks!