jiebi/CodeConvo huggingface dataset:
Change:
--network "${NETWORK}"  --source-ranges "$2"  --target-tags "$3"  <del> --allow tcp udp icmp esp ah sctp; then </del> <ins> --allow tcp,udp,icmp,esp,ah,sctp; then </ins> if (( attempt > 5 )); then echo -e "${color_red}Failed to create firewall rule $1 ${color_norm}" exit 2

Discussion:
This happens over and over. Scary messages. WARNING: Lists should be separated by commas, try "--allow=tcp,udp,icmp,esp,ah,sctp". If you intend to use udp, icmp, esp, ah, sctp for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--scopes=storage-ro,compute-rw". If you intend to use compute-rw for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--metadata-from-file=startup-script=/usr/local/google/home/thockin/src/kubernetes/hack/e2e-internal/../../cluster/../cluster/gce/../../cluster/../cluster/gce/configure-,kube-env=/tmp/kubernetes.MURmzX/master-kube-". If you intend to use kube-env=/tmp/kubernetes.MURmzX/master-kube- for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--disk=name=e2e-test-thockin-master-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no". If you intend to use device-name=master-pd, mode=rw, boot=no, auto-delete=no for positional arguments, put them before the flag.
That's a new one. gcloud started getting a little more anal here. Exciting. cc
They changed list argument syntax a while back, but the warnings are new. Time to update startup scripts I guess.
Change:
}, }, }) <ins> if apierrors.IsForbidden(err) { // The user is not allowed to create ClusterRoleBindings. This // probably means that RBAC is not being used. If RBAC is being // used, this test will probably fail later. framework.Logf("Attempt to create ClusterRoleBinding was forbidden: %v.", err) return } </ins> framework.ExpectNoError(err) err = framework.WaitForAuthorizationUpdate(jig.client.Authorization(),

Discussion:
Three tests now create RoleBindings to give permissions to test service accounts: NodeProblemDetector Ingress PreStop Creating RBAC Rolebindings currently requires the user issuing the create call to have the required permissions. If RBAC is not enabled, and the cluster hasn't been configured with any RBAC bootstrapping, that won't be possible. We should make this test code conditional on whether RBAC is in use.
c.f.
Quick fix is to tolerate forbidden errors there and assume e2e setups using methods other than RBAC have already granted permissions to the service accounts
I'll put together a PR to tolerate the 403 in the test helper.
I think this can be closed now that the e2e RBAC setup is best effort and failures there don't affect the test if another authorizer is in use
I agree. My original thought was that we'd make the RBAC test stuff only happen on RBAC-enabled setups. But, since we're going to be pushing setups towards using RBAC, we might as well have those pieces stick around in the common code (as best-effort).
Change:
configs[ResourceConsumer] = Config{list.PromoterE2eRegistry, "resource-consumer", "1.13"} configs[SdDummyExporter] = Config{list.GcRegistry, "sd-dummy-exporter", "v0.2.0"} configs[VolumeNFSServer] = Config{list.PromoterE2eRegistry, "volume/nfs", "1.3"} <del> configs[VolumeISCSIServer] = Config{list.PromoterE2eRegistry, "volume/iscsi", "2.5"} </del> <ins> configs[VolumeISCSIServer] = Config{list.PromoterE2eRegistry, "volume/iscsi", "2.6"} </ins> configs[VolumeRBDServer] = Config{list.PromoterE2eRegistry, "volume/rbd", "1.0.6"} configs[WindowsServer] = Config{list.MicrosoftRegistry, "windows", "1809"}

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
</tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">message</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">String detailing the error encountered during Attach or Detach operation. This string maybe logged, so it should not contain sensitive information.</p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">String detailing the error encountered during Attach or Detach operation. This string may be logged, so it should not contain sensitive information.</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td> <td class="tableblock halign-left valign-top"></td>

Discussion:
This came up as a follow up to Also rather than opening 5 different issues - we are going to use this github issue to track all follow up items mentioned here -
/sig storage
/assign /assign
: PR
and the rest is fixed in
Change:
} <ins> func TestCleanLegacyRealServersExcludeCIDRs(t *testing.T) { ipt := iptablestest.NewFake() ipvs := ipvstest.NewFake() ipset := ipsettest.NewFake(testIPSetVersion) gtm := NewGracefulTerminationManager(ipvs) fp := NewFakeProxier(ipt, ipvs, ipset, nil, []string{"4.4.4.4/32"}) fp.gracefuldeleteManager = gtm vs := &utilipvs.VirtualServer{ Address:   net.ParseIP("4.4.4.4"), Protocol:  string(v1.ProtocolUDP), Port:      56, Scheduler: "rr", Flags:     utilipvs.FlagHashed, } fp.ipvs.AddVirtualServer(vs) rss := []*utilipvs.RealServer{ { Address:      net.ParseIP("10.10.10.10"), Port:         56, ActiveConn:   0, InactiveConn: 0, }, { Address:      net.ParseIP("11.11.11.11"), Port:         56, ActiveConn:   0, InactiveConn: 0, }, } for _, rs := range rss { fp.ipvs.AddRealServer(vs, rs) } fp.netlinkHandle.EnsureDummyDevice(DefaultDummyDevice) fp.netlinkHandle.EnsureAddressBind("4.4.4.4", DefaultDummyDevice) fp.cleanLegacyService( map[string]bool{}, map[string]*utilipvs.VirtualServer{"ipvs0": vs}, map[string]bool{"4.4.4.4": true}, ) fp.gracefuldeleteManager.tryDeleteRs() remainingRealServers, _ := fp.ipvs.GetRealServers(vs) if len(remainingRealServers) != 2 { t.Errorf("Expected number of remaining IPVS real servers after cleanup should be %v. Got %v", 2, len(remainingRealServers)) } } </ins> func TestCleanLegacyService6(t *testing.T) { ipt := iptablestest.NewFake() ipvs := ipvstest.NewFake()

Discussion:
What happened: When I config kube-proxy with excludeCIDRs, kube-proxy still try to delete my ipvs rules. What you expected to happen: kube-proxy not delete excludeCIDRs virturl server. How to reproduce it (as minimally and precisely as possible): kubeadm init --config=kubeadm- --experimental-upload-certs Then add a ipvs on node: Then join the node, you can see kube-proxy log: If don't have an active connection, the ipvs will removed. Environment: Kubernetes version (use ): v1.14.0 OS (e.g: ): centos7.4 Kernel (e.g. ): 10 Install tools: kubeadm
/sig network
/triage unresolved I am a bot run by ‍
Kube-proxy delete RS from VIP, even if VIP in excludeCIDRs Because RS are the same with RS from Service VIP's Expected: But kube-proxy make that: - -
I think this is not we expected. I want using ipvs as a local porxy for kubernetes HA.
I've raised the pr
/remove-triage unresolved
Change:
} }) <del> It("should create matching services in underlying clusters", func() { </del> <ins> It("should create and update matching services in underlying clusters", func() { </ins> fedframework.SkipUnlessFederated(f.ClientSet) service = createServiceOrFail(f.FederationClientset, nsName, FederatedServiceName) defer func() { // Cleanup

Discussion:
As mentioned in when the service is deleted from the underlying cluster, the controller should recreate it, but it does not. Below's a transcript. is talking to the federation-apiserver, and is talking to the normal cluster it's pointed at.
Thanks for catching this cc
cc
This is definitely a bug, but I think that we can kick it out into v1.4. Until fixed (i.e. while in beta), we can tell customers not to delete the underlying services in their clusters.
it should not be, I have tested this before. How long did you wait when you check the service existence in last step? Can you send me the logs? The service deletion will cause federation service update, and then the federation service watcher will catch the update even and call another round of service updates to all clusters. When you delete the service, if the service got ingress ip already? I am thinking if the deletion did not trigger federation service update? So so no update event generated..
I think that the best way forward will be to encode this in a reproducible e2e test, otherwise there are too many variables to debug effectively. It's great to know that you've tested this case, and it works in at least some scenarios.
one possible solution come into my mind, currently we set the service full sync time to 10 minutes , if we change it back to 30s, then at least during the full sync, the deleted service will be re-created. I will send a PR anyway, you can judge if it should be put to v1.3
I think we need to find and fix the underlying problem, not cover it up with a shorter sync period. If we have the correct watch on each service, we will be notified as soon as they are deleted. Why is the watch notification not firing correctly?
Keeping this open until we've verified this fix in e2e tests.
I believe this to be fixed, but we still lack an e2e test to verify conclusively. would you like to take this on along with the other e2e tests that you are busy adding?
ping
plan on doing this for 1.4? or bump to 1.5?
Yes, 1.5 is fine.
switching this to 1.6 as it's too late for 1.5. ok?

Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.
Change:
func RestartApiserver(cs clientset.Interface) error { // TODO: Make it work for all providers. if !ProviderIs("gce", "gke", "aws") { <del> return fmt.Errorf("unsupported provider: %s", TestContext.Provider) </del> <ins> return fmt.Errorf("unsupported provider for RestartApiserver: %s", TestContext.Provider) </ins> } if ProviderIs("gce", "aws") { initialRestartCount, err := getApiserverRestartCount(cs)

Discussion:
is failing with "framework.RestartControllerManager() = unsupported provider: gke; want nil" /kind failing-test
/sig network
Introduced in , should be fixed by
Change:
// The first successful sync with the underlying store. // The cache must wait until this first sync is completed to be deemed ready. // Since we cannot send a bookmark when the lastProcessedResourceVersion is 0, <del> // we poll aggressively for the first RV before entering the dispatch loop. </del> <ins> // we poll aggressively for the first list RV before entering the dispatch loop. </ins> lastProcessedResourceVersion := uint64(0) if err := wait.PollUntilContextCancel(wait.ContextForChannel(c.stopCh), 10*time.Millisecond, true, func(_ context.Context) (bool, error) { <del> if rv := c.watchCache.getResourceVersion(); rv != 0 { </del> <ins> if rv := c.watchCache.getListResourceVersion(); rv != 0 { </ins> lastProcessedResourceVersion = rv return true, nil }

Discussion:
sig-release-master-blocking ci-kubernetes-unit 05/30/2024 19:25 IST Prow Logs: Triage: No response /sig
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 storage
/sig api-machinery
/cc This started last week, but it seems to be fairly rare, so might be a consequence of something a bit earlier. The value of "2" suggests that it's happening on the first event, and my brain goes towards: - will you be able to take a look at it?
sure, I will have a look. /assign
We chatted with about that offline and it seems like a real correctness issue. Regression indeed introduced by We have a race with setting RV in watchcache and incoming events. The current explanation is: initializeds with RV=N event comes with RV=N+1 [but wasn't yet dispatched] polling introduced in that PR catches RV=N+1 then the event (with RV=N+1) is received
So it is a release blocker, then? (Upcoming alpha 1 release cut scheduled for tomorrow)
I don't know what the release policy is but we might have a potential fix for this issue.
This is a real correctness bug introduced 2 weeks ago. I'm not sure what's our policy is for alpha releases, but it sounds like a potential blocker to me.
The fix for it is already approved.
Change:
RBDPool:      "pool1", RBDImage:     "image1", FSType:       "ext4", <ins> ReadOnly:     true, </ins> }, }, }),

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I created a job with parallelism=2, 1 container in each pod, and a rbd volume attached to the container. Attachment was read-only. Only 1 pod got the RBD mounted while the other POD failed with "still in use" in syslog, referencing the code in that checks watchers. Note that this is not the same thing as this: which refers to persistent volumes. This is not a persistent volume -the use case is to map read-only data to multiple containers from a single RBD, like for using a reference data set, etc. According to the documentation this should work (see below). What you expected to happen: I expect this to happen per the documentation: "A feature of RBD is that it can be mounted as read-only by multiple consumers simultaneously. This means that you can pre-populate a volume with your dataset and then serve it in parallel from as many Pods as you need. Unfortunately, RBD volumes can only be mounted by a single consumer in read-write mode - no simultaneous writers allowed." How to reproduce it (as minimally and precisely as possible): Create 2 pods, each with 1 container mapping a single rbd read only. Anything else we need to know?: Environment: Kubernetes version (use ): 4 Cloud provider or hardware configuration: self, x8664 systems OS (e.g. from /etc/os-release): Ubuntu Xenial Kernel (e.g. ): Linux dal1util6p30 4.4.0-116-generic -Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: ceph Others: I believe that in the case where a read-only mapping is being requested, the code should not check watchers. Again this is consistent with the documentation but it doesn't work that way. If a PV/PVC is the "right" way to do this it seems seriously overkill and the management overhead is severe, especially in a large scale environment.

The documentation states that the advantage of RBD is to be able to attach read-only volumes to multiple containers concurrently, and this is how I believe it should work. The watcher check is artificial and really needs to apply only to read/write. I can fix this bug myself but would like to understand the reasoning behind it a bit more. Thanks! Leo Reiter
/sig
Reiterating the mentions to trigger a notification: <detailsIn response to : /sig 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
Reiterating the mentions to trigger a notification: <detailsIn response to : /sig 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 will check the problem.
/assign
Change:
# limits the size of metadata fields to 32K, and stripping comments is the # easiest way to buy us a little more room. function prepare-startup-script() { <del> sed '/^s*#([^!].*)*$/ d' ${KUBE_ROOT}/cluster/gce/configure-vm.sh > ${KUBE_TEMP}/configure-vm.sh </del> <ins> # Find a standard sed instance (and ensure that the command works as expected on a Mac). SED=sed if which gsed &>/dev/null; then SED=gsed fi if ! ($SED --version 2>&1 | grep -q GNU); then echo "!!! GNU sed is required.  If on OS X, use 'brew install gnu-sed'." exit 1 fi $SED '/^s*#([^!].*)*$/ d' ${KUBE_ROOT}/cluster/gce/configure-vm.sh > ${KUBE_TEMP}/configure-vm.sh </ins> }

Discussion:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No 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): BUG REPORT Kubernetes version (use ): 1.5 beta 2 Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): CVM Kernel (e.g. ): Install tools: kube- What happened: Step 6 of fails What you expected to happen: Node upgrade to succeed. How to reproduce it (as minimally and precisely as possible): Follow the manual upgrade steps outlined in the linked document. Anything else do we need to know: The error is because the metadata is too large for the new node instance template.
More complete error output:
This is blocking test and per email I'm bumpting this to P0.
Does it mean that "node-kube-" is too large? It seems like that too me. If so, we should understand why those are different than on startup...
This is broken for me too: After an upgrade.
: so who is going to be the assignee? and come up with a plan of attack? :)
The problem is that configure- is too large. In my directory: You can see that the number of bytes in configure- () matches the output in the error message (). What is interesting is that configure- in the repo is actually larger_. In the 1.5 branch: and in the 1.4 branch: But we aren't seeing an error during new cluster creation in either release branch.
In the directory when creating a new cluster from the 1.4 branch: which is below the size limit.
Here's the diff between the two configure- scripts: which makes it appear that is the culprit.
This may be a mac issue -- when I manually run the command from the function it makes no changes. But if I run instead of then it strips a bunch of comments, reducing the file size below the allowed limit:
We should be able to do the same thing we do in this file to fix it.
I created but haven't had a chance to test it yet.

