What about when MyStruct is !Sync + !Send but Arc<Mutex> is Send + Sync?

Normally when we have a non Sync + Send type like MyStruct, let's suppose here it's because it holds a pointer *mut u8, we actually can think of Arc<Mutex<MyStruct>> as being Sync + Send, and do something like this:
struct SafeMyStruct(Arc<Mutex<MyStruct>>);
unsafe impl Send for SafeMyStruct {}
unsafe impl Sync for SafeMyStruct {}

so the compiler knows it's safe, because we'll only access those pointers one at a time because they are protected by a Mutex.
Is this possible in downcast_rs? Here's what I tried:
use downcast_rs::{DowncastSync, impl_downcast};
use std::sync::{Arc, Mutex};

trait Base: DowncastSync {}
impl_downcast!(sync Base);

#[derive(Debug)]
struct Foo {
    x: *mut u8
}

//Make Arc<Mutex<Foo>>: Send + Sync
struct SafeFoo(Arc<Mutex<Foo>>);
unsafe impl Send for SafeFoo {}
unsafe impl Sync for SafeFoo {}

impl Base for Foo {}

fn main() {
    let mut x = 0;
    let base: Arc<Mutex<dyn Base>> = Arc::new(Mutex::new(Foo{x: &mut x}));
    let base_ = base.clone();
    std::thread::spawn(move ||{
        base_;
    });

}

Error:
error[E0277]: `*mut u8` cannot be shared between threads safely
  --> src/main.rs:16:6
   |
4  | trait Base: DowncastSync {}
   |             ------------ required by this bound in `Base`
...
16 | impl Base for Foo {}
   |      ^^^^ `*mut u8` cannot be shared between threads safely
   |
   = help: within `Foo`, the trait `Sync` is not implemented for `*mut u8`
   = note: required because it appears within the type `Foo`

error[E0277]: `*mut u8` cannot be sent between threads safely
  --> src/main.rs:16:6
   |
4  | trait Base: DowncastSync {}
   |             ------------ required by this bound in `Base`
...
16 | impl Base for Foo {}
   |      ^^^^ `*mut u8` cannot be sent between threads safely
   |
   = help: within `Foo`, the trait `Send` is not implemented for `*mut u8`
   = note: required because it appears within the type `Foo`

error: aborting due to 2 previous errors; 1 warning emitted

Even though Arc<Mutex<Foo>> is Send + Sync, it looks like it's forcing Foo to be Send + Sync, which would generate undefined behaviour if we implemented.
Is there a way to fix this?

Sorry, I did not mean !Sync + !Send, I meant simply a struct that is not Sync neither Send, for example
#[derive(Debug)]
struct Foo {
    x: *mut u8
}

when I do impl_downcast!(sync Base);, and Foo: Base, then it forces Foo to be Sync + Send, which is not great. I just want Arc<Mutex<Foo>> to be Sync + Send, it's not ok for Foo to be Sync + Send

Having Foo implement Base and thus DowncastSync would allow downcasting Arc<dyn Base> to Arc<Foo>. In other words, nothing requires there to be a Mutex.
Perhaps you want to implement Base for Mutex<Foo>, so that you can cast Arc<dyn Base> to Arc<Mutex<Foo>>. Does that make sense?

Perhaps you were suggesting adding a new DowncastWrappedInMutex (or shorter name) to support (for Base: DowncastWrappedInMutex) down-casting Arc<Mutex<dyn Base>> to Arc<Mutex<Foo>>. The issue there is that Mutex doesn't have a downcast method to use.
So I recommend the Arc<dyn Base> → Arc<Mutex<Foo>> strategy I suggested above.


Fall back to CPU requests if limit is not specified

Why are these changes needed?
Per discussion in https://github.com/ray-project/kuberay/issues/2361, it is common and often recommended that workloads specify CPU requests and NOT limits. This is to prevent premature CPU throttling from cgroups and underutilization of machine resources.
In KubeRay, you must specify limits to appropriately configure --num-cpus flag in Ray. This PR makes limits optional by looking at CPU requests for num-cpus. We only check CPU requests if limits is not specified to avoid beaking existing deployments that rely on limits.
Related issue number

Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[ ] This PR is not tested :(

This feature is highly demanded! Would allow to run multiple workloads on the same node, especially in situation where the distribution of work is random in time, then every service would be able to simply get 100% of the node CPU while the other services running on the same node are doing nothing (in particular point in time). Hope that it would be approved soon! 🤞

@kevin85421 @MortalHappiness thoughts on this PR? It shouldn't imapct any exsting RayCluster specifying limits, but it will impact existing clusters with no limits

Looks good. Old RayClusters won't be affected by this change. I manually tested it by using the following yaml file:
apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: raycluster-sample
spec:
  rayVersion: '2.9.0'
  headGroupSpec:
    rayStartParams: {}
    template:
      spec:
        containers:
        - name: ray-head
          image: rayproject/ray:2.9.0
          resources:
            requests:
              cpu: 1
              memory: 2Gi
          ports:
          - containerPort: 6379
            name: gcs-server
          - containerPort: 8265
            name: dashboard
          - containerPort: 10001
            name: client

Steps:

Build and start a kuberay operator from master branch.
Apply the yaml file above.
Shutdown the kuberay operator.
Build and start a kuberay operator from this PR.
RayCluster raycluster-sample does not restart. (Expected behavior)
Change the metadata.name field in the above yaml file to raycluster-sample-1 and apply it again.
RayCluster raycluster-sample-1 is created with num-cpus set to 1.

@andrewsykim could you fix the linter issue? Otherwise LGTM.


fix: Add optional issueLabels prop to global footer

This PR correctly submits the changes from this original PR #324  with fix prefix in order to trigger a version bump on the theme.

This didn't do trick going to resubmit in a fresh branch


LUTRAM for CologneChip?!

Prompted by this result that puts GateMate at disadvantage compared to other FPGAs in its class, potentially downgrading it to a 10K LUT device (depending on design), we wonder if there is anything that can be done about this major shortcoming, both now, with as-is silicon, and in the future.
Given our upcoming utilization and stress tests, as well as comparisons with Gowin, LatticeSemi and Xilinx, we suspect that GateMate may come out short in most of them (while claiming 20-to-40K capacity on paper, it may fill up faster than a standard 20K device from other vendors).
Hence this call to CologneChip experts for help and advice on the approaches users can take for this architectural uniqueness.

downgrading it to a 10K LUT device

Where does that number come from?

Hence this call to CologneChip experts for help and advice on the approaches users can take for this architectural uniqueness.

There are a couple of things you could do, depending on your needs.

Use synchronous RAM, there is sufficient in GateMate
Use dual-port memory and simulate asynchronous read access
Use an asynchronous FIFO, GateMate has has built-in FIFOs
If the design is not area-critical, let the synthesis emulate it using FFs

Any plans for adding LUTRAM support to future silicon devices?
Block RAM is typically insufficient in use cases with lots of small storage elements sprinkled all over the chip.
10K is an arbitrary SWAG, based on the already established datapoint for OPL3 FPGA design:

GateMate: 2842 DFFs
others:      1635 DFFs
GateMate DFF efficiency: 1635 / 2842 = 57%, i.e. close to half compared to the others.

The trouble is that building RAM from DFFs consumes not only flops, but also the LUTs and wiring. Altogether, it may create routing choke points that restrict access to resources that are nominally "free".

We've conducted tests on Gowin and CologneChip FPGAs for respective "LUTRAM" capacities. The results and the reproduction steps are published on this repo.
Tests indicate that emulating LUTRAM behaviour is costly on GateMate FPGAs and the capacities are 10x less than ones of a comparable 20k LUT FPGA. Apart from this, there is an underutilization thing happening here: GateMate chip uses a tenth of the available CPE before failing in routing.

... as predicted, the cost of GateMate LUTRAM emulation in discrete FFs is very high and twofold:

explosion of spent flip-flops
routing congestion that prevents access to resources that are nominally not spent.

Is there anything that can be improved about the latter?!
We are thinking about:

more advanced PNR routing algorithms
or unlocking secret connectivity paths that you've built into silicon, and are yet to fully activate.

@DadoCCAG,  to bring this catastrophic result up to the management attention for the next spin of the chip

True LUTRAM would be a very,  very welcome addition to GateMate silicon, one that would bring it closer to the mainstream devices

@tarik-ibrahimovic any insights you can share on the benefit (or not) of this synthesis switch?

@chili-chips-ba the experimental -luttree feature has no relation to lutrams.

I assumed that this issue is only LUTRAM-related. Nevertheless:

GateMate does not appear to have traditional LUTs, but rather MUX trees

Where does this information come from? It is wrong: It is a tree of LUT2s - with 4 configruation bits each - and is described in detail in the Primitives Library from page 53.

Let's also note that its name is a bit misleading,

Please see above, since it is LUT2 in a tree structure, the name is already very appropriate.

or unlocking secret connectivity paths that you've built into silicon, and are yet to fully activate.

There is no way to read the config bits, that we store in latches, of the LUTs back. Furthermore there is no decoding logic that can be used by the user. Therefore there is also no possibility for a LUTRAM implementation. But again: there are alternatives, as I have shown in https://github.com/chili-chips-ba/openCologne/issues/28#issuecomment-2263666636.
About the LUT-tree itself. We are currently using yosys/abc to map combinatorial logic into typical LUT4. P&R analyzes it and maps it into the LUT-trees. This is certainly not the best way to go. Yosys already supports the mapping with the -luttree flag. Instead of mapping into 8-input functions, which is too computationally intensive, we have opted for the L2T4 (LUT-tree with 4 inputs) and L2T5 (LUT-tree with 5 inputs) approach. The exact structure is documented in the Primitives Library. The approach is smart, not computationally intensive and maps logic directly to our architecture.

Why did we decide to go with a LUT-tree? It requires fewer config bits than a standard LUT4 or LUT6. It also requires less space in the silicon.
Not all features are yet supported in the P&R. That's why we marked it experimental. As soon as we finish its implementation, it certainly makes sense to activate the feature in yosys by default. Nextpnr for GateMate will only support L2T4 and L2T5.

Thank you, this is all very informative. Part of the confusion comes from the statements in the press about GateMate falling into 40K LUT4, and even 20K LUT8 category! The latter looks unique, as there are currently no FPGA devices built with LUT8 components.
While an L2T4 indeed needs 12 instead of 16 configuration latches, is a true LUT4 otherwise better than the L2T4?

Are there 4-input logic combinations that cannot be realized with L2T4 structure?
What's the cost in timing closure from additional level of logic?

Also, are there 8-input logic combinations that cannot be realized with L2T4 and L2T5 structure shown above?
When it comes to the LUTRAM alternatives, they are simply too expensive, or too scarce / too coarse-grained to count. Tarik's experiment has shown us the following:

GateMate capacity is 10x less than a comparable 20K LUT4 FPGA => It's essentially like a 2K LUT4 device in this particular aspect 😞
We also run into under-utilization, i.e. start to fail routing when only a tenth of available CPEs is used 😞

The confusion is partly from the statements in the press about GateMate falling into 40K LUT4, and even 20K LUT8 category!

Sorry, this is probably off-topic by now, but there is no Cologne Chip press in which we claim to have LUT8. The official language regulation is 4/8-input LUT-tree.

L2T4 indeed needs 12 instead of 16 configuration latches. However, is a true LUT4 otherwise better than the L2T4?

I don't know how to rate "better". In purely mathematical terms, there are obviously fewer functions that can be implemented with it. In general, it's hard to say whether this is a limitation, as not every design utilizes the full scope of the LUTs. Please take a look at the official code, which should clarify many questions.

GateMate capacity is 10x less than a comparable 20K LUT4 FPGA

Once again, under what conditions? If I fill the entire chip with LUTRAM, maybe. But then I would first think about whether it's really that clever to implement it like this, and possibly use the built-in RAM, of which there is a lot more.

We on top of that run into under-utilization, i.e. start to fail routing with only a tenth of available CPEs used

Can you open an issue for this? We've been doing stress test with almost full utilization, i.e. with https://github.com/stnolting/fpga_torture.

How about having the percentage of the 4-input logic functions that L2T4 cannot implement analyzed, calculated, and published?!


Feature Request: Ability to Log Failed Downloads in Batch Mode for Later Manual Review, Without Resorting to Aborts

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm requesting a feature unrelated to a specific site
[X] I've looked through the README
[X] I've verified that I'm running yt-dlp version 2023.07.06 (update instructions) or later (specify commit)
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Provide a description that is worded well enough to be understood
Using the "--batch-file" option to download multiple videos generates a substantial amount of output, making it difficult to identify reports of videos that failed to download. A feature that allows the URLs of videos that couldn't be downloaded to be written to a specific text file (log file) would be beneficial both for manual inspection and for allowing error logging while using "-quiet --progress-bar". Current 'abort' commands that halt the download process when failures are detected are not ideal, as they interrupt the entire operation.
Is the description of the issue itself sufficient? and Is there enough context in your bug report? In my view, yes.  If anything remains confusing, please let me know.
Are you using the latest version? Yes.
Is the issue already documented? Not that I can tell through searching open issues.
Why are existing options not enough? I do not think there are any logging options such as I describe.
Have you read and understood the changes, between youtube-dl and yt-dlp Yes.
Does the issue involve one problem, and one problem only? Yes.
Is anyone going to need the feature? Yes, I believe this would be needed widely by anyone using the --batch-file option.
Is your question about yt-dlp? Yes.
Are you willing to share account details if needed? Yes.
Is the website primarily used for piracy? No.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-quiet', '--progress', '-vU']
[debug] Portable config "C:\Users\Molly\bin\EXE\ydl\yt-dlp.conf": ['--audio-format', 'mp3', '--format', 'mp4', '-o', 'C:\\Users\\Molly\\zInboxes\\Capture\\Videos\\%(duration>%H-%M-%S)s %(title)S.%(ext)s', '--embed-subs', '--sub-lang', 'en', '--restrict-filenames', '--trim-filenames', '150', '--sponsorblock-remove', 'sponsor,interaction,selfpromo,interaction,intro,outro']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19043-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: ffmpeg n5.0-1-ga66b58d61c-20220117 (setts), ffprobe n5.0-1-ga66b58d61c-20220117, phantomjs 2.1.1
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.05.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1855 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>Current Build Hash: 5ff3e702171a50175c34397494e2d18ce35d771c2110b1e59bd173ec2fb352aa
yt-dlp is up to date<EMAIL_ADDRESS>

Related: #1760, #2668

This has been requested before, but there's no issue open afair. This is however currently difficult to implement. As workaround, you can:

Send stderr to a different log file using shell redirects
Search the combined log for lines starting in ERROR: , or
--print-to-file after_move:original_url success.txt will record all successful URLs, which you can then diff with your --batch-file

I also need similar functions,
I use in the CMD under Windows >> re-directed output content, but it only has a general log (I guess only download and download successfully downloading and running successfully)
But all error outputs are still output on the screen
How can I only output the error into the log file?
The function of this implementation is the opposite I need :)

