edit/ update data on an existing instance with agularjs

Hi,
In my controller angular I create the new instance of sirTrevor like this:
  function initSirTrevor(){
    editorSt = new SirTrevor.Editor(
      {
        el: $('.js-st-instance'),
        blockTypes: ['Text', 'Image', 'Heading'],
        required: ['Text']
      }
    );
}

But i call this function if there is no other instances created, so i check it:
  if(SirTrevor.config.instances.length <= 0){
    initSirTrevor();
  }

Like this i can call always the first instance, but when I go in the edit page I get the first instance and i put my block because they are stored in my server.
        var instance = SirTrevor.getInstance(0);

        // create new blocks for the updated data
        project._description.forEach(function(block) {
          instance.mediator.trigger('block:create', block.type, block.data);
        });

In project._description i have my stored data, and in fact it works well. But at this point my html is just a normal text area without those blocks or even the + symbol. If I refresh the page it works.
I hope I explained my issue clearly :)

Thanks for creating an issue for this.
The safest way you'll find to do this is use a textarea as a hidden storage for your data.
I guess you could do something similar to this?
function initSirTrevor(){
  editorSt = new SirTrevor.Editor(
    {
      el: $('.js-st-instance'),
      blockTypes: ['Text', 'Image', 'Heading'],
      required: ['Text']
    }
  );
}

scope.$watch('name', function(newValue) {
  $('.js-st-instance').val(newValue);
  if(SirTrevor.config.instances.length <= 0){
    initSirTrevor();
  }
  editorSt.reinitialize();
});

onButtonClick = function() {
  editorSt.onFormSubmit();
  var data = editorSt.store.toString();
  // Do something with your data.
}

thanks,
right now still no success :)
I am getting this javascript error:
Sorry there has been a problem with parsing the JSON
sir-trevor.js:3356 SyntaxError: Unexpected token o(…)
I keep trying!

Ok.
Can't help with that message.
if you inspect $('.js-st-instance') does it contain what you'd expect? as in the actual output of editorSt.store.retreive or .toString ?

In your code you put a watch but what should i watch? one ng-model associated to my text-area in the html?
In  $('.js-st-instance') I have the html element.
I am thinking to create a plunker or similar to show you the issue.
Thanks for the support

My understanding of your issue is that you are binding a variable to the textarea and rendering the editor. The issue is the editor might be created before the data has been set. Then once the data is set you need to call reinitialize somewhere. As you've got ng-model="project._description" you'll want to watch the model and then when it changes call the instanance.reinitialize. You'll also want to make sure it's done after the textarea data has been updated. So the correct part of the digest.
If you are using angular < 2 then it's probably best creating a directive similar to the following:
http://stackoverflow.com/a/12021632
As your issue is now angularjs. Might be worth creating a stackoverflow for someone to respond to with specific angular knowledge. If you do that it would be good to update this issue with a link to that.

I did that few days ago :)
http://stackoverflow.com/questions/33546629/edit-blocks-sir-trevor-with-angularjs
I will let you know if I get some news

Very sensible.
Should you not be calling the sir-trevor instance in the link phase, rather than controller?

hmmm
I have tried that but it doesn't change the result.
calling it in the link phase should be different if you want to edit the element, I don't touch the element when I create the new blocks.
I am thinking that maybe I should compile the directive.
I will try it out in these days!

I think the key for you is storing the instance somewhere that can be destroyed when the directive is destroyed.
I saw in one of your things that you are using SirTrevor.getInstance(). I'd replace this with storing the instance somewhere as a variable as that will be deprecated in the future.
So use something similar to var editorSt = new SirTrevor.editor(); instead of var editorSt = SirTrevor.getInstance();

Thanks!
I have tried the repo and it looks very cool and working!
I am gonna try to use the directive in my project, but if I need to get the new data from the editor I should use: SirTrevor.getInstance().store.retrieve()? or is there another elegant way?
Because if I log the ngmodel i get undefined
thanks a lot

To get the new data you'll want:
editorSt.onFormSubmit();
var data = editorSt.store.retrieve();
Don't know what you mean by ngModel being undefined. Post your code once you've done that.

hi! I am back! :)
You declare the var= editorSt globally and it is used inside the directive and the controller.
But if I want to use different instances of sirTrevor I can't access to the instance and send it to a server.
Btw I am gonna fork you repo for angular and use it with like firebase and like this you can see what I mean

That was just an example quickly created to give some ideas. You'll want to define it per directive and destroy when finished so you can have multiple editors.

If you want a bit of explanation about that sort of directive you can take a look here.
http://truffles.me.uk/turn-anything-into-an-ng-model-with-ngmodelcontroller


palette/fix: Fixed case-search issue

Fix for a search issue described in #75.

I think there is no need because toLowerCase() method is applied earlier.
https://github.com/spring-projects/spring-flo/blob/1e7d8b9606e45b1f7f6085532f0575d7a0021e53/src/lib/palette/palette.component.ts#L293

Awesome :-) Thanks for checking this. LGTM. Merging...

Thanks very much for the contribution!


Ubuntu 14.04 not installing

http://pastebin.com/KBhYu2me

This looks like a Linux permission issue. I just installed on my 15.04 Ubuntu VM and everything went through ok.

You will either have to run sudo npm install donejs -g or use nvm which installs all Node versions local to the user.


Avoid default value for num_classes parameter in Unimodal Loss Functions

The num_classes parameter in unimodal loss functions currently has a default value. However, it's important to note that specifying the correct number of classes for this parameter must be done for every case. Relying on a default value may lead to errors that are difficult to diagnose.
Recommendation:

Remove the default value for the num_classes parameter in BetaCrossEntropyLoss, BinomialCrossEntropyLoss, ExponentialRegularisedCrossEntropyLoss, GeneralTriangularCrossEntropyLoss, PoissonCrossEntropyLoss, and TriangularCrossEntropyLoss

The default value of the parameter num_classes in unimodal loss functions has been removed, to avoid problems in future user implementations.


Typo in Part II. 18. Collision

Regarding the Paddle Bounce code
    ; First, check if the ball is low enough to bounce off the paddle.
    ld a, [_OAMRAM]
    ld b, a
    ld a, [_OAMRAM + 4]
    cp a, b
    jp nz, PaddleBounceDone ; If the ball isn't at the same Y position as the paddle, it can't bounce.
    ; Now let's compare the X positions of the objects to see if they're touching.
    ld a, [_OAMRAM + 5] ; Ball's X position.
    ld b, a
    ld a, [_OAMRAM + 1] ; Paddle's X position.
    sub a, 8
    cp a, b
    jp c, PaddleBounceDone
    add a, 8 + 16 ; 8 to undo, 16 as the width.
    cp a, b
    jp nc, PaddleBounceDone

    ld a, -1
    ld [wBallMomentumY], a

PaddleBounceDone:

should the X position checking instead be
    ld a, [_OAMRAM + 5] ; Ball's X position.
    ld b, a
    ld a, [_OAMRAM + 1] ; Paddle's X position.
    sub a, 8
    cp a, b
    jp nc, PaddleBounceDone
    add a, 8 + 16 ; 8 to undo, 16 as the width.
    cp a, b
    jp c, PaddleBounceDone

the conditionals for both jump commands should be swapped I believe. This allows the program to work for me where the tutorial code didn't. It makes more sense as the first jump should occur if the ball's X position is less than the paddle's X position but with jp c it jumps out of the bounce procedure whenever the Ball's X is greater than the Paddle's X

This is already resolved by #59

This is already resolved by #59

ah I see sorry about that I just ran into an issue in the tutorial and debugged it myself, didn't see there was a pending change


allow token_owner to be passed to the hidden proc for parameters as well

This allows the same functionality that is offered by the route-level hidden procs.

thanks @urkle … will be mörged


CI: Replace windows-2016 with windows-2022

Windows 2016 environment is going to be discontinued.
Fixes #17177

This pull request is ready to merge

Merged to master and 3.0 branches (after resolving trivial conflict). 1.1.1 branch needs a separate PR.


CUPS get stuck after restart on active cups-browsed print jobs

Describe the bug
Printer queues getting stuck or disabled and sometimes yield a status message "No suitable destination host found by cups-browsed, retrying later" or "No destination host name supplied by cups-browsed for printer , is cups-browsed running?". Printing on other printer queues from cups-browsed works successful, at least most of the time.
We tried solving the problem by clearing all print queues on the affected workstations at first (stopping both daemons and clear printers.conf), but it didn't stop it. The patch https://github.com/OpenPrinting/cups-browsed/commit/57d9351ea45f47b3bd185f263b1e37d276cf17b8 from #23 didn't really solved it, too.
At the moment, I suspect a line of shell script in our configuration management (fai) which restarts the cups-browsed daemon after a configuration change.
To Reproduce
Steps to reproduce the behavior:

Print a job to a printer queue managed by cups-browsed. Helpful if the print job is bigger than a few pages so you got more time to react.
Wait till the program printed and the job is processed by CUPS.
Restart the cups or cups-browsed systemd unit. Both should result in some or an other error described above.
Printing again to the same queue yields to the same error. Maybe a single print job passes through, but the same error is excepted.

Expected behavior
Printing works even through restart from one of the responsible daemons or the avoidance of persisting the error.
System Information:

OS: Ubuntu
Version 22.04 LTS

cups-browsed and cups-filters are backported from Ubuntu mantic (Version 2.0.0-0ubuntu2) because of trouble in earlier versions in junction to our CUPS server on Debian 11.
Also added the patch https://github.com/OpenPrinting/cups-browsed/commit/57d9351ea45f47b3bd185f263b1e37d276cf17b8
Additional context
From my current understanding, it's a problem when CUPS want to print but cups-browsed hasn't detected the remote printer. It could be because of those cases:

cups-browsed is in restart and therefor, printing isn't possible.
CUPS started and have unfinished jobs from the previous run. The daemon tries to print but cups-browsed didn't detected the remote printers yet, so no target to print.