(Master and) node upgrade worked for me on Ubuntu, so this does indeed seem to be Mac-specific.
I tested and it looks like it fixed my issue. I suppose I'll need to cherry pick it into the 1.5 branch once it merges to master.
Change:
} else { // This never happens, because dedupDeltas never returns an empty list // when given a non-empty list (as it is here). <del> // But if somehow it ever does return an empty list, then // We need to remove this from our map (extra items in the queue are // ignored if they are not in the map). delete(f.items, id) </del> <ins> // If somehow it happens anyway, deal with it but complain. if oldDeltas == nil { klog.Errorf("Impossible dedupDeltas for id=%q: oldDeltas=%#+v, obj=%#+v; ignoring", id, oldDeltas, obj) return nil } klog.Errorf("Impossible dedupDeltas for id=%q: oldDeltas=%#+v, obj=%#+v; breaking invariant by storing empty Deltas", id, oldDeltas, obj) f.items[id] = newDeltas return fmt.Errorf("Impossible dedupDeltas for id=%q: oldDeltas=%#+v, obj=%#+v; broke DeltaFIFO invariant by storing empty Deltas", id, oldDeltas, obj) </ins> } return nil }

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: In reviewing another PR, I noticed incorrect commentary and code. The primary offense is at , where a comment asserts (incorrectly) that a key can be present in but not and the code removes a key from without ensuring it is absent from . The only saving grace is that this code is actually unreachable (as also noted in the comment). I think it would be better to fix the comment and in this unreachable situation, than to violate an invariant that is critical to other code in this file. also contemplates the possibility that a key can be in and absent from . What you expected to happen: I expected there to be no comments or code that contemplate violations of the invariant at How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): current branch 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:
Sorry, I should have noticed this in my earlier pass over this code.
Agreed. Was discussing this with at
We discussed this one, Mike will send PR, Daniel will review.
Change:
// ... HPAScaleToZero: {Default: false, PreRelease: featuregate.Alpha}, <del> DisableKubeletCSRAdmissionValidation: {Default: false, PreRelease: featuregate.Deprecated}, // remove in 1.33 </del> <ins> AllowInsecureKubeletCertificateSigningRequests: {Default: false, PreRelease: featuregate.Deprecated}, // remove in 1.33 </ins> StorageNamespaceIndex: {Default: true, PreRelease: featuregate.Beta},

Discussion:
This comes from We've a feature gate, . However, we try to name feature gates after the positive thing they add, even if it's on by default, or even if we're setting if false because the positive thing is being dropped (rare, but it happens). Typically we don't start feature gate names with , as it makes the docs jar: Example quote 1: To temporarily revert to the legacy behavior, enable the feature gate. vs Example quote 2: You can enable the feature gate if you run code that relies on the previous behavior. You should plan to migrate. and because disabling things isn't really a feature. Some examples of gates you can or once could disable by turning them off_ include: - - - So, I recommend a rename of the gate before the v1.31 release. /sig auth architecture
FYI
Example gate names: (off by default) (off by default) (on by default) (on by default) (on by default) from (off by default, deprecated)
/milestone v1.31
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.31 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
Another possibility: , deprecated, off by default
Hello there! I am new to kubernetes and I want to contribute in it. Is it something that I can contribute to?
This issue is not a good issue for a first-time contributor to work on.
I'm a fan of , deprecated, off by default
hoping one of you are doing the PR? :) /milestone v1.31