jiebi/CodeConvo huggingface dataset:
Change:
Port *intstr.IntOrString `json:"port,omitempty" protobuf:"bytes,2,opt,name=port"` } <del> // IPBlock describes a particular CIDR (Ex. "192.168.1.1/24") that is allowed to the pods // matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should // not be included within this rule. </del> <ins> // IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed // to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs // that should not be included within this rule. </ins> type IPBlock struct { // CIDR is a string representing the IP Block <del> // Valid examples are "192.168.1.1/24" </del> <ins> // Valid examples are "192.168.1.1/24" or "2001:db9::/64" </ins> CIDR string `json:"cidr" protobuf:"bytes,1,name=cidr"` // Except is a slice of CIDRs that should not be included within an IP Block <del> // Valid examples are "192.168.1.1/24" </del> <ins> // Valid examples are "192.168.1.1/24" or "2001:db9::/64" </ins> // Except values will be rejected if they are outside the CIDR range // +optional Except []string `json:"except,omitempty" protobuf:"bytes,2,rep,name=except"`

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : mentions an IPBlock with only IPv4 examples. Add a comment or example to clarify that IPv6 network blocks are (or possibly aren't) valid here. Why is this needed: Cluster operators who use IPv6 networking want to understand how to isolate different workloads inside their cluster network (and without reading source code). Logged against kubernetes/kubernetes rather than the website repo because this is generated documentation. Kubernetes already has single-stack support for IPv6 clusters KEP for dual-stack support is /sig docs /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved can you guide me on what steps are needed to publish the examples?
I via the pull request. (Although I want these examples , it's not a task I'm familiar with).
Change:
// Input args must follow the format and sequence of ebtables list output. Otherwise, EnsureRule will always create // new rules and causing duplicates. EnsureRule(position RulePosition, table Table, chain Chain, args ...string) (bool, error) <ins> // DeleteRule checks if the specified rule is present and, if so, deletes it. DeleteRule(table Table, chain Chain, args ...string) error </ins> // EnsureChain checks if the specified chain is present and, if not, creates it.  If the rule existed, return true. EnsureChain(table Table, chain Chain) (bool, error) // DeleteChain deletes the specified chain.  If the chain did not exist, return error.

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The ebtables utility in is missing 3 useful features: method in its Interface table chain Why is this needed: The missing features are useful to allow for: rule deletion as there is a way to add (ensure) a rule but not removing it currently. manipulating the broute table and brouting chain The first feature would also align ebtables with iptables, as a DeleteRule method is available there.
/sig network
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Is there some feature/bugfix you're working on in kubernetes that needs this?
Yes, in kubernetes/dns (node-cache) actually. That PR is working, but it's only in my fork of kubernetes/dns at the moment as it depends on this. It solves this: Adding this code to ebtables would help me avoid re-inventing the wheel there.
... not sure if you've seen that ... but I have created a PR to solve this issue already:
Yes, I saw the PR first. So, kubernetes/kubernetes isn't really intended to be vendored into other repos and kubernetes/dns is being bad here. It's dubious to add methods to that kubernetes itself isn't using because someone else might just end up removing them later when they notice that they're not being used... OTOH the PR needs access to the internals of the ebtables code so you couldn't just add it to kubernetes/dns directly without forking all of ...
Thanks for your comments. I saw iptables used that way in node-cache and I thought it would be good for consistency to go down the same route with ebtables. To be honest I am not very keen on forking the entire package, for obvious reasons, but I can understand your reservations about this change.
/assign
Hi Did you manage to discuss this?
yes, sorry, didn't get a chance to get back to this on Friday. (I /lgtm'ed the PR) /remove-triage unresolved
Thanks!
Change:
# Pre-Condition: namepace does not exist and no POD exists output_message=$(! kubectl get namespace multi-resource-ns 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'namespaces "multi-resource-ns" not found' <del> kube::test::get_object_assert pods "{{range.items}}{{${id_field:?}}}:{{end}}" '' </del> <ins> kube::test::wait_object_assert pods "{{range.items}}{{${id_field:?}}}:{{end}}" '' </ins> # First pass, namespace is created, but pod is not (since namespace does not exist yet). output_message=$(! kubectl apply -f hack/testdata/multi-resource-1.yaml 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'namespaces "multi-resource-ns" not found'

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 --Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: runkubectlapplytests Testgrid link: Reason for failure: A test has a precondition that no pods should be up, but, previous test's deployment did not fully delete. As a result precondition check fails. Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig testing
Pasting the failed tests' output, for easy reference:
Found one more flake test, due to same reason. Checking for more.
Change:
if math.Mod(float64(fsize), float64(testpatterns.MinFileSize)) != 0 { fsize = fsize/testpatterns.MinFileSize + testpatterns.MinFileSize } <del> fpath := path.Join(dir, fmt.Sprintf("%s-%d", file, fsize)) </del> <ins> fpath := filepath.Join(mountPath, fmt.Sprintf("%s-%d", file, fsize)) defer func() { deleteFile(clientPod, fpath) }() </ins> if err = writeToFile(clientPod, fpath, ddInput, fsize); err != nil { return err } if err = verifyFile(clientPod, fpath, fsize, ddInput); err != nil { return err } <del> deleteFile(clientPod, fpath) </del> } return

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)] volumeIO should write files of various sizes, verify size, validate content [Slow] Since when has it been failing: 11/13 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: This is consistently failing in 1.13 branch and is release blocking. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test /sig storage /priority critical-urgent /milestone v1.13 /assign /cc
The test case is failing because it wrote 2MB instead of the expected 1MB. It's also very odd that the test is failing in soak, but passing in regular CI suites.
There's a few problems: .GetVolumeSource returns "/tmp" for everything. This means all tests will share the same directory. This should be probably use some unique directory instead volume IO test generates a unique mountPath directory, however that doesn't mean a unique directory is actually created on the host. Ie, a mountPath of "/a/b/c" on a hostpath volume at "/tmp" doesn't mean directory "/tmp/a/b/c" is created. io test file name is not unique seems like the IO test is not cleaning up the files it creates, so the files are getting reused on subsequent tests due to the non-unique naming issues.
The other thing I can't explain is why it's failing only now
Fix is here:
As per discussion in 1.13 burndown this morning, this is a test job issue and its not release blocking at this point. So we can take this fix in 1.14 as opposed now during code freeze let us know if you feel otherwise
/milestone v1.14 /priority important-soon
/remove-priority critical-urgent
Change:
} for _, lb := range serviceLBNames { framework.Logf("cleaning gce resource for %s", lb) <del> framework.CleanupServiceGCEResources(lb) </del> <ins> framework.CleanupServiceGCEResources(lb, framework.TestContext.CloudConfig.Zone) </ins> } //reset serviceLBNames serviceLBNames = []string{}

