jiebi/CodeConvo huggingface dataset:
Change:
} } if err != nil { <del> klog.Errorf("azureDisk - detach disk(%s, %s)) failed, err: %v", diskName, diskURI, err) </del> <ins> klog.Errorf("azureDisk - detach disk(%s, %s) failed, err: %v", diskName, diskURI, err) </ins> } else { klog.V(2).Infof("azureDisk - detach disk(%s, %s) succeeded", diskName, diskURI) }

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: add more logging in azure disk attach/detach 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: Others: /sig azure /assign
The issue message here doesn't say why a change was desired. The PR "Original logging is not clear when dealing with managed disk, since diskName is empty". That's more informative.
Change:
GCE_HOSTS= GCE_IMAGE_CONFIG_PATH=test/e2e_node/jenkins/image-config.yaml GCE_ZONE=us-central1-f <del> GCE_PROJECT=kubernetes-jenkins-pull </del> <ins> GCE_PROJECT=k8s-jkns-pr-node-e2e </ins> CLEANUP=true GINKGO_FLAGS='--skip="[Flaky]|[Slow]|[Serial]"' SETUP_NODE=false

Discussion:
I want to isolate these in their own project:
Right now just the CI jobs, but after we also need to do this for the PR jobs.
Change:
"k8s.io/kubernetes/test/e2e/framework" imageutils "k8s.io/kubernetes/test/utils/image" <ins> "encoding/base64" </ins> "github.com/onsi/ginkgo" <ins> "k8s.io/apimachinery/pkg/types" </ins> ) var _ = ginkgo.Describe("[sig-api-machinery] Secrets", func() {

Discussion:
This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to these query results from APIsnoop, we are lacking in tests for the follow endpoints related to Secrets. We chose the follow endpoints for this mock test. Test outline: a Secret in the default namespace with custom values Secrets in all namespaces search for Secret created in  the data in Secret  Secret  Secrets in all namespaces ensure that Secret  doesn't exist Discover useragents Display endpoints hit by the test Review the change in coverage If a test with these calls gets merged in, conformance will go up by 3 endpoints. /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
Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /close
Closing this issue. <detailsIn response to : Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /close 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
Change:
if [[ -n "${NON_MASQUERADE_CIDR:-}" ]]; then flags+=" --non-masquerade-cidr=${NON_MASQUERADE_CIDR}" fi <ins> # FlexVolume plugin if [[ -n "${VOLUME_PLUGIN_DIR:-}" ]]; then flags+=" --volume-plugin-dir=${VOLUME_PLUGIN_DIR}" fi </ins> if [[ "${ENABLE_MANIFEST_URL:-}" == "true" ]]; then flags+=" --manifest-url=${MANIFEST_URL}" flags+=" --manifest-url-header=${MANIFEST_URL_HEADER}"

Discussion:
For FlexVolume, there is a kubelet flag, --volume-plugin-dir, that specifies the path which FlexVolume plugin uses to find the custom volume driver. Currently it's not possible to set this flag through cluster/kube-
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 storage
Change:
// ApplyTo applies the run options to the method receiver and returns self func (s *ServerRunOptions) ApplyTo(c *server.Config) error { c.CorsAllowedOriginList = s.CorsAllowedOriginList <ins> c.HSTSDirectives = s.HSTSDirectives </ins> c.ExternalAddress = s.ExternalHost c.MaxRequestsInFlight = s.MaxRequestsInFlight c.MaxMutatingRequestsInFlight = s.MaxMutatingRequestsInFlight

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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 api-machinery
/remove-sig api-machinery /sig auth
Change:
import ( "os" <del> "k8s.io/kubernetes/pkg/api" </del> dockertypes "github.com/docker/engine-api/types" <ins> dockercontainer "github.com/docker/engine-api/types/container" "k8s.io/kubernetes/pkg/api" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" </ins> ) <ins> // These two functions are OS specific (for now at least) func updateHostConfig(hc *dockercontainer.HostConfig, opts *kubecontainer.RunContainerOptions) { // There is no /etc/resolv.conf in Windows, DNS and DNSSearch options would have to be passed to Docker runtime instead hc.DNS = opts.DNS hc.DNSSearch = opts.DNSSearch // MemorySwap == -1 is not currently supported in Docker 1.14 on Windows // https://github.com/docker/docker/blob/master/daemon/daemon_windows.go#L175 hc.Resources.MemorySwap = 0 } func DefaultMemorySwap() int64 { return 0 } </ins> func getContainerIP(container *dockertypes.ContainerJSON) string { if container.NetworkSettings != nil { for _, network := range container.NetworkSettings.Networks {

Discussion:
What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.
Change:
ARG BASEIMAGE ARG REGISTRY <ins> ARG OS_VERSION </ins> # We're using a Linux image to unpack the archive, then we're copying it over to Windows. FROM --platform=linux/amd64 alpine:3.6 as prep

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
go_test( name = "go_default_test", <del> srcs = select({ "@io_bazel_rules_go//go/platform:linux_amd64": [ "proxier_test.go", ], "//conditions:default": [], }), </del> <ins> srcs = ["proxier_test.go"], </ins> library = ":go_default_library", <del> deps = select({ "@io_bazel_rules_go//go/platform:linux_amd64": [ "//pkg/api:go_default_library", "//pkg/proxy:go_default_library", "//pkg/proxy/util:go_default_library", "//pkg/util/iptables:go_default_library", "//pkg/util/iptables/testing:go_default_library", "//pkg/util/ipvs:go_default_library", "//pkg/util/ipvs/testing:go_default_library", "//vendor/github.com/davecgh/go-spew/spew:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/types:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/intstr:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//vendor/k8s.io/utils/exec:go_default_library", "//vendor/k8s.io/utils/exec/testing:go_default_library", ], "//conditions:default": [], }), </del> <ins> deps = [ "//pkg/api:go_default_library", "//pkg/proxy:go_default_library", "//pkg/proxy/util:go_default_library", "//pkg/util/iptables:go_default_library", "//pkg/util/iptables/testing:go_default_library", "//pkg/util/ipvs:go_default_library", "//pkg/util/ipvs/testing:go_default_library", "//vendor/github.com/davecgh/go-spew/spew:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/types:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/intstr:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//vendor/k8s.io/utils/exec:go_default_library", "//vendor/k8s.io/utils/exec/testing:go_default_library", ], </ins> ) go_library(

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Currently, IPVS proxier only runs in linux platfrom. What you expected to happen: Run IPVS proxier UTs everywhere, including !linux platfrom, which will help a lot when developing in windows platfrom. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig network
/area kube-proxy
Change:
impersonationUserExtras: map[string][]string{"scopes": {"scope-a", "scope-b"}}, expectedUser: &user.DefaultInfo{ Name:   "system:admin", <del> Groups: []string{}, </del> <ins> Groups: []string{"system:authenticated"}, </ins> Extra:  map[string][]string{"scopes": {"scope-a", "scope-b"}}, }, expectedCode: http.StatusOK,

Discussion:
<!-- 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 ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): impersonate system:authenticated 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: baremetal OS (e.g. from /etc/os-release): Centos7 Kernel (e.g. ): Install tools: custom Others: Using RBAC What happened: Impersonating a user is not setting group which causes impersonate to fail What you expected to happen: If a user is in the tokens file they and they are impersonated the group should be for authz. How to reproduce it (as minimally and precisely as possible): sure group has cluster role a test user via token file a user with impersonate access submit a command via kubectl That request will fail with 403 response even though the user is in the group. Anything else we need to know: cc
We can probably be smart and put the authenticated group adder around the result of the impersonation filter. you see any issues with that?
We provide the group field to provide this kind of information. I'm not sure I would expect my request to the server about a particular user/group tuple to be evaluated for a different user/group tuple.
for impersonation, we already add groups when known (service accounts). doing so for the system:authenticated/system:unauthenticated groups makes sense to me
Only when the groups aren't specified, right? If memory serves, that's how we did it downstream where we can make group determination.
Change:
if len(kp.Path) == 0 { allErrs = append(allErrs, field.Required(fldPath.Child("path"), "")) } <del> allErrs = append(allErrs, validateLocalNonReservedPath(kp.Path, fldPath.Child("path"))...) </del> <ins> allErrs = append(allErrs, ValidateLocalNonReservedPath(kp.Path, fldPath.Child("path"))...) </ins> if kp.Mode != nil && (*kp.Mode > 0777 || *kp.Mode < 0) { allErrs = append(allErrs, field.Invalid(fldPath.Child("mode"), *kp.Mode, fileModeErrorMsg)) }

Discussion:
Originally posted by in
Hello, I'm new here. Can I try solving this? it seems like a good first issue
sure, context is the change is needed here: We have to tolerate existing pods / pod specs that fail this validation, so we should only do this additional validation on create or if the existing object passes this validation. To do this: an field to , initialize that field to false, and then conditionally override it to if is non-nil and has a projected token volume path that fails (will have to export the function to check this) , if is false, call the validation on the path:
Hi, I'd like to work on this if there is no one is proceeding on. /assign
Change:
if err != nil { return err } <del> fmt.Fprintf(o.Out, string(jsonBuffer.Bytes())) </del> <ins> fmt.Fprint(o.Out, string(jsonBuffer.Bytes())) </ins> case "yaml": yamlOutput, err := yaml.JSONToYAML([]byte(str)) if err != nil { return err } <del> fmt.Fprintf(o.Out, string(yamlOutput)) </del> <ins> fmt.Fprint(o.Out, string(yamlOutput)) </ins> } }

Discussion:
Is this a request for help?: No What keywords did you search in Kubernetes issues before filing this one?: save-config, view-last-applied Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- 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: Environment: Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): cos What happened: Create this: Then we print it: Notice that is printed as . But the saved config is correct, so it's clearly a YAML-printing error: This seems to be caused by being interpreted as a Go format code, because I also get this for other occurrences of : What you expected to happen: It should print the exact saved data. How to reproduce it (as minimally and precisely as possible): See above.
/sig cli /kind bug
/assign
/unassign Unassign since already has a PR
Change:
import ( "encoding/json" <ins> "errors" "net/http" </ins> "strconv" "strings" "sync"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, when AAD login is configured, refresh token timeout would make kubectl print an error, not able to re-login without manually remove the tokens. Expect kubectl to promote user to login again. Why is this needed: Configure refresh-token timeout from Azure is a way to force re-login after inactivity. kubectl doesn't promote re-login makes users harder to apply timeout policy.
/sig azure
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig azure 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
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/area provider/azure
the root cause of this issue is in this first gets the cached token (result of device code flow) at it's trying to refresh an expired token at and failed. An error is returned. Since the expired token is still in the cache, it will always hit this path until user removes the token from kubeconfig. the fix should be: the token from cache a retry to re-initiate the device code flow in
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/sig cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
I'm working on it.
are you working on it? I will grab it if I dont hear it from you :)
have the code ready will try PR this weekend Best, Ping
/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-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Closing as merged
Change:
$ kubectl proxy --port=8011 --www=./local/www/ // Run a proxy to kubernetes apiserver, changing the api prefix to k8s-api <del> // This makes e.g. the pods api available at localhost:8011/k8s-api/v1beta1/pods/ $ kubectl proxy --api-prefix=k8s-api </del> <ins> // This makes e.g. the pods api available at localhost:8011/k8s-api/v1beta3/pods/ $ kubectl proxy --api-prefix=/k8s-api </ins> ``` ### Options