When restarting CUPS, these problematic printing queues persist while other queues appear after cups-browsed detected them. Don't know if thats just a CUPS problem because theres a print job for him also.
On most workstations that reported the problem, we found log messages that systemd killed the service at some time and cups-browsed reports the following message for all print queues at the next start:
Timeout happened during creation of the queue <name>, turn on DebugLogging for more info.

We now tried to temporarily solve this problem by the following systemd unit override for cups.service:
# /etc/systemd/system/cups.service.d/20-cups-jobs.conf
[Service]
ExecStartPre=/usr/bin/find /var/spool/cups -maxdepth 1 -type f -delete

It cleans the printing queue before the start so it wont trigger an undetected cups-browsed printer.
I can give feedback if this solves it. At least at the next restart.
Would be nice if cups-browsed would be more resilient with this.

Additional to the reproducable error, we still had problems with this issue. Looks like 87 network printers and a VPN connection isnt the best usecase. In the debug log, I discovered longer waiting for the update_netifs function, especially if the client is connected via VPN. Maybe our latest VPN performance problem made it exponential.
On inhouse workstations, rechecking all printer queues took around 3s, for VPN clients it took around 1-2m. Now, it constantly take 0s with the following configuration option (which makes it a lot more stable):
FrequentNetifUpdate No

The trouble which a long printer queue refresh makes is quite interesting, as the daemon cant respond to implicitclass which expects the daemon to respond the URL for the printer. Because the daemon doesnt interrupt its queue refresh for this, implicitclass times out and cups reacts on this error with its policy (disable printer etc.).
I better not ask why this function needs to be called for each printer queue individually rather than wish I would found this configuration option more quickly ;-)
I will look if the one configuration option ruled them all or the original errors are still reproducible with those better timings. Mixed feelings about this because inhouse workstations where affected with the original problems.


chore(docs): fixed a typo in dark-mode doc

There is a typo in docs/dark-mode.

It says "opening an PR".
Fix:

@p-rohitt Looks like this is outdated now. I'm closing it but please re-open if you have any question. Thank you.


updated mactracker (7.5.1)

Thank you for the contribution. It was merged directly as 20a1924883478992ef77c4f3de7666e5f087d111 to keep commit history cleaner. Your contribution is still credited to you.


IEx strategy

Adds a strategy for running tests in the same OS process every time.
The first time a test is run, the process starts. From there, other runs communicate with the same process.
Still WIP, but mostly complete.
Closes #12

I found a small bug that won't clear past test result records, above contains 4 times records.

Another small bug is that the output cannot be displayed when the test passes. The left side is the result of iex test, the right side is the result of mix test

Also, does this strategy require the project to rely on {:ex_unit_notifier, "~> 1.2", only: :test}?

Running the test on the summary tree(by key r), it seems that the strategy used is still mix test:

Finally, I would like to say that the speed really Awesome.

I found a small bug that won't clear past test result records, above contains 4 times records.

Got it, should be easy to fix.

Another small bug is that the output cannot be displayed when the test passes. The left side is the result of iex test, the right side is the result of mix test

This is not related to this PR. It's because there is no output for successful tests. Maybe it could be set to something like "Test passed in 50ms".

Also, does this strategy require the project to rely on {:ex_unit_notifier, "~> 1.2", only: :test}?

No, if you are seeing that error, it is because you have that formatter listed in extra_formatters.

Running the test on the summary tree(by key r), it seems that the strategy used is still mix test:

The summary doesn't support specifying the strategy. You probably need to change the default strategy for the project in neotest.setup_project(). If you do, you won't need to pass it anymore in neotest.run.run() either.

@scottming Just fixed the two reported issues.

hi, Jhon, seems like the strategy field does not work in the setup.
		require("neotest-elixir")({
			args = { "--trace" },
      strategy = "iex",
		}),

but this lua require('neotest').run.run({strategy = 'iex'}) config will works

seems like the strategy field does not work in the setup.

Wrong place. It's a setting of the project in Neotest, not of the adapter.
require("neotest").setup_project(vim.loop.cwd(), {
  adapters = {...},
  default_strategy = "iex"
})

Another usage scenario we need to consider is that sometimes the loop of the iex strategy will hang, so we need to provide a function to end the process.
Currently lua require('neotest').run.stop() does not work
This problem can be reproduced when you type r at the file cursor of the side tree.


pioupload.py: UploadToDisk does not honor board needing .hex instead of .bin

I am using the Seeed Arch BLE board with firmware v0221 (2015-02-03) and it requires a .hex file to be copied to the "MBED" virtual USB disk.
The problem is that in /platformio/builder/tools/pioupload.py in lines 97 and 98 there is differentiation for .hex. Instead it reads:
    copyfile(join(env.subst("$BUILD_DIR"), "firmware.bin"),
             join(env.subst("$UPLOAD_PORT"), "firmware.bin"))

I changed this to
    copyfile(join(env.subst("$BUILD_DIR"), "firmware.hex"),
             join(env.subst("$UPLOAD_PORT"), "firmware.hex"))

in my local installation, but this is clearly not a scalable solution.
In fact I have another board out of the same series, but with a different MCU, the Seeed Arch Max which does required .bin files.
I would propose a proper patch, but don't know the platformio code well enough yet.
(Used version 2.3.4.)

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/27842727-pioupload-py-uploadtodisk-does-not-honor-platform-needing-hex-instead-of-bin?utm_campaign=plugin&utm_content=tracker%2F2014790&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F2014790&utm_medium=issues&utm_source=github).

Duplicate of https://github.com/platformio/platformio/issues/316


fix: Alternate way to debug addin - #63

Signed-off-by: K-Kumar-01<EMAIL_ADDRESS>

Closes #63

Configuration and documentation changes for alternate way to debug add-in.
Changes

 Launch.json file added
 Documentation updated.

Author Checklist

[x] Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
[ ] Vital features and changes captured in unit and/or integration tests
[x] Commits messages follow AP format
[x] Extend the documentation, if necessary
[x] Merging to master from fork:branchname
[ ] Manual accessibility test performed

[ ] Keyboard-only access, including forms
[ ] Contrast at least WCAG Level A
[ ] Appropriate labels, alt text, and instructions

@algomaster99
Requesting your review.

@K-Kumar-01 Thanks for this PR this new method for debugging the add-in works well 🎉


Is there a Python version of this code available?

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D435i

Firmware Version
NA

Operating System & Version
Ubuntu 18.04

Kernel Version (Linux Only)
5.0.0-36-generic

Platform
PC

SDK Version
NA

Language
python3.6

Segment
others

Face Antispoofing in Python
Can someone help me to conver the below chunk of code to Python. Appreciate your help.
bool find_depth_from(
    rs2::depth_frame const & frame,
    float const depth_scale,
    dlib::full_object_detection const & face,
    markup_68 markup_from, markup_68 markup_to,
    float * p_average_depth
)
{
    uint16_t const * data = reinterpret_cast<uint16_t const *>(frame.get_data());
    float average_depth = 0;
    size_t n_points = 0;
    for( int i = markup_from; i <= markup_to; ++i )
    {
        auto pt = face.part( i );
        auto depth_in_pixels = *(data + pt.y() * frame.get_width() + pt.x());
        if( !depth_in_pixels )
            continue;
        average_depth += depth_in_pixels * depth_scale;
        ++n_points;
    }
    if( !n_points )
        return false;
    if( p_average_depth )
        *p_average_depth = average_depth / n_points;
    return true;
}

Can someone tell me which pixel this line refers to?
auto depth_in_pixels = *(data + pt.y() * frame.get_width() + pt.x());

@RajkiranVeldur the depth frame data is stored in units that are called "pixels" here -- there's no standard convention that I know of, so that's the name that was used. Each "pixel" needs to then be scaled to an actual depth (in meters) by using the depth_scale.

@maloel thanks for the response. Does this mean that the variable will return the depth value of the landmark associated with it? For e.g., will it return x-depth value of nose_landmark?

@RajkiranVeldur The variable 'depth_in_pixels' is the depth (not in meters) of that specific landmark, yes.
The function iterates thru the landmark indices you give it and averages their depth.

@maloel thanks for replying. We were trying to implement this algorithm using MTCNN instead of Dlib, yet it wasn't accurate.

@RajkiranVeldur There's a pull request waiting right now that implements OpenVINO face detection (though without landmarks, which can be fairly easily added). I find the OpenVINO implementation (model) more robust (finds faces in a wider range of positions).
Check out their model zoo here.

@maloel OpenVINO is great, however we are more aligned towards MTCNN implementation for facial landmark detection but the accuracy is not even close to Dlib. Our main concern is we are planning to implement it at the edge. So, we are looking for a lightweight model and MTCNN is already lightweight.
Can you please guide us, how we can improve our accuracy with MTCNN based spoof-detection model?

Hi @RajkiranVeldur,
Can you please clarify what you mean by the accuracy issues? Are you referring to the accuracy of the depth you get from realsense, or the accuracy of MTCNN itself (such that the 5 points are off)?
Assuming the latter, it sounds like you need something more along the lines of DLIB's 68-point model which would provide many more points of reference. I did find one project with lightweight 68-point landmark extraction for javascript. Maybe the models it uses can be of use to you?

Hi @maloel yes, I was referring to the accuracy of using MTCNN with Realsense. Most of the time it was showing even a real person as Spoof. Might be, as you said it is because MTCNN gives us very fewer landmarks.
Also, may I get your's or anyone's email from the Realsense team? Actually, we would like to use Realsense with our Facial recognition product. We are from Techolution India Pvt Ltd and are working on a D435i camera for spoof detection and have NDA with Intel for information request regarding the RealSense (NDA Number: cnda037223). If it is not possible to share here, can you please email me on<EMAIL_ADDRESS>Thank you.

Hi @RajkiranVeldur
You can send me an email to<EMAIL_ADDRESS>Any general questions about using the technology are better discussed here, so more people could benefit from it

Hi @dorodnic thank you for sharing the contact details. Can you please help me with the C++ code to display some text on the frame window, depending on the condition?

@RajkiranVeldur
Putting text on a DLIB frame is a bit unintuitive.
Check here. Let me know if it works :).

@dorodnic @maloel can you tell me what are the landmarks you people are considering for the facial features?

