jiebi/CodeConvo huggingface dataset:
Code change:
# Note that fluentd is run with root permssion to allow access to # log files with root only access under /var/log/containers/* <del> FROM gcr.io/google-containers/debian-base-amd64:0.1 </del> <ins> FROM debian:stretch-slim COPY clean-apt /usr/bin COPY clean-install /usr/bin </ins> COPY Gemfile /Gemfile # 1. Install & configure dependencies.

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:
# Note that fluentd is run with root permssion to allow access to # log files with root only access under /var/log/containers/* <del> FROM gcr.io/google-containers/debian-base-amd64:0.1 </del> <ins> FROM debian:stretch-slim COPY clean-apt /usr/bin COPY clean-install /usr/bin </ins> COPY Gemfile /Gemfile # 1. Install & configure dependencies.

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:
# Note that fluentd is run with root permssion to allow access to # log files with root only access under /var/log/containers/* <del> FROM gcr.io/google-containers/debian-base-amd64:0.1 </del> <ins> FROM debian:stretch-slim COPY clean-apt /usr/bin COPY clean-install /usr/bin </ins> COPY Gemfile /Gemfile # 1. Install & configure dependencies.

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:
# Note that fluentd is run with root permssion to allow access to # log files with root only access under /var/log/containers/* <del> FROM gcr.io/google-containers/debian-base-amd64:0.1 </del> <ins> FROM debian:stretch-slim COPY clean-apt /usr/bin COPY clean-install /usr/bin </ins> COPY Gemfile /Gemfile # 1. Install & configure dependencies.

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:
# Note that fluentd is run with root permssion to allow access to # log files with root only access under /var/log/containers/* <del> FROM gcr.io/google-containers/debian-base-amd64:0.1 </del> <ins> FROM debian:stretch-slim COPY clean-apt /usr/bin COPY clean-install /usr/bin </ins> COPY Gemfile /Gemfile # 1. Install & configure dependencies.

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:
# Note that fluentd is run with root permssion to allow access to # log files with root only access under /var/log/containers/* <del> FROM gcr.io/google-containers/debian-base-amd64:0.1 </del> <ins> FROM debian:stretch-slim COPY clean-apt /usr/bin COPY clean-install /usr/bin </ins> COPY Gemfile /Gemfile # 1. Install & configure dependencies.

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:
// Adds a service to return the supported versions, preferred version, and name // of a group. E.g., a such web service will be registered at /apis/extensions. func AddGroupWebService(s runtime.NegotiatedSerializer, container *restful.Container, path string, group unversioned.APIGroup) { <del> groupHandler := GroupHandler(s, group) </del> <ins> ss := s if keepUnversioned(group.Name) { // Because in release 1.1, /apis/extensions returns response with empty // APIVersion, we use StripVersionNegotiatedSerializer to keep the // response backwards compatible. ss = StripVersionNegotiatedSerializer{s} } groupHandler := GroupHandler(ss, group) </ins> ws := new(restful.WebService) ws.Path(path) ws.Doc("get information of a group")

