jiebi/CodeConvo huggingface dataset:
Change:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately 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

Discussion:
specs := []*spec.Swagger{} for _, v := range crd.Spec.Versions { <del> s, err := builder.BuildSwagger(crd, v.Name, builder.Options{V2: false, StripDefaults: true, StripValueValidation: true, AllowNonStructural: true}) </del> <ins> s, err := builder.BuildSwagger(crd, v.Name, builder.Options{V2: false, StripDefaults: true, StripValueValidation: true, StripNullable: true, AllowNonStructural: true}) </ins> if err != nil { return nil, err }

v.Visit(s) return s } <ins> // StripNullable returns a copy without nullable. func (s *Structural) StripNullable() *Structural { s = s.DeepCopy() v := Visitor{ Structural: func(s *Structural) bool { changed := s.Nullable s.Nullable = false return changed }, } v.Visit(s) return s } </ins>

// Strip value validation. StripValueValidation bool <ins> // Strip nullable. StripNullable bool </ins> // AllowNonStructural indicates swagger should be built for a schema that fits into the structural type but does not meet all structural invariants AllowNonStructural bool }

if opts.StripValueValidation { schema = schema.StripValueValidations() } <ins> if opts.StripNullable { schema = schema.StripNullable() } </ins> schema = schema.Unfold() }

"type": "string" }, "protocol": { <del> "type": "string" </del> <ins> "type": "string", "nullable": true </ins> } }, "required": [
Change:
<!-- 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: vmss dirty cache issue, caused by What you expected to happen: clean vmss cache should happen after disk attach/detach operation, now it's before those operations, which would lead to dirty cache. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure

Discussion:
defer cancel() // Invalidate the cache right after updating <del> if err = ss.deleteCacheForNode(vmName); err != nil { return err } </del> <ins> defer ss.deleteCacheForNode(vmName) </ins> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s, %s) with DiskEncryptionSetID(%s)", nodeResourceGroup, nodeName, diskName, diskURI, diskEncryptionSetID) _, err = ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM, "attach_disk")

defer cancel() // Invalidate the cache right after updating <del> if err = ss.deleteCacheForNode(vmName); err != nil { return nil, err } </del> <ins> defer ss.deleteCacheForNode(vmName) </ins> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s, %s)", nodeResourceGroup, nodeName, diskName, diskURI) return ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM, "detach_disk")

return err } <del> // Invalidate the cache since we would update it. if err = ss.deleteCacheForNode(vmName); err != nil { return err } </del> <ins> // Invalidate the cache since right after update defer ss.deleteCacheForNode(vmName) </ins> // Update vmssVM with backoff. ctx, cancel := getContextWithCancel()

return err } <del> // Invalidate the cache since we would update it. if err = ss.deleteCacheForNode(nodeName); err != nil { return err } </del> <ins> // Invalidate the cache since right after update defer ss.deleteCacheForNode(nodeName) </ins> // Update vmssVM with backoff. ctx, cancel := getContextWithCancel()

