jiebi/CodeConvo huggingface dataset:
Change:
import ( "errors" "fmt" <ins> "io/ioutil" </ins> "os" "path/filepath" "strings"

Discussion:
I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
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
/remove-lifecycle rotten
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
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
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/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 </details
Change:
docker_pull( name = "debian-hyperkube-base-amd64", <del> digest = "sha256:e45d35f9f967ef7d49496d1d2e6f9ad378a29012b0c90f78b5d59a254f3135e6", </del> <ins> digest = "sha256:f3a37c4d8700a5ff454d94a2bef7d165d287759cea737a621c20e4aa3891dbbb", </ins> registry = "gcr.io", repository = "google-containers/debian-hyperkube-base-amd64", <del> tag = "0.3",  # ignored, but kept here for documentation </del> <ins> tag = "0.4",  # ignored, but kept here for documentation </ins> ) docker_pull(

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: When I update the kubelet on a node from 1.7.x to 1.8.0, pods on that node stop being able to connect to services whose pods happen to be on the same node. I use the Kubenet network plugin. What you expected to happen: Pods should be able to connect to a service even if the services's pods are on the same node. How to reproduce it (as minimally and precisely as possible): a cluster the DNS addon another pod that runs on the same node as one of the DNS pods resolution starts to fail when the service redirects the requests to the pod that is on the same node. Anything else we need to know?: I have some packet captures that I can show. Kubelet: 1.7.5 DNS pod: 10.2.4.76 Origin pod: 10.2.4.64 Kubelet: 1.8.0 DNS pod: 10.2.1.254 Origin pod: 10.2.1.234 We can see that in the requests that fail the DNS IP is correctly DNATed to the DNS POD destination address but the response is not masqueraded, it still carries the DNS POD source (it should have an origin of 10.3.0.10). Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Azure StandardA4 OS (e.g. from /etc/os-release): "Container Linux by CoreOS 1465.8.0 (Ladybug)" Kernel (e.g. ): Linux node-1-vm 4.12.14-coreos SMP Wed Sep 20 22:20:05 UTC 2017 x8664 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools:
/sig node
The problem appears when transitioning from kubelet v1.8.0-alpha.2 to v1.8.0-alpha.3.
Well, I've found the problem. Starting from v1.8.0-alpha.3 the "modprobe" binary is not included in the image and so the br-netfilter kernel module is not loaded. I'm using the image, although through "kubelet-wrapper" from CoreOS. Where should this binary reside?

cc/ 1.8 release team.
There is a PR from so it doesn't get lost.
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
if ! which salt-call >/dev/null 2>&1; then # Install salt binaries curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s <ins> # Fedora >= 23 includes salt packages but the bootstrap is # creating configuration for a (non-existent) salt repo anyway. # Remove the invalid repo to prevent dnf from warning about it on # every update.  Assume this problem is specific to Fedora 23 and # will fixed by the time another version of Fedora lands. local fedora_version=$(grep 'VERSION_ID' /etc/os-release | sed 's+VERSION_ID=++') if [[ "${fedora_version}" = '23' ]]; then local repo_file='/etc/yum.repos.d/saltstack-salt-fedora-23.repo' if [[ -f "${repo_file}" ]]; then rm "${repo_file}" fi fi </ins> fi }

Discussion:
The latest vagrant always restarts nfs when nfs is used to share folders: This doesn't work with the default kube libvirt image: Attempting to restart nfs (systemctl restart nfs) on this image results in a failure from /usr/sbin/exportfs (invoked in the nfs unit file via ExecStartPre) of 'No file systems exported!' and this halts vagrant provisioning. To replicate (centos 7.1+vagrant 1.8.1+vagrant-libvirt 0.0.32):
This issue should be resolved by (already merged) and .
I marked as lgtm, so its basically blocked by the submit queue being fixed.
Change:
go_test( name = "go_default_test", <del> srcs = [ "compatibility_test.go", "defaults_test.go", ], </del> <ins> srcs = ["defaults_test.go"], </ins> embed = [":go_default_library"], deps = [ <del> "//pkg/apis/core/install:go_default_library", </del> "//pkg/scheduler/algorithm/predicates:go_default_library", <del> "//pkg/scheduler/api:go_default_library", "//pkg/scheduler/api/latest:go_default_library", "//pkg/scheduler/factory:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", <del> "//staging/src/k8s.io/client-go/informers:go_default_library", "//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//staging/src/k8s.io/client-go/rest:go_default_library", "//staging/src/k8s.io/client-go/util/testing:go_default_library", </del> ], )

Discussion:
PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: If you contributed in phase 1, please give others a chance before claiming this issue. You can also help out by reviewing the phase 2 PRs. The tests in ensure backwards compatibility with the types in . It makes more sense for these tests to live in that package. /sig scheduling /kind cleanup /help /good-first-issue
This request has been marked as suitable for new contributors. 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 : PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. The tests in ensure backwards compatibility with the types in . It makes more sense for these tests to live in that package. /kind cleanup /help /good-first-issue 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 would like to take it and thanks
Hi! I am contributer and I would like to take it.
while you're working on do you mind letting take a crack at this one?
OK, go head
, thanks!
/lifecycle active for
Thanks for taking care of this one! :smiley:
You are wellcome
Change:
} const ( <del> proxyModeUserspace              = "userspace" proxyModeIPTables               = "iptables" experimentalProxyModeAnnotation = options.ExperimentalProxyModeAnnotation betaProxyModeAnnotation         = "net.beta.kubernetes.io/proxy-mode" </del> <ins> proxyModeUserspace = "userspace" proxyModeIPTables  = "iptables" </ins> ) func checkKnownProxyMode(proxyMode string) bool {

Discussion:
This annotation dates back almost a year. This is a relatively easy project for someone to contribute.
I'll work on getting a pull request in tomorrow for this. Ive been looking at contributing and think this would be a great place to start
nevermind. Looks like a pull request already exists. Overlooked the mention due to being on mobile. Cheers
We'll file more :)
Change:
var zeroIPv4 = net.ParseIP("0.0.0.0") var localhostIPv4 = net.ParseIP("127.0.0.1") <del> var zeroIPv6 = net.ParseIP("::0") </del> <ins> var zeroIPv6 = net.ParseIP("::") </ins> var localhostIPv6 = net.ParseIP("::1") // Build a slice of iptables args that are common to from-container and from-host portal rules.

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Upon code inspection, found that kube-proxy server takes into consideration a bind address of 0.0.0.0 (IPv4), but does not check for a bind address of :: (all-zeros IPv6) when calculating its node IP. What you expected to happen: IPv6 address "::" should be taken into consideration when calculating node IP. How to reproduce it (as minimally and precisely as possible): Code inspection. Anything else we need to know?: Environment: Kubernetes version (use ): Latest master Cloud provider or hardware configuration**: VirtualBox cluster, Ubuntu 16.04.1 host, CentOS 7 guests OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux 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
/area ipv6 /sig network
Change:
) predicateResults := make(map[string]HostPredicate) <del> if ecache != nil { // getHashEquivalencePod will return immediately if no equivalence pod found equivalenceHash, eCacheAvailable = ecache.getHashEquivalencePod(pod) } </del> podsAdded := false // We run predicates twice in some cases. If the node has greater or equal priority // nominated pods, we run them when those pods are added to meta and nodeInfo.

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc
Change:
kubeNodePortLocalSetUDPComment = "Kubernetes nodeport UDP port with externalTrafficPolicy=local" kubeNodePortLocalSetUDP        = "KUBE-NODE-PORT-LOCAL-UDP" <del> kubeNodePortSetSCTPComment = "Kubernetes nodeport SCTP port for masquerade purpose" kubeNodePortSetSCTP        = "KUBE-NODE-PORT-SCTP" </del> <ins> // This ipset is no longer active but still used in previous versions. // DO NOT create an ipset using this name legacyKubeNodePortSetSCTPComment = "Kubernetes nodeport SCTP port for masquerade purpose" legacyKubeNodePortSetSCTP        = "KUBE-NODE-PORT-SCTP" </ins> <del> kubeNodePortLocalSetSCTPComment = "Kubernetes nodeport SCTP port with externalTrafficPolicy=local" kubeNodePortLocalSetSCTP        = "KUBE-NODE-PORT-LOCAL-SCTP" </del> <ins> // This ipset is no longer active but still used in previous versions. // DO NOT create an ipset using this name legacyKubeNodePortLocalSetSCTPComment = "Kubernetes nodeport SCTP port with externalTrafficPolicy=local" legacyKubeNodePortLocalSetSCTP        = "KUBE-NODE-PORT-LOCAL-SCTP" kubeNodePortSetSCTPComment = "Kubernetes nodeport SCTP port for masquerade purpose with type 'hash ip:port'" kubeNodePortSetSCTP        = "KUBE-NODE-PORT-SCTP-HASH" kubeNodePortLocalSetSCTPComment = "Kubernetes nodeport SCTP port with externalTrafficPolicy=local with type 'hash ip:port'" kubeNodePortLocalSetSCTP        = "KUBE-NODE-PORT-LOCAL-SCTP-HASH" </ins> ) // IPSetVersioner can query the current ipset version.

Discussion:
What happened: When updating to 1.15 in IPVS mode, kube-proxy fails to start What you expected to happen: kube-proxy updates ok How to reproduce it (as minimally and precisely as possible): Deploy kube-proxy <1.15 in ipvs mode and update to 1.15 Anything else we need to know?: Error message in kube-proxy: I think the reason is the change of ipset type (bitmap to hash) in PR The 2 sets that creates the problem are: - Removing the sets manually works but is not a great solution for in-place updates. I think we should fix this before the 1.15 release (not sure what the best approach is: delete the set if it exists with the wrong type? Use a different name to avoid the collision?) Environment: Kubernetes version (use ): 1.14 =1.15 Cloud provider or hardware configuration: AWS OS (e.g: ): ubuntu 18.04 Kernel (e.g. ): 4.4 /sig network /area ipvs /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by ‍
Great catch! Looks like a breaking change. One solution like you mentioned is to add support for replacing ipsets in if a similar ipset already exists? Thoughts
I noticed we pass in for ipsets but that only checks for identical ipset types. Maybe needs to be smarter and do a full diff
This could work as well
Opened a fix for it here , let's chat there :)
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
Change:
// If certain nodes were deleted after the last snapshot was taken, we should remove them from the snapshot. func (cache *schedulerCache) removeDeletedNodesFromSnapshot(snapshot *Snapshot) { <del> toDelete := len(snapshot.nodeInfoMap) - len(cache.nodes) </del> <ins> toDelete := len(snapshot.nodeInfoMap) - cache.nodeTree.numNodes </ins> for name := range snapshot.nodeInfoMap { if toDelete <= 0 { break } <del> if _, ok := cache.nodes[name]; !ok { </del> <ins> if n, ok := cache.nodes[name]; !ok || n.info.Node() == nil { </ins> delete(snapshot.nodeInfoMap, name) toDelete-- }

Discussion:
/sig scheduling What happened: reverted an old behavior to ensure Pod information is not lost when Nodes are recreated without its Pods getting recreated. A ghost Pod is kep in The problem is that we rely in this map for determining deleted Nodes when updating the snapshot in . The good thing is that the nodeinfo's are cloned into the snapshot, so we shouldn't have nil pointer accesses. But we might lose a few cycles trying to schedule on nodes that are deleted How to reproduce it (as minimally and precisely as possible): a node with a few pods. node without deleting pods. Result: The snapshot still has the node. Environment: Kubernetes version (use ): 1.18+
/assign
It actually produces the error: which would cause failed scheduling cycles (the map is not recreated, only the lists).
Change:
return metrics.NewKubeRegistry() } <del> func AssertVectorCount(t *testing.T, name string, labelFilter map[string]string, wantCount int) { </del> <ins> func AssertVectorCount(t TB, name string, labelFilter map[string]string, wantCount int) { </ins> metrics, err := legacyregistry.DefaultGatherer.Gather() if err != nil { t.Fatalf("Failed to gather metrics: %s", err)

Discussion:
We have many "test only" packages through out the project, containing fixtures, helpers, utilities, etc... These test libraries are not intended for use in production binaries. They often lack rigorous review and sufficient testing for use in production binaries. We should make sure they don't accidentally get pulled in. Strawman proposal, test only packages must import "testing". Blank import is sufficient: Then write a presubmit that fails if we find symbol in the release binary. This approach is trivial and fairly effective although a more sophisticated approach could print a dep chain.
/assign
I hope I will be able to contribute once this gets marked as .
/triage accepted
I think that will be enough a new script or a check in the building scripts /cc since he has experience from the providerless building effort
I got what we want to achieve here but I'm little confused about: If I execute: after adding the import then only it is giving - what do we want to achieve by executing this command exactly? I got what it is doing. I've opened a thread in slack as well:
Hello! Is there anyone working on this issue at the moment? If not and the issue it's still relevant, I would like to work on it if possible. Thank you.
I opened a PR in the meantime, if it's not needed anymore, I can close it.
Change:
t.Errorf("unexpected non-error") } } <ins> func TestNoSelectorUnknowResourceType(t *testing.T) { b := newDefaultBuilder(). NamespaceParam("test"). ResourceTypeOrNameArgs(false, "unknown") err := b.Do().Err() if err != nil { if !strings.Contains(err.Error(), "server doesn't have a resource type "unknown"") { t.Fatalf("unexpected error: %v", err) } } } </ins> func TestSingleResourceType(t *testing.T) { b := newDefaultBuilder(). LabelSelectorParam("a=b").

Discussion:
Hello! I got this error: or:
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Do I need to use ?
use instead
Change:
// Can't get the network tier, just return an error. return "", err } <ins> // containsCIDR returns true if outer contains inner. func containsCIDR(outer, inner *net.IPNet) bool { return outer.Contains(firstIPInRange(inner)) && outer.Contains(lastIPInRange(inner)) } // firstIPInRange returns the first IP in a given IP range. func firstIPInRange(ipNet *net.IPNet) net.IP { return ipNet.IP.Mask(ipNet.Mask) } // lastIPInRange returns the last IP in a given IP range. func lastIPInRange(cidr *net.IPNet) net.IP { ip := append([]byte{}, cidr.IP...) for i, b := range cidr.Mask { ip[i] |= ^b } return ip } // subnetsInCIDR takes a list of subnets for a single region and // returns subnets which exists in the specified CIDR range. func subnetsInCIDR(subnets []*compute.Subnetwork, cidr *net.IPNet) ([]*compute.Subnetwork, error) { var res []*compute.Subnetwork for _, subnet := range subnets { _, subnetRange, err := net.ParseCIDR(subnet.IpCidrRange) if err != nil { return nil, fmt.Errorf("unable to parse CIDR %q for subnet %q: %v", subnet.IpCidrRange, subnet.Name, err) } if containsCIDR(cidr, subnetRange) { res = append(res, subnet) } } return res, nil } type netType string const ( netTypeLegacy netType = "LEGACY" netTypeAuto   netType = "AUTO" netTypeCustom netType = "CUSTOM" ) func typeOfNetwork(network *compute.Network) netType { if network.IPv4Range != "" { return netTypeLegacy } if network.AutoCreateSubnetworks { return netTypeAuto } return netTypeCustom } </ins>

Discussion:
/kind bug What happened: Continuation of . The fix to that bug only takes the first subnetwork in the correct region. However, if the user manual subnets in the region that the cluster exists, it's possible the cloudprovider could choose the wrong subnet. What you expected to happen: If no subnet is specified for a non-legacy network, always take the subnet which was automatically created. /assign /sig network /area platform/gce
Change:
apiVersion: apps/v1 kind: Deployment metadata: <del> name: metrics-server-v0.5.0 </del> <ins> name: metrics-server-v0.5.1 </ins> namespace: kube-system labels: k8s-app: metrics-server addonmanager.kubernetes.io/mode: Reconcile <del> version: v0.5.0 </del> <ins> version: v0.5.1 </ins> spec: selector: matchLabels: k8s-app: metrics-server <del> version: v0.5.0 </del> <ins> version: v0.5.1 </ins> template: metadata: name: metrics-server labels: k8s-app: metrics-server <del> version: v0.5.0 </del> <ins> version: v0.5.1 </ins> spec: securityContext: seccompProfile:

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 --As described in issue , we found kubernetes have been running normally, but the control-plane nodes's metrics value of startTime is similar to the timestamp. Get the correct metrics of node As described in issue anything else we need to provide? As described in issue 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:
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 node
/remove-sig node /sig instrumentation /assign
I think the issue is about Summary API having start time for node metric, but this timestamp is incorrect. This is node issue, not instrumentation. /sig node /remove-sig instrumentation /unassign
When discussing adding node start time metric to /metrics/resource endpoint I remember that SIG Node response to this was that there is no good way to define node start time. I don't think we will be able to provide correct value here. As summary API is technically deprecated, it makes no sense to fix it. We should warn users against using it and wait for removal of Summary API.
Okay, let's wait for the release of metrics-server v0.6.0
Do you know if this is fixed in metrics server?
/triage needs-information Can you please add info on name of timeserias and other steps to repro ti understand exactly what is needed here. Thank you!

in metrics server v0.6.0, we will use /metrics/resource Kubelet endpoint instead summary API
as issue described , the result is: for example : the startup time of the node test-us-west-1-control-plane-577lp is "startTime": "2021-08-03T19:33:50Z",, and timestamp reported by metrics is "2021-08-03T19:34:36Z", but as described, output from control plane node