PlaybloomSatisfyBundle::_form.html.twig

( ! ) Twig_Error_Loader: Unable to find template "PlaybloomSatisfyBundle::_form.html.twig" (looked into: /data/satis/satisfy/app/Resources/views, /data/satis/satisfy/vendor/symfony/twig-bridge/Resources/views/Form). in /data/satis/satisfy/vendor/twig/twig/lib/Twig/Loader/Filesystem.php on line 234

Hi @cuijianguo , thanks for reporting. Please post your installed packages from composer show.

The composer show has many packages, which one should be installed

Yes, that's right, many packages must present. Please paste here full list.

composer/ca-bundle                   1.1.3              Lets you find a path to the system CA bundle, and includes a fallback to the Mozilla CA bundle.
composer/composer                    1.7.3              Composer helps you declare, manage and install dependencies of PHP projects, ensuring you have the right stack everywhere.
composer/satis                       dev-master 3acf692 Simple Repository Generator
composer/semver                      1.4.2              Semver library that offers utilities, version constraint parsing and validation.
composer/spdx-licenses               1.5.0              SPDX licenses list and validation library.
composer/xdebug-handler              1.3.0              Restarts a process without xdebug.
doctrine/annotations                 v1.6.0             Docblock Annotations Parser
doctrine/instantiator                1.1.0              A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer                       v1.0.1             Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
friendsofphp/php-cs-fixer            v2.13.1            A tool to automatically fix PHP code style
incenteev/composer-parameter-handler v2.1.3             Composer script handling your ignored parameter file
jangregor/phpstan-prophecy           0.2.0              Provides a phpstan/phpstan extension for phpspec/prophecy
jean85/pretty-package-versions       1.2                A wrapper for ocramius/package-versions to get pretty versions strings
jms/metadata                         1.7.0              Class/method/property metadata management in PHP
jms/parser-lib                       1.0.0              A library for easily creating recursive-descent parsers.
jms/serializer                       1.13.0             Library for (de-)serializing data of any complexity; supports XML, JSON, and YAML.
jms/serializer-bundle                2.4.2              Allows you to easily serialize, and deserialize data of any complexity
justinrainbow/json-schema            5.2.7              A library to validate a json schema.
mikey179/vfsStream                   v1.6.5             Virtual file system to mock the real file system in unit tests.
myclabs/deep-copy                    1.8.1              Create deep copies (clones) of your objects
nette/bootstrap                      v2.4.6             🅱 Nette Bootstrap: the simple way to configure and bootstrap your Nette application.
nette/di                             v2.4.14            💎 Nette Dependency Injection Container: Flexible, compiled and full-featured DIC with perfectly usable autowiring and support for all new PH...
nette/finder                         v2.4.2             🔍 Nette Finder: find files and directories with an intuitive API.
nette/neon                           v2.4.3             🍸 Nette NEON: encodes and decodes NEON file format.
nette/php-generator                  v3.0.5             🐘 Nette PHP Generator: generates neat PHP code for you. Supports new PHP 7.2 features.
nette/robot-loader                   v3.1.0             🍀 Nette RobotLoader: high performance and comfortable autoloader that will search and autoload classes within your application.
nette/utils                          v2.5.3             🛠 Nette Utils: lightweight utilities for string & array manipulation, image handling, safe JSON encoding/decoding, validation, slug or stron...
nikic/php-parser                     v4.1.0             A PHP parser written in PHP
ninsuo/symfony-collection            2.1.30             A jQuery plugin that manages adding, deleting and moving elements from a Symfony collection
ocramius/package-versions            1.3.0              Composer plugin that provides efficient querying for installed package versions (no runtime IO)
paragonie/random_compat              v9.99.99           PHP 5.x polyfill for random_bytes() and random_int() from PHP 7
phar-io/manifest                     1.0.3              Component for reading phar.io manifest information from a PHP Archive (PHAR)
phar-io/version                      2.0.1              Library for handling version information and constraints
php-cs-fixer/diff                    v1.3.0             sebastian/diff v2 backport support for PHP5.6
phpcollection/phpcollection          0.5.0              General-Purpose Collection Library for PHP
phpdocumentor/reflection-common      1.0.1              Common reflection classes used by phpdocumentor to reflect the code structure
phpdocumentor/reflection-docblock    4.3.0              With this component, a library can provide support for annotations via DocBlocks or otherwise retrieve information that is embedded in a DocBlock.
phpdocumentor/type-resolver          0.4.0
phpoption/phpoption                  1.5.0              Option Type for PHP
phpspec/prophecy                     1.8.0              Highly opinionated mocking framework for PHP 5.3+
phpstan/phpdoc-parser                0.3                PHPDoc parser with support for nullable, intersection and generic types
phpstan/phpstan                      0.10.5             PHPStan - PHP Static Analysis Tool
phpstan/phpstan-phpunit              0.10               PHPUnit extensions and rules for PHPStan
phpstan/phpstan-symfony              0.10.2             Symfony Framework extensions and rules for PHPStan
phpunit/php-code-coverage            6.1.4              Library that provides collection, processing, and rendering functionality for PHP code coverage information.
phpunit/php-file-iterator            2.0.2              FilterIterator implementation that filters files based on a list of suffixes.
phpunit/php-text-template            1.2.1              Simple template engine.
phpunit/php-timer                    2.0.0              Utility class for timing
phpunit/php-token-stream             3.0.1              Wrapper around PHP's tokenizer extension.
phpunit/phpunit                      7.4.4              The PHP Unit Testing framework.
psr/cache                            1.0.1              Common interface for caching libraries
psr/container                        1.0.0              Common Container Interface (PHP FIG PSR-11)
psr/http-message                     1.0.1              Common interface for HTTP messages
psr/log                              1.0.2              Common interface for logging libraries
psr/simple-cache                     1.0.1              Common interfaces for simple caching
ramunasd/symfony-container-mocks     0.6                Provides extended Symfony dependency injection container enabling service mocking.
sebastian/code-unit-reverse-lookup   1.0.1              Looks up which function or method a line of code belongs to
sebastian/comparator                 3.0.2              Provides the functionality to compare PHP values for equality
sebastian/diff                       3.0.1              Diff implementation
sebastian/environment                3.1.0              Provides functionality to handle HHVM/PHP environments
sebastian/exporter                   3.1.0              Provides the functionality to export PHP variables for visualization
sebastian/global-state               2.0.0              Snapshotting of global state
sebastian/object-enumerator          3.0.3              Traverses array structures and object graphs to enumerate all referenced objects
sebastian/object-reflector           1.1.1              Allows reflection of object attributes, including inherited and non-public ones
sebastian/recursion-context          3.0.0              Provides functionality to recursively process PHP variables
sebastian/resource-operations        2.0.1              Provides a list of PHP built-in functions that operate on resources
sebastian/version                    2.0.1              Library that helps with managing the version number of Git-hosted PHP projects
seld/jsonlint                        1.7.1              JSON Linter
seld/phar-utils                      1.0.1              PHAR file format utilities, for when PHP phars you up
swop/github-webhook                  v2.0               Library which deals with incoming GitHub web hooks requests (signature validation & payload parsing)
symfony/asset                        v3.4.17            Symfony Asset Component
symfony/browser-kit                  v3.4.17            Symfony BrowserKit Component
symfony/cache                        v3.4.17            Symfony Cache component with PSR-6, PSR-16, and tags
symfony/class-loader                 v3.4.17            Symfony ClassLoader Component
symfony/config                       v3.4.17            Symfony Config Component
symfony/console                      v4.1.7             Symfony Console Component
symfony/debug                        v4.1.7             Symfony Debug Component
symfony/dependency-injection         v3.4.17            Symfony DependencyInjection Component
symfony/dom-crawler                  v3.4.17            Symfony DomCrawler Component
symfony/event-dispatcher             v3.4.17            Symfony EventDispatcher Component
symfony/filesystem                   v3.4.17            Symfony Filesystem Component
symfony/finder                       v4.1.7             Symfony Finder Component
symfony/form                         v3.4.17            Symfony Form Component
symfony/framework-bundle             v3.4.17            Symfony FrameworkBundle
symfony/http-foundation              v3.4.17            Symfony HttpFoundation Component
symfony/http-kernel                  v3.4.17            Symfony HttpKernel Component
symfony/inflector                    v3.4.17            Symfony Inflector Component
symfony/intl                         v3.4.17            A PHP replacement layer for the C intl extension that includes additional data from the ICU library.
symfony/lock                         v3.4.17            Symfony Lock Component
symfony/options-resolver             v3.4.17            Symfony OptionsResolver Component
symfony/polyfill-apcu                v1.9.0             Symfony polyfill backporting apcu_* functions to lower PHP versions
symfony/polyfill-ctype               v1.9.0             Symfony polyfill for ctype functions
symfony/polyfill-intl-icu            v1.9.0             Symfony polyfill for intl's ICU-related data and classes
symfony/polyfill-mbstring            v1.10.0            Symfony polyfill for the Mbstring extension
symfony/polyfill-php56               v1.9.0             Symfony polyfill backporting some PHP 5.6+ features to lower PHP versions
symfony/polyfill-php70               v1.9.0             Symfony polyfill backporting some PHP 7.0+ features to lower PHP versions
symfony/polyfill-php72               v1.9.0             Symfony polyfill backporting some PHP 7.2+ features to lower PHP versions
symfony/polyfill-util                v1.9.0             Symfony utilities for portability of PHP codes
symfony/process                      v3.4.17            Symfony Process Component
symfony/property-access              v3.4.17            Symfony PropertyAccess Component
symfony/psr-http-message-bridge      v1.1.0             PSR HTTP message bridge
symfony/routing                      v3.4.17            Symfony Routing Component
symfony/security                     v3.4.17            Symfony Security Component
symfony/security-bundle              v3.4.17            Symfony SecurityBundle
symfony/stopwatch                    v3.4.17            Symfony Stopwatch Component
symfony/templating                   v3.4.17            Symfony Templating Component
symfony/translation                  v3.4.17            Symfony Translation Component
symfony/twig-bridge                  v3.4.17            Symfony Twig Bridge
symfony/twig-bundle                  v3.4.17            Symfony TwigBundle
symfony/validator                    v3.4.17            Symfony Validator Component
symfony/yaml                         v3.4.17            Symfony Yaml Component
theseer/tokenizer                    1.1.0              A small library for converting tokenized PHP source code into XML and potentially other formats
twig/twig                            v2.5.0             Twig, the flexible, fast, and secure template language for PHP
webmozart/assert                     1.3.0              Assertions to validate method input/output with nice error messages.
zendframework/zend-diactoros         1.7.2              PSR HTTP Message implementations

Seem fine to me, a little bit outdated but ok.
Can You clear the cache and reproduce that issue?
If yse, then please post steps to reproduce.

cannot reproduce and no feedback in last 2 weeks


feat(ui): replace svg with user avatar , add avatar in the group cards & fix the stylings

Fixes #3622
Describe the changes you have made in this PR -

replace default svg with user profile image.
fix the overlapping of cards under 1200px
fix text overflow issue due to changing from svg to img
add name , email display on hover (necessary because text overflow hides full name and its quite annoying to open profile every time to see full name or email)
add image scaling on hover over image (only works on image not on default svg)

Screenshots of the changes (If any) -

replace default svg with user profile image.

fix the overlapping of cards under 1200px

before:

after:

add image scaling on hover over image (only works on image not on default svg)

Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

cc @VaibhavUpreti

Nicely done @Arnabdaz !!
Here are some ways that might help in improving the ux:

Converting images to hyper links that redirect to user profile

<%= link_to image_tag(member.user.profile_picture.url, alt: member.user.name, title: "#{member.user.name}\n#{member.user.email}"), user_path(member.user.id) %>

How about reducing the transform to scale(1) as it is causing overflow WDYT?, also how about making the avatars rounded?
square:

rounded:

Adding more height to group members card viewer list for ordinary 'group members' i.e not mentors

after:

@VaibhavUpreti can you check the changes ?

Great @Arnabdaz ! Just a quick fix, the SVG is not aligned with name and the pop up is not visible properly

Refer Code here
.
Could you fix these two and update the Screenshots on the first comment? This will be good to go then 👍 .

@VaibhavUpreti is it okay?


clojure support

amazing plugin! could you please add Clojure support back? how can I help, I can try to translate kotlin script to Clojure

Thank you! Sure, I look into it. I wonder if there is a reason you would LivePlugin instead of https://www.jetbrains.com/help/idea/ide-scripting-console.html which should already support Clojure?
In LivePlugin it should be just another implementation of PluginRunner and a bunch of actions (also a downloader for Clojure runtime jar). There is no Kotlin script really, just Kotlin.
Just for the record, these are the reasons I removed Clojure/Scala support:

it was an experiment at the time when Clojure/Scala were the coolest thing on the JVM
maintenance cost: I didn't really use Clojure in LivePlugin and wasn't sure if anyone else is using it
IDE or LivePlugin APIs were not designed for Clojure and having an idiomatic API for a specific language was one of the main ideas behind LivePlugin. It's easy to evaluate code on JVM in any JVM language but then it might be really painful to use IDE APIs written in Java/Kotlin (this is the main problem with IDE Scripting Console for me).
Kotlin is bundled with IntelliJ IDEs which are written Java/Kotlin so Kotlin seems like a better "default" language and I wanted LivePlugin to be a bit more focused

I couldn't get ide-scripting-console with Clojure working correctly, it seems like lack of document and is not actively maintained.

👍 Good to know so I don't make the same mistakes 😅


Updated to use react 0.14.0-beta3

It's a silly pull request, but for those of us on the cutting-edge. :-)

Thanks, @jwinn


[PTFE-215] 🐛 Workflow job error 500

Codecov Report

Merging #40 (0c962bb) into main (6f4b71e) will increase coverage by 0.63%.
The diff coverage is 96.87%.

:exclamation: Current head 0c962bb differs from pull request most recent head a525606. Consider uploading reports for the commit a525606 to get more accurate results

@@            Coverage Diff             @@
##             main      #40      +/-   ##
==========================================
+ Coverage   96.15%   96.79%   +0.63%
==========================================
  Files          10       14       +4
  Lines         442      499      +57
==========================================
+ Hits          425      483      +58
+ Misses         17       16       -1

Flag
Coverage Δ

api
96.69% <96.68%> (?)

unit
19.54% <38.70%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

gh_actions_exporter/metrics.py
89.56% <85.29%> (+1.23%)
:arrow_up:

gh_actions_exporter/main.py
96.07% <88.23%> (-1.49%)
:arrow_down:

tests/api/metrics/test_job.py
98.68% <98.68%> (ø)

gh_actions_exporter/Webhook.py
100.00% <100.00%> (ø)

gh_actions_exporter/config.py
97.22% <100.00%> (+0.44%)
:arrow_up:

gh_actions_exporter/cost.py
100.00% <100.00%> (ø)

tests/api/conftest.py
100.00% <100.00%> (ø)

tests/api/metrics/conftest.py
100.00% <100.00%> (ø)

tests/api/metrics/test_workflow.py
100.00% <100.00%> (ø)

tests/unit/conftest.py
100.00% <100.00%> (ø)

... and 1 more

Everything's good now!


Version information in Docker image is incorrect

Describe the bug
When running the docker image after v2.1.0, the version reported by locust is incorrrect
Expected behavior
From 2.1.0 image:
$ locust --version
locust 2.1.0

Actual behavior
$ locust --version
locust 0.1.dev1

Steps to reproduce
See above.
Expect it was introduced in #1847
Environment

OS: docker
Locust version: > 2.1.0 - including masterr
Locust command line that you ran: locust version

Thanks for reporting. It is fixed now (mainly in https://github.com/locustio/locust/commit/78efcf7748093f262901a176b9dc99682bf0084c), I just have to make a release...

Thanks for the quick action @cyberw
Just want to confirm that after pulling the newest docker image, this is now the response:
$ locust --version
locust 2.2.3.dev0

Not sure if that dev0 should be there :shrug:

Also, that's from the 2.2.2 docker image, not 2.2.3 (which doesnt exist, obviously)

Huh. That's weird. It shouldnt be there. I'll try again to fix it.

Should be fixed now!


Merged FesapiHdfProxy::createSubArrayNd() in FesapiHdfProxy::writeSubArrayNd()

Hi @philippeVerney!
Good Weekend! Since I have been working on very large data arrays, with size in GBs, I noticed that the algorithm is taking a lot of time writing these arrays. However, I found a better way to reduce time to write a subarray and improve performance of the overall algorithm. In the current implementation, FesapiHdfProxy::createSubArrayNd() is redundant, and if the array size is greater than the threshold, it recursively divides the array till the last ‘Nth’ dimension, which is not a good approach. In this case, sometimes the subarray becomes too small, hence exceeding the number of subarrays to be written against a single large data array. To resolve this issue, I have merged its code in FesapiHdfProxy::writeSubArrayNd(), so that it will no longer divide till the last dimension in case the subarray size already becomes less than the threshold value in the middle of the process. This approach has reduced the number of subarrays by 50%.
Also, I have changed FesapiHdfProxy::maxArraySize_ from 400000 to 12000000. It can still be increased/adjusted according to the MaxWebSocketMessagePayloadSize. I haven’t found the right way yet. 😊
Regards,
Hussain

Thanks a lot Hussain for this improvement!
FYI, deciding the correct size of the array is indeed a challenge because it requires you to understand how AVRO format its arrays which is not straightforward.
Some hints could be found here : https://github.com/F2I-Consulting/fetpapi/blob/4c5ec7df514a67ffd5d222b57c4778b6fffe79e5/src/etp/fesapi/FesapiHdfProxy.h#L597

You're welcome. Thanks for the suggestion. Seems like a very useful hint. 👍


[Question] About the parameter of writeToFile method and readFile method

Hello,
My team is working on enhancing the functionalities of SW360 (https://github.com/eclipse/sw360) - a software component catalog application. We plan to replace the old library used in SW360 with this library. But we are facing some problems so I come here to see if I can get some help.
We are using writeToFile method (https://github.com/spdx/Spdx-Java-Library/blob/master/src/main/java/org/spdx/library/Read.java#L124) and readFile method (https://github.com/spdx/Spdx-Java-Library/blob/master/src/main/java/org/spdx/library/Write.java#L97) to implement the Import/Export functions of SW360. However, these methods need one parameter modelStore, but as we understand, this interface was not implemented yet.
Ref: https://github.com/spdx/Spdx-Java-Library/blob/42fcd5bc77ee49afc1bfb2de992679162bbcb3cd/src/main/java/org/spdx/storage/ISerializableModelStore.java#L31
Could you tell me if our understanding is correct or not?
Another question is, we found this message in the README.md:
The default storage interface is an in-memory Map which should be sufficient for light weight usage of the library.
Does it mean we cannot use this library to read or write the large size file?
Thank you in advance!

@shi9qiu I'm quite happy to help support the use of this library in SW360.

However, these methods need one parameter modelStore, but as we understand, this interface was not implemented yet.

There are 3 implementations of this interface, but they are in different Github repos - you can add them as dependencies to  your project.  The 3 implementations represent 3 different serialization formats for SPDX:

SPDX Jackson Store supports JSON, YAML and XML formats
SPDX RDF Store supports various RDF format (e.g. RDF/XML)
SPDX tag/value Store

Does it mean we cannot use this library to read or write the large size file?

I've actually used this store for some very large files without issue - it does store everything in memory, however, so I'm sure there will be a limit.  I have a prototype RDF graph database implementation for very large RDF graphs.  I've thought about writing an SQL based store, but haven't found the need yet.

@shi9qiu If you would like an example using this library with the above mentioned store, check out the SPDX Converter utility

Thank you so much for your speedy reply! We will try it.

Hello, @goneall
I used this function createSpdxDocument() for make SpdxDocument object from RDF file input, but it is seem not work with large file. In library Spdx-Java-Library has same function can work with large file?

And a sample RDF large file https://github.com/eclipse/sw360/files/5984378/SPDX2_linux-4.18.tar.xz_1535128294-spdx.rdf.zip

I re-checked the library spdx-tools with function Verify and it used same function createSpdxDocument for making SpdxDocument.
I tested with RDF large file https://github.com/eclipse/sw360/files/5984378/SPDX2_linux-4.18.tar.xz_1535128294-spdx.rdf.zip (~80MB) and it can work fine.
namnp@namnp:~/tools$ java -jar target/spdx-tools-2.2.6-SNAPSHOT-jar-with-dependencies.jar Verify SPDX2_linux-4.18.tar.xz_1535128294-spdx.rdf/SPDX2_linux-4.18.tar.xz_1535128294-spdx.rdf
--------Start verify: [SPDX2_linux-4.18.tar.xz_1535128294-spdx.rdf/SPDX2_linux-4.18.tar.xz_1535128294-spdx.rdf]
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. Set system property 'log4j2.debug' to show Log4j2 internal initialization logging.
15:55:40.523 [main] ERROR org.spdx.rdfparser.license.ListedLicenses - I/O error opening Json TOC URL, using local TOC file
spdx.org
spdx.org
spdx.org
...
--------getSpecVersion: SPDX-2.1
--------getSpecName:   /srv/fossology/repository/report
This SPDX Document is valid.

So, I will re-check when using function with SW360.

@nam-np Were you able to re-check with SW360?  I'm working on a minor release for this library and would like to work in fixes for this if needed.

@goneall @nam-np
SW360 community tried new library,
We got error again.
https://github.com/eclipse/sw360/issues/1171#issuecomment-990610778
https://github.com/eclipse/sw360/issues/1171#issuecomment-990612685
But we found some root problem.
https://github.com/eclipse/sw360/issues/1171#issuecomment-990614065

@KoukiHama Thanks for the update - I left a comment in the SW360 issue.
Let me know if you'd like any help migrating from the old SPDX tools library to this one (I've done it a few times).
Since the issue is an incompatibility between the old library and this library, I'm going to close out this issue since I can't think of any way to resolve it without re-introducing a security vulnerability.  If you disagree or know of a way to resolve it with a change to this issue, please add a comment.


Freezing during inference

@Leengit we have a large project (~5000 HS studies) and the inference hangs frequently without displaying an error message. Sometimes this happens in < 1 hour and so we are getting through this ~50-100 jobs at a time by restarting the docker. These is no error message. It is definitely happening during the inference step e.g. 15/Unknown - 123s 7s/step. I have verified that this happens with with Jupyter and command-line scripts, with single and multi-gpu, and with small and large batch sizes. None of these parameters seem to have an effect on the frequency.

Can I get access to your failing example?  If that's not feasible, what do you recommend for constructing my own?  I can make 100 copies of an image and try to read them all in using histomics_stream; what parameters (e.g., tile size) would be appropriate?  Can you provide me a model that, even if it isn't the one you are using, should stress the system sufficiently to show the problem?

Hi Lee - I see this on all datasets I use. They don't necessarily have to be large, even tiny biopsies can provoke the problem.
Sending details on an example by email.


Two places defining the StatusResponse enums

I've found that there are two places where StatusResponse(CommandStatus) enums are stored as shown in the screenshot below. One in constant.py, the other in enums.py. I believe this should only be in constant.py, but in some place the ones in enums.py are used. Shall we refactor a bit?

CommandStatus suppose to stay only under the constant.py because it has no relation with the payload of the command, it's used only in the BXMP header which is not exposed to the user. For the refactoring we can improve the exceptions which will match it's cmd_statuses


Possible bug

For determining if a KFS account. A PPM can pass this, but we shouldn't be using PPM accounts.
https://github.com/ucdavis/Sloth/blob/master/Sloth.Core/Services/AccountValidationService.cs#L63
3 dashes
KL0733ATC1-TASK01-ADNO001-501090

Add check to ensure there is one character before the first dash IF the length != 7


cleaner not mounting the dind socket properly and won't start

Bug description
Image cleaner won't start with when using dind because it's unable to mount /var/run/docker.sock
The dind socket is located here:
https://github.com/jupyterhub/binderhub/blob/4b41dc23312b9b1f8ea5cd1434403752632c9644/helm-chart/binderhub/templates/dind/daemonset.yaml#L43
The image cleaner doesn't properly use the hostSocketDir and blindly mounts /var/run/docker.sock  for both dind as well as host docker.
https://github.com/jupyterhub/binderhub/blob/4b41dc23312b9b1f8ea5cd1434403752632c9644/helm-chart/binderhub/templates/image-cleaner.yaml#L44
Expected behaviour
image cleaner should start
Actual behaviour
image cleaner doesn't start
How to reproduce

Go to '...'
Click on '....'
Scroll down to '....'
See error

Your personal set up

If you are using DIND there should be two image cleaners. One for the host's dockerd and one for the DIND dockerd. The source of the mount is defined towards the bottom of templates/image-cleaner.yaml.


修复文档对异步请求的错误示例

文档中new了tokenFly而使用的却是newFly

Codecov Report

Merging #257 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #257   +/-   ##
=======================================
  Coverage   86.10%   86.10%
=======================================
  Files           1        1
  Lines         259      259
=======================================
  Hits          223      223
  Misses         36       36

Continue to review full report at Codecov.

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


op-node stop live sync for no reason

The node has never had problems since the chain was created and has always been in sync, but at the moment it cannot stay live and I am experiencing these problems
Release: v0.6.1 with .env.mainnet default settings
t=2024-01-07T01:20:13+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm8YjBeyU8WFDoX3nzAF9X6FyPsBpLcaBedXk77RPWj6sR num=8,899,887 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:13+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmLzJPWfRooigpG3sV4hJz2JreQkTRgBdr1o3f4XwC1BvA num=8,899,884 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:13+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAky2Uw31EXaQj1Ywhtrn1sZLXLEKEMJt1jFn3PEaaJeTGn num=8,899,882 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:14+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmJjBvxrpbQYgdqQBkNUEKJphppSbFu2ThLLomkzUgUppf num=8,899,881 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:14+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkySVQ7WD1f5Tqp1CYEAPZmGUQFWd947pr55tnFh5EJs9X num=8,899,880 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:14+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm3qwgs4Bvfx1GJ5qnY4LjPbYCc394kvdjpxuJBsP3SQnW num=8,899,879 err="failed to decode response: scope too small to decode execution payload: 0"
t=2024-01-07T01:20:14+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmTxXYA9xMqMdnzBCQEVG3EZwz5G2SbPZNjDHBFkaNSpma num=8,899,878 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:14+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkzQGSZcAgPxtNk3z9nN1s39mz8nwjEGjkEghJ625aFBCd num=8,899,876 err="peer failed to serve request with code 3"
t=2024-01-07T01:20:15+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmB62TGHsQTdLPAmvJ2WuSRkoqmTynqeMTfgABfq1iuNU6 num=8,899,875 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:15+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmJHU7J2oUxLZFZJKEnUPTWDJAqzzGRNajJkrm9agyiwiR num=8,899,872 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:15+0000 lvl=info msg="Received signed execution payload from p2p" id=0x1c3f5ac5459f70b22cc06811998a20110226c0263e58b3134d9905bdd219eeaf:8900534 peer=16Uiu2HAmTxXYA9xMqMdnzBCQEVG3EZwz5G2SbPZNjDHBFkaNSpma
t=2024-01-07T01:20:15+0000 lvl=info msg="Optimistically queueing unsafe L2 execution payload" id=0x1c3f5ac5459f70b22cc06811998a20110226c0263e58b3134d9905bdd219eeaf:8900534
t=2024-01-07T01:20:15+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmKt9zvrbzAmrH3jrtFdCm6h52J2Ue2rPQYEqKZFmWejC6 num=8,899,869 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:15+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkvLBTPqfA9HHXgnLUQiEJg7EKPb7gu7qMXfJFS79Goy3b num=8,899,867 err="failed to decode response: scope too small to decode execution payload: 0"
t=2024-01-07T01:20:16+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm5BQWJTL51WQUXqLwgu8RGaH9gEPYJtsXBioTb3QF6C8C num=8,900,004 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:16+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm5MCSsxM7fh2ZdHzJbP9h4yNRLSuxQhHxrGLRNqs8ddhN num=8,900,001 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:16+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmQDeaNDF7XWBodMpA8ZWK8FnbhebgbzDZHYsS9pBzgfxx num=8,900,000 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:16+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmMViHjEcMkMK8m1wyeXaEaqhUz7A3aJsDbDDq8oGKMgsT num=8,899,998 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:16+0000 lvl=info msg="no peers ready to handle block requests for more P2P requests for L2 block history" target=8,894,163 end=0xa5df59700edc2dc7eec72ce544ffc7157dc59b1ca915ebda5fc6425b8d385888:8900007 current=8,899,778
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmU8rjepzYJ1xxzf3PT4viFcr3D2rhShnVjSsDKpNChrzp num=8,899,967 err="peer failed to serve request with code 3"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm1NTD3neoW6A96Y92Np6zRQ82FtPqPboBRGwtXpUqjvS5 num=8,899,965 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm7NaqJbRfSmimaS9WAc9F8AJLGvyn9PtK24hhPUgMTQ6p num=8,899,963 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmGk7jGdUk5GG3XUpMdS619Wj2a5YVcXXqzsU1cGJbernG num=8,899,962 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkvCcL5sof9EN3twfv8Ewba8TgRtWibPacUJYdp6SMeYmM num=8,899,961 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmTeJNYGyKb6HLAAm3TU1X4EGzXCueo88rTS1TdHozkmaE num=8,899,956 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm8YjBeyU8WFDoX3nzAF9X6FyPsBpLcaBedXk77RPWj6sR num=8,899,958 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmLzJPWfRooigpG3sV4hJz2JreQkTRgBdr1o3f4XwC1BvA num=8,899,953 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:17+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAky2Uw31EXaQj1Ywhtrn1sZLXLEKEMJt1jFn3PEaaJeTGn num=8,899,951 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:17+0000 lvl=info msg="Received signed execution payload from p2p" id=0xb3a5c7f403a829b0b355c1c26d74e0c17003f5eb75de2ee190b9799b9a0b4920:8900535 peer=16Uiu2HAm7NaqJbRfSmimaS9WAc9F8AJLGvyn9PtK24hhPUgMTQ6p
t=2024-01-07T01:20:17+0000 lvl=info msg="Optimistically queueing unsafe L2 execution payload" id=0xb3a5c7f403a829b0b355c1c26d74e0c17003f5eb75de2ee190b9799b9a0b4920:8900535
t=2024-01-07T01:20:18+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmJjBvxrpbQYgdqQBkNUEKJphppSbFu2ThLLomkzUgUppf num=8,899,863 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:18+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkySVQ7WD1f5Tqp1CYEAPZmGUQFWd947pr55tnFh5EJs9X num=8,899,861 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:18+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm3qwgs4Bvfx1GJ5qnY4LjPbYCc394kvdjpxuJBsP3SQnW num=8,899,859 err="failed to decode response: scope too small to decode execution payload: 0"
t=2024-01-07T01:20:18+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmTxXYA9xMqMdnzBCQEVG3EZwz5G2SbPZNjDHBFkaNSpma num=8,899,837 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:18+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkzQGSZcAgPxtNk3z9nN1s39mz8nwjEGjkEghJ625aFBCd num=8,899,834 err="peer failed to serve request with code 3"
t=2024-01-07T01:20:19+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmB62TGHsQTdLPAmvJ2WuSRkoqmTynqeMTfgABfq1iuNU6 num=8,899,826 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:19+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmJHU7J2oUxLZFZJKEnUPTWDJAqzzGRNajJkrm9agyiwiR num=8,899,823 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:19+0000 lvl=info msg="Received signed execution payload from p2p" id=0x7af4ec6c49997a67fd89660007c04283ccfce01097e96bb5512865ae5e5f2449:8900536 peer=16Uiu2HAmTeJNYGyKb6HLAAm3TU1X4EGzXCueo88rTS1TdHozkmaE
t=2024-01-07T01:20:19+0000 lvl=info msg="Optimistically queueing unsafe L2 execution payload" id=0x7af4ec6c49997a67fd89660007c04283ccfce01097e96bb5512865ae5e5f2449:8900536
t=2024-01-07T01:20:19+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmKt9zvrbzAmrH3jrtFdCm6h52J2Ue2rPQYEqKZFmWejC6 num=8,899,819 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:19+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkvLBTPqfA9HHXgnLUQiEJg7EKPb7gu7qMXfJFS79Goy3b num=8,899,814 err="failed to decode response: scope too small to decode execution payload: 0"
t=2024-01-07T01:20:20+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm5BQWJTL51WQUXqLwgu8RGaH9gEPYJtsXBioTb3QF6C8C num=8,900,003 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:20+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm5MCSsxM7fh2ZdHzJbP9h4yNRLSuxQhHxrGLRNqs8ddhN num=8,899,997 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:20+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmQDeaNDF7XWBodMpA8ZWK8FnbhebgbzDZHYsS9pBzgfxx num=8,899,996 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:20+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmMViHjEcMkMK8m1wyeXaEaqhUz7A3aJsDbDDq8oGKMgsT num=8,899,995 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:20+0000 lvl=warn msg="L1 head signal indicates a possible L1 re-org" old_l1_head=0x21a5df8fe351240d01e7b379af6a50bc878aff90dba9af317005a49403eba84d:18951924 new_l1_head_parent=0x4116d0e7dee18c63b747ed52c2b0c0342ed9f3154bc44a886ab8df893eefdeaa new_l1_head=0x0522c5faf04d79ae016d8e7f4332bf5669bd9584f7ac4bd0597517d133044570:18951928
t=2024-01-07T01:20:20+0000 lvl=info msg="Advancing bq origin"                    origin=0x31d2a1524679d4f1b3431ac113bc9dafe4f23a912a66843b01caace471483188:18951923 originBehind=false
t=2024-01-07T01:20:20+0000 lvl=info msg="no peers ready to handle block requests for more P2P requests for L2 block history" target=8,894,163 end=0xa5df59700edc2dc7eec72ce544ffc7157dc59b1ca915ebda5fc6425b8d385888:8900007 current=8,899,778
t=2024-01-07T01:20:20+0000 lvl=info msg="Advancing bq origin"                    origin=0x21a5df8fe351240d01e7b379af6a50bc878aff90dba9af317005a49403eba84d:18951924 originBehind=false
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmU8rjepzYJ1xxzf3PT4viFcr3D2rhShnVjSsDKpNChrzp num=8,899,955 err="peer failed to serve request with code 3"
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm1NTD3neoW6A96Y92Np6zRQ82FtPqPboBRGwtXpUqjvS5 num=8,899,948 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm7NaqJbRfSmimaS9WAc9F8AJLGvyn9PtK24hhPUgMTQ6p num=8,899,946 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmGk7jGdUk5GG3XUpMdS619Wj2a5YVcXXqzsU1cGJbernG num=8,899,942 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAkvCcL5sof9EN3twfv8Ewba8TgRtWibPacUJYdp6SMeYmM num=8,899,941 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmTeJNYGyKb6HLAAm3TU1X4EGzXCueo88rTS1TdHozkmaE num=8,899,935 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAm8YjBeyU8WFDoX3nzAF9X6FyPsBpLcaBedXk77RPWj6sR num=8,899,939 err="peer failed to serve request with code 1"
t=2024-01-07T01:20:21+0000 lvl=info msg="Received signed execution payload from p2p" id=0x0b584e39a07c87649037299953d0d467e4d364fc5bee20b311fc7d1d6e387d61:8900537 peer=16Uiu2HAkzQGSZcAgPxtNk3z9nN1s39mz8nwjEGjkEghJ625aFBCd
t=2024-01-07T01:20:21+0000 lvl=info msg="Optimistically queueing unsafe L2 execution payload" id=0x0b584e39a07c87649037299953d0d467e4d364fc5bee20b311fc7d1d6e387d61:8900537
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAmLzJPWfRooigpG3sV4hJz2JreQkTRgBdr1o3f4XwC1BvA num=8,899,930 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"
t=2024-01-07T01:20:21+0000 lvl=warn msg="failed p2p sync request"                peer=16Uiu2HAky2Uw31EXaQj1Ywhtrn1sZLXLEKEMJt1jFn3PEaaJeTGn num=8,899,924 err="failed to open stream: failed to negotiate protocol: protocols not supported: [/opstack/req/payload_by_number/8453/0]"

do you know what causes this problem?
In the meantime I'm trying to restore it from a backup dated a week ago

do you have --l1.trustrpc or OP_NODE_L1_TRUST_RPC=true enabled? We found some issues with ethereum-optimism/optimism#8130 possibly disabling receipt validation that should be fixed in the next release (see ethereum-optimism/optimism#8861), so would recommend disabling this for now if enabled

yes is both enabled

The node restored with old backup, restarted without errorrs with the same old settings. Now I will temporarily disable l1-trustrpc until there is a fix, thanks for the support


Feature: new monitor type: MicroProfile Health Check

⚠⚠⚠ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:

[x] I have read and understand the pull request rules.

Description
Fixes #2501 - new monitor type: MicroProfile Health Check
Type of change
Please delete any options that are not relevant.

New feature (non-breaking change which adds functionality)
This change requires a documentation update

Checklist

[x] My code follows the style guidelines of this project
[x] I ran ESLint and other linters for modified files
[x] I have performed a self-review of my own code and tested it
[x] I have commented my code, particularly in hard-to-understand areas
(including JSDoc for methods)
[x] My changes generate no new warnings

Screenshots (if any)

MicroProfile is new to me, I would like to know are there any MicroProfile docker image that could be used to test this pr?

Hey @louislam , not sure how such a test setup should look like, have no experience in that topic.
What I can tell you: in the UP situation the target system will respond with an HTTP 200 and wil provide a JSON like this one (I added also the headers):
`*   Trying <IP_ADDRESS>:9990...

Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 9990 (#0)

GET /health HTTP/1.1
Host: <IP_ADDRESS>:9990
User-Agent: curl/7.86.0
Accept: /

Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 313
< Date: Thu, 23 Feb 2023 21:50:55 GMT
<
Connection #0 to host <IP_ADDRESS> left intact
{"status":"UP","checks":[{"name":"server-state","status":"UP","data":{"value":"running"}},{"name":"empty-readiness-checks","status":"UP"},{"name":"empty-liveness-checks","status":"UP"},{"name":"deployments-status","status":"UP"},{"name":"empty-startup-checks","status":"UP"},{"name":"boot-errors","status":"UP"}]}`

In case of a Problem the remote system will respond with a HTTP status Code 503 and with a JSON like this one, detailing which component(s) caused the problem(s):
`*   Trying <IP_ADDRESS>:9990...

Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 9990 (#0)

GET /health HTTP/1.1
Host: <IP_ADDRESS>:9990
User-Agent: curl/7.86.0
Accept: /

Mark bundle as not supporting multiuse
< HTTP/1.1 503 Service Unavailable
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 397
< Date: Thu, 23 Feb 2023 21:56:39 GMT
<
Connection #0 to host <IP_ADDRESS> left intact
{"status":"DOWN","checks":[{"name":"server-state","status":"UP","data":{"value":"running"}},{"name":"deployments-status","status":"UP","data":{"department-service.war":"OK"}},{"name":"boot-errors","status":"UP"},{"name":"started-deployment.department-service.war","status":"UP"},{"name":"pl.piomin.services.department.health.ReadinessEndpoint","status":"DOWN"},{"name":"Server up","status":"UP"}]}`

maybe for the test case it might be sufficient to provide these two JSON together with their corresponding HTTP Status Code and the Content-Type header.

I meant I want to do a test manually, but I don't know how to get it working.
What I had tried to do:

Download a demo project from: https://start.microprofile.io/index.xhtml
Run ./gradlew libertyDev

I placed the endpoint url into Uptime Kuma, but it didn't work.


More than one "purpose" in an authorization request.

Problem description
The OIDC profile PR adds purpose as a transaction specific request parameter, as specified in openid-connect-4-identity-assurance-1_0-13.
This changes the way how purpose was handled in ICM release-0.1.0 where it was declared within the requested scope.
Some colleagues from ICM WG have reservations about this change as they had been presented with a requirement from Open Gateway product team in the past which said that Applications must be able to request access to multiple APIs in the same authorization request. Each API might be consumed with a different purpose. This means that an application could need to declare more than one dpv_value (purpose) in the authorization request.
A single request parameter to specify purpose (as suggested in the PR) would not be able to fulfil this requirement.
Currently, there is no good solution available at hand to fulfil this requirement.
It was agreed in the working group that we will ask for feedback if this requirement is still valid/relevant.
It would be helpful to get feedback from all organizations active in ICM/Camara, and also colleagues from OGW/GSMA if this requirement is still valid/relevant.
Expected action
Request members to actively provide feedback in the form of comments under this issue if the above said requirement exists within your respective organizations.
Additional context

Yes, this requirement exists for aggregator usecases. Client App can request multiple APIs and we don't expect to initiate users to initiate multiple authorization call if they have already authorized once.

Yes, this requirement exists for aggregator usecases. Client App may request multiple APIs and we don't expect to initiate users to initiate multiple authorization call if they have already authorized once and token is not expired.

Is it discussed or documented somewhere that this "mother-of-all-access-token" is quite dangerous and sending it to all resource servers enhances the chance for it to be leaked?
Is this already implemented in some markets?
Are implementers downgrading the access tokens to less all-empowering scopes using refresh-tokens?
https://www.rfc-editor.org/rfc/rfc6749.html#page-47
The steps could be:

request a code for "openid dpv:LegitimateInterest:simswap number-verification:verify"
request a token and refreshtoken for that code (and all scopes mentioned above)
use the refreshtoken to get an accesstoken for a subset of scopes e.g. "number-verification:verify"
use the new accesstoken at the numberverification:verify resource server (and never at the simswap resource server.

That way usage of access tokens at RS endpoints that do not need them is eliminated.

During the TSC meeting we ask for more feedback on this use case. Please add your feedback here.

No, it is not implemented use case yet. It is more like feedback from user's usability perspective.
If user has provided consent once and token is not expired, why they will need to provide authorization if they need to use two API endpoints.
Original request from Shilpa in this issue was "Applications must be able to request access to multiple APIs in the same authorization request. Each API might be consumed with a different purpose. This means that an application could need to declare more than one dpv_value (purpose) in the authorization request"
I agree to steps given below:

request a code for "openid dpv:LegitimateInterest:simswap number-verification:verify"
request a token and refreshtoken for that code (and all scopes mentioned above)
use the refreshtoken to get an accesstoken for a subset of scopes e.g. "number-verification:verify"
use the new accesstoken at the numberverification:verify resource server (and never at the simswap resource server.

However, Shilpa mentioned that it is not possible to send two dpv values in one request - "openid dpv:LegitimateInterest:simswap number-verification:verify". If this is possible then it is sufficient.

We are running in circles regarding the various purpose proposals.
I think that restriction of "not possible to send two or more dpv values" in one request comes from some existing implementations. And I guess that if one purpose/dlv leads to a no-user-consent necessary situation and simultaneously user consent is required for a different scope then the consent page gets confusing for the user.

Hi all,
the current limit of asking for only one purpose in an authorization request is due to the fact that the consent is given on the pair of <purpose, data scope>.  When asking for multiple purposes for the same data scope, it might happen that for purpose1, consent is available but not for purpose2.  How should the answer look like ?
Solution analysis:

only allow allow one purpose in request, but list of scopes: straight forward, use access token on API call for the purpose in question
allow multiple purpose in request: use opaque access tokens and structures in auth server which manage  the pairs of purpose and scope and relate them to consent, send on API call the purpose in question to allow allow picking
allow multiple purpose in request: only grant access token with all combinations of purpose and data scope have consent

Example: Take the example of two purposes (service provisioning and advertising) and two data scopes (data-read, data-write). Then assume that consent is given for both purposes and data-read, but data-write is only given for provisioning.
So when calling the API for the write operation, how do I know whether it is permitted or not if I do not know the actual purpose ?
Summary:
Solution 2 is for sure possible to solve, but complex and not in line with current standards.
If multiple purposes shall be allowed I only see option 3 possible.

My initial understanding when I joined ICM was that we have purpose encoded in the scope parameter, but somebody said this is not possible or currently not implemented or agreed upon or there are some more requirements.
To write that down again, what I thought was the camara "solution":

an API WG defines some technical scopes (t1, t2, t3, ...) for their API api1
another API WG defines some technical scopes (T1, T2, T3, ...) for their API api2
at onboarding time of the client/application there are some purposes added (p1, p2, p3, ...)
pX defined by W3C example p1 = dpv:FraudPreventionAndDetection
The client onboards for product X at the AZ. Product X defines a list of purposes and technical scopes.
So, the AZ has list of allowed scope parameters (p1#t1 p2#t1 p1#t3 p1#T1 p2#T2) for that client/application.
no API-name as a wildcard for t1, t2, t3, ... T1, T2, T3

Then the AZ can create access tokens for this list of allowed scope parameters.
A simple approach for asking for consent could be: There is a text for each scope that is shown the user and they have to agree to all of them.
By clicking "OK" you agree to:
some text regarding p1#t1
some other text regarding p2#T2
...

Deny OK

The RS can validate the access token - does not matter whether the access token is self-contained or not.
if (valid(accessToken, RS_path) then
   do RS_path-specific-stuff
endif

(For billing purposes the RS can log the scope parameters, if there is a way to introspect the access token. The telco implementing the API can log the scope parameters - implicitly logging the purpose)
The above is compliant with OIDC as far as access token issuance at the AZ and usage at the RS is concerned.
The onboarding-of-the-client part is not defined in OIDC.
I see some danger that we end up with a very proprietary AZ and RS implementation if scope parameters are parsed to split purpose and technical scope.
But the issuing and usage of the access token can be done with an off-the-shelf AZ and RS without parsing, I think.
Parsing out the purposes from the scope parameters is not needed.
Having said the above, I am not sure what part of the above is part of ICM. The onboarding part is not OIDC.
If the above is not specified in ICM, then where is it specified?

Hi @Elisabeth-Ericsson , yes, that is the history and current proposal.
After the proposal to have purpose as split-out, there were concerns that this way we have only one purpose and that there is a requirement that Camara use-cases need more then one. Basically rejecting the current proposal.
I proposed in the meeting (sorry, minutes to be written still) that we use this issue to describe where we are regarding purpose&scopes.
The proposal to have purpose as a separate parameter found no big support. Because of the use case that "needs" multiple purposes which leads to terrible UX.
So, most probably the proposal is not going to stay in the profile.
So, today I wrote down what initially understood and which I think "technically" works - OIDC-wise.
In one sentence: Access token issuance and usage is OIDC compliant with purpose and scope combined in scope parameter while onboarding is not necessarily an ICM matter.
Let's run through the circle one more time, look what we can agree on.

Hi, that's also our understanding on Orange side.
The scope’s parameter needs to contain the couple purpose-scope, and each purpose-scope the user hasn't accepted or revoked must be asked when consents are asked to the End-User (after authentication).
Then the token generated will embed the purpose-scope in the scope’s parameter that has been accepted by the End-User.
End-User can for example accept dpv:FraudPreventionAndDetection#number-verification:verify but deny dpv:FraudPreventionAndDetection#number-verification:device-phone-number:read. Same purpose, different scope, and the RS will know during the introspection that Client only have access to check the MSISDN.

@sebdewet: From your description I understand that your proposal is to allow a list of pairs /#/.
There are examples where this approach will lead to unclear situations on API invocation, unless the current "purpose" is conveyed on the API invocation in addition.
Example: KYC API exposes two data scopes:

customer-identifiers:read,  -exposing MSISDN, personal identification number, tax id, etc)
customer-address:read  - exposing address data
An end user would accept both data scopes for the reason of dpv:EnforceSecurity, but for dpv:CustomerManagement only customer-identifiers;read data scope is permitted.
The access token would then contain the permitted scopes dpv:EnforceSecurity#customer-dentifiers:read dpv:EnforceSecurity#customer-address:read dpv:CustomerManagement#customer-dentifiers:read.

When calling the read operation of the API, how should the logic in the API determine, which data scope to expose ?
So either we must prevent/forbid having two different data scopes for the same operation on an API or we need to find a way to  send the current purpose in question when calling the API (which is not in line with the standard).

Maybe the problems we are facing stem from the fact that there is some disconnect between the API specification in an API working group and onboarding time addition of purposes.
In OpenApi each path can have a security requirement object.
Picking up @Elisabeth-Ericsson 's example (as I interpret it):
...
paths:
  /read:
    get:
      security:
        - openId:
          - customer-identifiers:read
          - customer-address:read

...

OpenAPI says: If the security scheme is of type "oauth2" or "openIdConnect", then the value is a list of scope names required for the execution
So, the above openapi.yaml fragment means that both scopes are REQUIRED (regardless of purpose).
Simply prepending purpose to the technical scopes would lead to
...
paths:
  /read:
    get:
      security:
        - openId:
          - dpv:EnforceSecurity#customer-identifiers:read
          - dpv:EnforceSecurity#customer-address:read
          - dpv:CustomerManagement#customer-identifiers:read
          - dpv:CustomerManagement#customer-address:read

...

All of these scopes are now required for the execution of /read, which means if the user declines consent to one scope, then the RS rejects "/read" for that an access token that has only three of the four scopes.
Which might make sense in some businesses where to fulfill a contract the user has to consent to all the scopes.
I think in openapi there is no way to say: "for this path the API behavior depends on whether one specific scope is 'in' the accesstoken". All required scopes are required. (Pulitzer prize for that last sentence)
The question is which openapi specification do we communicate to the client.
Latest at onboarding-time the client might need to know which purposes are available and allowed for them and which they pay for.
Or do we have something like this openapi spec returned at onboarding time to the client?
...
paths:
  /read__dpv:EnforceSecurity:
    get:
      security:
        - openId:
          - dpv:EnforceSecurity#customer-identifiers:read
          - dpv:EnforceSecurity#customer-address:read
  /read__dpv:CustomerManagement:
    get:
      security:
        - openId:
          - dpv:CustomerManagement#customer-identifiers:read
          - dpv:CustomerManagement#customer-address:read

...

The client knows which scopes are in the access token because the AZ returns the granted scopes if they list of granted scopes is different from the requested scopes. So, the client is not surprised if scopes are missing. Of course the client might then not be able to fulfill their contract with the user.
Regarding the RS: Whether the RS can "get" the scopes "in" the access token is implementation specific.
And if the RS "knows" the individual scopes then the RS can return scope-specific responses.
That can't be formalized in an openapi spec, though, I think. scope in openapi decides whether a request is authorized or not, it does not change the response.

Trying to recap, I believe there are two options in the table, depending on whether we aim to support tokens with multiple purposes (i.e. multiple reasons for accessing certain personal data), which appears to be a tradeoff between user experience (UX) vs. simplicity/security.
OPTION 1. Use a separate "purpose" attribute
It is the simplest option. It is valid if there is no need to send more than one purpose in the same authorization. Otherwise a developer would need to request more than one token. For example:

GET /authorize?scopes=device-location-read check-sim-swap openid&purpose=dpv:FraudPrevention&...

OPTION 2. Use scope prefixes (dpv:xyz#scope) to support for multiple purposes
For instance, if an application wants a token with a scope from the Location API (for marketing purpose) and another scope from the Sim Swap API (for fraud prevention):

GET /authorize?scopes=dpv:Marketing#device-location-read dpv:FraudPreventionAndDetection#check-sim-swap openid&...

An application cannot request the same scope with two different purposes. Otherwise it would be impossible to know which specific purpose is being used when calling an API as Elisabeth described. An example of an incorrect request would be:

GET /authorize?scopes=dpv:FraudPreventionAndDetection#device-location-read dpv:Marketing#device-location-read openid&...

Added complexity makes it unclear how to deal with partial consents as Elisabeth also explained. What if user grants consent for one purpose and not for the other? I also think that, if we choose this option, it should be an all-or-nothing approach.
Both options remove the restriction in ICM release-0.1.0 because devs can request scopes from different APIs without explicitly mentioning the API name(s), and also to identify the specific purpose for each scope.
IMO we should default to simple unless there is a clear requirement coming from OpenGateway product track or any other forum. It's easy to move from option 1 to option 2 in the future, but not the other way around.

Hi all,
I want to bring one more aspect to the discussion. In my view we must avoid - under all circumstances to include the purpose values into the API specifications. This will be unmanageable over time.
When we go for option 1, this will come out of the box.
When we go for option 2 at some point, we need to find a way to avoid the conflicts, e.g. do all-or-nothing for multiple purposes.
When going for a format of combining purpose and scope, we must avoid to ask for the same scope for two different purposes.
We can still go for a concatenation in the token request, but this concatenation must not be part of the yaml file.
IMO, we should start with option 1.

My summary: We see the UX topic but do not have a clear business requirement. We asked several times for comments on this issue providing business requirements (or not). I asked at Camara all-hands and at TSC meetings.
@gauravji2192 , @jpengar, @Elisabeth-Ericsson +1-ed @palmerabollo 's comment and preference for Option 1 (for now).
@sebdewet Orange seems to prefer Option 2. Maybe Orange can agree to have Option 1 in the current text and agree that we discuss moving to Option 2 in a later version?
If Orange agrees, do we then keep @shilpa-padgaonkar text and close this issue?
Purpose
A transaction specific request parameter purpose as specified in openid-connect-4-identity-assurance-1_0-13 MUST be used to allow a SP to state the purpose for the transfer of End-User data it is asking for.
The purpose string MUST use below format for interoperability
dpv:<dpvValue>
<dpvValue> is coming from W3C DPV purpose definition
Although, I suggest re-phrasing that text a little to:
Purpose
An OPTIONAL transaction specific request parameter purpose as specified in openid-connect-4-identity-assurance-1_0-13 allows the client to state the purpose of the requested scopes.
The purpose string MUST use below format for interoperability
dpv:<dpvValue>
<dpvValue> is coming from W3C DPV purpose definition

From a pure product perspective, Telefonica's preference would be to allow multiple couple scope-purpose (option 2) as the most wide approach for adapting the usage of tokens.
@sebdewet, totally agree with your approach.

Hi, that's also our understanding on Orange side.
The scope’s parameter needs to contain the couple purpose-scope, and each purpose-scope the user hasn't accepted or revoked must be asked when consents are asked to the End-User (after authentication).
Then the token generated will embed the purpose-scope in the scope’s parameter that has been accepted by the End-User. End-User can for example accept dpv:FraudPreventionAndDetection#number-verification:verify but deny dpv:FraudPreventionAndDetection#number-verification:device-phone-number:read. Same purpose, different scope, and the RS will know during the introspection that Client only have access to check the MSISDN.

@Elisabeth-Ericsson, agree with you about decoupling the purpose definition to the API spec, in fact that is why generic W3C purposes are promoted instead of creating ad-hoc for CAMARA. Whis this decoupling, we do have 2 separate sets of standard identifiers that jointly create a wide and adaptive usage of the APIs:

standard scopes per API as defined in CAMARA
Standard purposes per legal treatment of the data, as defined in W3C DPV

We just need to enable a mechanism to allow combining them in the same token, of course, defining strict rules (below).
Including only one purpose for a hole set of scopes in the same token will restrict to minimum the number of scenarios where one single token can be used to access more than one API (more than one scope), while reality shows that heterogeneous APIs will be required to be used together, e.g. Number Verification for antifraud while location for service provision and carrier billing for payment. Real example out of many others that cannot be handled with a single purpose.
Speaking about restrictions, it's clear that:

Each couple purpose-scope will require its own lawful base treatment. Consent, legitimate interest.. will require different treatment and considerations, and a different acceptance (automatic or not) will therefore imply that the token will finally only be valid for those "couples" that are accepted. But it is important to remark that this same issue will appear in  the single purpose approach, since same purpose applied to different APIs/scopes will indeed also require different lawful basis and different acceptance.
As per usage identification, it is clear that a token containing 2 couple of the same API but for different purpose need to be prevented. Simply because operator cannot know for which of those purposes it is being used, so charging, auditing or even lawful basis access control could not be executed if that situation appears.
If some APIs require a specific access token creation mechanism, it is also clear that being contained in a group shall not allow them to be retrieved with other mechanism. E.g. Number Verification can only work as part of an AuthCode flow, so a group of scopes:purposes including NV can only be triggered based on an authcode flow. Again, this restriction should apply to any of the two options.

Apart from those, developers will be able to use any purpose and scope within the same access token (from those that operator is, of course, offering) and therefore optimise the access to APIs employing a single token instead of 2, 3,4... again, just because the heterogeneous APIs/services handled in CAMARA is clearly targeting also heterogeneous purposes.

I support to start with option1 for now as mentioned above also by @palmerabollo @Elisabeth-Ericsson
If we want to later address complex combinations, IMHO we might want to look at RAR

@AxelNennker
I would avoid using the OpenId Identity Assurance specification as a reference for the purpose parameter of Option 1 (as described in this comment) as the specification also defines purpose as an extension of the claims parameter as defined by the OpenId Core specification.
Copying the example, claims would be extended to include purpose as follows:
"claims": {
  "given_name": {
    "essential": true,
    "purpose": "To make communication look more personal"
  },
  ...
}

Applying this to the CAMARA context for the proposed text, and assuming that, for CAMARA, a claim is equivalent to a scope, I therefore might expect the purpose for requesting a given scope to be specified as follows:
"claims": {
  "sim-swap:check": {
    "essential": true,
    "purpose": "dpv:FraudPreventionAndDetection"
  },
  ...
}

But that is not how I understand Option 1 at all, which I interpret to be adding purpose as an additional query parameter for authorisation code flow, or additional form parameter for the CIBA flow, e.g.:
Authorisation Code Flow
GET /authorize?scope=openid%20sim-swap:check&purpose=dpv:FraudPreventionAndDetection&...

CIBA
   POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   scope=openid%20sim-swap:check&
   purpose=dpv:FraudPreventionAndDetection&
   login_hint=...

So if my understanding of Option 1 is correct, then no reference to the Identity Assurance specification is required at all, as that defines a different mechanism for passing purpose.
And if my understanding of Option 1 is not correct, then I anyway need a much better description before I can agree to it.

@sebdewet Orange seems to prefer Option 2. Maybe Orange can agree to have Option 1 in the current text and agree that we discuss moving to Option 2 in a later version?
If Orange agrees, do we then keep @shilpa-padgaonkar text and close this issue?

Hi, Orange issue is that purpose outside of scope isn't OIDC standard, and we will need to obtain a validation for this modification of the standard, then implement it in the existing authorization servers.
If we pushed to add purpose in scope, it was to keep the OIDC standard, and to bring this evolution without modifying anything, aknowleding the fact that to get purpose was a good idea.
I don't really understand the difference between the option 1 and 2, except that option 1 need to add a purpose parameter (which is binding). The only goal is to check that we will only have one purpose for each authorize request ? We can also check in the scope parameter that we have only one purpose between each "dpv:" and "#" ? (If I understand the option 1 as @eric-murray)

@sebdewet We were running in circles with the purpose discussion. Yes, we could "code" purpose into scopes and that is what we had in 0.1 but that has some limitations. So, after arguing is circles for some time, we thought that re-using the purpose parameter as defined in eKYC-IDA Transaction-specific Purpose would be a simple step forward and clearly state what the purpose of the request was. Nothing more from eKYC-IDA is "borrowed".
Yes, that adds a new parameter but that is what "profiles" can do.
All agree that Camara needs the ability to express "purpose". Re-using the already in eKYC-IDA standardized parameter purpose for Camara seems a reasonable, small but meaningful step forward.

@sebdewet We were running in circles with the purpose discussion. Yes, we could "code" purpose into scopes and that is what we had in 0.1 but that has some limitations.

Hi, sorry, perhaps you already detailled it, but could you specify all the limitations that the option 1 would answer to and not the option 2 ?

we thought that re-using the purpose parameter as defined in eKYC-IDA Transaction-specific Purpose

Purpose has been removed from the latest version of this specification . It will be added in a separate draft : "Removed "transaction specific purpose" from IDA spec with intent to create separate draft" thus we can't rely on this spec version.

@sebdewet We were running in circles with the purpose discussion. Yes, we could "code" purpose into scopes and that is what we had in 0.1 but that has some limitations.

Hi, sorry, perhaps you already detailled it, but could you specify all the limitations that the option 1 would answer to and not the option 2 ?

The main arguments I see:

Option 2 will not only require a change of AZ to handle the purpose in every scope, but also a change of every RS to understand that it necessary to strip of the dpv value to get the actual technical scope defined in the API. With option 1 the RS could have ignored the purpose.
Option 2 is not extensible - e.g. it will never allow to differentiate between mandatory and optional purposes and/or scopes within a request (to present it accordingly to the end user who has to give the consent) like eKYC-IDA did with the purpose field within the claims parameter to differentiate between essential/non-essential and to have different purposes for single claims. I don't argue to introduce such complexity now, but by following them we would have kept the way open.
With the current status of discussion we don't have in Option 2 the semantic of multiple pairs of purpose#scope defined. E.g. how to present these and how to handle partial consent is not defined and will lead to different implementation -- there were some ideas mentions but nothing thought to an end. That defeats the purpose to support (potential) business use cases with multiple purposes already within the initial version of the profile.

Said this I would have really hoped that we will go with Option 1 within the initial profile. Now we are mostly thrown back to the short-term compromise within ICM v0.1 which is not only restricted to one purpose, but also more or less to one scope due to the undefined semantics of multiple purpose#scope pairs.

we thought that re-using the purpose parameter as defined in eKYC-IDA Transaction-specific Purpose

Purpose has been removed from the latest version of this specification . It will be added in a separate draft : "Removed "transaction specific purpose" from IDA spec with intent to create separate draft" thus we can't rely on this spec version.

You are right that we can't use these exact reference any more. But my understanding is that the group is still following the same approach, that they just decide to carve it out into a separate document (which make sense, as the purpose definition will be needed in different contexts).

This issue was created so that we could get some feedback from the OGW product team if the requirement to support multiple purposes in a single auth request is still valid or not. Our colleagues from TEF were kind to send out a separate email to the participants of the product team to react to this issue.
As there has been no feedback on this, can this issue be closed with the conclusion that currently Camara will ONLY support one purpose per auth request and if there is such a requirement coming up at a later point in time, a new issue will be created for it?
@AxelNennker and @jpengar  WDYT? Or was this already discussed in the last ICM meeting (sorry I missed it) and we already have some other decision in place?

This issue was created so that we could get some feedback from the OGW product team if the requirement to support multiple purposes in a single auth request is still valid or not. Our colleagues from TEF were kind to send out a separate email to the participants of the product team to react to this issue.
As there has been no feedback on this, can this issue be closed with the conclusion that currently Camara will ONLY support one purpose per auth request and if there is such a requirement coming up at a later point in time, a new issue will be created for it?
@AxelNennker and @jpengar WDYT? Or was this already discussed in the last ICM meeting (sorry I missed it) and we already have some other decision in place?

As suggested in last WG call (24/04), Telefónica supports going with option 1 (use a separate "purpose" request param and only one purpose per authorisation request) for now, given the existing requirements, and if more complex scenarios arise in the future, we can think about other solutions like RAR (OAuth 2.0 Rich Authorisation Requests - https://datatracker.ietf.org/doc/html/rfc9396) or other potential options that we may agree.

@jpengar @sebdewet @Elisabeth-Ericsson @AxelNennker : From all the latest comments under this issue, it seems that we are all in agreement that we restrict the authorization request for now to one purpose. After the release 0.4.0, when needed, a new issue can be created to handle complex cases such as multiple purposes in a single auth request.
With this comment, I will now close this issue.
All other discussions about how to represent purpose can be done as usual with comments under PR #121.
Thank you all for providing your feedback on this issue.


[BUG] Cluster not getting created when using RKE2 and choosing Harvester as the cloud provider

In Rancher creating a 3 node cluster (ctrl+master, etcd, worker) never completes. The 3 VMs are running on a server with Harvester.

From Rancher go to create cluster
Select RKE2 and custom nodes
Select cloud provider as Harvester
Create cluster and deploy using helm (passing in correct  as either --etcd --controlplane --worker)

curl -fL https://rancher75182.senode.dev/system-agent-install.sh | sudo  sh -s - --server https://rancher75182.senode.dev --label 'cattle.io/os=linux' --token 8nfrsv7ghcmtm77p92hhv7g2l4m8d45sznf9kv98htwpb54sxmw8jd  <type>

Cluster should take few minutes to create, but does not get created. t's stuck at:
[INFO ] waiting for viable init node
--
11:37:39 am | [INFO ] configuring bootstrap node(s) custom-283498eff280: waiting for agent to check in and apply initial plan
11:38:49 am | [INFO ] configuring bootstrap node(s) custom-283498eff280: waiting for probes: etcd, kubelet
11:39:05 am | [INFO ] non-ready bootstrap machine(s) custom-283498eff280 and join url to be available on bootstrap node
11:39:15 am | [INFO ] configuring control plane node(s) custom-e3216c1a5b9e: waiting for agent to check in and apply initial plan
11:39:21 am | [INFO ] configuring control plane node(s) custom-e3216c1a5b9e: waiting for probes: calico, kube-apiserver, kube-controller-manager, kube-scheduler, kubelet
11:39:35 am | [INFO ] configuring control plane node(s) custom-e3216c1a5b9e: waiting for probes: calico, kube-apiserver, kube-controller-manager, kube-scheduler
11:39:45 am | [INFO ] configuring control plane node(s) custom-e3216c1a5b9e: waiting for probes: calico
11:40:51 am | [INFO ] configuring control plane node(s) custom-e3216c1a5b9e: waiting for cluster agent to connect

Refer to https://docs.harvesterhci.io/v1.1/rancher/node/rke2-cluster#create-rke2-kubernetes-cluster
need install iptables by cloudinit userdata
#cloud-config
packages:
  - iptables

Unfortunately I am not using a cloud image. Instead I already have the VMs already created and using the custom option and then selecting Harvester.
Jattin

On Jan 2, 2023, at 6:33 PM, Hang Yu @.***> wrote:

Refer to https://docs.harvesterhci.io/v1.1/rancher/node/rke2-cluster#create-rke2-kubernetes-cluster
need install iptables by cloudinit userdata
#cloud-config
packages:

iptables
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.


Invalidate Cache After Index is Dropped

What changes were proposed in this pull request?
Index Data will be cached during using. After index is dropped, the related
cache should be removed.
Or the outdated cache may be used again and cause unexpected problem.
How was this patch tested?
Unit test pass

Note 1:
Used java reflection to get access for private member
Note 2:
How to test:
Start a cluster mode spark with OAP loaded.
enable debug log and start a spark-shell and run:
val path = "/Users/linhongl/temp/data"
spark.sql(s"""CREATE TEMPORARY VIEW oap_test (a INT, b STRING) using oap options (path '$path')""".stripMargin)
val data: Seq[(Int, String)] = (1 to 300).map { i => (i, s"this is test $i") }
data.toDF("key", "value").createOrReplaceTempView("t")
spark.sql("insert overwrite table oap_test select * from t")
spark.sql("select * from oap_test").show()
spark.sql("create oindex index1 on oap_test (a)")
spark.sql("select * from oap_test where a = 1").show()
spark.sql("drop oindex index1 on oap_test")

Check log and looking for:
FiberCacheManager: going to remove cache of index1, executor: 0
FiberCacheManager: cache size before remove: 13
FiberCacheManager: cache size after remove: 10 <-- after remove, cache size should decrease

After this, restart another spark-shell and run again, WITHOUTspark.sql("select * from oap_test where a = 1").show()
Check the log again, cache size should be same before and after remove.

Close #468


Clean commented script

cleanup commented code in script
1.remove gen-cert
2.remove commented code which is deprecated
3.remove setup controller_ip

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Please add description to the PR and squash ur commits.

retest

retest

retest

retest

why do we have changes from other PR here? example roles/inspec/defaults/main.yml  and other files.
We need to be careful on how we make PR's.  Blocking merge until is cleaned up.

replace by pr https://github.com/blueboxgroup/ursula/pull/2684


Add ParallelGate and deprecate ParallelGateOperation

This PR deprecates ParallelGateOperation in favor of a new ParallelGate which should be instead. See #4358 for more details.
This PR also adds support for ParallleGate in neutral atoms and pasqal devices, where currently ParallelGateOperation is used.
The uses of ParallelGateOperation will be removed later during deprecation.

Automerge cancelled: A status check is failing.


feat: Paginated Tables for Resource List Views

Added 5 Paginated Tables.
Fixes #583
/claim #583

Hi!
I still have some issues regarding how to get and display "Journeys Used By" and "Last Re-Computed" in the tables. Some clarification would help me correct it.

Hi @maxgurewitz! I have made the respective changes. Please have a look.

@Wr4th100 looking!

I have made the requested changes @maxgurewitz, please have a look!

@Wr4th100 looking!

Can you fix linting by running yarn workspace dashboard lint --fix and yarn workspace backend-lib lint --fix.

Yeah sure, done!

I prefer the look of the table without those borders, if you could please remove them!

Yeah sure!

Can you make use of the autoPageSize option to ensure that the table expands to full height of the page?

I have tried this, but it results in this error.

So worked it out by just removing the maxHeight property. The table automatically resizes to screen size.
Also, should I make the tables expand up to the screen width?

I have made the requested changes. Please have a look!
Also, the video for the tables' UX:
https://github.com/dittofeed/dittofeed/assets/68044488/c685d060-3078-4a62-937b-df47b10fdc8a

To clarify, the goal is to have the number of rows also adjust to fit the screen size so if the screen is larger, more rows are rendered. However, looking at timestamp 1:04 of your recording above, I see that the page size is 5, despite there being 9 results, and room to show more.

Oh, I see, I have made the required changed now. Have a look!
Should I re-record the video again?

@Wr4th100 yes please record another video 👍

@Wr4th100 yes please record another video 👍

Ok sure!
https://github.com/dittofeed/dittofeed/assets/68044488/49d2af75-39d5-4c1b-b840-826438e4ac37

Apologies for the late updates. I have made the required changes. Please have a look!

Hi apologies @Wr4th100 I totally missed that you had made additional changes, will re-review today!

@Wr4th100 here's a video recording with some additional feedback.
https://www.loom.com/share/0f63abbb8dd04c34af1cbfad7709e271?sid=5948fa65-faf8-4b35-bc25-3e8ac1bf384a

Sorry went offline for a few days, will be looking into it!

@Wr4th100 this is rising in priority, if you're not able to work on this, I'm going to have to ask someone else to take it over!

@Wr4th100 this is rising in priority, if you're not able to work on this, I'm going to have to ask someone else to take it over!

Apologies @maxgurewitz, I have had some health issues in the past few weeks.
I have made the required changes but there are some few issues...
Regarding that table scroll, autoPageSize does not work correctly when the rows have variable height. This has been highlighted in the issue https://github.com/mui/mui-x/issues/5697.
So, I have changed the "Used By" columns to dropdowns which displays the templates/journeys concisely.
https://github.com/dittofeed/dittofeed/assets/68044488/69d9d766-1151-40c4-acd5-0b56765a513d
Please let me know if this is ok. If not, I would love to have some guidance on how to use that old UI itself.

Apologies @maxgurewitz, I have had some health issues in the past few weeks.

I'm sorry to hear that! Please let me know if there's anything I can do to help.

So, I have changed the "Used By" columns to dropdowns which displays the templates/journeys concisely.

Great idea! I love it.
Looks like you still have some linting errors here. Beyond that, I will try to give a full re-review by EOD!

Other than small fixes requested, looks amazing! Just ran it locally on my machine and its working great! Thanks for your patience @Wr4th100

@maxgurewitz I have made the changes. Please have a look!

Amazing looks good to me!
Please fix the api test error and it's ready to merge!
https://docs.dittofeed.com/contributing/updating-api-docs

Done. Please have a look!

/tip $50

@Wr4th100 you should join our discord, I'd like to give you a shoutout!


New Regex Functionality Doesn't Appear to Work

Hello, can we have an example of the new Regex functionality is supposed to be used?  I can't seem to even get it to work on a comma separated string correctly.
I am using the Regex.Match function with the following pattern: (?<=^|,)("(?:[^"]|"")"|[^,])
A sample string looks like this: 105261079,43070,,,1283.4,12/24/2020,8177,100504,ABCDEFG Company OR,Test Cust 3,70013,,PSI000072,528,12/24/2020,12/24/2020,PSI000072
When I loop through the Matches table result, the first value is skipped.  It always starts on the second value.  However, running this in a .NET Regex tester yields the correct results.  The Regex.Split function achieves the same problem.

If you look at the tests for the Regex Module, you can find several examples of how the different functions are used.
From your regular expression, it seems like you want to match the first character after each comma? When I run your expression with the Regex Module and string '105261079,43070,,,1283.4,12/24/2020,8177,100504,ABCDEFG' I match the following characters: '1,4,1,1,8,1,A', which seems to be correct.

Could you clarify how you loop through the table? I used Repeat-Until to loop over the entries of the Matches table
Does it change your results, if you run FindFirst() on your table before outputting the result?

If you look at the tests for the Regex Module, you can find several examples of how the different functions are used.
From your regular expression, it seems like you want to match the first character after each comma? When I run your expression with the Regex Module and string '105261079,43070,,,1283.4,12/24/2020,8177,100504,ABCDEFG' I match the following characters: '1,4,1,1,8,1,A', which seems to be correct.

Could you clarify how you loop through the table? I used Repeat-Until to loop over the entries of the Matches table
Does it change your results, if you run FindFirst() on your table before outputting the result?

There doesn't seem to be any problem with the module itself. On top of @aholstrup having confirmed, that all is ok, several partners too have reported that they are using the module successfully. Also, our automated tests ensure, that the module is functional. If you keep having problems, please create a new issue for us, where you reference this one - we will try to support you the best we can. I will close this issue for now, as there isn't any action item for us.

There doesn't seem to be any problem with the module itself. On top of @aholstrup having confirmed, that all is ok, several partners too have reported that they are using the module successfully. Also, our automated tests ensure, that the module is functional. If you keep having problems, please create a new issue for us, where you reference this one - we will try to support you the best we can. I will close this issue for now, as there isn't any action item for us.


DeveloperGuide#A.1.: following PR solution fails the checkstyleTest

This is one of the feedback pointed out by the students during tutorial,
Under the DeveloperGuide#A.1. -> Storage component -> See this PR for the full solution.
The students followed the PR solution but failed the checkstyleTest as the solution code does not meet the OverloadMethodsDeclarationOrder check requirement.

To be fixed before next semester (we should refine all those sample PRs; they were created in a rush -- my bad for rushing it; and may have become outdated in other places too).

Should be resolved now since the CI tests are passing in https://github.com/se-edu/addressbook-level4/pull/594


add frame number while running

As you can see in this example, it's very hard to tell where I actually am in the total completion of the video. It would be helpful to have the frame number somewhere here so I can see how close the video actually is to completion. Sorry if this is already included somewhere.

Perhaps just a more descriptive progress bar is needed that'll show 100% as the completion of the video. We'd disable the one is the call function and use our own. I will look into it.


Code Unreadable

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.92
OS Version:  MacOs 14.5

my code on vs code has become humanly impossible to read after starting an update to version v1.92.
I've disabled all extensions, restarted the computer or even changed the encoding but the problem remains.
I downgraded the version to be able to work.

Your screenshot didn't load.
I would guess that it might be duplicate of #224115
Is you have same problem - check comments that suggest possible workarounds and CLI arguments to try


Move eth mapping creation to a background task

Summary of changes

Changes introduced in this pull request:

Add Ethereum mapping populate task in background
Add status to /readyz endpoint

$ curl "http://<IP_ADDRESS>:2346/readyz?verbose"
[!] sync incomplete
[!] epoch outdated
[+] rpc server running
[!] no eth mapping

Reference issue to close (if applicable)

Closes
Other information and links

Change checklist

[x] I have performed a self-review of my own code,
[x] I have made corresponding changes to the documentation,
[x] I have added tests that prove my fix is effective or that my feature works (if possible),
[x] I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

I believe Calibnet eth mapping check CI task needs to be re-enabled


⚠ ClamAV has degraded performance

In 40e923b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 66 ms

Resolved: ClamAV performance has improved in a18c025 after 5 minutes.


there is no need to use ConcurrentHashMap at synchronized method. Usi…

What is the purpose of the change
improve performance
there is no need to use ConcurrentHashMap at synchronized method. Using HashMap  instead can be helpful for the performance.

ping @hzdavid


XLA does not support complex value comparison for lax.reduce_window

When i try to implement the function from lax.reduce_window for making a max pooling effect from an array using jnp.max, below is the error i faced

File ".local/lib/python3.6/site-packages/jax/api.py", line 170, in f_jitted
name=flat_fun.name, donated_invars=donated_invars)
File ".local/lib/python3.6/site-packages/jax/core.py", line 1100, in call_bind
outs = primitive.impl(fun, *args, **params)
File ".local/lib/python3.6/site-packages/jax/interpreters/xla.py", line 542, in _xla_call_impl
*unsafe_map(arg_spec, args))
File ".local/lib/python3.6/site-packages/jax/linear_util.py", line 221, in memoized_fun
ans = call(fun, *args)
File ".local/lib/python3.6/site-packages/jax/interpreters/xla.py", line 668, in _xla_callable
compiled = backend.compile(built, compile_options=options)
RuntimeError: Unimplemented: complex comparison 'GE'

However, there is a precise result comes out from the function of jnp.max when dealing with complex number.

import jax.numpy as jnp
a = jnp.array([1+1j,2+0j,0+2j])
DeviceArray([1.+1.j, 2.+0.j, 0.+2.j], dtype=complex64)
jnp.max(a)
DeviceArray(2.+0.j, dtype=complex64)

The function i used is a wrapper of lax.reduce_window, and i am not good at coding, i am unable to reproduce the result just with lax.reduce_window. May i request for a feature for handling complex value in lax.reduce_window which workable with jnp.max? Thank you so much.

Thanks for the request!
Which backend are you using (CPU/GPU/TPU)? It may be that it's implemented on some but not others.

I do use Jit in both CPU and GPU, it also pop up the same error as i mentioned above. Thank you so much.

Here is the result when i try to log from the input of lax.reduce_window. Hope this information would help. Thank you so much.
<class 'jax.interpreters.ad.JVPTracer'> Traced<ShapedArray(complex64[128,16,16,16])>with<JVPTrace(level=1/1)>   with primal = Traced<ShapedArray(complex64[128,16,16,16]):JaxprTrace(level=-1/1)>        tangent = Traced<ShapedArray(complex64[128,16,16,16]):JaxprTrace(level=0/1)>

This is an old issue, but I think there's a more fundamental question: what do you mean by the max of two complex numbers? It doesn't seem to be a well-defined thing.
We could follow the numpy comparison behavior here, but honestly I think it's actually a bug in NumPy that comparison of floating point numbers is defined lexicographically. What do you think?


Regex for YYYY using strict mode allows 1-4 chars and pads with leading zeros causing invalid date comparisons

Regex for date formats using YYYY using strict mode allows 1-4 chars and pads with leading zeros causing invalid date comparisons.
var notValid = moment('27-01-17','DD-MM-YYYY',true);
notValid.isValid();
true

Code that causes this:
Line 47
 parseTokenFourDigits = /\d{1,4}/, // 0 - 9999

console.log( (new Date()).toString())
console.log((new Date()).toLocaleString())
console.log( (new Date()).getTimezoneOffset())
console.log( navigator.userAgent)
console.log(moment.version)
Tue Jan 31 2017 09:20:27 GMT-0500 (Eastern Standard Time)
1/31/2017, 9:20:27 AM
300
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
2.4.0

Fix:
parseTokenFourDigits = /\d{4}/,

You must be running an older version? Try pasting this into the console here:
moment('27-01-17','DD-MM-YYYY',true).isValid()
false

The relevant code is here: the second arg is the strict version and is defined here.