jiebi/CodeConvo huggingface dataset:
Code change:
// Not local instance, get addresses from Azure ARM API. if !isLocalInstance { <del> return addressGetter(name) </del> <ins> if az.vmSet != nil { return addressGetter(name) } // vmSet == nil indicates credentials are not provided. return nil, fmt.Errorf("no credentials provided for Azure cloud provider") </ins> } if len(metadata.Network.Interface) == 0 {

Related discussion:
text: Currently there is no way to run without any identity (be it service principal or E/MSI). In reality code running on a worker node can use via - and only via - without the need to access ARM. Here is the proposed change a new mode authN = this mode, is basically telling the cloud provider to work any identity, this means only IMDS calls is allowed. This mode can be detected from if no SPN set and both MSI settings are set to . to use a config map within the cluster. This config map can be loaded on the cluster statically. or created - if not existent - in that then only is used in The net new result of the above is users bootstrapping clusters can configure the worker node to use without any identity on said worker nodes.
/sig azure These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by ‍
In-tree AzureDisk volume plugin is also depending on Azure credential to fetch lun id. we should figure out how to solve it without credential
fetch disk lun id is also a dependency in kubelet code now, after my investigation, it could be removed on Linux node, while it cannot be removed on Windows node, need to change the k/k upstream code, there is a discussion on going here: , let' wait for the discussion result.
For Linux: 1- use IMDS my understanding is new api versions will have the disk/lun pairs. 2- don't use arm for the return of is the second parameter passed to . For Windows: I don't understand the dep on ARM for this. The above still apply, we just need to find a way to encode the value as ut return from that allow us to find the disk by on a windows machine. might be a good source for this. Ideally speaking. The value should be the same. But i will leave it for you to decide.
could be a good idea since currently it's a LUN num returned by Attach() and then it could be changed to the windows disk num, I will make the code change on v1.15 later, thanks for discussion.
Update: PR would remove the VM API calls when getting the LUN number for AzureDisk.
Code change:
*out = new(PluginSet) (*in).DeepCopyInto(*out) } <del> if in.NormalizeScore != nil { in, out := &in.NormalizeScore, &out.NormalizeScore *out = new(PluginSet) (*in).DeepCopyInto(*out) } </del> if in.Reserve != nil { in, out := &in.Reserve, &out.Reserve *out = new(PluginSet)

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Consolidate ) into Score plugin set in config API. Why is this needed: NormalizeScore extension point is implemented in . We decided to treat NormalizeScore as an "optional" step of Score plugin, see . However, we deferred the removal of due to API review delays. Now that PR was merged. We can start the actual removal from the API and start the API review process. /sig scheduling
/assign
Code change:
return utilfile.FileExists(kubeletpath) } <ins> func (mounter *NsenterMounter) EvalHostSymlinks(pathname string) (string, error) { return mounter.ne.EvalSymlinks(pathname, true) } </ins> func (mounter *NsenterMounter) CleanSubPaths(podDir string, volumeName string) error { return doCleanSubPaths(mounter, podDir, volumeName) }

Related discussion:
text: /kind bug Using , if a block device is symlinked to the discovery directory e.g. , then MapVolume will fail with since the containerized kubelet cannot see the path on host. is mounted by containerized kubelet, so if before we try to map the device we set devicePath to the evaluation of symlink and end up with a devicePath of , containerized kubelet will see the device and successfully map the device. Are there any issues with this solution? This is on Kubernetes 1.10
/sig storage
ah yes containerized kubelet has many issues when dealing with symlinks. Check out Mounter.GetMode(), it calls a nsenter EvalSymlinks which should be able to do what you need. But actually, one thing to consider, is do you need to do the losetup on the host, or does inside the container work?
Yes it appears to work from inside the container, on the host I run which disappears after I delete the pod using the device. My understanding of running losetup in MapVolume is not that great but I suppose that as long as that /dev/loop0 is created we are fine. Thanks for the quick response, I'll create a PR using that function and tag you
Does it create it on the host or in the containerized kubelet? What happens when containerized kubelet is restarted? The purpose of losetup is to do "refcounting" on the block device to prevent possible naming collisions when devices are attached/detached under unhealthy conditions. Ie, if a device showed up as /dev/sdb and you gave that to a pod, and then for some reason it become unhealthy and disappeared (while the pod is still running), another device (maybe even another volume type) could get attached to the node and reuse /dev/sdb. Now the pod has access to a device it's not supposed to. With filesystem volumes, the refcounting is done with mount points, but for block device, loopback is the equivalent.
It is created on the host (and also visible in the container), and stays around through restart. I understand now, thank you.
Actually after I restart it becomes /vdb instead of /dev/vdb in the losetup output, idk what that is about.
Code change:
return utilfile.FileExists(kubeletpath) } <ins> func (mounter *NsenterMounter) EvalHostSymlinks(pathname string) (string, error) { return mounter.ne.EvalSymlinks(pathname, true) } </ins> func (mounter *NsenterMounter) CleanSubPaths(podDir string, volumeName string) error { return doCleanSubPaths(mounter, podDir, volumeName) }

