jiebi/CodeConvo huggingface dataset:
Change:
Until is fixed (which won't happen before code-freeze is finished), kubemark-scale will be failing/timing-out and this is "working-as-intended" until then. It should be possible to switch off secrets in kubemark to make other problems debuggable. For now we would like to: switch off secrets in kubemark-scale leave them in all other kubemark suites
can you add a release-blocking or non-blocking label to this issue?
Is kubemark scale useful/realistic if it disables things that are required in actual deployments?
We use it for development, and we need a way to switch off particular parts.
- it's just a short term fix that would allow to fix/debug different problems at the same time (we already know that secrets are causing problems and we will be fixing it).
To clarify - I'm not going to leave that forever - as soon as we will have some fix for secrets in, we will enable it back in 5000-node kubemark. Currently because of secrets those tests doesn't bring any value.
Also - this one is already done.

Discussion:
--secure-port=443  --basic-auth-file=/srv/kubernetes/basic_auth.csv  --target-ram-mb=$((${NUM_NODES} * 60))  <del> --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota  </del> $(cat apiserver_flags) &> /var/log/kube-apiserver.log & # kube-contoller-manager now needs running kube-api server to actually start

--storage-backend=${STORAGE_BACKEND} --service-cluster-ip-range="${SERVICE_CLUSTER_IP_RANGE}" EOF <ins> if [ -z "${CUSTOM_ADMISSION_PLUGINS:-}"]; then cat >> "${RESOURCE_DIRECTORY}/apiserver_flags" <<EOF --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota EOF else cat >> "${RESOURCE_DIRECTORY}/apiserver_flags" <<EOF --admission-control=${CUSTOM_ADMISSION_PLUGINS} EOF fi </ins> sed -i'' -e "s/"//g" "${RESOURCE_DIRECTORY}/apiserver_flags" cat > "${RESOURCE_DIRECTORY}/scheduler_flags" <<EOF
Change:
FYI. Currently the field of TPR is marked as which is wrong, actually if you try to create a TPR with empty versions, it will cause api server panic. Versions should be necessary field of TPR, we should validate this somehow.

Discussion:
Description string `json:"description,omitempty"` // Versions are versions for this third party object <del> // +optional </del> Versions []APIVersion `json:"versions,omitempty"` }

// TODO: we should consider merge this struct with GroupVersion in unversioned.go type APIVersion struct { // Name of this version (e.g. 'v1'). <del> // +optional </del> Name string `json:"name,omitempty"` }

allErrs = append(allErrs, apivalidation.ValidateObjectMeta(&obj.ObjectMeta, false, ValidateThirdPartyResourceName, field.NewPath("metadata"))...) versions := sets.String{} <ins> if len(obj.Versions) == 0 { allErrs = append(allErrs, field.Required(field.NewPath("versions"), "must specify at least one version")) } </ins> for ix := range obj.Versions { version := &obj.Versions[ix] if len(version.Name) == 0 {

}, }, }, <ins> Required: []string{"name"}, </ins> }, }, Dependencies: []string{},

}, }, }, <ins> Required: []string{"versions"}, </ins> }, }, Dependencies: []string{

if err != nil { return err } <ins> if len(rsrc.Versions) == 0 { return fmt.Errorf("ThirdPartyResource %s has no defined versions", rsrc.Name) } </ins> plural, _ := meta.KindToResource(unversioned.GroupVersionKind{ Group:   group, Version: rsrc.Versions[0].Name,
Change:
FYI. Currently the field of TPR is marked as which is wrong, actually if you try to create a TPR with empty versions, it will cause api server panic. Versions should be necessary field of TPR, we should validate this somehow.

Discussion:
allErrs = append(allErrs, apivalidation.ValidateObjectMeta(&obj.ObjectMeta, false, ValidateThirdPartyResourceName, field.NewPath("metadata"))...) versions := sets.String{} <ins> if len(obj.Versions) == 0 { allErrs = append(allErrs, field.Required(field.NewPath("versions"), "must specify at least one version")) } </ins> for ix := range obj.Versions { version := &obj.Versions[ix] if len(version.Name) == 0 {

if err != nil { return err } <ins> if len(rsrc.Versions) == 0 { return fmt.Errorf("ThirdPartyResource %s has no defined versions", rsrc.Name) } </ins> plural, _ := meta.KindToResource(unversioned.GroupVersionKind{ Group:   group, Version: rsrc.Versions[0].Name,
Change:
Problem There are at least some examples of over logging in the scheduler. Solution Go through glog.Info and make sure we are consistently managing logs. At least one example to solve in an easy PR has shared with us.. Ill confirm this is happening still in upstream kube and fix as well as audit the others.
part of
yeah lets de-dupe the tickets, we have 3+ issues on this now.. closing this one. just submit the PRs and reference one of the other tickets.

Discussion:
matchingAntiAffinityTerms: matchingTerms, } for predicateName, precomputeFunc := range predicatePrecomputations { <del> glog.V(4).Info("Precompute: %v", predicateName) </del> <ins> glog.V(10).Info("Precompute: %v", predicateName) </ins> precomputeFunc(predicateMetadata) } return predicateMetadata

} nodeV, _ := nodeConstraints[k] if v != nodeV { <del> glog.V(2).Infof("Won't schedule pod %q onto node %q due to volume %q (mismatch on %q)", pod.Name, node.Name, pvName, k) </del> <ins> glog.V(10).Infof("Won't schedule pod %q onto node %q due to volume %q (mismatch on %q)", pod.Name, node.Name, pvName, k) </ins> return false, []algorithm.PredicateFailureReason{ErrVolumeZoneConflict}, nil } }

return 0 } if requested > capacity { <del> glog.V(4).Infof("Combined requested resources %d from existing pods exceeds capacity %d on node %s", </del> <ins> glog.V(10).Infof("Combined requested resources %d from existing pods exceeds capacity %d on node %s", </ins> requested, capacity, node) return 0 }
Change:
The restart test is broke by The original issue is The reason is We fixed this by filtering out mirror pod in the test. However changed to which broke the workaround. A quick fix is to filter out non-RestartAlways pods. Because either or pods could succeed, and we can not deal with terminated mirror pods very well now. /cc
Yeah... I see there's a number of problems here. I looked at the history of the image puller config and it looked to me that it was 'Never' from the beginning... Thanks for the fix though.
is this a release blocker for 1.5? Please update the issue ASAP, thanks! cc:

Discussion:
. "github.com/onsi/gomega" ) <del> func isRestartNeverMirrorPod(p *api.Pod) bool { </del> <ins> func isNotRestartAlwaysMirrorPod(p *api.Pod) bool { </ins> if !kubepod.IsMirrorPod(p) { return false } <del> return p.Spec.RestartPolicy == api.RestartPolicyNever </del> <ins> return p.Spec.RestartPolicy != api.RestartPolicyAlways </ins> } func filterIrrelevantPods(pods []*api.Pod) []*api.Pod { var results []*api.Pod for _, p := range pods { <del> if isRestartNeverMirrorPod(p) { </del> <ins> if isNotRestartAlwaysMirrorPod(p) { </ins> // Mirror pods with restart policy == Never will not get // recreated if they are deleted after the pods have // terminated. For now, we discount such pods.
Change:
https://k8s- Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gci-gke-serial ci-kubernetes-e2e-gke-serial-release-1.5 ci-kubernetes-e2e-gke-serial Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gci-gke-serial-release-1.5 ci-kubernetes-e2e-gke-containervm-1.4-gci-1.5-upgrade-cluster-new ci-kubernetes-e2e-gke-serial-release-1.5 Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
this is currently assigned to you -- can you take a look? I guess it has not failed individually recently, only as part of large "broken test runs" so maybe we should close it? Please advise.
This has only failed once in the last couple of weeks in https://k8s- and zero times in https://k8s- so I think we should close it. WDYT?
Yes, fixed a regression in this recently. Closing this.
It seems like this test is still flaking a lot on GKE
should this block 1.6?
Re-opening until we've verified it's fixed. It seems to have just failed again
I think the serial tests haven't picked up the fix yet.
Tests are looking good, closing if I see another success.
We need to cherrypick the fix in into 1.6. I've filed a separate issue to track the hanging network calls on the GKE apiserver. /cc
I believe this was fast forwarded onto the branch by
-- can we take this off of the 1.6 release now? It seems to be a test setup issue
Yes, this is not a blocker anymore.
this can be removed from the 1.6 milestone
This Issue hasn't been active in 49 days. It will be closed in 40 days (Jun 14, 2017). cc You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days

Discussion:
// How long pods have to become scheduled onto nodes podScheduledBeforeTimeout = PodListTimeout + (20 * time.Second) <del> podRespondingTimeout     = 2 * time.Minute </del> <ins> podRespondingTimeout     = 15 * time.Minute </ins> ServiceRespondingTimeout = 2 * time.Minute EndpointRegisterTimeout  = time.Minute

} if err != nil { if ctx.Err() != nil { <del> Failf("Controller %s: Failed to Get from replica %d [%s]: %vn pod status: %#v", r.controllerName, i+1, pod.Name, err, pod.Status) return false, err </del> <ins> // We may encounter errors here because of a race between the pod readiness and apiserver // proxy. So, we log the error and retry if this occurs. Logf("Controller %s: Failed to Get from replica %d [%s]: %vn pod status: %#v", r.controllerName, i+1, pod.Name, err, pod.Status) return false, nil </ins> } Logf("Controller %s: Failed to GET from replica %d [%s]: %vnpod status: %#v", r.controllerName, i+1, pod.Name, err, pod.Status) continue
Change:
When writing the docs for , I found there is a flag with short hand flag has been add to in 1.5. The flag is mostly used by add-on manger. I think we only give the flag that is very commonly used a shorthand flag. I think we should keep and save it for other flags in the future. We can make the change before it goes out in 1.5. cc:

Discussion:
kube::test::get_object_assert pods "{{range.items}}{{$id_field}}:{{end}}" '' kubectl delete pvc b-pvc 2>&1 "${kube_flags[@]}" <del> ## kubectl apply --prune --prune-whitelist(-w) </del> <ins> ## kubectl apply --prune --prune-whitelist </ins> # Pre-Condition: no POD exists kube::test::get_object_assert pods "{{range.items}}{{$id_field}}:{{end}}" '' # apply pod a

# check right pod exists kube::test::get_object_assert 'pods a' "{{${id_field}}}" 'a' # apply svc and don't prune pod a by overwriting whitelist <del> kubectl apply --prune -l prune-group=true -f hack/testdata/prune/svc.yaml -w core/v1/Service 2>&1 "${kube_flags[@]}" </del> <ins> kubectl apply --prune -l prune-group=true -f hack/testdata/prune/svc.yaml --prune-whitelist core/v1/Service 2>&1 "${kube_flags[@]}" </ins> kube::test::get_object_assert 'service prune-svc' "{{${id_field}}}" 'prune-svc' kube::test::get_object_assert 'pods a' "{{${id_field}}}" 'a' # apply svc and prune pod a with default whitelist

cmdutil.AddValidateFlags(cmd) cmd.Flags().StringVarP(&options.Selector, "selector", "l", "", "Selector (label query) to filter on") cmd.Flags().Bool("all", false, "[-all] to select all the specified resources.") <del> cmd.Flags().StringArrayP("prune-whitelist", "w", []string{}, "Overwrite the default whitelist with <group/version/kind> for --prune") </del> <ins> cmd.Flags().StringArray("prune-whitelist", []string{}, "Overwrite the default whitelist with <group/version/kind> for --prune") </ins> cmdutil.AddDryRunFlag(cmd) cmdutil.AddPrinterFlags(cmd) cmdutil.AddRecordFlag(cmd)
Change:
is quite confusing when provisioning for a PVC fails and then succeeds: it shows the PVC as , i.e. everything is OK the last logged event is , i.e. something went wrong What of the above is correct? We should log also the success:
fixed by

Discussion:
newClaimArray("claim11-1", "uid11-1", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation), // Binding will be completed in the next syncClaim newClaimArray("claim11-1", "uid11-1", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation, annStorageProvisioner), <del> noevents, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision1Success}, testSyncClaim), </del> <ins> []string{"Normal ProvisioningSucceeded"}, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision1Success}, testSyncClaim), </ins> }, { // Provision failure - plugin not found

newClaimArray("claim11-8", "uid11-8", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation), // Binding will be completed in the next syncClaim newClaimArray("claim11-8", "uid11-8", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation, annStorageProvisioner), <del> noevents, </del> <ins> []string{"Normal ProvisioningSucceeded"}, </ins> []reactorError{ // Inject error to the first // kubeclient.PersistentVolumes.Create() call. All other calls

claimWithClass("silver", newClaimArray("claim11-13", "uid11-13", "1Gi", "", v1.ClaimPending)), // Binding will be completed in the next syncClaim claimWithClass("silver", newClaimArray("claim11-13", "uid11-13", "1Gi", "", v1.ClaimPending, annStorageProvisioner)), <del> noevents, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision2Success}, testSyncClaim), </del> <ins> []string{"Normal ProvisioningSucceeded"}, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision2Success}, testSyncClaim), </ins> }, { // Provision error - non existing class

} } else { glog.V(2).Infof("volume %q provisioned for claim %q", volume.Name, claimToClaimKey(claim)) <ins> msg := fmt.Sprintf("Successfully provisioned volume %s using %s", volume.Name, plugin.GetPluginName()) ctrl.eventRecorder.Event(claim, v1.EventTypeNormal, "ProvisioningSucceeded", msg) </ins> } }
Change:
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.): upgrade test leak Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5 beta Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: kube- What happened: While doing manual upgrade testing, found that I couldn't start a new cluster as the existing firewall rules and external master ip address reservation where preventing kube-up from succeeding after running kube-down What you expected to happen: kube-down to clean up all cluster related resources How to reproduce it (as minimally and precisely as possible):
I tried this on a different GCP project and it didn't reproduce. I'm going to see if there's anything strange about my project.
Ack marking this as non-release-blocker
I think I found the problem. (from ) evaluates to false in bash on my mac. Changing it to fixes my issue. I'll send out a PR.

Discussion:
--format "value(zone)" | wc -l) # In the replicated scenario, if there's only a single master left, we should also delete load balancer in front of it. <del> if [[ "${REMAINING_MASTER_COUNT}" == "1" ]]; then </del> <ins> if [[ "${REMAINING_MASTER_COUNT}" -eq 1 ]]; then </ins> if gcloud compute forwarding-rules describe "${MASTER_NAME}" --region "${REGION}" --project "${PROJECT}" &>/dev/null; then detect-master local REMAINING_REPLICA_NAME="$(get-all-replica-names)"

fi # If there are no more remaining master replicas, we should delete all remaining network resources. <del> if [[ "${REMAINING_MASTER_COUNT}" == "0" ]]; then </del> <ins> if [[ "${REMAINING_MASTER_COUNT}" -eq 0 ]]; then </ins> # Delete firewall rule for the master, etcd servers, and nodes. delete-firewall-rules "${MASTER_NAME}-https" "${MASTER_NAME}-etcd" "${NODE_TAG}-all" # Delete the master's reserved IP

fi # If there are no more remaining master replicas: delete routes, pd for influxdb and update kubeconfig <del> if [[ "${REMAINING_MASTER_COUNT}" == "0" ]]; then </del> <ins> if [[ "${REMAINING_MASTER_COUNT}" -eq 0 ]]; then </ins> # Delete routes. local -a routes # Clean up all routes w/ names like "<cluster-name>-<node-GUID>"

# - 1: fatal error - cluster won't be working correctly # - 2: weak error - something went wrong, but cluster probably will be working correctly # We just print an error message in case 2). <del> if [[ "${validate_result}" == "1" ]]; then </del> <ins> if [[ "${validate_result}" -eq 1 ]]; then </ins> exit 1 <del> elif [[ "${validate_result}" == "2" ]]; then </del> <ins> elif [[ "${validate_result}" -eq 2 ]]; then </ins> echo "...ignoring non-fatal errors in validate-cluster" >&2 fi fi
Change:
What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR

Discussion:
Example: apply_example, Run: func(cmd *cobra.Command, args []string) { cmdutil.CheckErr(validateArgs(cmd, args)) <del> cmdutil.CheckErr(cmdutil.ValidateOutputArgs(cmd)) </del> cmdutil.CheckErr(validatePruneAll(options.Prune, cmdutil.GetFlagBool(cmd, "all"), options.Selector)) cmdutil.CheckErr(RunApply(f, cmd, out, errOut, &options)) },

} func RunApply(f cmdutil.Factory, cmd *cobra.Command, out, errOut io.Writer, options *ApplyOptions) error { <del> shortOutput := cmdutil.GetFlagString(cmd, "output") == "name" </del> schema, err := f.Validator(cmdutil.GetFlagBool(cmd, "validate"), cmdutil.GetFlagString(cmd, "schema-cache-dir")) if err != nil { return err

} dryRun := cmdutil.GetFlagBool(cmd, "dry-run") <ins> output := cmdutil.GetFlagString(cmd, "output") shortOutput := output == "name" </ins> encoder := f.JSONEncoder() decoder := f.Decoder(false)

} count++ <ins> if len(output) > 0 && !shortOutput { return cmdutil.PrintResourceInfoForCommand(cmd, info, f, out) } </ins> cmdutil.PrintSuccess(mapper, shortOutput, out, info.Mapping.Resource, info.Name, dryRun, "created") return nil }

} } count++ <ins> if len(output) > 0 && !shortOutput { return cmdutil.PrintResourceInfoForCommand(cmd, info, f, out) } </ins> cmdutil.PrintSuccess(mapper, shortOutput, out, info.Mapping.Resource, info.Name, dryRun, "configured") return nil })

} dryRun := cmdutil.GetFlagBool(cmd, "dry-run") <ins> output := cmdutil.GetFlagString(cmd, "output") </ins> count := 0 err = r.Visit(func(info *resource.Info, err error) error {

} count++ <del> shortOutput := cmdutil.GetFlagString(cmd, "output") == "name" </del> <ins> shortOutput := output == "name" if len(output) > 0 && !shortOutput { return cmdutil.PrintResourceInfoForCommand(cmd, info, f, out) } </ins> if !shortOutput { f.PrintObjectSpecificMessage(info.Object, out) }

"k8s.io/kubernetes/pkg/api/meta" "k8s.io/kubernetes/pkg/kubectl" <ins> "k8s.io/kubernetes/pkg/kubectl/resource" </ins> "k8s.io/kubernetes/pkg/runtime/schema" "github.com/spf13/cobra"

return maybeWrapSortingPrinter(cmd, printer), generic, nil } <ins> // PrintResourceInfoForCommand receives a *cobra.Command and a *resource.Info and // attempts to print an info object based on the specified output format. If the // object passed is non-generic, it attempts to print the object using a HumanReadablePrinter. // Requires that printer flags have been added to cmd (see AddPrinterFlags). func PrintResourceInfoForCommand(cmd *cobra.Command, info *resource.Info, f Factory, out io.Writer) error { printer, generic, err := PrinterForCommand(cmd) if err != nil { return err } if !generic || printer == nil { printer, err = f.PrinterForMapping(cmd, nil, false) if err != nil { return err } } return printer.PrintObj(info.Object, out) } </ins> func maybeWrapSortingPrinter(cmd *cobra.Command, printer kubectl.ResourcePrinter) kubectl.ResourcePrinter { sorting, err := cmd.Flags().GetString("sort-by") if err != nil {
Change:
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.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5 beta 2 Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): CVM Kernel (e.g. ): Install tools: kube- What happened: Step 6 of fails What you expected to happen: Node upgrade to succeed. How to reproduce it (as minimally and precisely as possible): Follow the manual upgrade steps outlined in the linked document. Anything else do we need to know: The error is because the metadata is too large for the new node instance template.
More complete error output:
This is blocking test and per email I'm bumpting this to P0.
Does it mean that "node-kube-" is too large? It seems like that too me. If so, we should understand why those are different than on startup...
This is broken for me too: After an upgrade.
: so who is going to be the assignee? and come up with a plan of attack? :)
The problem is that configure- is too large. In my directory: You can see that the number of bytes in configure- () matches the output in the error message (). What is interesting is that configure- in the repo is actually larger_. In the 1.5 branch: and in the 1.4 branch: But we aren't seeing an error during new cluster creation in either release branch.
In the directory when creating a new cluster from the 1.4 branch: which is below the size limit.
Here's the diff between the two configure- scripts: which makes it appear that is the culprit.
This may be a mac issue -- when I manually run the command from the function it makes no changes. But if I run instead of then it strips a bunch of comments, reducing the file size below the allowed limit:
We should be able to do the same thing we do in this file to fix it.
I created but haven't had a chance to test it yet.
(Master and) node upgrade worked for me on Ubuntu, so this does indeed seem to be Mac-specific.
I tested and it looks like it fixed my issue. I suppose I'll need to cherry pick it into the 1.5 branch once it merges to master.

Discussion:
# limits the size of metadata fields to 32K, and stripping comments is the # easiest way to buy us a little more room. function prepare-startup-script() { <del> sed '/^s*#([^!].*)*$/ d' ${KUBE_ROOT}/cluster/gce/configure-vm.sh > ${KUBE_TEMP}/configure-vm.sh </del> <ins> # Find a standard sed instance (and ensure that the command works as expected on a Mac). SED=sed if which gsed &>/dev/null; then SED=gsed fi if ! ($SED --version 2>&1 | grep -q GNU); then echo "!!! GNU sed is required.  If on OS X, use 'brew install gnu-sed'." exit 1 fi $SED '/^s*#([^!].*)*$/ d' ${KUBE_ROOT}/cluster/gce/configure-vm.sh > ${KUBE_TEMP}/configure-vm.sh </ins> }