@RajkiranVeldur
Putting text on a DLIB frame is a bit unintuitive.
Check here. Let me know if it works :).

Hey, @maloel it worked. Thank you :)

@dorodnic @maloel can you please tell me what are the landmarks you are considering for the facial features? Ear, Nose, Eye, Chin and Mouth with respect to the image below.

Hi @RajkiranVeldur
Is there anything further necessary on this thread?
*If we don’t hear from you in 7 days, this issue will be closed.


Node SDK fails when the app has a pending update

We are using the Node SDK (version 2.1.1), and I've seen several reports from developers in our org where our app suddenly fails to run with an error from envkey. They report that after opening the EnvKey app an update prompt appears and, following the update, our app resumes working correctly.
I'll try to come up with less anecdotal information once I can examine the problem in situ.

Thanks for reporting this @colvin--we're investigating.

This should now be fixed in version 2.1.2 of the Node SDK. Please re-open if you're still seeing any issues after upgrading!

@danenania I'm looking at the fix for this (0b75ff452323af02f01bab24f1f9ea55977192c1) + it looks like this is just a bandaid that doesn't prevent the issue from happening again.  Since this issue was closed, is there a better place to open a request for a fix that truly prevents the issue from happening again?  I'm happy to be corrected if my take is incorrect.

@slcrider The issue was that on the backend, we require clients to have a higher version than 2.1.0 due to some crypto performance optimizations that were implemented several months ago and require compatibility from the client.
The node package was self-reporting its version as 2.0.9 to the server, not the actual version, so the fix was simply to update reported version. The way this is written is unfortunately a bit error prone as referencing the version from package.json didn't work in some environments, so the version that gets sent to the server is duplicated, and it wasn't properly updated in the last couple releases.
I hope that makes more sense!

That makes sense, but I think still supports my ask - what does a fix that prevents future version drift look like?

Fair enough @slcrider. A test was just added to verify the versions match: https://github.com/envkey/envkey/compare/0b75ff4..3dccea8


Development mode prevents errors going into console

When development is set to true all errors are completely hidden. Is there away to have them show in the developer console like they would if this plugin wasn't installed? Thanks

Hi @nojacko
This is actually a bit tricky since ember-cli-sentry uses ravenjs ember plugin, which captures the exception.
Way back then it was not the case, we changed it in 1b8b756471cb478d312a20bf135cf81a324065ae by @rwjblue.
This change is actually quite good since it allows to benefit from plugin changes, but this is actually quite questionnable since it overwrites Ember.onerror and really messes up with logs with no clean possibility to keep standard error catching.
To answer your question: what you want is redefine the Ember.onerror in an initializer of your own that would call the already defined Ember.onerror (which is what the raven.js Ember plugin does).
// /instance-initializers/wheresmyerror.js

export function initialize(application) {

  let _onerror = Ember.onerror;

  Ember.onerror = function(error) {
    if (typeof _onerror === 'function') {
      _onerror.call(this, error);
    }
    // error handling, for example
    // throw error;
  }

  Ember.RSVP.on('error', function(error) {
    if (error !== undefined) {
      // error handling
    }
  });
}

export default {
  initialize,
  name: 'wheresmyerror'
};

Typing this makes little to no sense at all, but this would work I guess.
I'm wondering is whether or notember-cli-sentry should use the Ember plugin or not.
Any thought about it @rwjblue? I tried to ping @mattrobenolt about it with no luck so far.

What's up?

Hey @nojacko, I'm planning on doing rather heavy changes on the way this addon works.
I've pushed a branch that should work here: https://github.com/damiencaselli/ember-cli-sentry/tree/tsugi
It solves the problem you encounter by proxying the Raven object.
Could you please give it a shot and tell me what could be improved?
@mattrobenolt thanks for stopping by :bow:
Since Emberjs now encourages the use of ember-cli, do you think the emberjs plugin version of ravenjs should follow this tendency?
Doing this would avoid such problems as this one and that one by letting users choose how they want to handle Ember.onerror and RSVP errors.
Of course one could just install the emberless version of the plugin and handle it by themselves, but being backed by the GetSentry team would be awesome.
I've been working on a major refactor of this addon (see here) that addresses those issues, could you please have a look at it?
I'd gladly have someone from the GetSentry team to help maintain this repository, or give some advices|directions.
Cheers!

Since Emberjs now encourages the use of ember-cli, do you think the emberjs plugin version of ravenjs should follow this tendency?

Yeah, absolutely. I'm not an Ember developer, so this stuff is a bit foreign to me. We're down for supporting whatever the community needs.

I'd gladly have someone from the GetSentry team to help maintain this repository, or give some advices|directions.

I'd be happy to provide some general direction, but again, I'm not an ember user/developer, so my context is limited. I'm happy to support whatever makes sense.

Great!
So I guess moving the official emberjs plugin logic part to this add-on would be a good addition, so people can override default behaviour without much effort.

@damiencaselli When can we expect the new branch to drop? Excited about it.

I'm betting on a release this weekend.
The branch is actually pretty stable, but documentation has to be updated (who said "done"?), and I need to integrate the non-ember-cli plugin code to replicate current working state.

… or later this week more likely :smile_cat:

This should be fixed in the latest release (2.0.0-beta.1), feel free to let me know if you find any bug.

@devinus did you have the chance to test add-on next version beta (>= 2.0.0-beta.1)?

@damiencaselli Not yet, sorry. We had to use the old version and I'm looking for an opportunity to revisit it again.

I consider this issue resolved when updating to latest 2.0.0 (beta or not).


Make travis fail if Jenkins could not be triggered

https://github.com/monarch-initiative/mondo/blob/master/.travis.yml
We had an incident that the Jenkins server disappeared for two weeks, but travis did not fail, which gave the impression that all the QC succeeded.
I need some help with figuring out why travis did not fail:
https://travis-ci.org/github/monarch-initiative/mondo/builds/737340065#L215
I will try with adding --fail to the curl command.

Actually that is already there. Maybe we can try this:
https://superuser.com/questions/590099/can-i-make-curl-fail-with-an-exitcode-different-than-0-if-the-http-status-code-i

can we also investigate making things run fast enough such that we can just use travis?
or pay for travis enterprise?

can this be closed since we now use github actions?


fix typos and add extra punctuation

Description
Fixed some typos and made sentences smoother to read.
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[ ] Understand the repository structure
[ ] Add yourself as an author
[ ] Add your pattern
[ ] Add a great SVG diagram for your pattern
[ ] Read our general contribution guidelines
[ ] Read our code of conduct
[ ] Confirm your pattern frontmatter lints correctly. i.e. run npm install && npm run lint locally from your dev environment

Thank you very much!


Add org name to flow success message

Please describe the nature of this feature request

Add org name to flow success message Completed flow 'regression_org' successfully!

I often have to scroll up to verify which org I ran a flow on so it would be helpful to have it in the success message.

@Julian88Tex good idea. Here's where that line is produced if you want to try to fix it yourself: https://github.com/SFDO-Tooling/CumulusCI/blob/main/cumulusci/core/flowrunner.py#L418 ... should be a matter of including org_config.name

@davisagli thanks! just created the PR. Any chance there's a good doc on setting up CumulusCI locally for development so I can test it out?

@Julian88Tex You can tell us whether it's good or not, but that's what https://github.com/SFDO-Tooling/CumulusCI/blob/main/CONTRIBUTING.rst is for

Fixed in #2390


SpotifyPremium:falied to respond

Issue Description
when I'm trying to use sp command to play Spotify I got this error: SpotifyPremium:falied to respond
Functionality Affected
Please mark the functionality of the plugin that is affected by the issue:

[ ] Controlling the local Spotify client (changing track, pausing, skipping, muting)
[ ] Searching Spotify for albums, artists or songs

Software Versions
Please fill in the following information:

Spotify client version <IP_ADDRESS>0.g242057a2
Flow Launcher version 1.19.4

Please also make sure you're running the latest version of Flow.Launcher.Plugin.SpotifyPremium
Attached log file
2024-12-18.txt

nvm i forgot something in the security.store files


[BUG] Playwright Exception: Failed to read message from driver, pipe closed

Context:

Playwright Version: 1.12.1
Operating System: Windows
Browser: Chromium
Extra: Headless mode

Describe the bug
In our springboot application, We are using page.pdf() after navigating to a html page to print.
The code works fine initially i.e. all requests to convert html to pdf are sent to playwright and are successful.
But after a few days, for all the requests it starts throwing -
Playwright Exception thrown : Failed to read message from driver, pipe closed
And if we restart the application , the issue gets resolved.
What can be the reason for this ?

Looks like the driver (node) process dies for some reason. Is there anything interesting in stderr? You can try running with DEBUG=pw:browser to collect some more logs from the browser launcher.

For every request I am creating new playwright , browser, browser context and page objects.
         Playwright playwright = Playwright.create();

         BrowserType chromium = playwright.chromium();

         Browser browser = chromium.launch(new BrowserType.LaunchOptions()
                .setProxy(proxy).setChromiumSandbox(true));

         BrowserContext browserContext = browser.newContext();

        Page page = browserContext.newPage();

After it gets completed (navigates and prints) I close all the 4 objects like this -
        page.close();
        browserContext.close();
        browser.close();
        playwright.close();

I was not having debug flag while the issue arose, so I could not see anything in stderr and simple restarting application resolved the issue for now.
However , This issue may arise after a while again.
Is there anything you suggest that we can do to prevent it or to better diagnose issue?

Is there anything you suggest that we can do to prevent it or to better diagnose issue?

 Since it happens after a few days it might be that the temp folder where we extract the driver is changed by another app/deleted. Do I get it right that the playwright app is running for a few days without restart?

For every request I am creating new playwright , browser, browser context and page objects.

Just curious, is there a reason you recreate playwright and browser rather than just context?

 Since it happens after a few days it might be that the temp folder where we extract the driver is changed by another app/deleted. Do I get it right that the playwright app is running for a few days without restart?
Yes right. The app is running without restart.

