jiebi/CodeConvo huggingface dataset:
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area apiserver /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> cheftako deads2k lavalamp </ins> sttts <del> tallclair </del>
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the client-go repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> cheftako deads2k lavalamp </ins> sttts <del> tallclair </del>
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the cli-runtime repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig cli

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> liggitt </del> pwittrock seans3 soltysh

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips tallclair </del> <ins> pwittrock seans3 soltysh </ins>
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the code-generator repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area code-generation /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> cheftako deads2k lavalamp </ins> sttts <del> tallclair </del>
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the kube-aggregator repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> cheftako deads2k lavalamp </ins> sttts <del> tallclair </del>
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the kube-proxy repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
Can I list you folks? Anyone else who wants to be in?
count on me if you need more people

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips tallclair </del> <ins> andrewsykim danwinship dcbw lachie83 thockin </ins>
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-cli-plugin repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig cli

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> liggitt </del> pwittrock seans3 soltysh

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips tallclair </del> <ins> pwittrock seans3 soltysh </ins>
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-controller repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> cheftako deads2k lavalamp </ins> sttts <del> tallclair </del>
Change:
] 20 July 2020 [x] Two weeks soak end date: 3 August 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get a list of all group /apis Iterate through list Query each endpoint List the PreferredVersion for the endpoint Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 15 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/retitle Write checkAPIGroupPreferredVersion Test +Promote - +16 Endpoint coverage
/reopen Merged /assign Ready for creation of Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged /assign Ready for creation of Promotion PR 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

Discussion:
package apimachinery import ( <ins> "context" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> utilversion "k8s.io/apimachinery/pkg/util/version" "k8s.io/apiserver/pkg/endpoints/discovery" "k8s.io/kubernetes/test/e2e/framework"

framework.Failf("didn't find resource %s in the discovery doc", spec.Names.Plural) } }) <ins> ginkgo.It("should validate PreferredVersion for each APIGroup", func() { // get list of APIGroup endpoints list := &metav1.APIGroupList{} err := f.ClientSet.Discovery().RESTClient().Get().AbsPath("/apis/").Do(context.TODO()).Into(list) framework.ExpectNoError(err, "Failed to find /apis/") framework.ExpectNotEqual(len(list.Groups), 0, "Missing APIGroups") for _, group := range list.Groups { framework.Logf("Checking APIGroup: %v", group.Name) // locate APIGroup endpoint checkGroup := &metav1.APIGroup{} apiPath := "/apis/" + group.Name + "/" err = f.ClientSet.Discovery().RESTClient().Get().AbsPath(apiPath).Do(context.TODO()).Into(checkGroup) framework.ExpectNoError(err, "Fail to access: %s", apiPath) framework.ExpectNotEqual(len(checkGroup.Versions), 0, "No version found for %v", group.Name) framework.Logf("PreferredVersion.GroupVersion: %s", checkGroup.PreferredVersion.GroupVersion) framework.Logf("Versions found %v", checkGroup.Versions) // confirm that the PreferredVersion is a valid version match := false for _, version := range checkGroup.Versions { if version.GroupVersion == checkGroup.PreferredVersion.GroupVersion { framework.Logf("%s matches %s", version.GroupVersion, checkGroup.PreferredVersion.GroupVersion) match = true break } } framework.ExpectEqual(true, match, "failed to find a valid version for PreferredVersion") } }) </ins> })
Change:
] 20 July 2020 [x] Two weeks soak end date: 3 August 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get a list of all group /apis Iterate through list Query each endpoint List the PreferredVersion for the endpoint Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 15 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/retitle Write checkAPIGroupPreferredVersion Test +Promote - +16 Endpoint coverage
/reopen Merged /assign Ready for creation of Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged /assign Ready for creation of Promotion PR 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

Discussion:
definitions MUST be published for custom resource definitions. release: v1.16 file: test/e2e/apimachinery/crd_publish_openapi.go <ins> - testname: Discovery, confirm the PreferredVersion for each api group codename: '[sig-api-machinery] Discovery should validate PreferredVersion for each APIGroup [Conformance]' description: Ensure that a list of apis is retrieved. Each api group found MUST return a valid PreferredVersion unless the group suffix is example.com. release: v1.19 file: test/e2e/apimachinery/discovery.go </ins> - testname: Event, delete a collection codename: '[sig-api-machinery] Events should delete a collection of events [Conformance]' description: A set of events is created with a label selector which MUST be found

} }) <del> ginkgo.It("should validate PreferredVersion for each APIGroup", func() { </del> <ins> /* Release : v1.19 Testname: Discovery, confirm the PreferredVersion for each api group Description: Ensure that a list of apis is retrieved. Each api group found MUST return a valid PreferredVersion unless the group suffix is example.com. */ framework.ConformanceIt("should validate PreferredVersion for each APIGroup", func() { </ins> // get list of APIGroup endpoints list := &metav1.APIGroupList{}
Change:
<!-- 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: schedulerperf now is not able to support metrics other than "Histogram", if other type of "metrics" is configured in test, it will throw below exception, What you expected to happen: should show helpful error message instead of . How to reproduce it (as minimally and precisely as possible): Define testcase with in the config which includes a , for example. 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 scheduling
/assign

Discussion:
klog.Error(err) return nil } <ins> if hist.Histogram == nil { klog.Errorf("metric %q is not a Histogram metric", metric) return nil } </ins> if err := hist.Validate(); err != nil { klog.Error(err) return nil
Change:
3 July 2020 [x] Two weeks soak end date: 20 July 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get the server version (hits api path /version) Check that the major version is current Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/reopen
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
/reopen was Merge but the merge was reversed by Issue and Test grid restarted.
Reopened this issue. <detailsIn response to : /reopen was Merge but the merge was reversed by Issue and Test grid restarted. </details
Automatic retest and Merge again

Discussion:
events match. Events are produced from writes on a background goroutine. release: v1.15 file: test/e2e/apimachinery/watch.go <ins> - testname: Confirm a server version codename: '[sig-api-machinery] server version should find the server version [Conformance]' description: Ensure that an API server version can be retrieved. Both the major and minor versions MUST only be an integer. release: v1.19 file: test/e2e/apimachinery/server_version.go </ins> - testname: DaemonSet-FailedPodCreation codename: '[sig-apps] Daemon set [Serial] should retry creating failed daemon pods [Conformance]'

var _ = SIGDescribe("server version", func() { f := framework.NewDefaultFramework("server-version") <del> ginkgo.It("should find the server version", func() { </del> <ins> /* Release : v1.19 Testname: Confirm a server version Description: Ensure that an API server version can be retrieved. Both the major and minor versions MUST only be an integer. */ framework.ConformanceIt("should find the server version", func() { </ins> ginkgo.By("Request ServerVersion")
Change:
<!-- 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: If secondard CIDR are disassociated and associated again, AWS LoadBalancer creation fails. It's due to the VPC state is like so CIDRBlock is twice to securityGroup rules, which result in error What you expected to happen: only associated CIDR are considered when calculate VPC CIDR How to reproduce it (as minimally and precisely as possible): and then associated a secondary CIDR AWS CLB Service Anything else we need to know?: Environment: Kubernetes version (use ): <=1.18.0 Cloud provider or hardware configuration: aws OS (e.g: ): linux Kernel (e.g. ): linux Install tools: kops/eks Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍

Discussion:
cidrBlocks := make([]string, 0, len(vpcs.Vpcs[0].CidrBlockAssociationSet)) for _, cidr := range vpcs.Vpcs[0].CidrBlockAssociationSet { <ins> if aws.StringValue(cidr.CidrBlockState.State) != ec2.VpcCidrBlockStateCodeAssociated { continue } </ins> cidrBlocks = append(cidrBlocks, aws.StringValue(cidr.CidrBlock)) } return cidrBlocks, nil
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should come up with a better name for : Why is this needed: From /sig testing /priority important-soon /cleanup /help /good-first-issue
/assign
/lifecycle active /remove-help
what happened with ?
I redid it here There was a bit of confusion I'll fix it up.
/wg naming

Discussion:
// CurrentSuite represents current test suite. var CurrentSuite Suite <del> // CommonImageWhiteList is the list of images used in common test. These images should be prepulled // before a tests starts, so that the tests won't fail due image pulling flakes. Currently, this is // only used by node e2e test. </del> <ins> // PrePulledImages are a list of images used in e2e/common tests. These images should be prepulled // before tests starts, so that the tests won't fail due image pulling flakes. // Currently, this is only used by node e2e test. // See also updateImageWhiteList() in ../../e2e_node/image_list.go </ins> // TODO(random-liu): Change the image puller pod to use similar mechanism. <del> var CommonImageWhiteList = sets.NewString( </del> <ins> var PrePulledImages = sets.NewString( </ins> imageutils.GetE2EImage(imageutils.Agnhost), imageutils.GetE2EImage(imageutils.BusyBox), imageutils.GetE2EImage(imageutils.IpcUtils),

// So this function needs to be called after the extra envs are applied. func updateImageWhiteList() { // Union NodePrePullImageList and CommonImageWhiteList into the framework image pre-pull list. <del> framework.ImageWhiteList = NodePrePullImageList.Union(commontest.CommonImageWhiteList) </del> <ins> framework.ImageWhiteList = NodePrePullImageList.Union(commontest.PrePulledImages) </ins> // Images from extra envs framework.ImageWhiteList.Insert(getNodeProblemDetectorImage()) framework.ImageWhiteList.Insert(getSRIOVDevicePluginImage())