[CARBONDATA-2990] Fixed JVM crash when rebuilding bloom datamap.

Problem: while rebuilding the datamap it access the datamap store so it builds datamap and store in unsafe onheap storage. But while closing the reader it frees all memory acquired during that task. Since acquired memory is onheap but releasing the memory with offheap allocator it crashes the jvm.
Solution: Maintain the type of memory acquired in the memory block itself and get the allocator as per the memory type and release it.
Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[ ] Any interfaces changed?

[ ] Any backward compatibility impacted?

[ ] Document update required?

[ ] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/853/

Build Success with Spark 2.3.1, Please check CI http://<IP_ADDRESS>:8080/job/carbondataprbuilder2.3/8922/

@ravipesala Can you explain why the JVM crash issue does not happened in our tests, cause we also have tests for rebuilding datamap.

@xuchuanyin It can happen only in a cluster, that's why it is not caught in UT.

@ravipesala Why does it only occur in cluster mode? Just in curious

@xuchuanyin Since both driver and executor exists in the same JVM, it can get segment properties from blocklet datamap without loading them again in executor side, so no need to clear in executor side in case of noncluster mode.

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/696/

LGTM


Break #4115 PR into smaller ones to unblock improving job progress trackign

related to https://github.com/bacalhau-project/bacalhau/issues/3991


The downtime tab is inconsistent in compendiums

I'm currently preparing for a campaign and creating all the NPCs.  I wanted to use this to track loyalty scores, but when i went into the compendium to edit the actors, the downtime tab doesn't show up.
BUT THEN, I randomly discovered that SOME show the downtime tab, but some don't and I have no idea what's causing this.
Even if i import an actor into the world so the tab shows up, edit it, then put it back in the compendium, the tab is still gone.
The actor that HAS the downtime tab hasn't been edited at all since putting it in the compendium and activating the module.
I'm on V10.303
Dnd5e V 2.3.1

Hello!
It's intended that the tab won't display when opening an actor from a compendium. If you need to update downtime data for an actor in a compendium, import the actor first, open their sheet from the Actors tab, make any adjustments you need, and then stick them back into the compendium. The downtime data should be retained for the next time they're imported into the world. (If the tab isn't showing up when they're opened from the Actors tab, then check the module settings. There's a toggle in there for which types of actors the tab should display on - NPCs, PCs, or both. If that setting is set correctly, and you're still experiencing issues seeing the tab, then something is up.)
At this point I'm not maintaining this module anymore, and don't really have time to be fixing issues or taking feature requests. If the tab not displaying when opening an actor from a compendium is make or break for you, I'd suggest you check out Downtime Dnd5e (which is a sort of successor to this module) and make those bug reports or feature requests over there if they're still issues in that version of the mod.


Unhandled Exception: Scrollable.of() was called with a context that does not contain a Scrollable widget. No Scrollable widget ancestor could be found starting from the context that was passed to Scrollable.of(). This can happen because you are using a widget that looks for a Scrollable ancestor, but no such ancestor exists. The context used was:

@bawantha Please describe your problem in more detail. Maybe with a video or image.


unbound: remove custom options setting et al

Unbound can already live without the custom options, but the chroot makes it a little difficult to inject persistent files. We need another inclusion dir where we stage templates (and other things) to be copied over into the chroot on config changes.
Somewhat related to what @mimugmail is struggling with for unbound-plus.
Also of note are missing features around DOT:
qname-minimisation: yes
qname-minimisation-strict: yes

forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr<EMAIL_ADDRESS>forward-addr<EMAIL_ADDRESS>forward-addr<EMAIL_ADDRESS>
Get rid of the apply now that we have a cache retain option:
# git grep subsystem_dirty..unbound

@fichtner wouldn't the template engine already take care of that https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/unbound.inc#L443 (https://docs.opnsense.org/manual/unbound.html#advanced-configurations), although reading the docs again, If one would add a submodule in the Unbound template dir it would be added automatically, which is what "plus" also did if I'm not mistaken.

Yes and no, part of the issue is https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/unbound.inc#L413 returning too early (easy fix in general) and also not having a sufficiently persistent directory to avoid the clearing of /var/unbound on boot where unbound-plus requires refetching which can fail). so the templating needs a staging area in this case, preferably outside of /var -- not entirely sure yet but a good goal for 21.1 and the advanced options removal

So @AdSchellevis also mentioned that we need a non /var MFS staging area for blacklist itself with the best course of action making a whole persistent staging dir for unbound configurations so that reboots do not have bootstrap issues.

Not sure if this is the right place to comment on this, if not, my apologies in advance.
It seems to me that removing the advanced configuration capability doesn't really solve any issues but definitely makes OPNsense less flexible than it is.
I currently use advanced configuration to deploy support for DNS over TCP with server name validation as current DoT support doesn't validate TLS server name allowing MiTM attacks, disabling DNS round-robin responses as this interferes with reverse resolving primary vs alternate hostnames, adding custom SOA records for the local domain as this enables certain client functionality, adding custom SRV records for kerberos realm support, and adding custom PTR, SRV and TXT records for DNS Service Discovery support for my local domain.
Without advanced configuration I have no way of configuring OPNsense to handle my DNS needs and would be forced to use another DNS server (pihole or BIND) instead of unbound which is more than capable today.

@shonjir as mentioned in earlier posts, these types of options will disappear for security reasons, in most cases there are alternatives as described here https://docs.opnsense.org/manual/unbound.html#advanced-configurations in the case of unbound.

Relevant docs changes https://github.com/opnsense/docs/commit/775d737c3da

harden-below-nxdomain: yes is the default

@shonjir as mentioned in earlier posts, these types of options will disappear for security reasons, in most cases there are alternatives as described here https://docs.opnsense.org/manual/unbound.html#advanced-configurations in the case of unbound.

Will any of those alternatives will be preserved/restored by the backup module/function?

Features worth being backed up should have full GUI integration. That’s our only rule.

On 1. Aug 2021, at 16:28, Ciro Iriarte @.***> wrote:

@shonjir as mentioned in earlier posts, these types of options will disappear for security reasons, in most cases there are alternatives as described here https://docs.opnsense.org/manual/unbound.html#advanced-configurations in the case of unbound.
Will any of those alternatives will be preserved/restored by the backup module/function?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.


[Jammy] cflinuxsf4 - diagrams

In order to migrate cflinuxsf4 stack (jammy), we want to test and verify that diagrams works using the new stack
Acceptance Criteria

Confirm that diagrams's buildpack supports cflinuxsf4
Deploy diagrams in development cf using stack cflinuxsf4
Update application manifest to point to cflinuxsf4

Security considerations
None
Resources
https://github.com/cloud-gov/cg-diagrams
https://ci.fr.cloud.gov/teams/main/pipelines/deploy-diagrams
Implementation sketch

[x] Update broker deployment in dev to use cflinuxfs4

[x] In a custom branch, add stack: cflinuxfs4 to the manifest: https://github.com/cloud-gov/diagrams/blob/main/manifest.yml
[x] Update the pipeline to use your custom branch for deploying to prod: https://github.com/cloud-gov/diagrams/blob/main/ci/pipeline.yml. For this application, it's just diagrams and not customer-facing functionality, so we're not worried about breaking it in testing
[x] Run the deploy-production job if it doesn't run automatically

[x] Confirm that the app still works by visiting https://diagrams.fr.cloud.gov

I verified the cflinuxfs4 does work with diagrams


rewrite imports to point internally

Our patch is in the region package, so the gohbase package needs to import our region, not github.com/tsuna/gohbase/region. To be consistent, let's just do that everywhere.
@hzhaofb @ascarter @dcreemer

+1

+1


Messages API (SMS) Authentication Failed. Check you're using a valid authentication method

Authentication failed. Check you're using a valid authentication method.
Expected Behavior
I expected to be able to initialize Client with application_id and private_key filepath and then send an SMS with messages API.
Current Behavior
I get the error mentioned above : vonage.errors.AuthenticationError: Authentication failed. Check you're using a valid authentication method.
Possible Solution
Seems the local _application_id isn't saving properly so when its checked for here it doesn't exist even though application_id does exist on client.
Steps to Reproduce (for bugs)
Follow tutorial

Load client client = Client(application_id=application_id, private_key=private_key_file)
send message client.messages.send_message({          "channel": "sms",          "message_type": "text",          "text":body,          "from":from_,          "to":to      })
Error produced

Context
I am trying to follow along with the tutorials and send an SMS via Messages API but getting an authentication error. I've been able to receive messages using messages API webhooks and send messages with SMS API.
Your Environment

Version used: 4.0.0b0 (pre-release)
Environment name and version (e.g. language and server version): python 3.10.6,
Operating System and version: Windows 11

Hi, the beta version you're using didn't fix this bug, I will probably yank that release. The purpose of it was to expose Video API functionality to developers who wanted early access, but it became out-of-date and has since been superseded by the release of v3.12.0.
Things should work as expected with v3.12.0, please give that one a try!

Hi @maxkahan , thanks for the reply. So using 3.12.0 doesn't work because I have a version conflict that seems to be resolved 4.0.0b0. The error I get is:
vonage 3.12.0 requires pydantic==1.*,>=1.10, but you have pydantic 2.5.2 which is incompatible.
We need the latest version of pydantic and other pydantic libraries (like pydantic-settings) require a later versions of pydantic (2+ I think)
Here are some more errors I got along the way:
when downgrading to Vonage v 3.12.0:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. pydantic-settings 2.0.0 requires pydantic>=2.0b3, but you have pydantic 1.10.13 which is incompatible.
and when trying to run my application with the above, I get the issue: ModuleNotFoundError: No module named 'pydantic._internal' I imagine because pydantic-settings is looking for that module in pydantic, but older versions of pydantic aren't compatible
So, overall, if possible, I think upgrading pydantic to at least version 2 should help. Would that be possible?

I don't have permission to create a branch here but I made a few changes locally that seemed to enable my application to run properly @maxkahan The summary is:

Change some imports around:

from pydantic import BaseModel, Field, validator
from pydantic.types import  conint, constr, confloat, AnyType

change regex= in constr() to pattern=
add AnyType to type = Field(...) overrides in ncco.py, verify2.py, and connect_endpoints.py (where applicable). So type: AnyType = Field(...)
change const= in Field() to Literal=
remove or update pydantic version restriction in setup.py
update pydantic version in requirements.txt

Hi David, I started work to update the SDK to use Pydantic v2.x, but that required breaking changes so would have been rolled up into v4 of the SDK. I did some work on this on the old-4.x branch if you want to have a look, but it's incomplete. Priorities changed so I'm currently working on a full rewrite that will use Pydantic v2, as well as other significant changes. That won't be ready for a little while though. Hope this context is helpful!

Hi @dlewis2017 we've just released v3.13.0 with v2 support so that should solve this issue!


DC-installation fails

When following directions, DC-installation fails - and client tools etc. are missing:
{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"VMExtensionProvisioningError","message":"VM has reported a failure when processing extension 'InstallDomainController'. Error message: "DSC Configuration 'CreateADPDC' completed with error(s). Following are the first few: WinRM cannot process the request. The following error with errorcode 0x80090350 occurred while using Negotiate authentication: An unknown security error occurred. \r\n Possible causes are:\r\n -The user name or password specified are invalid.\r\n -Kerberos is used when no authentication method and no user name are specified.\r\n -Kerberos accepts domain user names, but not local user names.\r\n -The Service Principal Name (SPN) for the remote computer name and port does not exist.\r\n -The client and remote computers are in different domains and there is no trust between the two domains.\r\n After checking for the above issues, try the following:\r\n -Check the Event Viewer for events related to authentication.\r\n -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.\r\n Note that computers in the TrustedHosts list might not be authenticated.\r\n -For more information about WinRM configuration, run the following command: winrm help config."\r\n\r\nMore information on troubleshooting is available at https://aka.ms/VMExtensionDSCWindowsTroubleshoot "}]}

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d7c7b5d6-c9a4-3445-81c1-41dc41ae0929
Version Independent ID: a45e9b8a-185b-ff29-dc4a-b8912c13ed1b
Content: Tutorial: Explore Power BI Report Server in a VM - Power BI
Content Source: powerbi-docs/report-server/tutorial-explore-report-server-web-portal.md
Service: powerbi
Sub-service: powerbi-report-server
GitHub Login: @maggiesMSFT
Microsoft Alias: maggies

Hi @mortenf. You've reached the documentation team, and I think your question is more of a support request or product question than it is documentation feedback. You might find a solution asking in the Power BI Community. If not, try our support page. Thanks!


Ignore 'rpm' (use rpm-ndb) also for single-cloud descriptions

The comment <!-- OBS-IgnorePackage: rpm --> is not used for single-cloud image description and currently results in unresolvables, see https://build.suse.de/project/monitor/SUSE:SLE-15-SP5:GA:Staging:B?arch_x86_64=1&defaults=0&repo_images=1&unresolvable=1 for instance.

Thanks for spotting that. Background is that cross-cloud and single-cloud evolved from something like current scheme and old scheme. With moving some of the newer definitions to single-cloud where they actually belong, the IgnorePackage directive wasn't applied anymore. However, this PR enables it for all older image definitions which is obviously not intended. I'll fix it.


Not able to hot reload flutter app.

I have started a new Flutter default app which is the counter app and when I try run the app on emulator, it installs perfectly but I cannot just change anything and hot reload, I have to reinstall whole app.
Run window is stuck at
Launching lib\main.dart on sdk gphone x86 in debug mode...
Running Gradle task 'assembleDebug'...
√ Built build\app\outputs\apk\debug\app-debug.apk.
Installing build\app\outputs\apk\app.apk...
This is taking longer than expected...
Although the App gets installed properly and I can increment the counter too. But hot reload is grayed out since I believe Android studio is in disconnected state with the app. So to see the change, I always have to reinstall the whole app which is tedious process. Please guide me in finding what is wrong here.
Steps to Reproduce
1 - In Android Studio, start a new Flutter application.
2 - Start emulator with API level 30, Android 10.0 + Google Play
3 - Run the app.

Logs
**Run toolbar log:**
Launching lib\main.dart on sdk gphone x86 in debug mode...
Running Gradle task 'assembleDebug'...
√ Built build\app\outputs\apk\debug\app-debug.apk.
Installing build\app\outputs\apk\app.apk...
This is taking longer than expected...

Event log toolbar log:
7/23/2020
8:10 PM	Can't bind to local 8600 for debugger

Flutter Doctor
[√] Flutter (Channel stable, v1.17.5, on Microsoft Windows [Version 10.0.14393], locale en-US)
    • Flutter version 1.17.5 at D:\Softwares\flutter
    • Framework revision 8af6b2f038 (3 weeks ago), 2020-06-30 12:53:55 -0700
    • Engine revision ee76268252
    • Dart version 2.8.4

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at D:\AndroidSDK
    • Platform android-30, build-tools 30.0.1
    • ANDROID_HOME = D:\AndroidSDK
    • Java binary at: D:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
    • All Android licenses accepted.

[√] Android Studio (version 4.0)
    • Android Studio at D:\Program Files\Android\Android Studio
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[!] IntelliJ IDEA Community Edition (version 2019.2)
    • IntelliJ at D:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.2
    X Flutter plugin not installed; this adds Flutter specific functionality.
    X Dart plugin not installed; this adds Dart specific functionality.
    • For information about installing plugins, see
      https://flutter.dev/intellij-setup/#installing-the-plugins

[√] VS Code, 32-bit edition (version 1.7.2)
    • VS Code at C:\Program Files (x86)\Microsoft VS Code
    • Flutter extension version 3.7.1

[√] Proxy Configuration
    • HTTP_PROXY is set
    • NO_PROXY is localhost,<IP_ADDRESS>,LOCALHOST
    • NO_PROXY contains <IP_ADDRESS>
    • NO_PROXY contains localhost

[√] Connected device (1 available)
    • sdk gphone x86 • emulator-5554 • android-x86 • Android 11 (API 30) (emulator)

! Doctor found issues in 1 category.

