jiebi/CodeConvo huggingface dataset:
Change:
} } <del> // applyWaitingForSchedulingGatesCondition adds a {type:PodScheduled, reason:WaitingForGates} condition </del> <ins> // applySchedulingGatedCondition adds a {type:PodScheduled, reason:SchedulingGated} condition </ins> // to a new-created Pod if necessary. <del> func applyWaitingForSchedulingGatesCondition(pod *api.Pod) { </del> <ins> func applySchedulingGatedCondition(pod *api.Pod) { </ins> if !utilfeature.DefaultFeatureGate.Enabled(features.PodSchedulingReadiness) || len(pod.Spec.SchedulingGates) == 0 { return

Discussion:
<img width="844" alt="image" src="" <img width="942" alt="image" src="" Here are some incorrect comments and function name about SchedulingGated Comments and function names need to be changed to SchedulingGated nothing No response <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig scheduling
/remove-kind bug /kind cleanup
Change:
readonly extra_log_files="${LOG_DUMP_EXTRA_FILES:-}" readonly dump_systemd_journal="${LOG_DUMP_SYSTEMD_JOURNAL:-false}" # Log files found in WINDOWS_LOGS_DIR on Windows nodes: <del> readonly windows_node_logfiles="kubelet.log kube-proxy.log docker.log" </del> <ins> readonly windows_node_logfiles="kubelet.log kube-proxy.log docker.log docker_images.log" </ins> # Log files found in other directories on Windows nodes: readonly windows_node_otherfiles="C:WindowsMEMORY.dmp"

Discussion:
When a test run completes it would be useful to have a list of all the test containers that were pulled onto the node - see for the motivation. Let's add a call to at - just after seems like it should work fine. We can dump the output to a file and gather it from each node just like we do for
/assign Yang, we should also consider adding to the log gathering that the GCE diagnostics tool does :)
/sig windows
/reopen in the of our on 03-22 I don't see in the artifacts for the Windows node. Can you check on this? Did we miss a step or is something failing?
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Oh, missed to add the new log file to collector list.
Added the fix:
Change:
maxImagePullRetries = 5 // Sleep duration between image pull retry attempts. imagePullRetryDelay = time.Second <ins> // Number of parallel count to pull images. maxParallelImagePullCount = 5 </ins> ) // NodeImageWhiteList is a list of images used in node e2e test. These images will be prepulled

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Unless disabled, the tests will prepull all images when running. They do so using the . I think there's the opportunity to improve the runtime of the test suite by prepulling the images in parallel. Why is this needed: Its always nicer to have faster tests :) Specifically for users running locally, it's nice to have the image prepull occur as quick as possible. That being said, we should also be cognizant of any tradeoffs associated with prepulling the images in parallel. If the code is substantially more complex, we would need a large improvement in test speed to justify it. I'm hopeful this discussion could be had once we have a proof of concept diff (which I think should be fairly minimal effort to create).
/sig node
I think this could be a good first issue for someone looking to get involved with contributing to sig-node :) Please post if you plan on working on it, so that there aren't multiple people tackling it.
I'd be interested! I'm looking for a first issue and think this would be a good one
Wonderful! Want to reach out to me on Kubernetes slack? I'm on there too :)
:wave: hiya ! Are you still thinking you could be interested in working on this? Lmk if so, and we can chat about next steps? If not, perhaps I'll open it back up to a newcomer looking for a first commit?
I'm going to open this back up for someone looking for a first commit. Lmk if you're still interest in getting sig-node, and happy to find an issue for you :)
Opening this back up for folks :) I'm happy to mentor whoever picks this up if that'd be helpful :) Ping me on k8s-slack, where I'm also
Can you assign this to meI'd be interested!
/assign
Awesome - feel free to reach out on k8s-slack if you have questions, or if you already have a plan, feel free to tag me in the pull request. Thanks :)
/lifecycle active /priority important-longterm
Change:
// `HostIP: s.API.AdvertiseAddrs[0]`, if there is only one address` {Name: "http", ContainerPort: 9898, HostPort: 9898}, }, <ins> SecurityContext: &api.SecurityContext{ SELinuxOptions: &api.SELinuxOptions{ // TODO: This implies our discovery container is not being restricted by // SELinux. This is not optimal and would be nice to adjust in future // so it can read /tmp/secret, but for now this avoids recommending // setenforce 0 system-wide. Type: "unconfined_t", }, }, </ins> }}, Volumes: []api.Volume{{ Name: kubeDiscoverySecretName,