Related discussion:
text: There is no such thing as /vdb and /dev/vdb is still intact of course. Seems inconsequential since it is disappearing after all pods using the device are deleted, i.e. it's still serving as a refcounter
Code change:
// Max amount of time to wait for the container runtime to come up. maxWaitForContainerRuntime = 30 * time.Second <ins> // Max amount of time to wait for node list/watch to initially sync maxWaitForAPIServerSync = 10 * time.Second </ins> // nodeStatusUpdateRetry specifies how many times kubelet retries when posting node status failed. nodeStatusUpdateRetry = 5

Related discussion:
text: What happened: A deployment is created that uses a after the cluster master is created but before the cluster worker nodes are fully initialized. During the initialization of the worker nodes, the nodes are temporarily available for scheduling without the necessary label to match the deployment's node selector. Depending on how long the nodes are available for scheduling without the necessary node labels for the deployment, the scheduler will start to spam with cluster with pods in status. This spamming stops once the worker nodes are fully initialized and the pods are scheduled successful. The exact timing of all of this is TBD. What you expected to happen: Pods in status are annoying and require manual cleanup. It would be preferred that the scheduler avoid this an simply issue warning events. How to reproduce it (as minimally and precisely as possible): See issue description. Anything else we need to know?: No. Environment: Kubernetes version (use ): 1.18.3 Cloud provider or hardware configuration: IBM Cloud Kubernetes Service OS (e.g: ): Ubuntu 18.04.4 LTS Kernel (e.g. ): 4.15.0-96-generic Install tools: Managed service install Network plugin and version (if this is a network-related bug): N/A Others: N/A
Related to and
/sig scheduling
by spamming are you referring to scheduler logs? also, why are the nodes not labelled from the get go?
Just to confirm, all the pods in question are still in Pending state, yes? If the pods are in pending state, all of them will get scheduled eventually once the nodes get their labels.
The pods are not in state. They are actually in state. The pods eventually get scheduled but we are left with anywhere from a few to dozens of these state pods. Also, we are looking at labeling the nodes via kubelet flags to see if that helps.
/remove-kind bug
After we add some retry logic and wait time in this problem can be solved: As you can see this function returns initial node as the first request failed.
I also get hit by this, when single controller node gets rebooted and scheduler starts as static container before kubelet becomes ready.
Code change:
// Max amount of time to wait for the container runtime to come up. maxWaitForContainerRuntime = 30 * time.Second <ins> // Max amount of time to wait for node list/watch to initially sync maxWaitForAPIServerSync = 10 * time.Second </ins> // nodeStatusUpdateRetry specifies how many times kubelet retries when posting node status failed. nodeStatusUpdateRetry = 5

