jiebi/CodeConvo huggingface dataset:
Change:
// VirtualMachinesClient defines needed functions for azure compute.VirtualMachinesClient type VirtualMachinesClient interface { CreateOrUpdate(ctx context.Context, resourceGroupName string, VMName string, parameters compute.VirtualMachine, source string) (resp *http.Response, err error) <ins> Update(ctx context.Context, resourceGroupName string, VMName string, parameters compute.VirtualMachineUpdate, source string) (resp *http.Response, err error) </ins> Get(ctx context.Context, resourceGroupName string, VMName string, expand compute.InstanceViewTypes) (result compute.VirtualMachine, err error) List(ctx context.Context, resourceGroupName string) (result []compute.VirtualMachine, err error) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Instead of using the VM CreateOrUpdate () function of the Azure Go SDK, use the VM Update function () in the azureclient () Why is this needed: Currently, the Azure Cloud Provider is using the VM CreateOrUpdate call when e.g. detach/attaching disks to a VM. In some scenarios, this will re-create a VM that was deleted by an external application. This can lead to orphaned VMs or blocked resources. The Update function will only update an existing VM and will fail if the VM does not exist.
/sig azure
/assign
/sig cloud-provider
Could you describe more about the scenarios? Have you noticed such issues? I wonder adding etags to the API call could help to prevent this?
If you have an application that maintains your K8s clusters, e.g. takes care of OS update/patching. If the application wants to patch the OS of a worker node, it would drain the node first. If draining times out, it will go ahead and delete the VM anyway. But K8s might still be detaching disks. These detach operations, because they use CreateOrUpdate, will recreate the VM. Is there a reason why you would want to create a VM i.e. why CreateOrUpdate is required and Update would not work? AFAIK, Azure Compute RP does not support etags.
that sounds reasonable, thanks change to use function would be safer since it's only detach/attach disk operation. I will do that.
thanks for the information. Reasonable enough. /assign
/milestone v1.16
BTW, the reason why we only use func in the beginning is that Azure Compute go sdk did not provide a func at that time...
Great. Thanks!
Change:
- linters: - ginkgolinter text: use a function call in (Eventually|Consistently) <ins> # SSA Extract calls are allowed in tests. - linters: - forbidigo text: should not be used because managedFields was removed path: _test.go$ </ins> linters: disable-all: false # in contrast to golangci.yaml, the default set of linters remains enabled enable: # please keep this alphabetized and in sync with golangci.yaml <ins> - forbidigo </ins> - ginkgolinter - gocritic - govet

Discussion:
Add a code static check for to report using server-side-apply extract With optimization of and , the will be removed in and , and maybe more of other components in the future, using Extract is problematic. It's safer to add this lint check.
/cc
/sig api-machinery
/sig scheduling /sig apps
/assign /triage accepted
Change:
} } else { klog.V(2).Infof("azureDisk - attach disk(%s) succeeded", diskName) <del> // Invalidate the cache right after updating key := buildVmssCacheKey(nodeResourceGroup, ss.makeVmssVMName(ssName, instanceID)) ss.vmssVMCache.Delete(key) </del> } return err }

Discussion:
What happened: Azure Disks get randomly mounted in a way that makes them unusable, returning for every disk I/O operation. Affected Pods remain in until someone manually recreates them. What you expected to happen: Azure Disks are consistently usable by Pods inside which they are mounted. How to reproduce it: Create the following StatefulSet. Adjust the replicas and delete the associated Pods () until the problem occurs (i.e. some Pod ends up in ). <details</summary</details</brDefault StorageClass (as created by ACS-Engine): <details</summary</details</brAnything else we need to know?: Nodes were updated from 1.10.4 to 1.10.10, then from 1.10.10 to without a reboot. According to written by the issue is fixed, but I can still observe it quite often. Ref Azure/acs-engine Environment: Kubernetes version: v1.10.10 + Cloud provider or hardware configuration: Azure (westeurope) OS: Ubuntu 16.04.4 LTS Kernel: 4.13.0-1018-azure Install tools: ACS-Engine Others: /kind bug /sig storage /sig azure
In my current test environment: (pod uid is -f23b-11e8-bf38-) on the node Notice the mismatch between the disk referenced by lun0 () and the actual mount (). on the node
After deleting the failing Pod and waiting for its successful recreation: (pod uid is now -f247-11e8-bf38-) on the node This time disks are matching (). on the node
/assign
Change:
clientConfig.QPS = float32(s.KubeAPIQPS) clientConfig.Burst = int(s.KubeAPIBurst) <del> addChaosToClientConfig(s, clientConfig) </del> return clientConfig, nil } <del> // addChaosToClientConfig injects random errors into client connections if configured. func addChaosToClientConfig(s *options.KubeletServer, config *restclient.Config) { if s.ChaosChance != 0.0 { config.WrapTransport = func(rt http.RoundTripper) http.RoundTripper { seed := chaosclient.NewSeed(1) // TODO: introduce a standard chaos package with more tunables - this is just a proof of concept // TODO: introduce random latency and stalls return chaosclient.NewChaosRoundTripper(rt, chaosclient.LogChaos, seed.P(s.ChaosChance, chaosclient.ErrSimulatedConnectionResetByPeer)) } } } </del> // RunKubelet is responsible for setting up and running a kubelet.  It is used in three different applications: //   1 Integration tests //   2 Kubelet binary

Discussion:
/kind bug /sig release Such as:
Cool issue. /assign
I see the code in was pushed by you. I don't understand what Intercept() does. Do you think there is an Infinite recursive call?
Chaos client isn’t used anywhere, and we need to remove it soon.
Ok, I can help remove it.
But there are also one place using it. How to deal with it? Delete it directly? Or something we need to do?
Has never been anything other than experimental and was not used in practice. We can remove it and it’s flag from kubelet as it was experimental. are we deprecating experimental flags for one release or can we just remove?
Change:
} attachment, err := disk.waitForAttachmentStatus("attached") if err != nil { <ins> if err == wait.ErrWaitTimeout { c.applyUnSchedulableTaint(nodeName, "Volume stuck in attaching state - node needs reboot to fix impaired state.") } </ins> return "", err }

Discussion:
On AWS when we call "attach" of a volume then we periodically we check (via API call) if volume has indeed been attached. We run the check in a loop with timeout of 21 minutes. AWS documents that - if a volume is stuck in "attaching" state for too long, the node where volume is being attached is in "dirty" state and must be rebooted to fix the problem. Until node is rebooted, more pods with volumes to same node is only going be stuck in same state (i.e "attaching"). We propose that - if attach operation times out waiting for volume in "attaching" state, we should simply taint the node so as it can not affect other pods and a admin can manually fix the node. /sig aws /sig storage cc
Change:
{ name: "small mask IPv4", cidr: "192.168.1.1/28", <ins> want: 0, }, { name: "small mask IPv4", cidr: "192.168.1.1/27", </ins> want: 16, }, { name: "small mask IPv6", <ins> cidr: "fd00::1/124", want: 0, }, { name: "small mask IPv6", </ins> cidr: "fd00::1/122", want: 16, },

Discussion:
kube-apiserver observed a panic: kube-apiserver should not panic Not sure yet -- will add more details as I investigate. No response v1.25.4 N/A N/A N/A N/A N/A
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 network /cc
max is greater than offset?
/assign
Change:
"k8s.io/utils/clock" flowcontrol "k8s.io/api/flowcontrol/v1beta2" <del> flowcontrolapplyconfiguration "k8s.io/client-go/applyconfigurations/flowcontrol/v1beta2" </del> flowcontrolclient "k8s.io/client-go/kubernetes/typed/flowcontrol/v1beta2" flowcontrollister "k8s.io/client-go/listers/flowcontrol/v1beta2" )

Discussion:
A lot of different routines failing just when setting up an apiserver. Example: <details</detailsNo errors The test still passes, but those errors seem very worrisome <detailsmaster </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery /sig testing cc
yeah, the framework has some long standing tech debt /cc
all the panics I see are:
looks like again, due to
Looks like some integration tests must not be enabling SSA.
yeah, a lot don't, because it requires openapi, which also isn't universally enabled in integration. it is really expensive at API server startup, and when we tried enabling it universally in integration it blew up runtimes and integration timed out super frequently
that's what is still open for
/triage accepted
Change:
if err == nil { t.Fatal("expected error with json: prefix, got no error") } <del> if !strings.HasPrefix(err.Error(), "json: line 3:") { t.Fatalf("expected %q to have 'json: line 3:' prefix", err.Error()) </del> <ins> const msg = `json: offset 28: invalid character '"' after object key:value pair` if msg != err.Error() { t.Fatalf("expected %q, got %q", msg, err.Error()) </ins> } }

Discussion:
This bug was privately disclosed and told to open here. What happened: NewYAMLOrJSONDecoder from has an index out of bounds issue which can cause callers to panic. Download attached reproducer file Run golang test: When run with v0.19.3: Additionally, this can be seen in kubectl directly (below is kubectl 1.20.0): Environment: Kubernetes version (use ): Verified with 1.19, 1.20
/sig api-machinery
This piece attempts to find line+column position of a json syntax error. To do that it assumes that full input is available which is not true: is : is only the first data chunk: The subject happens e.g. when syntax error offset is past buffer size and Test to reproduce the panic: I am not sure it is easily possible to find line+column of json syntax error as full input may not be available. Maybe it should only attempt to find line+column if offset is within the first chunk (i.e. below buffer size).
Line number calculation in and updated in
do you want to submit a patch to with a defensive check to avoid the panic ( compare and )
I have raised a discussion on having line number in the . The consensus there is that it should be possible to count lines with a full input at hand and it does not worth to have it in the core library due to performance impact and maintenance costs. The problem of here is that it attempts to find out line number without having full input at hand. I think the defensive patch is not the right approach because line calculation is incorrect anyway even when there is no panic: begins at a value with a syntax error, i.e. in a stream of two values and syntax error in the second value it would contain only the second value and thus new lines in the first value in the stream would not be counted. I think the following options are there: to stream taken from . This is straightforward but changes interface. I can not find any code that uses field, it is only used in the error message that would change: line number only if offset is within the length of the first data chunk (). I am not sure what would be the unknown line number then, perhaps. line number properly during stream decoding, see This has some performance penalty as line number is calculated in any case even if there is no syntax error, i.e.

in the majority of the cases.
cc /triage accepted
This is probably acceptable.
I have opened a PR
Thank you for support.
Change:
// Annotation sets a {k,v} pair to the inner pod annotation. func (p *PodWrapper) Annotation(key, value string) *PodWrapper { <del> if p.ObjectMeta.Annotations == nil { p.ObjectMeta.Annotations = make(map[string]string) } p.ObjectMeta.Annotations[key] = value </del> <ins> metav1.SetMetaDataAnnotation(&p.ObjectMeta, key, value) </ins> return p }

Discussion:
We need an integration test for the scheduler enforcement of the alpha feature. This is required for beta graduation; we need to collect signal on the current behavior before we can proceed. See this comment for context:
/sig storage /sig scheduler
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
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig storage /sig scheduler 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
/sig scheduling
Change:
// recommended as one of the prime benefits of exec plugins is that no secrets need // to be stored directly in the kubeconfig. // +k8s:conversion-gen=false <del> Config runtime.Object </del> <ins> Config runtime.Object `json:"-"` </ins> // InteractiveMode determines this plugin's relationship with standard input. Valid // values are "Never" (this exec plugin never uses standard input), "IfAvailable" (this

Discussion:
yaml.Marshal a kubeconfig, as done in the example tests here LocationOfOrigin is not seen in output, as comment says "never serialized." Click "run example" doesn't suffer from this as it does some conversion <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
/assign /triage accepted
is what's known as internal type. It is not intended to be serialized by code. The serialization version is in and does not have this field. I could get behind removing all json tags from the internal version, but I wouldn't refine tags that shouldn't be used.
Change:
"fmt" "time" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/kubernetes/pkg/api/v1"

Discussion:
The merge queue is green with RBAC enabled, and the replicaset controller was missing permission to patch pods until fixed in Pod adoption and release depend on patching pods, which means that there are no merge-queue-blocking tests that test these features. Given that they are complex and rarely tested manually, we need tests that run as part of the merge queue to ensure they function correctly.
I'd like to work on this, where should the tests be ? I see that there are some patch-related tests for the replicaset controller in , and, according to http://submit-, the integration tests are run as part of the merge queue, is that correct? Thanks!
I think we'd want an e2e test that drives behavior externally on a normal cluster (by creating a replicaset, waiting to observe expected pods, modifies replicaset, waits to observe expected results, etc) . many of the integration tests tend to start up fake servers that don't share much in common with real deployments.
Ok thanks, on it.
cc:
Change:
/var/cache/docker-install/{{ override_deb }}: file.managed: <del> - source: {{ storage_base }}{{ override_deb }} </del> <ins> - source: {{ override_deb_url }} </ins> - source_hash: sha1={{ override_deb_sha1 }} - user: root - group: root

Discussion:
GCE updated docker, but only via a base-image update. AWS should match versions of docker, to slipstream off all the testing that GCE gets. This will be slightly complicated because docker 1.8.3 isn't in the bucket AFAICT. Thanks to for the tip.
This is done by
Change:
spec: containers: - name: netexec <del> image: gcr.io/kubernetes-e2e-test-images/netexec-amd64:1.0 </del> <ins> image: gcr.io/kubernetes-e2e-test-images/netexec-amd64:1.1 </ins> ports: - containerPort: 8080 protocol: TCP

