jiebi/CodeConvo huggingface dataset:
Code 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 ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Check , it is still using , we should move it to . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
/assign
probably will want to move the init container also to the PodSpec
I think the init container still depend on annotations , can I specify in ? If so, I want to file another issue to track it
FYI Init containers have graduated to GA and now appear as a field. The beta annotation value will still be respected and overrides the field value. (,
Seems like that the doc should be updated. EDIT: NOTE: This feature is beta in Kubernetes 1.5. Once the feature exits beta, Init Containers will be specified in the PodSpec alongside the app containers array.
Thanks I filed an issue here
What about merge this first and then handle init-container in a separate PR?
Sounds good to me, thanks.

Related discussion:
text: labels: app: cockroachdb annotations: <del> scheduler.alpha.kubernetes.io/affinity: > { "podAntiAffinity": { "preferredDuringSchedulingIgnoredDuringExecution": [{ "weight": 100, "labelSelector": { "matchExpressions": [{ "key": "app", "operator": "In", "values": ["cockroachdb"] }] }, "topologyKey": "kubernetes.io/hostname" }] } } </del> # Init containers are run only once in the lifetime of a pod, before # it's started up for the first time. It has to exit successfully # before the pod's main containers are allowed to start.
Code 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 ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Check , it is still using , we should move it to . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
/assign
probably will want to move the init container also to the PodSpec
I think the init container still depend on annotations , can I specify in ? If so, I want to file another issue to track it
FYI Init containers have graduated to GA and now appear as a field. The beta annotation value will still be respected and overrides the field value. (,
Seems like that the doc should be updated. EDIT: NOTE: This feature is beta in Kubernetes 1.5. Once the feature exits beta, Init Containers will be specified in the PodSpec alongside the app containers array.
Thanks I filed an issue here
What about merge this first and then handle init-container in a separate PR?
Sounds good to me, thanks.

Related discussion:
text: } ]' spec: <ins> affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpress: - key: app operator: In values: - cockroachdb topologyKey: kubernetes.io/hostname </ins> containers: - name: cockroachdb # Runs the master branch. Not recommended for production, but since
Code change:
I'm seeing the following in my logs: There was an errors, and we silently skipped it.
Good catch! Thanks for pointing.