func (ss *scaleSet) deleteCacheForNode(nodeName string) error { cached, err := ss.vmssVMCache.Get(vmssVirtualMachinesKey, cacheReadTypeUnsafe) if err != nil { <ins> klog.Errorf("deleteCacheForNode(%s) failed with error: %v", nodeName, err) </ins> return err }
Change:
<!-- 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 some cases, a create volume request can succeed in vSphere but time out in the vSphere storage plugin. This request will be retried, but fails with on subsequent attempts. As a result, the PersistentVolume object never gets created, and the pod requesting it never starts. Recovery requires manual steps. What you expected to happen: Since vSphere successfully created the volume, the storage plugin should reconcile and allow the PersistentVolume to get created. How to reproduce it (as minimally and precisely as possible): This is difficult to reproduce because it is caused by specific timing between vSphere and kubernetes. For testing, I a line of code to [][1] to inject failures after vSphere created the volume. [1]: Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage
Fixed by

Discussion:
if diskManager.volumeOptions.SCSIControllerType == "" { diskManager.volumeOptions.SCSIControllerType = vclib.LSILogicControllerType } <del> // Create virtual disk diskFormat := vclib.DiskFormatValidType[diskManager.volumeOptions.DiskFormat] // Create a virtual disk manager vdm := object.NewVirtualDiskManager(datastore.Client()) </del> <ins> // Check for existing VMDK before attempting create. Because a name collision // is unlikely, "VMDK already exists" is likely from a previous attempt to // create this volume. if dsPath := vclib.GetPathFromVMDiskPath(diskManager.diskPath); datastore.Exists(ctx, dsPath) { klog.V(2).Infof("Create: VirtualDisk already exists, returning success. Name=%q", diskManager.diskPath) return diskManager.diskPath, nil } </ins> // Create specification for new virtual disk <ins> diskFormat := vclib.DiskFormatValidType[diskManager.volumeOptions.DiskFormat] </ins> vmDiskSpec := &types.FileBackedVirtualDiskSpec{ VirtualDiskSpec: types.VirtualDiskSpec{ AdapterType: diskManager.volumeOptions.SCSIControllerType,

}, CapacityKb: int64(diskManager.volumeOptions.CapacityKB), } <ins> vdm := object.NewVirtualDiskManager(datastore.Client()) </ins> requestTime := time.Now() // Create virtual disk task, err := vdm.CreateVirtualDisk(ctx, diskManager.diskPath, datastore.Datacenter.Datacenter, vmDiskSpec)
Change:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Check Anything else we need to know: /cc /cc /sig cli /sig network /sig api-machinery /sig windows /priority critical-urgent /milestone v1.17
The label(s) cannot be applied. These labels are supported: <detailsIn response to : Which jobs are failing: Since when has it been failing: Testgrid link: Example: /cc /cc /sig network /sig api-machinery] /sig windows /milestone v1.17 </details
The label(s) cannot be applied. These labels are supported: <detailsIn response to : Which jobs are failing: Since when has it been failing: Testgrid link: Check /cc /cc /sig network /sig api-machinery] /sig windows /milestone v1.17 </details
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
The following have been fixed: For the DNS + Services tests, the issue is caused by: Bug report here: Disabling EndpointSlice feature-gate on kube-proxy should be enough to get them green again.
/cc
is back to just the guestbook test being solid red (tracked in ) 17 should green up similarly (was just fast-forwarded this morning)
This seems resolved. can we close this?
/close
Closing this issue. <detailsIn response to : /close 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

Discussion:
return } <ins> request := fmt.Sprintf("register?host=%s", getIP(hostPort).String()) log.Printf("Registering to master: %s/%s", hostPort, request) </ins> start := time.Now() for time.Since(start) < timeout { <del> response, err := dialHTTP("register", hostPort) </del> <ins> response, err := dialHTTP(request, hostPort) </ins> if err != nil { log.Printf("encountered error while registering to master: %v. Retrying in 1 second.", err) time.Sleep(sleep)

// registerHandler will register the caller in this server's list of slaves. // /set requests will be propagated to slaves, if any. func registerHandler(w http.ResponseWriter, r *http.Request) { <del> ip, _, err := net.SplitHostPort(r.RemoteAddr) </del> <ins> values, err := url.Parse(r.URL.RequestURI()) </ins> if err != nil { <del> fmt.Fprintf(w, "userip: %q is not IP:port", r.RemoteAddr) </del> <ins> http.Error(w, fmt.Sprintf("%v", err), http.StatusBadRequest) </ins> return } <del> log.Printf("GET /register, IP: %s", ip) </del> <ins> ip := values.Query().Get("host") log.Printf("GET /register?host=%s", ip) </ins> // send all the store to the slave as well. output := make(map[string]interface{})

} return client } <ins> func getIP(hostPort string) net.IP { conn, err := net.Dial("udp", hostPort) if err != nil { log.Fatal(err) } defer conn.Close() localAddr := conn.LocalAddr().(*net.UDPAddr) return localAddr.IP } </ins>
Change:
The regression is caused by two changes: Changes in reflector () which results in issuing LIST with RV="" (meaning it will go to etcd) on WATCH restarts caused by 410 (RV too old) errors Enabling EndpointSlice API without bumping the cache size for EndpointSlices (will be fixed in ). The default cache size is 100, which is not enough for resources that can change as rapidly as EndpointSlice (to compare cache size for Endpoints, which EndpointSlices is replacing, was 10* # nodes), which results in WATCHes being terminated with 410 and then issuing heavy LISTs to restart them (see above). If you take into account that this happens on each node (kube-proxy is watching EndpointSlices) the burst in heavy LIST can effectively kill control-plane which we observe in scale tests. Below the graphs showing exactly this situation in kubemark-5K test (last two runs failed in exactly the same way): ! ! We hope that will fix the issue and make our tests passing. We're currently running the tests manually to confirm that. /sig scalability /milestone v1.17
/priority critical-urgent This is a release blocker

Discussion:
watchCacheSizes := make(map[schema.GroupResource]int) watchCacheSizes[schema.GroupResource{Resource: "replicationcontrollers"}] = maxInt(5*clusterSize, 100) watchCacheSizes[schema.GroupResource{Resource: "endpoints"}] = maxInt(10*clusterSize, 1000) <ins> watchCacheSizes[schema.GroupResource{Resource: "endpointslices", Group: "discovery.k8s.io"}] = maxInt(10*clusterSize, 1000) </ins> watchCacheSizes[schema.GroupResource{Resource: "nodes"}] = maxInt(5*clusterSize, 1000) watchCacheSizes[schema.GroupResource{Resource: "pods"}] = maxInt(50*clusterSize, 1000) watchCacheSizes[schema.GroupResource{Resource: "services"}] = maxInt(5*clusterSize, 1000)
Change:
<!-- 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: Regression in 1.17 introduced by When there are several items passed using KUBECTLEXTRAPRUNE_WHITELIST flag, cluster/addons/addon-manager/kube- generates wrong flags for kubectl: Which causes: What you expected to happen: It should generate: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig release Environment: Kubernetes version (use ): 1.17.*
/assign
- FYI This seems like a regression in 1.17, so we should merge fix in 1.17.
cc for shellcheck-induced regressions
This happens because we don't have an "API" documented for these environment variables. Ideally we should not be depending on space splitting strings.
Not yet fixed for 1.17 /reopen
Reopened this issue. <detailsIn response to : Not yet fixed for 1.17 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

Discussion:
# besides the default ones. extra_prune_whitelist= if [ -n "${KUBECTL_EXTRA_PRUNE_WHITELIST:-}" ]; then <del> extra_prune_whitelist=( "${KUBECTL_EXTRA_PRUNE_WHITELIST:-}" ) </del> <ins> read -ra extra_prune_whitelist <<< "${KUBECTL_EXTRA_PRUNE_WHITELIST}" </ins> fi prune_whitelist=( "${KUBECTL_PRUNE_WHITELIST[@]}"  "${extra_prune_whitelist[@]}" ) prune_whitelist_flags=$(generate_prune_whitelist_flags "${prune_whitelist[@]}")
Change:
After this () has been merged and EnpointSlice feature is now enabled by default, we noticed Kube-proxy will not work on Windows. Only message I can see in the logs is: /sig windows
/cc /cc /cc
How about separating the above check into two if statements so that the log can pinpoint which field is false ?
It seems long term, EndpointSlice support should be so that is kept in sync with other implementations.
cc
Thanks for reporting this! Windows proxiers were still intended to be reading from Endpoints, but apparently that's not working as intended. EndpointSlices are moving back to disabled by default for 1.17, so that should fix the failing tests for now. I'll work on an actual fix for this as well, but it may not make it in until after KubeCon. /assign /sig network /priority important-soon
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
/assign cc
GitHub didn't allow me to assign the following users: jocelynberrendonner. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign cc Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
: Please let me know if you need any help on the fix! I'll be more than happy to review/help test the fix on Windows.

Discussion:
serviceConfig.RegisterEventHandler(s.Proxier) go serviceConfig.Run(wait.NeverStop) <del> if utilfeature.DefaultFeatureGate.Enabled(features.EndpointSlice) { </del> <ins> if s.UseEndpointSlices { </ins> endpointSliceConfig := config.NewEndpointSliceConfig(informerFactory.Discovery().V1beta1().EndpointSlices(), s.ConfigSyncPeriod) endpointSliceConfig.RegisterEventHandler(s.Proxier) go endpointSliceConfig.Run(wait.NeverStop)

OOMScoreAdj:            config.OOMScoreAdj, ConfigSyncPeriod:       config.ConfigSyncPeriod.Duration, HealthzServer:          healthzServer, <ins> UseEndpointSlices:      utilfeature.DefaultFeatureGate.Enabled(features.EndpointSlice), </ins> }, nil }

OOMScoreAdj:        config.OOMScoreAdj, ConfigSyncPeriod:   config.ConfigSyncPeriod.Duration, HealthzServer:      healthzServer, <ins> UseEndpointSlices:  false, </ins> }, nil }
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : currently this create file share action is also considered as data-path operation that's the reason why it failed since create file share action happens on master node which is not in selected network, in the future, this action will not be handled as data-path operation. as confirmed by azure file team, api-version supports this functionality, need to upgrade the api-version: Why is this needed: /assign /kind bug /priority important-soon /sig cloud-provider /area provider/azure
related issue:
Are you already working on this? If not, I was wondering if I can pick it up.
yes, it's half done already. actually the code change is already in my dev machine, let it send it out.
ok, sounds good!
/reopen since it's not fixed
Reopened this issue. <detailsIn response to : /reopen since it's not fixed 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
/reopen