Related discussion:
text: Kubectl client Kubectl api-versions should check if v1 is in available api versions [Conformance] Expected error: <_errors.errorString | 0xc208641770: { s: "Error running &{/jenkins-master-data/jobs/kubernetes-upgrade-gke-1.1-master-step1-deploy/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://130.211.136.232 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-upgrade-gke-1.1-master-step1- api-versions] [] error: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1"n [] 0xc208382fa0 exit status 1 true [0xc208627148 0xc208627168 0xc208627188] [0xc208627148 0xc208627168 0xc208627188] [0xc208627160 0xc208627180] [0x6d81a0 0x6d81a0] 0xc2082fb2c0}:nCommand stdout:nnstderr:nerror: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1"nn", } Error running &{/jenkins-master-data/jobs/kubernetes-upgrade-gke-1.1-master-step1-deploy/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://130.211.136.232 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-upgrade-gke-1.
Code change:
// Adds a service to return the supported versions, preferred version, and name // of a group. E.g., a such web service will be registered at /apis/extensions. func AddGroupWebService(s runtime.NegotiatedSerializer, container *restful.Container, path string, group unversioned.APIGroup) { <del> groupHandler := GroupHandler(s, group) </del> <ins> ss := s if keepUnversioned(group.Name) { // Because in release 1.1, /apis/extensions returns response with empty // APIVersion, we use StripVersionNegotiatedSerializer to keep the // response backwards compatible. ss = StripVersionNegotiatedSerializer{s} } groupHandler := GroupHandler(ss, group) </ins> ws := new(restful.WebService) ws.Path(path) ws.Doc("get information of a group")

Related discussion:
text: 1-master-step1- api-versions] [] error: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1" [] 0xc208382fa0 exit status 1 true [0xc208627148 0xc208627168 0xc208627188] [0xc208627148 0xc208627168 0xc208627188] [0xc208627160 0xc208627180] [0x6d81a0 0x6d81a0] 0xc2082fb2c0}: Command stdout: stderr: error: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1" not to have occurred* See and Investigating. cc
Okiedokie. Looks like the v1.1 client is getting a response from the v1.2 master, but the v1.1 client doesn't know how to handle the v1 APIVersions object, because in v1.1, that object was never expected to have an . From a 1.1 server, we get which doesn't include a . We should expect to have plenty of pre-v1.1.7 clients floating around, and releasing a fixed v1.1.8 probably isn't going to solve this; if we want to be backward compatible, we need to not return an string with unversioned kinds like . Looking into more details about how we got here... cc cc
I have a maybe feeling that this is caused by ? In particular, we went from: to
Probably it's caused by this:
Let me double check the code. cc
What about that line? I've never dealt with the version negotiation; should the server and client be negotiating in a way that the server can return an object without ?
More precisely it's this line: This line sets the version to "v1". In , during encoding, we set unversioned object's APIVersion field to "v1".
I think in the long run, because we expect to move many unversioned types to group "common", so they should be versioned, so making APIVersion=v1 is the right move. Back to the backwards compatibility issue, how's the situation at other url, like http://127.0.0.1:8080/apis/extensions?
Code change:
// Adds a service to return the supported versions, preferred version, and name // of a group. E.g., a such web service will be registered at /apis/extensions. func AddGroupWebService(s runtime.NegotiatedSerializer, container *restful.Container, path string, group unversioned.APIGroup) { <del> groupHandler := GroupHandler(s, group) </del> <ins> ss := s if keepUnversioned(group.Name) { // Because in release 1.1, /apis/extensions returns response with empty // APIVersion, we use StripVersionNegotiatedSerializer to keep the // response backwards compatible. ss = StripVersionNegotiatedSerializer{s} } groupHandler := GroupHandler(ss, group) </ins> ws := new(restful.WebService) ws.Path(path) ws.Doc("get information of a group")

Related discussion:
text: That address also returns a versioned object, which at release 1.1 is unversioned: Do we need to keep all unversioned objects unversioned, or do we only need to ensure the server returns unversioned object at api/?
cc
Per our versioning rules, we should expect a v1.2 server to remain backward compatible with v1.1 clients. I don't have much experience with the api machinery, but if clients weren't expecting an unversioned object, it seems like we can't up and switch to versioned objects.
I think we have to maintain compatibility somehow. any ideas for a fix other than the obvious one?
Yes, we have to maintain backward compatibility with 1.1 (and 1.0) clients. New paths that old clients didn't know about could behave differently than paths that existed in previous releases.
Nope, let's make sure we leave a test and comment.
We can't make the change here though, this would break "versioned unversioned" objects (like )
The other implication of course is now we "versioned unversioned" objects (v1 status) and "unversioned unversioned", which means we shouldn't ever add new objects that don't return a version. I don't think anything in 1.2 qualifies as a new object without a version, just 1.1 objects that didn't have correct versions. Having objects from extensions group be returned without versions terrifies me - I don't see any way of describing that except as a bug.
We may need per API group version rules registered on scheme about whether "unversioned" objects are returned in their scheme version or as empty. That's probably the backward compatible fix that gives us a hope of reasoning about behavior correctly (status in 1.0 is v1, status in extensions might be "", apiversions in any new group is "v1"). The unversioned marker on the objects should ensure 1.2 clients can receive objects in both "" and "v1" form, we should add a test to verify that. I'm against letting empty API versions spread, but agree backcompat for existing groups versions should match previous behavior.
Can we make (or use) a different serializer/codec just for the endpoints that 1.1 clients used?
Code change:
// Adds a service to return the supported versions, preferred version, and name // of a group. E.g., a such web service will be registered at /apis/extensions. func AddGroupWebService(s runtime.NegotiatedSerializer, container *restful.Container, path string, group unversioned.APIGroup) { <del> groupHandler := GroupHandler(s, group) </del> <ins> ss := s if keepUnversioned(group.Name) { // Because in release 1.1, /apis/extensions returns response with empty // APIVersion, we use StripVersionNegotiatedSerializer to keep the // response backwards compatible. ss = StripVersionNegotiatedSerializer{s} } groupHandler := GroupHandler(ss, group) </ins> ws := new(restful.WebService) ws.Path(path) ws.Doc("get information of a group")

Related discussion:
text: Probably we just need to change the version registered here:
That won't work like you expect - the type registry then has no knowledge in v1 of what schema the object is. That's not what we want - we want to not serialize the version of the object for specific API groups, which is a much more targeted change. This is a special, exceptional case (v1 group should return v1 Status. v1beta1 should not). , Chao Xu wrote:
Changing v1 breaks 1.0 backwards compat (we always returned apiVersion=v1 for 1.0) , Clayton Coleman wrote:
I mean this: Will this work?
I'm not sure without looking at the outcome (which is why unversioned is a bit of a disaster in our codebase). I would much prefer to explicitly identify which objects should have an unset apiversion via a method on the scheme, and do the explicit check at the time we do convert to version. That's an extremely controlled change, is obvious, and doesn't make the unversioned problem worse.
I remember somewhere in asserts version cannot be empty, so I guess my proposed solution won't work without extra work. I'll take the approach suggested by
Code change:
// located in (i.e. where the controller will be running). If this is // blank, then the local zone will be discovered via the metadata server. LocalZone string `gcfg:"local-zone"` <del> // Possible values: List of api names separated by comma. Default to none. </del> <ins> // Default to none. </ins> // For example: MyFeatureFlag AlphaFeatures []string `gcfg:"alpha-features"` }

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: If the field in contains multiple entries, e.g. , none of them are enabled. Log message: What you expected to happen: Each of the comma-separated entries should be enabled. How to reproduce it (as minimally and precisely as possible): Read above. Anything else we need to know?: Root cause appears to be the value of is not split before being used in CC Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
[MILESTONENOTIFIER] Milestone Issue Current Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
I think it's better to process when reading
currently is rendered from . While it is defined as in . When inputing , it will be rendered as a string array with length equals 1, instead of (length is 2). The result can be only when we have multiple set in the conf, just as the link shown by Also this is the same with .
I uploaded a PR () to parse the comma-separated values while still supporting the original gcfg muiltvalue mechanism (i.e., allowing setting the field multiple times) pointed out by the the above comments; this ensures backward compatibility (even though I don't know if anyone is using it that way). I'll let the reviewers decide which method they prefer.
Code change:
// storageWatchListPageSize is the cacher's request chunk size of // initial and resync watch lists to storage. storageWatchListPageSize = int64(10000) <ins> // defaultBookmarkFrequency defines how frequently watch bookmarks should be send // in addition to sending a bookmark right before watch deadline defaultBookmarkFrequency = time.Minute </ins> ) // Config contains the configuration for a given Cache.

Related discussion:
text: Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.
Code change:
ctx, cancel := getContextWithCancel() defer cancel() <del> glog.V(4).Infof("listing registries") result, err := a.registryClient.List(ctx) if err != nil { glog.Errorf("Failed to list registries: %v", err) return cfg } for ix := range result { loginServer := getLoginServer(result[ix]) var cred *credentialprovider.DockerConfigEntry </del> <ins> if a.config.UseManagedIdentityExtension { glog.V(4).Infof("listing registries") result, err := a.registryClient.List(ctx) if err != nil { glog.Errorf("Failed to list registries: %v", err) return cfg } </ins> <del> if a.config.UseManagedIdentityExtension { cred, err = getACRDockerEntryFromARMToken(a, loginServer) </del> <ins> for ix := range result { loginServer := getLoginServer(result[ix]) glog.V(2).Infof("loginServer: %s", loginServer) cred, err := getACRDockerEntryFromARMToken(a, loginServer) </ins> if err != nil { continue } <del> } else { cred = &credentialprovider.DockerConfigEntry{ </del> <ins> cfg[loginServer] = *cred } } else { // Add our entry for each of the supported container registry URLs for _, url := range containerRegistryUrls { cred := &credentialprovider.DockerConfigEntry{ </ins> Username: a.config.AADClientID, Password: a.config.AADClientSecret, Email:    dummyRegistryEmail, } <ins> cfg[url] = *cred </ins> } <del> cfg[loginServer] = *cred </del> } return cfg }

Related discussion:
text: After my repro and investigation(really spent a lot of time...), I found the issue lies here, would return empty even after granting sp access to azure acr, and after around 15min, it returns correct loginServer list: Looks like it's a SDK or acr list with specific sp issue, workaround is wait around 15min or more time, it could recover by itself. Paste my investigation logs here, I grant sp access to acr in around , you could see it returns empty registry list first and then after a few more minutes, it returns the correct list with loginServer:
BTW, in v1.12, acr list() uses new API, I will check whether in v1.12 would have same issue. Acutally I have already implemented LazyProvide func(check here: ), while it won't fix the original issue.
Update: After a few more tries, I found it's related to this code snippet, before , we need to generate a new ServicePrincipalToken every time: I will move this code snippet into Provide() func, and send out a PR! The failure recover time is within 2min now.