Just curious, is there a reason you recreate playwright and browser rather than just context?
Yes. This is because playwright is not thread-safe.
Initially I was using the same approach to create new browser context for every request and other objects only once but in case of concurrent requests coming on the app, I was getting Playwright Exceptions something like  "Object doesn't exist" .

@yury-s  Can you tell if there is a way to monitor when the playwright should be restarted ?

Can you please tell if there is a way to monitor when the playwright should be restarted ?

You should not need to restart it, there is either a bug or the driver is running out of memory like I mentioned above.

Yes. This is because playwright is not thread-safe.

Interesting, so now you have the app create/close many playwright instances on parallel threads and eventually the driver starts throwing the error, is that correct?

Interesting, so now you have the app create/close many playwright instances on parallel threads and eventually the driver starts throwing the error, is that correct?

@yury-s When I create all playwright instances (playwright, browser, browser context, page) seperately on each thread , I do not get this exception. But if I create only browser context seperately for each new thread ( not rest of the playwright instances) ,  I get this exception.

@yury-s When I create all playwright instances (playwright, browser, browser context, page) seperately on each thread , I do not get this exception. But if I create only browser context seperately for each new thread ( not rest of the playwright instances) , I get this exception.

Well, as our documentation  says it is unsafe to do this, and you are expected to get exceptions like "Object doesn't exist".


fix: intentionality of async / promise code for question generation

Description

Addresses an issue where async methods in the quiz designer were not being properly handled, and Sonar was flagging it for intentionality

:tada: This PR is included in version 1.17.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Policies are accessible to all connectors

While not necessarily a bug but rather a design issue I am posting it is a bug anyway to get the discussion started somewhere:
When negotiating a new contract a connector can list the policies of any resource in full, including all details. In fact, these details are even required as API input.
IMHO this poses a serious security risk as anyone can essentially figure out who has access to what data. I doubt that this is acceptable to the legal departments of any bigger company.
Thus, I propose to simply hide the permission details from consumer connectors. They do not need to know why they have access or not. Instead of requiring the full permission rule as API input just stick to the requested access type (like idsc:use).
Side note: Why is it possible to negotiate a contract for an artifact I do not have access to anyway?

I agree with the point that asking about permission details is a security leak. Any consumer is able to ask any provider about permission details, use the permission details for creating contracts and get the data from the provider (assumed both are valid connectors with valid certificates and the endpoints are known).
A possible solution could be, that the DAPS authorize the communication between specific connectors and therefore asking about the permission information is allowed?

After a lot of thinking I have to change my opinion on this: the only issue are in fact usage permissions in the form of white lists, etc.. These, however, should not really be part of the contract offer to begin with. I would assume that the idea is rather that contract offers come with a set of conditions (just like contracts "in the real world") ranging from "consumer needs an account at xyz" to "by agreeing to this contract the consumer consents to a monthly fee of N". The current restriction of contract offers to specific consumer connectors is, thus, only a stop-gap until we have support for these more sophisticated policies.
That said, I still think that, given the lack of policy support atm, it would be good to have a separate set of permissions for a contract offer which are in fact private (not visible to consumer connectors) and state which connectors are allowed to negotiate a contract based on an offer.
This might require an extension to the IDS model, that I am not sure about atm.
In summary:

contract offers should not be private, my original claim was simply wrong
contract offers should have a separate, private set of permissions which the provider connector can use to determine which consumer is allowed to negotiate a contract (stop-gap until we have full policy support with payment models, etc.)

Closing this issue for good now as I realized that contracts are actually only useful with proper policies that do not restrict the connector via a white list etc..


[BUG] CSI Back-off restarting: Can't connect unix:///csi/csi.sock

What happened: CSI nodes are in crash loop. (Cannot connect to socket)

Timeline/Details ⚠

⚠
Back-off restarting failed container juicefs-plugin in pod juicefs-csi-node-psz5n_kube-system(<uuidv4>)
Source kubelet <node>
Count 36
Sub-object spec.containers{juicefs-plugin}
Last seen 2023-07-03T04:41:01+03:00

Container juicefs-plugin failed liveness probe, will be restarted
Source kubelet <node>
Count 2
Sub-object spec.containers{juicefs-plugin}
Last seen 2023-07-03T04:27:57+03:00

⚠
Liveness probe failed: Get "http://<IP_ADDRESS>:9909/healthz": dial tcp <IP_ADDRESS>:9909: connect: connection refused
Source kubelet <node>
Count <unlimited>
Sub-object spec.containers{juicefs-plugin}
Last seen 2023-07-03T04:27:57+03:00

Started container node-driver-registrar
Source kubelet <node>
Count 1
Sub-object spec.containers{node-driver-registrar}
Last seen 2023-07-03T04:25:59+03:00

Container image "registry.k8s.io/sig-storage/livenessprobe:v2.10.0" already present on machine
Source kubelet <node>
Count 1
Sub-object spec.containers{liveness-probe}
Last seen 2023-07-03T04:25:59+03:00

Created container liveness-probe
Source kubelet <node>
Count 1
Sub-object spec.containers{liveness-probe}
Last seen 2023-07-03T04:25:59+03:00

Started container liveness-probe
Source kubelet <node>
Count 1
Sub-object spec.containers{liveness-probe}
Last seen 2023-07-03T04:25:59+03:00

Container image "juicedata/juicefs-csi-driver:v0.20.0" already present on machine
Source kubelet <node>
Count 3
Sub-object spec.containers{juicefs-plugin}
Last seen 2023-07-03T04:27:58+03:00

Created container juicefs-plugin
Source kubelet <node>
Count 2
Sub-object spec.containers{juicefs-plugin}
Last seen 2023-07-03T04:26:58+03:00

Started container juicefs-plugin
Source kubelet <node>
Count 6
Sub-object spec.containers{juicefs-plugin}
Last seen 2023-07-03T04:30:58+03:00

Container image "registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0" already present on machine
Source kubelet <node>
Count 1
Sub-object spec.containers{node-driver-registrar}
Last seen 2023-07-03T04:25:58+03:00

Created container node-driver-registrar
Source kubelet <node>
Count 1
Sub-object spec.containers{node-driver-registrar}
Last seen 2023-07-03T04:25:58+03:00

Successfully assigned kube-system/juicefs-csi-node-psz5n to <node>
Source <unknown>
Count
Sub-object

What you expected to happen:  Do not crash, keep running
How to reproduce it (as minimally and precisely as possible): I have not tried outside of the current env.

Anything else we need to know?

Logs: juicefs-csi-controller-0

juicefs-plugin
I0703 01:25:58.645185       7 main.go:90] Run CSI controller
I0703 01:25:58.850751       7 driver.go:48] Driver: csi.juicefs.com version v0.19.0-24-gf93ad97 commit f93ad97aaa3484f5a493909d9f510de149021d81 date 2023-06-13T02:14:37Z
I0703 01:25:59.167040       7 driver.go:113] Listening for connection on address: &net.UnixAddr{Name:"/var/lib/csi/sockets/pluginproxy/csi.sock", Net:"unix"}
I0703 01:25:59.253240       7 mount_manager.go:108] Mount manager started.
I0703 01:25:59.253984       7 leaderelection.go:248] attempting to acquire leader lease kube-system/mount.juicefs.com...
I0703 01:26:17.197239       7 leaderelection.go:258] successfully acquired lease kube-system/mount.juicefs.com

csi-provisioner
I0703 01:25:59.154339       1 feature_gate.go:245] feature gates: &{map[]}
I0703 01:25:59.154452       1 csi-provisioner.go:150] Version: v3.3.0
I0703 01:25:59.154460       1 csi-provisioner.go:173] Building kube configs for running in cluster...

I0703 01:26:00.277480       1 leaderelection.go:352] lock is held by<PHONE_NUMBER>364-8081-csi-juicefs-com and has not yet expired
I0703 01:26:00.277518       1 leaderelection.go:253] failed to acquire lease kube-system/csi-juicefs-com
I0703 01:26:00.277583       1 leader_election.go:185] new leader detected, current leader:<PHONE_NUMBER>364-8081-csi-juicefs-com
I0703 01:26:10.955227       1 leaderelection.go:352] lock is held by<PHONE_NUMBER>364-8081-csi-juicefs-com and has not yet expired
I0703 01:26:10.955789       1 leaderelection.go:253] failed to acquire lease kube-system/csi-juicefs-com
I0703 01:26:20.014249       1 leaderelection.go:258] successfully acquired lease kube-system/csi-juicefs-com
I0703 01:26:20.016199       1 leader_election.go:185] new leader detected, current leader:<PHONE_NUMBER>182-8081-csi-juicefs-com
I0703 01:26:20.016253       1 leader_election.go:178] became leader, starting
I0703 01:26:20.019347       1 reflector.go:221] Starting reflector *v1.StorageClass (1h0m0s) from k8s.io/client-go/informers/factory.go:134
I0703 01:26:20.019413       1 reflector.go:257] Listing and watching *v1.StorageClass from k8s.io/client-go/informers/factory.go:134
I0703 01:26:20.019866       1 reflector.go:221] Starting reflector *v1.PersistentVolumeClaim (15m0s) from k8s.io/client-go/informers/factory.go:134
I0703 01:26:20.019989       1 reflector.go:257] Listing and watching *v1.PersistentVolumeClaim from k8s.io/client-go/informers/factory.go:134
I0703 01:26:20.117873       1 shared_informer.go:285] caches populated
I0703 01:26:20.118229       1 shared_informer.go:285] caches populated
I0703 01:26:20.118280       1 controller.go:811] Starting provisioner controller csi.juicefs.com_juicefs-csi-controller-0_76e78fff-4fe8-424f-8019-398df9d08562!
I0703 01:26:20.118788       1 reflector.go:221] Starting reflector *v1.PersistentVolume (15m0s) from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:845
I0703 01:26:20.118960       1 reflector.go:257] Listing and watching *v1.PersistentVolume from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:845
I0703 01:26:20.119294       1 reflector.go:221] Starting reflector *v1.StorageClass (15m0s) from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:848
I0703 01:26:20.119326       1 reflector.go:257] Listing and watching *v1.StorageClass from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:848
I0703 01:26:20.119755       1 volume_store.go:97] Starting save volume queue
I0703 01:26:20.133334       1 leaderelection.go:278] successfully renewed lease kube-system/csi-juicefs-com
I0703 01:26:20.219319       1 shared_informer.go:285] caches populated
I0703 01:26:20.220879       1 controller.go:860] Started provisioner controller csi.juicefs.com_juicefs-csi-controller-0_76e78fff-4fe8-424f-8019-398df9d08562!