Discussion:
import ( "context" "fmt" <ins> "net/http" "strings" </ins> "github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2019-06-01/storage"

// CreateFileShare creates a file share func (c *Client) CreateFileShare(resourceGroupName, accountName, name string, sizeGiB int) error { <ins> result, err := c.GetFileShare(resourceGroupName, accountName, name) if err == nil { klog.V(2).Infof("file share(%s) under account(%s) rg(%s) already exists", name, accountName, resourceGroupName) return nil } else if err != nil && result.Response.StatusCode != http.StatusNotFound && !strings.Contains(err.Error(), "ShareNotFound") { return fmt.Errorf("failed to get file share(%s), err: %v", name, err) } </ins> quota := int32(sizeGiB) fileShare := storage.FileShare{ Name: &name,

ShareQuota: &quota, }, } <del> _, err := c.fileSharesClient.Create(context.Background(), resourceGroupName, accountName, name, fileShare) </del> <ins> _, err = c.fileSharesClient.Create(context.Background(), resourceGroupName, accountName, name, fileShare) </ins> return err }
Change:
What happened: If doesn't exist in $KUBEROOT/output/release-tars, the script doesn't prompt for downloading from external release URL, but just move on util an error is thrown instead. What you expected to happen: If the tarball does not exist, it should be able to download from external release URL. How to reproduce it (as minimally and precisely as possible): remove the tarball from $KUBEROOT/output/release-tars run Anything else we need to know?: The script has everything there, but there is a minor issue has caused the script move on silently after the close the child function. Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
tagging with the appropriate sigs, but please mind that kube-up is deprecated and should not be used in the wild. please move to a different tool for cluster creation, like kubeadm, kops, minikube, kind, cluster-api etc. /sig cluster-lifecycle testing