Hi @nilesh14
Can you please try this [solution(https://stackoverflow.com/a/32507892)
If the problem persist after solution, Can you please provide  your flutter run --verbose
Thank you

Hello @TahaTesser  Thank you for responding. I had found this solution earlier and had tried it too before posting my query. Nothing worked at the time.
I checked yesterday and it started working again.. To get flutter to connect to the android emulator I had set some environment variable as below:
HTTP_PROXY=http://<IP_ADDRESS>:1087
HTTPS_PROXY=http://<IP_ADDRESS>:1087
NO_PROXY=localhost,<IP_ADDRESS>,LOCALHOST
This did not work too so I removed all these variables as it was causing some issue in building the project. I was getting some connection timed out in flutter pub get command.
But the next day when I turned on the PC, things became normal again.
Although instant/hot reload working fine, I still get the Flutter is taking longer than expected to report its views. Still trying... message in the Run toolbar.
Launching lib\main.dart on AOSP on IA Emulator in debug mode...
[!] Your app isn't using AndroidX.
To avoid potential build failures, you can quickly migrate your app by following the steps on https://goo.gl/CP92wY.
Running Gradle task 'assembleDebug'...
√ Built build\app\outputs\apk\debug\app-debug.apk.
Installing build\app\outputs\apk\app.apk...
Flutter is taking longer than expected to report its views. Still trying...
Debug service listening on ws://<IP_ADDRESS>:52592/W5IsDKJ_8qA=/ws
Syncing files to device AOSP on IA Emulator...
Thank you

Hi @nilesh14
Can you please try with a fresh project with counter example? Also reset your emulator, it could be slow down if the emulator has too many apps, not enough space
Thank you

Hello @TahaTesser , I created new flutter project and it is running as expected.
I hope that it keeps running without issue.
Thank you for your support!


Import constraints from Constraints.jl instead of locally

Codecov Report

Merging #18 (39be9f1) into main (c3e56d5) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #18   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           18        18
  Lines          336       336
=========================================
  Hits           336       336

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c3e56d5...39be9f1. Read the comment docs.


Allow the user to show timestamps of the image instead of the time recorded

As stated above there should be an option for the user to select image sources from the time the image was taken, not when it was saved to WIW Database.
For example, so you could have in this list written 2012 instead of 2016...

Hi @ACH1980 ,
I reached out the project manager @robert-waterman of the Wayback App regarding this issue and here is his reply:

World Imagery is composed of hundreds of thousands of individual images stitched together to form a single basemap layer. Esri does not have access to all of the individual images used to produce the basemap. Therefore, we do not have a practical way of creating an archive by acquisition date (which is a property of each individual image). As such, we provide an archive consisting of versions of the World Imagery layer arranged by release date (a property of each layer).

Hope it's helpful. Thanks.


datetime format %z not working

Hi team,
I found an issue with the Get Current Date function in the DateTime library. The datetime format for utc offset (%z) is not working.
Here's the code:
${date}     Get Current Date   result_format=%Y-%m-%dT%H:%M:%S%z%A
Log To Console  Show date: ${date}
The expected result should be:
Show date: 2020-11-18T15:08:38+1100Wednesday
The actual result:
Show date: 2020-11-18T15:08:38Wednesday
The system I've tested is Mac and Linux:
Mac:

Linux:
Docker Ubuntu latest :
https://hub.docker.com/layers/ubuntu/library/ubuntu/latest/images/sha256-1d7b639619bdca2d008eca2d5293e3c43ff84cbee597ff76de3b7a7de3e84956?context=explore
Could you please advice that is it a bug or just not supported? Thanks in advance!
Regards,
Ken

According to https://strftime.org %z is timezone which can be empty if the object isn't timezone aware. The DataTime library doesn't support timezones because Python hasn't had built-in support for them. I think Python 3.9 actually added some timezone support so perhaps this could enhanced. Are you possibly interested to look at that?


ERROR: Invalid File on one computer but not the other

Hi, I have AAXtoMP3 installed on two computers. Both are running Linuxmint.
One returns EVERY FILE as ERROR: Invalid File: .......................  It then continues to say Noclobber enabled but directly exists so skipping so it doesn't totally fail.
The other computer has no errors what so ever. (with the same files)
Where can I start troubleshooting my issues? I assume it could be a codec missing or something like that?
Thanks!

I appologize, old version of ffmpeg

same problem, even after apt upgrade
using ffmpeg 7:3.4.8-0ubuntu0.2


body(response) will timeout if read response is not getting eof. Should use content-length to decide if read is completed.

I'm connecting to a customized http server. Client send a post request to server, and server will send back a response. But client will not read eof, maybe because server is not closing the socket immediately. In this case, the process will always wait for the body ending. I think cpp-netlib should use Content-Length to decide if it reaches the end of body.
I use the attached patch to temporarily make it working.
g.txt

Please send in a pull request against the 0.12-devel branch instead of attaching a patch so we can track contributions and attributions properly.

@alpsxing -- can you convert this patch into a pull request?


Error loops during switching the instance type

Description
Observed Behavior:
During switching the instance type of the actual used nodes (from m6g.2xlarge to r6g.2xlarge) in provisioner, Karpenter hangs in Error loop during provisioning the node.
The workload which is used below provisioner is simple - Elasticsearch single pod deployed as a sts in node. Limit and resource quotas are fitted to node possibilities.
Here is the code of the provisioner:
---
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: eng-eck-logs-warm-a
spec:
  providerRef:
    name: eng-20gb

  labels:
    bolt.eu/costcenter: eng
    role: eck-logs-warm

  requirements:
    - key: kubernetes.io/arch
      operator: In
      values:
        - arm64
    - key: karpenter.k8s.aws/instance-family
      operator: In
      values:
        - m6g
        - r6g
    - key: karpenter.k8s.aws/instance-size
      operator: In
      values:
        - 2xlarge
    - key: topology.kubernetes.io/zone
      operator: In
      values:
        - eu-central-1a
    - key: kubernetes.io/os
      operator: In
      values:
        - linux
    - key: karpenter.sh/capacity-type
      operator: In
      values:
        - on-demand

  taints:
    - key: dedicated
      value: eck-logs
      effect: NoSchedule

  limits: # https://karpenter.sh/preview/concepts/provisioners/#speclimitsresources
    resources:
      cpu: "336"
      memory: 2688Gi

  consolidation:
    enabled: false

Here is the log with normal behaviour:
2023-11-16T08:59:00.284Z	DEBUG	controller.provisioner	397 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:59:00.365Z	DEBUG	controller.provisioner	9 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:59:00.563Z	INFO	controller.provisioner	found provisionable pod(s)	{"commit": "dc3af1a", "pods": 1}
2023-11-16T08:59:00.563Z	INFO	controller.provisioner	computed new node(s) to fit pod(s)	{"commit": "dc3af1a", "nodes": 1, "pods": 1}
2023-11-16T08:59:00.564Z	INFO	controller.provisioner	launching machine with 1 pods requesting {"cpu":"6105m","memory":"58738Mi","pods":"6"} from types r6g.2xlarge	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-a"}
2023-11-16T08:59:00.971Z	DEBUG	controller.provisioner.cloudprovider	discovered kubernetes version	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-a", "kubernetes-version": "1.26"}
2023-11-16T08:59:01.261Z	DEBUG	controller.provisioner.cloudprovider	discovered new ami	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-a", "ami": "ami-07c194f003f9bda84", "query": "/aws/service/eks/optimized-ami/1.26/amazon-linux-2-arm64/recommended/image_id"}
2023-11-16T08:59:01.483Z	DEBUG	controller.provisioner.cloudprovider	created launch template	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-a", "launch-template-name": "Karpenter-elasticsearch-live-eu-central-1-9874207509174187694", "launch-template-id": "lt-xxxxxxxxxxxxx"}
2023-11-16T08:59:04.062Z	INFO	controller.provisioner.cloudprovider	launched new instance	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-a", "id": "i-0d0cb79a6533148f0", "hostname": "ip-xxxxxxxxx.eu-central-1.compute.internal", "instance-type": "r6g.2xlarge", "zone": "eu-central-1a", "capacity-type": "on-demand"}

And here is the log with Error loop, when pod will hang in Pending state till the karpenter leader controller will be restarted. After the restart, new node is scheduled correctly, without issues.
2023-11-16T08:57:19.724Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.724Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.724Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.725Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.725Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.725Z	DEBUG	controller.provisioner	99 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.725Z	DEBUG	controller.provisioner	21 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.725Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.725Z	DEBUG	controller.provisioner	377 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T08:57:19.725Z	ERROR	controller.provisioner	Could not schedule pod, all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-hot-a", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-hot-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1a] not in topology.kubernetes.io/zone In [eu-central-1c]; key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-master-b", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-master-c", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-master-a", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-warm-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1a] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-eck-logs-warm-b", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1a] not in topology.kubernetes.io/zone In [eu-central-1b]; incompatible with provisioner "eng-eck-logs-hot-b", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1a] not in topology.kubernetes.io/zone In [eu-central-1b]; incompatible with provisioner "eng-shared", incompatible requirements, label "role" does not have known values	{"commit": "dc3af1a", "pod": "eck-logs/logs-es-data-warm-v1-a-1"}

Expected Behavior:
Nodes will be reprovisioned without errors.
Reproduction Steps (Please include YAML):

Add new instance type to provisioner.
Provide more resources to the workload to use new instance type

Versions:

Chart Version: v0.27.0
Kubernetes Version (kubectl version): 1.26

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Interesting thing is that on the az-b and az-c I don't see such behaviour, so Im suspecting that this could be related to capacity issue in the region. Anyway - would be nice to have such kind of information in Karpenter logs

Can you supply full logs of the failed launch? If a launch fails for a capacity reason, we internally mark the instance type as not available for a few minutes.

Here is the full log.
As you can see at the beginning - first attempt works. After that it starting looping with the error. To proceed further I need to restart actual lease leader.
2023-11-16T14:44:17.093Z	DEBUG	Successfully created the logger.
2023-11-16T14:44:17.093Z	DEBUG	Logging level set to: debug
{"level":"info","ts":1700145857.0986578,"logger":"fallback","caller":"injection/injection.go:63","msg":"Starting informers..."}
2023-11-16T14:44:17.199Z	DEBUG	controller	waiting for configmaps	{"commit": "dc3af1a"}
2023-11-16T14:44:17.712Z	DEBUG	controller	waiting for configmaps	{"commit": "dc3af1a"}
2023-11-16T14:44:18.213Z	DEBUG	controller	waiting for configmaps	{"commit": "dc3af1a"}
2023-11-16T14:44:18.714Z	DEBUG	controller	waiting for configmaps	{"commit": "dc3af1a"}
2023-11-16T14:44:19.215Z	DEBUG	controller	waiting for configmaps	{"commit": "dc3af1a"}
2023-11-16T14:44:19.790Z	DEBUG	controller.aws	discovered region	{"commit": "dc3af1a", "region": "eu-central-1"}
2023-11-16T14:44:19.943Z	DEBUG	controller.aws	discovered cluster endpoint	{"commit": "dc3af1a", "cluster-endpoint": "https://xxxxxxxxx.eu-central-1.eks.amazonaws.com"}
2023-11-16T14:44:19.947Z	DEBUG	controller.aws	discovered kube dns	{"commit": "dc3af1a", "kube-dns-ip": "xxxxxxxx"}
2023-11-16T14:44:19.948Z	DEBUG	controller.aws	discovered version	{"commit": "dc3af1a", "version": "v0.27.0"}
2023/11/16 14:44:19 Registering 2 clients
2023/11/16 14:44:19 Registering 2 informer factories
2023/11/16 14:44:19 Registering 3 informers
2023/11/16 14:44:19 Registering 6 controllers
2023-11-16T14:44:19.950Z	INFO	controller	Starting server	{"commit": "dc3af1a", "path": "/metrics", "kind": "metrics", "addr": "[::]:8080"}
2023-11-16T14:44:19.950Z	INFO	controller	Starting server	{"commit": "dc3af1a", "kind": "health probe", "addr": "[::]:8081"}
2023-11-16T14:44:20.100Z	INFO	controller	Starting informers...	{"commit": "dc3af1a"}
2023-11-16T14:44:20.497Z	INFO	controller.aws.pricing	updated spot pricing with instance types and offerings	{"commit": "dc3af1a", "instance-type-count": 631, "offering-count": 1681}
I1116 14:44:20.651397       1 leaderelection.go:248] attempting to acquire leader lease karpenter/karpenter-leader-election...
2023-11-16T14:44:23.130Z	INFO	controller.aws.pricing	updated on-demand pricing	{"commit": "dc3af1a", "instance-type-count": 615}
I1116 14:58:39.398688       1 leaderelection.go:258] successfully acquired lease karpenter/karpenter-leader-election
2023-11-16T14:58:39.399Z	INFO	controller.provisioner	starting controller	{"commit": "dc3af1a"}
2023-11-16T14:58:39.399Z	INFO	controller.deprovisioning	starting controller	{"commit": "dc3af1a"}
2023-11-16T14:58:39.399Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "daemonset", "controllerGroup": "apps", "controllerKind": "DaemonSet", "source": "kind source: *v1.DaemonSet"}
2023-11-16T14:58:39.399Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "daemonset", "controllerGroup": "apps", "controllerKind": "DaemonSet"}
2023-11-16T14:58:39.399Z	INFO	controller.metric_scraper	starting controller	{"commit": "dc3af1a"}
2023-11-16T14:58:39.399Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod", "source": "kind source: *v1.Pod"}
2023-11-16T14:58:39.399Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod"}
2023-11-16T14:58:39.400Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-11-16T14:58:39.400Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node"}
2023-11-16T14:58:39.400Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-11-16T14:58:39.400Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1alpha5.Provisioner"}
2023-11-16T14:58:39.400Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Pod"}
2023-11-16T14:58:39.400Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "node", "controllerGroup": "", "controllerKind": "Node"}
2023-11-16T14:58:39.401Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod", "source": "kind source: *v1.Pod"}
2023-11-16T14:58:39.401Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod"}
2023-11-16T14:58:39.401Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1alpha5.Provisioner"}
2023-11-16T14:58:39.401Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-11-16T14:58:39.401Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod", "source": "kind source: *v1.Pod"}
2023-11-16T14:58:39.401Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod"}
2023-11-16T14:58:39.403Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "termination", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-11-16T14:58:39.403Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "termination", "controllerGroup": "", "controllerKind": "Node"}
2023-11-16T14:58:39.403Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1alpha5.Provisioner"}
2023-11-16T14:58:39.403Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1.Node"}
2023-11-16T14:58:39.403Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-11-16T14:58:39.407Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1alpha5.Provisioner"}
2023-11-16T14:58:39.407Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-11-16T14:58:39.407Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate", "source": "kind source: *v1alpha1.AWSNodeTemplate"}
2023-11-16T14:58:39.407Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate"}
2023-11-16T14:58:39.408Z	INFO	controller	Starting EventSource	{"commit": "dc3af1a", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-11-16T14:58:39.410Z	INFO	controller	Starting Controller	{"commit": "dc3af1a", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node"}
2023-11-16T14:58:39.408Z	INFO	controller.interruption	starting controller	{"commit": "dc3af1a"}
2023-11-16T14:58:39.413Z	DEBUG	controller.interruption	watching interruption queue	{"commit": "dc3af1a", "queue": "xxxxxxxxxxx"}
2023-11-16T14:58:39.409Z	DEBUG	controller.aws	hydrating the launch template cache	{"commit": "dc3af1a", "tag-key": "karpenter.k8s.aws/cluster", "tag-value": "xxxxxxx"}
2023-11-16T14:58:39.700Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "daemonset", "controllerGroup": "apps", "controllerKind": "DaemonSet", "worker count": 10}
2023-11-16T14:58:39.701Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-11-16T14:58:39.795Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-11-16T14:58:40.095Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod", "worker count": 10}
2023-11-16T14:58:40.096Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod", "worker count": 1}
2023-11-16T14:58:40.106Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "termination", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-11-16T14:58:40.199Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate", "worker count": 10}
2023-11-16T14:58:40.200Z	DEBUG	controller.aws	finished hydrating the launch template cache	{"commit": "dc3af1a", "tag-key": "karpenter.k8s.aws/cluster", "tag-value": "xxxxxx", "item-count": 0}
2023-11-16T14:58:40.200Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "worker count": 10}
2023-11-16T14:58:40.201Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "worker count": 10}
2023-11-16T14:58:40.202Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "worker count": 1}
2023-11-16T14:58:40.296Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-11-16T14:58:40.395Z	INFO	controller	Starting workers	{"commit": "dc3af1a", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod", "worker count": 10}
2023-11-16T14:58:41.410Z	DEBUG	controller.awsnodetemplate	discovered subnets	{"commit": "dc3af1a", "awsnodetemplate": "eng-20gb", "subnets": ["xxxxxxxxx (eu-central-1c)", "xxxxxxxxxxxxxx (eu-central-1b)", "xxxxxxxxxxxx (eu-central-1a)"]}
2023-11-16T14:58:42.797Z	DEBUG	controller.awsnodetemplate	discovered security groups	{"commit": "dc3af1a", "awsnodetemplate": "eng-20gb", "security-groups": ["xxxxxxxxx"]}
2023-11-16T14:58:45.800Z	DEBUG	controller.deprovisioning	discovered EC2 instance types	{"commit": "dc3af1a", "instance-type-count": 613}
2023-11-16T14:58:47.402Z	DEBUG	controller.inflightchecks	discovered EC2 instance types zonal offerings for subnets	{"commit": "dc3af1a", "node": "ip-xxxxxxx.eu-central-1.compute.internal", "subnet-selector": "{\"Name\":\"xxxxxxxxxx\"}"}
2023/11/16 14:58:53 http: TLS handshake error from xxxxxx: EOF
2023/11/16 14:58:54 http: TLS handshake error from xxxxxxx: EOF
2023/11/16 14:58:54 http: TLS handshake error from xxxxxxx:42092: EOF
2023/11/16 14:58:54 http: TLS handshake error from xxxxxxx:42168: EOF
2023/11/16 14:58:54 http: TLS handshake error from xxxxxxxxx:42194: EOF
2023/11/16 14:58:54 http: TLS handshake error from xxxxxxxxxxx:42238: EOF
2023/11/16 14:58:54 http: TLS handshake error from xxxxxxxxx:42234: EOF
2023-11-16T14:59:20.996Z	DEBUG	controller.provisioner	17 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T14:59:20.997Z	DEBUG	controller.provisioner	9 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T14:59:20.997Z	DEBUG	controller.provisioner	9 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T14:59:20.997Z	DEBUG	controller.provisioner	294 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T14:59:20.997Z	DEBUG	controller.provisioner	397 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T14:59:20.998Z	DEBUG	controller.provisioner	397 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T14:59:20.998Z	DEBUG	controller.provisioner	9 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T14:59:21.209Z	INFO	controller.provisioner	found provisionable pod(s)	{"commit": "dc3af1a", "pods": 1}
2023-11-16T14:59:21.209Z	INFO	controller.provisioner	computed new node(s) to fit pod(s)	{"commit": "dc3af1a", "nodes": 1, "pods": 1}
2023-11-16T14:59:21.296Z	INFO	controller.provisioner	launching machine with 1 pods requesting {"cpu":"6105m","memory":"58738Mi","pods":"6"} from types r6g.2xlarge	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-b"}
2023-11-16T14:59:22.196Z	DEBUG	controller.provisioner.cloudprovider	discovered kubernetes version	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-b", "kubernetes-version": "1.26"}
2023-11-16T14:59:22.405Z	DEBUG	controller.provisioner.cloudprovider	discovered new ami	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-b", "ami": "ami-xxxxxx", "query": "/aws/service/eks/optimized-ami/1.26/amazon-linux-2-arm64/recommended/image_id"}
2023-11-16T14:59:22.596Z	DEBUG	controller.provisioner.cloudprovider	created launch template	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-b", "launch-template-name": "xxxxxxxxxxx3", "launch-template-id": "lt-xxxxxxxxx"}
2023-11-16T14:59:24.696Z	INFO	controller.provisioner.cloudprovider	launched new instance	{"commit": "dc3af1a", "provisioner": "eng-eck-logs-warm-b", "id": "i-xxxxxxxx", "hostname": "ip-xxxxxxxxx.eu-central-1.compute.internal", "instance-type": "r6g.2xlarge", "zone": "eu-central-1b", "capacity-type": "on-demand"}
2023-11-16T15:04:20.095Z	DEBUG	controller.aws	deleted launch template	{"commit": "dc3af1a"}
2023-11-16T15:08:52.505Z	DEBUG	controller.inflightchecks	discovered EC2 instance types	{"commit": "dc3af1a", "node": "ip-xxxxxxxxxx.eu-central-1.compute.internal", "instance-type-count": 613}
2023-11-16T15:10:27.506Z	DEBUG	controller.provisioner	377 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.596Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.597Z	DEBUG	controller.provisioner	99 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.598Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.599Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.600Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.601Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.601Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:27.602Z	ERROR	controller.provisioner	Could not schedule pod, incompatible with provisioner "eng-shared", incompatible requirements, label "role" does not have known values; incompatible with provisioner "eng-eck-logs-hot-b", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-warm-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-eck-logs-hot-a", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1a]; incompatible with provisioner "eng-eck-logs-master-b", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-master-c", did not tolerate dedicated=eck-logs-master:NoSchedule; all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-hot-c", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-eck-logs-master-a", did not tolerate dedicated=eck-logs-master:NoSchedule	{"commit": "dc3af1a", "pod": "eck-logs/logs-es-data-warm-v1-b-1"}
2023-11-16T15:10:51.212Z	DEBUG	controller.provisioner	99 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.213Z	DEBUG	controller.provisioner	377 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.213Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.214Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.214Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.214Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.214Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.214Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:10:51.214Z	ERROR	controller.provisioner	Could not schedule pod, all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-warm-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-shared", incompatible requirements, label "role" does not have known values; incompatible with provisioner "eng-eck-logs-hot-b", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-hot-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-master-a", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-hot-a", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1a]; incompatible with provisioner "eng-eck-logs-master-b", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-master-c", did not tolerate dedicated=eck-logs-master:NoSchedule; all available instance types exceed provisioner limits	{"commit": "dc3af1a", "pod": "eck-logs/logs-es-data-warm-v1-b-1"}
2023-11-16T15:11:07.995Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.995Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.996Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.996Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.996Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.997Z	DEBUG	controller.provisioner	99 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.997Z	DEBUG	controller.provisioner	377 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.997Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:07.997Z	ERROR	controller.provisioner	Could not schedule pod, incompatible with provisioner "eng-eck-logs-master-c", did not tolerate dedicated=eck-logs-master:NoSchedule; all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-hot-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-master-a", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-hot-a", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1a]; key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-master-b", did not tolerate dedicated=eck-logs-master:NoSchedule; all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-warm-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-shared", incompatible requirements, label "role" does not have known values; incompatible with provisioner "eng-eck-logs-hot-b", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]	{"commit": "dc3af1a", "pod": "eck-logs/logs-es-data-warm-v1-b-1"}
2023-11-16T15:11:24.007Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.008Z	DEBUG	controller.provisioner	99 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.008Z	DEBUG	controller.provisioner	377 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.009Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.009Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.009Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.010Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.010Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:24.010Z	ERROR	controller.provisioner	Could not schedule pod, incompatible with provisioner "eng-eck-logs-hot-b", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-warm-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-shared", incompatible requirements, label "role" does not have known values; incompatible with provisioner "eng-eck-logs-master-b", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-master-c", did not tolerate dedicated=eck-logs-master:NoSchedule; all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-hot-c", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-eck-logs-master-a", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-hot-a", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1a]; key role, role In [eck-logs-warm] not in role In [eck-logs-hot]	{"commit": "dc3af1a", "pod": "eck-logs/logs-es-data-warm-v1-b-1"}
2023-11-16T15:11:49.303Z	DEBUG	controller.provisioner	99 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.304Z	DEBUG	controller.provisioner	377 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.304Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.304Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.305Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.498Z	DEBUG	controller.provisioner	58 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.498Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.499Z	DEBUG	controller.provisioner	445 out of 613 instance types were excluded because they would breach provisioner limits	{"commit": "dc3af1a"}
2023-11-16T15:11:49.499Z	ERROR	controller.provisioner	Could not schedule pod, all available instance types exceed provisioner limits; incompatible with provisioner "eng-eck-logs-warm-c", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-shared", incompatible requirements, label "role" does not have known values; incompatible with provisioner "eng-eck-logs-hot-b", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-hot-c", incompatible requirements, key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1c]; incompatible with provisioner "eng-eck-logs-master-a", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-hot-a", incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [eu-central-1b] not in topology.kubernetes.io/zone In [eu-central-1a]; key role, role In [eck-logs-warm] not in role In [eck-logs-hot]; incompatible with provisioner "eng-eck-logs-master-b", did not tolerate dedicated=eck-logs-master:NoSchedule; incompatible with provisioner "eng-eck-logs-master-c", did not tolerate dedicated=eck-logs-master:NoSchedule; all available instance types exceed provisioner limits	{"commit": "dc3af1a", "pod": "eck-logs/logs-es-data-warm-v1-b-1"}

Sorry. I've done with eng-eck-logs-warm-a and switch to eng-eck-logs-warm-b - The code for those are same with the az difference.

I found the issue.
As you can see from the code:
  consolidation:
    enabled: false

This settings will preserve the node even if it will be empty (having only DS). So the limits related to CPU and Memory were exhausted due to preserving old nodes.
I think that would be nice to have in logs, that the provisioner exhaust the limits.
Thanks for checking it for me!
BR
Maciej


Defaulting of source metadata generator and worker indexing

Once the generator is otherwise ready, we need to cut a version of the SDK which makes the auto-registration on by default, removing the need for this line in project files:
<FunctionsAutoRegisterGeneratedMetadataProvider>True</FunctionsAutoRegisterGeneratedMetadataProvider>

That setting could still be explicitly set to "False" if needed.
Doing so would enable us to do the same thing for the worker indexing, I believe, and we could similarly remove the need for:
<FunctionsEnableWorkerIndexing>True</FunctionsEnableWorkerIndexing>

Again allowing it to be disabled if needed.

The worker indexing piece may have some interdependency with https://github.com/Azure/azure-functions-host/issues/9536 which should be assessed. It's possible that we need to break this item up to separate the generator update from that. But ultimately we need both removed from the project.


About the "Known issue - DI exception"