Related discussion:
text: Can be cleaned up with:
/sig node
the spam cycle is this loop: "pod create, pod schedule, worker reject, pod failed" -- we don't have a lot of protection in higher level workload controllers to handle pods that fail at kubelet admission time versus pods that just dont create due to quota/admission. in general, is the spam causing any other stability issues? is pod gc pruning the pods?
I wonder if we can do a trick in node lister to mitigate any race condition here...
we could maybe do something similar to to ensure node lister has synced...
hacking on option to ensure if kubelet has a node lister with a valid kube client, we wait for it to sync at least once here which should mitigate this issue. see:
We noticed the problem on the OLM pod which is managed by the OLM operator. Right or wrong, the operator does not like seeing the pod go to status and no longer reconciles the pod. The end result is that manual intervention (i.e. pod deletion) is required to fix the problem.
sure... i would have thought the pod is failed in that instance and reached a terminal state. either way, i am looking at what i can do to mitigate this.
The problem persists in our environment as well, and the workaround cited above will not do anymore. Is there something in the works for this one?
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
Code change:
return true, nil } <del> // nextRotationDeadline returns a value for the threshold at which the // current certificate should be rotated, 80%+/-10% of the expiration of the // certificate. func (m *manager) nextRotationDeadline() time.Time { // forceRotation is not protected by locks if m.forceRotation { m.forceRotation = false return time.Now() } m.certAccessLock.RLock() defer m.certAccessLock.RUnlock() </del> <ins> // Check that the current certificate on disk satisfies the requests from the // current template. // // Note that extra items in the certificate's SAN or orgs that don't exist in // the template will not trigger a renewal. // // Requires certAccessLock to be locked. func (m *manager) certSatisfiesTemplateLocked() bool { </ins> if m.cert == nil { <del> return time.Now() </del> <ins> return false </ins> } <del> // Ensure the currently held certificate satisfies the requested subject CN and SANs </del> if template := m.getTemplate(); template != nil { if template.Subject.CommonName != m.cert.Leaf.Subject.CommonName { <del> glog.V(2).Infof("Current certificate CN (%s) does not match requested CN (%s), rotating now", m.cert.Leaf.Subject.CommonName, template.Subject.CommonName) return time.Now() </del> <ins> glog.V(2).Infof("Current certificate CN (%s) does not match requested CN (%s)", m.cert.Leaf.Subject.CommonName, template.Subject.CommonName) return false </ins> } currentDNSNames := sets.NewString(m.cert.Leaf.DNSNames...) desiredDNSNames := sets.NewString(template.DNSNames...) missingDNSNames := desiredDNSNames.Difference(currentDNSNames) if len(missingDNSNames) > 0 { <del> glog.V(2).Infof("Current certificate is missing requested DNS names %v, rotating now", missingDNSNames.List()) return time.Now() </del> <ins> glog.V(2).Infof("Current certificate is missing requested DNS names %v", missingDNSNames.List()) return false </ins> } currentIPs := sets.NewString()

Related discussion:
text: I'd love to see an integration test that would catch this (but that shouldn't block a fix).
Thanks for the comments! Now that I have the CLA signed, I'll address those and submit a PR.
Just submitted the PR:
Code change:
Create-Directories Download-HelperScripts <del> Install-LoggingAgent Configure-LoggingAgent Restart-LoggingAgent </del> <ins> # Even if Stackdriver is already installed, the function will still [re]start the service. if (IsLoggingEnabled $kube_env) { Install-LoggingAgent Configure-LoggingAgent Restart-LoggingAgent } </ins> Create-DockerRegistryKey Configure-Dockerd

Related discussion:
text: What happened: The stackdriver logging agent is installed and start running no matter logging is enabled/disabled in the cluster or not. What you expected to happen: Do not install and start the logging agent if logging is disabled.
/sig windows
cc
Code change:
BeforeEach(func() { podClient = f.PodClient() }) <del> // TODO: Fix Flaky issue #68066 and then re-add this back into Conformance Suite </del> /* <del> Release : v1.9 </del> <ins> Release : v1.15 </ins> Testname: Pods, delete grace period <del> Description: Create a pod, make sure it is running, create a watch to observe Pod creation. Create a 'kubectl local proxy', capture the port the proxy is listening. Using the http client send a ‘delete’ with gracePeriodSeconds=30. Pod SHOULD get deleted within 30 seconds. </del> <ins> Description: Create a pod, make sure it is running. Create a 'kubectl local proxy', capture the port the proxy is listening. Using the http client send a ‘delete’ with gracePeriodSeconds=30. Pod SHOULD get deleted within 30 seconds. </ins> */ <del> It("should be submitted and removed  [Flaky]", func() { </del> <ins> framework.ConformanceIt("should be submitted and removed", func() { </ins> By("creating the pod") name := "pod-submit-remove-" + string(uuid.NewUUID()) value := strconv.Itoa(time.Now().Nanosecond())

Related discussion:
text: We need to fix this potentially flaky test and add it back to conformance suite. Please see discussion in Also waiting on:
cc /sig testing
/area conformance
/cc
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
can we convert it to conformance now??
Once 1.15 opens up
Code change:
// ValidateCSINodeDrivers tests that the specified CSINodeDrivers have valid data. func validateCSINodeDrivers(drivers []storage.CSINodeDriver, fldPath *field.Path, validationOpts CSINodeValidationOptions) field.ErrorList { allErrs := field.ErrorList{} <del> driverNamesInSpecs := make(sets.String) </del> <ins> driverNamesInSpecs := sets.New[string]() </ins> for i, driver := range drivers { idxPath := fldPath.Index(i) allErrs = append(allErrs, validateCSINodeDriver(driver, driverNamesInSpecs, idxPath, validationOpts)...)