Discussion:
Without , works just fine, With '--api-prefix=xxx-api', it stops work: My version: could you take a look? Thanks.
--api-prefix was in . could you take a look? This appears to be completely broken, so we should fix it or rip it out.
Reading the code and I find the way to fix it. You need to use , note the slashes. I will fix the man page.
What's an example command line that works?
then
Ah, the default flag value has leading and trailing slashes: The example in the documentation is wrong: Re-opening for doc fix.
The trailing slash is not necessary. and duplicate each other.
Change:
} // IsCriticalPodBasedOnPriority checks if the given pod is a critical pod based on priority resolved from pod Spec. <del> func IsCriticalPodBasedOnPriority(ns string, priority int32) bool { // Critical pods are restricted to "kube-system" namespace as of now. if ns != kubeapi.NamespaceSystem { return false } </del> <ins> func IsCriticalPodBasedOnPriority(priority int32) bool { </ins> if priority >= scheduling.SystemCriticalPriority { return true }

Discussion:
When we used annotations to mark critical pods, we considered pods with such an annotation critical only when they were created in "kube-system" namespace. Going to the new era of using priority to indicate critical pods, we would like to remove the restriction of "kube-system" namespace and consider pods with critical priority as critical no matter what namespace they are in. ref/ /kind bug /sig scheduling /assign cc/
While I am fine with the approach, it seems the only way to ensure that those critical pods are not coming from some random namespace is whitelisting them using priority admission controller or using quota. Atleast previously we have one more level of security that critical pod has to be created in kube-system namespace.
The requirement to limit the critical pod annotation meaning to the kube-system namespace was a workaround for the lack of access control and quota around the annotation. We actively work to prevent special handling of the kube-system namespace wherever possible.
Yes, which is why those aspects are essential to a functional priority system that works for a variety of cluster configurations
Agree with Ravi and Jordan on what is needed for final solution.
There is no doubt that we need to have quota for priority. It is needed not only for critical priorities, but also for any other high priority classes that users may define. That effort is going forward and we will have it soon.
, I think we also need to update Priority admission controller for that.
see later PR re-restricting this until the quota controls graduate to at least beta state:
Got that, thanks :) That makes sense to me.
If this is closed and there even was a for this type of functionality, what is the current status? And is in sync with current status?
It seems that namespace is still , so I guess the current status is that system critical pods are still limited to namespace. Based on that I think this issue should not be closed.
can we reopen this issue please because as pointed out by the issue still exists. Thanks.
Waiting for this to be available myself. No reason my Node Exporter dataset has to run in the namespace instead of my Grafana namespace.
Confirmed code + behavior. /open
/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
I too am confused based on that documentation. Can we get an update here with an answer and fix the documentation if it's wrong?
This is resolved in 1.17 See