jiebi/CodeConvo huggingface dataset:
Change:
Currently, fluentd on master is unable to ingest logs from master node on GCE. After some investigation it turned out that DNS (10.0.0.10) is unavailable from inside the fluentd container: no host can be resolved, doesn't depend on the fluentd image version. Fluentd container on the minion node works, no problems whatsoever. Steps to reproduce: Spin up a cluster on GCE Check fluentd logs on the master node If cluster is built from 1.5 branch, fluentd on master node works, logs are being ingested. CC
cc
What is the commit that your cluster is built with?
From HEAD today, can't say the exact commit But the problem actually is there for quite some time, for two weeks at least.
There are two issues at work here: -proxy is not run on the master node, which means service VIPs will not be accessible from the master. pod that runs on the master uses ClusterFirst, which means the points to the service VIP. One of those needs to change for DNS to work.
OK, thanks! I will try to change the dnsPolicy tomorrow to see if it helps Could you please explain what have changed since 1.5? For what I know, fluentd was moved to DaemonSet, is this the reason?
-- this looks like your change:
As far as I know, the master has never run kube-proxy
The migration to DS should be unrelated here. We used to have fluentd as manifest pod before.
Using didn't help Is it possible to have the same for fluentd on master as the rest of the pods?
Define "doesn't work" after this? should show whatever the host machine has.
Sorry, my bad, was testing with the wrong setup. Using did indeed help for fluentd with Stackdriver, thanks a lot!

Discussion:
annotations: scheduler.alpha.kubernetes.io/critical-pod: '' spec: <ins> dnsPolicy: Default </ins> containers: - name: fluentd-gcp image: gcr.io/google_containers/fluentd-gcp:1.38
Change:
Encountered this error while running on master: Should we set to by default? cc
Why is it empty? Would be better?
seems to expect $(whoami) based on the value of that variable for my machine. I can make that change if you would like.
Can you keep as an option if it is specified? returns a 6 digit numeric value on my machine (corporate provisioned) and that is incompatible with GCI images, as well as error-ing out during e2e provisioning.
that is a great idea, so should be defaulting to whoami in the case where it has not been defined.
OK, will file an PR to fix this.
Filed PR at . PTAL

Discussion:
CGROUP_ROOT=${CGROUP_ROOT:-""} # name of the cgroup driver, i.e. cgroupfs or systemd CGROUP_DRIVER=${CGROUP_DRIVER:-""} <ins> # owner of client certs, default to current user if not specified USER=${USER:-$(whoami)} </ins> # enables testing eviction scenarios locally. EVICTION_HARD=${EVICTION_HARD:-"memory.available<100Mi"}
Change:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "scheduledjob" (and try to understand from the title whether this could be related to my issue) "find job" Is this a BUG REPORT or FEATURE REQUEST? (choose one): Feature request. Kubernetes version (use ): ~ Environment: Cloud provider or hardware configuration: AWS via kube-aws 0.93-ish What happened: I'm using scheduled jobs, and then try to review the logs of the job executions. I have multiple scheduled jobs in the system. Generally this works via: ... search for the ones that seem to relate to my scheduled job name . Repeat this if there are more than one execution. the whole list for previous jobs What you expected to happen: I'd love to be able to filter the initial job list already to only include jobs created by a specific scheduled job, something like . For that to happen I need scheduledjob to label the created job, just like a job already labels the pods executing it.
can you include labels in the cronjob's jobTemplate spec?
Yes, that is certainly possible. I filed this ticket mainly because I think this should happen automatically: Any resource produced by a resource I created should be labeled such that I can find these resources back easily.
/sig apps
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. Prevent issues from auto-closing with an comment. 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 /remove-lifecycle stale
From my perspective this is still something I'd like to see.
I've given this a go. There was actually a todo for it in the comments.
/remove-lifecycle rotten
Lovely, thanks a lot!