Related discussion:
text: function run-gcloud-compute-with-retries { RETRIES="${RETRIES:-3}" for attempt in $(seq 1 ${RETRIES}); do <del> local -r gcloud_result=$(gcloud compute "$@" 2>&1) local -r ret_val="$?" </del> <ins> # We don't use 'local' to declare gcloud_result as then ret_val always gets value 0. gcloud_result=$(gcloud compute "$@" 2>&1) || local ret_val="$?" </ins> echo "${gcloud_result}" <del> if [[ "${ret_val}" -ne "0" ]]; then </del> <ins> if [[ "${ret_val:-0}" -ne "0" ]]; then </ins> if [[ $(echo "${gcloud_result}" | grep -c "already exists") -gt 0 ]]; then if [[ "${attempt}" == 1 ]]; then echo -e "${color_red}Failed to $1 $2 $3 as the resource hasn't been deleted from a previous run.${color_norm}" >& 2
Code change:
I'm seeing the following in my logs: There was an errors, and we silently skipped it.
Good catch! Thanks for pointing.

Related discussion:
text: --disk "name=${MASTER_NAME}-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no" run-gcloud-compute-with-retries instances add-metadata "${MASTER_NAME}"  <ins> ${GCLOUD_COMMON_ARGS}  </ins> --metadata-from-file startup-script="${KUBE_ROOT}/test/kubemark/resources/start-kubemark-master.sh" if [ "${EVENT_PD:-false}" == "true" ]; then
Code change:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG OR Do i miss something important? Kubernetes version (use ): k8s 1.3.5. still exists in 1.6.2 What happened: HA of kube-controller-manager and kube-scheduler is achieved by create endpoint and update it periodically. However, endpoint controller deletes endpoints without corresponding services which is implemented in checkLeftoverEndpoints func: That will result in leader transition. What you expected to happen: checkLeftoverEndpoints func shouldn't delete endpoints used by LeaderElection. How to reproduce it (as minimally and precisely as possible): turn on LeaderElection for kube-controller-manager and kube-scheduler. After five minutes, endpoint controller will delete orphan endpoints. Anything else we need to know: we can add some logic in checkLeftoverEndpoints, for example, not add endpoint in kube-system namespace to queue.
Fixed by
Thanks

Related discussion:
text: "//pkg/api/v1/pod:go_default_library", "//pkg/client/clientset_generated/clientset:go_default_library", "//pkg/client/informers/informers_generated/externalversions/core/v1:go_default_library", <ins> "//pkg/client/leaderelection/resourcelock:go_default_library", </ins> "//pkg/client/listers/core/v1:go_default_library", "//pkg/controller:go_default_library", "//pkg/util/metrics:go_default_library",
Code change:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG OR Do i miss something important? Kubernetes version (use ): k8s 1.3.5. still exists in 1.6.2 What happened: HA of kube-controller-manager and kube-scheduler is achieved by create endpoint and update it periodically. However, endpoint controller deletes endpoints without corresponding services which is implemented in checkLeftoverEndpoints func: That will result in leader transition. What you expected to happen: checkLeftoverEndpoints func shouldn't delete endpoints used by LeaderElection. How to reproduce it (as minimally and precisely as possible): turn on LeaderElection for kube-controller-manager and kube-scheduler. After five minutes, endpoint controller will delete orphan endpoints. Anything else we need to know: we can add some logic in checkLeftoverEndpoints, for example, not add endpoint in kube-system namespace to queue.
Fixed by
Thanks

Related discussion:
text: podutil "k8s.io/kubernetes/pkg/api/v1/pod" "k8s.io/kubernetes/pkg/client/clientset_generated/clientset" coreinformers "k8s.io/kubernetes/pkg/client/informers/informers_generated/externalversions/core/v1" <ins> "k8s.io/kubernetes/pkg/client/leaderelection/resourcelock" </ins> corelisters "k8s.io/kubernetes/pkg/client/listers/core/v1" "k8s.io/kubernetes/pkg/controller" "k8s.io/kubernetes/pkg/util/metrics"
Code change:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG OR Do i miss something important? Kubernetes version (use ): k8s 1.3.5. still exists in 1.6.2 What happened: HA of kube-controller-manager and kube-scheduler is achieved by create endpoint and update it periodically. However, endpoint controller deletes endpoints without corresponding services which is implemented in checkLeftoverEndpoints func: That will result in leader transition. What you expected to happen: checkLeftoverEndpoints func shouldn't delete endpoints used by LeaderElection. How to reproduce it (as minimally and precisely as possible): turn on LeaderElection for kube-controller-manager and kube-scheduler. After five minutes, endpoint controller will delete orphan endpoints. Anything else we need to know: we can add some logic in checkLeftoverEndpoints, for example, not add endpoint in kube-system namespace to queue.
Fixed by
Thanks

Related discussion:
text: } for i := range list.Items { ep := &list.Items[i] <ins> if _, ok := ep.Annotations[resourcelock.LeaderElectionRecordAnnotationKey]; ok { // when there are multiple controller-manager instances, // we observe that it will delete leader-election endpoints after 5min // and cause re-election // so skip the delete here // as leader-election only have endpoints without service continue } </ins> key, err := keyFunc(ep) if err != nil { utilruntime.HandleError(fmt.Errorf("Unable to get key for endpoint %#v", ep))
Code change:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.

Related discussion:
text: // if the number of consecutive read failure equals or exceeds the failureThreshold , the // configuration is regarded as not ready. failureThreshold int <ins> // number of consecutive failures so far. failures int </ins> // if the configuration is regarded as ready. ready               bool mergedConfiguration runtime.Object
Code change:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.

Related discussion:
text: } func (a *poller) Run(stopCh <-chan struct{}) { <del> var failure int go wait.Until(func() { configuration, err := a.get() if err != nil { failure++ if failure >= a.failureThreshold { a.notReady() } return </del> <ins> go wait.Until(a.sync, a.interval, stopCh) } func (a *poller) sync() { configuration, err := a.get() if err != nil { a.failures++ if a.failures >= a.failureThreshold { a.notReady() </ins> } <del> failure = 0 a.setConfigurationAndReady(configuration) }, a.interval, stopCh) </del> <ins> return } a.failures = 0 a.setConfigurationAndReady(configuration) </ins> }
Code change:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.

Related discussion:
text: failures:          failures, successes:         successes, configurationList: configurationList, <del> stopCh:            make(chan struct{}), </del> t:                 t, } } // The first List will be successful; the next m.failures List will <del> // fail; the next m.successes List will be successful; the stopCh is closed at // the 1+m.failures+m.successes call. </del> <ins> // fail; the next m.successes List will be successful // List should only be called 1+m.failures+m.successes times. </ins> func (m *mockLister) List(options metav1.ListOptions) (*v1alpha1.InitializerConfigurationList, error) { m.invoked++ <del> // m.successes could be 0, so call this `if` first. if m.invoked == 1+m.failures+m.successes { close(m.stopCh) } </del> if m.invoked == 1 { return &m.configurationList, nil }
Code change:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.