Discussion:
Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-beta.11", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-23T22:53:01Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-26T18:10:32Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"} Environment: AWS - CentOS 7.2 x8664 with cloud-init (HVM) (ami-) OS (e.g. from /etc/os-release): NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" IDLIKE="rhel fedora" VERSIONID="7" PRETTYNAME="CentOS Linux 7 (Core)" ANSICOLOR="0;31" CPENAME="cpe:/o:centos:centos:7" HOMEURL="" BUGREPORTURL="" CENTOSMANTISBTPROJECT="CentOS-7" CENTOSMANTISBTPROJECTVERSION="7" REDHATSUPPORTPRODUCT="centos" REDHATSUPPORTPRODUCTVERSION="7" Linux ip-172-31-35-103 3.10.0-327.el7.x8664 SMP Thu Nov 19 22:10:57 UTC 2015 x8664 x8664 x86_64 GNU/Linux Install tools: Others: What happened: when selinux is enabled i was getting following error on discovery container What you expected to happen: i expected node to be able to join master, but nothing was running on 9898 port of master i.e.

discovery due the error mentioned above How to reproduce it (as minimally and precisely as possible): use the api which i gave you and do normal kubeadm init Anything else do we need to know: This issue got fixed with setenforce 0
This issue got fixed with setenforce 0 but want to track it
cc
BTW the issue was on latest Centos iso too downloaded from here
cc
this is to do with secrets, and kubelet log is the place to look for more info, could you please grab and paste it in a gist (it's gonna be fairly large)? Also, the kernel audit log would be handy, do you know how to get this (I forgot)?
not sure if this will help
the lines are incomplete, it's best if you redirect it to a file and upload it somewhere with a link here.
could you also provide the output of ?
Change:
- mode: 644 - makedirs: true <ins> libltdl7: pkg.installed </ins> docker-upgrade: cmd.run: - name: /opt/kubernetes/helpers/pkg install-no-start {{ docker_pkg_name }} {{ override_docker_ver }} /var/cache/docker-install/{{ override_deb }} - require: - file: /var/cache/docker-install/{{ override_deb }} <ins> - pkg: libltdl7 </ins> {% endif %} # end override_docker_ver != ''

Discussion:
Kubernetes is failing to start on AWS wily. Following the guide from here: Here's a snippet from /var/log/syslog
More logs,
cc
Is there a workaround fix I can use in the scripts to get around this?
Change:
}, }, }, <ins> Labels: map[string]string{"a": "b"}, </ins> } func TestCreateController(t *testing.T) {

Discussion:
If a ReplicaController has a selector that doesn't match the template it'll just create tons and tons of pods. It should validate that the pods it is creating have a good chance of satisfying its selector.
It would also be useful to validate that the selector doesn't obviously overlap with selectors of other replicationControllers.
Change:
} // metricsCollector collects metrics from legacyregistry.DefaultGatherer.Gather() endpoint. <del> // Currently only Histrogram metrics are supported. </del> <ins> // Currently only Histogram metrics are supported. </ins> type metricsCollector struct { *metricsCollectorConfig labels map[string]string

Discussion:
The new scheduler performance test was introduced back in 1.18, back then, the metric it supported are all . However, along with , some metrics are updated to be , and hence it's no longer appropriate to return the first Histogram: However, it's very common (for instance Preemption) that the metrics may hold multiple histograms: Additionally, metrics and have been removed, we should update them to : /sig scheduling
/triage accepted /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
"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++ {

Discussion:
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

