jiebi/CodeConvo huggingface dataset:
Code change:
dockernat "github.com/docker/go-connections/nat" "github.com/golang/glog" <ins> utilerrors "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/kubernetes/pkg/credentialprovider" runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime" <ins> "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" </ins> "k8s.io/kubernetes/pkg/kubelet/types" "k8s.io/kubernetes/pkg/security/apparmor" <del> "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" </del> <ins> "k8s.io/kubernetes/pkg/util/parsers" </ins> ) const (

Related discussion:
text: <!-- 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: We have a private registry configured (where all images including the sandbox one), are hosted. The registry credentials are being pulled by one of k8s credentials providers () With Kubernetes 1.7 sandbox image failed to be pulled with the following error message: Looks like with this only creds from docker config are being evaluated on the sandbox image pull What you expected to happen: Sandbox image pull should be attempted using credentials returned by not just the basic docker credential provider, but other credentials providers registered in the system. How to reproduce it (as minimally and precisely as possible): 1) Register private repo credentials with one of the k8s credential providers (we've tried with rancher). Configure the to use the image from the the private repo. 2) Make sure you are not logged in to this private repo on the kubelet host 3) Try to create a pod. Sandbox image pull will fail with an error mentioned above. Anything else we need to know?: Non-sandbox images from the same private repo were able to download correctly using private repo credentials provider. Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node Just tested the same use case against k8s 1.5.x, it worked fine there and sandbox image was pulled using the credentials passed by the credential provider, not from docker config file. So it might have regressed in 1.7.x (haven't tested it on 1.6, so can't tell for sure)
Confirmed a bug introduced in dockershim. Will file a PR to fix this.
Code change:
dockernat "github.com/docker/go-connections/nat" "github.com/golang/glog" <ins> utilerrors "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/kubernetes/pkg/credentialprovider" runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime" <ins> "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" </ins> "k8s.io/kubernetes/pkg/kubelet/types" "k8s.io/kubernetes/pkg/security/apparmor" <del> "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" </del> <ins> "k8s.io/kubernetes/pkg/util/parsers" </ins> ) const (

Related discussion:
text: Could you also verify whether fixed your problem?
tested against your commits cherry-picked on top of 1.8 beta, the fix seems to work
thanks.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Code change:
MemoryManager:                                  {Default: false, PreRelease: featuregate.Alpha}, CPUCFSQuotaPeriod:                              {Default: false, PreRelease: featuregate.Alpha}, TopologyManager:                                {Default: true, PreRelease: featuregate.Beta}, <del> ServiceNodeExclusion:                           {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.23 NodeDisruptionExclusion:                        {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.22 </del> StorageObjectInUseProtection:                   {Default: true, PreRelease: featuregate.GA}, SupportPodPidsLimit:                            {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.23 SupportNodePidsLimit:                           {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.23

Related discussion:
text: What is missing? Based on SIG call it's probably "tests" but I am not sure. Could use some investigation and followup - how do we get it to GA? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
This one seems not a good first one, I'll take this to myself and start bothering people in Slack to check what's missing, mostly as I've seen this is also related to cloud providers :)
I think this one originally. According to the KEP in This should have went GA in v.19 and be removed in v1.20. Given it's still marked beta, at the very least we should mark it GA in v1.20 and remove it in v1.21. anything I'm missing here?
yeap. Honest question, changing a Feature Gate to GA process is only changing the related line in and also putting a comment that this goes to GA? If so, probably this one can also be a good first issue and we can open a future issue for the removal in v1.21 once v1.20 ships. I think this will also need to be changed in the in v1.21 right? If is ok with that, I would like then to mark this as a good first issue to turn the feature GA in v1.20 :)
Well, taking a look into how secure is to move to GA: In the KEP there are some considerations about removing the IsMasterNode function, which seems to be already dealt in commit E2E tests needs to be also checked about usage of IsMasterNode(), which I could not find anymore and also seems to be removed from the same commit above. About the same Kep, it's directly related to other Feature Gate: ` So what I think that needs to be done: Promote LegacyNodeRoleBehavior to GA and Default it to false as proposed in the Kep -I'll open another issue just for this According to the LegacyNodeRoleBehavior should be removed in v1.19 but according to the Kep in v1.21, so let's stick with v1.21? ServiceNodeExclusion - Should be moved to GA, already defaulted to true. This issue is going to deal ONLY with this.
Code change:
MemoryManager:                                  {Default: false, PreRelease: featuregate.Alpha}, CPUCFSQuotaPeriod:                              {Default: false, PreRelease: featuregate.Alpha}, TopologyManager:                                {Default: true, PreRelease: featuregate.Beta}, <del> ServiceNodeExclusion:                           {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.23 NodeDisruptionExclusion:                        {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.22 </del> StorageObjectInUseProtection:                   {Default: true, PreRelease: featuregate.GA}, SupportPodPidsLimit:                            {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.23 SupportNodePidsLimit:                           {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.23

Related discussion:
text: NodeDisruptionExclusion - Should be moved to GA, already defaulted to true. I'll open another issue for this I'm afraid of this having some sort of direct impact in cloud providers, do you want me to take this to the sig-cloudproviders meet? Otherwise can we move the above Feature Gates to GA, and schedule their removal for v1.21, wdyt?
Per deprecation lifecycle it seems that a feature needs 6 months or 2 releases (the longer one) in Beta before going to GA. So this actually seems to be the missing part before moving to GA. As the 3 FeatureGates are directed related, probably this issue should be: Move all of them to GA in v1.21 Default LegacyNodeRoleBehavior to false Sounds a good approach? I can keep this opened until we reach v1.21
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
/retitle Move Feature gate ServiceNodeExclusion to GA and LockToDefault
/triage accepted as this FG is scheduled to be moved to GA in v1.21, do you want to tackle on this?
fixed in /close
Closing this issue. <detailsIn response to : fixed in /close </details
Code change:
node.Status.NodeInfo.BootID = info.BootID } <del> rootfs, err := kl.GetCachedRootFsInfo() if err != nil { node.Status.Capacity[v1.ResourceStorage] = resource.MustParse("0Gi") } else { for rName, rCap := range cadvisor.StorageScratchCapacityFromFsInfo(rootfs) { node.Status.Capacity[rName] = rCap } } if hasDedicatedImageFs, _ := kl.HasDedicatedImageFs(); hasDedicatedImageFs { imagesfs, err := kl.ImagesFsInfo() </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(features.LocalStorageCapacityIsolation) { rootfs, err := kl.GetCachedRootFsInfo() </ins> if err != nil { <del> node.Status.Capacity[v1.ResourceStorageOverlay] = resource.MustParse("0Gi") </del> <ins> node.Status.Capacity[v1.ResourceStorageScratch] = resource.MustParse("0Gi") </ins> } else { <del> for rName, rCap := range cadvisor.StorageOverlayCapacityFromFsInfo(imagesfs) { </del> <ins> for rName, rCap := range cadvisor.StorageScratchCapacityFromFsInfo(rootfs) { </ins> node.Status.Capacity[rName] = rCap } } <ins> if hasDedicatedImageFs, _ := kl.HasDedicatedImageFs(); hasDedicatedImageFs { imagesfs, err := kl.ImagesFsInfo() if err != nil { node.Status.Capacity[v1.ResourceStorageOverlay] = resource.MustParse("0Gi") } else { for rName, rCap := range cadvisor.StorageOverlayCapacityFromFsInfo(imagesfs) { node.Status.Capacity[rName] = rCap } } } </ins> } // Set Allocatable.

Related discussion:
text: Local storage is not expected to be available as a scheduling resource in v1.7. Kubelet is incorrectly exposing a resource named . This is incorrect because the feature is alpha and so it requires opt-in via feature flags and, the resource names are invalid. The expected resource names are listed - and . cc This is v1.7 blocker because we cannot expose a new resource in the API and rename it in a subsequent release.
CC I'll find someone on the storage team to address this.
/assign
GitHub didn't allow me to assign the following users: verult. 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
Code change:
docker_pull( name = "debian-hyperkube-base-amd64", <del> digest = "sha256:fc1b461367730660ac5a40c1eb2d1b23221829acf8a892981c12361383b3742b", </del> <ins> digest = "sha256:d83594ecd85345144584523e7fa5388467edf5d2dfa30d0a1bcbf184cddf4a7b", </ins> registry = "k8s.gcr.io", repository = "debian-hyperkube-base-amd64", <del> tag = "0.8",  # ignored, but kept here for documentation </del> <ins> tag = "0.9",  # ignored, but kept here for documentation </ins> ) docker_pull(

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Upgraded to Kuberenetes 1.9 and now IPVS mode in kube-proxy stopped working due to What you expected to happen: Normal startup as it's been working flawless in 1.8.5 How to reproduce it (as minimally and precisely as possible): Use kube-proxy with IPVS service mode on 1.9.0 hyperkube image from GCR Anything else we need to know?: If i exec into the running kube-proxy pod and do then restart the container kube-proxy starts in ipvs mode fine Environment: Kubernetes version (use ):Cloud provider or hardware configuration: On-prem OS (e.g. from /etc/os-release): CoreOS Container Linux by CoreOS stable (1576.4.0) Kernel (e.g. ): 4.13.16-coreos-r2 Install tools: Own Others:
/sig network
According to jell in #sig-network these images are to be considered experimental and not used in production and might be missing binarys? , could someone shed some light on this
To be more precise: hyperkube binary can hide some options of underlying applications (e.g. of fix for that: ) and whole docker image of hyperkube - as this issue shows, can miss some useful binaries. That's why I named it as a tool to do experiments, while for real deployments probably a better choice would be to use underlying applications directly using own docker image, carefully tuned.
Is this connected to and by chance the changes hasn't propagated down to the public images yet?
image is based on (which is based on ) (and ) has a separate image based on But as has included support, IMO also should be extended by command, after this line.
Seems this issue already got fixed? Can close now?
Where do you get the info it's fixed, all my kube-proxy instances is still failbacking to iptables due to missing ipset that was present in 1.8.5
It was fixed by merging So, as it's in master, the fix will land in next release.
Ok, so it's fixed in the next version. I'll just switch away from Hyperkube then. Thanks
FYI: I've rebuilt hyperkube image for CoreOS with installed. Just for testing purposes. Everything works for me with it.
Code change:
docker_pull( name = "debian-hyperkube-base-amd64", <del> digest = "sha256:fc1b461367730660ac5a40c1eb2d1b23221829acf8a892981c12361383b3742b", </del> <ins> digest = "sha256:d83594ecd85345144584523e7fa5388467edf5d2dfa30d0a1bcbf184cddf4a7b", </ins> registry = "k8s.gcr.io", repository = "debian-hyperkube-base-amd64", <del> tag = "0.8",  # ignored, but kept here for documentation </del> <ins> tag = "0.9",  # ignored, but kept here for documentation </ins> ) docker_pull(

Related discussion:
text: Waiting for the next release. :relaxed:
So does have ipset. So please use that. However does not have ipset (see below). The commit above was merged well before we shipped v1.9.0, But hyperkube image does not use the debian-iptables, it uses debian-hyperkube-base image if you see Anyone want to log a PR for hyperkube image to have ipset?
Can we re-open this, only fixes this on debian, not amd64!
/reopen
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /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
will need to reopen, then :)
Code change:
// on port 443 // If the Service is nil, that means the handling for the API groupversion is handled locally on this server. // The call will simply delegate to the normal handler chain to be fulfilled. <ins> // +optional </ins> optional ServiceReference service = 1; // Group is the API group name this server hosts

Related discussion:
text: /sig api-machinery /kind bug /cc this makes any updates on a "Local" apiservice failing by kubectl (unless you disable the client-side validation). a quick repro: (edit whatever a local apiservice) a label "foo: bar" will fail on the schema validation # "" was not valid: # * : Invalid value: "The edited file failed validation": ValidationError(): missing required field "service" in client-side v1.15.0 server-side v1.15.2 referencing the published openapi v2 for apiservice#spec below:
/label help-wanted
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label help-wanted 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
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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 can on this if no one else is currently working on it.
sure, feel free to tag me to request reviewing..
awesome, I will /assign
are you still working on this one?
Code change:
} } <ins> func SkipIfCSIMigrationEnabled() { if utilfeature.DefaultFeatureGate.Enabled(csiMigration) { skipInternalf(1, "Only supported when %v feature is disabled", csiMigration) } } </ins> // SkipIfMissingResource skips if the gvr resource is missing. func SkipIfMissingResource(dynamicClient dynamic.Interface, gvr schema.GroupVersionResource, namespace string) { resourceClient := dynamicClient.Resource(gvr).Namespace(namespace)

Related discussion:
text: Right now, we have e2e test for that executes only CSI mock driver with artificial limit of 2 volumes per node. We need a test with real CSI driver(s). Proposal: Allow individual test storage drivers to specify if they support CSI limits. Add a test that picks a random node and creates as many pods with a PV that the volume can handle (128 on GCE!). Check that the node can't handle any other volume. Make this test part of . Add similar test(s) for in-tree volume plugins. Make sure the tests work with in-tree volume plugins migrated to CSI.
/sig storage
/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
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
This sounds important /remove-lifecycle rotten /lifecycle frozen
/priority backlog
To add to this I believe we should test that an in-tree plugin and its "replacement" CSI Driver share the same attach limits (both max and current usage)
/cc
I see this test has been here: But I want to add a more basic/faster version of the test that simply checks if a driver has then has been set in CSINode, similar to wdyt, would it be useful?
This is a really old issue :-D. I think the required test has been implemented, however, we do not run it in CI, because it takes too much time to provision 128 PDs that a GCP node can handle. /unassign That sounds useful!
/assign opened to close this for good :)
Code change:
resource *storageframework.VolumeResource } var ( <ins> dInfo   = driver.GetDriverInfo() </ins> eDriver storageframework.EphemeralTestDriver l       local )

Related discussion:
text: Let's assume this scenario: linux node, zone A, tainted windows node, zone B, untainted In a multizone cluster, while trying to run the generic ephemeral volume tests in Windows nodes it might be possible that a volume that's supposed to be for a Windows node is created in the zone for the Linux node instead. The generic ephemeral storage tests use : [Testpattern: Generic Ephemeral-volume (default fs) (late-binding)] ephemeral [Testpattern: Generic Ephemeral-volume (default fs) (immediate)] ephemeral [Testpattern: Generic Ephemeral-volume (block volmode) (late-binding)] ephemeral This issue is happening because we're using the immediate testpattern which is not compatible with a multizone cluster. /kind failing-test /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
I think "immediate" binding in general won't work in a multi-zone cluster. What do we do for other tests that explicitly specify immediate mode?
I think nothing special in any of the tests besides , it's just another test pattern that's tested
Do you see failures of other "immediate" mode tests? I'm wondering if there is some logic to detect and automatically skip those tests
that was the only failure, after I the skip I didn't see any other testpatterns that failed with "immediate" mode in other test groups.
I checked tests that passed with VolumeBindingMode immediate which are found in the topology tests, the topology tests detect if the testdriver has the field set to work and modify the clone of the StorageClass adding the field to it, I'm going to do the same for the Generic Ephemeral Volume tests.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
Code change:
resource *storageframework.VolumeResource } var ( <ins> dInfo   = driver.GetDriverInfo() </ins> eDriver storageframework.EphemeralTestDriver l       local )

Related discussion:
text: 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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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
Code change:
return false, err } <del> type ContainerState uint32 </del> <ins> type ContainerState int </ins> const ( <del> ContainerStateWaiting ContainerState = 1 << iota </del> <ins> ContainerStateWaiting ContainerState = iota </ins> ContainerStateRunning ContainerStateTerminated ContainerStateUnknown

Related discussion:
text: Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc