jiebi/CodeConvo huggingface dataset:
Change:
We need a "panic" script for stopping clusters also when they are currently being created. This is needed for the purpose of our performance testing. It should work for at least GCE and GKE.
I think that the first step in GCE and GKE can basically be as simple as: "resize to 0 (or delete)" all MIGs It's far from being perfect but better than nothing.
For GKE that's probably only thing we can do now.
Discussed offline and it seems that for GCE it should be enough to kill the kube-up script and immediately after that start kube-down. Which we already have.
But we still need to for GKE. I'll try to hack something today.

Discussion:
<ins> #!/bin/bash # 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. echo "This is NOT a production-ready tool.n IT'S A HACKY, BEST-EFFORT WAY TO "STOP" CREATION OF THE GKE CLUSTER." read -n 1 -p "Are you sure you want to proceed (y/N)?: " decision echo "" if [[ "${decision}" != "y" ]]; then echo "Aborting..." exit 0 fi set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. if [ -f "${KUBE_ROOT}/cluster/env.sh" ]; then source "${KUBE_ROOT}/cluster/env.sh" fi source "${KUBE_ROOT}/cluster/gke/util.sh" STAGING_ENDPOINT="CLOUDSDK_API_ENDPOINT_OVERRIDES_CONTAINER=https://staging-container.sandbox.googleapis.com/" detect-project cluster=$(gcloud container operations list "--project=${PROJECT}" | grep "CREATE_CLUSTER" | grep "RUNNING" || true) if [ -z "${cluster}" ]; then echo "Couldn't find any cluster being created in production environment. Trying staging..." cluster=$(env ${STAGING_ENDPOINT} gcloud container operations list "--project=${PROJECT}" | grep "CREATE_CLUSTER" | grep "RUNNING" || true) fi if [ -z "${cluster}" ]; then echo "No cluster creation in progress found. Aborting." exit 0 fi zone=$(echo "${cluster}" | tr -s "[:blank:]" | cut -f3 -d" ") cluster_name=$(echo "${cluster}" | tr -s "[:blank:]" | cut -f4 -d" ") gcloud="gcloud" if [ "${zone}" == "us-east1-a" ]; then gcloud="env ${STAGING_ENDPOINT} gcloud" fi migs=$(${gcloud} compute instance-groups managed list --project=${PROJECT} --zones=${zone} | grep "gke-${cluster_name}" | cut -f1 -d" ") echo "Managed instance groups for cluster ${cluster_name}: ${migs}" for mig in ${migs}; do echo "Resizing ${mig}..." ${gcloud} compute instance-groups managed resize --project="${PROJECT}" --zone="${zone}" "${mig}" --size=1 done echo "All managed instance groups resized to 1. Cluster creation operation should end soon, and you will be be able to delete the cluster." </ins>
Change:
Bug report. Kubernetes version (use ): Build of master branch commit Environment: Ubuntu 16.04, 24GB memory, 8 cores (parallel compilation used as 11GB memory) Linux gbhc1 4.4.0-38-generic -Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x8664 x8664 x8664 GNU/Linux What happened: Following the build-from-source directions, I cloned kubernetes; cd &lt;dir&gt;; make release This fails with : +++ [0929 09:16:04] linux/amd64: go build started +++ [0929 09:17:42] linux/amd64: go build finished +++ [0929 09:16:04] linux/arm: go build started # constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int +++ [0929 09:16:04] linux/arm64: go build started +++ [0929 09:18:06] linux/arm64: go build finished Makefile:79: recipe for target 'all' failed make[1]:  [all] Error 1 Makefile:255: recipe for target 'cross' failed make:  [cross] Error 1 Makefile:239: recipe for target 'release' failed make:  [release] Error 1 What you expected to happen: A successful build How to reproduce it (as minimally and precisely as possible): make release Anything else do we need to know: gavin awk '(NR==57 NR==183) {print}' < fsCapacityBounds := bounded(100mb, 100gb) "AvailableBytes": bounded(100mb, 100gb), "UsageBytes": bounded(10mb, 10gb), "WorkingSetBytes": bounded(10mb, 10gb), "RxBytes": bounded(1mb, 100gb), "TxBytes": bounded(10kb, 10gb), "UsedBytes": bounded(kb, 10gb),
can you look into this build failure please?
oh, this was broken by a PR that went in yesterday, .

Discussion:
// Setup expectations. const ( <del> kb = 1000 mb = 1000 * kb gb = 1000 * mb tb = 1000 * gb </del> <ins> kb int64 = 1000 mb int64 = 1000 * kb gb int64 = 1000 * mb tb int64 = 1000 * gb </ins> maxStartAge = time.Hour * 24 * 365 // 1 year maxStatsAge = time.Minute
Change:
https://k8s- Failed: TestNamespaceController {namespace} Previous issues for this test:
GetObjectFromChan() is timing out (20s) and returning nil causing the panic. Happens in TestSecretController (and probably TestIngressController) controller as well. https://k8s-
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
I have a fix for this in
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
/cc OWNERS of :
I think this is also related to Issue .
fix is pending

Discussion:
fake_kubeclientset "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_5/fake" "k8s.io/kubernetes/pkg/client/testing/core" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/wait" </ins> "github.com/stretchr/testify/assert" )

assert.NotNil(t, createdNamespace) assert.Equal(t, ns1.Name, createdNamespace.Name) <ins> // Wait for the secret to appear in the informer store err := WaitForStoreUpdate( namespaceController.namespaceFederatedInformer.GetTargetStore(), cluster1.Name, ns1.Name, wait.ForeverTestTimeout) assert.Nil(t, err, "namespace should have appeared in the informer store") </ins> // Test update federated namespace. ns1.Annotations = map[string]string{ "A": "B",

kubeclientset "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_5" fake_kubeclientset "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_5/fake" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/wait" </ins> "github.com/stretchr/testify/assert" )

assert.Equal(t, secret1.Name, createdSecret.Name) assert.True(t, secretsEqual(secret1, *createdSecret)) <ins> // Wait for the secret to appear in the informer store err := WaitForStoreUpdate( secretController.secretFederatedInformer.GetTargetStore(), cluster1.Name, getSecretKey(secret1.Namespace, secret1.Name), wait.ForeverTestTimeout) assert.Nil(t, err, "secret should have appeared in the informer store") </ins> // Test update federated secret. secret1.Annotations = map[string]string{ "A": "B",

api_v1 "k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/client/testing/core" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/wait" </ins> "k8s.io/kubernetes/pkg/watch" "github.com/golang/glog"

}, } } <ins> // Ensure a key is in the store before returning (or timeout w/ error) func WaitForStoreUpdate(store util.FederatedReadOnlyStore, clusterName, key string, timeout time.Duration) error { retryInterval := 100 * time.Millisecond err := wait.PollImmediate(retryInterval, timeout, func() (bool, error) { _, found, err := store.GetByKey(clusterName, key) return found, err }) return err } </ins>
Change:
When using go 1.7, is failing with the following error:
Emm... I'll need this fix
Wouldn't a full struct copy work if we zero out the fields we don't want retained afterwards? It'll be less fragile as well.
You prefer to re-open my pull request or include that commit in ?
I'm also trouble in the issue when I execute command on release-1.4 branch of Kubernetes. Have someone fixed it? Fails (all fails in ):
, we can not just re-open : in , it did not include & which means build failed in go1.6 if re-open .
BTW, do we still support go1.6 in master? If so, we need upmerge to master.
Is this still a problem? I don't see any test failures on go-1.7.3

Discussion:
"net/url" "os" "reflect" <ins> "runtime" "strings" </ins> "testing" "k8s.io/kubernetes/pkg/util/sets"

// These fields are not copied "SessionTicketsDisabled", "SessionTicketKey", <del> "DynamicRecordSizingDisabled", "Renegotiation", </del> // These fields are unexported "serverInitOnce",

"sessionTicketKeys", ) <ins> // See #33936. if strings.HasPrefix(runtime.Version(), "go1.7") { expected.Insert("DynamicRecordSizingDisabled", "Renegotiation") } </ins> fields := sets.NewString() structType := reflect.TypeOf(tls.Config{}) for i := 0; i < structType.NumField(); i++ {
Change:
Kubernetes version (use ): Found in CI Environment: Cloud provider or hardware configuration: AWS defaults What happened: https://k8s- is red, mostly because of the suite. It's probably a timing difference on AWS, but I'm trying to get AWS stable enough for the SQ, and this just isn't. c.f. , , , What you expected to happen: The suite should be green. How to reproduce it (as minimally and precisely as possible): It's constantly being reproduced.
[FLAKE-PING] This flaky-test issue would love to have more attention.
This test is about to enter the blocking category on SQ. Do you have time to look at this, or do I need to blacklist on AWS and find someone to fix the testing hole? I know I don't have the time right now.
how much do we care about this feature working on AWS? Can we disable it for now and fix at our leisure?
Is there anything special about AWS vs, say, on-prem, etc? My guess is that there's something minorly wrong with the timing here, based on looking at and from . It looks like it takes upwards of 20s-30s just to pull the image, so maybe a simple would fix this?
I can't imagine anything specific to the test that would vary based on provider. As you suggest, it's probably something ancillary like that the pods have not started.
Hmm... we actually already wait up to 10 minutes for at least one pod to be running. Perhaps we should wait until all pods are running before proceeding.
Oh, I see now. Yeah, I was misreading the failure, that's just roundtripping the itself.
No. Line 74 is waiting for the PDB to be updated, and it waits only 1 minute. The PDB won't be updated until all the pods are running. I have a PR that waits for all 3 pods to be running before proceeding with this test. Will send shortly.
[FLAKE-PING] This flaky-test issue would love to have more attention.
seems to have driven down the flakes dramatically, but there's a consistent flake on AWS for these tests: Any thoughts?

Discussion:
err = cs.Pods(ns).Evict(e) Expect(err).Should(MatchError("Cannot evict pod as it would violate the pod's disruption budget.")) } else { <ins> // Only wait for running pods in the "allow" case // because one of shouldDeny cases relies on the // replicaSet not fitting on the cluster. waitForPodsOrDie(cs, ns, c.podCount+int(c.replicaSetSize)) </ins> // Since disruptionAllowed starts out false, if an eviction is ever allowed, // that means the controller is working. err = wait.PollImmediate(framework.Poll, timeout, func() (bool, error) {
Change:
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
this appears to have always been broken, I'm going to disable the job for now. https://k8s-
Failed: https://k8s- Run so broken it didn't make JUnit output!

Discussion:
# # -M installs the master set +x <del> curl -L http://bootstrap.saltstack.com | sh -s -- -M -X </del> <ins> curl -L --connect-timeout 20 --retry 6 --retry-delay 10 http://bootstrap.saltstack.com | sh -s -- -M -X </ins> set -x echo $MASTER_HTPASSWD > /srv/salt/nginx/htpasswd

# # We specify -X to avoid a race condition that can cause minion failure to # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 <del> curl -L http://bootstrap.saltstack.com | sh -s -- -X </del> <ins> curl -L --connect-timeout 20 --retry 6 --retry-delay 10 http://bootstrap.saltstack.com | sh -s -- -X </ins>
Change:
https://k8s-
I have a similar problem when I try to make release on my local desktop:
Related to .
Similar problem for :
Can you open a new issue for your problem with information about your set up. Mac/Linux? Docker version? etc.
Please add details to (to be opened) issue. I suspect that is a different issue.
New issue:

Discussion:
fi } <del> function kube::build::probe_address { # Apple has an ancient version of netcat with custom timeout flags.  This is # the best way I (jbeda) could find to test for that. local netcat if nc 2>&1 | grep -e 'apple' >/dev/null ; then netcat="nc -G 1" else netcat="nc -w 1" fi </del> <ins> function kube::build::rsync_probe { </ins> # Wait unil rsync is up and running. <del> if ! which nc >/dev/null ; then V=6 kube::log::info "netcat not installed, waiting for 1s" sleep 1 return 0 fi local tries=10 </del> <ins> local tries=20 </ins> while (( ${tries} > 0 )) ; do <del> if ${netcat} -z "$1" "$2" 2> /dev/null ; then </del> <ins> if rsync "rsync://k8s@${1}:${2}/"  --password-file="${LOCAL_OUTPUT_BUILD_CONTEXT}/rsyncd.password"  &> /dev/null ; then </ins> return 0 fi tries=$(( ${tries} - 1))

# machines) we have to talk directly to the container IP.  There is no one # strategy that works in all cases so we test to figure out which situation we # are in. <del> if kube::build::probe_address 127.0.0.1 ${mapped_port}; then </del> <ins> if kube::build::rsync_probe 127.0.0.1 ${mapped_port}; then </ins> KUBE_RSYNC_ADDR="127.0.0.1:${mapped_port}" <del> sleep 0.5 </del> return 0 <del> elif kube::build::probe_address "${container_ip}" ${KUBE_CONTAINER_RSYNC_PORT}; then </del> <ins> elif kube::build::rsync_probe "${container_ip}" ${KUBE_CONTAINER_RSYNC_PORT}; then </ins> KUBE_RSYNC_ADDR="${container_ip}:${KUBE_CONTAINER_RSYNC_PORT}" <del> sleep 0.5 </del> return 0 fi
Change:
Kubernetes version (use ): 1.4.0 Environment: Cloud provider or hardware configuration: Azure What happened: Trying to mount an Azure file share by following the directions fails because hyperkube does not include cifs-utils (eg, ). Can this be to the hyperkube image, please?
is this related to GCI image missing nfs related package?
This should fix the reported issue:
Thanks for fixing this so quickly!
No, unrelated

Discussion:
git  nfs-common  glusterfs-client  <ins> cifs-utils  </ins> && DEBIAN_FRONTEND=noninteractive apt-get upgrade -y  && DEBIAN_FRONTEND=noninteractive apt-get autoremove -y  && DEBIAN_FRONTEND=noninteractive apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
Change:
The script doesn't support a user-value for the Kube-apiserver option. This is the IPs on which the Kube API will listen for secure API requests. The local-cluster-up script is set in such a way that it will only bind to the same IP as the one defined in : The default value of will never be used as is always set on the line before. This means that today getting to the secure Kube API through the kube service IP doesn't work. (By default the secure API only binds to on the host). Proposal is to have a default of for secure API binding, or whatever value is provided by the user.

Discussion:
API_PORT=${API_PORT:-8080} API_HOST=${API_HOST:-127.0.0.1} API_HOST_IP=${API_HOST_IP:-${API_HOST}} <del> API_BIND_ADDR=${API_HOST_IP:-"0.0.0.0"} </del> <ins> API_BIND_ADDR=${API_BIND_ADDR:-"0.0.0.0"} </ins> KUBELET_HOST=${KUBELET_HOST:-"127.0.0.1"} # By default only allow CORS for requests on localhost API_CORS_ALLOWED_ORIGINS=${API_CORS_ALLOWED_ORIGINS:-"/127.0.0.1(:[0-9]+)?$,/localhost(:[0-9]+)?$"}
Change:
It seems that we stopped uploading logs to GCS around Friday/Saturday. As examples, this is the first kubemark-scale run that doesn't have logs: But we also don't have any logs e.g. for kubernetes-gce-e2e suite (which seems to be our main suite), e.g.: This seems to be the last run, for which we have logs: which suggests that it was broken around 2016-10-08 01:00:00
P0 - because it makes any debugging roughly impossible.
is working on this
It seems that after fixes from yesterday, we are still lacking logs from all kubemark runs.
Lack of kubemark logs is significantly slowing down any scalability-related work, which is our P0 goal for this quarter, so please prioritize it. - FYI ^^
As an example: [is a run from an hour ago] and it contains only file.
I'm going to migrate this job over to where our code (rather than a jenkins plugin) captures and uploads logs, which we want to do anyway and will hopefully resolve this. Odd... if we look at job/kubernetes-e2e-gce/configure we will a bunch of conditional build steps in the post-build actions configuration, which matches what is specified in yaml: We also have this specified in kubemark yaml: However I don't see where this is applied in the actual configuration: /job/kubernetes-kubemark-gce-scale/configure
I suspect that the job updater ran at some point this weekend while the conditional build step plugin wasn't working, so it wasn't able to add that step. I'm not sure why it hasn't rectified it since.
That seems to be the problem. I've cleared the job cache and done a full rebuild, so gce-scale and anything else that was updated why the postbuild plugin was missing should be fixed now.
Hmm - it doesn't seem to be fully fixed. Basically, we used to have logs from kubemark master machine, e.g.: (there is this kubemark-500-kubemark-master/ directory) However, even now (this is the last run), we no longer have those logs: So something is still broken...
Any thoughts about it? The logs are still missing, e.g.:
All the files in _artifacts are being properly uploaded. Something else is failing to copy the logs onto the node. In In , it seems to be copying more: Did something else change in kubemark between these time periods? Is scp from the master broken now? This is a separate issue.
I'm not aware of any other changes. - we should try to debug it tomorrow.
We did touch recently in . Might be related.
Yeah, I was just trying to work out if it was. I tried to keep the fake path alive as best I could.
- if you could figure out if it was because of your PR (timing matches) that would be great...
I confirm that this is fixed now. - thanks a lot for fixing this!

Discussion:
scp -oLogLevel=quiet -oConnectTimeout=30 -oStrictHostKeyChecking=no -i "${LOG_DUMP_SSH_KEY}" "${LOG_DUMP_SSH_USER}@${node}:${scp_files}" "${dir}" > /dev/null || true else case "${KUBERNETES_PROVIDER}" in <del> gce|gke) </del> <ins> gce|gke|kubemark) </ins> gcloud compute copy-files --project "${PROJECT}" --zone "${ZONE}" "${node}:${scp_files}" "${dir}" > /dev/null || true ;; aws)