Discussion:
In federation tests, if we observe the build logs. we see cleaning up LoadBalancer from cloud provider seems not working. It has 2 effects: delays the tests by waiting to delete but always returns error. so we waste like 5 minutes. maybe we are leaking the LoadBalancer in the project.
we can see these errors in every build. but just for reference here are some build logs https://k8s-
cc
All the errors in logs are . It doesn't necessarily indicate we are leaking resource, just now we must have clusterID initialized before calling EnsureLoadBalancerDeleted(). Would be better to not call this function directly in e2e test :)
Federation cleanup should use the same implementation as non-federated e2e test:
function looks like only specific to GCE. in future we would run the e2e tests in AWS too. it would be better to use generic functions if any.
using is working for us. here is the test logs https://k8s-
EnsureLoadBalancerResourcesDeleted() actually cleans up nothing, it only lists forwarding rules and probably logging :)
Change:
if cfg, err := ReadDockerConfigFile(); err == nil { return cfg } else if !os.IsNotExist(err) { <del> glog.V(1).Infof("Unable to parse Docker config file: %v", err) </del> <ins> glog.V(4).Infof("Unable to parse Docker config file: %v", err) </ins> } return DockerConfig{} }

Discussion:
As per We should look for the .dockercfg in three places: ./.dockercfg, ~/.dockercfg, and $rootDir/.dockercfg
I'll tackle this.
Bunch of questions: we also add a flag that overrides the search mechanism suggested in this issue? Perhaps, ? to the user's homedir requires we use os/user [0] . The os/user package and cross-compiling don't play nice [1]. So, if we add to the search path, cross-compiled kubelet binaries will not actually be able to take advantage of it. Is this an issue? is the proper lookup order? I suggest: if provided, , , . walking through the lookups, do we stop at the first file that exists, or the first file that exists and is parsed as a valid ? [0] [1] /cc
I would absolutely love a --dockercfg option, and it would also be helpful if it logged which .dockercfg it ultimately used.
1) Seems like YAGNI to me 2) Is all of os/user broken? We will eventually want actual user support. I'm fine with dropping it for now. 3) I would say $rootDir/.dockercfg, ./.dockercfg (assuming we drop ~) 4) First successful parse sounds good to me. And can we NOT log errors if files don't exist :)
would it make sense to default to the kubelet config directory if provided rather than the working directory of the kubelet process? then no extra flag required.
What ever happened with this idea?
/cc
It never got high enough on my weekend TODO list :( I can keep telling myself that I need to do it, or we can find someone who has a bit more time than me.
I can probably get to this today.
Cool, thank you! , Mike Danese wrote:
Change:
} func NewResourceExpirationEvaluator(currentVersion apimachineryversion.Info) (ResourceExpirationEvaluator, error) { <del> ret := &resourceExpirationEvaluator{ // TODO https://github.com/kubernetes/kubernetes/issues/109799 set this back to false after beta is tagged. strictRemovedHandlingInAlpha: true, } </del> <ins> ret := &resourceExpirationEvaluator{} </ins> if len(currentVersion.Major) > 0 { currentMajor64, err := strconv.ParseInt(currentVersion.Major, 10, 32) if err != nil {

Discussion:
once the we hit a beta release, we can reset the default value for strict handling to false to prep for 1.25. It will likely be introduced in /kind bug /priority important-soon /milestone v1.25 ignore template No response this time <details</details<details</details<details</details<details</details
/sig api-machinery
/assign /triage accepted
Hello my name is Justin Chizer and I am one of the k8s 1.25 bug triage shadow assigned to track this body of work. Is this still on track for 1.25?
This needs to be done now that master is on 1.26 until 1.25.0 is cut, since verify jobs are failing on removal of 1.26 deprecated APIs /priority critical-urgent
Change:
} if !f.readOnly { <del> volume.SetVolumeOwnership(f, fsGroup) </del> <ins> if f.plugin.capabilities.FSGroup { volume.SetVolumeOwnership(f, fsGroup) } </ins> } return nil

Discussion:
What happened: For some filesystems recursively applying an SELinux label through chcon or the GID permission is expensive (30 mins in some cases). There is better strategies for the recursive change and the call should be available through FLEX API. What you expected to happen: FLEX has a shell script call to label or set GID for a volume. Notes-- The fix should be backwards compatible.. If the shell call to perform the permission change is absent, then we fall back on the original method.
Change:
) (bool, []algorithm.PredicateFailureReason, error) { ec.mu.Lock() defer ec.mu.Unlock() <ins> if nodeInfo == nil || nodeInfo.Node() == nil { // This may happen during tests. return false, []algorithm.PredicateFailureReason{}, fmt.Errorf("nodeInfo is nil or node is invalid") } </ins> fit, reasons, invalid := ec.lookupResult(pod.GetName(), nodeInfo.Node().GetName(), predicateKey, equivClassInfo.hash) if !invalid { return fit, reasons, nil

Discussion:
in the integration test in an seemingly unrelated PR
/assign
It is known that may be nil during testing, and we've checked this case in some other places. But not sure why this happens in TestTaintNodeByCondition right now. Looking looking ...
Another case in another unrelated PR https://k8s-
, thanks for your input, I'd like to see what will happen after merged :)
still seeing this: panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x1103224] goroutine [running]: (0x0, 0x0, 0x0) +0x107 panic(0x361b8e0, 0x71ac100) +0x229 (ObjectMeta).GetName(...) (EquivalenceCache).RunPredicate(0xc42500cd40, 0x3f62748, 0x3e2aa3f, 0x11, 0xc42f9a2380, 0x523ab40, 0xc4345c8e10, 0x0, 0xc4235e5d50, 0x528e060, ...) +0xc4 (0xc42f9a2380, 0x523ab40, 0xc4345c8e10, 0x0, 0xc4339a3320, 0x528e060, 0xc42436fa40, 0xc42500cd40, 0x527b2c0, 0xc43b40ee70, ...) +0x1de (*genericScheduler).findNodesThatFit.func1(0x0) +0x19a (0xc4235e5d90, 0xc42cdbad20, 0xc43bb83dc0) +0x96 created by +0x10b https://k8s-
is the failing code live in master or feature gated? is this a release blocker?
The failing code is live in master(, we enabled the feature gate in the test), where as the equivalence cache is still in alpha.

While the issue is something needs to be fixed in ecache code which is working on, this shouldn't be be blocking 1.11 release as we are still planning to graduate ecache to beta and that has not yet happened. I will send a PR to disable test till the promotion happens. While promoting ecache we can re-enable it.
Equivalence cache implementation is behind a feature gate, and still alpha.
Change:
"k8s.io/apimachinery/pkg/types" "k8s.io/kubernetes/pkg/util/mount" utilstrings "k8s.io/kubernetes/pkg/util/strings" <ins> "k8s.io/kubernetes/pkg/volume" </ins> ) type flexVolume struct {

Discussion:
kind feature What happened: Currently there is no mechanism to report metrics as the flex plugins are not enabled to collect metrics. All flex volumes lack this feature as compared to in-tree/built-in drivers even though it is possible to collect such metrics for most of the plugins. What you expected to happen: Depending on the availability of the metrics from the mounted FS, flex plugins should allow to report metrics for the FS. How to reproduce it (as minimally and precisely as possible): The default behavior that can be proved easily by just running a command similar to the following command on a node that is running a flex volume. This will show that there are no metrics collected for flex volumes. kubectl proxy $curl 127.0.0.1:8001/api/v1/nodes/<IP/proxy/stats/summary Environment**: Kubernetes version (use ): 1.12 Cloud provider or hardware configuration: local x86 OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux KubeStorage 4.4.0-130-generic -Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Others: /sig storage
+1 Yes, it will be good, if flex volume can support atleast the default metrics( i.e ), which most of the volume plugins support now. Based upon flex plugin "capabilities" parameters, it can be decided, whether the plugin supports "default metrics" or "nil metrics".
Change:
<ins> The [SaltStack pillar](http://docs.saltstack.com/en/latest/topics/pillar/) data is partially statically dervied from the contents of this directory. The bulk of the pillars are hard to perceive from browsing this directory, though, because they are written into [cluster-params.sls](cluster-params.sls) at cluster inception. * [cluster-params.sls](cluster-params.sls) is generated entirely at cluster inception. See e.g. [configure-vm.sh](../../gce/configure-vm.sh#L226) * [docker-images.sls](docker-images.sls) stores the Docker tags of the current Docker-wrapped server binaries, twiddling by the Salt install script * [logging.sls](logging.sls) defines the cluster log level * [mine.sls](mine.sls): defines the variables shared across machines in the Salt mine. It is starting to be largely deprecated in use, and is totally unavailable on GCE, which runs standalone. * [privilege.sls](privilege.sls) defines whether privileged containers are allowed. * [top.sls](top.sls) defines which pillars are active across the cluster. ## Future work Document the current pillars across providers </ins>

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
return true, tr, nil })) <del> _, host := newTestHost(t, client) </del> <ins> tempDir, host := newTestHost(t, client) defer os.RemoveAll(tempDir) </ins> var myVolumeMounter = projectedVolumeMounter{ projectedVolume: &projectedVolume{

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: I run the unit tests for , but I found it would not clean the tempdir it created. ! What you expected to happen: automatically clean up when finishing unit tests. How to reproduce it (as minimally and precisely as possible): go test $ Anything else we need to know?: Environment: k8s 1.15 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 storage /sig testing
/assign Assign the issue to you since you have fired a pull request.
Change:
// Same as above, when annotations are modified with ServerSideApply, // ManagedFields may also change and must be excluded p.ManagedFields = nil <del> // Finalizers must be excluded because scheduled result can not be affected </del> <ins> // The following might be changed by external controllers, but they don't // affect scheduling decisions. </ins> p.Finalizers = nil <ins> p.Status.Conditions = nil </ins> return p } assumedPodCopy, podCopy := f(assumedPod), f(pod)

Discussion:
What happened: An extra scheduling attempt is observed in some scenarios when kube-scheduler already has already assumed a pod and this has entered the binding routine. If, during this time, a pod update is received, the pod is back to the scheduling queue, even if binding succeeds. This is the correct behavior, as scheduling conditions might change. However this updates could just be unrelated status updates, such as updates to pod conditions. We observe an extra scheduling attempt, which is visible in the log line: Which indicates that an attempt was made when the pod was already scheduled. What you expected to happen: No extra scheduling attempts How to reproduce it (as minimally and precisely as possible): This depends on other controllers running on the cluster that might report pod conditions. One such controller is
/sig scheduling
Change:
experimentalCheckNodeCapabilitiesBeforeMount, keepTerminatedPodVolumes) <del> runtimeCache, err := kubecontainer.NewRuntimeCache(klet.containerRuntime) if err != nil { return nil, err } klet.runtimeCache = runtimeCache </del> klet.reasonCache = NewReasonCache() klet.workQueue = queue.NewBasicWorkQueue(klet.clock) klet.podWorkers = newPodWorkers(klet.syncPod, kubeDeps.Recorder, klet.workQueue, klet.resyncInterval, backOffPeriod, klet.podCache)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In version 1.8.0, accessing the container stats via Kubelet API proxy using the path returns 503. What you expected to happen: In versions prior to 1.8.0, the container stats were returned. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.8.0 OS (e.g. from /etc/os-release): Mac OS X Install tools: Minikube
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
does the summary API also have issues? ?
The summary API works as expected. The affected endpoints are:
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 stale
/remove-lifecycle stale
/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
Hmm... this fell of my radar a bit. If you go directly to the node, do you get a response?
no response either. I've created that fixes the issue. I think there has been a refactoring introduced in version 1.8 that broke the sequence of objects initialisation for that endpoint.