Helm discovery report

I started using Helm this week and spent  ~20 hours playing with Helm. I thanks all the team for this project.
I wanted to share a discovery report. I might say things that can already be doable but in this case I would suggest to consider to clarify the doc since I read carefully the doc and didn't find my answer.

when I write helm install nginx-ingress I would expect nginx-ingress to be added to requirements.yaml

"release" keyword is misleading. I started calling my releases v1, v2, v3 etc and then I understood that release is actually an instance of the chart.

I would like to decorelate the fact to add a dependency to the chart I'm building and to deploy the dependency. I would expect helm install xxx to fetch the dependency and add it to my list of dependencies. Nothing more. helm deploy would then connect to my cluster.

I'm still struggling to build my charts with a dependency used twice. For example I use https://hub.helm.sh/charts/incubator/aws-alb-ingress-controller and would like to instanciate this chart twice. To do so I would love to write something like this in values.yaml:

aws-alb-ingress-controller:
  instance1:
    namespace: 'default'
    autoDiscoverAwsRegion: true
    autoDiscoverAwsVpcID: true
  instance2:
    namespace: 'monitoring'
    autoDiscoverAwsRegion: true
    autoDiscoverAwsVpcID: true

It's really surprising that some of the most used Helm charts are not in a standard repository. I would like to be able to write helm install nginx-ingress without adding a repo first.

I don't know if this feedback will be deprecated in helm 3 but I don't want to install tiller and thus I use helm like this: helm template --name main . -f config.yaml | kubectl apply -f - which seems to be a trick. I spent hours to find this solution but it seems to me that it should be the standard way to do.

Thanks @nicgirault for your detailed feedback on Helm. I will try and tackle all comments here.

when I write helm install nginx-ingress I would expect nginx-ingress to be added to requirements.yaml

helm install nginx-ingress will render the chart (nginx-ingress) and deploy the  resources into the Kubernetes cluster. If the chart has subcharts defined in the requirements.yaml, it will also install those dependencies.  Refer to doc for more information on dependencies.

"release" keyword is misleading. I started calling my releases v1, v2, v3 etc and then I understood that release is actually an instance of the chart.

I agree that the release keyword can be confusing. It is however what has been used as the chart instance. The glossary is a usual reference for the components of Helm.

I would like to decorelate the fact to add a dependency to the chart I'm building and to deploy the dependency. I would expect helm install xxx to fetch the dependency and add it to my list of dependencies. Nothing more. helm deploy would then connect to my cluster.

It is not working for you as expected? You do have to request download of dependencies after adding the dependencies to the requirements file. helm dependency update will use your dependency file to download all the specified charts into your charts/ directory for you. Refer to dependencies for more information.

I'm still struggling to build my charts with a dependency used twice. For example I use https://hub.helm.sh/charts/incubator/aws-alb-ingress-controller and would like to instanciate this chart twice. To do so I would love to write something like this in values.yaml:

I am not sure how best to workaround this as this does not seem to be supported.  Maybe some might be able to provide an insight?

It's really surprising that some of the most used Helm charts are not in a standard repository. I would like to be able to write helm install nginx-ingress without adding a repo first.

It might be best to ask the chart maintainers in the charts slack channel about this.

I don't know if this feedback will be deprecated in helm 3 but I don't want to install tiller and thus I use helm like this: helm template --name main . -f config.yaml | kubectl apply -f - which seems to be a trick. I spent hours to find this solution but it seems to me that it should be the standard way to do.

Yes, Tiller is removed in Helm 3.  There are some good docs/blogs on Tillerless Helm as follows:

https://helm.sh/docs/using_helm/#installing
https://rimusz.net/tillerless-helm

Also as you have shown, using helm template and piping to kubectl works well.

@nicgirault FYI, the helm users slack channel is a good place to reach out and ask any questions.

I'm going to close this ticket due to inactivity, but please re-open if this still needs to be addressed. Thanks!


ChunkLoadEvent and ChunkUnloadEvent never fire after upstream changes

Spark link
Not Relevant
Expected behavior
ChunkLoadEvent and ChunkUnloadEvent should fire regularly as chunks load and unload.
Observed/Actual behavior
These events do not fire at all as of today's Purpur build 2266.
Steps/models to reproduce
Added to test plugin:
    @EventHandler
    public void onChunkLoad(ChunkLoadEvent event) {
        getLogger().info("Chunk load " + event.getChunk().getX() + " " + event.getChunk().getZ());
    }

    @EventHandler
    public void onChunkUnLoad(ChunkUnloadEvent event) {
        getLogger().info("Chunk UNload " + event.getChunk().getX() + " " + event.getChunk().getZ());
    }

    @EventHandler
    public void onPlayerMove(PlayerMoveEvent event) {
        // Control test to verify that events do fire
        getLogger().info(event.getTo().getX() + " " + event.getTo().getY() + " " + event.getTo().getZ());
    }

Join the server and confirm that the move event correctly logs positions as a control test, but the other two events never fire.
Purpur version
Self-built Purpur 2266, 86a65436
Agreements

[X] I am running the latest version of Purpur available from https://purpurmc.org/downloads.
[X] I have searched for and ensured there isn't already an open issue regarding this.
[ ] I ticked all the boxes without actually reading them
[X] My version of Minecraft is supported by Purpur.

Other
The same test plugin was tested on the following:

Paper 1.21 build 89 ("fix exact choice shapeless recipes", 44c3dd0) (working)
Purpur 1.21 build 2265 (8f0f20d) (working)
Purpur 1.21 build 2266 (86a6543) (NOT working)

I would also add that this was discovered in part because WorldGuard depends on these events, and regions do not appear to load at all when the events are not fired. That means that servers updating to this version will likely lose world protection entirely.

@joshuaprince Since these are paper upstream commits you'll want to test this on Paper builds too. Purpur build 2266 merges in changes from Paper builds 82-89.

Oh I completely missed that you already tested on latest Paper. Will look into this.

@granny It looks like java/ca/spottedleaf/moonrise/common/util/ChunkSystem.java isn't patched the same way Paper's version is. I'm trying to track down why, but you'll probably beat me to it.
Paper:
    public static void onChunkBorder(final LevelChunk chunk, final ChunkHolder holder) {
        // TODO move hook
        io.papermc.paper.chunk.system.ChunkSystem.onChunkBorder(chunk, holder);
        chunk.loadCallback(); // Paper
    }

    public static void onChunkNotBorder(final LevelChunk chunk, final ChunkHolder holder) {
        // TODO move hook
        io.papermc.paper.chunk.system.ChunkSystem.onChunkNotBorder(chunk, holder);
        chunk.unloadCallback(); // Paper
    }

Purpur:
    public static void onChunkBorder(final LevelChunk chunk, final ChunkHolder holder) {
        ((ChunkSystemServerLevel)((ServerLevel)chunk.getLevel())).moonrise$getLoadedChunks().add(
                ((ChunkSystemLevelChunk)chunk).moonrise$getChunkAndHolder()
        );
    }

    public static void onChunkNotBorder(final LevelChunk chunk, final ChunkHolder holder) {
        ((ChunkSystemServerLevel)((ServerLevel)chunk.getLevel())).moonrise$getLoadedChunks().remove(
                ((ChunkSystemLevelChunk)chunk).moonrise$getChunkAndHolder()
        );
    }

loadCallback and unloadCallback are responsible for calling these events, and the definitions for both show gray in my IDE, indicating that they're unused.

The copy of Paper that you're traversing is outdated by 4 commits. Leaf moves ChunkSystem under a different package in the following commit: https://github.com/PaperMC/Paper/commit/00b949f1bbbf444e2b5e7b8de7c9b14fbd2133c6

You're right, trying it again on a freshly-cleaned Paper repo, I can reproduce it there too. I'll open an issue on their tracker.

https://github.com/PaperMC/Paper/issues/11103

I've created a PR to Paper fixing this issue here: https://github.com/PaperMC/Paper/pull/11104. I've also gone ahead and applied it to Purpur ahead of time since I'm getting ready for bed (and won't be able to upstream until I wake up!).


"Please check that you properly call the callback!"

What issue do you have? Please be as thorough and explicit as possible.
At first I thought this was more of a global issue but have been able to narrow it down to govee only devices that are controlled via voice/Siri through HOOBS and this plugin.
On a rather regular basis I can ask Siri to turn on/off or change the color/brightness, etc of a device and it will carry out the request successfully, but then report to me that either the device is taking too long and/or that it failed to respond.
Rarely is it that it actually takes too long or doesn't carry out the request but it is quite annoying to have my homepod minis constantly telling me that something isn't working that is.
Details of your setup.

Do you use (1) Homebridge UI-X (2) Homebridge CLI or (3) HOOBS?

HOOBS in a box

Which version of Homebridge/HOOBS do you have?

4.1.22

Which platform do you run Homebridge/HOOBS on (e.g. Raspberry Pi/Windows/HOOBS Box)? Please also mention your version of Node.js/NPM if known.

HOOBS in a box
NODE: 16.14.0

Which version of this plugin (homebridge-govee) do you have? Has the issue started since upgrading from a previous version?

4.28
(Just installed 4.28.1-beta 5 to see if that may help, but no)

Which Govee devices do you have that are causing issues? Please include product models if applicable.

It doesn't seem to matter as I have over a dozen different devices (models) and it seems to randomly effect almost all of them at different times/instances. Whether it is WiFi light strips, Neon, Glide, etc.
Please paste any relevant logs below.

2/13/2022, 8:35:37 PMGoveeERROR[Govee 08B7@Hue] The write handler for the characteristic 'Hue' on the accessory 'Office Closet' was slow to respond!
2/13/2022, 8:35:37 PMGoveeERROR[Govee 08B7@On] The write handler for the characteristic 'On' on the accessory 'Corner' was slow to respond!
2/13/2022, 8:35:37 PMGoveeERROR[Govee 08B7@On] The write handler for the characteristic 'On' on the accessory 'Desk Lights' was slow to respond!
2/13/2022, 8:35:37 PMGoveeERROR[Govee 08B7@Hue] The write handler for the characteristic 'Hue' on the accessory 'Bricks' was slow to respond!
2/13/2022, 8:35:37 PMGoveeERROR[Govee 08B7@Hue] The write handler for the characteristic 'Hue' on the accessory 'Upper' was slow to respond!
2/13/2022, 8:35:37 PMGoveeERROR[Govee 08B7@On] The write handler for the characteristic 'On' on the accessory 'Portal' was slow to respond!
2/13/2022, 8:35:37 PMGoveeERROR[Govee 08B7@Hue] The write handler for the characteristic 'Hue' on the accessory 'Glide' was slow to respond!
2/13/2022, 8:35:37 PMGoveeGoveeWARNING[Office Closet] device supports 'colorwc' command, let me know on Github with model number [H6144].
2/13/2022, 8:35:37 PMGoveeGovee[Office Closet] current colour [rgb 191 239 255].
2/13/2022, 8:35:37 PMGoveeGovee[Immersion] current colour [rgb 191 239 255].
2/13/2022, 8:35:38 PMGoveeGoveeWARNING[Lively] device supports 'colorwc' command, let me know on Github with model number [H610A].
2/13/2022, 8:35:38 PMGoveeGovee[Lively] current colour [rgb 191 239 255].
2/13/2022, 8:35:38 PMGoveeGoveeWARNING[Kitchen Neon] device supports 'colorwc' command, let me know on Github with model number [H61A0].
2/13/2022, 8:35:39 PMGoveeGovee[Kitchen Neon] current colour [rgb 191 239 255].
2/13/2022, 8:35:39 PMGoveeGovee[Bricks] current colour [rgb 191 239 255].
2/13/2022, 8:35:40 PMGoveeGovee[Upper] current colour [rgb 191 239 255].
2/13/2022, 8:35:40 PMGoveeGovee[Glide] current colour [rgb 191 239 255].
2/13/2022, 8:35:41 PMGoveeGoveeWARNING[Office Closet] device supports 'colorwc' command, let me know on Github with model number [H6144].
2/13/2022, 8:35:43 PMGoveeERROR[Govee 08B7@On] The write handler for the characteristic 'On' on the accessory 'Corner' didn't respond at all!. Please check that you properly call the callback!
2/13/2022, 8:35:43 PMGoveeERROR[Govee 08B7@On] The write handler for the characteristic 'On' on the accessory 'Desk Lights' didn't respond at all!. Please check that you properly call the callback!
2/13/2022, 8:35:43 PMGoveeERROR[Govee 08B7@On] The write handler for the characteristic 'On' on the accessory 'Portal' didn't respond at all!. Please check that you properly call the callback!

Hi @CadLiara
Do you have your govee username and password and API key in the plugin settings?
Also have you setup the plugin to control any devices via bluetooth?
Just trying to work out your setup so far!

Username/password  both in config of plug-in along with my API key.
And no, no other settings on any of the other devices are checked and/or utilized.
Due to an unrelated issue (prior to which I had the same problem I am reporting here) I had to pull and reflash the HOOBS memory card and reinstall everything from scratch and still this issue came back along with it.
This didn’t used to be a problem in the past and cropped up in the last 2-3 months.

On Feb 13, 2022, at 11:48 PM, Ben @.***> wrote:

Hi @CadLiara
Do you have your govee username and password and API key in the plugin settings?
Also have you setup the plugin to control any devices via bluetooth?
Just trying to work out your setup so far!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.

Can you show me your plugin startup logs?

Sure thing.
(I enabled debug logging at 11:15 2-15-22 and proceeded to reboot the govee plugin if that helps to isolate in the logs)
log.txt

I am wondering if you need to request a new API key from Govee. Could you do this, update the config with the new API key you receive from govee and then restart the govee bridge?

Just got a new key, input it, restarted the bridge. The issue persists.

I'm having the same issue. It hangs up homebridge so no other device can be used until it finishes going through all of the brightness steps. "The write handler for the characteristic 'Brightness' on the accessory 'XXX' was slow to respond!".

Could either of you get me some logs with the plugin debug mode setting on?
@theyluvloki are you using hoobs or homebridge?
Sorry its taken me a while to respond to this!

The logs I posted were with debug mode on.

On Feb 28, 2022, at 10:57 AM, Ben @.***> wrote:

Could either of you get me some logs with the plugin debug mode setting on?
@theyluvloki are you using hoobs or homebridge?
Sorry its taken me a while to respond to this!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.

Ok I am not sure what you did with 4.29 and I am knocking on wood, but I just updated and not only  is Siri no longer reporting the delays / cannot communicate with issues but the devices are responding almost instantly.
Praying this will last.

Never mind. The issue remains. :(

The logs I posted were with debug mode on.

I cannot see any plugin debug logging in the logs you posted. Make sure you turn on debug logging in the plugin settings, this is separate to the debug mode that HOOBS has.

Hopefully with this mode on, you will be able to recreate some of the errors so I can see exactly what is going wrong from the logs

My third post in this thread included the downloaded logs with debug on.
I just ran another log with debug on as well (attached.) The issue persists, is consistently replicated and command to response through Homekit voice takes anywhere from 20 seconds to a full minute with Siri either reporting a "your device is taking too long to respond" or "is not responding" error even though the device eventually does what was asked.
This is ONLY with govee devices through Hoobs/plugin. My other plugins/devices and native homekit devices work fine.
Govee debug log 3-6-22.txt

I have a theory (and bear with me as I have zero programming/backend experience) but I am wondering if perhaps throughout the history of me setting up homekit / adding-deleting devices, etc there may somehow be a "phantom" version of the plugin and/or perhaps somehow data that is still lingering causing siri/homekit to call to an a different version of the devices and/or multiple iterations of devices duplicating the efforts.
Is this possible?
I have checked and cleared the cache, deleted and repaired the bridge, you name it, I have probably tried it to try and troubleshoot this issue.
Perhaps I am chasing ghosts (no pun intended) but everything I have tried so far hasn't worked.

Closing this as a bit overwhelmed with issues.
Please update to the beta version of the plugin, and if you are still having issues, do reopen this ticket!
Thanks and apologies if closing prematurely.

Sorry, this is a minor issue (as it is working) but I am seeing the same:

Ask Siri to turn on or off the bedroom air purifier.
The command is executed (it goes on or off, appropriately)
Siri responds "The bedroom air purifier is not responding"

Only message (with debug on) seems to be:
[10/19/2022, 7:00:31 PM] [Govee] [Bedroom Air Purifier] could not be updated as Request failed with status code 400 at settle (file:///usr/lib/node_modules/homebridge-govee/node_modules/axios/lib/core/settle.js:19:12).

@tjb1013 which model is your device and which version of the plugin do you have?

@tjb1013 which model is your device and which version of the plugin do you have?

My bad … Govee H7122
homebridge-govee v6.0.4
OS	Raspbian GNU/Linux Buster (10)
Node.js Version	[v16.17.1]

@tjb1013 which model is your device and which version of the plugin do you have?

My bad … Govee H7122
homebridge-govee v6.0.4
OS Raspbian GNU/Linux Buster (10)
Node.js Version [v16.17.1]

Thanks, you should find this is fixed in the beta version of the plugin
https://github.com/bwp91/homebridge-govee/wiki/Beta-Version
^ i’m assuming you have your govee email and password in the plugin config?

Thanks, you should find this is fixed in the beta version of the plugin

That fixed it, thanks.


Installing with operator.configAuditScannerEnabled=false in helm causes trivy-operator to crash

What steps did you take and what happened:
Installing with operator.configAuditScannerEnabled=false in helm causes trivy-operator to crash.
$ helm install trivy-operator aqua/trivy-operator --namespace trivy-system --create-namespace --set="operator.configAuditScannerEnabled=false" --version 0.11.0

$ kubectl get pods
NAME                              READY   STATUS             RESTARTS     AGE
trivy-operator-6f845fb77c-zxhn2   0/1     CrashLoopBackOff   1 (4s ago)   6s

$ kubectl logs trivy-operator-6f845fb77c-zxhn2
{"level":"info","ts":"2023-02-06T04:44:30Z","logger":"main","msg":"Starting operator","buildInfo":{"Version":"0.11.0","Commit":"23b2914f793936c32d16abbeb457802d53d375b3","Date":"2023-02-05T10:42:09Z","Executable":""}}
{"level":"info","ts":"2023-02-06T04:44:30Z","logger":"operator","msg":"Resolved install mode","install mode":"AllNamespaces","operator namespace":"trivy-system","target namespaces":[],"exclude namespaces":"","target workloads":["pod","replicaset","replicationcontroller","statefulset","daemonset","cronjob","job"]}
{"level":"info","ts":"2023-02-06T04:44:30Z","logger":"operator","msg":"Watching all namespaces"}
{"level":"info","ts":"2023-02-06T04:44:31Z","logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":":8080"}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x1973d28]

goroutine 1 [running]:
github.com/aquasecurity/trivy-operator/pkg/operator.Start({_, _}, {{_, _}, {_, _}, {_, _}, {_, _}}, ...)
        /home/runner/work/trivy-operator/trivy-operator/pkg/operator/operator.go:212 +0x1908
main.run()
        /home/runner/work/trivy-operator/trivy-operator/cmd/trivy-operator/main.go:50 +0x230
main.main()
        /home/runner/work/trivy-operator/trivy-operator/cmd/trivy-operator/main.go:34 +0x1c

GetConfigAuditPlugin() returns nil for pluginContext because configAuditReports.scanner does not exist in trivy-operator configMap.

https://github.com/aquasecurity/trivy-operator/blob/v0.11.0/pkg/operator/operator.go#L212
https://github.com/aquasecurity/trivy-operator/blob/v0.11.0/pkg/plugins/factory.go#LL78-L94

$ kubectl get configmap trivy-operator -o yaml
apiVersion: v1
data:
  report.recordFailedChecksOnly: "true"
  scanJob.compressLogs: "true"
  scanJob.podTemplateContainerSecurityContext: '{"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"privileged":false,"readOnlyRootFilesystem":true}'
  vulnerabilityReports.scanner: Trivy
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: trivy-operator
    meta.helm.sh/release-namespace: trivy-system
  creationTimestamp: "2023-02-06T04:44:29Z"
  labels:
    app.kubernetes.io/instance: trivy-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trivy-operator
    app.kubernetes.io/version: 0.11.0
    helm.sh/chart: trivy-operator-0.11.0
  name: trivy-operator
  namespace: trivy-system
  resourceVersion: "3696279"
  uid: 2941be0e-6f75-4054-935f-3f82fdaddcf7

What did you expect to happen:
If operator.configAuditScannerEnabled=false, either skip the call to GetConfigAuditPlugin() or add configAuditReports.scanner: Trivy to configMap by default at helm install.
Environment:

Trivy-Operator version (use trivy-operator version): 0.11.0
Kubernetes version (use kubectl version): Client 1.26.1 / Server 1.25.0
OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): Client macOS Monterey 12.6.3 / Server Ubuntu 22.04

@mrtc0 thank you for reporting this issue , will review it ASAP


Bug in swagger-core-2.1.2, @Schema(implementation = Map.class) causes NPE

Sample code to reproduce to problem:
@GET
  @Path("path")
  @Operation(summary = "A summary.",
          description = "A description.",
          responses = {@ApiResponse(responseCode = "200",
                  content = @Content(schema = @Schema(implementation = Map.class)))
          }
  )
  public Map<String, String> getMapping() {
      return null;
  }

The NPE occurs in the class io.swagger.v3.core.util.AnnotationsUtils, method resolveSchemaFromType because Swagger doesn't resolve any schema implementation for Map.class. This line:
...
                 if (StringUtils.isNotBlank(resolvedSchema.schema.getName())) {
...

I found that List.class is causing the same issue. Seems to be related to the class being an Interface.

The same error occurs when using hash maps. Is there a known workaround?


Removed unused header file "chrono" from iso2dfd and particle-diffusion

Description
Removed unused header file "chrono" from iso2dfd and particle-diffusion.
Thanks to Joe Oster for pointing that out.
Fixes # (issue)
Deleted unused includes, simplifying code
Please delete options that are not relevant. Add a 'X' to the one that is applicable.

[X ] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Command Line
[ ] oneapi-cli
[ x] Visual Studio
[ ] Eclipse IDE
[ ] VSCode

Checklist for Moving samples:
Links and Details can be found in the samples WG Teams Files.

[ ] Review sample design with domain reviewers https://github.com/oneapi-src/oneAPI-samples/wiki/Reviewers-and-Domain-Experts
[ ] Implement coding guidelines and ensure code quality.
[ ] Adhere to sample.json specification. https://github.com/oneapi-src/oneAPI-samples/wiki/sample-json-specification
[ ] Run jsonlint on sample.json to verify json syntax. www.jsonlint.com
[ ] Adhere to readme template
[ ] Ensure/create CI test configurations for sample (ciTests field) https://github.com/oneapi-src/oneAPI-samples/wiki/sample-json-ci-test-object
[ ] Enforce format via clang-format config file
[ ] Review DPC++ code with Paul Peterseon. (GitHub User: pmpeter1)
[ ] Review readme with Tom Lenth or Joe Oster. (GitHub User: JoeOster)
[ ] Tested using Dev Cloud when applicable
[ ] Implement fixes for ONSAM Jiras
[ ] If you have new dependencies/binaries, inform Samples Project Manager Swapna R Dontharaju (@srdontha) or @JoeOster

@JoeOster Thanks for the comment about the unused header file. I removed those includes.

I like your readme statement about the dpc_common, but it isn't addressing Linux only Windows
I would include a statement such as what's used in the mandelbrot readme, if you want to continue to use your statement, I would add it to the bottom as a Troubleshhooting section or similar.
https://github.com/Alberto-Villarreal/oneAPI-samples/tree/master/DirectProgramming/DPC%2B%2B/CombinationalLogic/mandelbrot

@JoeOster I added the General statement you suggested about the include path (Both for Linux and Windows). Deleted the warning for windows- It might be redundant and to maintain consistency with other code samples. Thanks for reviewing.


Change colour of ship base

When the theme was Light+, the ship was blended into the background.

Much better. Thanks @davecharron


Update SSDP section to inclue client poller

@RackHD/corecommitters @uppalk1 @tannoa2 @zyoung51 @keedya

:+1:

:+1:


Mount workspace does not work on with IMDSV2 when using goofys

After switching to IMDSV2, I cannot use %mount_workspace_dir
Error:
UsageError: Unable to mount the Workspace. stdout= stderr=2023/10/04 20:04:31.367627 main.FATAL Unable to mount file system, see syslog for details

In the syslog:
/usr/bin/goofys[20574]: s3.ERROR code=NoCredentialProviders msg=no valid providers in chain. Deprecated.#012#011For verbose messaging see aws.Config.CredentialsChainVerboseErrors, err=<nil>

This is because Goofys does not support IMDS v2.
https://github.com/kahing/goofys/issues/727


[BUG] Rancher provisioned RKE1 clusters stay in updating state post rancher upgrade

Rancher Server Setup

Rancher version: v2.5.16 upgraded to v2.6.4
Installation option (Docker install/Helm Chart): RKE1, RKE1 version: 1.2.22, k8s version: v1.20.15, 3 nodes, all roles

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc):

Proxy/Cert Details: Self-signed

Information about the Cluster

Kubernetes version: v1.20.15
Cluster Type (Local/Downstream): Downstream custom 3 worker, 1 etcd, 1 cp

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):

User Information

What is the role of the user logged in? Admin

If custom, define the set of permissions:

Describe the bug
After upgrading the rancher server from the version 2.5.16 to the version 2.6.4, the cluster is stuck in Unavailable state and never comes back up active.
To Reproduce

Install rancher on v2.5.16 with the above mentioned spec
As an admin, create a downstream cluster with 3 worker, 1 etcd and 1 cp node
Upgrade rancher server to v2.6.4 by running the helm command:

helm upgrade --install rancher rancher-latest/rancher --version 2.6.4 --namespace cattle-system --set hostname=<hostname>

Rancher server comes back up active and upgraded to 2.6.4

Result
Downstream rke1 cluster stays in Unavailable state and never comes back up active.
Expected Result
Expected downstream to come back up active.
Additional context
Noticed that from the downstream cluster logs, the pod cattle-cluster-agent restarted 5 times and the following logs are seen in the rancher pod logs:

2023/01/10 18:30:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing
--
Tue, Jan 10 2023 10:30:49 am | 2023/01/10 18:30:49 [ERROR] error syncing 'c-jxppf': handler cluster-deploy: cluster context c-jxppf is unavaiblable, requeuing
Tue, Jan 10 2023 10:32:32 am | 2023/01/10 18:32:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing
Tue, Jan 10 2023 10:32:49 am | 2023/01/10 18:32:49 [ERROR] error syncing 'c-jxppf': handler cluster-deploy: cluster context c-jxppf is unavaiblable, requeuing
Tue, Jan 10 2023 10:34:32 am | 2023/01/10 18:34:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing
Tue, Jan 10 2023 10:34:49 am | 2023/01/10 18:34:49 [ERROR] error syncing 'c-jxppf': handler cluster-deploy: cluster context c-jxppf is unavaiblable, requeuing
Tue, Jan 10 2023 10:36:32 am | 2023/01/10 18:36:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing
Tue, Jan 10 2023 10:36:49 am | 2023/01/10 18:36:49 [ERROR] error syncing 'c-jxppf': handler cluster-deploy: cluster context c-jxppf is unavaiblable, requeuing
Tue, Jan 10 2023 10:38:32 am | 2023/01/10 18:38:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing
Tue, Jan 10 2023 10:38:49 am | 2023/01/10 18:38:49 [ERROR] error syncing 'c-jxppf': handler cluster-deploy: cluster context c-jxppf is unavaiblable, requeuing
Tue, Jan 10 2023 10:40:32 am | 2023/01/10 18:40:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing
Tue, Jan 10 2023 10:40:49 am | 2023/01/10 18:40:49 [ERROR] error syncing 'c-jxppf': handler cluster-deploy: cluster context c-jxppf is unavaiblable, requeuing
Tue, Jan 10 2023 10:42:32 am | 2023/01/10 18:42:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing
Tue, Jan 10 2023 10:42:49 am | 2023/01/10 18:42:49 [ERROR] error syncing 'c-jxppf': handler cluster-deploy: cluster context c-jxppf is unavaiblable, requeuing
Tue, Jan 10 2023 10:44:32 am | 2023/01/10 18:44:32 [ERROR] error syncing '_all_': handler user-controllers-controller: failed to start user controllers for cluster c-jxppf: ClusterUnavailable 503: cluster not found, requeuing

Not seeing the issue when upgrading from 2.5.16 >> 2.6.9 or 2.5.16 >> 2.7.0

Considering the dependencies within Rancher may downgrade in this use case, we have been having conversations about how this upgrade path (later 2.5.x versions to early 2.6.x versions) will not be supported.
Looking at when the dates of 2.5.16 was released, could we do 1 sanity test with the 2.6.7 release which was at the same timeframe as 2.5.
@anupama2501 Can you test 2.5.16 -> 2.6.7 to see if we still have this issue or not? If this doesn't happen in that use case, then I'd say this is due to a downgrade of dependencies.

Validated that the downstream RKE1 custom clusters come back up active after upgrading rancher server from 2.5.16 >> 2.6.7
Steps:

Install rancher on v2.5.16 on an RKE1 cluster, version: 1.2.22, k8s version: v1.20.15, 3 nodes, all roles
As an admin create a standard user - user1
create a downstream cluster with 3 worker, 1 etcd and 1 cp node as user1
Upgrade rancher server to v2.6.7 by running the helm command:
helm upgrade --install rancher rancher-latest/rancher --version 2.6.7 --namespace cattle-system --set hostname=
Rancher server comes back up active and upgraded to 2.6.7
Downstream rke1 cluster  comes back up active. with the cluster-agent upgraded to 2.6.7


Include commit hash in yazi --version

Is your feature request related to a problem? Please describe
I installed yay from yay -S.
Hi, when I open an issue, I noticed that yazi --version doesn't include the commit sha. I installed yazi-git via yay, and it shouldn't be version 0.1.5 but rather the latest from git main branch. This can be confusing when reporting bugs.
Will you be willing to contribute this feature?

[X] Yes, I will try to implement it

Describe the solution you'd like
something like

1.0.13+f5bf67bd1
rustc 1.75.0-nightly (fee5518cd 2023-11-05)

Describe alternatives you've considered
No response
Additional context
No response

I'm not quite sure how to include it.
Yazi is a workspace structure, I modify all crates' versions before release using https://github.com/sxyazi/yazi/blob/main/scripts/bump.sh currently, then use the version command of clap to display it out to users when they do a yazi -V:
https://github.com/sxyazi/yazi/blob/5439c80a03987fe286e721e0025b5ad4c4105615/yazi-config/src/boot/cli.rs#L6

example https://github.com/sxyazi/yazi/pull/393


Running tests on net standard 1.5 (NLog 4.5)

See https://github.com/NLog/NLog/pull/2341#issuecomment-336697328

not planned


Chat not displaying, only "Drag a view here to display."

Copilot Chat Extension Version: v0.21.0
VS Code Version:
OS Version: Version 14.6.1 (23G93) macOs Sonoma
Logs:

Steps to Reproduce:

Wrong workspace settings


[BEAM-7238] Make sfl4j bindings runtimeOnly/testRuntimeOnly

R: @mxm

Did all suggested changes. Could you PTAL again @lukecwik.

Thanks!


PluginClean deletes Vundle

When I run PluginClean, it want's to delete Vundle.vim. Is this the expected behavior?
Here's the start of my .vimrc file:
set nocompatible
filetype off

set rtp+=$HOME/.vim/bundle/Vundle.vim
call vundle#begin()

" let Vundle manage Vundle
" required!.
Plugin 'gmarik/vundle'

I note that you have 'gmarik/vundle' instead of this current repo. I can imagine some confusion there if you your names don't line up.

Good catch. Thanks. I must have copied that from another script.

I re-installed Vundle from scratch, making sure it's from this repo. PluginClean still asks to remove "Plugin 'Vundle'".


Update documentation and code cleanup for teleport event frontend

Description:
Basic player teleport implementation should be finished. Make sure that there is a document for other users to walk through code and show how to integrate with backend.

Major frontend cleanup commit here:
https://github.com/neu-cs4530/spring-23-team-514/commit/3dd0c42c6e3d830f1ee32bae64c8c8eee3c9d965


How do you customize the transition in each card?

This looks interesting. Is this doable?

This is an issue in react-navigation which does not support this feature yet. 😭 - https://github.com/react-community/react-navigation/issues/175

Close due to inactivity


Testing selenium with multiple browsers

Bit of an experiment to try and add testing on firefox as well as chrome. @istride maybe one we can discuss, some of the tests need to be adapted due to differences between Firefox and Chrome. Need to consider the best way to run the tests in both browsers (if that is something that is desirable)

will close as changes here have been merged into #1505


Add support for multi-value defaultValue and fallbackValue for parameters and options

Somehow related to #877:
Currently, it is possible to annotate a defaultValue for options and parameters. However, one can specify a string/value only, not multiple values. Fortunately, one can workaround this by using split on the option/positional parameter definition, this solution has some limitations, however.
Code example that illustrates the issue:
public class DefaultValueMultipleOptions {

    public static void main(String... args) {
        CommandLine cmd = new CommandLine(new MyFileCommand());
        cmd.execute(args);
    }
}

@Command( name="myCommand", mixinStandardHelpOptions = true)
class MyFileCommand implements Runnable {

    @Parameters(defaultValue = { "default file 1", "default file 2" }) // does not work (yet)
    // @Parameters(defaultValue = "default file 1,default file 2", split = ",") // this is workaround
    String[] files = { "file 1", "file 2" };

    public void run() {
        for (String file : files)
          System.out.println("File: " + file);

        System.out.println(String.format("%s files", files.length));
    }
}

As said, this is a low priority enhacement as we have a workaround here.
I just wanted to get the author's opinion on this prior to authoring a PR ;-)

If we do #877 then it makes sense to do this as well.
What I haven’t fully thought through is the edge cases. Basically, what if there are multiple default values specified for a single-value option or positional parameter?

What I haven’t fully thought through is the edge cases.
Basically, what if there are multiple default values specified
for a single-value option or positional parameter?

This reminds me of the discussion we had concerning #745.
I would propose to implement the same solution that was eventually chosen for #745:

runtime initialization exception from the CommandLine constructor
compile-time error by the annotation processor

I considered doing this for 4.7, but having second thoughts (and I may give up on this altogether).
The problem is, that while this will be a backwards compatible change for Java,
it will be a breaking change for languages that require different syntax for array type vs single value type annotation members.
Specifically for Groovy, Kotlin and Scala, this would be a breaking change: applications need to change their code in order to compile after this change.
For example:
Before the Change (Current Code)
Before the change, defaultValue = "someValue" and fallbackValue = "someValue" are valid syntax in Groovy, Kotlin and Scala.
// groovy / kotlin
@Option(names = ["--log-level"], defaultValue = "INFO")

// scala
@Option(names = Array("--log-level"), defaultValue = "INFO")

After the Change
After the change, [ and ] or Array( and ) become required around the default value:
// groovy / kotlin
@Option(names = ["--log-level"], defaultValue = ["INFO"]) // '[' and ']' become required around the default value

// scala
@Option(names = Array("--log-level"), defaultValue = Array("INFO")) // 'Array(' and ')' become required