fi else case "${KUBERNETES_PROVIDER}" in <del> gce|gke) </del> <ins> gce|gke|kubemark) </ins> files="${files} ${gce_logfiles}" ;; aws)
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 ): 1.3.8 custom build - the code seems to still be in place in master. Environment: Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): VERSION="14.04.5 LTS, Trusty Tahr" Kernel (e.g. ): 4.4.0-38-generic ~14.04.1-Ubuntu SMP Tue Sep 6 17:20:43 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: Custom Others: What happened: When the OpenStack Nova API is not accessible Nodes are marked as "NotReady" The OpenStack cloud providers seems to call Nova on a schedule to get information. If the API is not contactable, kubelet fails to call back to the masters, and gets marked as NotReady. Masters also call the Nova API, and when it fails, it can mark all nodes as NotReady. What you expected to happen: Nothing - the cluster should still work, regardless of Nova's API How to reproduce it (as minimally and precisely as possible): Install Kubernetes using the OpenStack provider. On the OpenStack controller stop the nova-api process.

Discussion:
} } } <del> if err := kl.setNodeStatus(node); err != nil { return nil, err } </del> <ins> kl.setNodeStatus(node) </ins> return node, nil }

kl.updatePodCIDR(node.Spec.PodCIDR) <del> if err := kl.setNodeStatus(node); err != nil { return err } </del> <ins> kl.setNodeStatus(node) </ins> // Patch the current status on the API server updatedNode, err := nodeutil.PatchNodeStatus(kl.kubeClient, types.NodeName(kl.nodeName), originalNode, node) if err != nil {

// any fields that are currently set. // TODO(madhusudancs): Simplify the logic for setting node conditions and // refactor the node status condition code out to a different file. <del> func (kl *Kubelet) setNodeStatus(node *v1.Node) error { </del> <ins> func (kl *Kubelet) setNodeStatus(node *v1.Node) { </ins> for _, f := range kl.setNodeStatusFuncs { if err := f(node); err != nil { <del> return err </del> <ins> glog.Warningf("Failed to set some node status fields: %s", err) </ins> } } <del> return nil </del> } // defaultNodeStatusFuncs is a factory that generates the default set of