jiebi/CodeConvo huggingface dataset:
Change:
// This call is idempotent, and must not return an error if the sandbox has // already been removed. RemovePodSandbox(ctx context.Context, in *RemovePodSandboxRequest, opts ...grpc.CallOption) (*RemovePodSandboxResponse, error) <del> // PodSandboxStatus returns the status of the PodSandbox. </del> <ins> // PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not // present, returns an error. </ins> PodSandboxStatus(ctx context.Context, in *PodSandboxStatusRequest, opts ...grpc.CallOption) (*PodSandboxStatusResponse, error) // ListPodSandbox returns a list of PodSandboxes. ListPodSandbox(ctx context.Context, in *ListPodSandboxRequest, opts ...grpc.CallOption) (*ListPodSandboxResponse, error)

Discussion:
The behavior when requested id doesn't exist is not defined clearly in CRI. Currently, we define that should return when requested image doesn't exist (), and kubelet is relying on this behavior now (). However, we haven't clearly defined the behavior of and . Currently, they return error when requested sandbox/container doesn't exist, and kubelet is also relying on this behavior. Not super urgent, just track the issue here. /cc
/assign
Added for clarifying the behavior.
Change:
} log.Printf("OK: Constructed OIDC provider for issuer %v", unsafeClaims.Issuer) <del> validTok, err := iss.Verifier(&oidc.Config{ClientID: audience}).Verify(ctx, raw) </del> <ins> validTok, err := iss.Verifier(&oidc.Config{ ClientID:             audience, SupportedSigningAlgs: []string{oidc.RS256, oidc.ES256}, }).Verify(ctx, raw) </ins> if err != nil { log.Fatal(err) }

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 --e2e test fails with ECDSA Service Account key e2e test to succeed with ECDSA Service Account key Use ECDSA key for the service account key. Logs from the started test container: library defaults to by default as the only supported method while should be explicitly: Relevant code: On the API server side: Kubernetes version (use ): 1.21.0-rc.0 Cloud provider or hardware configuration: OS (e.g: ): Talos 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 testing
Changing the service account key type to RSA fixes the test:
this is a problem for us, as this test is part of test suite, and it fails with 1.21-rc.0 e2e tests
SIG Auth own their test cases (it's tagged in the test name), SIG Architecture own conformance. Testing owns the frameworks, CI, tooling, etc. EDIT: just clarifying and making sure the right people see it. I raised this to the conformance work group.
/assign /priority critical-urgent /milestone v1.21 because this is in the conformance suite, it must not restrict valid+supported cluster configurations
/reopen the image needs to be promoted and bumped in the e2e test
Reopened this issue. <detailsIn response to : /reopen the image needs to be promoted and bumped in the e2e test 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
promote image PR:
I believe with merged this can be closed as all the fixes were done and backported to 1.21
Thanks!
Change:
"io" "io/ioutil" "os" <ins> "regexp" </ins> "time" "github.com/Azure/azure-sdk-for-go/services/containerregistry/mgmt/2017-10-01/containerregistry"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: PR() fixed pull image error from a cross-subscription azure container registry by service principal, while for MSI, this issue is not fixed. Need to find a way how to fix this issue for MSI, related code is here: Here the difficulty is could not list all ACR since it's based on one subscriptionID: So if we could not get in a different subscription, how could we set the . What you expected to happen: How to reproduce it (as minimally and precisely as possible): error msg would be like following when pull a repository from an ACR in another subscription: Anything else we need to know?: Environment: Kubernetes version (use ): v.9 - v1.12 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
By further investigation, I think we should implement LazyProvider for azure acrProvider: Related code:
Update: It's hard to fix this since in the beginning we cannot list ACR in another subscription, will always list acr under current subscription, and without target loginServer address of ACR, we cannot get : And in func, we cannot get target repo, it's not passed on
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
-- is this still an issue? If not, let's it out.
it's still an issue, and currently it should be low priority, let's keep it
Rotten issues close after 30d of inactivity.

Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
/remove-lifecycle rotten /reopen
Reopened this issue. <detailsIn response to : /remove-lifecycle rotten /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
Change:
func (ss *scaleSet) newVmssVMCache() (*timedCache, error) { getter := func(key string) (interface{}, error) { // vmssVM name's format is 'scaleSetName_instanceID' <del> ssName, instanceID, err := ss.extractVmssVMName(key) </del> <ins> ssName, instanceID, err := extractVmssVMName(key) </ins> if err != nil { return nil, err }

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: When useInstanceMetadata is set to true for vmss nodes, their providerID is wrong. What you expected to happen: Their providerID should be in format azure:///subscriptions/&lt;subscription-id/resourceGroups/&lt;rg-name/providers/Microsoft.Compute/virtualMachineScaleSets/&lt;scaleset-name/virtualMachines/&lt;instance-id 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:
/sig azure
adding priority important-soon so that this issue can stay in 1.10. Please update if incorrect. /priority important-soon
Change:
type tokenSource interface { Token() (*azureToken, error) <ins> Refresh(*azureToken) (*azureToken, error) </ins> } type azureTokenSource struct {

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:
<ins> #!/bin/bash # Copyright 2015 Google Inc. 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. # This script will build a kubernetes.tar.gz and # kubernetes-test.tar.gz, unpack them in a separate directory and try # to run e2es from there, as if it were a binary distribution separate # from the git tree. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. # Build a release echo echo "... building release" echo "${KUBE_ROOT}/build/release.sh" echo echo "... ensuring git e2e cluster is down" echo go run "${KUBE_ROOT}/hack/e2e.go" -v -down TEST_DEPLOY="${KUBE_ROOT}/_output/test-deploy" echo echo "... deploying kubernetes.tar.gz / kubernetes-test.tar.gz to ${TEST_DEPLOY}" echo rm -rf ${TEST_DEPLOY} mkdir -p ${TEST_DEPLOY} tar -C "${TEST_DEPLOY}" -xzf _output/release-tars/kubernetes.tar.gz tar -C "${TEST_DEPLOY}" -xzf _output/release-tars/kubernetes-test.tar.gz # Nothing past here should touch the git checkout. unset KUBE_ROOT cd "${TEST_DEPLOY}/kubernetes" echo echo "... running e2e tests from ${TEST_DEPLOY}" echo go run ./hack/e2e.go -v -up -test -down "$*" || ( status=$? echo echo "... e2e tests failed from ${TEST_DEPLOY}! To reproduce this command:" echo "...   (cd '${TEST_DEPLOY}/kubernetes' && go run ./hack/e2e.go -v -up -test -down" "$*" ")" echo exit ${status}) exit 0 </ins>

Discussion:
The build has been failing for the last several days because of this:
Do you have an opinion on this one? checkin basically introduced a dep on a random ass file in contrib, making the default for basiclally every provider out there to pull this file and turn on DNS. I actually agree with it, but I'm more inclined to take the file and put it somewhere else that's not contrib anymore, since , by its name, says "we aren't officially supporting it", and shouldn't really be pulling from unsupported places. I looked at it briefly this morning, and the solutions to this broke down to: Move the file somewhere else: ( toplevel somewhere somewhere?) Ship some subset of Ship snapshots of
I'm going to move the file under
We do similar stuff for monitoring. But that stuff happens to be in which we do package. Ug.
should all of the contrib/dns dir move there, then? , Joe Beda wrote:
-- yes. I'm moving and to . At some point we can make those addons be more generic so that you can just drop something in there and there are helper scripts to launch it into a cluster. Testing it now.
Change:
} else { dialCommand = fmt.Sprintf("echo%%20%s", echoMessage) } <del> config.DialFromContainer(protocol, dialCommand, config.TestContainerPod.Status.PodIP, targetIP, testContainerHTTPPort, targetPort, maxTries, minTries, expectedResponse) </del> <ins> return config.DialFromContainer(protocol, dialCommand, config.TestContainerPod.Status.PodIP, targetIP, testContainerHTTPPort, targetPort, maxTries, minTries, expectedResponse) </ins> } // diagnoseMissingEndpoints prints debug information about the endpoints that

Discussion:
What would you like to be : Right now we poll one node at a time for intra-pod tests. We ultimately fail a test if any one node is unreachable. If we instead polled all nodes, multiple times, and collected the number of times a node was unreachable, this would tell us what % of nodes on the cluster were broken, rather then just telling us the first node that was broken. not break the testing contract (were still verifying intra-pod connectivity, just doing so in a way that gives us holistic cluster info) Why is this needed: I described why this would make triage alot easier, and in general make it easier to see why tests are failing, here ... i'll collect a little more data on this to justify the decision .... as this is a conformance test so the bar for modification is higher (even if the test itself isnt changing) then regular tests.
/sig network
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
Pod:         st.MakePod().Name("test-prefilter").UID("test-prefilter").Obj(), NumAllNodes: 1, Diagnosis: framework.Diagnosis{ <del> NodeToStatusMap:      framework.NodeToStatusMap{}, </del> <ins> NodeToStatusMap: framework.NodeToStatusMap{ "node1": framework.NewStatus(framework.Unschedulable, "node(s) didn't satisfy plugin FakePreFilter2"), }, </ins> UnschedulablePlugins: sets.Set[string]{}, PreFilterMsg:         "node(s) didn't satisfy plugin FakePreFilter2", },

Discussion:
When PreFilter returns UnschedulableAndUnresolvable, we don't need to run the preemption, but currently we run. This unexpected preemption could cause errors from the preemption by trying to read non-exist PreFilter data. As pointed out (), actually we didn't run the preemption in such cases in the past versions, but introduced this bug. /kind bug /kind regression /sig scheduling /triage accepted /priority important-soon
/assign
will fix this.
Change:
"UsageBytes":      bounded(10*e2evolume.Kb, 80*e2evolume.Mb), "WorkingSetBytes": bounded(10*e2evolume.Kb, 80*e2evolume.Mb), "RSSBytes":        bounded(1*e2evolume.Kb, 80*e2evolume.Mb), <del> "PageFaults":      bounded(0, 1000000), "MajorPageFaults": bounded(0, 10), </del> <ins> "PageFaults":      bounded(0, expectedPageFaultsUpperBound), "MajorPageFaults": bounded(0, expectedMajorPageFaultsUpperBound), </ins> }), "VolumeStats": gstruct.MatchAllElements(summaryObjectID, gstruct.Elements{ "test-empty-dir": gstruct.MatchAllFields(gstruct.Fields{

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --- ci-crio-cgroupv1-node-e2e-conformance many Many tests failing, they seem to be timing out. Example: Flakiness began late on 07/21 with this failure run: Note that cri-o jobs do not pin version of cri-o or Fedora CoreOS so it is possible the underlying components got bumped. /sig node
/cc
/milestone v1.22
I will take this /assign
/triage accepted
/remove-kind flake /kind failing-test as stats/summary test is now continuously failing
it is hard to tell because the tests were very flaky before, but I am suspicious of for causing the perma-failures. I have opened to test, where we can compare the difference in failures. It's possible this is just due to some crio configuration not being happy with the metrics server bump
/milestone v1.23
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /remove-kind failing-test /kind flake back to flaking:
it looks like the major page fault value is a bit off. I've opened to fix
Change:
} cfg[url] = *cred } <ins> // Handle the custom cloud case // In clouds where ACR is not yet deployed, the string will be empty if a.environment != nil && strings.Contains(a.environment.ContainerRegistryDNSSuffix, ".azurecr.") { customAcrSuffix := "*" + a.environment.ContainerRegistryDNSSuffix hasBeenAdded := false for _, url := range containerRegistryUrls { if strings.EqualFold(url, customAcrSuffix) { hasBeenAdded = true break } } if !hasBeenAdded { cred := &credentialprovider.DockerConfigEntry{ Username: a.config.AADClientID, Password: a.config.AADClientSecret, Email:    dummyRegistryEmail, } cfg[customAcrSuffix] = *cred } } </ins> } // add ACR anonymous repo support: use empty username and password for anonymous access

Discussion:
What happened: An aks-engine cluster with a user assigned managed service cluster identity fails to authenticate to azure container registries in private clouds when the proper (acrpull) azure role assignments are in place and when there are no image pull secrets. What you expected to happen: The cluster should be able to authenticate and pull from an ACR hosted in the same azure cloud without needing additional pull secrets when the cluster identity has the proper acrpull azure role assignment, no matter which azure cloud it is operating in. How to reproduce it (as minimally and precisely as possible): Assume you have a private azure cloud where every url ends with "". That would mean the ACR suffix would be . Let's pretend you have an ACR at and you try to deploy a pod in your cluster referencing the image . This will fail to pull when you have no image pull secrets. Anything else we need to know?: The problem stems from the following lines where expected ACR suffix domains are hardcoded: Environment: Kubernetes version (use ): 1.16.9 Cloud provider or hardware configuration: Azure private OS: ubuntu 16.0.4 Network plugin and version: Azure CNI
/sig provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig provider-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 /sig cloud-provider
It looks like we may be able to obtain the acr suffix from the azure environment:
there is a security issue here: if we support self defined ACR domain, e.g. , then service principal secret could be sent to that remote server. The reason why we use hardcoded domains is that we could always make sure the following 4 domains are owned by Azure:
Change:
"//test/e2e/framework/service:go_default_library", "//test/e2e/framework/skipper:go_default_library", "//test/e2e/framework/ssh:go_default_library", <del> "//test/e2e/network/netpol:go_default_library", </del> "//test/e2e/network/scale:go_default_library", "//test/e2e/storage/utils:go_default_library", "//test/utils:go_default_library",

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Remove the folder in favor of . Why is this needed: With the refactoring from the Netpol validation , the tests from folder are deprecated and duplicated at this point. Action items: tests tests
/area testing /sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /area testing /sig network 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
thank you ... !
/triage accepted