3. --print-to-file after_move:original_url success.txt will record all successful URLs, which you can then diff with your --batch-file

Thank you, this is really useful

Use at your own risk, provided with no warranty, but would be curious about people's experiences with (and edits to, improvements upon, etc.) this.  This would be a batch file pulling in all the urls from 'inputFile', which fits my particular use case.
@echo off
setlocal

rem Get the current date and time in the format YYYYMMDDHHMMSS
for /f "tokens=2 delims==" %%i in ('wmic os get localdatetime /value ^| find "="') do set datetime=%%i
set "datetime=%datetime:~0,4%%datetime:~4,2%%datetime:~6,2%%datetime:~8,2%%datetime:~10,2%%datetime:~12,2%"

rem Paths to the input and output files
set "inputFile=urls.txt"
set "successFile=success.txt"
set "fullOutput=full_output.log"
set "errorFile=errorlog-%datetime%.txt"

rem Clear the previous success and full output logs if they exist
if exist "%successFile%" del "%successFile%"
if exist "%fullOutput%" del "%fullOutput%"

rem Download videos and log the full output
yt-dlp --batch-file="%inputFile%" --print-to-file after_move:original_url "%successFile%" > "%fullOutput%"

rem Create temporary files for comparison
set "tempInputFile=temp_input.txt"
if exist "%tempInputFile%" del "%tempInputFile%"

rem Copy original URLs to a temporary input file
for /f "usebackq tokens=*" %%i in ("%inputFile%") do echo %%i >> "%tempInputFile%"

rem Compare the original list with the successful URLs to find failures
for /f "usebackq tokens=*" %%i in ("%tempInputFile%") do (
    findstr /i /c:"%%i" "%successFile%" >nul
    if errorlevel 1 echo %%i >> "%errorFile%"
)

rem Clean up temporary files
del "%tempInputFile%"

endlocal

Here is a batch file that handles an input file and then writes anything with the "ERROR" prefix during the output into a separate file.  Use at your own risk and no warranty is offered, but it should work ...
@echo off
setlocal