Related discussion:
text: if m.invoked <= 1+m.failures+m.successes { return &m.configurationList, nil } <del> m.t.Fatalf("unexpected call to List, stopCh has been closed at the %d time call", 1+m.successes+m.failures) </del> <ins> m.t.Fatalf("unexpected call to List, should only be called %d times", 1+m.successes+m.failures) </ins> return nil, nil }
Code change:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.

Related discussion:
text: mock := newMockLister(c.successes, c.failures, v1alpha1.InitializerConfigurationList{}, t) manager := NewInitializerConfigurationManager(mock) manager.interval = 1 * time.Millisecond <del> manager.Run(mock.stopCh) <-mock.stopCh </del> <ins> for i := 0; i < 1+c.successes+c.failures; i++ { manager.sync() } </ins> _, err := manager.Initializers() if err != nil && c.expectReady { t.Errorf("case %s, expect ready, got: %v", c.name, err)
Code change:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): Environment: Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): RHE 7.2 Kernel (e.g. ): What happened: The node resource is empty when start local cluster by . What you expected to happen: There's one node in this local cluster. How to reproduce it (as minimally and precisely as possible):
Just check the script/code, it seems kubelet will not register until dynamic config is there ( enabled all alpha features by default).
I met same problem
What do you mean "dynamic config" ?
I think there's a PR that make kubelet can update configuration dynamically, similar to what we had done in scheduler. But did not find PR :(. I'm checking the code.
Should be this one: /cc /sig node
that shouldn't be the case. As long as you can get a client and a nodeName you should be able to register. What specific error are you seeing that suggests it's dynamic config? Also why does local-up-cluster enable all alpha features by default? That seems wrong to me.
Not sure why, but it really does:
I think this should be caused by /cc
, sorry for the disturbing :). Regarding all alpha features, I prefer to enable is by default: local-up-cluster is a kind of test environment for developer, enabling all alpha features maybe helpful to catch up potential feature interactions.
I would not expect all alpha features on by default in local up cluster
Neither would I. Developers, by default, shouldn't have to wonder if bugs are their fault or if they come from unstable alpha components. Users, by default, shouldn't have to deal with unstable alpha features either.
/ , got that; alpha components is unstable, do NOT cover everything for it.
met same problem

Related discussion:
text: HOSTNAME_OVERRIDE=${HOSTNAME_OVERRIDE:-"127.0.0.1"} CLOUD_PROVIDER=${CLOUD_PROVIDER:-""} CLOUD_CONFIG=${CLOUD_CONFIG:-""} <del> FEATURE_GATES=${FEATURE_GATES:-"AllAlpha=true"} </del> <ins> FEATURE_GATES=${FEATURE_GATES:-"AllAlpha=false"} </ins> STORAGE_BACKEND=${STORAGE_BACKEND:-"etcd3"} # enable swagger ui ENABLE_SWAGGER_UI=${ENABLE_SWAGGER_UI:-false}
Code change:
We have , but there isn't a label in the k/k repo. There is only . Do we need to add a label or rename to ?
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig ui :smiley:
/sig contributor-experience
/cc
I just it. Fixed?
Yeah. BTW, the page has a bad md format. It also should be fixed.
Feel free to send a PR to fix :)
As Piotr is the owner, I thought let him fix:) If it's Okay, I will do. Thanks Christoph!
anyone can contribute to the kubernetes/community repo too :) the PR would be reviewed like any other (usually the sig-lead for that sig would review)
Okay:)
Yep just fix things when you can. That's just faster :)
FWIW this lead me to open

Related discussion:
text: import ( "bytes" "encoding/json" <ins> "fmt" </ins> "io/ioutil" "reflect" "time"
Code change:
We have , but there isn't a label in the k/k repo. There is only . Do we need to add a label or rename to ?
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig ui :smiley:
/sig contributor-experience
/cc
I just it. Fixed?
Yeah. BTW, the page has a bad md format. It also should be fixed.
Feel free to send a PR to fix :)
As Piotr is the owner, I thought let him fix:) If it's Okay, I will do. Thanks Christoph!
anyone can contribute to the kubernetes/community repo too :) the PR would be reviewed like any other (usually the sig-lead for that sig would review)
Okay:)
Yep just fix things when you can. That's just faster :)
FWIW this lead me to open

Related discussion:
text: var lastEndpoints []api.Endpoints sleep := 5 * time.Second <ins> // Used to avoid spamming the error log file, makes error logging edge triggered. hadSuccess := true </ins> for { data, err := ioutil.ReadFile(s.filename) if err != nil { <del> glog.Errorf("Couldn't read file: %s : %v", s.filename, err) </del> <ins> msg := fmt.Sprintf("Couldn't read file: %s : %v", s.filename, err) if hadSuccess { glog.Error(msg) } else { glog.V(1).Info(msg) } hadSuccess = false </ins> time.Sleep(sleep) continue } <ins> hadSuccess = true </ins> if bytes.Equal(lastData, data) { time.Sleep(sleep)
Code change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- 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: the psp admission controller iterates through applicable psps for both the user and the service account. This leads to at least one RBAC DENY message for each pod. What you expected to happen: "RBAC DENY" should be a more meaningful message How to reproduce it (as minimally and precisely as possible): enable psp w/rbac
closing in favor of

Related discussion:
text: // Build a detailed log of the denial. // Make the whole block conditional so we don't do a lot of string-building we won't use. <del> if glog.V(2) { </del> <ins> if glog.V(5) { </ins> var operation string if requestAttributes.IsResourceRequest() { b := &bytes.Buffer{}
Code change:
5 tests failed, 6 jobs failed, 151 builds failed. Failure stats cover 1 day time range '2 Jun 2017 20:57 UTC' to '3 Jun 2017 20:57 UTC'. <details<summaryRationale for assignments:</summary </details<br
/unassign I am probably not the right owner for these tests. Leaving this to to triage it.
This seems pretty likely a quota issue. Many of them started after the cleanuped the old gce resources. Probably some tests are leaking resources. Though it doesn't occur on other CIs like . I will dig into it a bit more.
The root cause is ~2 years old from We are parsing human readable gcloud output, which recently changed. Additionally, when we fail to create the LB we leak the static IP address. It's failing on GKE but not GCE because GKE uses a pre-release version of gcloud as a canary.
/priority failing-test
/reopen ci-kubernetes-e2e-gci-gke-slow-release-1.5 and ci-kubernetes-e2e-gke-slow-release-1.5 will continue failing until we cherry pick the fix. Reopen for now.
Forgot to update: ci-kubernetes-e2e-gci-gke-slow starts passing after was merged.
Can you cherrypick to both 1.5 and 1.6 branch? But this issue is not 1.7 blocking issue anymore.
Sure, working on it.
Sent cherry picks: release-1.6: release-1.5: release-1.4: Cherrypicking the fix into 1.4 as well because we also have gce-slow-1.4 and gci-slow-1.4 CIs running.
remove the milestone, this is not a 1.7 issue
Since all issues listed here are addressed separately. Close this one.

Related discussion:
text: for attempts := 0; attempts < 4; attempts++ { outputBytes, err = exec.Command("gcloud", "compute", "addresses", "create", name, "--project", TestContext.CloudConfig.ProjectID, <del> "--region", region, "-q").CombinedOutput() </del> <ins> "--region", region, "-q", "--format=yaml").CombinedOutput() </ins> if err == nil { break }
Code change:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign

Related discussion:
text: # Metadata for driving the build lives here. META_DIR := .make <del> # Our build flags. # TODO(thockin): it would be nice to just use the native flags.  Can we EOL #                these "wrapper" flags? KUBE_GOFLAGS := $(GOFLAGS) KUBE_GOLDFLAGS := $(GOLDFLAGS) KUBE_GOGCFLAGS = $(GOGCFLAGS) </del> <ins> ifdef KUBE_GOFLAGS $(info KUBE_GOFLAGS is now deprecated. Please use GOFLAGS instead.) ifndef GOFLAGS GOFLAGS := $(KUBE_GOFLAGS) unexport KUBE_GOFLAGS else $(error Both KUBE_GOFLAGS and GOFLAGS are set. Please use just GOFLAGS) endif endif </ins> # Extra options for the release or quick-release options: KUBE_RELEASE_RUN_TESTS := $(KUBE_RELEASE_RUN_TESTS)
Code change:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign

Related discussion:
text: # Use eval to preserve embedded quoted strings. local goflags goldflags gogcflags <del> eval "goflags=(${KUBE_GOFLAGS:-})" goldflags="${KUBE_GOLDFLAGS:-} $(kube::version::ldflags)" gogcflags="${KUBE_GOGCFLAGS:-}" </del> <ins> eval "goflags=(${GOFLAGS:-})" goldflags="${GOLDFLAGS:-} $(kube::version::ldflags)" gogcflags="${GOGCFLAGS:-}" </ins> local use_go_build local -a targets=()
Code change:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign

Related discussion:
text: # KUBE_RACE="-race" make -C "${KUBE_ROOT}" test  WHAT="${WHAT:-$(kube::test::find_integration_test_dirs | paste -sd' ' -)}"  <del> KUBE_GOFLAGS="${KUBE_GOFLAGS:-}"  </del> <ins> GOFLAGS="${GOFLAGS:-}"  </ins> KUBE_TEST_ARGS="${KUBE_TEST_ARGS:-} ${SHORT:--short=true} --vmodule=garbage*collector*=6 --alsologtostderr=true"  KUBE_RACE=""  KUBE_TIMEOUT="${KUBE_TIMEOUT}"
Code change:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign

Related discussion:
text: shift $((OPTIND - 1)) # Use eval to preserve embedded quoted strings. <del> eval "goflags=(${KUBE_GOFLAGS:-})" </del> <ins> eval "goflags=(${GOFLAGS:-})" </ins> eval "testargs=(${KUBE_TEST_ARGS:-})" # Used to filter verbose test output.