jiebi/CodeConvo huggingface dataset:
Change:
apierrors "k8s.io/apimachinery/pkg/api/errors" "k8s.io/apimachinery/pkg/api/meta" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" <ins> "k8s.io/apimachinery/pkg/runtime/schema" </ins> utilerrors "k8s.io/apimachinery/pkg/util/errors" utilruntime "k8s.io/apimachinery/pkg/util/runtime" "k8s.io/apimachinery/pkg/util/sets"

Discussion:
What happened: Created a CRD: Created another CRD defining an overlapping type with CustomResourceDefinition: Verify both exist: Deleted the one overlapping with the in-tree CRD type: Verify only the overlapping CRD remains: and is stuck deleting: What you expected to happen: Creation and deletion of the overlapping type CRD would have no effect on the in-tree data. Anything else we need to know?: The only types in the kube-apiserver (currently) that store data under a group prefix are: APIService () CustomResourceDefinition () Custom resources () When a CRD is deleted, all instances of the type it defines are first removed. That means that defining and deleting a CustomResourceDefinition that defines an overlapping APIService or CustomResourceDefinition type will remove existing APIService or CustomResourceDefinition data. We can special-case these two resources in the CRD deletion code, but we need a more robust solution before CRD v1. /cc /sig api-machinery /priority important-soon /area custom-resources
/sub
Is anyone working on this? I'll like to take a stab at this.
Not currently, no. Great. I'd suggest discussion a potential solution here before diving into code. The two main aspects are: -time - Should we forbid creating CRDs that overlap with built-in types? -time - How do we detect a CRD overlapping with a built-in type and skip the etcd cleanup for it
I think we should forbid creating CRDs that overlap (option 1).
That can help, but is not sufficient. Imagine: n forbids creating overlapping CRDs on version n creates MyType, which is allowed because that is not a built-in type upgrades to version n+1 which adds MyType as a built-in type deletes CRD What should happen?
For that, we may need delete-time detection of overlapping types as well (option 2), which may make option 1 redundant. Do you have any advice for detecting overlapping CRDs?
for now, just delete-time detection in
Change:
"//pkg/api/v1:go_default_library", "//pkg/api/v1/helper:go_default_library", "//pkg/apis/apps/v1beta1:go_default_library", <ins> "//pkg/apis/autoscaling/v1:go_default_library", </ins> "//pkg/apis/batch/v1:go_default_library", "//pkg/apis/extensions/v1beta1:go_default_library", "//pkg/controller:go_default_library",

