jiebi/CodeConvo huggingface dataset:
Change:
return false } <ins> // Since containers and initContainers cannot currently be added, removed, or updated, it is unnecessary // to mutate and validate limitrange on pod updates. Trying to mutate containers or initContainers on a pod // update request will always fail pod validation because those fields are immutable once the object is created. if a.GetKind().GroupKind() == api.Kind("Pod") && a.GetOperation() == admission.Update { return false } </ins> return a.GetKind().GroupKind() == api.Kind("Pod") || a.GetKind().GroupKind() == api.Kind("PersistentVolumeClaim") }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pod stuck in terminating state. What you expected to happen: Pod successfully cleaned up. How to reproduce it (as minimally and precisely as possible): up a LimitRange. (Say "limits: defaultRequest: cpu: 100m type: Container") a mutating webhook on pod which creates an additional container on the pod (Eg. ) without the limit range. a Pod with foreground deletion finalizer. that you have a Pod with 2 containers. The 1 you created which now has a limit and the istio container which does not. to delete the Pod. garbage collector tries to update the pod to remove the finalizer, however this triggers the limit range admission control to add the limit to the istio container. This then causes the API server to get the error "invalid: spec: Forbidden: pod updates may not change fields other than , , or " the pod is now stuck in terminating. Anything else we need to know?: Environment: Kubernetes version (use ): 1.9.6 /sig api-machinery
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 PR open
Change:
return "", fmt.Errorf("no plugin name provided") } <ins> if strings.ContainsRune(plugin, os.PathSeparator) { return "", fmt.Errorf("invalid plugin name: %s", plugin) } </ins> if len(paths) == 0 { return "", fmt.Errorf("no paths provided") }

Discussion:
is identified with with severity rating as high. This is found using snyk scan while running against k/k master We're not using directly however, it gets tagged for vulnerability scans as we use . The fix is already present in and we can bump the dep. Bump dep to which has the mentioned CVE fix. and check Kubernetes version (use ): n/a Cloud provider or hardware configuration: any OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a /sig architecture /area code-organization for the dependency
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
Change:
{MountPath: "/dir/nested", Name: "vol2"}, {MountPath: "/ignore2", Name: "vol5"}, {MountPath: "/dir", Name: "vol1"}, <ins> {MountPath: "/dir/nested-vol", Name: "vol6"}, {MountPath: "/dir/nested.vol", Name: "vol7"}, {MountPath: "/dir/nested2/double", Name: "vol8"}, </ins> {MountPath: "/dir/nested2", Name: "vol3"}, }, },