rem Check if the input file argument is provided
if "%~1"=="" (
    echo Usage: %~nx0 inputfile
    exit /b 1
)

rem Get the input file from the command-line argument
set "inputFile=%~1"

rem Verify the input file exists
if not exist "%inputFile%" (
    echo The input file "%inputFile%" does not exist.
    exit /b 1
)

rem Get the current date and time in the format YYYYMMDDHHMMSS
for /f "tokens=2 delims==" %%i in ('wmic os get localdatetime /value ^| find "="') do set datetime=%%i
set "datetime=%datetime:~0,4%%datetime:~4,2%%datetime:~6,2%%datetime:~8,2%%datetime:~10,2%%datetime:~12,2%"

rem Paths to the output files
set "fullOutput=full_output.log"
set "errorFile=errorlog-%datetime%.txt"
set "tempErrorFile=temp_error.txt"

rem Clear previous logs if they exist
if exist "%fullOutput%" del "%fullOutput%"
if exist "%errorFile%" del "%errorFile%"
if exist "%tempErrorFile%" del "%tempErrorFile%"

rem Download videos and log the full output
yt-dlp --batch-file="%inputFile%" > "%fullOutput%" 2>&1

rem Extract lines containing errors and save to temporary error file
findstr /r /c:"ERROR: " "%fullOutput%" > "%tempErrorFile%"

rem Remove "ERROR: " from the beginning of each error line and save to final error file
for /f "tokens=*" %%i in (%tempErrorFile%) do (
    set "line=%%i"
    setlocal enabledelayedexpansion
    echo !line:ERROR: =! >> "%errorFile%"
    endlocal
)

rem Cleanup temporary file
del "%tempErrorFile%"
del "%fullOutput%"

endlocal


add helpers to prompt users to upgrade their manage tool

now that we're linking versions, its much more important for them to update the boot2docker tool too.

Sorry, this repository is long-since deprecated in favor of Docker Toolbox (whose usage is now also discouraged in favor of Docker for Windows and Docker for Mac).


Support storage buffers in derive AsBindGroup

Objective

Storage buffers are useful and not currently supported by the AsBindGroup derive which means you need to expand the macro if you need a storage buffer

Solution

Add a new #[storage] attribute to the derive AsBindGroup macro.

Support and optional read_only parameter that defaults to false when not present.
Support visibility parameters like the texture and sampler attributes.

Changelog

Add a new #[storage(index)] attribute to the derive AsBindGroup macro.

Sorry to be push-y but what is the status of this PR?

It just needs people to review it and approve it and nobody has done it yet.

Could you add an example for this attribute?
Maybe at the doc example here https://github.com/bevyengine/bevy/blob/main/crates/bevy_render/src/render_resource/bind_group.rs#L79, and also updating what the wgsl would look like

Done.
The example also uses the read_only attributes in parts because it's nice to show the feature, but also because it's the default when using var<storage> in wgsl.

Yes, I originally created this PR when working on https://github.com/IceSentry/bevy_prototype_frametime_display_plugin because I wanted to use a storage buffer to store the array of frametimes so I was forced to not use the Material abstraction. I've also seen a couple of people ask for it on discord.
My goal was mainly to make the Material abstraction more general and support more features.

I need this feature to render gradients. Since the stops and colors are dynamic, I need a storage buffer to store them.


nodeadm: add retry until daemon is detected running

Issue #, if available:
more general attempt than https://github.com/awslabs/amazon-eks-ami/pull/1942 at solving the related issue
Description of changes:
revamp the retrier helper a bit and block on daemon EnsureRunning impls to guarantee the service is up before continuing with the rest of the bootstrap.

fixed a bug in how GetDaemonStatus was implemented for systemd. The current implementation was using the string value of a pointer rather than the value of the systemd property.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Testing Done
built a dev ami and verified completion of the bootstrap. also logged the GetDaemonStatus calls on a dev ami, and recorded 10 second transition from activiting to active for both containerd and kubelet.
This increases the total time-to-node-join metric, but would reduce potential retries in other parts of the bootstrap where connectivity to containerd or etc is required.

nodeadm test logs
[root@ip-172-31-15-250 ~]# journalctl -u nodeadm-run
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal systemd[1]: Starting nodeadm-run.service - EKS Nodeadm Run...
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.7596016,"caller":"init/init.go:54","msg":"Checking user is root.."}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.7599344,"caller":"init/init.go:62","msg":"Loading configuration..","configSource":"imds://user-data"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.7624507,"caller":"init/init.go:71","msg":"Loaded configuration","config":{"metadata":{"creationTimestamp":null},"spec":{"cluster":{"name":"my-cluster","apiServerEndpoint":">
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.7627125,"caller":"init/init.go:73","msg":"Enriching configuration.."}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.762764,"caller":"init/init.go:153","msg":"Fetching instance details.."}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: SDK 2024/09/16 20:07:51 DEBUG attempting waiter request, attempt count: 1
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9515529,"caller":"init/init.go:166","msg":"Instance details populated","details":{"id":"i-0eac6143cb37792cb","region":"us-west-2","type":"m1.small","availabilityZone":"us-w>
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9515986,"caller":"init/init.go:167","msg":"Fetching default options..."}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9525166,"caller":"init/init.go:175","msg":"Default options populated","defaults":{"sandboxImage":"602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/pause:3.5"}}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9526398,"caller":"init/init.go:78","msg":"Validating configuration.."}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9526534,"caller":"init/init.go:83","msg":"Creating daemon manager.."}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9537528,"caller":"init/init.go:117","msg":"Setting up system aspects..."}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9538164,"caller":"init/init.go:120","msg":"Setting up system aspect..","name":"local-disk"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.95388,"caller":"system/local_disk.go:26","msg":"Not configuring local disks!"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9539227,"caller":"init/init.go:124","msg":"Set up system aspect","name":"local-disk"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9539704,"caller":"init/init.go:120","msg":"Setting up system aspect..","name":"networking"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9540231,"caller":"system/networking.go:79","msg":"writing eks_primary_eni_only network configuration"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.965532,"caller":"init/init.go:124","msg":"Set up system aspect","name":"networking"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517271.9656186,"caller":"init/init.go:133","msg":"Ensuring daemon is running..","name":"containerd"}
Sep 16 20:07:51 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:52 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:52 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:52 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:52 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:53 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:53 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:53 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:54 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:54 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:54 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:54 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:55 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:55 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:55 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:55 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:56 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:56 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:56 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:56 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:57 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:57 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:57 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:57 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:58 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:58 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:58 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:58 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:59 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:59 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:59 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:07:59 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:00 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:00 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:00 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:00 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of containerd.service : "activating"
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517281.810569,"caller":"init/init.go:137","msg":"Daemon is running","name":"containerd"}
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517281.810625,"caller":"init/init.go:139","msg":"Running post-launch tasks..","name":"containerd"}
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517281.810633,"caller":"containerd/sandbox.go:21","msg":"Looking up current sandbox image in containerd config.."}
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517281.9384398,"caller":"containerd/sandbox.go:33","msg":"Found sandbox image","image":"602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/pause:3.5"}
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517281.948726,"caller":"containerd/sandbox.go:35","msg":"Fetching ECR authorization token.."}
Sep 16 20:08:01 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517281.9796603,"caller":"containerd/sandbox.go:49","msg":"Pulling sandbox image..","image":"602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/pause:3.5"}
Sep 16 20:08:02 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517282.8603086,"caller":"containerd/sandbox.go:54","msg":"Finished pulling sandbox image","image-ref":"sha256:6996f8da07bd405c6f82a549ef041deda57d1d658ec20a78584f9f436c9a3bb7"}
Sep 16 20:08:02 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517282.8603635,"caller":"init/init.go:143","msg":"Finished post-launch tasks","name":"containerd"}
Sep 16 20:08:02 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517282.8603747,"caller":"init/init.go:133","msg":"Ensuring daemon is running..","name":"kubelet"}
Sep 16 20:08:02 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:03 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:03 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:03 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:03 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:04 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:04 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:04 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:04 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:05 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:05 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:05 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:05 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:06 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:06 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:06 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:06 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:07 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:07 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:07 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:07 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:08 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:08 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:08 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:08 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:09 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:09 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:09 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:09 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:10 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:10 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:10 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:10 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:11 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:11 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:11 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:11 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:12 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:12 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:12 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:12 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:13 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:13 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:13 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: status of kubelet.service : "activating"
Sep 16 20:08:14 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517294.0026217,"caller":"init/init.go:137","msg":"Daemon is running","name":"kubelet"}
Sep 16 20:08:14 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517294.002651,"caller":"init/init.go:139","msg":"Running post-launch tasks..","name":"kubelet"}
Sep 16 20:08:14 ip-172-31-15-250.us-west-2.compute.internal nodeadm[2131]: {"level":"info","ts":1726517294.0026739,"caller":"init/init.go:143","msg":"Finished post-launch tasks","name":"kubelet"}

See this guide for recommended testing for PRs. Some tests may not apply. Completing tests and providing additional validation steps are not required, but it is recommended and may reduce review time and time to merge.

/ci
+workflow:os_distros al2023

/ci
+workflow:os_distros al2023

/ci
+workflow:os_distros al2023

should be the last one 🤞
/ci
+workflow:os_distros al2023

fyi @ndbaker1 you should be able to just use slash ci, it'll target al2023 if the only change is in nodeadm 👍


Update Core Tech: Sidekiq Gem

[ ] Understand if methods were deprecated by gem owners.
[ ] Find new methods that are of value (useful to our customers)
[ ] Instrument those new methods
[ ] Update our multiverse to dynamically pull the latest version so that we do not have to manually update each gem version number manually.

Relates to #1479

Relates to #1567

Since Sidekiq::Extensions::DelayedClass has been removed from Sidekiq 7.0 and put into a separate Gem, this would also need to be added to the newrelic ruby agent:
https://github.com/gemhome/sidekiq-delay_extensions

Thank you, @daskycodes!

The embedded feature described in the 7.0 upgrade guide appears to be working well with the agent from what I've tested. All the expected data is showing up and everything looks the same as when it is not used. It doesn't look like there is anything additional that would need to be recorded for it either, since it's basically just running the server inside the main application rather than a different process.
Sidekiq metrics is info is discussed here https://github.com/newrelic/newrelic-ruby-agent/issues/1479
I didn't get a chance to look into the capsules or redis related items mentioned in the upgrade guide.

@tannalynn  - Thanks for looking into this! From your analysis, it seems like we don't have any action to take to update Sidekiq instrumentation this time around. Is this issue safe to close out? Or would you prefer we look into capsules and Redis-related items first?

Thanks for looking into this! From your analysis, it seems like we don't have any action to take to update Sidekiq instrumentation this time around. Is this issue safe to close out? Or would you prefer we look into capsules and Redis-related items first?

It doesn't seem like there is anything with those that would make sense for us to instrument really, even though I didn't have a chance to really dig into them. I think at this point it makes sense to close it out.


Update scala-library to 2.12.16

Updates org.scala-lang:scala-library from 2.12.15 to 2.12.16.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (2.12.15).
You might want to review and update them manually.
.github/workflows/ci.yml

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala-library" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.scala-lang", artifactId = "scala-library" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Coverage decreased (-0.3%) to 33.621% when pulling 105e7138ab374cf210a43968f2a7c31806e8811d on scala-steward:update/scala-library-2.12.16 into d082b04ae38161e522ab7991a62ceff130832f4e on evolution-gaming:master.