Discussion:
// getJobFromTemplate makes a Job from a CronJob func getJobFromTemplate(sj *batchv1beta1.CronJob, scheduledTime time.Time) (*batchv1.Job, error) { <del> // TODO: consider adding the following labels: // nominal-start-time=$RFC_3339_DATE_OF_INTENDED_START -- for user convenience // scheduled-job-name=$SJ_NAME -- for user convenience </del> labels := copyLabels(&sj.Spec.JobTemplate) annotations := copyAnnotations(&sj.Spec.JobTemplate) // We want job names for a given nominal start time to have a deterministic name to avoid the same job being created twice
Change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: When I create a docker registry secret, the is also a MUST, I think we should make this parameter as optional as there is no need always put when creating a docker registry secret. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
Agree it should not be required
Did this change get reverted? I do not see as optional on stable.
I feel that this code should be changed because "--docker-email flag" is no longer required.
error: flag docker-email is required. On kubenetes 1.10.3, the above error message still exists
The field is still required. This is very frustrating as does not require an email but Kubernetes does? Is there a good reason for this?
Why is this closed? As far as I can see it is still required?

Discussion:
if err != nil { return err } <del> requiredFlags := []string{"docker-username", "docker-password", "docker-email", "docker-server"} </del> <ins> requiredFlags := []string{"docker-username", "docker-password", "docker-server"} </ins> for _, requiredFlag := range requiredFlags { if value := cmdutil.GetFlagString(cmd, requiredFlag); len(value) == 0 { return cmdutil.UsageErrorf(cmd, "flag %s is required", requiredFlag)
Change:
Kubernetes version: master branch. Environment: OSX. What happened: cc/
I just took as an example. When running on OSX, always returns . However, on Linux, the actual calling path is , which will return when is . When get , will not run, which will call methods TearDownPod. And this is why on OSX calls to testing.MockNetworkPlugin.TearDownPod are missing.
Thanks. Could you file a PR to fix this?

Discussion:
} func containerIsNetworked(containerName string) bool { <del> return false </del> <ins> return containerName == PodInfraContainerName </ins> } // Returns nil as both Seccomp and AppArmor security options are not valid on Windows
Change:
I am running locally which is failing with the following error: Is this expected? Is there a way to change that path? cc
starts kubelet as a normal user, which doesn't have the permission to create the socket in . I think we can create a new kubelet flag to pass this path. /cc
From test- at "# This command checks that the built commands can function together for simple scenarios. It does not require Docker." In this case, can we update this not require On another hand, why test-cmd requires a working Kubelet which does nothing today?
Yes kubectl tests should not really require kubelet. I think it should be fine to remove it if the tests pass without it. cc who own this I think.
See . It passed locally for me.

Discussion:
kube::util::wait_for_url "http://127.0.0.1:${CTLRMGR_PORT}/healthz" "controller-manager" } <del> function run_kubelet() { # Only run kubelet on platforms it supports if [[ "$(go env GOHOSTOS)" == "linux" ]]; then kube::log::status "Building kubelet" make -C "${KUBE_ROOT}" WHAT="cmd/kubelet" kube::log::status "Starting kubelet in masterless mode" "${KUBE_OUTPUT_HOSTBIN}/kubelet"  --really-crash-for-testing=true  --root-dir=/tmp/kubelet.$$  --cert-dir="${TMPDIR:-/tmp/}"  --docker-endpoint="fake://"  --hostname-override="127.0.0.1"  --address="127.0.0.1"  --port="$KUBELET_PORT"  --healthz-port="${KUBELET_HEALTHZ_PORT}" 1>&2 & KUBELET_PID=$! kube::util::wait_for_url "http://127.0.0.1:${KUBELET_HEALTHZ_PORT}/healthz" "kubelet(masterless)" kill ${KUBELET_PID} 1>&2 2>/dev/null kube::log::status "Starting kubelet in masterful mode" "${KUBE_OUTPUT_HOSTBIN}/kubelet"  --really-crash-for-testing=true  --root-dir=/tmp/kubelet.$$  --cert-dir="${TMPDIR:-/tmp/}"  --docker-endpoint="fake://"  --hostname-override="127.0.0.1"  --address="127.0.0.1"  --api-servers="${API_HOST}:${API_PORT}"  --port="$KUBELET_PORT"  --healthz-port="${KUBELET_HEALTHZ_PORT}" 1>&2 & KUBELET_PID=$! kube::util::wait_for_url "http://127.0.0.1:${KUBELET_HEALTHZ_PORT}/healthz" "kubelet" fi } # Creates a node object with name 127.0.0.1 if it doesnt exist already. # This is required for non-linux platforms where we do not run kubelet. </del> <ins> # Creates a node object with name 127.0.0.1. This is required because we do not # run kubelet. </ins> function create_node() { <del> if [[ "$(go env GOHOSTOS)" == "linux" ]]; then kube::util::wait_for_url "http://127.0.0.1:${API_PORT}/api/v1/nodes/127.0.0.1" "apiserver(nodes)" else # create a fake node kubectl create -f - -s "http://127.0.0.1:${API_PORT}" << __EOF__ </del> <ins> kubectl create -f - -s "http://127.0.0.1:${API_PORT}" << __EOF__ </ins> { "kind": "Node", "apiVersion": "v1",

} } __EOF__ <del> fi </del> } kube::log::status "Running kubectl tests for kube-apiserver"

