jiebi/CodeConvo huggingface dataset:
Change:
<ins> /* Copyright 2016 The Kubernetes Authors 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 types // int64 is used as a safe bet against wrap-around (uid's are general // int32) and to support uid_t -1, and -2. type UnixUserID int64 type UnixGroupID int64 </ins>

Discussion:
We have a couple fields in the API for Unix UID and GID. We should define and and use them everywhere.
Is really correct? As you pointed out, GID is an unsigned int32, isn't it?
If I recall, POSIX does not actually specify signedness and some Unixes differ on it. int64 seems like a safe superset, unless we know of any OS that uses 64 bit UID/GID ? On Oct 16, 2015 6:58 AM, "Paul Morie" wrote:
I personally don't know of one. How about you ?
int64 also has the nice property of allowing negative values without wraparound. (uidt)-1 is a thing, sadly, and (uidt)-2 is apparently a thing, too. , Paul Morie wrote:
Okay, you've got me on the fence.
I will change and will change when he's back from PTO.
We might want to talk through the effects of changing this on the origin policy stuff before we start doing it.
Okay, after talking to I suggest that we do the following: Change the types of and to and respectively in and Have another commit that makes the following type changes: Introduce and as has suggested in this issue Changes the types in and in applicable fields This will be easier for us to consume in our rebase of OpenShift onto Kubernetes than if we modify and before going into master. Any objections?
I don'[t object as long as the final goal is correct , Paul Morie wrote:
Change:
klog.Infof(log("blockMapper.stageVolumeForBlock STAGE_UNSTAGE_VOLUME capability not set. Skipping MountDevice...")) return "", nil } <del> publishVolumeInfo := attachment.Status.AttachmentMetadata </del> <ins> publishVolumeInfo := map[string]string{} if attachment != nil { publishVolumeInfo = attachment.Status.AttachmentMetadata } </ins> nodeStageSecrets := map[string]string{} if csiSource.NodeStageSecretRef != nil { nodeStageSecrets, err = getCredentialsFromSecret(m.k8s, csiSource.NodeStageSecretRef)

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: During I develop a driver that supports raw block devices but do not need to be attached to nodes, I found it would fail when a pod mount a raw block device. PS: I use cluster-driver register and make requiredAttach as false. kubectl get csidriver csi-xxx -o yaml ! What you expected to happen: Mount a raw block device successfully. How to reproduce it (as minimally and precisely as possible): driver that supports raw block devices but do not need to be attached to nodes, I found it would fail when a pod mount a raw block device. cluster-driver register and make requiredAttach as false. a pod with raw block devices Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: BaiduCloud OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage /assign
I would send a PR later
Change:
if err == nil { t.Errorf("expected error too old") } <ins> if _, ok := err.(*errors.StatusError); !ok { t.Errorf("expected error to be of type StatusError") } </ins> } { result, err := store.GetAllEventsSince(2)

Discussion:
We sorta fixed this-- now it's a real status error, but we left the status code 500, so it still produces stack traces and potentially confuses clients. we should figure out the correct status code.
I think there is a lot more going on related to this in . Clients are re-listing after the error but not rewatching.
/sub
It turned out this was not causing job e2e flakes. Just sending 500s that were confusing. So lowering priority.
How about a NewBadRequest error?
that certainly sounds like an improvement.
Change:
kubectl create -f $KUBE_REPO/examples/mysql-wordpress-pd/local-volumes.yaml ``` ### GCE Persistent Disk This storage option is applicable if you are running on

Discussion:
Version: Running this example on RHEL 7.2 (assume same for centos), and using hostPath, I get a permissions error when the mysql container does a . If I set selinux to permissive on the host it works. If I manually run the container with it works. I was not able to get it to work when adding to the deployment. My fix was to locate the PVs in by changing the local- file, and doing . I this comment to local- If this issue is valid I will create a quick PR to doc this selinux solution.
See pr
Change:
UserAssignedIdentityID string `json:"userAssignedIdentityID,omitempty" yaml:"userAssignedIdentityID,omitempty"` // The ID of the Azure Subscription that the cluster is deployed in SubscriptionID string `json:"subscriptionId,omitempty" yaml:"subscriptionId,omitempty"` <ins> // Identity system value for the deployment. This gets populate for Azure Stack case. IdentitySystem string `json:"identitySystem,omitempty" yaml:"identitySystem,omitempty"` </ins> } // GetServicePrincipalToken creates a new service principal token based on the configuration func GetServicePrincipalToken(config *AzureAuthConfig, env *azure.Environment) (*adal.ServicePrincipalToken, error) { <ins> var tenantID string if strings.EqualFold(config.IdentitySystem, ADFSIdentitySystem) { tenantID = "adfs" } else { tenantID = config.TenantID } </ins> if config.UseManagedIdentityExtension { klog.V(2).Infoln("azure: using managed identity extension to retrieve access token") msiEndpoint, err := adal.GetMSIVMEndpoint()

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need to enhance Azure cloud provider code to support both AAD and ADFS authentication. Why is this needed: On Azure Stack customer can have two type of deployment .
/sig azure
/assign
Change:
// ListAndWatch lists devices and update that list according to the Update call func (m *Stub) ListAndWatch(e *pluginapi.Empty, s pluginapi.DevicePlugin_ListAndWatchServer) error { log.Println("ListAndWatch") <del> var devs []*pluginapi.Device for _, d := range m.devs { devs = append(devs, &pluginapi.Device{ ID:     d.ID, Health: pluginapi.Healthy, }) } s.Send(&pluginapi.ListAndWatchResponse{Devices: devs}) </del> <ins> s.Send(&pluginapi.ListAndWatchResponse{Devices: m.devs}) </ins> for { select {

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?: /kind bug What happened: For now, UT in doesn't work because callback function will never be called, is rewritten in this function : Another thing, i'm wondering why we rewrite device health in function which in this file: What you expected to happen: UT assertion should be executed. How to reproduce it (as minimally and precisely as possible): Add some logs in callback function of , it will show nothing. Anything else we need to know?: I will send a PR to fix this. /cc WDYT? /sig node
/assign
GitHub didn't allow me to assign the following users: RenaudWasTaken. Note that only can be assigned. <detailsIn response to : /assign 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
Good catch
Change:
func getRESTMappings(mapper meta.RESTMapper, pruneResources *[]pruneResource) (namespaced, nonNamespaced []*meta.RESTMapping, err error) { if len(*pruneResources) == 0 { <del> // default whitelist // TODO: need to handle the older api versions - e.g. v1beta1 jobs. Github issue: #35991 </del> <ins> // default allowlist </ins> *pruneResources = []pruneResource{ {"", "v1", "ConfigMap", true}, {"", "v1", "Endpoints", true},

Discussion:
What happened: Sweeping uses of extensions/v1beta1 in preparation for , the addon manager stood out as using extensions/v1beta1 Ingress by default: What you expected to happen: All components shipped in 1.21 must use Ingress in order to work properly against a 1.22 API server. /sig networking cc per cluster/addons/addon-manager/OWNERS cc I'm not sure what the addon manager does if given a prune list of Ingress objects while still using a manifest containing extensions/v1 Ingress objects... this needs to be tested. /milestone v1.21 /priority important-soon /lifecycle frozen
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: cc /priority important-soon /lifecycle frozen 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 network
/triage accepted
how "urgent" is this? Can wait until next tuesday? Otherwise I can work on the tests this weekend :)
important, not urgent. it should happen early in the 1.21 cycle, but does not require work out of business hours
Hello! I am from the Bug Triage team! This issue has not been updated for a few weeks, so I'd like to check on the status. Code freeze is starting March 9th, 2021 (about 1 week from now). We want to ensure that each PR has a chance to be merged before code freeze. As the Issue is tagged for 1.21, is it still planned for this release?
we're waiting to the PR to get merged :) I guess it's important for the v1.21 release, for the sake of extensions apiGroup deprecation :) Will ping reviewers on the PR
Change:
w.Write(output) })) defer server.Close() <del> client := NewDiscoveryClientForConfigOrDie(&restclient.Config{Host: server.URL}) </del> for _, test := range tests { <ins> client := NewDiscoveryClientForConfigOrDie(&restclient.Config{Host: server.URL}) </ins> got, err := client.ServerResourcesForGroupVersion(test.request) if test.expectErr { if err == nil {

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: With client-go v0.17.0, I observed many "Throttling request" when DiscoveryClient is used to get API group resources from API server. This didn't happen with client-go kubernetes-1.16.0. It looks like originally this kind of discovery requests are not throttled because no rate limiter provided and QPS == 0. But with rate limiter is always set if nil rate limiter is provided. is particularly suspicious because it is always true because DefaultQPS is nonzero. What you expected to happen: Discovery requests should not be throttled as before. How to reproduce it (as minimally and precisely as possible): Create DiscoveryClient and then call with it. 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 api-machinery
The NewTokenBucketRateLimiter was via Always negotiate a decoder using ClientNegotiator /cc
To be clear, that was fixing a bug where the documented defaults for rate limiting were not taking effect. I don't think we should completely disable throttling until more of the server-side priority work is completed, but discovery is expected to be bursty, so I could see defaulting to a different amount in the discovery client constructor, similar to
Yeah, everyone must be rate limited. I think we could give discovery a big burst value.
opened
Change:
package cache import ( <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" )

Discussion:
/sig scheduling What happened: reverted an old behavior to ensure Pod information is not lost when Nodes are recreated without its Pods getting recreated. A ghost Pod is kep in The problem is that we rely in this map for determining deleted Nodes when updating the snapshot in . The good thing is that the nodeinfo's are cloned into the snapshot, so we shouldn't have nil pointer accesses. But we might lose a few cycles trying to schedule on nodes that are deleted How to reproduce it (as minimally and precisely as possible): a node with a few pods. node without deleting pods. Result: The snapshot still has the node. Environment: Kubernetes version (use ): 1.18+
/assign
It actually produces the error: which would cause failed scheduling cycles (the map is not recreated, only the lists).
Change:
tsInfo: storageframework.TestSuiteInfo{ Name:         "read-write-once-pod", TestPatterns: patterns, <del> FeatureTag:   "[Feature:ReadWriteOncePod]", </del> }, } }

Discussion:
For 1.27 we should graduate the ReadWriteOncePod feature to beta. This is needed to rollout the feature to GA. In beta this feature will support preemption of pods using PVCs. See:
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 storage /sig scheduling
Change:
Raw() } if err != nil { <del> Logf("Controller %s: Failed to GET from replica %d [%s]: %v:", r.controllerName, i+1, pod.Name, err) </del> <ins> Logf("Controller %s: Failed to GET from replica %d [%s]: %vnpod status: %#v", r.controllerName, i+1, pod.Name, err, pod.Status) </ins> continue } // The response checker expects the pod's name unless !respondName, in

Discussion:
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
Change:
} var tests = map[string]struct { <del> spec        core.PersistentVolumeClaimSpec gateEnabled bool want        *core.TypedLocalObjectReference </del> <ins> spec core.PersistentVolumeClaimSpec want *core.TypedLocalObjectReference </ins> }{ "enabled with empty ds": { <del> spec:        core.PersistentVolumeClaimSpec{}, gateEnabled: true, want:        nil, </del> <ins> spec: core.PersistentVolumeClaimSpec{}, want: nil, </ins> }, "enabled with invalid spec": { <del> spec:        invalidSpec, gateEnabled: true, want:        nil, </del> <ins> spec: invalidSpec, want: nil, </ins> }, "enabled with valid spec": { <del> spec:        validSpec, gateEnabled: true, want:        validSpec.DataSource, }, "disabled with invalid spec": { spec:        invalidSpec, gateEnabled: false, want:        nil, }, "disabled with valid spec": { spec:        validSpec, gateEnabled: false, want:        nil, }, "diabled with empty ds": { spec:        core.PersistentVolumeClaimSpec{}, gateEnabled: false, want:        nil, </del> <ins> spec: validSpec, want: validSpec.DataSource, </ins> }, "enabled with valid spec but nil APIGroup": { <del> spec:        validSpecNilAPIGroup, gateEnabled: true, want:        validSpecNilAPIGroup.DataSource, }, "disabled with valid spec but nil APIGroup": { spec:        validSpecNilAPIGroup, gateEnabled: false, want:        nil, </del> <ins> spec: validSpecNilAPIGroup, want: validSpecNilAPIGroup.DataSource, </ins> }, } for testName, test := range tests { t.Run(testName, func(t *testing.T) { <del> defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.VolumePVCDataSource, test.gateEnabled)() </del> DropDisabledFields(&test.spec, nil) if test.spec.DataSource != test.want { <del> t.Errorf("expected drop datasource condition was not met, test: %s, gateEnabled: %v, spec: %v, expected: %v", testName, test.gateEnabled, test.spec, test.want) </del> <ins> t.Errorf("expected drop datasource condition was not met, test: %s, spec: %v, expected: %v", testName, test.spec, test.want) </ins> } })

Discussion:
/kind feature /sig storage /sig api PVC Data Sources have been in beta since 1.16 and should be ready to be promoted to GA in the 1.18 release. KEP:
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /kind feature /sig storage /sig api 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:
podSchedulingDirty bool mutex sync.Mutex <ins> informationsForClaim []informationForClaim } type informationForClaim struct { // The availableOnNode node filter of the claim converted from the // v1 API to nodeaffinity.NodeSelector by PreFilter for repeated // evaluation in Filter. Nil for claim which don't have it. availableOnNode *nodeaffinity.NodeSelector // The status of the claim got from the // schedulingCtx by PreFilter for repeated // evaluation in Filter. Nil for claim which don't have it. status *resourcev1alpha2.ResourceClaimSchedulingStatus </ins> } func (d *stateData) Clone() framework.StateData {

Discussion:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign
Change:
}, }, update: networking.NetworkPolicy{ <del> ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: "bar"}, </del> <ins> ObjectMeta: metav1.ObjectMeta{Name: "baz", Namespace: "bar"}, </ins> Spec: networking.NetworkPolicySpec{ <del> PodSelector: metav1.LabelSelector{ MatchLabels: map[string]string{"a": "b"}, }, Ingress: []networking.NetworkPolicyIngressRule{}, </del> <ins> PodSelector: metav1.LabelSelector{}, Ingress:     []networking.NetworkPolicyIngressRule{}, </ins> }, }, }, } for testName, errorCase := range errorCases { <ins> errorCase.old.ObjectMeta.ResourceVersion = "1" errorCase.update.ObjectMeta.ResourceVersion = "1" </ins> if errs := ValidateNetworkPolicyUpdate(&errorCase.update, &errorCase.old); len(errs) == 0 { t.Errorf("expected failure: %s", testName) }

Discussion:
I tried to update the NetworkPolicy Spec field with more ingress rules but got It seems NetworkPolicy does not allow update on Spec This means if I want to have more ingress rules, I will have to add those in a new networkpolicy in the same namespace. Any reason why I should not add those in the existing one(update the existing networkpolicy)? Thanks!
This is as designed for now. The expectation is that updates to the spec will be allowed when the NetworkPolicy API moves from v1beta1 to GA.
(And that is planned for Kubernetes 1.6 release.)
good to know, thanks!
Note that the PR to move NetworkPolicy to v1 did not make it into v1.6, but is now planned for 1.7:
Oh, I didn't know about this bug and that didn't get changed in but we can do it as another PR after. (I'm trying to not make any more changes there so we can get it merged.)
Change:
func TestEndpointAddressNodeNameUpdateRestrictions(t *testing.T) { oldEndpoint := newNodeNameEndpoint("kubernetes-node-setup-by-backend") updatedEndpoint := newNodeNameEndpoint("kubernetes-changed-nodename") <del> // Check that NodeName cannot be changed during update (if already set) </del> <ins> // Check that NodeName can be changed during update, this is to accommodate the case where nodeIP or PodCIDR is reused. // The same ip will now have a different nodeName. </ins> errList := ValidateEndpoints(updatedEndpoint) errList = append(errList, ValidateEndpointsUpdate(updatedEndpoint, oldEndpoint)...) <del> if len(errList) == 0 { t.Error("Endpoint should not allow changing of Subset.Addresses.NodeName on update") </del> <ins> if len(errList) != 0 { t.Error("Endpoint should allow changing of Subset.Addresses.NodeName on update") </ins> } }

Discussion:
/kind bug What happened: We have noticed that one of the node-exporters is down. It turned out that service has "old" endpoint still. After digging deeper i see following errors in controller manager Turns out controller manager can not update endpoints for node-exporter service, because of this error. In endpoint list is see right IPs for worker nodes, but wrong IP for master node (that's why we detected the problem). Context: two worker nodes were recreated with new hostnames (generated randomly), but they use same ip address one master node were recreated with new hostname and new ip I've tried to manually update hostname and got same error, seems nodeName is not updatable field. It also affects all other endpoints, we were forced to recreated all pods (so they will change IPs) to be able to fix endpoints reconciliation. What you expected to happen: controller manager successfully update endpoints after node recreated with same IP, but different hostname. How to reproduce it (as minimally and precisely as possible): 1 master, 1 worker, service that points to pods with host network. k8s API service (keep it shut down) worker node with same IP and different host name to recreate pod on worker and in controller manager should appear error above. Anything else we need to know?: Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: baremetal OS (e.g. from /etc/os-release): CoreOS 1688.5.3 Kernel (e.g. ): 4.14.32-coreos Install tools: own tool () Others:
/sig node
what is the use case of changing node name?
/sig api-machinery
We have ephemeral immutable nodes in our clusters. So upgrade or any other operation will cause node recreation. Hostname generated automatically, but the IP address depends on the underlay hypervisor node, where node will be scheduled. So it's possible that node stays on the same hypervisor and uses same ip address.
/cc
/assign
/cc do you think it's reasonable to loose endpoints validation?
/sig network this API is owned by sig network