Superseded by #89.


Traefik ingress default bind port

Hello,
i would like to install k3s alongside an existing nginx on my single node bare metal server but i would still like to use your traefik ingress. The proble is that if i install k3s with its default traefik it binds to port 80 and 443 on localhost and i cannot access my self hosted websited anymore. What i owuld like to do is terminate SSL at my nginx and then forward to my traefik.

Can you check out these docs and let me know if they give you sufficient guidance?
https://rancher.com/docs/k3s/latest/en/networking/#traefik-ingress-controller

Thanks for the help. I already discovered the link but it didnt really help me. I tried a few modifications on the deployed manifest like deployment.hostPort.httpsEnabled true and deployment.hostPort.httpsPort 444 but that only adds an additioanl bind for 444 along the existing 443. I think i have to modify the underlying traefik service but i am not sure how to do it.

@marcoceppi we are using stable/traefik helm chart to deploy the ingress controller with service type LoadBalancer, and the ports there are hardcoded to 443 and 80 https://github.com/helm/charts/blob/master/stable/traefik/templates/service.yaml, as a workaround you can either:

edit the traefik service after deployment and change the port from 80 and 443 to whatever you like
or
add serviceType: NodePort and use service.nodePorts.https option to use different nodeport port on the host

Afaik, the ports will be reset everytime k3s starts. How do you work around this? My idea is that you should put a "patch" file in the same folder alongside /var/lib/rancher/k3s/server/manifests/traefik.yaml. How should this yaml file look like? Any other solution?

@biels https://rancher.com/docs/k3s/latest/en/helm/#customizing-packaged-components-with-helmchartconfig

For anyone else struggling with this, here's how to do it:

Create file /var/lib/rancher/k3s/server/manifests/traefik-config.yaml with contents:

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ports:
      web:
        exposedPort: 8080
      websecure:
        exposedPort: 8443

Apply changes with sudo kubectl apply -f /var/lib/rancher/k3s/server/manifests/traefik-config.yaml

does anyone know: how come the config says exposedPort: 80 and yet in reality it picks a random one every time k3s starts up?

What exactly are you talking about? The service is exposed externally on port 80, but the node ports are randomly assigned. Thats just how it works.

@SandroHc solution won't work for me, I'm confused, i literally copied what he posted, checked docs which say the same thing, but ports are not changed. What to do ?


Added solution to Add Flex Superpowers to the Tweet Embed challenge

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

Closes #XXXXX

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


WIP: Simple tagging system for Internet Exchanges

Implement a simple tagging system for Internet Exchanges.
Fixes:

Add django-taggit, modified the Internet Exchange model in peering/models.py (implemented per their guide)
Add django-taggit-serializer, so tags show up within the REST API (implemented per their guide)

Note: this should still be classified as work in progress, as the UI does not show tags or grant the user the ability to add tags. Tags can only be added within the Admin Area or within the API. I am unsure about the UI implementation which is the reason why it is not included in this PR.

Turns out tag changes sent via the API we're not saved, fixed in latest commit.

I'm closing this PR since the tags work is currently done in the tags branch. Thanks for starting to work on this feature.


Suggestion to add a basic command to work with Typescript

Hello,
thank you for the lib! Great job!
I'd be interested in trying it out, but I don't know how to make it work with TypeScript.
I'm not so familiar with babel, but I guess it can be done using different script switches in package.json.
It'd be great if you could update the docs, to include just bare-bones info on how to get started with this lib and TS.
Thank you in advance!

Hi @paroxyzm
I had the same issue for a while but I figured it out.
The solution is a little weird but it's just the way that babel works.
Babel needs some extra configuration for the file extensions that cannot be provided in your .babelrc file.

Make sure you have @babel/preset-typescript installed as a dev dependency.
Add it as a preset in your .babelrc file.
Create a file called babel-register.js in your  project.
Open the file and write the following code.

const register = require('@babel/register').default;

register({extensions: ['.js', '.ts', '.jsx', '.tsx']});

In your package.json file in the "test": "" script require the file you just created:

"test": "nyc riteway -r @babel/polyfill 'src/**/*.test.js' -r './babel-register.js' | tap-nirvana"

Run yarn test

I hope this helps.
This is just one way of doing it. There might be other methods, but this is the first one I came across that worked.
As an aside, I would not recommend writing your tests in TypeScript. See the article Eric wrote here.

Another way is install ts-node and use transpilation:
riteway --require ts-node/register/transpile-only src/**/*.test.ts


Feature Layer Not Present in Pre-build Image

I have a private feature which creates and adds a user to the underlying container. The feature passes all of its tests; it definitely correctly creates a user. I've published the feature image to the GitHub container registry.
When I use this feature with a Dev Container, it works fine. For some reason, when I pre-build and push the Dev Container's image to GHCR, the user is no longer present in the pre-built image.
When I look at the build logs, the feature is definitely being installed. For some reason, all of the "work" that feature does is not present in the pre-built image.
Do you have any suggestions for troubleshooting this issue?

For context, the image is being published with a namespace "/devcontainers/". Is having multiple forward slashes an issue?

I think I found the issue... I had thought that ${localENV:...} variables were evaluated on each individual user's machine. It appears that localEnv is evaluated when images are pre-built. Is there any way to prebuild an image that looks for local environment variables when the image is used?

I think I found the issue... I had thought that ${localENV:...} variables were evaluated on each individual user's machine. It appears that localEnv is evaluated when images are pre-built. Is there any way to prebuild an image that looks for local environment variables when the image is used?