Discussion:
/kind bug /sig release when we use , we must make sure xxx is not nil. So before we use it, we should check err value first. Such as:
I think even if the file is nil , maybe It doesn't matter
Sometimes it does matter, while can't handle nil correctly. Maybe it is just a good practise.
Although File.Close() can handle cases like this, serverConn.Close() will cause panic to happen. Anyway, these are bugs that exist. /assign
Change:
{" 100-200 ", true, "100-200", 200, 201}, {"0-0", true, "0-0", 0, 1}, {"", true, "", -1, 0}, <del> {"100", false, "", -1, -1}, </del> <ins> {"100", true, "100-100", 100, 101}, </ins> {"100 - 200", false, "", -1, -1}, {"-100", false, "", -1, -1}, {"100-", false, "", -1, -1}, {"200-100", false, "", -1, -1}, {"60000-70000", false, "", -1, -1}, {"70000-80000", false, "", -1, -1}, <ins> {"70000+80000", false, "", -1, -1}, {"1+0", true, "1-1", 1, 2}, {"0+0", true, "0-0", 0, 1}, {"1+-1", false, "", -1, -1}, {"1-+1", false, "", -1, -1}, {"100+200", true, "100-300", 300, 301}, {"1+65535", false, "", -1, -1}, {"0+65535", true, "0-65535", 65535, 65536}, </ins> } for i := range testCases {

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: Implement this TODO: What you expected to happen: Start kube-proxy with a 'beginPort+offset' format port range configuration. This is needed when I want to allocate specific numbers of port from a host without extra manual calculation. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
/sig network Does anyone besides kube-proxy use this?
/assign
Change:
"//staging/src/k8s.io/api/policy/v1beta1:go_default_library", "//staging/src/k8s.io/api/rbac/v1:go_default_library", "//staging/src/k8s.io/api/rbac/v1beta1:go_default_library", <del> "//staging/src/k8s.io/api/scheduling/v1alpha1:go_default_library", </del> <ins> "//staging/src/k8s.io/api/scheduling/v1beta1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/meta:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library",

Discussion:
/kind bug What happened: When I try to create a priorityclass object like: It fails with And when I try create it with yaml file like: It works. What you expected to happen: Create a priorityclass object with kubectl.
/sig cli
Do you have --runtime- set in kube-apiserver?
No, if set this, it works.
Agree this is a bug. v1beta1 should be preferred.
/sig scheduling
Change:
framework.ExpectNoError(results.ExitsBefore(init1, restartableInit1)) }) <del> ginkgo.It("should start first restartable init container before starting second init container", func() { framework.ExpectNoError(results.StartsBefore(restartableInit1, init2)) }) </del> ginkgo.It("should run first init container and first restartable init container together", func() { <del> framework.ExpectNoError(results.RunTogether(restartableInit1, init2)) </del> <ins> framework.ExpectNoError(results.RunTogetherLhsFirst(restartableInit1, init2)) </ins> }) ginkgo.It("should run second init container to completion before starting second restartable init container", func() {

Discussion:
master-blocking: ci-node-e2e Recent failures: No response /sig node
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
is also similar. The fix for that was bumping the delay time.
Hi Vyom - would this be a good first issue because there is a previous similar solution?
I hit the same failure in my . This seems caused because expects the regular container to start before the postStart: I posted a PR() to add to the postStart. However, there are other approaches such as: Introduce as mentioned . Remove from this test case because this check does not look the primary purpose of this testcase.
The test mentioned by is similar to this flake and doesn't use . I can just remove it. I'm also going to add a comment on RunTogether to indicate it expects ordering to be enforced. That being said, shouldn't PostStart be enforced to run after the container is started? /assign
Hey PRs are more than welcome :)
I've submitted the PR, let me know if I didn't follow any best practices or anything else is required, thanks!
Skipped after was merged. Last CI run passed. /close
Closing this issue. <detailsIn response to : Skipped after was merged. Last CI run passed. </details
/reopen close the wrong one: is closed for swap test skip. this is for another flake. Sorry.
Reopened this issue. <detailsIn response to : /reopen close the wrong one: is closed for swap test skip. this is for another flake. Sorry. 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
Change:
# Well known tags TAG_KEY_MASTER_IP="kubernetes.io/master-ip" <ins> OS_DISTRIBUTION=${KUBE_OS_DISTRIBUTION} </ins> # Defaults: ubuntu -> wily <del> if [[ "${KUBE_OS_DISTRIBUTION}" == "ubuntu" ]]; then KUBE_OS_DISTRIBUTION=wily </del> <ins> if [[ "${OS_DISTRIBUTION}" == "ubuntu" ]]; then OS_DISTRIBUTION=wily </ins> fi <del> # For GCE script compatibility OS_DISTRIBUTION=${KUBE_OS_DISTRIBUTION} case "${KUBE_OS_DISTRIBUTION}" in trusty|wheezy|jessie|vivid|wily|coreos) source "${KUBE_ROOT}/cluster/aws/${KUBE_OS_DISTRIBUTION}/util.sh" </del> <ins> # Loads the distro-specific utils script. # If the distro is not recommended, prints warnings or exits. function load_distro_utils () { case "${OS_DISTRIBUTION}" in jessie) ;; wily) ;; vivid) echo "vivid is currently end-of-life and does not get updates." >&2 echo "Please consider using wily or jessie instead" >&2 echo "(will continue in 10 seconds)" >&2 sleep 10 ;; coreos) echo "coreos is no longer supported by kube-up; please use jessie instead" >&2 exit 2 ;; trusty) echo "trusty is no longer supported by kube-up; please use jessie or wily instead" >&2 exit 2 ;; wheezy) echo "wheezy is no longer supported by kube-up; please use jessie instead" >&2 exit 2 </ins> ;; *) <del> echo "Cannot start cluster using os distro: ${KUBE_OS_DISTRIBUTION}" >&2 </del> <ins> echo "Cannot start cluster using os distro: ${OS_DISTRIBUTION}" >&2 echo "The current recommended distro is jessie" >&2 </ins> exit 2 ;; esac <ins> source "${KUBE_ROOT}/cluster/aws/${OS_DISTRIBUTION}/util.sh" } load_distro_utils </ins> # This removes the final character in bash (somehow) AWS_REGION=${ZONE%?}

Discussion:
If e.g. coreos doesn't work with kube-up, we should point users to an installation method that works. Also consider offering hints like "vivid no longer gets security updates, consider using wily or official"