Discussion:
#   KUBE_MANIFESTS_TAR function find-release-tars() { SERVER_BINARY_TAR=$(find-tar kubernetes-server-linux-amd64.tar.gz) <ins> if [[ -z "${SERVER_BINARY_TAR}" ]]; then exit 1 fi </ins> if [[ "${NUM_WINDOWS_NODES}" -gt "0" ]]; then NODE_BINARY_TAR=$(find-tar kubernetes-node-windows-amd64.tar.gz) fi
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-cos-master-alpha-features Which test(s) are failing: [sig-network] Networking should recreate its iptables rules if they are deleted [Disruptive] Since when has it been failing: as far as testgrid can see, since forever, it's like ... 10% flake Testgrid link: Reason for failure: Anything else we need to know: /cc /sig network /priority important-soon /milestone v1.17
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
FTR, I'm pretty sure that the feature is working fine and it's only the test that is broken. The kubelet logs (eg, ) show that it is noticing the deleted chains and reloading: I1119 10:56:23. 1325 ] iptables canary mangle/KUBE-KUBELET-CANARY deleted I1119 10:56:23. 1325 ] Reloading after iptables flush And if it failed to recreate any of the rules, it would log errors about it: if _, err := kl.iptClient.EnsureRule(utiliptables.Append, utiliptables.TableNAT, KubeMarkDropChain, "-j", "MARK", "--set-xmark", dropMark); err != nil { klog.Errorf("Failed to ensure marking rule for %v: %v", KubeMarkDropChain, err) return } and we don't see those errors in the logs. So I think there's just a bug in the test case. Trying to reproduce now in a debug PR...
my apologies, this is the cause of the flakiness The test tries to find the KUBE-MARK-DROP rule but kube-proxy deletes the rule because we are not recreating it as we are doing with the KUBE-MARK-MASK Since is only needed for kube-proxy with dual stack in iptables mode and that PR is not merged we can revert it. The other option is making the the chains in kubelet and kube-proxy different

Discussion:
writeLine(proxier.filterChains, utiliptables.MakeChainLine(chainName)) } } <del> for _, chainName := range []utiliptables.Chain{kubeServicesChain, kubeNodePortsChain, kubePostroutingChain, KubeMarkMasqChain, KubeMarkDropChain} { </del> <ins> for _, chainName := range []utiliptables.Chain{kubeServicesChain, kubeNodePortsChain, kubePostroutingChain, KubeMarkMasqChain} { </ins> if chain, ok := existingNATChains[chainName]; ok { writeBytesLine(proxier.natChains, chain) } else {

:KUBE-NODEPORTS - [0:0] :KUBE-POSTROUTING - [0:0] :KUBE-MARK-MASQ - [0:0] <del> :KUBE-MARK-DROP - [0:0] </del> :KUBE-SVC-AHZNAGK3SCETOS2T - [0:0] :KUBE-SEP-PXD6POUVGD2I37UY - [0:0] :KUBE-SEP-SOKZUIT7SCEVIP33 - [0:0]
Change:
What happened: I used dual-stack and set the parameter of kube-controller to --node-cidr-mask-size-ipv4=24 --node-cidr-mask-size-ipv6=96, but the podCidr my node got was still a /64 mask What you expected to happen: The mask the node gets should be the /96 I set How to reproduce it (as minimally and precisely as possible): Deploy the cluster using kubeadm, which is configured as followsAnd modify the network-plugin of kubelet to be kubenet Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: KVM virtual machine OS (e.g: ): VERSION="18.04.2 LTS (Bionic Beaver)" Kernel (e.g. ): Linux k8s02-01 4.15.0-70-generic -Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
is the configuration above correct? should be using integers instead of strings to configure the node-cidr-masks? Ref.
I initially tried using integers, but kubeadm init reported an error.That's why I replaced it with a string, and then I didn't get an error
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
thank you for reporting this. I'll take a look.
/assign

Discussion:
} cfg.NodeCIDRMaskSize = o.NodeCIDRMaskSize <ins> cfg.NodeCIDRMaskSizeIPv4 = o.NodeCIDRMaskSizeIPv4 cfg.NodeCIDRMaskSizeIPv6 = o.NodeCIDRMaskSizeIPv6 </ins> return nil }