setup run_kube_apiserver run_kube_controller_manager <del> run_kubelet </del> create_node SUPPORTED_RESOURCES=("*") # WARNING: Do not wrap this call in a subshell to capture output, e.g. output=$(runTests)
Change:
the timing is suspicious. Your pull merged, right?
it did, i will take a look.

Discussion:
"k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/apimachinery/pkg/watch" restclient "k8s.io/client-go/rest" "k8s.io/client-go/tools/record"

} waitForQuota(t, quota, clientset) <del> if _, err := clientset.Core().Pods(ns.Name).Create(pod); err != nil { </del> <ins> // attempt to create a new pod once the quota is propagated err = wait.PollImmediate(5*time.Second, time.Minute, func() (bool, error) { // retry until we succeed (to allow time for all changes to propagate) if _, err := clientset.Core().Pods(ns.Name).Create(pod); err == nil { return true, nil } return false, nil }) if err != nil { </ins> t.Fatalf("unexpected error: %v", err) } }
Change:
https://k8s-
is looking into this.
Seems like a lot of flakes are caused by the watch issue: Maybe we should switch to polling in the test.
I'm taking this
Opened a fix that will at minimum give us more info, but also increases timeout
This is the last failure before my changed merged: https://k8s- Still waiting for a post.
Do you think is enough to address this issue? Or there are some other pending issues in watching code? Can we close this one?
We can close this, the issue is almost certainly the one fixed.

Discussion:
By("verifying pod deletion was observed") deleted := false <del> timeout := false </del> var lastPod *v1.Pod <del> timer := time.After(30 * time.Second) for !deleted && !timeout { </del> <ins> timer := time.After(2 * time.Minute) for !deleted { </ins> select { case event, _ := <-w.ResultChan(): <del> if event.Type == watch.Deleted { </del> <ins> switch event.Type { case watch.Deleted: </ins> lastPod = event.Object.(*v1.Pod) deleted = true <ins> case watch.Error: framework.Logf("received a watch error: %v", event.Object) Fail("watch closed with error") </ins> } case <-timer: <del> timeout = true </del> <ins> Fail("timed out waiting for pod deletion") </ins> } } if !deleted {
Change:
I saw this in the kubelet logs: and were working from the host. describe node showed that it had stopped posting node status: tcpdump showed requests to the IAM metadata endpoint, but it showed no requests to the EC2 local-ipv4 / public-ipv4 endpoints. Restarting kubelet caused it to recover, and we saw requests to the local-ipv4 / public-ipv4 endpoints again.
Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.
do you want this in v1.7? is this the right sig to own this issue?
I a richer log message in to help diagnostics. I'm not sure if this behaviour is wrong actually. The kubelet goes offline, the node gets evicted etc. The only challenge is if the metadata service goes down cluster-wide. We don't want to just shut-down. When we have sig/cloud we can talk about it there I guess.
/remove-priority P0 /priority critical-urgent (I'm not actually sure this is the right priority, just trying to remove the old priority/PN labels)
Thanks - punting to 1.8 as I don't think this behaviour is necessarily wrong, though it is suboptimal if (for some reason) the metadata service went down AWS-wide.
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.8 milestone for more than 7 days: kind: Must specify exactly one of [, , ]. Removing it from the milestone. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/close Taking an educated guess that this isn't going to get fixed given that we've seen no additional reports of this happening here. Please /reopen if this is still happening

Discussion:
internalIP, err := c.metadata.GetMetadata("local-ipv4") if err != nil { <del> return nil, err </del> <ins> return nil, fmt.Errorf("error querying AWS metadata for %q: %v", "local-ipv4", err) </ins> } addresses = append(addresses, v1.NodeAddress{Type: v1.NodeInternalIP, Address: internalIP})
Change:
The last 4 runs of https://k8s- have failed on the and steps with : https://k8s- https://k8s- https://k8s- https://k8s- The GCE version of this test suite appears to be fine. This is blocking the submit queue. CC
Is there a way to see what does /cluster/gce/list- output in the runs... exit status 1 is not very informative
Here is a non-gke failure: https://k8s-
Given that the last thing output from the listing of resource is: I would bet that the defined is failing to find a match from (see )
Hummm I ran it locally against but did not get the same failure
you might be more familiar with list-
This started happening on the 16th and became more regular on the 18th-- do you think the new janitor code might be causing this? More details here:
is giving me exit status 1, let me find which command it is.
Yeah, and have figured it out. Because of the janitor, we no longer have any default firewall rules in these projects (which might be a bug), and so now the is failing. I think in the distant past always printed out a header, even if nothing was found, though it hasn't done that in a long time. Fix for is to the on L52. We may also want to decide if we should be deleting the default firewalls.
We'll want to cherrypick that to the old branches, too.
hummm I'll let it skip default-firewall
Keeping open until we've verified fix

Discussion:
while true; do if result=$(gcloud compute ${resource} list --project=${PROJECT} ${@:2}); then if [[ ! -z "${GREP_REGEX}" ]]; then <del> result=$(echo "${result}" | grep "${GREP_REGEX}") </del> <ins> result=$(echo "${result}" | grep "${GREP_REGEX}" || true) </ins> fi echo "${result}" return
Change:
When setting for other container runtime, won't start kubelet correctly because cri is disabled : Is there any reason of disabling cri at ? cc
no, that wasn't supposed to go in. I was testing something and it slipped in accidentally. I'll open a PR to fix.
Ah I see your PR for it. Thanks!

Discussion:
CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-"docker"} CONTAINER_RUNTIME_ENDPOINT=${CONTAINER_RUNTIME_ENDPOINT:-""} IMAGE_SERVICE_ENDPOINT=${IMAGE_SERVICE_ENDPOINT:-""} <ins> ENABLE_CRI=${ENABLE_CRI:-"true"} </ins> RKT_PATH=${RKT_PATH:-""} RKT_STAGE1_IMAGE=${RKT_STAGE1_IMAGE:-""} CHAOS_CHANCE=${CHAOS_CHANCE:-0.0}

fi sudo -E "${GO_OUT}/hyperkube" kubelet ${priv_arg} <del> --enable-cri=false  </del> <ins> --enable-cri="${ENABLE_CRI}"  </ins> --v=${LOG_LEVEL}  --chaos-chance="${CHAOS_CHANCE}"  --container-runtime="${CONTAINER_RUNTIME}"
Change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): rollout status namespace Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Macbook Pro 2015 OS (e.g. from /etc/os-release): Mac OSX Sierra Kernel (e.g. ): Install tools: Others: What happened: , where does the following: Describes a Deployment object Sets a non-default namespace in the metadata . An error message says the resource was not found . The response shows the status of the rollout. What you expected to happen: I expected to work as well by using the namespace that is set inside for the rollout status request. How to reproduce it (as minimally and precisely as possible): the following file as (taken from the but updated to add the namespace): Returns Returns Anything else we need to know: We've seen this issue on 1.5.1 as well, and also on Ubuntu. The recreate instructions above were performed on a fresh minikube setup.
I also noticed this today. The node is using version 1.5.2 and we are using latest gcloud SDK components (v146). At the moment I have to use
This issue also exists on kubectl built from HEAD.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale

Discussion:
} // check if deployment's has finished the rollout <del> status, done, err := statusViewer.Status(cmdNamespace, info.Name, revision) </del> <ins> status, done, err := statusViewer.Status(info.Namespace, info.Name, revision) </ins> if err != nil { return err }

return intr.Run(func() error { _, err := watch.Until(0, w, func(e watch.Event) (bool, error) { // print deployment's status <del> status, done, err := statusViewer.Status(cmdNamespace, info.Name, revision) </del> <ins> status, done, err := statusViewer.Status(info.Namespace, info.Name, revision) </ins> if err != nil { return false, err }
Change:
The bug is introduced in The oldData, newData in seem always to be the same. So it always showing . After digging a bit, I found that: the place where we save the may be wrong. sometimes oldData and newData are different because of different s, even though the patch is . cc:
cc
info.Object is updated by the info.Refresh call. We should compute old data prior to refreshing the info bug was introduced in
I think the second bug is because using read from stream has less infomation than when you fetch from server, so but didn't

Discussion:
} count++ <del> if err := info.Refresh(patchedObj, true); err != nil { return err } </del> oldData, err := json.Marshal(info.Object) if err != nil { return err

dataChangedMsg = "patched" } <ins> // After computing whether we changed data, refresh the resource info with the resulting object if err := info.Refresh(patchedObj, true); err != nil { return err } </ins> if len(options.OutputFormat) > 0 && options.OutputFormat != "name" { return cmdutil.PrintResourceInfoForCommand(cmd, info, f, out) }

} } <ins> func TestPatchNoop(t *testing.T) { _, svc, _ := testData() getObject := &svc.Items[0] patchObject := &svc.Items[0] f, tf, codec, _ := cmdtesting.NewAPIFactory() tf.UnstructuredClient = &fake.RESTClient{ APIRegistry:          api.Registry, NegotiatedSerializer: unstructuredSerializer, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { switch p, m := req.URL.Path, req.Method; { case p == "/namespaces/test/services/frontend" && m == "PATCH": return &http.Response{StatusCode: 200, Header: defaultHeader(), Body: objBody(codec, patchObject)}, nil case p == "/namespaces/test/services/frontend" && m == "GET": return &http.Response{StatusCode: 200, Header: defaultHeader(), Body: objBody(codec, getObject)}, nil default: t.Fatalf("unexpected request: %#vn%#v", req.URL, req) return nil, nil } }), } tf.Namespace = "test" // No-op { buf := bytes.NewBuffer([]byte{}) cmd := NewCmdPatch(f, buf) cmd.Flags().Set("namespace", "test") cmd.Flags().Set("patch", `{}`) cmd.Run(cmd, []string{"services", "frontend"}) if buf.String() != "service "baz" not patchedn" { t.Errorf("unexpected output: %s", buf.String()) } } // Patched { copied, _ := api.Scheme.DeepCopy(patchObject) patchObject = copied.(*api.Service) if patchObject.Annotations == nil { patchObject.Annotations = map[string]string{} } patchObject.Annotations["foo"] = "bar" buf := bytes.NewBuffer([]byte{}) cmd := NewCmdPatch(f, buf) cmd.Flags().Set("namespace", "test") cmd.Flags().Set("patch", `{"metadata":{"annotations":{"foo":"bar"}}}`) cmd.Run(cmd, []string{"services", "frontend"}) if buf.String() != "service "baz" patchedn" { t.Errorf("unexpected output: %s", buf.String()) } } } </ins> func TestPatchObjectFromFileOutput(t *testing.T) { _, svc, _ := testData()