I've been using the modal for a few weeks now and I'm pretty happy with it. Great work!
However, the DI-know issue that requires us to add this kind of code ...
return Injector.resolve([
      provide(DynamicComponentLoader, {useValue: this.injector.get(DynamicComponentLoader)}),
      provide(ICustomModal, {useValue: new WizardModalContent(...),
      provide(IterableDiffers, {useValue: this.injector.get(IterableDiffers)}),
      provide(KeyValueDiffers, {useValue: this.injector.get(KeyValueDiffers)}),
      provide(Renderer, {useValue: this._renderer}),
      provide(MyService, {useValue: this.injector.get(MyService}),
      provide(/*whatvever the component you put in the modal (or ANY of it's subcomponents need*/)
    ]);

... combined with the fact that those components apparently can't declare this ...
@Component({
    providers: [MyService]
})

... because that crashes a well. And that of course an issue that will bite me real hard one I reuse that component in a non-modal context :(
Do you think think this can all be solved by fixing angular/angular#4330? If so, maybe we should breathe some more life into this issue!

Sorry for the delay, since the issue is fixed now, can you see if the fix solved your issues?

Unfortunately, I can't test this quickly. I've tried updating to beta6 a few days ago but this breaks so much (on our app) that I gave up. Will give it another try in a few weeks.

I'll close this stale issue, please re-open with a comment if it still an issue.


perf: optimize physical_sort.cpp implementation

What problem does this PR solve?
perf:

Evaluate OrderBy expression ahead of time for sorting
Use divide-and-conquer merge to replace the original merge algorithm

bench:

add benchmark for sort

Code changes

[x] Has Code change
[ ] Has CI related scripts change

Check List
Tests

[x] Unit test
[x] Integration test
[x] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Note for reviewer

@mergify merge


Attribution

Vanity request - any chance of changing my attribution to 'Matt Painter'? 😉

For sure 😊


Netclient keeps added routes after disconnected

netclient v0.18.6 installed with service running and everything properly configured as far as I can see, however the Egress node routes published upon connection established do not get removed after disconnection.
This causes the machine to lose connectivity to the IP ranges published by the Egress node when the netclient is not connected.

netclient 0.21.0 behaves the same way.
It's a pain. I try to connect to some hosts in the same local area network but can't because Netmaker only works with hosts with a different public IP. So I need to write a script for always leaving the Netmaker network and deleting all host entries when I'm in my home network where my server is located.
Please fix that or make Netmaker also work over local area networks.

I found a solution. You simply need to create a bridge over the Netmaker server. When I want to access a host in my network over the DNS name like I would by being connected to a network from Netmaker I use the DNS server from Netmaker as local DNS server and connect to Netmaker via Wireguard.
This is how I did it:

Setup Netmaker on a VPS.
Add a network.
Create an access token for that network and copy it
Add the following to the docker-compose.yml file and add the token:

  netclient:
    container_name: netclient-dns-server
    image: 'gravitl/netclient:v0.21.0'
    network_mode: "service:coredns"
    depends_on:
      - coredns
    restart: always
    privileged: true
    environment:
      TOKEN: my-token
    volumes:
      - ./netclient-data:/etc/netclient

Start up the server again.
Now a new host with a cryptic name joined the network. Rename it to a fitting name and copy its IP.
Create a gateway in Netmaker in that network and set the default DNS server to the copied IP.
Connect a device via Wireguard.

Now you can access all hosts in that network over the DNS name like you would with Netclient if you were behind another NAT.


Bugfix/descw 2419

@kshapka-bcgov There's a ticket in the upcoming sprint to figure out how to test this so we can know whether these changes have affected the way the cron tasks function. It seems like this should work but without logs or some way of testing it's hard to tell.


Update on login

Hello.
I'm new on laravel-activitylog and i have the following issue.
I added log when user logged in, but in db also adds update event even if nothing is updated
{"attributes":
{"name":"Denis Narcisa","email":"kpintea@ghita.com"},"old":
{"name":"Denis<EMAIL_ADDRESS>How can i skip this update?

Add those attribute to $ignoreChangedAttributes
https://docs.spatie.be/laravel-activitylog/v1/advanced-usage/logging-model-events#ignoring-changes-to-certain-attributes


Migrate: Env vars break in Windows

When using toolkit create-plugin:migrate this gets generated:
    "build": "TS_NODE_PROJECT=\"./.config/webpack/tsconfig.webpack.json\" webpack -c ./.config/webpack/webpack.config.ts --env production",
    "dev": "TS_NODE_PROJECT=\"./.config/webpack/tsconfig.webpack.json\" webpack -w -c ./.config/webpack/webpack.config.ts --env development",

but that doesn't seem to be valid in windows - you can't set environment variables that way in windows.  I tried seeing if webpack pays attention to config but it doesn't seem to.
 "scripts": {
    "build": "webpack -c ./.config/webpack/webpack.config.ts --env production",
    "dev": "webpack -w -c ./.config/webpack/webpack.config.ts --env development",
     /* ... */
  },
  "config": {
    "TS_NODE_PROJECT": "./.config/webpack/tsconfig.webpack.json"
  },

Initially this seemed to work as it runs the right thing:
yarn run v1.21.1
$ webpack -w -c ./.config/webpack/webpack.config.ts --env development

However, after that there are a lot of other errors.  They all seem to be related to the fact that config didn't actually set TS_NODE_PROJECT...
I noticed webpack has an --env parameter, so I tried this:
    "dev": "webpack -w --env TS_NODE_PROJECT=./.config/webpack/tsconfig.webpack.json -c ./.config/webpack/webpack.config.ts --env development",

but this didn't work.  Reading the docs on that that sets a webpack environment variable, which is not the same as an OS environment variable.
Chasing through the cause of this, I found this old webpack issue that completely describes the problem and suggests suggest two ideas:

Install cross-env and set the variable that way, also suggested as a solution here
Manipulate the environment variable somewhere else, like in webpack.config.ts

That webpack ticket is followed up with some webpack documentation that suggests the cross-env solution is the right one, though I suspect since grafana generates the webpack.config.ts they might have other ideas that don't bring in another dependency.

HI @wz2b thanks for reporting this issue. It is now addressed in https://github.com/grafana/create-plugin/pull/75 and we'll release an update to the create-plugin package after is merged.


Transient state

I've been thinking a bit lately about how an architecture like this would solve the problem of local, transient UI state in a tree that can be quite deep.
For example, let's say we want to have some state when an icon is hovered over so we can change the color of the svg element within. We could use an action to change the state at the top-level, but how do we go about storing this type of state? It's state that is relevant only to icon itself, e.g activeIcon: true, not the entire app. The same could be said for the open state of select menus, or whether an accordion-style UI element is open.
If we store this state along with our app state, we have a couple of new problems:

We need to pass this transient state down through functions and components that don't care about it, which makes the functionality of a much deeper UI element dependant on a higher level component (or multiple) passing the state down through the tree. This breaks the "only care about one level down" approach.
We need to identify the state with this single part of the UI so that when we render it gets given the correct state. How do we do this? Using it's path? A unique ID? In the accordion example, would we have app state with a key of accordion and store the state there? What about the current hovered icon example?
If state updates are kept next to the component, as in this article, then how do we manage updating the same state across many parts of the UI? For example, if I have a project, I might be able to edit that in multiple ways. If we're just throwing actions upwards what component should own the ability to update the project state? My guess is the first common ancestor. This higher-level component could be responsible for updating the state of many different parts of the UI so that the state can be passed back down correctly.

After building and working with Deku for a year or so most of my thoughts are similar to the work you're doing here. If we can keep all state out of the virtual DOM, use bubbling actions to manipulate state, and hold all state outside of the tree, then everything becomes much simpler. I'm struggling to think about:

Where local, transient state should live, or if it should exist at all
How we pass state down without needing to pass it through components that don't care about it. Maybe this is just the way apps need to be built. There needs to be a series of components that are coupled to the app state structure.

I'm really curious to know what people who are approaching UI in a similar way to the Elm architecture are thinking regarding these problems. Hopefully I'm missing some really obvious, but I haven't yet tried building anything of real complexity using an approach like this.

Hello @anthonyshort. It's nice to have you here. Deku is really cool!
You seem to be making a separation between "app state" and "transient state". I don't understand why you see these things so differently (it might be because other frameworks separates them). You probably know it, but the Elm architecture uses the "big state approach", similar to Om. All state is stored in a single big data structure. That includes business state (things you might want to persist), temporary view state and everything else. Conceptually these things are of course very different. But I don't see why we can't handle them equally.

We need to pass this transient state down through functions and components that don't care about it, which makes the functionality of a much deeper UI element dependant on a higher level component (or multiple) passing the state down through the tree. This breaks the "only care about one level down" approach.

Yes. You are right that we have to pass state down through several components. But in a way they will care about it. They won't care about the content but they will care about passing it one level further down the chain. That makes the flow of data explicit and is inherent to the architecture. I don't see how that breaks the "only care about one level down" principle. Consider something like this:
Component1 -> Component2 -> Component3 -> Component4

Each component only know what it receives and what it has to pass on. But Component2 doesn't know if there is 1 or 5 components above it. It also has no idea that there is two components beneath it. This guarantees infinite nestability and loose coupling.

If state updates are kept next to the component, as in this article, then how do we manage updating the same state across many parts of the UI? For example, if I have a project, I might be able to edit that in multiple ways. If we're just throwing actions upwards what component should own the ability to update the project state? My guess is the first common ancestor. This higher-level component could be responsible for updating the state of many different parts of the UI so that the state can be passed back down correctly.

Yes, my answer would be exactly the same. If several components depends on the same data the data will have to originate in a common ancestor since data can only flow down through the functions.
Have you seen the nesting example? It might answer some of your questions.
I think your questions are very interesting and I'm not sure if you will find my answers acceptable. Basically I don't see transient state as something that different from everything else. If you can think of a simple example that would demonstrate your concern I'd like to take a shot at implementing it.

@anthonyshort  great practical questions. These kinds of things I have been struggling with as well, looking at Mercury, Om, Reagent, Elm, and various Flux alternatives.
To me, one nice part about the Elm approach is although there is a single state atom, you mostly don't need to think about it that way. As @paldepind said, you just have to think about what a child component needs from its parent. There are usually two parts to this --

You have an init function to initialize child component state. This can be as flexible as you need it to be to specify what state should be passed in and what should be defaulted within the child, etc.

From the parent component, you expose to the child component how to update the branch(es) of the state tree that is/are to get updated by child actions. This is harder to get your head around, and seems verbose and tedious at first -- at least for me coming from Om, where persistent data structures + global cursors handle some of the plumbing for you. But the benefit is that you don't have to worry about changing your state tree's structure down the road and having to fix a bunch of components.  The Todo app example here has a number of different examples of this, which make use of flyd (similar to Elm's signals), and in particular flyd-forwardto.

The proof is in the pudding though, and I have yet to build anything 'real' with this architecture, although I hope too soon.
I would like to experiment some more with building some useful components which involve both HTTP interactions and also a good bit of 'transient' state. Two things that come to mind are:

autocomplete
file uploader

NB. I noticed that evancz recently proposed a new set of abstractions for doing HTTP in Elm which I also want to look at more in depth.

FYI I've added two examples here, both of which deal with transient state in nested components and asynchronous updates, in case useful to look at (comments welcome).

Autocomplete
File uploader

They both make use of a similar abstraction to Elm's Effects.
On another note, I found this in-depth Redux tutorial useful in terms of thinking about modelling state transitions from the beginning in a moderately complex app (see "Designing The Application State Tree").

They are great examples :+1:
I'll have to take a look at the Redux tutorial. Flux has a lot in common with the Elm architecture. Though generally it doesn't seem to insist so much on immutability and purity.

Awesome, going to have a read through all of this :) Learning a lot here, thanks everyone.


HDFS-16670. Improve Code With Lambda in EditLogTailer class

Description of PR
Improve Code With Lambda in EditLogTailer class

I can create an issue to optimize lambda in hadoop-hdfs module. And create some sub tasks to fix one by one. We can review sub PRs and merge them into the big issue first, then merge it to the trunk.
How about this? @slfan1989 @goiri

I don't think 1 by 1 submits pr, which is really unreasonable. But hadoop-hdfs is indeed relatively large. Can it be submitted according to functional categories, such as HDFS-NN, HDFS-DN, HDFS-JN?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 50s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 42s

trunk passed

+1 :green_heart:
compile
1m 43s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 38s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
1m 23s

trunk passed

+1 :green_heart:
mvnsite
1m 45s

trunk passed

+1 :green_heart:
javadoc
1m 24s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
1m 47s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 41s

trunk passed

+1 :green_heart:
shadedclient
22m 57s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 24s

the patch passed

+1 :green_heart:
compile
1m 26s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 26s

the patch passed

+1 :green_heart:
compile
1m 17s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 17s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  0s

the patch passed

+1 :green_heart:
mvnsite
1m 28s

the patch passed

+1 :green_heart:
javadoc
0m 58s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
1m 33s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 21s

the patch passed

+1 :green_heart:
shadedclient
22m 23s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
239m 21s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 57s

The patch does not generate ASF License warnings.

349m 23s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.ha.TestHAAppend

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4596/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4596

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux e69c6b62e0b4 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / a256d53000663c8fdab5a144f9275180211bd271

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4596/1/testReport/

Max. process+thread count
2979 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4596/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@ZanderXu  I suggest to create a draft pr first, find all the places to be optimized in hadoop-hdfs (with Lambda), let's see how many changes are there? If it is really a lot, split multiple prs. If the number is not too many, it is best to complete it in one pr, so that it will be easier for others to backport your code.
thanks for your contribution.

@slfan1989 Thanks for your suggestion, I will create a draft PR to found all places of Hadoop-Hdfs module. After I completed it, I'm asking for your help to review it.

Thanks @slfan1989 for you review and nice suggestion. I will close this PR and accomplish it in HDFS-16695.


Improve the performance of start/stop function #311

This pull request for #311 .
I improved performance of start/stop function.

This change is

This have one issue #360 and we should resolve before next release..

Current coverage is 58.68% (diff: 100%)

Merging #359 into fb_k5_openstack_enhance will not change coverage

@@           fb_k5_openstack_enhance       #359   diff @@
=========================================================
  Files                         1911       1911
  Lines                        97581      97581
  Methods                          0          0
  Messages                         0          0
  Branches                     12134      12134
=========================================================
  Hits                         57270      57270
  Misses                       37295      37295
  Partials                      3016       3016

Powered by Codecov. Last update 026cf0c...a03c674

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


[DOC] - Security Overview and best practices

Preliminary Checks

[X] This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/nebari-dev/nebari/discussions

Summary
Notion Page
Steps to Resolve this Issue

...

Closing as this will need to be refined/scoped. If we have specific documentation requests around one aspect of security, we can open more targeted issues.


Atom crashes on startup

I've no idea why, but after reboot of my system, when I try to run Atom, it just show me this and nothing more:

I'm working on Ubuntu GNOME 15.10. Error:
SyntaxError: Unexpected end of input
    at Object.parse (native)
    at FileSystemBlobStore.load (/opt/atom/resources/app.asar/src/file-system-blob-store.js:31:31)
    at Function.load (/opt/atom/resources/app.asar/src/file-system-blob-store.js:10:14)
    at window.onload (file:///opt/atom/resources/app.asar/static/index.js:18:39)

I've just removed my ~/.atom folder and it started up as well. But I still dunno what was the cause of this. I hadn't installed anything and hadn't changed its configurations.

It says there was an error in BlobStore.load, so I guess your blob-store got corrupted somehow.

Had the same issue when I loaded up this morning.  Removing ~/.atom resolved my issue as well.  Thanks @denysdovhan

@cameronbarker thanks.
Looks like removing of ~/.atom/blob-store was enough to make it works again.

This is already being looked into (I can't find the original issue right now unfortunately).

@50Wliu please give us reference to original issues. Personally, I wanna get updates about fixing.

@denysdovhan Found it (it has a generic title which is why I couldn't when I briefly searched around for it): #10015.  It will be fixed by #10293.

@50Wliu ok, thanks.


Issue?+Suggestion: Inability to Achieve Transparency Animation with Glowing Eyes Effect in Version 1.21.3.

Normal Functionality in older version

To make the light effect (Glowing Eyes) fade to transparency, you typically set the color to black, while white will make it visible.
Advantages

This method allows for creating animations that fade the light in or out, revealing the texture behind.

Disadvantages

The downside is that the colors can become distorted. Even when set to pure white, the effect remains somewhat transparent.
It’s necessary to use a black background texture or adjust the white light effect's color filter to prevent excessive color distortion.

Current Issue in Version 1.21.3
In version 1.21.3, it seems there is either a bug or a recent change in the lighting system :

You can no longer make the effect transparent.
When the "Color filter" with "Glowing Eyes" is set to black, it turns completely black and is no longer transparent.
Setting it to white does not cause color distortion, as it is not transparent at all.

This change can be seen as a solution to the color distortion in transparency, but it raises the question: what if you want the effect to be transparent?

left 1.21.1 And right 1.21.3
(both are CPM 0.16.19a)
https://github.com/user-attachments/assets/e5806875-e304-462c-b195-b3a58952c4fc
File model :
TestGlowColorSetBlackto0.zip
Suggestion

I propose adding an "Alpha Color" or "Alpha Channel" in the "Color filter" bar for lights. This would ensure that colors remain unaffected when creating transparent light animations.

Impact on Older Models
Currently, older models that used this transparency technique have turned into solid black or non-transparent versions. This affects:

Effects resembling outlines of models
Barrier armor effects
Clear glass effects

1.21.1

1.21.3

no more halloween glow effect. XD
*not my model

Summary
I appreciate the new lighting system (Glowing Eyes). I'm uncertain if the lack of transparency is a bug or a fix, but it effectively prevents color distortion, which is a benefit. However, I would still like to retain the ability to create transparent light effects. Adding an "Alpha" thing in the "Color filter" specifically for animations would be ideal.
More info - Tested with

Minecraft version 1.21.3 on both Fabric and Forge
No other mods on 1.21.3
CPM 0.16.19a
AMD RX570 graphics card

I just tested version 1.21.2 and encountered the same issue.


change code a bit to also include getters and setters

I think i did everything required to work! Statically, it shows no errors - will test in practice soon :+1:
fixes #1

Thanks Mateusz, I really appreciate it.
But this will break non-stream getters, if we have something like:
int get index => _index;

because isolate communication works asynchronously,
we can use getters for streams only,
for non-stream getters maybe we can have a private stream to handle the isolate communication and a public getter to return the value we get from the stream.


Support the latest EFS client

WHAT
Upgrade EFS code to support the latest EFS client, and specify the dependency version to use aws-sdk-efs 1.13.0 or above.
WHY
Current code fails the test
Failures:

  1) Terraforming::Resource::EFSFileSystem.tf should generate tf
     Failure/Error: client.stub_responses(:describe_file_systems, file_systems: [efs_description_0, efs_description_1])

     ArgumentError:
       parameter validator found 2 errors:
         - missing required parameter params[:file_systems][0][:tags]
         - missing required parameter params[:file_systems][1][:tags]
     # ./spec/lib/terraforming/resource/efs_file_system_spec.rb:39:in `block (2 levels) in <module:Resource>'

  2) Terraforming::Resource::EFSFileSystem.tfstate should generate tfstate
     Failure/Error: client.stub_responses(:describe_file_systems, file_systems: [efs_description_0, efs_description_1])

     ArgumentError:
       parameter validator found 2 errors:
         - missing required parameter params[:file_systems][0][:tags]
         - missing required parameter params[:file_systems][1][:tags]
     # ./spec/lib/terraforming/resource/efs_file_system_spec.rb:39:in `block (2 levels) in <module:Resource>'

Finished in 2.71 seconds (files took 1.84 seconds to load)
226 examples, 2 failures

Failed examples:

rspec ./spec/lib/terraforming/resource/efs_file_system_spec.rb:43 # Terraforming::Resource::EFSFileSystem.tf should generate tf
rspec ./spec/lib/terraforming/resource/efs_file_system_spec.rb:66 # Terraforming::Resource::EFSFileSystem.tfstate should generate tfstate

Coverage remained the same at 100.0% when pulling 07543bf8c9ed9dcd9f1b3936003c18a5fb99f68e on dtan4/support-latest-efs into 1ba96b958123087dc1454e284ce34cc9c00b69a0 on master.

Coverage remained the same at 100.0% when pulling 07543bf8c9ed9dcd9f1b3936003c18a5fb99f68e on dtan4/support-latest-efs into 1ba96b958123087dc1454e284ce34cc9c00b69a0 on master.

Coverage remained the same at 100.0% when pulling 07543bf8c9ed9dcd9f1b3936003c18a5fb99f68e on dtan4/support-latest-efs into 1ba96b958123087dc1454e284ce34cc9c00b69a0 on master.

Bundler 2.x doesn't support Ruby < 2.3.
Bundler: Announcing Bundler 2.0

Removed support for Ruby < 2.3

Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Bundler could not find compatible versions for gem "bundler":
  In Gemfile:
    bundler (~> 1.7)
  Current Bundler version:
    bundler (2.0.1)
This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running `gem install bundler`?
Could not find gem 'bundler (~> 1.7)' in any of the relevant sources:
  the local ruby installation


cancel queries or timeout option

If a user writes a query that is not efficient and abandons the sqlpad query page, it appears that the database will still attempt to complete the query behind the scenes.
Can there be an option in configuration or connection to add a time out variable? Alternatively, a cancel query button on the query page? Or preferably, both.

Hi @raybuhr - I think a timeout config is something possible short-term. Eventually I'd like the ability to cancel queries as well, but that will require larger changes.
Any preference in whether timeouts are defined in configuration (for all connections) or at the connection level?
I could almost see it going both places, for specific connections to override the main config setting...
Thoughts?

I like that idea of having a global option in config and then an override option in the connection. Personally, I think having no timeout would be best for the distributed databases and a timeout of like 30 minutes on the traditional RDBMS connections.

@rickbergfalk Is this something that is working?  On version 3.1.0 I have confirmed that SQLPad times out at 2 minutes even with remote execution on MSSQL set to 10 minutes.  I am running as a Docker container.

This issue is closed in that the http timeout of 2 minutes is now configurable. What isn't addressed is that queries will keep on running in background. Fixing that requires special handling for each db driver in node unfortunately (there's no common JDBC/ODBC driver that standardizes that sort of thing). Similarly, coding a solution that allows cancelling a query would also require significant API changes and again special efforts for each db driver.
I'm not really using SQLPad much beyond it being a companion tool while working against a development database.
If anyone wants to dig into this stuff and fix it I'm open to PRs improving this, but I personally won't be putting any effort into it.

@rickbergfalk I am running latest via docker (3.4.0 at time of writing) and have added
; HTTP server timeout as number of seconds. Extend as necessary for long running queries timeoutSeconds=480
into my sqlpad.ini which is pointed to via env var SQLPAD_CONFIG /var/lib/sqlpad/sqlpad.ini, however I still experience MSSQL queries that take longer than 2 minutes to timeout exactly at the 2 minute mark.


Can you please add  analytics_Dashboard to targets? This allows us to use this component in the Tableau CRM Dashboards

What is missing from the application? Please describe.
A clear and concise description of what the problem is. Ex. I'd like to see an implementation of [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Hi @ksengodan
Thank you for opening this issue. We are working on it, we will update you in this thread once it is available.

Tableau Viz LWC is being Archived
All outstanding PRs and Issues are being addressed and closed. Please migrate to the new Tableau View LWC.
For more information about why this is happening, please see the README

@ksengodan  Analytics Studio uses the new Tableau View LWC for embedding Tableau views. The new LWC also supports embedding views published to Salesforce on lightning pages. If you have questions about using the new LWC, please open a case through Salesforce.