You could add an ENTRYPOINT or CMD to the Dockerfile that runs when the container is started. Make sure to use "overrideCommand": false to get it to run. You could use "containerEnv": { } to pass values to it.

Could I pre-build the image, and have a user of the image specify "containerEnv": {"USERNAME": "${localEnv:USER}"}"?


Upgrade to ember-decorators 2.1.0

Purpose
Update to latest ember-decorators, which includes updated type definitions for @ember-decorators/data.
Summary of Changes

upgrade to ember-decorators 2.1.0
remove local @ember-decorators/data type definition overrides.

Side Effects / Testing Notes
n/a
Ticket
n/a
Reviewer Checklist

[ ] meets requirements
[ ] easy to understand
[ ] DRY
[ ] testable and includes test(s)
[ ] changes described in CHANGELOG.md

Coverage remained the same at 56.936% when pulling bd2492275f45d01deeb03e970954e177e20efcf8 on jamescdavis:update_to_latest_ember_decorators into 0fba1f0be13b18855c481fa8f20a6172101b1e6e on CenterForOpenScience:develop.


Support asm_group_id option.

This Sendgrid feature is described in full here: https://sendgrid.com/docs/User_Guide/Suppressions/advanced_suppression_manager.html

i suppose in this commit mail.data['asm_group_id'] has to be mail. smtpapi.data['asm_group_id']

True. Trying to land #23


Added a pip requirements text file

Installed BS4 and used pip freeze > requirements.txt to pipe the
output into a text file.
Fixes #14

I will merge this since nobody was assigned to the issue. But be sure to always communicate that you are working in an issue and that it hasn't been already assigned to anyone else

Ah my apologies. I will remember to inform that I'm working on an issue next time!


Black quad on metal

Rendering a quad with a texture works fine on OpenGL on mono on mac.
But switching the backend to Metal and the quad is rendered black.
Note that the original textured cube sample does render fine on both OpenGL and mono. The difference, as far as I'm aware, is that I'm loading my png texture with system.drawing and the image uses a different pixel format.
To reproduce:
Run MonoQuad from here, see the 2 quads being rendered.
Then change the backend to metal here and see the black quads.

@tzachshabtay The problem here is that you are specifying a depth of 0 in your UpdateTexture call. This means that you've effectively asked to copy an empty region. Even when copying 2D regions, the depth parameter should be 1.
The OpenGL backend is ignoring the depth parameter for 1D and 2D copies, which it shouldn't be doing. Fixing that will align the backends, but you'll still need to pass 1 for the depth to get anything to render.

Is there a valid use-case for passing 0?
If not, maybe an exception should be thrown for 0 (and negative numbers).

There's not really a use-case in the senes that it is effectively a no-op. However, it could be useful if the texture region's dimensions were computed from some other information in your application -- having to special case an empty region just to avoid the exception would be annoying. Logically, there's nothing wrong with asking to update an empty region. Further, all the native API's allow it, so it seems best to just keep the current behavior.


KAFKA-12210; AdminClient should use DescribeCluster API when available

This PR updates the AdminClient to use the DescribeCluster API when available. The clients fails back to the Metadata API otherwise.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Failed tests are not related to this PR:

Build / JDK 11 / org.apache.kafka.clients.consumer.internals.FetcherTest.testEarlierOffsetResetArrivesLate()
Build / JDK 15 / org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationSSLTest.testOneWayReplicationWithAutoOffsetSync()
Build / JDK 8 / org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationSSLTest.testOneWayReplicationWithAutoOffsetSync()

Failed tests are not related to this PR:

Build / JDK 11 / org.apache.kafka.clients.consumer.internals.FetcherTest.testEarlierOffsetResetArrivesLate()
Build / JDK 15 / org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationSSLTest.testOneWayReplicationWithAutoOffsetSync()
Build / JDK 8 / org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationSSLTest.testOneWayReplicationWithAutoOffsetSync()


istio-proxy don't respect ProxyConfig terminationDrainDuration 30s

Bug Description
I am trying to change the default terminationDrainDuration from 5s to 30s. However, I do not see the change appearing because the proxy logs are saying:
2023-05-01T18:25:20.227362Z	info	Agent has successfully terminated
2023-05-01T18:25:20.227349Z	info	Envoy aborted normally
2023-05-01T18:25:20.227143Z	warn	Aborting proxy
2023-05-01T18:25:20.227079Z	info	There are no more active connections. terminating proxy...
2023-05-01T18:25:20.155936Z	warn	Envoy proxy is NOT ready: server is not live, current state is: DRAINING
2023-05-01T18:25:19.220727Z	info	Checking for active connections...
2023-05-01T18:25:18.156447Z	warn	Envoy proxy is NOT ready: server is not live, current state is: DRAINING
2023-05-01T18:25:16.156685Z	warn	Envoy proxy is NOT ready: server is not live, current state is: DRAINING
2023-05-01T18:25:14.220630Z	info	Agent draining proxy for 5s, then waiting for active connections to terminate... <- still default 5s
2023-05-01T18:25:14.219331Z	info	Agent draining Proxy
2023-05-01T18:25:14.219319Z	info	Status server has successfully terminated

My helm chart config:
meshConfig:
    defaultConfig:
      terminationDrainDuration: 30s
      proxyMetadata:
        EXIT_ON_ZERO_ACTIVE_CONNECTIONS: 'true'

My proxy config_dump:
kubectl exec my-service-7d846b757c-nh4cn -c istio-proxy -- pilot-agent request GET config_dump |grep -i terminationDrainDuration
       "terminationDrainDuration": "30s"

