jiebi/CodeConvo huggingface dataset:
Change:
It'd be similar to Linux , a command to search the man page files
Why not just make do a search if it doesn't have an exact match?
sounds good.
SGTM
- Can be useful in this issue
I will work on this issue, if nobody is already working on it ( is not working on it).
thanks!
I focused currently on a bit different stuff, sorry. So I will start/finish it later. If anyone want to take over this one, feel free for now.

Discussion:
f.BindFlags(cmds.PersistentFlags()) f.BindExternalFlags(cmds.PersistentFlags()) <ins> cmds.SetHelpCommand(NewCmdHelp(f, out)) </ins> // From this point and forward we get warnings on flags that contain "_" separators cmds.SetGlobalNormalizationFunc(flag.WarnWordSepNormalizeFunc)

<ins> /* Copyright 2016 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package cmd import ( "io" "strings" "github.com/spf13/cobra" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" ) const help_long = `Help provides help for any command in the application. Simply type kubectl help [path to command] for full details.` func NewCmdHelp(f *cmdutil.Factory, out io.Writer) *cobra.Command { cmd := &cobra.Command{ Use:   "help [command] | STRING_TO_SEARCH", Short: "Help about any command", Long:  help_long, Run: RunHelp, } return cmd } func RunHelp(cmd *cobra.Command, args []string) { foundCmd, a, err := cmd.Root().Find(args) // NOTE(andreykurilin): actually, I did not find any cases when foundCmd can be nil, //   but let's make this check since it is included in original code of initHelpCmd //   from github.com/spf13/cobra if foundCmd == nil { cmd.Printf("Unknown help topic %#q.n", args) cmd.Root().Usage() } else if err != nil { // print error message at first, since it can contain suggestions cmd.Println(err) argsString := strings.Join(args, " ") var matchedMsgIsPrinted bool = false for _, foundCmd := range foundCmd.Commands() { if strings.Contains(foundCmd.Short, argsString) { if !matchedMsgIsPrinted { cmd.Printf("Matchers of string '%s' in short descriptions of commands: n", argsString) matchedMsgIsPrinted = true } cmd.Printf("  %-14s %sn", foundCmd.Name(), foundCmd.Short) } } if !matchedMsgIsPrinted { // if nothing is found, just print usage cmd.Root().Usage() } } else if len(a) == 0 { // help message for help command :) cmd.Root().Usage() } else { helpFunc := foundCmd.HelpFunc() helpFunc(foundCmd, args) } } </ins>
Change:
During the startup process of kubelet, we have Since we have following Code segment 1 and 2 seems dup to me. Am i getting this wrong?

Discussion:
runtime.ReallyCrash = s.ReallyCrashForTesting rand.Seed(time.Now().UTC().UnixNano()) <del> credentialprovider.SetPreferredDockercfgPath(s.RootDirectory) glog.V(2).Infof("Using root directory: %v", s.RootDirectory) </del> // TODO(vmarmol): Do this through container config. oomAdjuster := kcfg.OOMAdjuster if err := oomAdjuster.ApplyOOMScoreAdj(0, int(s.OOMScoreAdj)); err != nil {

capabilities.Setup(kcfg.AllowPrivileged, privilegedSources, 0) credentialprovider.SetPreferredDockercfgPath(kcfg.RootDirectory) <ins> glog.V(2).Infof("Using root directory: %v", kcfg.RootDirectory) </ins> builder := kcfg.Builder if builder == nil {
Change:
Failure:
Assigning to per
do you have reason to think this is still happening? if not, want to close it?
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Test passed with the latest code, suggest to close it firstly; if happened again, please assign it to me directly :). Head: OS: Test command: Test output:
- this is flake, not permanent failure (as almost all issues with "kind/flake"; running a test once most probably will not fail and that's expected
thanks for your input. The log is gone, let me check the code to see if any clue :).
Here maybe the root case after reviewing the code: the do the following steps: into current time () item from current time () the wait period () The problem is that: the timer start at "Step 1" in in , if there's any delay between "Step 1" & "Step 2", the wait period will be shorter than expected. The proposed PR is to record time before adding item. If any comments, please let me know. Thanks klaus

Discussion:
dq := NewDelayQueue() delay := 2 * time.Second <del> dq.Add(&testjob{d: delay}) </del> before := time.Now() <ins> dq.Add(&testjob{d: delay}) </ins> x := dq.Pop() now := time.Now()
Change:
Observed on but I don't think it's the pr. Similar to but I don't think I can dupe the stack traces.

Discussion:
Process: s.HandleDeltas, } <del> s.controller = New(cfg) </del> func() { s.startedLock.Lock() defer s.startedLock.Unlock() <ins> s.controller = New(cfg) </ins> s.started = true }()

} func (s *sharedIndexInformer) HasSynced() bool { <ins> s.startedLock.Lock() defer s.startedLock.Unlock() if s.controller == nil { return false } </ins> return s.controller.HasSynced() }
Change:
Need to finish so the client allows you to select an init container, and verify the kubelet works correctly.
(this is a nice intersection of new in 1.3, node and usability, if anyone wants to give it a shot. Pretty sure Clayton is busier than I am and I don't think I'll get to it)
Will be happy to review any changes - should be fairly straightforward.
Yes, init containers are "run to completion" always. , harryz wrote:
IIUC when the init containers of pod have not complete, the pod should be in status, which means will fail, if init containers run to completion, they will exit, still fail. I don't know what you mean exec should work on init containers?
the init container is still up and running even when the pod is in pending, we should be able to exec and debug why it's hung, for example.
add a straightforward exec implementation ptal.

Discussion:
* [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager <del> ###### Auto generated by spf13/cobra on 5-Apr-2016 </del> <ins> ###### Auto generated by spf13/cobra on 3-Jun-2016 </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_exec.md?pixel)]()

return err } <del> if pod.Status.Phase != api.PodRunning { return fmt.Errorf("pod %s is not running and cannot execute commands; current phase is %s", p.PodName, pod.Status.Phase) } </del> containerName := p.ContainerName if len(containerName) == 0 { glog.V(4).Infof("defaulting container name to %s", pod.Spec.Containers[0].Name)

return true } } <ins> for _, c := range pod.Spec.InitContainers { if c.Name == containerName { return true } } </ins> return false }
Change:
container manager setup node routine should ensure that cpu and memory cgroups for container runtime are of the same value, and warn if they are equal to . For background, on systemd environments, the default unit file for has CPU and Memory accounting not enabled, so the /proc/.../cgroup file reports as cpu cgroup.
/cc - I will send a bug-fix for 1.3 for this in next couple days.
/cc
Looking forward to the fix
The PR that fixes this issue was prematurely merged by the merge bot so re-opening.

Discussion:
return utilerrors.NewAggregate(errs) } <del> // Gets the (CPU) container the specified pid is in. </del> <ins> // getContainer returns the cgroup associated with the specified pid. // It enforces a unified hierarchy for memory and cpu cgroups. // On systemd environments, it uses the name=systemd cgroup for the specified pid. </ins> func getContainer(pid int) (string, error) { cgs, err := cgroups.ParseCgroupFile(fmt.Sprintf("/proc/%d/cgroup", pid)) if err != nil { return "", err } <del> cg, ok := cgs["cpu"] if ok { return cg, nil </del> <ins> cpu, found := cgs["cpu"] if !found { return "", cgroups.NewNotFoundError("cpu") } memory, found := cgs["memory"] if !found { return "", cgroups.NewNotFoundError("memory") } // since we use this container for accounting, we need to ensure its a unified hierarchy. if cpu != memory { return "", fmt.Errorf("cpu and memory cgroup hierarchy not unified.  cpu: %s, memory: %s", cpu, memory) } // on systemd, every pid is in a unified cgroup hierarchy (name=systemd as seen in systemd-cgls) // cpu and memory accounting is off by default, users may choose to enable it per unit or globally. // users could enable CPU and memory accounting globally via /etc/systemd/system.conf (DefaultCPUAccounting=true DefaultMemoryAccounting=true). // users could also enable CPU and memory accounting per unit via CPUAccounting=true and MemoryAccounting=true // we only warn if accounting is not enabled for CPU or memory so as to not break local development flows where kubelet is launched in a terminal. // for example, the cgroup for the user session will be something like /user.slice/user-X.slice/session-X.scope, but the cpu and memory // cgroup will be the closest ancestor where accounting is performed (most likely /) on systems that launch docker containers. // as a result, on those systems, you will not get cpu or memory accounting statistics for kubelet. // in addition, you would not get memory or cpu accounting for the runtime unless accounting was enabled on its unit (or globally). if systemd, found := cgs["name=systemd"]; found { if systemd != cpu { glog.Warningf("CPUAccounting not enabled for pid: %d", pid) } if systemd != memory { glog.Warningf("MemoryAccounting not enabled for pid: %d", pid) } return systemd, nil </ins> } <del> return "", cgroups.NewNotFoundError("cpu") </del> <ins> return cpu, nil </ins> } // Ensures the system container is created and all non-kernel threads and process 1
Change:
I saw this as well. Log: Brief discussion in
I think I have a fix for this
Just submitted a PR that I believe fixes this. I was able to get the flakes locally w/o my PR and haven't seen any with it. PTAL!
how did you repro locally? I tried ran this test 1,000 times last night and it passed 1,000 times.
Change the resync period from 1 milli to 1 microsecond. You can also add 'stress -c 8' to the mix. On Friday, May 20, 2016, Matt Liggett wrote:
- FYI
sent which should fix this

Discussion:
package cache import ( <ins> "errors" </ins> "fmt" "math/rand" "strconv"

func TestReflectorResync(t *testing.T) { iteration := 0 stopCh := make(chan struct{}) <ins> rerr := errors.New("expected resync reached") </ins> s := &FakeCustomStore{ ResyncFunc: func() error { iteration++ if iteration == 2 { <del> close(stopCh) </del> <ins> return rerr </ins> } return nil },

} resyncPeriod := 1 * time.Millisecond r := NewReflector(lw, &api.Pod{}, s, resyncPeriod) <del> r.ListAndWatch(stopCh) </del> <ins> err := r.ListAndWatch(stopCh) if err != rerr { t.Errorf("expected exiting from err %v, got: %v", rerr, err) } </ins> if iteration != 2 { t.Errorf("exactly 2 iterations were expected, got: %v", iteration) }
Change:
Not many details in the logs: FAIL 2.721s
I ran tests a few times against recent master but couldn't see this, could it be an edgy case?
i'll look at it
should help a lot, still there will be a short window where the test could get wrong. Patch will follow when is merged.
Today I saw a very similar error to the one reported in , but seeing as that was closed as a dupe of this, adding details here:
this looks like something new. Let's keep this issue open for this unit test flake: I filled for integration test flake you reported.

Discussion:
// can't reliably simulate periodic sync of volumes/claims - it would be // either very timing-sensitive or slow to wait for real periodic sync. func TestControllerSync(t *testing.T) { <ins> expectedChanges := []int{1, 4, 1, 1} </ins> tests := []controllerTest{ // [Unit test set 5] - controller tests. // We test the controller as if

}, } <del> for _, test := range tests { </del> <ins> for ix, test := range tests { </ins> glog.V(4).Infof("starting test %q", test.name) // Initialize the controller

time.Sleep(10 * time.Millisecond) } <ins> count := reactor.getChangeCount() </ins> // Call the tested function err := test.test(ctrl, reactor, test) if err != nil { t.Errorf("Test %q initial test call failed: %v", test.name, err) } <del> reactor.waitTest() </del> <ins> for reactor.getChangeCount() < count+expectedChanges[ix] { reactor.waitTest() } </ins> evaluateTestResults(ctrl, reactor, test, t) }
Change:
The following tests failed multiple times both in GCE and GKE suites: The error message is the same: Logs:
Assigning for fix or triage. cc
I can work on this, as I am writing tests for openstack in .
It would be great!
Huamin, Thanks for jumping on this. Please consider it priority - flaky tests are killing us, and if this turns out to be real, we need it fixed. , Huamin Chen wrote:
sure
These two tests are so flaky that they will block the merge queue for over half of the time it takes to merge a fix. If you think the fix will take more than a day, I'd suggest moving these to the flaky suite until they're fixed.
I'd suggest tagging them flaky ASAP. Whenever they get fixed they can be untagged.
I am okay with moving these to the flaky suite until we can get some focus on it.
PR is , will likely need a manual merge since the SQ is so blocked.
Hang on this looks like it was broken by a PR merged on Sunday: Test Run and earlier are Green. Test Run (after this PR was merged) are Flaky. CC I'll prepare a roll back.
good catch, i'll take a look at the gce attacher.
give me some moments to figure out a fix
I think the appropriate thing to do here was to move them into the flaky suite or revert the offending PR right away, not wait several hours for the fix to pass code review and CI.
Agreed, this could've been handled better.
PR marking tests as flaky () has been merged. will follow up with his PR () to see if he can fix the test, if so, he will move the tests back out of flaky.
Occurrences tracked automatically in . I don't care if you leave this one open too.
Closing this in favor autogenerated

Discussion:
Logf("Warning: kubectl exec encountered i/o timeout.nerr=%vnstdout=%vnstderr=%v)", err, string(stdOutBytes), string(stdErrBytes)) continue } <ins> if strings.Contains(strings.ToLower(string(stdErrBytes)), "container not found") { // Retry on "container not found" errors Logf("Warning: kubectl exec encountered container not found.nerr=%vnstdout=%vnstderr=%v)", err, string(stdOutBytes), string(stdErrBytes)) time.Sleep(2 * time.Second) continue } </ins> } return stdOutBytes, stdErrBytes, err
Change:
Kubelet log is full of errors from tearing down network at HEAD. From the log, a lot of them were the result of trying to access . Note that if you an exited container, the returned PID will be 0. Therefore, my guess is that kubelet tried to tear down the network after the container has already exited. I didn't dig further. could you take a look?
/cc
Is this a dup of ? We can add a safe guard to prevent TearDown to proceed, but it will not solve the root cause. IIUC,the root cause is the race between syncPod and podKiller.
See also
I don't think failed because of this. this is probably caused by , like you said. The fact that we are seeing more errors than before is likely due to , which enforces graceless namespace deletions. Before that, most objects in the e2e were deleted gracefully and the race condition was rarely hit. Now most objects will hit this path. It'd still be a good idea to add a safeguard to check whether the pid is 0.

Discussion:
} // no cached CIDR is Ok during teardown <del> if cidr, ok := plugin.podCIDRs[id]; ok { </del> <ins> cidr, hasCIDR := plugin.podCIDRs[id] if hasCIDR { </ins> glog.V(5).Infof("Removing pod CIDR %s from shaper", cidr) // shaper wants /32 if addr, _, err := net.ParseCIDR(cidr); err != nil {

} } if err := plugin.delContainerFromNetwork(plugin.netConfig, network.DefaultInterfaceName, namespace, name, id); err != nil { <ins> // This is to prevent returning error when TearDownPod is called twice on the same pod. This helps to reduce event pollution. if !hasCIDR { glog.Warningf("Failed to delete container from kubenet: %v", err) return nil } </ins> return err } delete(plugin.podCIDRs, id)
Change:
Another image pull related failure: Looking at the docker logs, it looks like docker is getting a 404 pulling some of the images
The error message looks normal. Kubelet always inspects to check whether the image is present before pulling image. If the image is not present, docker will record 404 error in log. However, the wired thing is that, if we've already prepull images, the image should be present. :)
The logs are from May 2nd, when we didn't have the image prepulling. Closing the issue.

Discussion:
package e2e_node import ( <del> "github.com/golang/glog" </del> "os/exec" <ins> "time" "github.com/golang/glog" </ins> ) const ( <del> busyBoxImage = iota </del> <ins> // Number of attempts to pull an image. maxImagePullRetries = 5 // Sleep duration between image pull retry attempts. imagePullRetryDelay = time.Second busyBoxImage        = iota </ins> hostExecImage netExecImage

// Pre-fetch all images tests depend on so that we don't fail in an actual test func PrePullAllImages() error { for _, image := range ImageRegistry { <del> output, err := exec.Command("docker", "pull", image).CombinedOutput() </del> <ins> var ( err    error output []byte ) for i := maxImagePullRetries; i > 0; i++ { if output, err = exec.Command("docker", "pull", image).CombinedOutput(); err == nil { break } time.Sleep(imagePullRetryDelay) } </ins> if err != nil { glog.Warningf("Could not pre-pull image %s %v output:  %s", image, err, output) return err
Change:
In kube-up we use var while in GKE, documentation, issues etc I think we call it cluster autoscaler. We should make it consistent.
I assume this is what you were already thinking, but: I think we should change it to cluster autoscaler (everywhere). You scale the cluster by adding/removing nodes. You scale a node by adding/removing resources to/from the node, so node autoscaler isn't the right term IMO.

Discussion:
KUBERNETES_CONFIGURE_CBR0: $(yaml-quote ${KUBERNETES_CONFIGURE_CBR0:-true}) EOF fi <del> if [[ "${ENABLE_NODE_AUTOSCALER:-}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </ins> cat >>$file <<EOF <del> ENABLE_CLUSTER_AUTOSCALER: $(yaml-quote "true") </del> <ins> ENABLE_CLUSTER_AUTOSCALER: $(yaml-quote ${ENABLE_CLUSTER_AUTOSCALER}) </ins> AUTOSCALER_MIG_CONFIG: $(yaml-quote ${AUTOSCALER_MIG_CONFIG}) EOF fi

# Optional: Create autoscaler for cluster's nodes. ENABLE_CLUSTER_AUTOSCALER="${KUBE_ENABLE_CLUSTER_AUTOSCALER:-false}" <del> if [[ "${KUBE_ENABLE_NODE_AUTOSCALER:-false}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then ENABLE_CLUSTER_AUTOSCALER="true" </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </ins> AUTOSCALER_MIN_NODES="${KUBE_AUTOSCALER_MIN_NODES:-}" AUTOSCALER_MAX_NODES="${KUBE_AUTOSCALER_MAX_NODES:-}" AUTOSCALER_ENABLE_SCALE_DOWN="${KUBE_AUTOSCALER_ENABLE_SCALE_DOWN:-true}"

# Optional: Create autoscaler for cluster's nodes. ENABLE_CLUSTER_AUTOSCALER="${KUBE_ENABLE_CLUSTER_AUTOSCALER:-false}" <del> if [[ "${KUBE_ENABLE_NODE_AUTOSCALER:-false}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then ENABLE_CLUSTER_AUTOSCALER="true" </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </ins> AUTOSCALER_MIN_NODES="${KUBE_AUTOSCALER_MIN_NODES:-}" AUTOSCALER_MAX_NODES="${KUBE_AUTOSCALER_MAX_NODES:-}" AUTOSCALER_ENABLE_SCALE_DOWN="${KUBE_AUTOSCALER_ENABLE_SCALE_DOWN:-false}"

# Starts cluster autoscaler. function start-cluster-autoscaler { <del> if [[ "${ENABLE_NODE_AUTOSCALER:-}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER:-}" == "true" ]]; then </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER:-}" == "true" ]]; then </ins> echo "Start kubernetes cluster autoscaler" prepare-log-file /var/log/cluster-autoscaler.log

# Starts k8s cluster autoscaler. start_cluster_autoscaler() { <del> if [ "${ENABLE_NODE_AUTOSCALER:-}" = "true" ] || [ "${ENABLE_CLUSTER_AUTOSCALER:-}" = "true" ]; then </del> <ins> if [ "${ENABLE_CLUSTER_AUTOSCALER:-}" = "true" ]; then </ins> prepare-log-file /var/log/cluster-autoscaler.log # Remove salt comments and replace variables with values
Change:
For some reason they stopped working and we even don't create manifest file for cluster autoscaler. I used the following command to start the cluster:
It's possible it's related to

Discussion:
mkdir -p "${dst_dir}" local salt_dir="${KUBE_ROOT}/cluster/saltbase/salt" <ins> cp "${salt_dir}/cluster-autoscaler/cluster-autoscaler.manifest" "${dst_dir}/" </ins> cp "${salt_dir}/fluentd-es/fluentd-es.yaml" "${release_stage}/" cp "${salt_dir}/fluentd-gcp/fluentd-gcp.yaml" "${release_stage}/" cp "${salt_dir}/kube-registry-proxy/kube-registry-proxy.yaml" "${release_stage}/"

cp "${src_file}" /etc/kubernetes/manifests } <ins> # Starts cluster autoscaler. function start-cluster-autoscaler { if [ "${ENABLE_NODE_AUTOSCALER:-}" = "true" ]; then touch /etc/kubernetes/start-cluster-autoscaler-enabled # Remove salt comments and replace variables with values src_file="${KUBE_HOME}/kube-manifests/kubernetes/gci-trusty/cluster-autoscaler.manifest" remove-salt-config-comments "${src_file}" local params=`sed 's/^/"/;s/ /","/g;s/$/",/' <<< "${AUTOSCALER_MIG_CONFIG}"` sed -i -e "s@"{{param}}",@${params}@g" "${src_file}" sed -i -e "s@{%.*%}@@g" "${src_file}" cp "${src_file}" /etc/kubernetes/manifests fi } </ins> # A helper function for copying addon manifests and set dir/files # permissions. #

start-kube-controller-manager start-kube-scheduler start-kube-addons <ins> start-cluster-autoscaler </ins> else start-kube-proxy # Kube-registry-proxy.

cp "${src_file}" /etc/kubernetes/manifests } <ins> # Starts k8s cluster autoscaler. start_cluster_autoscaler() { if [ "${ENABLE_NODE_AUTOSCALER:-}" = "true" ]; then # Remove salt comments and replace variables with values src_file="${kube_home}/kube-manifests/kubernetes/gci-trusty/cluster-autoscaler.manifest" remove_salt_config_comments "${src_file}" local params=`sed 's/^/"/;s/ /","/g;s/$/",/' <<< "${AUTOSCALER_MIG_CONFIG}"` sed -i -e "s@"{{param}}",@${params}@g" "${src_file}" sed -i -e "s@{%.*%}@@g" "${src_file}" cp "${src_file}" /etc/kubernetes/manifests fi } </ins> # Starts a fluentd static pod for logging. start_fluentd() { if [ "${ENABLE_NODE_LOGGING:-}" = "true" ]; then

start_kube_controller_manager start_kube_scheduler start_kube_addons <ins> start_cluster_autoscaler </ins> } 2>&1 | logger --priority daemon.info -t ${UPSTART_JOB} end script

<ins> {% if pillar.get('enable_node_autoscaler', '').lower() == 'true' %} </ins> {% set params = pillar['autoscaler_mig_config'] -%} { "kind": "Pod",

"restartPolicy": "Always" } } <ins> {% endif %} </ins>