Discussion:
Currently the time it takes for HPA and CA to scale up after load increase is not measured at all, and this can lead to regressions that will be missed. This issue is about adding an e2e test that will prevent such regressions.
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 .
Filip, can you reopen? I cannot do this myself, and this issue is clearly not closed yet.
Thanks Wojtek!
Change:
<ins> /* Copyright 2019 The Kubernetes Authors. 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 yaml import ( "fmt" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" "sigs.k8s.io/yaml" ) // DefaultMetaFactory is a default factory for versioning objects in JSON or // YAML. The object in memory and in the default serialization will use the // "kind" and "apiVersion" fields. var DefaultMetaFactory = SimpleMetaFactory{} // SimpleMetaFactory provides default methods for retrieving the type and version of objects // that are identified with an "apiVersion" and "kind" fields in their JSON // serialization. It may be parameterized with the names of the fields in memory, or an // optional list of base structs to search for those fields in memory. type SimpleMetaFactory struct{} // Interpret will return the APIVersion and Kind of the JSON wire-format // encoding of an object, or an error. func (SimpleMetaFactory) Interpret(data []byte) (*schema.GroupVersionKind, error) { gvk := runtime.TypeMeta{} if err := yaml.Unmarshal(data, &gvk); err != nil { return nil, fmt.Errorf("could not interpret GroupVersionKind; unmarshal error: %v", err) } gv, err := schema.ParseGroupVersion(gvk.APIVersion) if err != nil { return nil, err } return &schema.GroupVersionKind{Group: gv.Group, Version: gv.Version, Kind: gvk.Kind}, nil } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add an external MetaFactory that allows for serializing multiple YAML (or JSON) files in kubeadm. The logic of marshalling YAML should be factored out from to . Why is this needed: This will allow processing component configs containing multiple documents per file. Additionally, an out-of-tree library would allow sharing this functionality with other components.
I will try work on this as carry-on from /sig cluster-lifecycle /cc
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
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
Change:
func (s *SchedulerServer) AddHyperkubeFlags(fs *pflag.FlagSet) { s.addCoreFlags(fs) <del> fs.StringVar(&s.kmPath, "km-path", s.kmPath, "Location of the km executable, may be a URI or an absolute file path.") </del> <ins> fs.StringVar(&s.kmPath, "km-path", s.kmPath, "Location of the km executable, may be a URI or an absolute file path; may be prefixed with 'file://' to specify the path to a pre-installed, agent-local km binary.") </ins> } // returns (downloadURI, basename(path))

Discussion:
I'd like to run local in agent host. The parameters is used to set executor, but it did not set 's arguments. The proposal is to provide an argument to set the local path of in agent host. cc
It seems we have a hidden parameter , I'll try it firstly.
any suggestion?
how did work out? if you ran into problems .. what were they?
Just have a try, it seems not work; I'm on sure whether configuration issue.
, just go through the code; the will only point to the binaries in master and Mesos agent will fetch it. It did not match this requirement. Do you have time on this? I'd like to work on this and let you review it :).
, would you help to review the patch?
Yes, just provided some feedback on your PR , Klaus Ma wrote:
Change:
}, timeToPass: 1 * time.Minute, newNodeStatus: v1.NodeStatus{ <del> NodeInfo: v1.NodeSystemInfo{ KubeletVersion: "v1.2.0", }, </del> Conditions: []v1.NodeCondition{ { Type:   v1.NodeReady,

Discussion:
As discussed on slack with we might want to clean the node controller from code that ensures backward compatibility for version 1.4 and earlier ones. /sig node
/assign
- how do we plan to devide this one ? The following order for merge should be fine I think: the tests (we can split also test case deletion if it's too long to review): logic itself + kubeletVersion on the according tests: change how we create nodecontroller: clean consts and BUILD:
Yeah, sounds good.
I'll create the PRs accordingly and assign them to you
Change:
Master(clusterName string) (string, error) } <del> func GetLoadBalancerName(clusterName, serviceNamespace, serviceName string) string { return clusterName + "-" + serviceNamespace + "-" + serviceName </del> <ins> // TODO(#6812): Use a shorter name that's less likely to be longer than cloud // providers' name length limits. func GetLoadBalancerName(service *api.Service) string { //GCE requires that the name of a load balancer starts with a lower case letter. ret := "a" + string(service.UID) ret = strings.Replace(ret, "-", "", -1) //AWS requires that the name of a load balancer is shorter than 32 bytes. if len(ret) > 32 { ret = ret[:32] } return ret </ins> } // TCPLoadBalancer is an abstract, pluggable interface for TCP load balancers.

Discussion:
Since this PR got merged, the ELB e2e test, which was consistently succeeding, is now consistently failing: Revert now that is in, and fix the tests that were relying on it. (details) Commit by arob Revert now that is in, and fix the tests that were relying on it. The file was modified The file was modified The file was modified I'm going to roll it back to confirm.
Change:
"strings" "testing" <del> apps "k8s.io/api/apps/v1" </del> batchv1 "k8s.io/api/batch/v1" batchv1beta1 "k8s.io/api/batch/v1beta1" corev1 "k8s.io/api/core/v1"

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: of Job created by using command will be . This apiVersion is wrong. What you expected to happen: Set the to How to reproduce it (as minimally and precisely as possible): CronJob manifest: <details</detailsApply CronJob and execute command Anything else we need to know?: Environment: Kubernetes version (use ):
/sig cli
This was introduced by . /assign
GitHub didn't allow me to assign the following users: odino. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : This was introduced by . 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 created fix pull request:
Change:
type InsecureSuperuser struct{} func (InsecureSuperuser) AuthenticateRequest(req *http.Request) (*authenticator.Response, bool, error) { <ins> auds, _ := request.AudiencesFrom(req.Context()) </ins> return &authenticator.Response{ User: &user.DefaultInfo{ Name:   "system:unsecured", Groups: []string{user.SystemPrivilegedGroup, user.AllAuthenticated}, }, <ins> Audiences: auds, </ins> }, true, nil }

Discussion:
Semantics are going to vary. We need to cross off these authenticators: [x] if ctx has an audience limitation, verify the token audience and echo in the response [x] take implicit audiences at WebhookTokenAuthenticator construction time if ctx is audience-limited, add into the tokenreview object if the tokenreview returns with an audience set that matches the ctx, copy into the response and return success if the tokenreview returns without an audience set, ensure the ctx audiences intersect with the implicit audiences taken at WebhookTokenAuthenticator construction time, and pick one to add into the response [x] echo audience in response if present in ctx [x] echo audience in response if present in ctx [x] check that the the order of (audience in the context) ∩ ( (implicit api audiences) ∪ (clientids) ) 0 Take implicit audiences at Authenticator construction time, and if ctx is audience-limited, ensure it intersects with the implicit audiences, and echo an audience in the response. [x] [x] [x] [x] [x] [x] Do nothing? [x] [x] [x] [x] [x] [x] [x] note: we already keyed the cache with the audience. [x]
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
/close
Closing this issue. <detailsIn response to : /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:
Then you can create the service by running: <del> ```shell cluster/cloudcfg.sh -c redis-slave-controller.json create /replicationControllers </del> <ins> ```js $ cluster/cloudcfg.sh -c examples/guestbook/redis-slave-controller.json create /replicationControllers Using master: kubernetes-master (external IP: 1.2.3.4) { "id": "redisSlaveController", "desiredState": { "replicas": 2, "replicasInSet": { "name": "redisslave" }, "podTemplate": { "desiredState": { "manifest": { "version": "", "volumes": null, "containers": [ { "image": "brendanburns/redis-slave", "ports": [ { "hostPort": 6380, "containerPort": 6379 } ] } ] } }, "labels": { "name": "redisslave" } } }, "labels": { "name": "redisslave" } } </ins> ``` The redis slave configures itself by looking for the Kubernetes service environment variables in the container environment.  In particular, the redis slave is started with the following command:

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: I am running an admission webhook using If there it has been hours since the last mutating request to the webhook, then the next mutating request will take many seconds to be processed. This may even take long enough to have the request time out. What you expected to happen: A request takes approximately the same amount of time to be processed regardless of how long it has been since the last request. How to reproduce it (as minimally and precisely as possible): Create an API server for handling a new API group. Wait a couple hours. Send a CREATE request to the API server. Observe that the CREATE request takes a few seconds to complete. Anything else we need to know?: This is the offending code. It must loop through once for every second since the last request. Environment: Kubernetes version (use ): 1.19.0
/sig api-machinery
I thought we'd already merged a fix for this from before the release?
I assume that the fix was supposed to be From my understanding, those changes only are in effect if the apiserver is running with priority and fairness enabled. In my situation, I do not have that enabled.
Ack, if we have the problem in both places we need the fix in both places :)
/triage accepted
I think we have fixed this in , do you guys agree?
Change:
treated as "reconcile class addons" for now. - Resources under `$ADDON_PATH` need to have either one of these two labels. Otherwise it will be omitted. <del> - The above label and namespace rule does not stand for `/opt/namespace.yaml` and resources under `/etc/kubernetes/admission-controls/`. addon-manager will attempt to create them regardless during startup. </del> #### How to release

Discussion:
What happened: Add-on manager uses kubectl apply to create the kube-system namespace at start-up. This is redundant because the kube-apiserver creates the namespace in NewBootstrapController. This is a problem because if someone uses apply to make changes to the kube-system namespace, the add-on manager will wipe out these changes. What you expected to happen: Kube-APIServer has the sole responsibility of creating the kube-system namespace. How to reproduce it (as minimally and precisely as possible): kubectl apply a label to the kube-system namespace. restart the add-on manager. Note the labels have been removed. Anything else we need to know?: /sig api-machinery Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
the contention script wipes out namespace ^^
/cc
i guess it is intentional to have the addon manager to ensure kube-system is not modified, it tries to avoid the case that some cluster admin accidentally delete kube-system that result in a non-functional cluster.
The add-on manager will only perform the check when it restarts. The API Server will also perform this check when it restarts. I think we should only have 1 system responsible for this and I believe that system should be the API server.
trying to have my first contribute here, so is it proper to have the kube-system existence checked before applying the yaml file to create the kube-system namespace once again?
The Kube API Server will check for the existence of the kube-system namespace and create it if absent. It does all of this using client-go requests. The Add-On manager is the only system creating the kube-system by applying (a private) yaml file. I believe the correct fix here is to remove the Add-On managers attempts to create the kube-system namespace entirely. This is especially important if a user writes a CI/CD controller to apply their desired state to the kube-system namespace. I would argue the CI/CD is correct but the add-on manager will randomly wipe out the users changes. The API Server on the other hand will not.
, thanks for your help, so i will remove that line and pull a request later
Trying to get my first PR here. Is the issue still open ?
The issue is still open. You may want to check on though as was trying to fix the issue with that PR.
Change:
w.Write(LEVEL_0, "Namespace:t%sn", pvc.Namespace) w.Write(LEVEL_0, "StorageClass:t%sn", storageutil.GetPersistentVolumeClaimClass(pvc)) if pvc.ObjectMeta.DeletionTimestamp != nil { <del> w.Write(LEVEL_0, "Status:tTerminating (lasts %s)n", translateTimestampUntil(*pvc.ObjectMeta.DeletionTimestamp)) </del> <ins> w.Write(LEVEL_0, "Status:tTerminating (lasts %s)n", translateTimestampSince(*pvc.ObjectMeta.DeletionTimestamp)) </ins> } else { w.Write(LEVEL_0, "Status:t%vn", pvc.Status.Phase) }

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: Kubectl describe pv xxx shows last<invalidif pv is terminating ! I found pvc and pod have the same issue What you expected to happen: Terminating (lasts 10s) How to reproduce it (as minimally and precisely as possible): 1 create a pv, pvc or pod is terminating 2 using kubectk describe xxx Anything else we need to know?: Environment: Kubernetes version (use ): 1.13.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig cli
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/assign
Change:
package mount import ( <ins> "os" </ins> "path/filepath" "strings"

Discussion:
What happened: Windows documentation claims: V1.VolumeMount.mountPropagation - only MountPropagationHostToContainer is available. However, the internals suggest otherwise; is always returned on Windows: Either the docs should be corrected, or the Kubelet should be updated, or we should have a comment on why this does in fact enable MountPropagationHostToContainer on Windows. /cc /sig windows
/cc
/cc
I think the doc is not accurate. The doc claims the same thing. For MountPropagationHostToContainer option, we can test it whether it is working or not.
i created two PRs to address the documentation gap. we will also test this and get back to this thread.
For 1.15 we may need to update Kubelet code to allow HostToContainer.
Change:
fs.StringSliceVar(&o.OIDC.SigningAlgs, "oidc-signing-algs", []string{"RS256"}, ""+ "Comma-separated list of allowed JOSE asymmetric signing algorithms. JWTs with a "+ <del> "'alg' header value not in this list will be rejected. "+ </del> <ins> "supported 'alg' header values are: RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512. "+ </ins> "Values are defined by RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1.") fs.Var(cliflag.NewMapStringStringNoSplit(&o.OIDC.RequiredClaims), "oidc-required-claim", ""+

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 --A kube-apiserver does not support all of the signing algorithms listed in RFC 7518 It fails with something like When looking into the or in the code I really get the impression that all algorithms from the RFC document are supported But after some time, I noticed the most essential word is : The documentation to be improved to explicitly list the supported algorithms instead of referring to the RFC document that lists much more algorithms than the actual supported ones. Run the kube-apiserver with flag I think the really supported algorithms are explicitly listed here 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:
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 auth /kind documentation
: I will be happy to do it, but would require some more insight on what is to be done?
Hi Could you please elaborate what is not clear? I think I have provided quite detailed information and references to the code and documentation. Just to be clear, the documentation is correct even today, but it is hard to digest as the referenced RFC document does not describe which signing algorithm is asymmetric and which symmetric.
Hi IMO We can do two things here either we will mention the supported signing algorithm for oidc instead of or explicitly mention the supported signing algorithm in the docs. What do you suggest? I'm up for it if nobody is doing that.
Fixed it here: