jiebi/CodeConvo huggingface dataset:
Code change:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: 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 do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

Related discussion:
text: MinExternalEtcdVersion = "3.2.18" // DefaultEtcdVersion indicates the default etcd version that kubeadm uses <del> DefaultEtcdVersion = "3.5.0-rc.0-0" </del> <ins> DefaultEtcdVersion = "3.5.0-0" </ins> // Etcd defines variable used internally when referring to etcd component Etcd = "etcd"
Code change:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: 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 do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

Related discussion:
text: 19: "3.4.13-0", 20: "3.4.13-0", 21: "3.4.13-0", <del> 22: "3.5.0-rc.0-0", 23: "3.5.0-rc.0-0", </del> <ins> 22: "3.5.0-0", 23: "3.5.0-0", </ins> } // KubeadmCertsClusterRoleName sets the name for the ClusterRole that allows
Code change:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: 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 do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

Related discussion:
text: # A set of helpers for starting/running etcd for tests <del> ETCD_VERSION=${ETCD_VERSION:-3.5.0-rc.0} </del> <ins> ETCD_VERSION=${ETCD_VERSION:-3.5.0} </ins> ETCD_HOST=${ETCD_HOST:-127.0.0.1} ETCD_PORT=${ETCD_PORT:-2379} export KUBE_INTEGRATION_ETCD_URL="http://${ETCD_HOST}:${ETCD_PORT}"
Code change:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: 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 do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

Related discussion:
text: imagePullPolicy: Never args: [ "--etcd-servers=http://localhost:2379" ] - name: etcd <del> image: quay.io/coreos/etcd:v3.5.0-rc.0 </del> <ins> image: quay.io/coreos/etcd:v3.5.0 </ins>
Code change:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: 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 do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

Related discussion:
text: e2essh "k8s.io/kubernetes/test/e2e/framework/ssh" ) <del> const etcdImage = "3.5.0-rc.0-0" </del> <ins> const etcdImage = "3.5.0-0" </ins> // EtcdUpgrade upgrades etcd on GCE. func EtcdUpgrade(targetStorage, targetVersion string) error {
Code change:
Creating a service with fails to be created when trying to use a TCP health probe. Example service: Failed as follows: Health probe works correctly and is registered properly as TCP health probe. Take the mentioned service yaml and apply it, together with a corresponding pod / deployment exposing port 445. E.g. like this: The respective code seems to take the wrong path to me (it's +/- the same code on the in-tree as on the out of tree cloud provider): My reading of the code and passed values are like this: returns returns -- because returns returns therefore: So the requestPath is not at this point and the azure API server returns a 400 bad request. Kubernetes version (use ): 1.20.6 Cloud provider or hardware configuration: azure OS (e.g: ): linux Network plugin and version (if this is a network-related bug): vxlan & flannel
/sig cloud-provider
related PR introducing the feature:
/assign /triage accepted
/assign

Related discussion:
text: # See the License for the specific language governing permissions and # limitations under the License. <del> # Set provider independent environment variables </del> <ins> # Set the default provider of Kubernetes cluster to know where to load provider-specific scripts # You can override the default provider by exporting the KUBERNETES_PROVIDER # variable in your bashrc # # The valid values: 'gce', 'azure' and 'vagrant' </ins> <del> # Set provider of Kubernetes cluster to know where to load provider-specific scripts, values: gce, vagrant, etc. KUBERNETES_PROVIDER="gce" #KUBERNETES_PROVIDER="vagrant" </del> <ins> KUBERNETES_PROVIDER=${KUBERNETES_PROVIDER:-gce} </ins>
Code change:
When we introduced we an additional check during attach disk call to check for canonical path - Now this is creating a regression in many deployments because when volume is created, canonical path gets replaced - and hence when attach is attempted k8s can't find canonical path of the volume anymore. It throws following error: There are two ways of fixing this. We could decide to use old in attach code, if we can't fetch canonical path or we could decide not to replace canonical path during provisioning. cc /sig storage
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
cc:
The code that replaces canonical Path during provisioning is pretty old and hence I don't remember/know why we are doing that. But since there could be many existing PVs that now have different canonical path - I think it might be safest to merge - to prevent any regressions.

Related discussion:
text: return "", err } <del> // try and get canonical path for disk and if we can't throw error vmDiskPath, err = getcanonicalVolumePath(ctx, vm.Datacenter, vmDiskPath) if err != nil { klog.Errorf("failed to get canonical path for %s on node %s: %v", vmDiskPath, convertToString(nodeName), err) return "", err </del> <ins> // try and get canonical path for disk and if we can't use provided vmDiskPath canonicalPath, pathFetchErr := getcanonicalVolumePath(ctx, vm.Datacenter, vmDiskPath) if canonicalPath != "" && pathFetchErr == nil { vmDiskPath = canonicalPath </ins> } diskUUID, err = vm.AttachDisk(ctx, vmDiskPath, &vclib.VolumeOptions{SCSIControllerType: vclib.PVSCSIControllerType, StoragePolicyName: storagePolicyName})
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --https://prow.ppc64le- Below two test cases started failing on ppc64le: 6th June 2021 https://k8s- ... was the delta between the passing and failing tests Started failing after
/assign
/sig cloud-provider /priority important-soon /triage accepted /assign
Thanks for reporting the issue. This was caused by vendor changes in , which introduced external dependency on IMDS. If IMDS endpoint is not reachable, then the new logic would report error.
Filed to clean up the failed tests.

Related discussion:
text: } ) <del> func TestGetServicePrincipalTokenFromMSIWithUserAssignedID(t *testing.T) { configs := []*AzureAuthConfig{ { UseManagedIdentityExtension: true, UserAssignedIdentityID:      "UserAssignedIdentityID", }, // The Azure service principal is ignored when // UseManagedIdentityExtension is set to true { UseManagedIdentityExtension: true, UserAssignedIdentityID:      "UserAssignedIdentityID", TenantID:                    "TenantID", AADClientID:                 "AADClientID", AADClientSecret:             "AADClientSecret", }, } env := &azure.PublicCloud for _, config := range configs { token, err := GetServicePrincipalToken(config, env) assert.NoError(t, err) msiEndpoint, err := adal.GetMSIVMEndpoint() assert.NoError(t, err) spt, err := adal.NewServicePrincipalTokenFromMSIWithUserAssignedID(msiEndpoint, env.ServiceManagementEndpoint, config.UserAssignedIdentityID) assert.NoError(t, err) assert.Equal(t, token, spt) } } func TestGetServicePrincipalTokenFromMSI(t *testing.T) { configs := []*AzureAuthConfig{ { UseManagedIdentityExtension: true, }, // The Azure service principal is ignored when // UseManagedIdentityExtension is set to true { UseManagedIdentityExtension: true, TenantID:                    "TenantID", AADClientID:                 "AADClientID", AADClientSecret:             "AADClientSecret", }, } env := &azure.PublicCloud for _, config := range configs { token, err := GetServicePrincipalToken(config, env) assert.NoError(t, err) msiEndpoint, err := adal.GetMSIVMEndpoint() assert.NoError(t, err) spt, err := adal.NewServicePrincipalTokenFromMSI(msiEndpoint, env.ServiceManagementEndpoint) assert.NoError(t, err) assert.Equal(t, token, spt) } } </del> func TestGetServicePrincipalToken(t *testing.T) { config := &AzureAuthConfig{ TenantID:        "TenantID",
Code change:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

Related discussion:
text: } func (q *graceTerminateRSList) flushList(handler func(rsToDelete *listItem) (bool, error)) bool { <ins> q.lock.Lock() defer q.lock.Unlock() </ins> success := true for name, rs := range q.list { deleted, err := handler(rs)
Code change:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

Related discussion:
text: } if deleted { klog.InfoS("Removed real server from graceful delete real server list", "realServer", name) <del> q.remove(rs) </del> <ins> delete(q.list, rs.String()) </ins> } } return success
Code change:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

Related discussion:
text: package ipvs import ( <ins> "fmt" netutils "k8s.io/utils/net" </ins> "reflect" "testing" utilipvs "k8s.io/kubernetes/pkg/util/ipvs" utilipvstest "k8s.io/kubernetes/pkg/util/ipvs/testing" <del> netutils "k8s.io/utils/net" </del> ) func Test_GracefulDeleteRS(t *testing.T) {
Code change:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

Related discussion:
text: }) } } <ins> func Test_RaceTerminateRSList(t *testing.T) { ipvs := &utilipvstest.FakeIPVS{} gracefulTerminationManager := NewGracefulTerminationManager(ipvs) go func() { for i := 1; i <= 10; i++ { for j := 1; i <= 100; j++ { gracefulTerminationManager.rsList.add(makeListItem(i, j)) } } }() if !gracefulTerminationManager.rsList.flushList(gracefulTerminationManager.deleteRsFunc) { t.Error("failed to flush entries") } } func makeListItem(i, j int) *listItem { vs := fmt.Sprintf("%d.%d.%d.%d", 1, 1, i, i) rs := fmt.Sprintf("%d.%d.%d.%d", 1, 1, i, j) return &listItem{ VirtualServer: &utilipvs.VirtualServer{ Address:  netutils.ParseIPSloppy(vs), Protocol: "tcp", Port:     uint16(80), }, RealServer: &utilipvs.RealServer{ Address: netutils.ParseIPSloppy(rs), Port:    uint16(80), }, } } </ins>