Hey Guys, When running command on release-1.4 branch, I got the below errors, my GO version is , how to fix it or something else have I missed?
dup of . fixed by . we can close this. /sig api-machinery
Sure, close it.
Change:
fRC.mutex.Lock() defer fRC.mutex.Unlock() <ins> fRC.Calls = append(fRC.Calls, "Delete") </ins> if routes, ok := fRC.FakeStore[routeTableName]; ok { if _, ok := routes[routeName]; ok { delete(routes, routeName)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Kubernetes shouldn't put route table when it's already been configured. Azure cloud provider should check whether the route has already been created before invoking . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cloud-provider /priority important-soon
Why this is a bug? A PUT operation should be idempotent and multiple calls should get the same result?
Right. But cloud provider shouldn't make unnecessary API calls.
To check whether it is configured, we need a GET call, so we're going to replace PUT call with GET call in this case?
it's not a replace, we need to LIST routes and check whether it has already been there, then PUT if it's not.
I got your point. But if we directly send a PUT request, seems route RP will also do this comparation? Is there any issue making us have to do the comparation by ourselves instead of sending PUT request to route RP?
It would help to reduce the chances of ARM PUT throttling.
I'd like to work on this
/assign
Change:
# github.com/cpuguy83/go-md2man/v2 v2.0.2 ## explicit; go 1.11 github.com/cpuguy83/go-md2man/v2/md2man <del> # github.com/cyphar/filepath-securejoin v0.2.3 </del> <ins> # github.com/cyphar/filepath-securejoin v0.2.4 </ins> ## explicit; go 1.13 github.com/cyphar/filepath-securejoin # github.com/davecgh/go-spew v1.1.1

Discussion:
One of the dependencies of k8s, filepath-securejoin, has a following vulnerability discovered: It has been patched in version 0.2.4, however k8s is still using version 0.2.3. Potential fix: updating the dependency. A small PR will follow. /sig security
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig security
/kind bug /sig security
Change:
windows/amd64 ) <ins> # Gigabytes desired for parallel platform builds. 8 is fairly # arbitrary, but is a reasonable splitting point for 2015 # laptops-versus-not. readonly KUBE_PARALLEL_BUILD_MEMORY=8 </ins> readonly KUBE_ALL_TARGETS=( "${KUBE_SERVER_TARGETS[@]}" "${KUBE_CLIENT_TARGETS[@]}"

Discussion:
Filing for This code is wrong The local needs to be on a separate line from the command execution, and we need to be resilient to not existing on OS X, like:
For once I was actually watching the output of a build and noticed that I was seeing an error about md5sum not being found. I'm building on a mac using boot2docker. The short_hash function () works fine on my mac as md5 does exist.
Actually, I'm just going to fix this as a follow-on to .
Thank you!
Change:
ADDON_MANAGER_LEADER_ELECTION: $(yaml-quote ${ADDON_MANAGER_LEADER_ELECTION}) EOF fi <ins> if [ -n "${API_SERVER_TEST_LOG_LEVEL:-}" ]; then cat >>$file <<EOF API_SERVER_TEST_LOG_LEVEL: $(yaml-quote ${API_SERVER_TEST_LOG_LEVEL}) EOF fi </ins> else # Node-only env vars.

Discussion:
After we moved logging all requests in apiserver to V(3) level: We have the: --vmodule=httplog=3 to config of all scalability tests, because debugging scalability tests is pretty much impossible without having those logs. However, apparently this is adding a huge lock contention on that, because if vmodule is non-empty, we enter a non-trivial code-path in the glog for every single glog call: I did some experiments, and switching --v=3 for apiserver (instead of --v=2 + vmodule) doesn't introduce the significiant change - the difference in amount of produced logs is about 10% (a bit less). So given that we don't do that in production anyway, what we should do is to: set --v=3 for apiserver in our scalability tests (to have all the logs we need) get rid of those vmodule settings
Something went wrong here. The vmodule flag change worked as expected, but setting --v=3 in apiserver didn't. Here are the api-server args from the recent run of the gce scale perormance ! The vmodule is not set, but the log level is set to v2. As the result we currently don't have the http logs. I'm investigating why log verbosity is not overridden in api server.
Env variables seem to be set correctly in the build file: !
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
seems to be fixing the issue - !
Change:
o := NewExplainOptions(parent, streams) cmd := &cobra.Command{ <del> Use:                   "explain RESOURCE", </del> <ins> Use:                   "explain TYPE [--recursive=FALSE|TRUE] [--api-version=api-version-group] [--output=plaintext|plaintext-openapiv2]", </ins> DisableFlagsInUseLine: true, Short:                 i18n.T("Get documentation for a resource"), Long:                  explainLong + "nn" + cmdutil.SuggestAPIResources(parent),

Discussion:
Especially the options description are super sad. I think we can improve them in the next beta iteration cc /sig cli
/triage accepted
Hi does fixes this issue?
I agree with the same. Unlike other outputs, it doesn't share the details about the values or their usage.
Unfortunately, I don't think it does. Have you tried it? Please send a pull-request I'll happily review it.
Hi , I'd like to work on this. However, I would need some guidance so I know I'm in the right direction. My guess is we change the text I have noticed these descriptions are not as per the other flag descriptions in kubectl. I'll make a draft once you confirm.
For eg these are options in : we can try adding details and formal tone to the text. /assign
I don't know if you need my help, you seem to be doing just fine. Please go ahead and ask me questions if you have specific problems, I'll be happy to guide. Thanks!
That's correct.
sure thing , I'll send the PR
Hi How does this output looks :
Hi Raised the PR: for reviews on same.
Change:
if printContainers { printValue(w, PodColumn) } <ins> sort.Slice(metrics, func(i, j int) bool { if withNamespace && metrics[i].Namespace != metrics[j].Namespace { return metrics[i].Namespace < metrics[j].Namespace } return metrics[i].Name < metrics[j].Name }) </ins> printColumnNames(w, PodColumns) for _, m := range metrics { err := printSinglePodMetrics(w, &m, printContainers, withNamespace)

Discussion:
and node should sort by namespace / name so that results don't jump around. We should consider adding sort, but only after we make a stable sort the default.
next Also, why does it sometimes lose nodes? Annoying
I did not reproduce this. I think this may be caused by the monitoring timeout of heapster. So that the data got missing.
Change:
return ioutil.WriteFile(destFile, b, 0644) } <ins> type labelValues struct { label  string values []string } </ins> // metricsCollectorConfig is the config to be marshalled to YAML config file. <ins> // NOTE: The mapping here means only one filter is supported, either value in the list of `values` is able to be collected. </ins> type metricsCollectorConfig struct { <del> Metrics []string </del> <ins> Metrics map[string]*labelValues </ins> } // metricsCollector collects metrics from legacyregistry.DefaultGatherer.Gather() endpoint.

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : run got the below error message, We should provide the metric data for different extension points from the metric of "schedulerframeworkextensionpointdurationseconds" Why is this needed: Those metrics have been removed by this commit - Those metrics are deprecated cause it is suggested to use - , but simply remove those metrics definitely is not a nice way to address the issue. /sig scheduling
/triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /triage accept Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
Account mount path MUST be auto mounted to the Container. */ framework.ConformanceIt("should mount an API token into pods ", func() { <del> var tokenContent string </del> var rootCAContent string <ins> sa, err := f.ClientSet.CoreV1().ServiceAccounts(f.Namespace.Name).Create(&v1.ServiceAccount{ObjectMeta: metav1.ObjectMeta{Name: "mount-test"}}) framework.ExpectNoError(err) </ins> // Standard get, update retry loop framework.ExpectNoError(wait.Poll(time.Millisecond*500, framework.ServiceAccountProvisionTimeout, func() (bool, error) { By("getting the auto-created API token") <del> sa, err := f.ClientSet.CoreV1().ServiceAccounts(f.Namespace.Name).Get("default", metav1.GetOptions{}) </del> <ins> sa, err := f.ClientSet.CoreV1().ServiceAccounts(f.Namespace.Name).Get("mount-test", metav1.GetOptions{}) </ins> if apierrors.IsNotFound(err) { <del> framework.Logf("default service account was not found") </del> <ins> framework.Logf("mount-test service account was not found") </ins> return false, nil } if err != nil { <del> framework.Logf("error getting default service account: %v", err) </del> <ins> framework.Logf("error getting mount-test service account: %v", err) </ins> return false, err } if len(sa.Secrets) == 0 { <del> framework.Logf("default service account has no secret references") </del> <ins> framework.Logf("mount-test service account has no secret references") </ins> return false, nil } for _, secretRef := range sa.Secrets {

Discussion:
https://k8s- /sig auth /kind failing-test
Adding a priority to this: /priority important-soon Please raise the priority if you consider this a release blocker. Given the test job, it normally wouldn't be.
It's a test issue. I'm hoping to fix this before 1.13 but I don't consider it a release blocker.
Change:
<ins> /* Copyright 2015 Google Inc. All rights reserved. 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 apiserver import ( "testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/meta" "github.com/emicklei/go-restful" ) func TestScopeNamingGenerateLink(t *testing.T) { selfLinker := &setTestSelfLinker{ t:           t, expectedSet: "/api/v1beta3/namespaces/other/services/foo", name:        "foo", namespace:   "other", } s := scopeNaming{ meta.RESTScopeNamespace, selfLinker, "/api/v1beta3/namespaces/{namespace}/services/{name}", true, } service := &api.Service{ ObjectMeta: api.ObjectMeta{ Name:      "foo", Namespace: "other", }, TypeMeta: api.TypeMeta{ Kind: "Service", }, } _, _, err := s.GenerateLink(&restful.Request{}, service) if err != nil { t.Errorf("Unexpected error %v", err) } } </ins>

Discussion:
Accessing entities without namespaces in the url makes the selflink to look corrupted (has namespace missing): Example - invoking: http://localhost:8080/api/v1beta3/services/ returns entities with this selflink (note the part after namespaces) "selfLink": "/api/v1beta3/namespaces/%7Bnamespaces%7D/services/guestbook"
I thought accessing namespaced objects without the namespace was just disallowed in v1beta3. ?
Oh, probably list is allowed for components that need to watch all objects across all namespaces, such as kube-proxy. In that case, the selfLink looks broken, yes.
- right. I will look into the self link this afternoon to see what's going on. Self assigning.
The api has to allow fetching all objects cross namespaces without specifying namespace, otherwise it will cause multiple requests to the api - per namespace, big overhead for clients.