Related discussion:
text: It seems to be valid to add here. Would you like to open a pull request for it? this is like a cleanup, as the set insert will skip and the validation will do twice. is used to track bugs. I suggest you open a PR for that if you like.
/sig storage
I think adding ` == true and we didn't skip, it will insert set twice I believe? wasn't notice that at first glance. However, I can file a PR now
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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
/triage accepted
Please feel free to submit a PR.
Code change:
} func (a genericAccessor) SetAnnotations(annotations map[string]string) { <ins> if a.annotations == nil { emptyAnnotations := make(map[string]string) a.annotations = &emptyAnnotations } </ins> *a.annotations = annotations }

Related discussion:
text: When trying to edit multiple resources, for example: will panic. Ref as the possible cause cc
if was the cause, any fix needs to happen in 1.1 as well, was already cherry picked there
Also shows that we need a test for this case.
is the cause. When we edit multiple resources (i.e., list-type objects), the list's Accessor.annotations (type ) is nil and will panic when UpdateApplyAnnotation tries to SetAnnotations ().
Code change:
maxBackOffTolerance  = time.Duration(1.3 * float64(kubelet.MaxContainerBackOff)) podRetryPeriod       = 1 * time.Second podRetryTimeout      = 1 * time.Minute <ins> podReadyTimeout      = 1 * time.Minute </ins> ) // testHostIP tests that a pod gets a host IP

Related discussion:
text: [x] Original approval issue: - Reverted due to flakes [x] Two weeks soak end date: 20 November 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still some remaining Pod endpoints which are untested. a Pod with a static label the Pod with a new Label and updated data the Pod to ensure it's patched the Pod's status the Pod's status Ready condition to False the Pod's status to check if Ready is False all Pods in all Namespaces find the Pod(1) ensure that the Pod is found and is patched Namespaced Pod(1) via a Collection with a LabelSelector the Pod to check that it's deleted Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/reopen Test PR Merge Promotion PR to be created next
Reopened this issue. <detailsIn response to : /reopen Test PR Merge Promotion PR to be created next 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
reverted by due to flaky test
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
/reopen PR on test grid for 2 weeks before promotion to conformance
Reopened this issue. <detailsIn response to : /reopen PR on test grid for 2 weeks before promotion to conformance 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
/triage accepted
Code change:
scheme := runtime.NewScheme() scheme.AddKnownTypes(cmResource.GroupVersion(), &v1.ConfigMap{}) codecs := serializer.NewCodecFactory(scheme) <del> o := NewFieldManagedObjectTracker(scheme, codecs.UniversalDecoder(), fakeTypeConverter) </del> <ins> o := NewFieldManagedObjectTracker(scheme, codecs.UniversalDecoder(), configMapTypeConverter(scheme)) </ins> reaction := ObjectReaction(o) patch := []byte(`{"apiVersion": "v1", "kind": "ConfigMap", "metadata": {"name": "cm-1"}, "data": {"k": "v"}}`)

Related discussion:
text: Smoke tests run by publishing-bot on client-go master are failing Ref for failure logs: Tests defined for client-go, after publishing, Since commit No response As part of , when module is used from within the staging directory, can be used by traversing to the parent directory. But once the module is made as a separate repository as part of publishing, then traversing to repository using path will not work. No response /sig-api-machinery
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api-machinery 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
Looking
I'll remove the swagger file dependency, I don't think we strictly need it.
/triage accepted
Code change:
newDevicePath := "" <del> err = wait.Poll(1*time.Second, timeout, func() (bool, error) { </del> <ins> err = wait.PollImmediate(1*time.Second, timeout, func() (bool, error) { </ins> if newDevicePath, err = findDiskByLun(int(lun), io, exec); err != nil { return false, fmt.Errorf("azureDisk - WaitForAttach ticker failed node (%s) disk (%s) lun(%v) err(%s)", nodeName, diskName, lun, err) }

Related discussion:
text: <!-- 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: When starting pods with AFS volumes, there is an initial delay of five seconds until the pod is transitioning from the "Scheduled" state. The reason for this is that currently the volume mounting happens inside a wait.Poll which will initially wait a specified interval (currently 5 seconds) before execution. Event log for comparison with and without AFS volume attached (seconds since event): What you expected to happen: 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: /assign /priority important-soon /sig cloud-provider /area provider/azure
see