Discussion:
to have all the mount points sorted and grouped. For example, the following strings are sorted in this exact order: With the current implementation, test, we would get: This is worse on Windows, where paths usually have backslashes instead (with no test changes): [1] ` should group mount points correctly. /kind bug /sig windows Kubernetes master, Kubernetes v1.25 and older. N/A N/A <details</details<details</details<details</details
/triage accepted /milestone v1.26
Change:
echo "+++ Copying release artifacts to ${gcs_destination}" # First delete all objects at the destination <del> gsutil -q rm -f -R "${gcs_destination}" >/dev/null 2>&1 || true </del> <ins> if gsutil ls "${gcs_destination}" >/dev/null 2>&1; then echo "!!! ${gcs_destination} not empty." read -p "Delete everything under ${gcs_destination}? [y/n] " -r || { echo "EOF on prompt.  Skipping upload" return } [[ $REPLY =~ ^[yY]$ ]] || { echo "Skipping upload" return } gsutil -m rm -f -R "${gcs_destination}" fi </ins> # Now upload everything in release directory gsutil -m "${gcs_options[@]+${gcs_options[@]}}" cp -r "${RELEASE_DIR}"/* "${gcs_destination}" # Having the "template" scripts from the GCE cluster deploy hosted with the # release is useful for GKE.  Copy everything from that directory up also. <del> gsutil -m "${gcs_options[@]+${gcs_options[@]}}" cp "${KUBE_ROOT}/cluster/gce/templates/*.sh" "${gcs_destination}extra/gce-templates/" </del> <ins> gsutil -m "${gcs_options[@]+${gcs_options[@]}}" cp  "${RELEASE_STAGE}/full/kubernetes/cluster/gce/templates/*.sh"  "${gcs_destination}extra/gce-templates/" # Upload the "naked" binaries to GCS.  This is useful for install scripts that # download the binaries directly and don't need tars. local platform platforms platforms=($(cd "${RELEASE_STAGE}/client" ; echo *)) for platform in "${platforms[@]}"; do local src="${RELEASE_STAGE}/client/${platform}/kubernetes/client/bin/*" local dst="${gcs_destination}bin/${platform/-//}/" # We assume here the "server package" is a superset of the "client package" if [[ -d "${RELEASE_STAGE}/server/${platform}" ]]; then src="${RELEASE_STAGE}/server/${platform}/kubernetes/server/bin/*" fi gsutil -m "${gcs_options[@]+${gcs_options[@]}}" cp  "$src" "$dst" done </ins> # TODO(jbeda): Generate an HTML page with links for this release so it is easy # to see it.  For extra credit, generate a dynamic page that builds up the

Discussion:
Sometimes it is nice to have non-tar'd binaries for releases. We should upload those along with the our packaged tarballs. This will help fix
Change:
# # -M installs the master set +x <del> wget -q -O - https://bootstrap.saltstack.com | sh -s -- -M -X </del> <ins> curl -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s -- -M -X </ins> set -x <del> echo $MASTER_HTPASSWD > /srv/salt/nginx/htpasswd </del>

Discussion:
When wgetting to this address during the installation process, this just fails silently. Turns out the issue is that if you take a raw and curl that address you get a TLS error. I've fixed it by changing to , but obviously that's more risky.
Related (filed after an email exchange around wget) I don't have easy access to the vSphere so I can't verify how it relates to my debian install.
Yes, that is exactly the error I was experiencing.
Does curl work? Or is it busted too?
Curl is not installed on the image by default. I'm building a new image based on Debian 7.7 where I pull in curl by default, so we can switch to using that everywhere (instead of an awkward mix of wget and curl).
Thanks for reporting this I hadn't seen this yet. I uploaded a new VMDK that includes curl and updated the deployment scripts to use curl. I verified that deployment works again for me.
I can confirm that this works now with latest build from master on ESX. Probably still won't work with v0.4.3 (even w new image) since the scripts still used wget back then.
We are probably going to fork for v0.5 soon. But I can backport if this trips folks up. sent from tiny keyboard On Nov 12, 2014 9:09 AM, "Ben Smith" wrote:
Change:
var newHnsEndpoint *hcsshim.HNSEndpoint hnsNetworkName := proxier.network.name var err error <ins> // targetPort is zero if it is specified as a name in port.TargetPort, so the real port should be got from endpoints. // Note that hcsshim.AddLoadBalancer() doesn't support endpoints with different ports, so only port from first endpoint is used. // TODO(feiskyer): add support of different endpoint ports after hcsshim.AddLoadBalancer() add that. if svcInfo.targetPort == 0 { svcInfo.targetPort = int(ep.port) } </ins> if len(ep.hnsID) > 0 { newHnsEndpoint, err = hcsshim.GetHNSEndpointByID(ep.hnsID) }

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?: What happened: Tried to create a service using targetPort as a string referencing the name of the pod port. Traffic was not routed to pod. What you expected to happen: Service to route traffic to pod How to reproduce it (as minimally and precisely as possible): See line targetPort Anything else we need to know?: Link that describes how this feature is supposed to work Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-04-27T09:22:21Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"windows/amd64"} Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-09-27T16:55:41Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): WindowsBuildLabEx : .1000.amd64fre.rs_prerelease.-1413 Kernel (e.g. ): Install tools: Others:
/sig windows
/assign
Change:
up{8}, down{oldReady: 4, newReady: 8, to: 2}, up{10}, <del> down{oldReady: 10, newReady: 2, to: 0}, </del> <ins> down{oldReady: 1, newReady: 10, to: 0}, </ins> }, output: `Created foo-v2 Scaling up foo-v2 from 5 to 10, scaling down foo-v1 from 6 to 0 (keep 10 pods available, don't exceed 12 pods)

Discussion:
I intentionally cause the rolling update to fail by specifying a non-existent image in the spec, so that it times out. rollback then fails with a timeout as well, despite the original replication controller having 1 healthy replica: This is on 1.1.2. I expect the rollback to succeed as the original rc (copper) has 1 healthy replica still.
With 2 replicas the rollback seems to work as expected.
I found the bug inside of the function of . It erroneously assumes reducing replicas on scale down will always drop the minimum available, when this isn't the case if you are rolling back from a failed deployment (where the scale down will be on the NotReady/failed pods). It needs to consider not ready replicas as well in each RC when deciding if it can scale down. This test case illustrates the problem:
Change:
os.MkdirAll(dir, 0750) var options []string <ins> options = append(options, "allow-usermapping-in-volumename") </ins> if mounter.readOnly { options = append(options, "ro") }

Discussion:
What happened: Containers cannot access Quobyte volumes provided via a Quobyte mount run by the Quobyte plugins mount command due to permission denied issues. Even if user mappings are provided these are ignored by the Quobyte client due to a missing mount flag. What you expected to happen: Access should work with the provided user mapping. How to reproduce it (as minimally and precisely as possible): Quobyte volumes without providing an externally managed plugin mount, thus allowing the Quobyte plugin to run the mount command. Quobyte based StorageClass, PVC and pod desc. the pod Anything else we need to know?: 'm preparing a pull request with a fix is to run an externally managed mount for the plugin, e.g. via a systemd unit or a k8s daemonset. Ensure that mount activates the allow-usermapping-in-volumename option. In this case the plugin uses the existing mount. Environment: not relevant. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /kind bug /sig storage
/assign
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Hello , I'm a bug triage shadow and I'd like to remind that code freeze is coming in 2 days (Friday, 8th March). :snowflake: Is it still planned for this issue to be fixed for 1.14?
I'm happy to merge this asap, ideas on how to bring this forward?
Change:
podSubnet: "" serviceSubnet: 10.96.0.1/12 nodeName: "" <ins> privilegedPods: false </ins> token: "" unifiedControlPlaneImage: "" `),

Discussion:
Dear All: I'm not sure if I'm right. When i use whith .I found controller-manager logs Someone can help me? Thanks a lot.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
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
Please give more information about your set up cc
Sorry for report later. My openstack didn't support metadata service,but support config-drive service. More info:
Thanks Based on this, I think it's an openstack cloudprovider problem more than a kubeadm problem...
Thank you for help me. I will change the label.
/area cloudprovider
/remove-kind support
Should be fixed with you can specify a search order for metadata and config drive /close
Specifying a search order doesn't really solve the problem, especially if the metadata api isn't available which is what ZhenyangZhao said . I'm getting the same issue and since the config drive is my only option at the moment.
Like for this to be /open
can you please provide logs/versions for your problem in your environment? Thanks, Dims
Let me know if you need anything else Kubernetes version: 1.8.4 Docker version: 17.09.0-ce Linux: CentOS 7.4 Looking at the docker container log for the api-server (I don't have problems with the controller-manager):
and share the following:
Hi! Thank you for filing this issue. We appreciate your interest in Kubernetes and kubeadm. In order to make the kubernetes/kubernetes issue tracker more usable, we're routing issues to different repositories with different focuses. I think this issue belongs in the kubeadm repository. Please move this issue to the in order for the kubeadm team to be able to track this efficiently. If you disagree with my assessment of moving this issue, please speak up and/or reopen the issue. Finally, please try to reproduce the bug with the latest Kubernetes version, it might as well already have been fixed :) Thank you and have a good day!
Change:
t.Error("Unexpected error creating custom resource but metadata validation rule") } }) <ins> t.Run("CRD creation MUST pass for an CRD with empty field", func(t *testing.T) { structuralWithValidators := crdWithSchema(t, "WithEmptyObject", structuralSchemaWithEmptyObject) _, err := fixtures.CreateNewV1CustomResourceDefinition(structuralWithValidators, apiExtensionClient, dynamicClient) if err != nil { t.Errorf("unexpected error creating CRD with empty field: %v", err) } }) </ins> t.Run("CR creation MUST fail if a x-kubernetes-validations rule exceeds the runtime cost limit", func(t *testing.T) { structuralWithValidators := crdWithSchema(t, "RuntimeCostLimit", structuralSchemaWithCostLimit) crd, err := fixtures.CreateNewV1CustomResourceDefinition(structuralWithValidators, apiExtensionClient, dynamicClient)

Discussion:
While migrating webhooks to CEL for one of the structs in our CRD api, I noticed that the empty object in CEL is interpreted wrongly. Empty map object seems to be interpreted correctly. In the example below, both map and object are sent empty () in json output. returns true json (captured on the client side) sent to the apiserver CRD schema No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
CEL only sees the JSON sent to the server, and is correctly evaluated as present. The issue is with the client sending the request populating a value in that field. How is the request being constructed? /remove-kind bug /kind support
/cc /triage accepted
Upon investigation, the problem lies there: We requires either or be set.
Thanks for raising this issue! I was debugging offline with and seems like CRD/CR validation didn't handle the situation of unsetting properties with field type specified . It is a corner case in CRD since we normally would ask for properties defined if the field type is (I could not think of use case which having properties unset). But it might ok to allow it through since it won't hurt from CRD perspective. We will fix in CEL values handling which treat this as empty map passed. /assign
GitHub didn't allow me to assign the following users: jiahui. Note that only with read permissions, 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 : Thanks for raising this issue! I was debugging offline with and seems like CRD/CR validation didn't handle the situation of unsetting properties with field type specified 'Object1object`(I could not think of use case which having properties unset). But it might ok to allow it through since it won't hurt from CRD perspective. We will fix in CEL values handling which treat this as empty map passed. /assign </details
also check if the CRD validation allows the or values, and if so, if the CEL code handles those properly as well
FYI: We do not allow in crd structured schema now:
Change:
<del> linux/amd64=fedora:26 linux/arm64=arm64v8/fedora:26 linux/ppc64le=ppc64le/fedora:26 </del> <ins> linux/amd64=fedora:33 linux/arm64=arm64v8/fedora:33 linux/ppc64le=ppc64le/fedora:33 </ins>

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 --When I run some e2e storage testcases locally, below testcases as an example, I consistently saw the below error message, ceph should be deployed successfully and testcase should pass. Run the testcases mentioned above. e.g. Kubernetes version (use ): ALL Cloud provider or hardware configuration: ARM64 OS (e.g: ): ubuntu18 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing /sig storage
/assign
is this happening in CI? please provide links to occurences?
Hey, Ben, I update the issue description a little bit, this won't be an issue on X86 which is currently the default arch CI is running, but tons of testcases will fail on ARM64 due to this issue. Eventually, we hope the k8s will have a ARM CI along with the more adoption of arch beside the X86, and thus, those e2e testcases should workable on ARM64 firstly. I will explain why it failed on ARM64 in the PR desc, pls help to review, thanks!
/triage accepted
Change:
local cmd for cmd in gcloud gsutil; do if ! which "${cmd}" >/dev/null; then <del> local resp </del> <ins> local resp="n" </ins> if [[ "${KUBE_PROMPT_FOR_UPDATE}" == "y" ]]; then echo "Can't find ${cmd} in PATH.  Do you wish to install the Google Cloud SDK? [Y/n]" read resp <del> else resp="y" </del> fi if [[ "${resp}" != "n" && "${resp}" != "N" ]]; then curl https://sdk.cloud.google.com | bash

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): all :smile: Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): all Kernel (e.g. ): all Install tools: Others: What happened: uses the cli a lot and does a (in the commonly used function ) before doing things like . updates can introduce breaking changes (for example in the recent 132.0.0 release it removed a bunch of flags). This has caused cross-the-board test failures like . But this is not limited to just tests. Any kubernetes GCE users who rely on the and commands could have been broken. What you expected to happen: Stop updating gcloud automatically. We could either warn user to have the required dependencies installed, or pin to specific versions of dependencies like gcloud. How to reproduce it (as minimally and precisely as possible): download 1.4.4 release tarball run and Anything else do we need to know:
cc
/cc
cc I think it's reasonable to remove gcloud update calls from scripts, as I believe gcloud is updated out of band by k8s continuous testing. The scripts will still need to work with latest, so maybe they should check for a minimum version.
Good idea.
Yeah, we definitely want to continue using latest in CI so that we know if things break, but I think it's reasonable to remove the update itself from the kubernetes cluster util scripts.
Change:
echo cat "${LICENSE_ROOT}/LICENSE" echo <del> echo "= LICENSE $(md5sum < "${LICENSE_ROOT}/LICENSE" | awk '{print $1}')" </del> <ins> echo "= LICENSE $(kube::util::md5 "${LICENSE_ROOT}/LICENSE")" </ins> echo "================================================================================" ) > ${TMP_LICENSE_FILE}

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: run on macOS, all md5 hashes will be stripped from the output and the script will not fail or warn. What you expected to happen: The script should work or detect this issue and fail. Currently it silently ignores not existing on the host. We have some warning logic, but solely based on bash version, if the user upgraded their bash installation but did not install md5sum we don't warn them. How to reproduce it (as minimally and precisely as possible): run the script 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 testing /priority important-longterm /assign
cc