My all config_dump:
kubectl exec my-service-7d846b757c-nh4cn  -c istio-proxy -- pilot-agent request GET config_dump
....
"PROXY_CONFIG": {
       "serviceCluster": "istio-proxy",
       "drainDuration": "45s",
       "tracing": {
        "zipkin": {
         "address": "jaeger-jaeger-operator-jaeger-collector.tracing:9411"
        }
       },
       "statNameLength": 189,
       "binaryPath": "/usr/local/bin/envoy",
       "controlPlaneAuthPolicy": "MUTUAL_TLS",
       "concurrency": 2,
       "statusPort": 15020,
       "configPath": "./etc/istio/proxy",
       "terminationDrainDuration": "30s",
       "discoveryAddress": "istiod.istio-system.svc:15012",
       "parentShutdownDuration": "60s",
       "proxyAdminPort": 15000,
       "proxyMetadata": {
        "EXIT_ON_ZERO_ACTIVE_CONNECTIONS": "true"
       }
      }
....

The config  terminationDrainDuration: 30s already appeared in my config_dump but as you can see in the logs above. It's still default 5s for draining....
Question:

What is wrong with my config and how to change to default terminationDrainDuration from 5s -> whatever I want

Version
istioctl version
client version: 1.17.2
control plane version: 1.15.2
data plane version: 1.15.2 (20 proxies)

kubectl version --short
Client Version: v1.24.0
Kustomize Version: v4.5.4
Server Version: v1.25.8-gke.500

helm version --short
v3.8.2+g6e3701e

Additional Information
No response
Affected product area

[ ] Ambient
[ ] Docs
[X] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[X] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Control Plane Revisions

Hmm, this all looks right from config perspective. Will need to take another look.
Note 1.15 is EOL; it's plausible this has been fixed since then

Hmm, this all looks right from config perspective. Will need to take another look.
Note 1.15 is EOL; it's plausible this has been fixed since then

let me test with one more scenario by removing:         EXIT_ON_ZERO_ACTIVE_CONNECTIONS: 'true'

oh if you have that set then it intentional iirc, it waits 5s for any new
open connections (takes some time to tell clients to stop) then terminates
when there are no connections
On Mon, May 1, 2023, 8:26 PM Thien Chuong @.***> wrote:

Hmm, this all looks right from config perspective. Will need to take
another look.
Note 1.15 is EOL; it's plausible this has been fixed since then
let me test with one more scenario by removing: EXIT_ON_ZERO_ACTIVE_CONNECTIONS:
'true'
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/44690#issuecomment-1530818090, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXJGTZSYD3IJJUE4FPDXEB5EXANCNFSM6AAAAAAXSOE7NE
.
You are receiving this because you commented.Message ID:
@.***>

Hi @howardjohn, I was able to identify the root cause. The source code (https://github.com/istio/istio/blob/fb5353b54abb148156851d4e1b60aedcc8aa264f/pkg/envoy/agent.go#L136) makes it very clear. If we enable the EXIT_ON_ZERO_ACTIVE_CONNECTIONS which means we skip the terminationDrainDuration, we should use the MINIMUM_DRAIN_DURATION instead. The valid config must be:
meshConfig:
    defaultConfig:
      proxyMetadata:
        EXIT_ON_ZERO_ACTIVE_CONNECTIONS: 'true'
        MINIMUM_DRAIN_DURATION: '30s'

MINIMUM_DRAIN_DURATION will be executed first, then it'll check active connection and exit when it becomes 0.
Why do you even need to set a static 30s before dynamic connection check? Why not just set to 0, and have EXIT_ON_ZERO_ACTIVE_CONNECTIONS  to determine when to shutdown the istio proxy sidecar?

@chuong-ts
MINIMUM_DRAIN_DURATION will be executed first, then it'll check active connection and exit when it becomes 0.
Why do you even need to set a static 30s before dynamic connection check? Why not just set to 0, and have EXIT_ON_ZERO_ACTIVE_CONNECTIONS  to determine when to shutdown the istio proxy sidecar?


Update gpt-4o pricing and add gpt-4o-mini model

Pricing: https://openai.com/api/pricing/

Closing this PR as this fork seems actively maintained: https://github.com/animalnots/BetterChatGPT-PLUS


iac-repository is broken due to manual terraform state file changes

Accidentally created story in clubhouse and not here. will do better next time ;)

Story details: https://app.clubhouse.io/mineiros/story/241

changes

be more verbose in the Makefile
remove additional tags
when pushing: We always create latest tag + $DOCKER_IMAGE_TAG (when tagged with version)
store image in a hardcoded filename docker-image.tar
only use tags in the promotion to docker hub
only push latest tag when tag starts with v

the scope is the PR is to fix the situation... not to improve or make it perfect...


Ports field is required for services of type ExternalName

In the kubernetes documentation it states:

An ExternalName service is a special case of service that does not have selectors. It does not define any ports or endpoints. Rather, it serves as a way to return an alias to an external service residing outside the cluster.

However, helm requires all services have a ports field or else the chart will not install.

Helm should not require anything about a service other than that it is in a valid format. Can you drop in the error message you are seeing?

The error is Error: error validating "": error validating data: field ports: is required.  If I remove the service file or add some dummy ports then the error goes away.

That error is bubbling up from the Kubernetes validator. You can try running helm install --dry-run --debug and then using kubectl to send the manifest to Kubernetes. That might shed light on what is going on.

I tried running helm install --dry-run --debug $CHART_DIR and I got the same error.

Error: error validating "": error validating data: field ports: is required

Is there a way to bypass the validation step?

try --verify=false?

You can also try helm lint $CHART_DIR.

Or use the helm template plugin.
 Helm doesn't do its own validation. It just validates against Kubernetes. So if that step is failing here, there is a high, high probability that it will fail anytime it is submitted to the Kubernetes server.
Without seeing the manifest or template, there's not much we can do to help out.

closing this as inactive. Please re-open if you have more info to share. Thanks!