jiebi/CodeConvo huggingface dataset:
Change:
<ins> # This Dockerfile will build an image that is configured to use Fluentd to # collect container log files from the specified paths and send them to the # Google Cloud Logging API. # The environment variable that controls which log files are collected is # FILES_TO_COLLECT. Files specified in the environment variable should be # separated by whitespace, as in "/var/log/syslog /var/log/nginx/access.log". # This configuration assumes that the host performning the collection is a VM # that has been created with a logging.write scope and that the Logging API # has been enabled for the project in the Google Developer Console. FROM ubuntu:14.04 MAINTAINER Alex Robinson "arob@google.com" # Disable prompts from apt. ENV DEBIAN_FRONTEND noninteractive ENV OPTS_APT -y --force-yes --no-install-recommends # Install the Fluentd agent that knows how to send logs to Google Cloud Logging. RUN apt-get -q update &&  apt-get -y install curl &&  apt-get clean &&  curl -s https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh | sudo bash # Copy the configuration file generator for creating input configurations for # each file specified in the FILES_TO_COLLECT environment variable. COPY config_generator.sh /usr/local/sbin/config_generator.sh # Copy the Fluentd configuration file for collecting from all the inputs # generated by the config generator and sending them to Google Cloud Logging. COPY google-fluentd.conf /etc/google-fluentd/google-fluentd.conf # Run the config generator to get the config files in place and start Fluentd. # We have to run the config generator at runtime rather than now so that it can # incorporate the files provided in the environment variable in its config. CMD /usr/local/sbin/config_generator.sh && /usr/sbin/google-fluentd -qq --use-v1-config --suppress-repeated-stacktrace > /var/log/google-fluentd/google-fluentd.log </ins>

Discussion:
We should provide a dockerfile for a pre-configured Fluentd image that can be passed file paths to collect logs from. We'll likely want one for exporting to elasticsearch and one for exporting to Google Cloud Logging, as we have today for the per-node stdout/stderr collectors. How to collect log files from within a container is a question that comes up occasionally (including ), and it provides a strong example of the usefulness of sidecar containers. cc
A controller that keeps one instance of a pod alive on each node would be useful for this. Shall I go ahead and write such a controller?
Would it be? This is intended to run as a sidecar container in a pod with the user's actual application. I think a pod-per-node controller is orthogonal (and is being discussed in and ). I'll create the actual Dockerfile, and a quick example of how to use it.
Sorry, my rush to catch up I think I mis-understood this thread.
Change:
}, Spec: api.ReplicationControllerSpec{ Replicas: 1, <del> Selector: podLabels, </del> <ins> Selector: rcPodLabels, </ins> Template: &api.PodTemplateSpec{ ObjectMeta: api.ObjectMeta{ <del> Labels: podLabels, </del> <ins> Labels: rcPodLabels, </ins> }, Spec: api.PodSpec{ Containers: []api.Container{

Discussion:
cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.
Change:
deps = [ "//staging/src/k8s.io/api/authorization/v1beta1:go_default_library", "//staging/src/k8s.io/api/rbac/v1beta1:go_default_library", <del> "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library",

Discussion:
What would you like to be : The function in should check for GKE and allow a missing SubjectAccessReview endpoint. If we get a 404 on another provider an error should still be returned. GKE doesn't enable the SAR endpoint. Without this endpoint, we cannot determine if the policy engine has adjusted as expected. In this case, we currently wait one second and hope it's up to date without returning an error and that it has adjusted as expected. Why is this needed: A 404 on that endpoint is not expected behavior for any provider other than GKE so it doesn't make any sense to implicitly allow 404s and hope that everything is ok. If it is a special, allowable, condition for GKE we should make that explicit in the code. The problem with doing it now is that checking the provider requires access to the TestContext which forces us to import the entire package. This goes against the goal of At the same time, we don't want to cause every test/caller of this to have to (1) know that GKE acts differently in this situation and code that one special path. This may be the lesser of the evils though, but regardless of how it is accomplished, at some point, the code should be validating this flow. Open to other solutions to this; maybe a specific test to test this code path (in which case this helper can be assumed to not be responsible for it?) Not sure if that is considered sufficient as it creates an awkward coupling between a helper function's assumptions and the existence of particular test.
/sig testing /area test /area test-framework
I think that comment no longer applies, and we can just remove that GKE special case. IIRC, GKE didn't initially enable serving the group, but it does now.
OK; I will: confirm GKE handling paste link here for history Put up PR removing the special case entirely
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" <ins> "k8s.io/apimachinery/pkg/labels" </ins> "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/wait" <ins> "k8s.io/apimachinery/pkg/watch" </ins> clientset "k8s.io/client-go/kubernetes" <ins> "k8s.io/client-go/tools/cache" watchtools "k8s.io/client-go/tools/watch" </ins> "k8s.io/client-go/util/retry" batchinternal "k8s.io/kubernetes/pkg/apis/batch" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
[x] Test approval issue : [x] Test PR : - Needed an update on the handling of anotations 27 March 2022 [x] Two weeks soak end date : 6 April 2022 [x] Test promotion PR : [x] Update Test PR: 15 April 2022 [x] Two weeks soak end date : 4 May 2022 with start of 1.25 [x] Update Test Promotion: According to these APIsnoop queries, there are still four remaining Job endpoints which are untested. Using a number of existing e2e test practices a new has been created for this job lifecycle test. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen for tracking e2e testgrid and promotion PR
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
go k.launchTask(driver, taskId, pod) } <del> // TODO(jdef) add metrics for this? type suicideTimer struct { timer *time.Timer } func (w *suicideTimer) Next(d time.Duration, driver bindings.ExecutorDriver, f jumper) suicideWatcher { return &suicideTimer{ timer: time.AfterFunc(d, func() { log.Warningf("Suicide timeout (%v) expired", d) f(driver, nil) }), } } func (w *suicideTimer) Stop() (result bool) { if w != nil && w.timer != nil { log.Infoln("stopping suicide watch") //TODO(jdef) debug result = w.timer.Stop() } return } // return true if the timer was successfully reset func (w *suicideTimer) Reset(d time.Duration) bool { if w != nil && w.timer != nil { log.Infoln("resetting suicide watch") //TODO(jdef) debug w.timer.Reset(d) return true } return false } </del> // determine whether we need to start a suicide countdown. if so, then start // a timer that, upon expiration, causes this executor to commit suicide. // this implementation runs asynchronously. callers that wish to wait for the

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: Followed the documentation on rules to limit group Id's to non-superuser (root) using the rule. The creation attempt failed with: From PSP yaml: What you expected to happen: Successfully create a new PSP for non-superuser (root) group privileges using available rule values (which actually seems to be , , according the the ) How to reproduce it (as minimally and precisely as possible): Attempt to create a PSP with a rule set to Anything else we need to know?: I don't think so Environment: Kubernetes version (use ): , looks to affect , and doc as well Cloud provider or hardware configuration: IBM Cloud OS (e.g: ):Kernel (e.g. ): Install tools: Others:
/sig docs
/assign
thanks will send out a fix next week
I wonder whether this is a bug in implementation or the document. Is this really a documentation issue?
yes, RunAsGroup does not support MustRunAsNonRoot
Got it. Thank you!
/priority important-soon
Change:
// Create the subPath directory on the host existing := path.Join(source.Path, subPath) <del> externalIP, err := framework.GetNodeExternalIP(&nodeList.Items[0]) </del> <ins> nodeIP, err := framework.GetNodeExternalIP(&nodeList.Items[0]) if err != nil { nodeIP, err = framework.GetNodeInternalIP(&nodeList.Items[0]) } </ins> framework.ExpectNoError(err) <del> result, err := framework.SSH(fmt.Sprintf("mkdir -p %s", existing), externalIP, framework.TestContext.Provider) </del> <ins> result, err := framework.SSH(fmt.Sprintf("mkdir -p %s", existing), nodeIP, framework.TestContext.Provider) </ins> framework.LogSSHResult(result) framework.ExpectNoError(err) if result.Code != 0 {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: "[sig-storage] HostPath [It] should support existing single file subPath" test failed on environments which don't support external IPs like What you expected to happen: The test can pass successfully. How to reproduce it (as minimally and precisely as possible): just kick: Environment: Kubernetes version (use ): v1.11.1 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): Ubuntu 16.04.4 LTS Kernel (e.g. ): 4.4.0-134-generic Install tools: kubeadm Others:
/sig storage
Change:
} } <ins> func TestNestedDecodeStrictDecodingError(t *testing.T) { strictErr := runtime.NewStrictDecodingError([]error{fmt.Errorf("duplicate field")}) n := &testNestedDecodable{nestedErr: strictErr} decoder := &mockSerializer{obj: n} codec := NewCodec(nil, decoder, nil, nil, nil, nil, nil, nil, "TestNestedDecode") o, _, err := codec.Decode([]byte(`{}`), nil, n) if strictErr, ok := runtime.AsStrictDecodingError(err); !ok || err != strictErr { t.Errorf("unexpected error: %v", err) } if o != n { t.Errorf("did not successfully decode with strict decoding error: %v", o) } if !n.nestedCalled { t.Errorf("did not invoke nested decoder") } } </ins> func TestNestedEncode(t *testing.T) { n := &testNestedDecodable{nestedErr: fmt.Errorf("unable to decode")} n2 := &testNestedDecodable{nestedErr: fmt.Errorf("unable to decode 2")}

Discussion:
With the addition of server side validation in 1.23, it is now possible for a call to successfully decode it’s data and return a non-nil error when there are strict decoding errors (e.g. duplicate/unknown fields). This means that callers of can distinguish between fatal errors (that cause decoding to fail) and strict decoding errors (that still allow the decode to succeed) by inspecting the target object (to see if it was successfully decoded into) and the error itself (to see if it is a ) With the NestedObjectDecoder however, it only returns an error from giving no indication whether a strict decoding error it has returned comes from an internal decode step that short circuited (by not accounting for strict decoding errors) or actually did successfully decode, but also encountered strict decoding errors. We propose taking a few actions to minimize the possibility of erroneous short-circuiting from Document how all nested decoders should only return strict decoding errors if all decoding is successful or return only non-strict decoding (ie. fatal errors). Document this for all known in-tree and out-of-tree . Update in-tree nested decoders to do the above mentioned behavior (which is just the kube-scheduler) Long-term solutions to better guarantee that no erroneous short-circuiting is taking place could include deprecating the current interface in favor of one that returns both the target object that was decoded into along with an error return a special error type specific to indicating that all internal decoding was successful.
/sig api-machinery
/triage accepted
Change:
# but we only need to rebuild targets if the contents actually changed.  That # is what the .stamp file represents. $(foreach dir, $(CONVERSION_DIRS), $(META_DIR)/$(dir)/$(CONVERSIONS_META)): <del> TAGS=$$(grep -h '^// *+k8s:conversion-gen=' $</*.go    </del> <ins> TAGS=$$(grep --color=never -h '^// *+k8s:conversion-gen=' $</*.go   </ins> | cut -f2- -d=                                     | sed 's|$(PRJ_SRC_PATH)/||');                     mkdir -p $(@D);                                       

Discussion:
Using the grep from OSX, fails when GREPOPTIONS/GREPCOLOR is set as shown below (). Workaround : unset GREPOPTIONS/GREPCOLOR Note that using GNU grep using brew install will show that GREPOPTIONS shows immediately that GREP_OPTIONS may be interfering with make ()
oh, here's badly manged conversion-
Will look, thanks. For make-related bugs, please @ me directly.
Will do. thanks
This breaks building kubernetes inside Alpine Linux:
I'm pressing more and more on the idea that the only supported build is the dockerized build. Trying to accomodate every random environment is just too taxing. , Marc Villacorta wrote:
I agree with We can support the stuff in to run on mac to get you dockerized but everything else is only supported in there. I've worked around a few BSD/OSX things in but it isn't fun. We should try to keep that stuff isolated.
I agree, with the usual caveat that we need to be doing all of the build in one container with as little as possible happening outside. OS X tends to have old and broken versions of important programs, which is terrible. We discussed setting up CI for it but it's not going to happen in the near term. Alpine/Busybox purposefully omit features from their versions for good reasons, but it's still more work to support than it's worth.
Ok, I will re-think my workflow.
How did you find yourself building in Alpine, in I may ask? , Marc Villacorta wrote:
nothing is forcing me to use Alpine I just like the distro. I run stuff on CoreOS and my aim is to solve the build-deliver-run pipeline with a single small container. By the way, I have the problem installing the GNU package :-)
Change:
func testMonitoringUsingHeapsterInfluxdb(c clientset.Interface) { // Check if heapster pods and services are up. <del> expectedPods, err := verifyExpectedRcsExistAndGetExpectedPods(c) framework.ExpectNoError(err) framework.ExpectNoError(expectedServicesExist(c)) // TODO: Wait for all pods and services to be running. </del> <ins> var expectedPods []string rcErr := fmt.Errorf("failed to verify expected RCs within timeout") serviceErr := fmt.Errorf("failed to verify expected services within timeout") err := wait.PollImmediate(sleepBetweenAttempts, initializationTimeout, func() (bool, error) { expectedPods, rcErr = verifyExpectedRcsExistAndGetExpectedPods(c) if rcErr != nil { framework.Logf("Waiting for expected RCs (got error: %v)", rcErr) return false, nil } serviceErr = expectedServicesExist(c) if serviceErr != nil { framework.Logf("Waiting for expected services (got error: %v)", serviceErr) return false, nil } return true, nil }) if err != nil { framework.ExpectNoError(rcErr) framework.ExpectNoError(serviceErr) framework.Failf("Failed to verify RCs and services within timeout: %v", err) } </ins> expectedNodes, err := getAllNodesInCluster(c) framework.ExpectNoError(err)

Discussion:
The following E2E test is failing in the GCE 1.5-1.6 upgrade jobs. Please take a look and let me know ASAP if this is a 1.6 blocker or not (I think it may be a flake, but need you to confirm). https://k8s- Expected error: <*errors.errorString | 0xc421d5ef10: { s: "expected to find one replica for RC or deployment with label heapster but got 0", } expected to find one replica for RC or deployment with label heapster but got 0 not to have occurred
/assign
can you help get this looked at and triaged ASAP? Thanks.
I pinged by email. He's really the one who should look at this.
The problem seems to be not with the test itself but with Kubernetes or test framework, since the test failed on starting Heapster. I'll investigate more later today.
I haven't got time to investigate. This seems to be unrelated to monitoring itself, so any help during MTV day would be great. If not I'll try to fix this tomorrow
thanks
The problem is in , in function . The function is called immediately from , w/o waiting for system pods (heapster) to start. We should give some time for heapster to become ready, as it takes few minutes after cluster creation.
CC
thanks a lot for investigation! is going to fix it.
Change:
t.Errorf("autoSubnetInList() = %v, expected: %v", gotNames, expectedNames) } } <ins> func TestFirewallToGcloudArgs(t *testing.T) { firewall := compute.Firewall{ Description:  "Last Line of Defense", TargetTags:   []string{"jock-nodes", "band-nodes"}, SourceRanges: []string{"3.3.3.3/20", "1.1.1.1/20", "2.2.2.2/20"}, Allowed: []*compute.FirewallAllowed{ { IPProtocol: "udp", Ports:      []string{"321", "123-456", "123"}, }, { IPProtocol: "tcp", Ports:      []string{"321", "123-456", "123"}, }, }, } got := firewallToGcloudArgs(&firewall, "my-project") var e = `--description "Last Line of Defense" --allow tcp:123,tcp:123-456,tcp:321,udp:123,udp:123-456,udp:321 --source-ranges 1.1.1.1/20,2.2.2.2/20,3.3.3.3/20 --target-tags band-nodes,jock-nodes --project my-project` if got != e { t.Errorf("%q does not equal %q", got, e) } } </ins>

Discussion:
/kind bug /sig network /assign What happened: For events being generated within the GCE cloudprovider, slices of firewall parameters are not being sorted before converted into a string. Due to random ordering, this may result in the same line being repeated.
Change:
package app import ( <del> "github.com/prometheus/client_golang/prometheus" </del> "net/http" goruntime "runtime" <ins> "github.com/prometheus/client_golang/prometheus" </ins> genericapifilters "k8s.io/apiserver/pkg/endpoints/filters" apirequest "k8s.io/apiserver/pkg/endpoints/request" apiserver "k8s.io/apiserver/pkg/server"

Discussion:
The kube-apiserver is protected, so it's responses should not be cached. The only known exception is for openapi data which is not sensitive, which is large, and which has etags. /assign
/sig api-machinery
Change:
// Log is intended to be called once at the end of your request handler, via defer func (rl *respLogger) Log() { latency := time.Since(rl.startTime) <del> glog.V(2).Infof("%s %s: (%v) %v%v%v", rl.req.Method, rl.req.RequestURI, latency, rl.status, rl.statusStack, rl.addedInfo) </del> <ins> if glog.V(2) { glog.InfoDepth(1, fmt.Sprintf("%s %s: (%v) %v%v%v", rl.req.Method, rl.req.RequestURI, latency, rl.status, rl.statusStack, rl.addedInfo)) } </ins> } // Header implements http.ResponseWriter.

Discussion:
the file and line for these log statements is in the That's not helpful I1031 11:09:06. ] 'foo' has no storage object I1031 11:09:06. ] 'pods' is not a redirector I'd rather see Maybe use runtime.Caller in httplog to somehow fake the log to come from the caller's file/line.
Yeah-- actually this should be a feature of the glog package. Would be awesome to do:
Followup: glog is an opensource copy of a google-internal library; there's already something enabling this internally; we'll try to get a new version pushed externally in the next week or so. Then we can fix this.
Awesome. On Oct 31, 2014 2:53 PM, "Daniel Smith" wrote:
should meet your requirements.
+1, I would love to have this.
Change:
errorType string test      string }{ <del> /*{ </del> <ins> { </ins> pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:   "fakename",

Discussion:
A significant number of the of are commented out, possibly was done by mistake in the past. I uncommented the tests to see if they pass, but one of them failed. What we need is to uncomment those tests, fix the one that is not passing and remove the redundant ones if there are any. /sig scheduling /help
/assign I will be moving some of the tests to unit tests and leave a cleaner set of integration tests.
/remove-help
would you like to take this? I can provide guidance.
/help /unassign
/assign
/remove-help
Change:
if info.IsDir() { mask |= os.ModeSetgid <ins> mask |= execMask </ins> } err = os.Chmod(path, info.Mode()|mask)

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?: What happened: I am using Persistent Local Volumes. The mountpoints for it are set up with 0700 permissions. When running a pod with a user other than root, and with fsGroup to allow access to the volume, the permissions are wrong and the pod cannot use the volume. The permissions are changed from 0700 to 2760. What you expected to happen: fsGroup makes the volume usable for the group by setting the permissions to 2770. How to reproduce it (as minimally and precisely as possible): You need a cluster with local volumes whose permissions are set to 0700. pv-permission- As you can see, the permissions are 2760. Since the execute bit is missing for the group, the directory cannot be used. Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.2 Cloud provider or hardware configuration: libvirt/QEMU OS (e.g. from /etc/os-release): CentOS Linux release 7.5.1804 (Core) Kernel (e.g. ): 3.10.0-862.11.6.el7.x8664 SMP Tue Aug 14 21:49:04 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm Others:
/sig storage
The fix is probably to add execute bits here
do you see any problem with setting group execute for fsgroup?
I think that execute should be fine.
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. 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