I0703 01:26:01.637586       7 leaderelection.go:248] attempting to acquire leader lease kube-system/mount.juicefs.com...

csi-provisioner
I0703 01:26:01.378582       1 feature_gate.go:245] feature gates: &{map[]}
I0703 01:26:01.378716       1 csi-provisioner.go:150] Version: v3.3.0
I0703 01:26:01.378726       1 csi-provisioner.go:173] Building kube configs for running in cluster...

I also verified there is access to the cluster node using the service account as it should be with this command:
> curl https://<IP_ADDRESS>:10250/pods/ --insecure -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

All debugging led me to run ss on the container and I did not find socket information there.
kubectl exec -n kube-system -ti juicefs-csi-node-6rkdg -- bash
root@juicefs-csi-node-6rkdg:/app# ss
Netid                 State                 Recv-Q                 Send-Q                                 Local Address:Port                                  Peer Address:Port
tcp                   ESTAB                 0                      0                                        <IP_ADDRESS>:54048                                    <IP_ADDRESS>:https
tcp                   ESTAB                 0                      0                                        <IP_ADDRESS>:33974                                   <IP_ADDRESS>:10250

Anyways, thanks for your possible help in advance. Feel free to ask if you need any more exact details or otherwise I could help with this.

More details

Describe: juicefs-csi-node-bzmwn ⚠

⚠
Name:                 juicefs-csi-node-bzmwn
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Service Account:      juicefs-csi-node-sa
Node:                 <node>/<IP_ADDRESS>
Start Time:           Mon, 03 Jul 2023 04:25:57 +0300
Labels:               app=juicefs-csi-node
                      app.kubernetes.io/instance=juicefs-csi-driver
                      app.kubernetes.io/name=juicefs-csi-driver
                      controller-revision-hash=6f47785f45
                      pod-template-generation=1
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  DaemonSet/juicefs-csi-node
Containers:
  juicefs-plugin:
    Container ID:  containerd://40562f9bc000e9502f51801621bb3f380d65fc7d1ec4f971bc08d94e4b97b50d
    Image:         juicedata/juicefs-csi-driver:v0.20.0
    Image ID:      docker.io/juicedata/juicefs-csi-driver@sha256:43978fc60798a2bd6ae8e5ad340917267d91905f33ab4b0356918a7405b66af9
    Port:          9909/TCP
    Host Port:     0/TCP
    Args:
      --endpoint=$(CSI_ENDPOINT)
      --logtostderr
      --nodeid=$(NODE_NAME)
      --v=5
      --enable-manager=true
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    143
      Started:      Mon, 03 Jul 2023 05:12:38 +0300
      Finished:     Mon, 03 Jul 2023 05:13:37 +0300
    Ready:          False
    Restart Count:  17
    Limits:
      cpu:     1
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  512Mi
    Liveness:  http-get http://:healthz/healthz delay=10s timeout=3s period=10s #success=1 #failure=5
    Environment:
      CSI_ENDPOINT:             unix:/csi/csi.sock
      NODE_NAME:                 (v1:spec.nodeName)
      POD_NAME:                 juicefs-csi-node-bzmwn (v1:metadata.name)
      JUICEFS_MOUNT_NAMESPACE:  kube-system (v1:metadata.namespace)
      HOST_IP:                   (v1:status.hostIP)
      KUBELET_PORT:             10250
      JUICEFS_MOUNT_PATH:       /var/lib/juicefs/volume
      JUICEFS_CONFIG_PATH:      /var/lib/juicefs/config
    Mounts:
      /csi from plugin-dir (rw)
      /dev from device-dir (rw)
      /jfs from jfs-dir (rw)
      /root/.juicefs from jfs-root-dir (rw)
      /var/lib/kubelet from kubelet-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-7bkjz (ro)
  node-driver-registrar:
    Container ID:  containerd://80074371e951feb62d484fbacff0edf47db21f0f411de5639edb848fe89e7be2
    Image:         registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0
    Image ID:      registry.k8s.io/sig-storage/csi-node-driver-registrar@sha256:f6717ce72a2615c7fbc746b4068f788e78579c54c43b8716e5ce650d97af2df1
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)
      --v=5
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:58 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:               /csi/csi.sock
      DRIVER_REG_SOCK_PATH:  /var/lib/kubelet/csi-plugins/csi.juicefs.com/csi.sock
    Mounts:
      /csi from plugin-dir (rw)
      /registration from registration-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-7bkjz (ro)
  liveness-probe:
    Container ID:  containerd://71dc80886764b440b3feedf3781af2c4730517dbf99552e2a58fc23f13219211
    Image:         registry.k8s.io/sig-storage/livenessprobe:v2.10.0
    Image ID:      registry.k8s.io/sig-storage/livenessprobe@sha256:4dc0b87ccd69f9865b89234d8555d3a614ab0a16ed94a3016ffd27f8106132ce
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --health-port=$(HEALTH_PORT)
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:58 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:      /csi/csi.sock
      HEALTH_PORT:  9909
    Mounts:
      /csi from plugin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-7bkjz (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kubelet-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet
    HostPathType:  Directory
  plugin-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet/csi-plugins/csi.juicefs.com/
    HostPathType:  DirectoryOrCreate
  registration-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet/plugins_registry/
    HostPathType:  Directory
  device-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /dev
    HostPathType:  Directory
  jfs-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/volume
    HostPathType:  DirectoryOrCreate
  jfs-root-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/config
    HostPathType:  DirectoryOrCreate
  kube-api-access-7bkjz:
    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:              <none>
Tolerations:                 CriticalAddonsOnly op=Exists
                             node.kubernetes.io/disk-pressure:NoSchedule op=Exists
                             node.kubernetes.io/memory-pressure: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  50m                  default-scheduler  Successfully assigned kube-system/juicefs-csi-node-bzmwn to <node>
  Normal   Started    50m                  kubelet            Started container liveness-probe
  Normal   Pulled     50m                  kubelet            Container image "registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0" already present on machine
  Normal   Created    50m                  kubelet            Created container node-driver-registrar
  Normal   Started    50m                  kubelet            Started container node-driver-registrar
  Normal   Pulled     50m                  kubelet            Container image "registry.k8s.io/sig-storage/livenessprobe:v2.10.0" already present on machine
  Normal   Created    50m                  kubelet            Created container liveness-probe
  Normal   Created    49m (x2 over 50m)    kubelet            Created container juicefs-plugin
  Normal   Pulled     48m (x3 over 50m)    kubelet            Container image "juicedata/juicefs-csi-driver:v0.20.0" already present on machine
  Normal   Killing    48m (x2 over 49m)    kubelet            Container juicefs-plugin failed liveness probe, will be restarted
  Normal   Started    45m (x6 over 50m)    kubelet            Started container juicefs-plugin
  Warning  Unhealthy  10m (x78 over 50m)   kubelet            Liveness probe failed: Get "http://<IP_ADDRESS>:9909/healthz": dial tcp <IP_ADDRESS>:9909: connect: connection refused
  Warning  BackOff    48s (x157 over 44m)  kubelet            Back-off restarting failed container juicefs-plugin in pod juicefs-csi-node-bzmwn_kube-system(609f0cc0-772d-4692-9668-6b8e7857a92b)

Describe: juicefs-csi-node-jxf2p ⚠

⚠
Name:                 juicefs-csi-node-jxf2p
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Service Account:      juicefs-csi-node-sa
Node:                 <node>/<IP_ADDRESS>
Start Time:           Mon, 03 Jul 2023 04:25:57 +0300
Labels:               app=juicefs-csi-node
                      app.kubernetes.io/instance=juicefs-csi-driver
                      app.kubernetes.io/name=juicefs-csi-driver
                      controller-revision-hash=6f47785f45
                      pod-template-generation=1
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  DaemonSet/juicefs-csi-node
Containers:
  juicefs-plugin:
    Container ID:  containerd://114d8aef4ccab28e4c296dfacab31f79cf4da105b9f5417970dd964a69bfd499
    Image:         juicedata/juicefs-csi-driver:v0.20.0
    Image ID:      docker.io/juicedata/juicefs-csi-driver@sha256:43978fc60798a2bd6ae8e5ad340917267d91905f33ab4b0356918a7405b66af9
    Port:          9909/TCP
    Host Port:     0/TCP
    Args:
      --endpoint=$(CSI_ENDPOINT)
      --logtostderr
      --nodeid=$(NODE_NAME)
      --v=5
      --enable-manager=true
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    143
      Started:      Mon, 03 Jul 2023 05:19:18 +0300
      Finished:     Mon, 03 Jul 2023 05:20:17 +0300
    Ready:          False
    Restart Count:  19
    Limits:
      cpu:     1
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  512Mi
    Liveness:  http-get http://:healthz/healthz delay=10s timeout=3s period=10s #success=1 #failure=5
    Environment:
      CSI_ENDPOINT:             unix:/csi/csi.sock
      NODE_NAME:                 (v1:spec.nodeName)
      POD_NAME:                 juicefs-csi-node-jxf2p (v1:metadata.name)
      JUICEFS_MOUNT_NAMESPACE:  kube-system (v1:metadata.namespace)
      HOST_IP:                   (v1:status.hostIP)
      KUBELET_PORT:             10250
      JUICEFS_MOUNT_PATH:       /var/lib/juicefs/volume
      JUICEFS_CONFIG_PATH:      /var/lib/juicefs/config
    Mounts:
      /csi from plugin-dir (rw)
      /dev from device-dir (rw)
      /jfs from jfs-dir (rw)
      /root/.juicefs from jfs-root-dir (rw)
      /var/lib/kubelet from kubelet-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kghc4 (ro)
  node-driver-registrar:
    Container ID:  containerd://e9ed2cb84d324df2da4664c10d0e7e9c131b89a65278a9ce3a46770dc8d816c6
    Image:         registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0
    Image ID:      registry.k8s.io/sig-storage/csi-node-driver-registrar@sha256:f6717ce72a2615c7fbc746b4068f788e78579c54c43b8716e5ce650d97af2df1
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)
      --v=5
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:58 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:               /csi/csi.sock
      DRIVER_REG_SOCK_PATH:  /var/lib/kubelet/csi-plugins/csi.juicefs.com/csi.sock
    Mounts:
      /csi from plugin-dir (rw)
      /registration from registration-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kghc4 (ro)
  liveness-probe:
    Container ID:  containerd://53e5e9b675295aa6dd3ad86ae25153cdc052b07ef1fcb83d0cc3b387ea13258d
    Image:         registry.k8s.io/sig-storage/livenessprobe:v2.10.0
    Image ID:      registry.k8s.io/sig-storage/livenessprobe@sha256:4dc0b87ccd69f9865b89234d8555d3a614ab0a16ed94a3016ffd27f8106132ce
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --health-port=$(HEALTH_PORT)
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:58 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:      /csi/csi.sock
      HEALTH_PORT:  9909
    Mounts:
      /csi from plugin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kghc4 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kubelet-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet
    HostPathType:  Directory
  plugin-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet/csi-plugins/csi.juicefs.com/
    HostPathType:  DirectoryOrCreate
  registration-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet/plugins_registry/
    HostPathType:  Directory
  device-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /dev
    HostPathType:  Directory
  jfs-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/volume
    HostPathType:  DirectoryOrCreate
  jfs-root-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/config
    HostPathType:  DirectoryOrCreate
  kube-api-access-kghc4:
    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:              <none>
Tolerations:                 CriticalAddonsOnly op=Exists
                             node.kubernetes.io/disk-pressure:NoSchedule op=Exists
                             node.kubernetes.io/memory-pressure: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  55m                 default-scheduler  Successfully assigned kube-system/juicefs-csi-node-jxf2p to <node>
  Normal   Started    55m                 kubelet            Started container liveness-probe
  Normal   Pulled     55m                 kubelet            Container image "registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0" already present on machine
  Normal   Created    55m                 kubelet            Created container node-driver-registrar
  Normal   Started    55m                 kubelet            Started container node-driver-registrar
  Normal   Pulled     55m                 kubelet            Container image "registry.k8s.io/sig-storage/livenessprobe:v2.10.0" already present on machine
  Normal   Created    55m                 kubelet            Created container liveness-probe
  Normal   Created    54m (x2 over 55m)   kubelet            Created container juicefs-plugin
  Normal   Killing    53m (x2 over 54m)   kubelet            Container juicefs-plugin failed liveness probe, will be restarted
  Normal   Pulled     53m (x3 over 55m)   kubelet            Container image "juicedata/juicefs-csi-driver:v0.20.0" already present on machine
  Normal   Started    50m (x6 over 55m)   kubelet            Started container juicefs-plugin
  Warning  Unhealthy  15m (x80 over 54m)  kubelet            Liveness probe failed: Get "http://<IP_ADDRESS>:9909/healthz": dial tcp <IP_ADDRESS>:9909: connect: connection refused
  Warning  BackOff    0s (x175 over 49m)  kubelet            Back-off restarting failed container juicefs-plugin in pod juicefs-csi-node-jxf2p_kube-system(ed2198d0-07f1-4e83-acd2-a22ae4405319)

Describe: juicefs-csi-node-psz5n ⚠

⚠
Name:                 juicefs-csi-node-psz5n
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Service Account:      juicefs-csi-node-sa
Node:                 <node>/<IP_ADDRESS>
Start Time:           Mon, 03 Jul 2023 04:25:57 +0300
Labels:               app=juicefs-csi-node
                      app.kubernetes.io/instance=juicefs-csi-driver
                      app.kubernetes.io/name=juicefs-csi-driver
                      controller-revision-hash=6f47785f45
                      pod-template-generation=1
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  DaemonSet/juicefs-csi-node
Containers:
  juicefs-plugin:
    Container ID:  containerd://0a4ffeecb35d9c02dfa2f8522d2038bc85900c89c21d7ddf55405527cd2b54da
    Image:         juicedata/juicefs-csi-driver:v0.20.0
    Image ID:      docker.io/juicedata/juicefs-csi-driver@sha256:43978fc60798a2bd6ae8e5ad340917267d91905f33ab4b0356918a7405b66af9
    Port:          9909/TCP
    Host Port:     0/TCP
    Args:
      --endpoint=$(CSI_ENDPOINT)
      --logtostderr
      --nodeid=$(NODE_NAME)
      --v=5
      --enable-manager=true
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    143
      Started:      Mon, 03 Jul 2023 05:19:18 +0300
      Finished:     Mon, 03 Jul 2023 05:20:18 +0300
    Ready:          False
    Restart Count:  19
    Limits:
      cpu:     1
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  512Mi
    Liveness:  http-get http://:healthz/healthz delay=10s timeout=3s period=10s #success=1 #failure=5
    Environment:
      CSI_ENDPOINT:             unix:/csi/csi.sock
      NODE_NAME:                 (v1:spec.nodeName)
      POD_NAME:                 juicefs-csi-node-psz5n (v1:metadata.name)
      JUICEFS_MOUNT_NAMESPACE:  kube-system (v1:metadata.namespace)
      HOST_IP:                   (v1:status.hostIP)
      KUBELET_PORT:             10250
      JUICEFS_MOUNT_PATH:       /var/lib/juicefs/volume
      JUICEFS_CONFIG_PATH:      /var/lib/juicefs/config
    Mounts:
      /csi from plugin-dir (rw)
      /dev from device-dir (rw)
      /jfs from jfs-dir (rw)
      /root/.juicefs from jfs-root-dir (rw)
      /var/lib/kubelet from kubelet-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-wjk8s (ro)
  node-driver-registrar:
    Container ID:  containerd://1cc9a2dce8818e147faa1e218cdd644e753a167997968e2e1f2a27b05aac292b
    Image:         registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0
    Image ID:      registry.k8s.io/sig-storage/csi-node-driver-registrar@sha256:f6717ce72a2615c7fbc746b4068f788e78579c54c43b8716e5ce650d97af2df1
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)
      --v=5
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:59 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:               /csi/csi.sock
      DRIVER_REG_SOCK_PATH:  /var/lib/kubelet/csi-plugins/csi.juicefs.com/csi.sock
    Mounts:
      /csi from plugin-dir (rw)
      /registration from registration-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-wjk8s (ro)
  liveness-probe:
    Container ID:  containerd://ee3166d57344da8e272b6e729693854cd028a5a78dfd3ca2ebd7c2a43ba6215d
    Image:         registry.k8s.io/sig-storage/livenessprobe:v2.10.0
    Image ID:      registry.k8s.io/sig-storage/livenessprobe@sha256:4dc0b87ccd69f9865b89234d8555d3a614ab0a16ed94a3016ffd27f8106132ce
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --health-port=$(HEALTH_PORT)
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:59 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:      /csi/csi.sock
      HEALTH_PORT:  9909
    Mounts:
      /csi from plugin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-wjk8s (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kubelet-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet
    HostPathType:  Directory
  plugin-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet/csi-plugins/csi.juicefs.com/
    HostPathType:  DirectoryOrCreate
  registration-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet/plugins_registry/
    HostPathType:  Directory
  device-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /dev
    HostPathType:  Directory
  jfs-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/volume
    HostPathType:  DirectoryOrCreate
  jfs-root-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/config
    HostPathType:  DirectoryOrCreate
  kube-api-access-wjk8s:
    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:              <none>
Tolerations:                 CriticalAddonsOnly op=Exists
                             node.kubernetes.io/disk-pressure:NoSchedule op=Exists
                             node.kubernetes.io/memory-pressure: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  55m                  default-scheduler  Successfully assigned kube-system/juicefs-csi-node-psz5n to <node>
  Normal   Pulled     55m                  kubelet            Container image "registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0" already present on machine
  Normal   Created    55m                  kubelet            Created container node-driver-registrar
  Normal   Started    55m                  kubelet            Started container liveness-probe
  Normal   Started    55m                  kubelet            Started container node-driver-registrar
  Normal   Pulled     55m                  kubelet            Container image "registry.k8s.io/sig-storage/livenessprobe:v2.10.0" already present on machine
  Normal   Created    55m                  kubelet            Created container liveness-probe
  Normal   Created    54m (x2 over 55m)    kubelet            Created container juicefs-plugin
  Normal   Killing    53m (x2 over 54m)    kubelet            Container juicefs-plugin failed liveness probe, will be restarted
  Normal   Pulled     53m (x3 over 55m)    kubelet            Container image "juicedata/juicefs-csi-driver:v0.20.0" already present on machine
  Normal   Started    30m (x12 over 55m)   kubelet            Started container juicefs-plugin
  Warning  Unhealthy  15m (x80 over 55m)   kubelet            Liveness probe failed: Get "http://<IP_ADDRESS>:9909/healthz": dial tcp <IP_ADDRESS>:9909: connect: connection refused
  Warning  BackOff    27s (x171 over 49m)  kubelet            Back-off restarting failed container juicefs-plugin in pod juicefs-csi-node-psz5n_kube-system(d9601f75-f75c-451c-a547-d7b327f26967)

Describe: juicefs-csi-controller-0

Name:                 juicefs-csi-controller-0
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-cluster-critical
Service Account:      juicefs-csi-controller-sa
Node:                 <node>/<IP_ADDRESS>
Start Time:           Mon, 03 Jul 2023 04:25:57 +0300
Labels:               app=juicefs-csi-controller
                      app.kubernetes.io/instance=juicefs-csi-driver
                      app.kubernetes.io/name=juicefs-csi-driver
                      controller-revision-hash=juicefs-csi-controller-5dfb49d587
                      statefulset.kubernetes.io/pod-name=juicefs-csi-controller-0
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  StatefulSet/juicefs-csi-controller
Containers:
  juicefs-plugin:
    Container ID:  containerd://47fdb990aa9832dd7d23b35c3be09c95cd40e8d77faa14bc65cb3e4f1f69b8ba
    Image:         juicedata/juicefs-csi-driver:v0.20.0
    Image ID:      docker.io/juicedata/juicefs-csi-driver@sha256:43978fc60798a2bd6ae8e5ad340917267d91905f33ab4b0356918a7405b66af9
    Port:          9909/TCP
    Host Port:     0/TCP
    Args:
      --endpoint=$(CSI_ENDPOINT)
      --logtostderr
      --nodeid=$(NODE_NAME)
      --v=5
      --leader-election
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:58 +0300
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  512Mi
    Liveness:  http-get http://:healthz/healthz delay=10s timeout=3s period=10s #success=1 #failure=5
    Environment:
      CSI_ENDPOINT:             unix:///var/lib/csi/sockets/pluginproxy/csi.sock
      POD_NAME:                 juicefs-csi-controller-0 (v1:metadata.name)
      NODE_NAME:                 (v1:spec.nodeName)
      JUICEFS_MOUNT_NAMESPACE:  kube-system (v1:metadata.namespace)
      JUICEFS_MOUNT_PATH:       /var/lib/juicefs/volume
      JUICEFS_CONFIG_PATH:      /var/lib/juicefs/config
    Mounts:
      /jfs from jfs-dir (rw)
      /root/.juicefs from jfs-root-dir (rw)
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-rrcbg (ro)
  csi-provisioner:
    Container ID:  containerd://1535b2af3ff30e13aba5042faf18fa4af832c03d1df6f83749f9ad648edc900b
    Image:         registry.k8s.io/sig-storage/csi-provisioner:v3.3.0
    Image ID:      registry.k8s.io/sig-storage/csi-provisioner@sha256:ee3b525d5b89db99da3b8eb521d9cd90cb6e9ef0fbb651e98bb37be78d36b5b8
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --timeout=60s
      --v=5
      --leader-election
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:58 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:  /var/lib/csi/sockets/pluginproxy/csi.sock
    Mounts:
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-rrcbg (ro)
  liveness-probe:
    Container ID:  containerd://aef7ddbd3b3121316ff3327c25430cfc3bc6524a0fcebef5fbce0774bcadbd7d
    Image:         registry.k8s.io/sig-storage/livenessprobe:v2.10.0
    Image ID:      registry.k8s.io/sig-storage/livenessprobe@sha256:4dc0b87ccd69f9865b89234d8555d3a614ab0a16ed94a3016ffd27f8106132ce
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --health-port=$(HEALTH_PORT)
    State:          Running
      Started:      Mon, 03 Jul 2023 04:25:59 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:      /csi/csi.sock
      HEALTH_PORT:  9909
    Mounts:
      /csi from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-rrcbg (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  socket-dir:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  jfs-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/volume
    HostPathType:  DirectoryOrCreate
  jfs-root-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/config
    HostPathType:  DirectoryOrCreate
  kube-api-access-rrcbg:
    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:              <none>
Tolerations:                 CriticalAddonsOnly op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  56m   default-scheduler  Successfully assigned kube-system/juicefs-csi-controller-0 to <node>
  Normal  Pulled     56m   kubelet            Container image "juicedata/juicefs-csi-driver:v0.20.0" already present on machine
  Normal  Created    56m   kubelet            Created container juicefs-plugin
  Normal  Started    56m   kubelet            Started container juicefs-plugin
  Normal  Pulled     56m   kubelet            Container image "registry.k8s.io/sig-storage/csi-provisioner:v3.3.0" already present on machine
  Normal  Created    56m   kubelet            Created container csi-provisioner
  Normal  Started    56m   kubelet            Started container csi-provisioner
  Normal  Pulled     56m   kubelet            Container image "registry.k8s.io/sig-storage/livenessprobe:v2.10.0" already present on machine
  Normal  Created    56m   kubelet            Created container liveness-probe
  Normal  Started    56m   kubelet            Started container liveness-probe

Describe: juicefs-csi-controller-1

Name:                 juicefs-csi-controller-1
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-cluster-critical
Service Account:      juicefs-csi-controller-sa
Node:                 <node>/<IP_ADDRESS>
Start Time:           Mon, 03 Jul 2023 04:26:00 +0300
Labels:               app=juicefs-csi-controller
                      app.kubernetes.io/instance=juicefs-csi-driver
                      app.kubernetes.io/name=juicefs-csi-driver
                      controller-revision-hash=juicefs-csi-controller-5dfb49d587
                      statefulset.kubernetes.io/pod-name=juicefs-csi-controller-1
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  StatefulSet/juicefs-csi-controller
Containers:
  juicefs-plugin:
    Container ID:  containerd://3c3b8364668416aaf929f8e562559432bab8d18e3ad9b5d0258dd906c1a83cf0
    Image:         juicedata/juicefs-csi-driver:v0.20.0
    Image ID:      docker.io/juicedata/juicefs-csi-driver@sha256:43978fc60798a2bd6ae8e5ad340917267d91905f33ab4b0356918a7405b66af9
    Port:          9909/TCP
    Host Port:     0/TCP
    Args:
      --endpoint=$(CSI_ENDPOINT)
      --logtostderr
      --nodeid=$(NODE_NAME)
      --v=5
      --leader-election
    State:          Running
      Started:      Mon, 03 Jul 2023 04:26:01 +0300
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  512Mi
    Liveness:  http-get http://:healthz/healthz delay=10s timeout=3s period=10s #success=1 #failure=5
    Environment:
      CSI_ENDPOINT:             unix:///var/lib/csi/sockets/pluginproxy/csi.sock
      POD_NAME:                 juicefs-csi-controller-1 (v1:metadata.name)
      NODE_NAME:                 (v1:spec.nodeName)
      JUICEFS_MOUNT_NAMESPACE:  kube-system (v1:metadata.namespace)
      JUICEFS_MOUNT_PATH:       /var/lib/juicefs/volume
      JUICEFS_CONFIG_PATH:      /var/lib/juicefs/config
    Mounts:
      /jfs from jfs-dir (rw)
      /root/.juicefs from jfs-root-dir (rw)
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sbljd (ro)
  csi-provisioner:
    Container ID:  containerd://120135be7cf8554b0ea4f90e9a89939e58f44b951e505a660dee48148d59da95
    Image:         registry.k8s.io/sig-storage/csi-provisioner:v3.3.0
    Image ID:      registry.k8s.io/sig-storage/csi-provisioner@sha256:ee3b525d5b89db99da3b8eb521d9cd90cb6e9ef0fbb651e98bb37be78d36b5b8
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --timeout=60s
      --v=5
      --leader-election
    State:          Running
      Started:      Mon, 03 Jul 2023 04:26:01 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:  /var/lib/csi/sockets/pluginproxy/csi.sock
    Mounts:
      /var/lib/csi/sockets/pluginproxy/ from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sbljd (ro)
  liveness-probe:
    Container ID:  containerd://aa7900fcf3df1488934a2950e9418d875358201376f47d6c21c7d10e725ebaf1
    Image:         registry.k8s.io/sig-storage/livenessprobe:v2.10.0
    Image ID:      registry.k8s.io/sig-storage/livenessprobe@sha256:4dc0b87ccd69f9865b89234d8555d3a614ab0a16ed94a3016ffd27f8106132ce
    Port:          <none>
    Host Port:     <none>
    Args:
      --csi-address=$(ADDRESS)
      --health-port=$(HEALTH_PORT)
    State:          Running
      Started:      Mon, 03 Jul 2023 04:26:01 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      ADDRESS:      /csi/csi.sock
      HEALTH_PORT:  9909
    Mounts:
      /csi from socket-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sbljd (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  socket-dir:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  jfs-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/volume
    HostPathType:  DirectoryOrCreate
  jfs-root-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/juicefs/config
    HostPathType:  DirectoryOrCreate
  kube-api-access-sbljd:
    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:              <none>
Tolerations:                 CriticalAddonsOnly op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  56m   default-scheduler  Successfully assigned kube-system/juicefs-csi-controller-1 to <node>
  Normal  Pulled     56m   kubelet            Container image "juicedata/juicefs-csi-driver:v0.20.0" already present on machine
  Normal  Created    56m   kubelet            Created container juicefs-plugin
  Normal  Started    56m   kubelet            Started container juicefs-plugin
  Normal  Pulled     56m   kubelet            Container image "registry.k8s.io/sig-storage/csi-provisioner:v3.3.0" already present on machine
  Normal  Created    56m   kubelet            Created container csi-provisioner
  Normal  Started    56m   kubelet            Started container csi-provisioner
  Normal  Pulled     56m   kubelet            Container image "registry.k8s.io/sig-storage/livenessprobe:v2.10.0" already present on machine
  Normal  Created    56m   kubelet            Created container liveness-probe
  Normal  Started    56m   kubelet            Started container liveness-probe

Yes, posting in two parts, coz I did indeed hit GitHub comment character limit

@ky-bd
Would you mind to provide following information:

Managed or Self-managed cluster?
What is your kubernetes version?
Are you using K3s?
Are you using arm64, amd64 or mixed?
What is your CNI?
What CSI driver are you expirencing this issue with?
What is your node-driver-registrar version?

With this information I can compare our envs and try find common factor for the error.  Thanks in advance for your time.

Notes for people and myself while debugging.
I identified this issue on my end after cluster nodes experienced a K3S upgrade from v1.26.2 to a higher version. Nodes running the old versions do work still. To answer my own questions:

Self-Manager cluster on VMs
v1.26.6+k3s (lately upgraded from v1.26.2+k3s)
Yes
Mixed amd64/arm64
Flannel with VXLAN
juicefs
registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0

Just note here, I am also using Longhorn and it is working fine without this issue.

Try the newer version
I tried to upgrade juicedata/juicefs-csi-driver:v0.20.0 to version v0.20.1 in hopes "something" might fix.
Result: False
Debug networking
As ky-bd indicated in his response this might be something to do with the networking. Firstly I edited the DaemonSet on juicefs-csi-node. There on container juicefs-plugin I upped failureThreshold to 50000, so I can stay in the container for a bit longer without needing to reopen the console.
I checked to listen on the previously mentioned container with the following command and the result:

kubectl exec -n kube-system -ti juicefs-csi-node-5vgtk  -- bash -c 'ss -l'                                                                       03:30:13
Defaulted container "juicefs-plugin" out of: juicefs-plugin, node-driver-registrar, liveness-probe
Netid               State                Recv-Q               Send-Q                             Local Address:Port                                   Peer Address:Port
nl                  UNCONN               0                    0                                           rtnl:kernel                                             *
nl                  UNCONN               4352                 0                                        tcpdiag:ss/920                                             *
nl                  UNCONN               896                  0                                        tcpdiag:kernel                                             *
nl                  UNCONN               0                    0                                          audit:kernel                                             *
nl                  UNCONN               0                    0                                      fiblookup:kernel                                             *
nl                  UNCONN               0                    0                                            nft:kernel                                             *
nl                  UNCONN               0                    0                                         uevent:kernel                                             *
nl                  UNCONN               0                    0                                           genl:kernel                                             *
u_str               LISTEN               0                    4096                               /csi/csi.sock 56894765                                          * 0
tcp                 LISTEN               0                    4096                                   <IP_ADDRESS>:6060                                        <IP_ADDRESS>:*

This confirms there is a socket listening and as long the socket is accessible from other containers, there should not be any issues at all.
Next, I tried to exec on the node-driver-registrar container without success and the image has been built in a way to disallow executing commands inside the container. So, the next best thing was to investigate the docs of that container here.

Doing some investigation on the juicefs-driver container. I noticed the juicefs registration socket is missing.
root@juicefs-csi-node-x7v5x:/app# ls /var/lib/kubelet/plugins_registry/ -l
total 0
srwx------. 1 root root 0 Jul  3 00:28 csi.hetzner.cloud-reg.sock
srwx------. 1 root root 0 Jul  3 00:28 driver.longhorn.io-reg.sock
srwx------. 1 root root 0 Jul  3 00:28 secrets-store.csi.k8s.io-reg.sock
srwx------. 1 root root 0 Jul  3 00:28 smb.csi.k8s.io-reg.sock

I'll continue investigating this route and let you know as soon as possible. Currently, this seems chart related configuration issue.

Debugging
I continued debugging this issue by adding new container into the daemonset. Configuration for the additional pod is following:
        - name: debug
          image: alpine:latest
          command:
            - sleep
            - '999999'
          env:
            - name: ADDRESS
              value: /run/csi/csi.sock
            - name: HEALTH_PORT
              value: '9909'
          resources: {}
          volumeMounts:
            - name: plugin-dir
              mountPath: /run/csi
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: IfNotPresent

In this container, I was able to create "mock" of the liveness probe. You can create the mock and run it by doing the following steps:
apk add -q curl git make go bash ; \
git clone -b v2.10.0 --single-branch https://github.com/kubernetes-csi/livenessprobe.git ; \
cd livenessprobe ; \
make build

bin/livenessprobe  --csi-address=/csi/csi.sock --health-port=9909 -v 11

However, running the livenessprobe in the debug container had the same results (as expected) as the livenessprobe container itself.
Comparing to hetznercloud/csi-driver
In effort to understand how stuff works, I decided to go through another csi driver daemonset definition. I found that juicefs driver is using non-standard directories for the csi and registration sockets. Just to make sure this isn't configuration related problem in the chart I will be trying to "merge" juicefs and hetzner daemon set files. After I finished the merge, I got the following diff compared to the original daemonset file created by helm for the juicefs:
@@ -35,7 +35,7 @@
             type: Directory
         - name: plugin-dir
           hostPath:
-            path: /var/lib/kubelet/csi-plugins/csi.juicefs.com/
+            path: /var/lib/kubelet/plugins/csi.juicefs.com/
             type: DirectoryOrCreate
         - name: registration-dir
           hostPath:
@@ -68,7 +68,7 @@
               protocol: TCP
           env:
             - name: CSI_ENDPOINT
-              value: unix:/csi/csi.sock
+              value: unix:/csi/socket
             - name: NODE_NAME
               valueFrom:
                 fieldRef:
@@ -146,9 +146,9 @@
             - '--v=5'
           env:
             - name: ADDRESS
-              value: /csi/csi.sock
+              value: /csi/socket
             - name: DRIVER_REG_SOCK_PATH
-              value: /var/lib/kubelet/csi-plugins/csi.juicefs.com/csi.sock
+              value: /var/lib/kubelet/plugins/csi.juicefs.com/socket
           resources: {}
           volumeMounts:
             - name: plugin-dir
@@ -165,7 +165,7 @@
             - '--health-port=$(HEALTH_PORT)'
           env:
             - name: ADDRESS
-              value: /csi/csi.sock
+              value: /csi/socket
             - name: HEALTH_PORT
               value: '9909'
           resources: {}

After patching the daemonset with these changes I was able to get juicefs back into working condition.
Pod: juicefs-csi-node-xxxxx/juicefs-plugin
I0708 12:15:22.692763       7 main.go:94] Run CSI node
I0708 12:15:22.827505       7 node.go:131] Pod Reconciler Started
I0708 12:15:22.827683       7 driver.go:48] Driver: csi.juicefs.com version v0.19.0-24-gf93ad97 commit f93ad97aaa3484f5a493909d9f510de149021d81 date 2023-06-13T02:14:37Z
I0708 12:15:22.939014       7 driver.go:113] Listening for connection on address: &net.UnixAddr{Name:"/csi/socket", Net:"unix"}

Pod: juicefs-csi-node-xxxxx/node-driver-registrar
I0708 12:15:22.861509       1 main.go:167] Version: v2.8.0
I0708 12:15:22.863085       1 main.go:168] Running node-driver-registrar in mode=registration
I0708 12:15:22.864451       1 main.go:192] Attempting to open a gRPC connection with: "/csi/socket"
I0708 12:15:22.864704       1 connection.go:164] Connecting to unix:///csi/socket
I0708 12:15:23.868459       1 main.go:199] Calling CSI driver to discover driver name
I0708 12:15:23.868820       1 connection.go:193] GRPC call: /csi.v1.Identity/GetPluginInfo
I0708 12:15:23.868832       1 connection.go:194] GRPC request: {}
I0708 12:15:23.873550       1 connection.go:200] GRPC response: {"name":"csi.juicefs.com","vendor_version":"v0.19.0-24-gf93ad97"}
I0708 12:15:23.873711       1 connection.go:201] GRPC error: <nil>
I0708 12:15:23.873790       1 main.go:209] CSI driver name: "csi.juicefs.com"
I0708 12:15:23.873845       1 node_register.go:53] Starting Registration Server at: /registration/csi.juicefs.com-reg.sock
I0708 12:15:23.874828       1 node_register.go:62] Registration Server started at: /registration/csi.juicefs.com-reg.sock
I0708 12:15:23.875334       1 node_register.go:92] Skipping HTTP server because endpoint is set to: ""
I0708 12:15:23.992988       1 main.go:102] Received GetInfo call: &InfoRequest{}
I0708 12:15:24.000566       1 main.go:109] "Kubelet registration probe created" path="/var/lib/kubelet/plugins/csi.juicefs.com/registration"
I0708 12:15:24.157554       1 main.go:121] Received NotifyRegistrationStatus call: &RegistrationStatus{PluginRegistered:true,Error:,}

Pod: juicefs-csi-node-xxxxx/liveness-probe
I0708 12:15:23.052129       1 main.go:149] calling CSI driver to discover driver name
I0708 12:15:23.054315       1 main.go:155] CSI driver name: "csi.juicefs.com"
I0708 12:15:23.054742       1 main.go:183] ServeMux listening at "<IP_ADDRESS>:9909"

Whats next?
I will check if I can implement this patch in the Helm chart. No promises tough.

Hi @NikoGrano , thanks for your investigation.
I try to reproduce it and find something out here.

It recommends to use csi-plugins instead of plugins when k8s version is above v1.17, referring to https://github.com/kubernetes-csi/node-driver-registrar#usage . And csi.sock is the typical one.

I try to reproduce this issue with k3s. But it works well with /var/lib/kubelet/csi-plugins.

I find out how node-driver-registrar works:
a. It connects to csi plugin and call GetPluginInfo to get csi name and csi endpoint which provided by parameter kubelet-registration-path. refer to https://github.com/kubernetes-csi/node-driver-registrar/blob/master/cmd/csi-node-driver-registrar/main.go#L203
b. Then listen to reg socket and wait for kubelet calling. https://github.com/kubernetes-csi/node-driver-registrar/blob/master/cmd/csi-node-driver-registrar/node_register.go#L36
c. Kubelet connects to it and get csi endpoint by GetInfo. https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/pluginmanager/operationexecutor/operation_generator.go#L91
d. When kubelet get csi endpoint, kubelet will connect to csi plugin wherever endpoint be.


Make .reply() return None when reddit doesn’t return a comment object

Closes #1093.
@Watchful1 has uncovered a scenario where reddit doesn’t return a comment object after replying to a comment in a quarantined subreddit.
I propose that .reply() should return None in this case.
Please see the linked issue to view the full discussion and the other candidate solutions.

I’ve removed the messages test and used cassettes for the other two.
Although I don’t see how this is an improvement.

Thanks!

With the mocks module we can have the ability to control both the response and the expectation in one place. With Betamax we can only control the expectation and extra work needs to be done to control the response.

You are correct, though one still has to make a comment to update the mock to ensure the right output is produced and copied into the mock. That manual work is really what I'd like to avoid. The only people deleting cassettes to update them should be people familiar with how they work.
Overall I appreciate the discord and offering different ideas for how to do things. Mocking is fantastic and I absolutely prefer to use it when I know the API won't change, or will change but it extremely well documented. Unfortunately, Reddit isn't such an API. Furthermore, I think consistency in the test cases makes it easier to get up to speed with developing PRAW, and thus strongly encourage us to use betamax whenever possible.