I am not sure if this causes a runtime error. (Haven't tried this yet.)
If existing Kotlin, Groovy and Scala applications (compiled against an older version of picocli that requires single-value default values) would continue to work at runtime (with a newer version of picocli that requires array type default values), then it may be feasible to do this.

One idea is to add new API for multi-value defaults and leave the existing API as is for single-value defaults.
Something like this:
Option(defaultValues = {"1", "2"}, fallbackValues = {"3", "4"})

This introduces the possibility of some invalid combinations:

use of both defaultValue and defaultValues
use of defaultValues annotation on single-value option

Both can be handled by throwing an InitializationException at runtime, compile error from annotation processor.

Related: https://github.com/remkop/picocli/issues/1743


caldav sync does not work without propfind support

Dear all,
Not sure it is an issue, but it seems that propfind is required.
But servers like Baikal allow direct addressing like http://...../baikal/card.php or
http://...../baikal/card.php/principals
Could we have support for this configuration, in case propfind (mod_dav module for Apache) cannot be installed ?
Thank you

I was wondering why baikal direct URL didn't work and if I was missing something. I'm running rainloop on nginx, can I fix this myself or does it need to be made in rainloop code ?

It would be nice indeed to have the choice of using PROPFIND or not. Lots of shared web hosting services don't allow this type of request. Actually, I am concerned by this limitation:
[11:48:47.579][1186af17] INFO[NOTICE]: exception 'SabreForRainLoop\DAV\Exception\NotImplemented' with message 'Not Implemented' in /rainloop/v/<IP_ADDRESS>/app/libraries/SabreForRainLoop/DAV/Client.php:447
By the way, I read that SabreDAV (apparently used by RainLoop) can run without PROFIND method, is that true?

Even with PROPFIND I have issues.

Looking at the log, I think Rainloop isn't asking for the right URL, event using `https://cardav.server/card.php/addressbooks/user/default/` as carddav URL.

From WebDav rfc-4918

"All DAV-compliant resources MUST support the PROPFIND method and the propfind XML
element (Section 14.20) along with all XML elements defined for use with that element."

 Or switch for a hosting
 service that provides WebDAV out of the box" :-)


Questions about Agent Sampling logic

I have some questions about the agent sampling logic when I'm reading the code of SamplingService.java today:

I don't see the effect of forceSampled() method. It just increase the samplingFactorHolder, but the vacancy space it left can not be used by current request. The only effect it seems just making the sampling result count decrease 1 in current period, And the current request still need to compete for sampling in high concurrency scenario, it seems not so helpful for current request's sampling.
The trySampling method use CAS, In extreme situation, It may result in some requests be ignored but sum of  the sampled requests even less than the threshold set by SAMPLE_N_PER_3_SECS in this period. Will it?

Background
I know the agent sampling exist to avoid extreme huge request make cpu and network overload. And the backend sampling to store a part of traces to reduce storage cost.
What I want to do is saving the error traces 100% while opening the backend sampling to save the storage cost. This is a common demand in distributed tracing system.
As different service report data respectively in one request, they don't know if each other contains exception.
The common practice is using downstream feedback mechanism. For example, if there is an invocation chain like: A -> B -> C, if C caught an exception and make it's segment be force sampled. Then it can set a flag in the response, B found the flag from the response and also set force sampling and then propagation the flag to A. This mechanism can promise the exception trace(except the branch of the invocation tree) be sampled 100% and it may be very helpful for problem troubleshooting.
Hope SkyWalking have this feature.

Let me give you the conclusion first, the feedback chain would work. Think about how MQ and many async mechanisms work today in the distributed system. This is a bad mislead to the users saying, we could only sample the wrong request.

And you are still seeing SkyWalking like it was 4 years ago, now, traces are affecting the topology and metrics analysis. All client sampling is recommended only when it has to be, due to performance impact. Otherwise, don't do client sampling.
Right now, in 2020 and 2021, k8s/micro-service/distributed-service is the trend and reality. Purely using tracing like enhanced logs would not be recommended.

Back to the codes, #forceSampled is for making sure the trace continues when context exists and propagated from downstream. And you should know, we never declared SAMPLE_N_PER_3_SECS that N is an accurate number and must be kept.

In the end, I think you are walking on the wrong road. If you want to reduce the storage load, try to activate sampling at the backend, but metrics should be accurate and consistent.
If no topology and metrics, actually, you don't need the APM. Trace records are not SkyWalking design goal, APM is.

We also want to have this feature, but we are not to reduce storage load, but for two purposes:

Set a lower sampling rate to reduce the impact on client machine performance
When troubleshooting online problems, no abnormal trace will be missed

I see that this issue has joined the 8.6.0 milestone, but has been closed again.

We also want to have this feature, but we are not to reduce storage load, but for two purposes:

Set a lower sampling rate to reduce the impact on client machine performance
When troubleshooting online problems, no abnormal trace will be missed

I see that this issue has joined the 8.6.0 milestone, but has been closed again.

We have explained the reasons. Unless you have something to fix our concerns, there is no further action to be taken.

Let me give you the conclusion first, the feedback chain would work. Think about how MQ and many async mechanisms work today in the distributed system. This is a bad mislead to the users saying, we could only sample the wrong request.

I don't quite understand the feedback chain implementation mechanism here.
But when I tried to implement 100% error trace collection in SkyWalking, there was a problem:
For example, A-> B-> C, when C does not return, because A and B do not know whether the trace is wrong, A and B need to keep the TracingContext information in memory all the time, which affects the machine memory.

But when I tried to implement 100% error trace collection in SkyWalking, there was a problem:
For example, A-> B-> C, when C does not return, because A and B do not know whether the trace is wrong, A and B need to keep the TracingContext information in memory all the time, which affects the machine memory.

We never said this should be done. Do you misunderstand something?

I'm just discussing how to implement this feature in skywalking if possible

I'm just discussing how to implement this feature in skywalking if possible

From my understanding, if you consider MQ and async processes, this never works. So, this is a limited feature.

But when the all trace is called synchronously, there will also be the memory problems I mentioned.

You definitely have to cost as much as 100% sampling, as you never know what is the case. That is also we don't believe this could work efficiently. So, in the design level, SkyWalking trust we make sure 100% sampling working on the agent side.

I have learned that if this feature is to be supported, these losses are inevitable in this case. Thanks.


[ProxySQL] WARN when stats_mysql_query_rules is empty is spamming logs.

Note: If you have a feature request, you should contact support so the request can be properly tracked.
Output of the info page
# docker exec -it dd-agent s6-svstat /var/run/s6/services/agent/
up (pid<PHONE_NUMBER> seconds

# docker exec -it dd-agent agent status
Getting the status from the agent.

===============
Agent (v7.24.1)
===============

  Status date: 2021-02-24 09:48:39.629378 -04
  Agent start: 2021-01-05 13:20:42.726823 -04
  Pid: 389
  Go Version: go1.14.7
  Python Version: 3.8.5
  Build arch: amd64
  Agent flavor: agent
  Check Runners: 4
  Log Level: info

  Paths
  =====
    Config File: /etc/datadog-agent/datadog.yaml
    conf.d: /etc/datadog-agent/conf.d
    checks.d: /etc/datadog-agent/checks.d

  Clocks
  ======
    NTP offset: 958µs
    System UTC time: 2021-02-24 09:48:39.629378 -04

  Host Info
  =========
    bootTime: 2020-11-25 15:36:09.000000 -04
    kernelArch: x86_64
    kernelVersion: 3.10.0-1062.18.1.el7.x86_64
    os: linux
    platform: debian
    platformFamily: debian
    platformVersion: bullseye/sid
    procs: 552
    uptime: 981h44m42s
    virtualizationRole: guest
    virtualizationSystem: docker

  Hostnames
  =========
    ec2-hostname: ip-10-54-1-232.ec2.internal
    hostname: i-0bd9e66c0f2a2be3d
    instance-id: i-0bd9e66c0f2a2be3d
    socket-fqdn: ip-10-54-1-232.ec2.internal.
    socket-hostname: ip-10-54-1-232.ec2.internal
    host tags:
      dept:dba
      app:mysql
      scope:credtacob
      hostname:ip-10-54-1-232
      datacenter:us-east-1a
    hostname provider: aws
    unused hostname providers:
      configuration/environment: hostname is empty
      gce: unable to retrieve hostname from GCE: status code 404 trying to GET http://<IP_ADDRESS>/computeMetadata/v1/instance/hostname

  Metadata
  ========
    cloud_provider: AWS
    hostname_source: aws

=========
Collector
=========

  Running Checks
  ==============

    cpu
    ---
      Instance ID: cpu [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/cpu.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 7, Total: 2,010,051
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2021-02-24 09:48:29.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:29.000000 -04

    disk (4.0.0)
    ------------
      Instance ID: disk:e5dffb8bef24336f [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/disk.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 180, Total: 51,546,428
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 48ms
      Last Execution Date : 2021-02-24 09:48:36.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:36.000000 -04

    docker
    ------
      Instance ID: docker [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/docker.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 68, Total: 19,121,448
      Events: Last Run: 0, Total: 3
      Service Checks: Last Run: 1, Total: 287,151
      Average Execution Time : 24ms
      Last Execution Date : 2021-02-24 09:48:28.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:28.000000 -04

    file_handle
    -----------
      Instance ID: file_handle [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/file_handle.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 5, Total: 1,435,755
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2021-02-24 09:48:35.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:35.000000 -04

    io
    --
      Instance ID: io [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/io.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 286, Total: 81,210,100
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 1ms
      Last Execution Date : 2021-02-24 09:48:27.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:27.000000 -04

    load
    ----
      Instance ID: load [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/load.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 6, Total: 1,722,906
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2021-02-24 09:48:34.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:34.000000 -04

    memory
    ------
      Instance ID: memory [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/memory.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 18, Total: 5,168,718
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2021-02-24 09:48:26.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:26.000000 -04

    mysql (2.1.1)
    -------------
      Instance ID: mysql:99eb73b5098a2fe0 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/mysql.d/conf.yaml
      Total Runs: 282,883
      Metric Samples: Last Run: 64, Total: 18,103,743
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 565,756
      Average Execution Time : 84ms
      Last Execution Date : 2021-02-24 09:48:38.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:38.000000 -04
      metadata:
        flavor: MySQL
        version.build: log
        version.major: 5
        version.minor: 7
        version.patch: 29
        version.raw: 5.7.29+log
        version.scheme: semver

    network (1.19.0)
    ----------------
      Instance ID: network:5c571333f400457d [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/network.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 31, Total: 8,901,681
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 2ms
      Last Execution Date : 2021-02-24 09:48:33.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:33.000000 -04

    ntp
    ---
      Instance ID: ntp:d884b5186b651429 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/ntp.d/conf.yaml.default
      Total Runs: 4,786
      Metric Samples: Last Run: 1, Total: 4,786
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 4,786
      Average Execution Time : 0s
      Last Execution Date : 2021-02-24 09:35:57.000000 -04
      Last Successful Execution Date : 2021-02-24 09:35:57.000000 -04

    proxysql (2.0.0)
    ----------------
      Instance ID: proxysql:69427ee3c9fa0d76 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/proxysql.d/conf.yaml
      Total Runs: 287,151
      Metric Samples: Last Run: 61, Total: 17,516,211
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 574,302
      Average Execution Time : 29ms
      Last Execution Date : 2021-02-24 09:48:30.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:30.000000 -04
      metadata:
        version.build: g7b02b19c
        version.major: 2
        version.minor: 0
        version.patch: 14
        version.raw: 2.0.14-70+g7b02b19c
        version.release: 70
        version.scheme: semver

    system_swap (1.9.0)
    -------------------
      Instance ID: system_swap:d884b5186b651429 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/system_swap.d/conf.yaml
      Total Runs: 287,151
      Metric Samples: Last Run: 2, Total: 574,302
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2021-02-24 09:48:37.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:37.000000 -04

    uptime
    ------
      Instance ID: uptime [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/uptime.d/conf.yaml.default
      Total Runs: 287,151
      Metric Samples: Last Run: 1, Total: 287,151
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2021-02-24 09:48:25.000000 -04
      Last Successful Execution Date : 2021-02-24 09:48:25.000000 -04

========
JMXFetch
========

  Information
  ==================
  Initialized checks
  ==================
    no checks

  Failed checks
  =============
    no checks

=========
Forwarder
=========

  Transactions
  ============
    Deployments: 0
    Dropped: 0
    DroppedOnInput: 0
    Nodes: 0
    Pods: 0
    ReplicaSets: 0
    Requeued: 64
    Retried: 64
    RetryQueueSize: 0
    Services: 0

  Transaction Successes
  =====================
    Total number: 605411
    Successes By Endpoint:
      check_run_v1: 287,151
      intake: 31,109
      series_v1: 287,151

  Transaction Errors
  ==================
    Total number: 34
    Errors By Type:
      ConnectionErrors: 8

  API Keys status
  ===============
    API key ending with 70d63: API Key valid

==========
Endpoints
==========
  https://app.datadoghq.com - API Key ending with:
      - 70d63

==========
Logs Agent
==========

  Logs Agent is not running

=========
APM Agent
=========
  Status: Not running or unreachable on localhost:8126.
  Error: Get "http://localhost:8126/debug/vars": dial tcp [::1]:8126: connect: connection refused

=========
Aggregator
=========
  Checks Metric Sample: 214,495,940
  Dogstatsd Metric Sample: 1
  Event: 4
  Events Flushed: 4
  Number Of Flushes: 287,151
  Series Flushed: 180,897,576
  Service Check: 4,878,325
  Service Checks Flushed: 5,165,468

=========
DogStatsD
=========
  Event Packets: 0
  Event Parse Errors: 0
  Metric Packets: 0
  Metric Parse Errors: 0
  Service Check Packets: 0
  Service Check Parse Errors: 0
  Udp Bytes: 0
  Udp Packet Reading Errors: 0
  Udp Packets: 1
  Uds Bytes: 0
  Uds Origin Detection Errors: 0
  Uds Packet Reading Errors: 0
  Uds Packets: 0

Additional environment details (Operating System, Cloud provider, etc):
Host info:
Cloud provider AWS
Operating System Centos7
#uname -a
Linux ip-10-54-1-232.ec2.internal 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Scenario:
ProxySQL integration with datadog agent.
Steps to reproduce the issue:

Set up a proxysql instance and integrate it with datadog agent
Be sure that proxysql's mysql_query_rules table is empty -which is the out-of-the-box state-, so that SELECT rule_id, hits FROM stats_mysql_query_rules returns nothing.

mysql> select * from stats_mysql_query_rules;
Empty set (0.00 sec)

mysql> select * from mysql_query_rules;
Empty set (0.00 sec)

(The tables exist and are empty)

Check docker logs <dd-agent-container-name> for the following message being logged repeatedly.

2021-02-21 00:04:15 -04 | CORE | WARN | (pkg/collector/python/datadog_agent.go:120 in LogMessage) | proxysql:69427ee3c9fa0d76 | (proxysql.py:86) | Failed to fetch records from query: `SELECT rule_id, hits FROM stats_mysql_query_rules`.

Related source code
Describe the results you received:
The mentioned message is spamming the dd-agent logs.
Describe the results you expected:
Since it is expected to the stats_mysql_query_rules table to be empty when no rules are loaded, maybe it could be better to log a message only when the query fails, or keep the logging when the resultset is empty but with a minor log-level like DEBUG.
I think it is ok to WARN or ERROR when some query fails to execute, and when a resultset is positively expected to be returned.
Additional information you deem important (e.g. issue happens only occasionally):
When a monitored proxysql has query rules loaded, this message is properly not logged.
Also tried with v7.25.1 with same results.

Hi @marcossabatini,
The reason you may be seeing these warning logs is because of your configuration for proxysql. Take a look at the example config for proxysql. There is an option additional_metrics that you can configure and remove the query_rules_metrics option. This will stop the agent from querying tables that you are not using.

Thank you @luisgonzalex


ci: release 0.10.0

:robot: I have created a release beep boop
0.10.0 (2023-08-23)
Features

add healthcheck package for background tasks (4b3fe14)

Bug Fixes

fixed bug in consent page (d1a8e7a)
move buildInfo into service (a8a0115)
use check statuses in the service layer (1d89f0f)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/canonical/identity-platform-login-ui/releases/tag/v0.10.0 :sunflower:


Add confirmation modal for "Remove wallet" action

users always may miss-click to the remove button so with that we need to ask him if he really wants to do it

@thatStrangeGuyThorchain is there more than one "Remove wallet" action? I checked the code and ran through the app, the "Remove wallet" action in the screenshot below has a confirmation modal. IMO the copy in the modal could use some work: change "Remove wallet" to "Are you sure you want to remove your wallet? You cannot undo this action and will have to re-create your wallet from your seed phrase." or something like that

IMO the copy in the modal could use some work: change "Remove wallet" to "Are you sure you want to remove your wallet? You cannot undo this action and will have to re-create your wallet from your seed phrase." or something like that

@warrenshen Nice feedback, please add such description into the modal. All texts for wallets are defined in src/renderer/i18n/{lang}/wallet.ts. For languages you can't do add translations, just add EN texts suffixed with {LANG}, for example:
// EN
'wallet.action.remove.title': 'Are you sure you want to remove your wallet?', // previously 'wallet.action.remove': 'Remove wallet'
'wallet.action.remove.description': 'You cannot undo this action and will have to re-create your wallet from your seed phrase.'

 - FR', // previously 'wallet.action.remove': 'Remove wallet'
'wallet.action.remove.description': 'You cannot undo this action and will have to re-create your wallet from your seed phrase. - FR'

Also it would be nice to style such modal (it's currently just a standard antd modal). We already have different modals components in src/renderer/components/modal or just create a another (better styled) component for this.
Thanks!

@veado sounds good, will do

Resolved w/ #1479


Do NOT use joinChannel on App Channels

@Joe-Dunleavy  @osouthwell-scottlogic  @robmoffat  The 1.2 open tests are still using fdc3.joinChannel calls for app channels - as previously discussed you must use fdc3.getOrCreateChannel on app channels NOT fdc3.joinChannel: https://github.com/finos/FDC3-conformance-framework/blob/14b1ea628fa572c2a7dfbd5c7bed8e476c88d6e0/src/test/v1.2/advanced/fdc3.open.ts#L31
and your receiver needs to use the channel object NOT the top level fdc3.addContextListener (which is for user/system channels): https://github.com/finos/FDC3-conformance-framework/blob/14b1ea628fa572c2a7dfbd5c7bed8e476c88d6e0/src/test/v1.2/advanced/fdc3.open.ts#L252
You'll need to fix this both in the test definition and the mock apps (which still contain JS in a script tag): https://github.com/finos/FDC3-conformance-framework/blob/14b1ea628fa572c2a7dfbd5c7bed8e476c88d6e0/static/v1.2/general/index.html#L16-L38
This applies to both 1.2 and 2.0 mock apps (I've only provided references for 1.2)

This PR resolves this in both 1.2 and 2.0: https://github.com/finos/FDC3-conformance-framework/pull/140

resolved


STYLE: Remove local ImageScanlineIterator type aliases, using C++17 CTAD

Removed the local type aliases of ImageScanlineIterator and ImageScanlineConstIterator that were previously only used to declare a single local variable, and used C++17 class template argument deduction instead.

I assume we can, and should, do the same simplification for other image iterator types?

Thanks for your approval, @dzenanz Of course, this is just a style improvement, I would not say "we should". But I do think it very much improves code readability. In general, when a typedef is used only once, the typedef may not be needed anyway. Moreover, I feel that CTAD makes it even easier to just use the original template name, instead of some helper typedef, when declaring a variable.


[CYPRESS] : Add Nuvei Connector

Description:
This task involves adding a connector for the Nuvei functionality in Cypress.
For reference, similar connectors have already been implemented in the repository. You can refer to the existing connectors here:
https://github.com/juspay/hyperswitch/tree/main/cypress-tests/cypress/e2e/PaymentUtils
Pre-requisites:

Cypress is the testing framework that Hyperswitch is using to run automated tests. Having good grip on Javascript to work on Cypress is a must.
Please follow the README for guidelines on file structure, formatting and instructions on how to set up and run Cypress.

Steps:

Add the Nuvei connector .js files under the PaymentUtils directory:
PaymentUtils Directory

Add the card details and corresponding test case functions for Nuvei, following the format used in the Cybersource.js connector.

In the Nuvei connector, map the test cases and statuses properly. To do this, use the below dashboard credentials where Nuvei is already configured, test the flows, and then assign the correct statuses.

URL: https://integ.hyperswitch.io
Username, Password: Please drop a comment requesting credentials. The Creds are only shared on request
Test Cases:

Add test cases for card payments. (Testcases are already written under)
Add test cases for bank redirect.
Test Creds https://docs.nuvei.com/documentation/integration/testing/testing-cards/

Postman collection for reference
https://www.postman.com/altimetry-participant-63653904/hyperswitch
Note:

Test cases for other payment methods should be skipped.

The test cases are already written under PaymentTest:
PaymentTest Directory.Just map the test cases and their statuses in the config.js file.

Submission Process:

Ask the maintainers for assignment of the issue, you can request for assignment by commenting on the issue itself.
Once assigned, submit a pull request (PR).
Maintainers will review and provide feedback, if any.
Maintainers can unassign issues due to inactivity, read more here.

Refer here for Terms and conditions for the contest.

Hi , I would like to work on issue, could you assign it to me?


WIP: onnx support

Add onnx support to sd_image model.

Convert sd_image model to onnx

python scripts/convert_sd_image_checkpoint_to_onnx.py \
--model_path <path-to-pytorch-ckpt-or-huggingfaces-url> \
--output_path <path-to-output-onnx-model>

Test onnx model

from pathlib import Path
from lambda_diffusers import StableDiffusionImageEmbedOnnxPipeline
from PIL import Image

pipe = StableDiffusionImageEmbedOnnxPipeline.from_pretrained(
    "../sd-image-variations-diffusers-onnx",
    revision="onnx",
    provider="CUDAExecutionProvider", # or CPUExecutionProvider for running the job on CPU
)

im = Image.open("path-to-your-input-image")
num_samples = 2
image = pipe(num_samples*[im])
image = image["sample"]
base_path = Path("./")
base_path.mkdir(exist_ok=True, parents=True)
for idx, im in enumerate(image):
    im.save(base_path/f"{idx:06}_onnx.png")

It is not ready to be merged because the onnx model does not speed things up for GPU. This is not specifically for sd_image but also for the reference huggingface model. See issue here.
The onnx model does give ~35% iteration time when running on CPU. However it is still too slow to be used (GPU can be two order of magnitude faster)

Model Format
CPU
CUDA RTX 8000
CUDA RTX 8000 + autocast

PyTorch
10.16s/it
4.57it/s
8.92 it/s

Onnx
6.70s/it
2.23it/s
N/A

Hugginface diffusers has some issue with onnxruntime-gpu installation. See fix here and here.

The current onnx pipeline only use onnx for vae and unet, and keep the other parts of the model as PyTorch ckpts
This is due to

get_image_features is not a nn.Module so doesn't work with onnx_export. Similar discussion found here. Tried replacing it with CLIPVisionModel, was able to export but caused another error that is related to "TypeError: forward() takes 1 positional argument but 2 were given"
safety_checker onnx model doesn't work with batch size > 1. Haven't looked into the reason.

However, having these modules running in PyTorch (instead of onnx) doesn't seems to have much of a impact to the speed, since the speed of the sd_image model in this table matches the speed of the reference huggingface model (table below), despite all modules in the huggingface model can be converted into onnx.

Model Format
CPU
CUDA RTX 8000
CUDA RTX 8000 + autocast

PyTorch
10.16s/it
4.56it/s
8.78 it/s

Onnx
6.64s/it
2.21it/s
N/A


Refresh the documentation

This replaces the current documentation page with one built with Lookbook.
The approach has some advantages:

Nice UI for browsing variations
Has built in resizing tool for previewing responsiveness
Supports searching/filtering
Won't require manually refreshing the examples page
Uses view-component's native preview functionality

Things to solve

[ ] hosting - we'll need to host the dummy Rails app somewhere, GOV.UK PaaS makes sense
[ ] formatting the output - currently it's all on one line, would be nice to make it more readable

Preview

Oooh, lovely stuff. How can I get this running locally?

It's set up in the 'dummy' Rails app in spec/dummy.
Just bundle as normal, then cd spec/dummy and bundle exec rails s.
It's the root route, so the app should then be available at localhost:3000.

Coming together quite nicely!

Ah, just needed the right combination of commands to get the WEBrick server to start. This should be really helpful to those using the gem. I wonder if the examples should align with those on the design system website, where possible?

 Been waiting for this. Guessing the docs will be hosted on a new URL?

Yeah, planning on getting it sorted over the Christmas break - just need to work out how to make it automatically deploy to the PaaS :)


Attribute: do not apply vector_size to enums

clang silently ignores the attribute; GCC issues an error diagnostic
Fixes #658

I decided to return a parse error (when relevant) instead of just setting the type to invalid, because otherwise vector_size can lead to other downstream problems, e.g. something like the following:
struct  __attribute__((vector_size(32))) S  {
    int x;
};

would also cause a crash:
panic: reached unreachable code
/Users/ehaas/source/arocc/src/aro/Type.zig:2338:21: 0x10816e8dc in fromType (arocc)
            else => unreachable,
                    ^
/Users/ehaas/source/arocc/src/aro/Parser.zig:2026:56: 0x1082ee5c1 in typeSpec (arocc)
                try ty.combine(p, Type.Builder.fromType(record_ty), tag_tok);
                                                       ^
/Users/ehaas/source/arocc/src/aro/Parser.zig:1475:27: 0x108254f87 in declSpec (arocc)
        if (try p.typeSpec(&spec)) continue;
                          ^

since record_ty would be .invalid


Just pushing for diff

Just putting this here temporarily to get a look at what this will be like to review.
I don't believe this will be merged here, I anticipate managing this as a separate repository/image, given the number of major changes in ES and the features we're are/can offer in this version and beyond.
As-is, this is the first successful attempt to get ES 7.0 working with built in user auth and TLS termination - I've not reviewed any of my work here, and there are TODO's left in code where I know there are things I know I will still do.
Once this much is finished and reviewed, the first PR will be to add cluster support :D

Reminder to look into how the cluster name will be set - first thought is based on the first node's database handle.
https://aptible.zendesk.com/agent/tickets/24449

@bayley-aptible I'm happy with where this is now, let me know once you've laid eyes on it if you think a once-through where I explain the reason for each change might help provide enough context for you to meaningfully review it.

Closing in an approved state. This branch be pushed to https://github.com/aptible/docker-elasticsearch


hidden-layer visualizations

I really like Mxnet. I was wondering - is it possible with Mxnet to visualize the activations hidden layers to understand what kind of features the CNN is learning? (e.g. any of these methods - http://cs231n.github.io/understanding-cnn/) ? any thoughts much appreciated

There isn't an API for this. But example/adversary is a good reference.

Tagging with HowTo and closing for now.


Issue reporter removes option to include enabled extensions when reporting issue with extension

Issue Type: Bug
Create an issue with the issue reporter
Select 'An Extension' in the File On drop down
Actual: The 'Include my enabled extensions' checkbox disappears
Expected: The checkbox to remain in place
VS Code version: Code - Insiders 1.24.0-insider (bfd155e6039f64d2795c6b514a029ebd01a33527, 2018-05-29T05:16:50.002Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz (4 x 2594)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwarevideo_decode: enabledvideo_encode: enabledvpx_decode: unavailable_softwarewebgl: enabledwebgl2: enabled

Memory (System)
7.89GB (0.79GB free)

Process Argv
C:\Program Files\Microsoft VS Code Insiders\Code - Insiders.exe

Screen Reader
no

VM
0%

Extensions: none

Found while testing https://github.com/Microsoft/vscode/issues/50491

This is actually by design, the idea being that if a user has narrowed a problem down to a particular extension, the list of extensions the user has is very likely not a useful piece of information to have in the bug report.


Calico-node Frequently enters the Completed state and restarts

root@worker-01:/home/sunminming# kubectl -n kube-system describe pod calico-node-cbd5s
Name:                 calico-node-cbd5s
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Service Account:      calico-node
Node:                 k8s-10-10-40-33/<IP_ADDRESS>
Start Time:           Sun, 24 Nov 2024 15:42:12 +0800
Labels:               controller-revision-hash=56f9dcc8f
                      k8s-app=calico-node
                      pod-template-generation=2
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  DaemonSet/calico-node
Init Containers:
  install-cni:
    Container ID:  containerd://3ae90d7f54c60c7e647000b001264bc6886fbe27d6fb3085d0e3bbf98574a767
    Image:         easzlab.io.local:5000/calico/cni:v3.26.4
    Image ID:      sha256:17d35f5bad38f1d00ee41111d6655540797ec5011740a733b706b4717d300ede
    Port:          <none>
    Host Port:     <none>
    Command:
      /opt/cni/bin/install
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Sun, 24 Nov 2024 16:06:49 +0800
      Finished:     Sun, 24 Nov 2024 16:06:50 +0800
    Ready:          True
    Restart Count:  7
    Environment Variables from:
      kubernetes-services-endpoint  ConfigMap  Optional: true
    Environment:
      CNI_CONF_NAME:       10-calico.conflist
      CNI_NETWORK_CONFIG:  <set to the key 'cni_network_config' of config map 'calico-config'>  Optional: false
      ETCD_ENDPOINTS:      <set to the key 'etcd_endpoints' of config map 'calico-config'>      Optional: false
      CNI_MTU:             <set to the key 'veth_mtu' of config map 'calico-config'>            Optional: false
      SLEEP:               false
    Mounts:
      /calico-secrets from etcd-certs (rw)
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-zrfvj (ro)
 mount-bpffs:
    Container ID:  containerd://b322c5f181a565125ce28171c209dbfa9cc11f14b7b4f66853f5d0cc95f01f64
    Image:         easzlab.io.local:5000/calico/node:v3.26.4
    Image ID:      sha256:ded66453eb630bd4d4efddee2ccf290cbca4c67bca07c2d53c35c35dd0251136
    Port:          <none>
    Host Port:     <none>
    Command:
      calico-node
      -init
      -best-effort
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Sun, 24 Nov 2024 16:06:51 +0800
      Finished:     Sun, 24 Nov 2024 16:06:51 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /nodeproc from nodeproc (ro)
      /sys/fs from sys-fs (rw)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-zrfvj (ro)
Containers:
  calico-node:
    Container ID:   containerd://bac41554456221baba6f963d8c84fccb7bf9cf5fc38d744263761e5f84858d98
    Image:          easzlab.io.local:5000/calico/node:v3.26.4
    Image ID:       sha256:ded66453eb630bd4d4efddee2ccf290cbca4c67bca07c2d53c35c35dd0251136
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Sun, 24 Nov 2024 16:03:51 +0800
      Finished:     Sun, 24 Nov 2024 16:06:48 +0800
    Ready:          False
    Restart Count:  6
    Limits:
      cpu:     500m
      memory:  1Gi
    Requests:
      cpu:      500m
      memory:   1Gi
    Liveness:   exec [/bin/calico-node -felix-live -bird-live] delay=10s timeout=10s period=10s #success=1 #failure=6
    Readiness:  exec [/bin/calico-node -felix-ready -bird-ready] delay=0s timeout=10s period=10s #success=1 #failure=3
    Environment Variables from:
      kubernetes-services-endpoint  ConfigMap  Optional: true
    Environment:
      ETCD_ENDPOINTS:                     <set to the key 'etcd_endpoints' of config map 'calico-config'>  Optional: false
      ETCD_CA_CERT_FILE:                  <set to the key 'etcd_ca' of config map 'calico-config'>         Optional: false
      ETCD_KEY_FILE:                      <set to the key 'etcd_key' of config map 'calico-config'>        Optional: false
      ETCD_CERT_FILE:                     <set to the key 'etcd_cert' of config map 'calico-config'>       Optional: false
      CALICO_K8S_NODE_REF:                 (v1:spec.nodeName)
      CALICO_NETWORKING_BACKEND:          <set to the key 'calico_backend' of config map 'calico-config'>  Optional: false
      CLUSTER_TYPE:                       k8s,bgp
      IP:                                 autodetect
      IP_AUTODETECTION_METHOD:            can-reach=<IP_ADDRESS>
      CALICO_IPV4POOL_IPIP:               Always
      FELIX_IPINIPMTU:                    <set to the key 'veth_mtu' of config map 'calico-config'>  Optional: false
      FELIX_VXLANMTU:                     <set to the key 'veth_mtu' of config map 'calico-config'>  Optional: false
      FELIX_WIREGUARDMTU:                 <set to the key 'veth_mtu' of config map 'calico-config'>  Optional: false
      CALICO_IPV4POOL_CIDR:               <IP_ADDRESS>/16
      CALICO_DISABLE_FILE_LOGGING:        true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:  ACCEPT
      FELIX_IPV6SUPPORT:                  false
      FELIX_HEALTHENABLED:                true
      FELIX_KUBENODEPORTRANGES:           30000:32767
      FELIX_PROMETHEUSMETRICSENABLED:     false
    Mounts:
      /calico-secrets from etcd-certs (rw)
      /host/etc/cni/net.d from cni-net-dir (rw)
      /lib/modules from lib-modules (ro)
      /run/xtables.lock from xtables-lock (rw)
      /sys/fs/bpf from bpffs (rw)
      /var/lib/calico from var-lib-calico (rw)
      /var/log/calico/cni from cni-log-dir (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/nodeagent from policysync (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-zrfvj (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       False
  ContainersReady             False
  PodScheduled                True
Volumes:
  lib-modules:
    Type:          HostPath (bare host directory volume)
    Path:          /lib/modules
    HostPathType:
  var-run-calico:
    Type:          HostPath (bare host directory volume)
    Path:          /var/run/calico
    HostPathType:
  var-lib-calico:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/calico
    HostPathType:
  xtables-lock:
    Type:          HostPath (bare host directory volume)
    Path:          /run/xtables.lock
    HostPathType:  FileOrCreate
  sys-fs:
    Type:          HostPath (bare host directory volume)
    Path:          /sys/fs/
    HostPathType:  DirectoryOrCreate
  bpffs:
    Type:          HostPath (bare host directory volume)
    Path:          /sys/fs/bpf
    HostPathType:  Directory
  nodeproc:
    Type:          HostPath (bare host directory volume)
    Path:          /proc
    HostPathType:
  cni-bin-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /opt/cni/bin
    HostPathType:
  cni-net-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /etc/cni/net.d
    HostPathType:
  cni-log-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/log/calico/cni
    HostPathType:
  etcd-certs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  calico-etcd-secrets
    Optional:    false
  policysync:
    Type:          HostPath (bare host directory volume)
    Path:          /var/run/nodeagent
    HostPathType:  DirectoryOrCreate
  kube-api-access-zrfvj:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              kubernetes.io/os=linux
Tolerations:                 :NoSchedule op=Exists
                             :NoExecute op=Exists
                             CriticalAddonsOnly op=Exists
                             node.kubernetes.io/disk-pressure:NoSchedule op=Exists
                             node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/network-unavailable:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists
                             node.kubernetes.io/pid-pressure:NoSchedule op=Exists
                             node.kubernetes.io/unreachable:NoExecute op=Exists
                             node.kubernetes.io/unschedulable:NoSchedule op=Exists
Events:
  Type     Reason     Age   From               Message
  ----     ------     ----  ----               -------
  Normal   Scheduled  24m   default-scheduler  Successfully assigned kube-system/calico-node-cbd5s to k8s-10-10-40-33
  Warning  Unhealthy  24m   kubelet            Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/calico/bird.ctl: connect: connection refused
W1124 07:42:16.221537      48 feature_gate.go:241] Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.
  Warning  Unhealthy  24m  kubelet  Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/calico/bird.ctl: connect: connection refused
W1124 07:42:18.006339     124 feature_gate.go:241] Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.
  Warning  Unhealthy  24m  kubelet  Readiness probe failed: 2024-11-24 07:42:22.723 [INFO][253] confd/health.go 180: Number of node(s) with BGP peering established = 0
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>
W1124 07:42:22.715553     253 feature_gate.go:241] Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.
  Normal   Killing         23m                kubelet  Stopping container calico-node
  Normal   Pulled          23m (x2 over 24m)  kubelet  Container image "easzlab.io.local:5000/calico/cni:v3.26.4" already present on machine
  Normal   Created         23m (x2 over 24m)  kubelet  Created container install-cni
  Normal   Started         23m (x2 over 24m)  kubelet  Started container install-cni
  Normal   SandboxChanged  23m                kubelet  Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled          23m (x2 over 24m)  kubelet  Container image "easzlab.io.local:5000/calico/node:v3.26.4" already present on machine
  Normal   Started         23m (x2 over 24m)  kubelet  Started container mount-bpffs
  Normal   Created         23m (x2 over 24m)  kubelet  Created container mount-bpffs
  Normal   Started         23m (x2 over 24m)  kubelet  Started container calico-node
  Normal   Created         23m (x2 over 24m)  kubelet  Created container calico-node
  Warning  Unhealthy       23m                kubelet  Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/calico/bird.ctl: connect: connection refused
W1124 07:43:43.579392      99 feature_gate.go:241] Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.
  Warning  Unhealthy  23m  kubelet  Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/calico/bird.ctl: connect: connection refused
W1124 07:43:44.185882     142 feature_gate.go:241] Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.
  Normal   Pulled     19m (x4 over 24m)     kubelet  Container image "easzlab.io.local:5000/calico/node:v3.26.4" already present on machine
  Warning  Unhealthy  9m57s (x37 over 19m)  kubelet  (combined from similar events): Readiness probe failed: 2024-11-24 07:57:12.867 [INFO][717] confd/health.go 180: Number of node(s) with BGP peering established = 0
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>
W1124 07:57:12.779037     717 feature_gate.go:241] Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.
  Warning  BackOff  4m48s (x24 over 23m)  kubelet  Back-off restarting failed container calico-node in pod calico-node-cbd5s_kube-system(588856b9-3c97-4630-bd0b-39e66b0c24e8)

 2024-11-24 08:04:54.984 [INFO][100] monitor-addresses/reachaddr.go 47: Auto-detected address by connecting to remote Destination="<IP_ADDRESS>" IP=<IP_ADDRESS>
2024-11-24 08:04:54.985 [INFO][100] monitor-addresses/autodetection_methods.go 143: Using autodetected IPv4 address <IP_ADDRESS>/22, detected by connecting to <IP_ADDRESS>
2024-11-24 08:04:59.161 [INFO][104] felix/summary.go 100: Summarising 20 dataplane reconciliation loops over 1m4s: avg=50ms longest=516ms (resync-filter-v4,resync-ipsets-v4,resync-mangle-v4,resync-nat-v4,resync-raw-v4,resync-routes-v4,resync-routes-v4,resync-rules-v4,update-filter-v4,update-ipsets-4,update-mangle-v4,update-nat-v4,update-raw-v4)
2024-11-24 08:05:16.243 [INFO][104] felix/int_dataplane.go 1289: Linux interface state changed. ifIndex=74 ifaceName="nodelocaldns" state=""
2024-11-24 08:05:16.243 [INFO][104] felix/int_dataplane.go 1325: Linux interface addrs changed. addrs=<nil> ifaceName="nodelocaldns"
2024-11-24 08:05:16.243 [INFO][104] felix/iface_monitor.go 235: Netlink address update but interface isn't yet known.  Will handle when interface is signalled. addr="<IP_ADDRESS>" exists=false ifIndex=74
2024-11-24 08:05:16.243 [INFO][104] felix/int_dataplane.go 1893: Received interface update msg=&intdataplane.ifaceStateUpdate{Name:"nodelocaldns", State:"", Index:74}
2024-11-24 08:05:16.243 [INFO][104] felix/int_dataplane.go 1913: Received interface addresses update msg=&intdataplane.ifaceAddrsUpdate{Name:"nodelocaldns", Addrs:set.Set[string](nil)}
2024-11-24 08:05:16.243 [INFO][104] felix/hostip_mgr.go 84: Interface addrs changed. update=&intdataplane.ifaceAddrsUpdate{Name:"nodelocaldns", Addrs:set.Set[string](nil)}
2024-11-24 08:05:16.243 [INFO][104] felix/ipsets.go 130: Queueing IP set for creation family="inet" setID="this-host" setType="hash:ip"
2024-11-24 08:05:16.245 [INFO][104] felix/ipsets.go 778: Doing full IP set rewrite family="inet" numMembersInPendingReplace=5 setID="this-host"
2024-11-24 08:05:36.394 [INFO][104] felix/int_dataplane.go 1289: Linux interface state changed. ifIndex=77 ifaceName="nodelocaldns" state="down"
2024-11-24 08:05:36.394 [INFO][104] felix/int_dataplane.go 1325: Linux interface addrs changed. addrs=set.Set{<IP_ADDRESS>} ifaceName="nodelocaldns"
2024-11-24 08:05:36.394 [INFO][104] felix/iface_monitor.go 238: Netlink address update for known interface.  addr="<IP_ADDRESS>" exists=true ifIndex=77
2024-11-24 08:05:36.394 [INFO][104] felix/int_dataplane.go 1893: Received interface update msg=&intdataplane.ifaceStateUpdate{Name:"nodelocaldns", State:"down", Index:77}
2024-11-24 08:05:36.394 [INFO][104] felix/int_dataplane.go 1913: Received interface addresses update msg=&intdataplane.ifaceAddrsUpdate{Name:"nodelocaldns", Addrs:set.Typed[string]{"<IP_ADDRESS>":set.v{}}}
2024-11-24 08:05:36.394 [INFO][104] felix/hostip_mgr.go 84: Interface addrs changed. update=&intdataplane.ifaceAddrsUpdate{Name:"nodelocaldns", Addrs:set.Typed[string]{"<IP_ADDRESS>":set.v{}}}
2024-11-24 08:05:36.395 [INFO][104] felix/ipsets.go 130: Queueing IP set for creation family="inet" setID="this-host" setType="hash:ip"
2024-11-24 08:05:36.396 [INFO][104] felix/ipsets.go 778: Doing full IP set rewrite family="inet" numMembersInPendingReplace=6 setID="this-host"
2024-11-24 08:05:54.988 [INFO][100] monitor-addresses/reachaddr.go 47: Auto-detected address by connecting to remote Destination="<IP_ADDRESS>" IP=<IP_ADDRESS>
2024-11-24 08:05:54.990 [INFO][100] monitor-addresses/autodetection_methods.go 143: Using autodetected IPv4 address <IP_ADDRESS>/22, detected by connecting to <IP_ADDRESS>
bird: Mesh_10_10_40_34: State changed to stop
bird: Mesh_10_10_40_34: State changed to down
bird: Mesh_10_10_40_34: Starting
bird: Mesh_10_10_40_34: State changed to start
2024-11-24 08:06:03.090 [INFO][104] felix/summary.go 100: Summarising 13 dataplane reconciliation loops over 1m3.9s: avg=20ms longest=70ms (resync-filter-v4)

Expected Behavior

keep Running
Current Behavior

completed and restart
Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Calico version 3.26.4
Calico dataplane (iptables, windows etc.) dataplane
Orchestrator version (e.g. kubernetes, mesos, rkt): 1.30.1
Operating System and version:Linux worker-01 6.5.0-18-generic #18~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb  7 11:40:03 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Link to your project (optional):

@sunminming Can you upgrade to a newer releases like 3.28 or 3.29? 3.26.4 is a bit old now.
Also can you include a complete Calico node log?

@sunminming Can you upgrade to a newer releases like 3.28 or 3.29? 3.26.4 is a bit old now.
Also can you include a complete Calico node log?

@mazdakn  I have upgraded to 3.28.2, but it still keeps restarting. I got these logs from the /var/log/pods/calico-node* directory
6.log
master.log
worker.log
I

What sort of cluster networking do you setup? It feels like some sort of network reach-ability which leads to readiness prob failure.

@mazdakn I have solved this problem. It was caused by a problem in the containerd configuration file. Thank you for your help.


Elasticsearch metrics not pulling the right cluster name

We are using the docker image image: justwatch/elasticsearch_exporter:1.0.2 and have several alerts setup for ElasticSearch. The metrics are getting successfully scraped and hence showing up on the UI but when the alert fires, it is not reaching slack, pagerduty or any other integrations. The other alerts from the same cluster are working though.
I noticed that one of the metric elasticsearch_cluster_health_status that we have an alert on has the cluster name wrong in the labels. It is showing up with cluster="abc05" whereas the actual cluster name is "abc05-prod". For example:
elasticsearch_cluster_health_status{cluster="abc05",color="green",endpoint="es-metrics",instance="<IP_ADDRESS>:9108",job="elasticsearch-exporter",namespace="monitoring",pod="elasticsearch-exporter-9f896cf85-j8wbc",service="elasticsearch-exporter"}

I suspect that the wrong cluster name could be preventing the alert from routing through the AlertManager integrations.
We are using Prometheus Operator with Alertmanager version 0.16.0.

Hi @verma-preet,
can you please send me the output of
curl <your_es_url>:9200/_cluster/health | jq .cluster_name
and
curl <your_es_url>:9200/ | jq .cluster_name

to help me to debug the problem?!

there must be a mismatch about what you interpret as cluster name and what the ES API endpoint and thus the elasticsearch_exporter sees as the cluster name. The above API calls are exactly the calls the exporter does. The jq pipe just filters out the json field.
Where is the value "syd05-prod" coming from? Where do you see it?

@zwopir The cluster name is coming from the inventory and I see that it's not set right in ES and hence the exporter is working as expected. Thanks for taking time to look into it.


Incorrect resizeToFitDevice on mac with portaitOrientation=true

fixture('React').page('https://facebook.github.io/react/');

test('Resize to fit device', async t => {
    await t.resizeWindowToFitDevice('Nexus 7 (2013)', { portraitOrientation: true });

    const getWindowHeight = ClientFunction(() => window.innerHeight);
    const getWindowWidth  = ClientFunction(() => window.innerWidth);

    expect(await getWindowHeight()).eql(960);
    expect(await getWindowWidth()).eql(600);
});

AssertionError: expected 896 to deeply equal 960

We cannot resize a window to the size bigger than the desktop size on Mac. Can you specify your Mac desktop size as well?

@AndreyBelym Maybe we could give warning in that case?

Sure!

Browser provider API changes:
canResizeWindowToDimensions(browserId, width, height)
Allows to validate the specified width and height of browser window browserId before the actual resize. The result is true if browser window can be resized to the specified dimensions, false otherwise.
hasCustomActionForBrowser(browserId)
Enables feature querying for the specified browser window browserId. The function should return an object with the following properties:
hasResizeWindow - the browser window supports resizing,
hasMaximizeWindow - the browser  window supports maximizing,
hasTakeScreenshots - the browser window image can be captured to the file,
hasCanResizeWindowToDimensions - the requested window dimensions can be validated before resize.
If a property in the returned object has the true value, the provider should have an implemented function with the name corresponding to the property. (e.g. hasTakeScreenshot => takeScreenshot). The default implementation for hasCustomActionForBrowser checks for the function names by calling hasOwnProperty on provider object.
isLocalBrowser(browserId)
Returns true if the specified browser browserId is a local browser. Default implementation ignores browserId and always returns false.