[Docs] add compare section in documentation

I think it would be valuable to have a dedicated section in the docs where we compare similar operators.
I often see devs struggle with this particular issue. e.g. "should I use flatmap or switchmap for this usecase".
Also that's a point we can't make very clear in the api docs because there we are focused on that single operator.
For now I don't have any precise idea about the structure and the content itself. I just wanted to raise that idea so that it doesn't get lost :D
Feedback appreciated

Great idea. combineLatest, forkJoin and zip would be another one to cover, alongside switchMap, concatMap and mergeMap. These are the two sets that I find myself explaining most often I think.
I'm also not sure what the best format would be, but I'm thinking something with a practical example might be best. When explaining switchMap, concatMap and mergeMap I often use the concept of a search box that is emitting a stream of user input changes. That stream is then switch/concat/merge mapped to some async call for search results. In that context you can explain the different results you would get from the three operators, and say why in this case switchMap is (probably) the one you want.

There is a practical example that covers all four of the flattening operators in this article (of mine): https://link.medium.com/XZKkTzAfAS

@JWO719 maybe there should be considering putting together an editorial team that can work on content such as this. The team could meet and put together plans for how to get content out to the public. Also, consideration should be taken for having the external resource section where content can be assembled for anyone looking for more deep dive other than source code.

https://github.com/btroncone/learn-rxjs has sections for operators grouping them based on use case.
The docs are currently a bit confusing I think because you don't exactly know whether or not you want to use the new docs at https://rxjs-dev.firebaseapp.com but then that's basically just API documentation without the guides and intro from the old docs. I reckon that's a no-starter for beginners...

@JWO719 any updates here? How should we proceed?


development testing broken due to federation-mode-testing code

@hyi @dtarb @martinseul @aphelionz
The code:
class TestUserZoneIRODSFederation(TestCaseCommonUtilities, TransactionTestCase):
    #....
    def setUp(self):
        super(TestUserZoneIRODSFederation, self).setUp()
        super(TestUserZoneIRODSFederation, self).assert_federated_irods_available()

crashes on my local dev environment, because assert_federated_irods_available only works for instances at RENCI. This also fails on cuahsi-dev-1 and cuahsi-dev-2. These test cases should be skipped unless running on a RENCI host.
assert_federated_irods_available is
    def assert_federated_irods_available(self):
        """assert federated iRODS is available before proceeding with federation-related tests."""
        self.assertTrue(settings.REMOTE_USE_IRODS and
                        settings.HS_USER_ZONE_HOST == 'users.local.org' and
                        settings.IRODS_HOST == 'data.local.org',
                        "irods docker containers are not set up properly for federation testing")
        self.irods_fed_storage = IrodsStorage('federated')
        self.irods_storage = IrodsStorage()

This can never succeed on a host using iRODS servers with different names and -- since it is invoked in setup and teardown -- registers as a testing error rather than a skip.
These tests should be skipped.

@alvacouch
iRODS servers for cuahsi-dev-1 and cuahsi-dev-2 is cuahsi-irods-1 and cuahsi-irods-2 and both were configured correctly, cuahsi-dev-2 is Federated of cuahsi-irods-1, not sure why your code got failed on these server?

@alvacouch @phuongdm The reason assert_federated_irods_available was written that way was that we expected that all iRODS federation-specific tests would only run using the two iRODS docker containers that were federated. This was how the iRODS tests have been run in sandbox triggered by Jenkins for all our PRs and commits. The main consideration for this is based on the assumption that we don't really use real iRODS servers for testing purposes but rather only use iRODS docker containers for easy cleanup without potentially polluting real iRODS servers.

@phuongdm Please comment or close, if you will...

Yes, it's wrong configuration problem, fixed


Command to view gold balance

currently on 'score' will add a 'worth' command which is typically found in dikus.

Awesome ty!

Also say I wanted to change the name of gold, is there any quick way of going about that?

Worth (wo) was added. Will send you a simple one-liner with a players current gold.
There were, with the new worth command, only two references to the word 'gold' -- in commands.js.
After some thought -- I added a new property to config.js: 'coinage'. Changing this value will change the display name everywhere. Because of this the end of comabat string in Combat.js was adjusted to give this value upon mob death. Previously it gave 'coints'.
The default value of World.config.coinage is 'gold'.


Duplicate ReactiveDict name: activeRouteConfig

Meteor version <IP_ADDRESS>
Duplicate ReactiveDict name: activeRouteConfig error begins to show as soon as Meteor flow router title was added with meteor add ostrio:flow-router-title (even without any code level changes).
Plugin still seems to work once the required code is added in FlowRouter routes, the error still persists.

Hello @williamli ,
I can not reproduce it. Could you please post your .meteor/packages file?

Meteor packages used by this project, one per line.
Check this file (and the other files in this directory) into your repository.

'meteor add' and 'meteor remove' will edit this file for you,
but you can also edit it by hand.
<EMAIL_ADDRESS>           # Packages every Meteor app needs to have
<EMAIL_ADDRESS>     # Packages for a great mobile UX
<EMAIL_ADDRESS>                 # The database Meteor supports right now
<EMAIL_ADDRESS>  # Compile .html files into Meteor Blaze views
<EMAIL_ADDRESS>               # Client-side reactive dictionary for your app
<EMAIL_ADDRESS>                # Helpful client-side library
<EMAIL_ADDRESS>               # Meteor's client-side reactive programming library
<EMAIL_ADDRESS>              # ECMAScript 5 compatibility for older browsers.
<EMAIL_ADDRESS>            # Enable ECMAScript2015+ syntax in app code
kadira:flow-router
kadira:blaze-layout
alanning:roles
<EMAIL_ADDRESS>arillo:flow-router-helpers
<EMAIL_ADDRESS>mantarayar:shortid
momentjs:moment
<EMAIL_ADDRESS><EMAIL_ADDRESS>wylio:mandrill
themeteorchef:jquery-validation
lbee:moment-helpers
risul:moment-timezone
yagni:split-on-newlines
<EMAIL_ADDRESS>juliancwirko:s-alert
juliancwirko:s-alert-stackslide
patrickml:swal
risul:jsondiffpatch
maximdubrovin:uploadcare
<EMAIL_ADDRESS>fortawesome:fontawesome
lukemadera:social-share
tomwasd:flow-router-seo
maxharris9:classnames
underscorestring:underscore.string
djedi:sanitize-html-client
raix:handlebar-helpers
reywood:publish-composite
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>react-template-helper
react-meteor-data
fourseven:scss
<EMAIL_ADDRESS>dynamic-import

Hello @williamli ,
Thanks for info.

I don't see ostrio:flow-router-title to be installed
ostrio:flow-router-title is guaranteed to work only with ostrio:flow-router-extra
If you swap kadira:flow-router with meteor/ostrio:flow-router-extra, do not forget to remove arillo:flow-router-helpers (it's built in)

ostrio:flow-router-title is not installed because it was causing the problem
i didn't know i need to use ostrio:flow-router-extra instead of kadira:flow-router

thanks for the info.
ps: maybe a line stating it is not intended for kadira:flow-router in the README would help?

See second line - https://github.com/VeliovGroup/Meteor-flow-router-title#reactive-page-title

BTW FlowRouter-Extra already suggested by blaze.js and it's coming to Meteor's guide


Indigo 2022.1.0 compatibility

Indigo's plug-in store indicates that this plug-in may not be compatible with versions after Indigo 2022.1.0. All embedded and external Python scripts are now executed in Python 3.10.
See https://www.indigodomo.com/docs/2022.1/getting_started#python_script_changes_and_plugin_compatibility

This plugin is obsolete and no longer maintained.  There is a replacement plugin under active development. See https://forums.indigodomo.com/viewforum.php?f=366

Thanks @FlyingDiver. I'll switch over to that HomeKitLink Plugin Beta Release.


Add poll to EVCC to check if vehicle is connect before quirying the API

Currently you poll the vehicle every 5 mins even in the night waking up the vehicle to send SOC information
If this is only used to feed EVCC for SOC it would be nice to have a poll to EVCC and check if the vehicle is actually connected to the charger and only if connected send out a SOC API query,
This would drastically limit the API usage and battery drain on the vehicle. EVCC API can provide you with the if connected part.
So a parameter is EVCC only would be needed so we can skip almost all API pulls only battery related would be needed. and at the same time if this is set a EVCC pull would determine if the vehicle is connected and if connected we can querry the API and at a higher pace like default every 2 min.

As this is an homeassistant addon, I will not implement any evcc functionality, sorry. Maybe someone builds an evcc plugin.

ok fair,
Would it be ok if i would do  that based on your work using this module ?

Sure!! Feel free to fork!

ok fair,
Would it be ok if i would do that based on your work using this module ?

You can change the poll time from homeassistant
action: number.set_value
metadata: {}
data:
  value: "{{ periodo }}"
target:
  entity_id: number.volvo_xxxxx_update_interval


Implement CallParams / FunctionResult

#62 adds preliminary smart contract support but only supports passing parameters/results as bytes for the moment.
We have a decently fleshed out API in the Java SDK that we should probably just copy:

https://github.com/hashgraph/hedera-sdk-java/blob/master/src/main/java/com/hedera/hashgraph/sdk/CallParams.java
https://github.com/hashgraph/hedera-sdk-java/blob/master/src/main/java/com/hedera/hashgraph/sdk/FunctionResult.java

CallParams encoding is implemented in https://github.com/hashgraph/hedera-sdk-js/pull/94


[Usability][Keyboard Navigation Services->+symbol] Visual focus indicator is cut off for “Privacy statement link”

Actual Result:
Visual focus indicator is not clearly visible for “Privacy statement link”
Expected Result:
Visual focus indicator should be clearly visible for “Privacy statement link”
Repro Steps:

Open the Bot Framework V4 Emulator.
Navigate to Welcome tab screen and select it, screen gets opened
Navigate to the open bot and select it
Open bot dialog gets opened and connect to the open bot
Live chat screen gets appears
Navigate to the Edit ngrok settings and select it
Emulator screen gets opened
Navigate to the Privacy statement and observe the issue

User Impact:
Users who rely on Keyboard navigation will be affected the keyboard focus indicator is not clearly visible on control so that keyboard dependant users will be affected.
Test Environment:
OS Build: Version 1903(OS Build 18362.239)
Browser: Edge
Application: Bot Framework V4 Emulator
Usability_settings.zip

Note: focus is cut off. We just need to fix that - no need to involve Design.

Might just be able to throw width: auto onto the link and call it a day

addressed in https://github.com/microsoft/BotFramework-Emulator/pull/1776

Verified in latest Bot emulator version -4.5.2-79718 .Issue got fixed hence we are closing this bug.
Now  Visual focus indicator clearly visible for “Privacy statement link”


storage: add new backend HttpProxy

This pr adds a new storage backend HttpProxy which can access blobs through a http proxy server.
The http proxy server can be local (using unix socket) or remote (using https:// or using http://).
HttpProxy uses two API endpoints to access the blobs:

HEAD /path/to/blobs to get the blob size
GET /path/to/blobs to read the blob

The http proxy server should respect the Range header to compute the offset and length of the blob.
The example config files for this new backend may be:
// for remote usage
{
  "backend": {
    "type": "http-proxy",
    "config": {
      "addr": "http://<IP_ADDRESS>:9977",
      "path": "/namespace/<repo>/blobs"
    }
  }
}

or
// for local unix socket
{
  "backend": {
    "type": "http-proxy",
    "config": {
      "addr": "/path/to/unix/socket/file"
    }
  }
}

There is also a test in http_proxy.rs to make sure HttpProxy works well, which setups a simple http server and generates a HttpProxy backend to get contents from the server.
Signed-off-by: Nan Li<EMAIL_ADDRESS>

Thanks @loheagn for the contribution, it can make nydus-image unpack faster!
My suggestion is that maybe we should implement the content store backend with HTTP over unix domain socket instead of TCP, which is simpler and requires only implementing two distribution APIs:

HEAD blob size;
GET blob data (HTTP range get);

It's very like contrib/nydus-backend-proxy server (it receives HTTP requests and proxy to a local blob directory).

Please also add SOB for the commits.

Hi @loheagn, Could also update the doc in here? Thanks!

Hi @loheagn, Could also update the doc in here? Thanks!

No problem. The docs were updated.

need rebase to master since anolis test script is updated


Testing Rultor

Testing Rultor

@rultor try to merge

@rultor try to merge

@mikita-herasiutsin OK, I'll try to merge now. You can check the progress of the merge here

@rultor try to merge

@mikita-herasiutsin Done! FYI, the full log is here (took me 2min)

@rultor try to merge

@rultor try to merge

@mikita-herasiutsin The pull request is closed already, so I can't merge it

@rultor try to merge

@mikita-herasiutsin I'm sorry, I don't understand you :( Check this page and try again please


kappa value for penalizing term in Discontinuous Galerkin

Hello,
I am using a DG formulation which relies on a stabilizing kappa coefficient for the bilinear and linear forms.
The kappa value is set automatically to (p+1)^2 but I can't find any publication confirming that particular choice.
Could you send me a reference where I could look at that?
Thank you
Pierre

Most references mention "the SIPG method is stable for sufficiently large \kappa". If you are using NIPG, this changes to "the method is stable for any \kappa > 0". So it depends which type of stabilization you choose and then you are left with the freedom (or burden) of choice.

Yes I agree totally with your statements.
In my case, it is SIPG. Nitsche says in its paper that we can find a sufficiently large value to get a stable method.
However, relating \kappa to the order of the method is not given.

Hello @pmguilcher, you can look at this paper:
Shahbazi, K. (2005).  An explicit expression for the penalty parameter of the interior penalty method, Journal of Computational Physics, 205(2), 401--407. http://dx.doi.org/10.1016/j.jcp.2004.11.017
I can provide you with more references if you are interested.

Hello @pazner,
Thank you very much, I think that it totally corresponds to the value used in mfem lib.
Best regards

Hi @pazner,
I'd like to use Shahbazi's algorithm for computing the penalty parameter for a SIPG discretization. Did your comment indicate that it's already implemented somewhere? If not, I can implement it, but I'm unsure how to compute some of the terms in the numerator of Eq. (7) from his paper. Specifically, I mean the face area that does not intersect the boundary, and the face area that does intersect the boundary. Is there an easy way to get the information needed from the ElementTransformation (or FaceElementTransformation)?

I suppose what you need to do is loop over each face of the element, and determine whether the face is in the interior or on the boundary (i.e., does it have one neighboring element or two), and then compute the surface area (by summing the Jacobian determinant weighted by the quadrature weights).
I don't anticipate that this penalty term will differ significantly from what MFEM currently implements.
Can I ask what your motivation is for optimizing the penalty parameter?

@pazner I had been seeming some issues with convergence rates for a particular problem of mine, that were resolved when I went to very large penalty parameter (~10^8). I'm now more suspecting that there is something else wrong that is forcing the use of such a large parameter. I'll come back here if I can't figure it out, thank you!

Sounds good. Closing for now… re-open if needed.
Generally speaking, if you just supply MFEM's DGDiffusionIntegrator with a moderate O(1) kappa value, it should be stable.
The rates of convergence for IP-DG shouldn't depend on the penalty parameter — if the parameter is large enough so that the method is stable, you should get $h^p$ in the broken $H^1$ norm and $h^{p+1}$ in the $L^2$ norm.


Add PWA support

Context
Add PWA capability to quickly install as an app-like experience on Mobile, PC, Mac, or any platform.
Screenshot

Friggin awesome.
Tak pasti nak test macam mana kat iOS, tapi merge dulu.
Ribuan terima kasih! Nanti nak explore PWA.

@amree ios gini rasanya


Enhancement - Elastic Sources - Allow tstats from datamodels queries

Enhancement - Elastic Sources - Allow tstats from datamodels queries

Canceled, there are some unexpected behaviours and potential consequences


Add Stream API Example

Adds an example to demonstrate how the streaming mode is supposed to be used.

sick! @rasbt


[native_pdf_view] nnbt migration, flutter v2 capability, replace exte…

…nded_image by photo_view, bump 4.0.0

hi @SergeShkurko
thanks so much for building and maintaining this package 🤗 extra thanks for your efforts adding support for flutter v2 and nnbd.
is this 4.0.0 release of native_pdf_view waiting on something before you do a release? anything i can help with?
thanks again!


unstick element

I ran into an issue where unstick element was not working properly.
unStickElement sets the style attribute to the initial style.
However the initial style ngSticky cached isn't necessarily correct as it may have a media query.
If unStickElement simply removed the style attribute from the element it would work correctly.

+1


HotplugCPU: target pod unschedulable, source pod disappeared

What happened:
After adjusting the CPU socket through a patch, the operation returned a success message. However, due to insufficient CPU resources, the target virt-launcher pod remains in a pending state, and the source virt-launcher pod has disappeared. This situation has caused the original virtual machine to be affected.

What you expected to happen:
When there are insufficient resources to start the target pod, the original virtual machine remains unaffected, and the CPU expansion process can be canceled.
How to reproduce it (as minimally and precisely as possible):
In a Kubernetes scenario with insufficient resources, perform CPU scaling on a running virtual machine.
Environment:

KubeVirt version (use virtctl version): 1.2.0
Kubernetes version (use kubectl version): 1.27.6
OS (e.g. from /etc/os-release): centos 8

The source should not have disappeared for sure, what is the status of the VM? Do you know why the source disappeared?


Add AppVeyor build for Windows, use zlib NuGet package

This is the minimal change to introduce a first Windows build with AppVeyor CI.

Added .appveyor.yml

Create a self-signed certificate to make the signtool.exe build steps happy

Start using NuGet to manage packages for the Visual Studio Solution

Added vcnet/packages.config which contains the zlib dependency with name and version
You can restore the dependencies in the command line: nuget restore vcnet\ippsample.sln
You can restore the dependencies in Visual Studio

- Right click on the Solution
  - Manage NuGet Packages for Solution...
  - Restore NuGet Packages

Added the AppVeyor Build Status Badge to the README.md

This should be updated once you have activated AppVeyor builds for istopwg/ippsample repo.

At the moment you can see my forked builds. The build #25 shows the current status. The build errors at
  ..\cups\http-support.c(16): fatal error C1083: Cannot open include file: 'dns_sd.h': No such file or directory [C:\projects\ippsample\vcnet\libcups2.vcxproj]

With this PR I don't want to change too many files, just to get started with AppVeyor.
A next PR will have some code changes to improve the compilation of libcups2 on Windows.
A general question is how we could proceed with the Bonjour SDK for the HAVE_DNSSD compile switch?

From a developers perspective it would be the simplest to have the Bounjour SDK packages as a NuGet package that can be added to the package.config. Visual Studio then adds include and lib pathes.
I know the Bonjour SDK for Windows is only available with an Apple developer ID at https://developer.apple.com/download/more/?=Bonjour SDK for Windows
So sad ;-)

Hmm, the download didn’t used to require a developer ID... Will ask about that...

Another idea is to add another build target "Debug with DNSSD" / "Release with DNSSD" to set the HAVE_DNSSD define and move it out of the vcnet/config.h.
Just to be able to make the build working on AppVeyor without the Bonjour SDK until we have a solution for that.

I am working on a run-time solution with a local static library that handles dynamically loading the Bonjour library.

@StefanScherer Check out the latest code - Bonjour is loaded at runtime and NuGet is used for zlib. Seems to work for me... :)

Thanks @michaelrsweet that looks very good.
I had to retarget the solution to my current Windows SDK, but then I was able to compile the solution.
PS C:\Users\demo\Documents\Visual Studio 2017\Projects\ippsample> dir .\vcnet\x64\Debug\*.exe

    Directory: C:\Users\demo\Documents\Visual Studio 2017\Projects\ippsample\vcnet\x64\Debug

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       10/18/2018   6:45 AM         113664 ippfind.exe
-a----       10/18/2018   6:45 AM         423424 ippserver.exe
-a----       10/18/2018   6:45 AM         155648 ipptool.exe

I'll update the PR to just add the .appveyor.yml

I've updated the .appveyor.yml in this PR. Everything else is already in master branch. The build of the release binaries works fine, even the signtool works with the temporary certificate.
The AppVeyor build also runs the three binaries as a very simple test.
An example build of this PR is here: https://ci.appveyor.com/project/StefanScherer/ippsample/builds/19608257
The AppVeyor build also stores the exe files and dll's as build artifact for six months for each Git commit.
The Artifacts can be found in the Artifacts tab https://ci.appveyor.com/project/StefanScherer/ippsample/builds/19608257/artifacts
Once the PR is merged and AppVeyor is connected to this repo we can add a build status badge to the README.md with the correct URL.

I forgot to add a link, here is AppVeyor in the GitHub marketplace https://github.com/marketplace/appveyor

OK, let's see how this works... :)

Looks really good, people now can pick the artifacts from AppVeyor and try things out and give feedback even without an own compiler.


Add cache headers for asset (css/js) responses

Cache for a configurable amount of time.

Migrated to https://gitlab.com/commento/commento-ce/issues/35


add requestHeaderModifier fail

Describe the bug
I have configured httproute.spec.rules.filters.requestHeaderModifier.add.name and httproute.spec.rules.filters.requestHeaderModifier.add.value in httproute. The values are X-Real-IP and remote_addr, respectively. httproute.spec.rules.filters.type is RequestHeaderModifier. However, in the nginx-gateway Pod, remote_addr is recognized as proxy_set_header X-Real-IP "${x_real_ip_header_var}remote_addr"; how can I configure it to recognize as proxy_set_header X-Real-IP "$remote_addr"? I have tried configuring httproute.spec.rules.filters.requestHeaderModifier.add.value as $remote_addr, but it causes all proxy_set_header commands in the nginx-gateway to not be recognized. How can I resolve this issue?

Hi @Eason-Liu, we don't support setting nginx variables like $remote_addr in requestHeaderModifier filter, or any of the HeaderModifiers.
If you describe the HTTPRoute where you defined this requestHeaderModifier you should see an error like:
All rules are invalid: spec.rules[0].filters[0].RequestHeaderModifier.add: Invalid value: v1.HTTPHeader{Name:"X-Real-IP", Value:"$remote_addr"}: a valid value must have all '"' escaped and must not contain any '$' or end with an unescaped '\' (e.g. 'my-header-value',  or 'example/12345==', regex used for validation is '([^"$\\]|\\[^$])*')

Can I ask what you are trying to achieve? Are you trying to preserve the client's IP address? Would this planned feature help: https://github.com/nginxinc/nginx-gateway-fabric/issues/1406?

Yes, I want to retain the client's real IP address for log analysis.

Yes, I want to retain the client's real IP address for log analysis.

@Eason-Liu thanks for the response. #1406 will add this feature and is planned for the next release.


move to a better reporter

lets move to the default reporter of mocha.
nyan is funny but actually not really useful and it is a mess on travis

Default reporter:
...
  ✓ #or
  ✓ #pick
  ✓ #pipe
  ✓ #plus
  ✓ #property
  ✓ #reduce
  ✓ #reduceFrom
  ✓ #reduceFromRight
  ✓ #reduceRight
  ✓ #replace
  ✓ #shallowClone
  ✓ #shave
  ✓ #some
  ✓ #split
  ✓ #tail
  ✓ #take
  ✓ #takeUntil
  ✓ #takeWhile
  ✓ #times
  ✓ #uncurry
  ✓ #uncurry3
  ✓ #xor

  74 passing (82ms)

:cat:


Can you publish 1.1.4 podspec?

Currently, we have to pin our Podfile to 1.1.2 (due to an encoding issue in 1.1.3) or override TDOAuth.podspec locally. Would be nice to just use the published 1.1.4 version.

Sorry, done.
FYI, you can specify the git-tag you need in your Podfile, though obviously, better to report the omission like you did, so: many thanks.

Thank you! 😄


chore: Removes last vestiges of old store based titling

I saw some bits of the old store based titling still existed but didn't really do anything anymore, so I went through and cleaned up.
While I was there I made it so all "detail" pages use the form name-of-the-specific-thing Type of thing (e.g. program-0 Data plane proxy) consistently. The shouldn't/doesn't require test amends seeing as we check titles contain the text rather than equals the text.
Just to note I much like the fact that we are getting rid of more code here and its much easier and more obvious how to set the title of the page, a small thing but all these little small improvements will gradually add up.
Signed-off-by: John Cowen<EMAIL_ADDRESS>

Suggestion: Perhaps we should also add "Mesh" to the mesh name in the document title.

👍 added!


[TC-153] URL Signing Plugin - Query String Hashing Override Option

When using query string URL signing, if the client adds any additional  query strings to the URL, these are ALWAYS considered in the URL hash regardless of the use parts settings.
When using pathparams URL signing, if the client adds query string parameters to the URL they are NEVER considered in the URL hash regardless of the use parts settings.
Provide a signing option which allows users to override the default behavior and include or exclude custom query strings in the URL signature hash. Standard behavior could remain as is and this new parameter would allow users to override the standard behavior.
Author: Ryan Durfey
JIRA Link: https://issues.apache.org/jira/browse/TC-153
Found Version: 2.1.0

@ryandurfey
@ashish-timilsina

Is this still an issue - especially now that Consistent Hashing Query Parameters have been introduced? Which kind of hashing are you talking about, Traffic Router or Traffic Server?


Fix minor bug

Codecov Report

Merging #48 (582cec3) into master (26c673a) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master      #48   +/-   ##
=========================================
  Coverage     72.74%   72.74%
  Complexity      412      412
=========================================
  Files            71       71
  Lines          1273     1273
  Branches        132      132
=========================================
  Hits            926      926
  Misses          313      313
  Partials         34       34

Impacted Files
Coverage Δ

...c/main/java/seedu/address/model/person/Person.java
97.87% <100.00%> (ø)

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 26c673a...582cec3. Read the comment docs.


Credentials not found

What happened:
Trying to scan a pod containing a private image and it fails, public images are scanned.
$ oc logs scanner-zap2docker-stable-b72cafcd-4ccc-47cd-8e79-1fb6--1-jpr67 -n sbu-dev

time="2022-04-26T16:21:19Z" level=debug msg="Credentials not found. image name=uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00." \
func="github.com/cisco-open/kubei/shared/pkg/utils/creds.(*CredExtractor).GetCredentials" file="/build/shared/pkg/utils/creds/extractor.go:78"

What you expected to happen:
I expect the secret (which is available in the namespace being scanned) to be obtained and used.
How to reproduce it (as minimally and precisely as possible):
Deploy kubeclarify v2.1.2 to k8s and perform a namespace scan whereby images within namespace are in a private registry.
Are there any error messages in KubeClarity logs?
$ oc logs scanner-zap2docker-stable-b72cafcd-4ccc-47cd-8e79-1fb6--1-jpr67 -n sbu-dev

time="2022-04-26T16:21:19Z" level=debug msg="Credentials not found. image name=uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00." \
func="github.com/cisco-open/kubei/shared/pkg/utils/creds.(*CredExtractor).GetCredentials" file="/build/shared/pkg/utils/creds/extractor.go:78"

Anything else we need to know?:
Environment:

KubeClarity version: v2.1.2

I increased the log-level and have also now seen this:
{IMAGE_NAME_TO_SCAN uk.icr.io/sbu-pipeline/zap2docker-stable:2.11 nil} {K8S_IMAGE_PULL_SECRET  &EnvVarSource{FieldRef:nil,ResourceFieldRef:nil,ConfigMapKeyRef:nil,SecretKeyRef:&SecretKeySelector{LocalObjectReference:LocalObjectReference{Name:basic-regcred,},Key:.dockerconfigjson,Optional:nil,},}}]

and this:
time="2022-04-26T18:19:50Z" level=debug msg="No matching secret found." func=github.com/cisco-open/kubei/shared/pkg/utils/k8s.GetMatchingSecretName file="/build/shared/pkg/utils/k8s/k8s_utils.go:71"

Which I believe relates to lines 202 and 231 of this code whereby the image pull secret is supposedly obtained and then the matching secret obtained as well.

Hi @mtcolman @mmurhamm, thanks for the information. We'll add documents about the architectural changes between Kubei 1 and a Kubei 2 to make it more clear. Regarding the image pull secret, the main difference is that we moved from using DockerKeyRing https://github.com/cisco-open/kubei/blob/1.0.16/pkg/utils/k8s/k8s_utils.go#L57 to use
"github.com/google/go-containerregistry/pkg/authn/kubernetes:
https://github.com/cisco-open/kubei/blob/3217eb2e7da5b7d05952dc9711cc1ad9efd2b0cb/shared/pkg/utils/k8s/k8s_utils.go#L75
From the provided logs, looks like the basic-regcred secret should be used (no ImagePullSecret on the pod), right?

@akpsgit thanks for your reply. The imagePullSecret is in the pod to be scanned, so it would expect it to use that rather than falling back to basic-regcred:
$ oc get pod matt-zap-owaspzap-zap-66cb56cdc4-wkxlw -n sbu-dev -oyaml | grep PullSecrets -A2
  imagePullSecrets:
  - name: sbu-pipeline

Secret is present in that namespace as well:
$ oc get secret -n sbu-dev | grep sbu
sbu-pipeline                                         kubernetes.io/dockerconfigjson        1      152d

Is matt-zap-owaspzap-zap-66cb56cdc4-wkxlw is the only pod that contains the uk.icr.io/sbu-pipeline/zap2docker-stable:2.11 image? I'm asking because we create a scanner per image, and take the details from the first pod in the list that contains this image (might not have the pull secret) - small chance but worth checking:
https://github.com/cisco-open/kubei/blob/3217eb2e7da5b7d05952dc9711cc1ad9efd2b0cb/runtime_scan/pkg/scanner/job_managment.go#L262
If there is no other pod that uses this image, worth trying to start this pod in a separate namespace and scan only it to get more coherent logs in KubeClarity backend (where the job management is running). If nothing new comes up, can you please attach the "oc get pod matt-zap-owaspzap-zap-66cb56cdc4-wkxlw -n sbu-dev -oyaml" output (with stripped sensitive/identifying values) so we can try to recreate and debug it?

Created brand new namespace mattzap and deployed pod. That via UI, selected namespace and ran scan:
$ oc get pod -n mattzap
NAME                                                              READY   STATUS      RESTARTS   AGE
newzap-owaspzap-zap-b9dc5f9d7-qbm44                               2/2     Running     0          2m32s
scanner-nginx-unprivileged-e34e22b6-7eab-4d4a-a45a-fc3--1-sg4bw   0/1     Completed   0          54s
scanner-zap2docker-stable-78eba9a6-6014-49bb-8331-2dac--1-pvndz   0/1     Completed   0          54s

Scan results are:
time="2022-04-27T16:08:52Z" level=info msg="Start scanning..." func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).Scan" file="/build/runtime_scan/pkg/scanner/scanner.go:265" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:08:52Z" level=debug msg="No matching secret found." func=github.com/cisco-open/kubei/shared/pkg/utils/k8s.GetMatchingSecretName file="/build/shared/pkg/utils/k8s/k8s_utils.go:71"
time="2022-04-27T16:08:52Z" level=debug msg="No matching secret found." func=github.com/cisco-open/kubei/shared/pkg/utils/k8s.GetMatchingSecretName file="/build/shared/pkg/utils/k8s/k8s_utils.go:71"
time="2022-04-27T16:08:52Z" level=info msg="Total 2 unique images to scan" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).initScan" file="/build/runtime_scan/pkg/scanner/scanner.go:255" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:08:52Z" level=debug msg="Created job=&Job{ObjectMeta:{scanner-nginx-unprivileged-e34e22b6-7eab-4d4a-a45a-fc3366394ca3  mattzap    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[app:scanner sidecar.istio.io/inject:false] map[] [] []  []},Spec:JobSpec{Parallelism:nil,Completions:nil,ActiveDeadlineSeconds:nil,Selector:nil,ManualSelector:nil,Template:{{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[app:scanner sidecar.istio.io/inject:false] map[] [] []  []} {[{tmp-volume {nil EmptyDirVolumeSource{Medium:,SizeLimit:<nil>,} nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil}}] [] [{vulnerability-scanner ghcr.io/cisco-open/kubeclarity-runtime-k8s-scanner:latest [] [scan --log-level debug]  [] [] [{RESULT_SERVICE_ADDR kubeclarity-kubeclarity.kubeclarity:8888 nil} {SBOM_DB_ADDR kubeclarity-kubeclarity-sbom-db.kubeclarity:8080 nil} {ANALYZER_LIST syft gomod nil} {ANALYZER_SCOPE squashed nil} {SCANNERS_LIST grype nil} {SCANNER_GRYPE_MODE REMOTE nil} {REGISTRY_SKIP_VERIFY_TLS false nil} {REGISTRY_USE_HTTP false nil} {SCANNER_REMOTE_GRYPE_SERVER_ADDRESS kubeclarity-kubeclarity-grype-server.kubeclarity:9991 nil} {SCANNER_REMOTE_GRYPE_SERVER_TIMEOUT 2m nil} {SCAN_UUID 4a32c0a3-296b-440c-839c-a0f1478e1098 nil} {IMAGE_ID_TO_SCAN uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2 nil} {IMAGE_HASH_TO_SCAN e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2 nil} {IMAGE_NAME_TO_SCAN uk.icr.io/sbu-pipeline/nginx-unprivileged:1.21.4-alpine-sbu nil}] {map[cpu:{{1000 -3} {<nil>}  DecimalSI} memory:{{1048576000 0} {<nil>}  BinarySI}] map[cpu:{{50 -3} {<nil>} 50m DecimalSI} memory:{{52428800 0} {<nil>} 50Mi BinarySI}]} [{tmp-volume false /tmp  <nil> }] [] nil nil nil nil   Always &SecurityContext{Capabilities:&Capabilities{Add:[],Drop:[all],},Privileged:*false,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:*true,ReadOnlyRootFilesystem:*true,AllowPrivilegeEscalation:*false,RunAsGroup:nil,ProcMount:nil,WindowsOptions:nil,SeccompProfile:nil,} false false false}] [] Never <nil> <nil>  map[]   <nil>  false false false <nil> nil []   nil  [] []  <nil> nil [] <nil> <nil> <nil> map[] [] <nil> nil}},BackoffLimit:*0,TTLSecondsAfterFinished:*300,CompletionMode:nil,Suspend:nil,},Status:JobStatus{Conditions:[]JobCondition{},StartTime:<nil>,CompletionTime:<nil>,Active:0,Succeeded:0,Failed:0,CompletedIndexes:,UncountedTerminatedPods:nil,Ready:nil,},}" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).runJob" file="/build/runtime_scan/pkg/scanner/job_managment.go:164" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:08:52Z" level=info msg="Running job mattzap/scanner-nginx-unprivileged-e34e22b6-7eab-4d4a-a45a-fc3366394ca3 to scan imageID uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).runJob" file="/build/runtime_scan/pkg/scanner/job_managment.go:166" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:08:52Z" level=debug msg="Created job=&Job{ObjectMeta:{scanner-zap2docker-stable-78eba9a6-6014-49bb-8331-2daca6ce9373  mattzap    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[app:scanner sidecar.istio.io/inject:false] map[] [] []  []},Spec:JobSpec{Parallelism:nil,Completions:nil,ActiveDeadlineSeconds:nil,Selector:nil,ManualSelector:nil,Template:{{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[app:scanner sidecar.istio.io/inject:false] map[] [] []  []} {[{tmp-volume {nil EmptyDirVolumeSource{Medium:,SizeLimit:<nil>,} nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil}}] [] [{vulnerability-scanner ghcr.io/cisco-open/kubeclarity-runtime-k8s-scanner:latest [] [scan --log-level debug]  [] [] [{RESULT_SERVICE_ADDR kubeclarity-kubeclarity.kubeclarity:8888 nil} {SBOM_DB_ADDR kubeclarity-kubeclarity-sbom-db.kubeclarity:8080 nil} {ANALYZER_LIST syft gomod nil} {ANALYZER_SCOPE squashed nil} {SCANNERS_LIST grype nil} {SCANNER_GRYPE_MODE REMOTE nil} {REGISTRY_SKIP_VERIFY_TLS false nil} {REGISTRY_USE_HTTP false nil} {SCANNER_REMOTE_GRYPE_SERVER_ADDRESS kubeclarity-kubeclarity-grype-server.kubeclarity:9991 nil} {SCANNER_REMOTE_GRYPE_SERVER_TIMEOUT 2m nil} {SCAN_UUID c8321846-3f3f-44ea-8bf7-e6ebdb50deb1 nil} {IMAGE_ID_TO_SCAN uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00 nil} {IMAGE_HASH_TO_SCAN 6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00 nil} {IMAGE_NAME_TO_SCAN uk.icr.io/sbu-pipeline/zap2docker-stable:2.11.1-sbu nil}] {map[cpu:{{1000 -3} {<nil>}  DecimalSI} memory:{{1048576000 0} {<nil>}  BinarySI}] map[cpu:{{50 -3} {<nil>} 50m DecimalSI} memory:{{52428800 0} {<nil>} 50Mi BinarySI}]} [{tmp-volume false /tmp  <nil> }] [] nil nil nil nil   Always &SecurityContext{Capabilities:&Capabilities{Add:[],Drop:[all],},Privileged:*false,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:*true,ReadOnlyRootFilesystem:*true,AllowPrivilegeEscalation:*false,RunAsGroup:nil,ProcMount:nil,WindowsOptions:nil,SeccompProfile:nil,} false false false}] [] Never <nil> <nil>  map[]   <nil>  false false false <nil> nil []   nil  [] []  <nil> nil [] <nil> <nil> <nil> map[] [] <nil> nil}},BackoffLimit:*0,TTLSecondsAfterFinished:*300,CompletionMode:nil,Suspend:nil,},Status:JobStatus{Conditions:[]JobCondition{},StartTime:<nil>,CompletionTime:<nil>,Active:0,Succeeded:0,Failed:0,CompletedIndexes:,UncountedTerminatedPods:nil,Ready:nil,},}" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).runJob" file="/build/runtime_scan/pkg/scanner/job_managment.go:164" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:08:52Z" level=info msg="Running job mattzap/scanner-zap2docker-stable-78eba9a6-6014-49bb-8331-2daca6ce9373 to scan imageID uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).runJob" file="/build/runtime_scan/pkg/scanner/job_managment.go:166" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:08:53Z" level=info msg="Waiting for result. imageID=uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).waitForResult" file="/build/runtime_scan/pkg/scanner/job_managment.go:135" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:08:53Z" level=info msg="Waiting for result. imageID=uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).waitForResult" file="/build/runtime_scan/pkg/scanner/job_managment.go:135" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=info msg="Vulnerabilities result was set for imageID \"uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00\"" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).HandleScanResults" file="/build/runtime_scan/pkg/scanner/scanner.go:392" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=warning msg="Vulnerabilities scan of imageID \"uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00\" has failed: &{failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00': unable determine image source TBD}" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).HandleScanResults" file="/build/runtime_scan/pkg/scanner/scanner.go:399" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=info msg="Image scanned result has arrived. imageID=uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).waitForResult" file="/build/runtime_scan/pkg/scanner/job_managment.go:139" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=info msg="Vulnerabilities result was set for imageID \"uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2\"" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).HandleScanResults" file="/build/runtime_scan/pkg/scanner/scanner.go:392" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=warning msg="Vulnerabilities scan of imageID \"uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2\" has failed: &{failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2': unable determine image source TBD}" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).HandleScanResults" file="/build/runtime_scan/pkg/scanner/scanner.go:399" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=info msg="Image scanned result has arrived. imageID=uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).waitForResult" file="/build/runtime_scan/pkg/scanner/job_managment.go:139" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=info msg="All jobs has finished" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).jobBatchManagement" file="/build/runtime_scan/pkg/scanner/job_managment.go:93" scanner id=f880455f-e909-4fa5-8d7f-2c38a92d66c2
time="2022-04-27T16:09:01Z" level=info msg="Succeeded to apply runtime scan results. app ids=[], failures=[Failed to scan image \"uk.icr.io/sbu-pipeline/zap2docker-stable:2.11.1-sbu\".\nEffected pods: newzap-owaspzap-zap-b9dc5f9d7-qbm44/mattzap.\nReasons: failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00': unable determine image source. Failed to scan image \"uk.icr.io/sbu-pipeline/nginx-unprivileged:1.21.4-alpine-sbu\".\nEffected pods: newzap-owaspzap-zap-b9dc5f9d7-qbm44/mattzap.\nReasons: failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2': unable determine image source.]" func="github.com/cisco-open/kubei/backend/pkg/rest.(*Server).startScan.func1" file="/build/backend/pkg/rest/runtime_scan_controller.go:255"

This is what shows in the UI:
Failed to scan image "uk.icr.io/sbu-pipeline/zap2docker-stable:2.11.1-sbu". Effected pods: newzap-owaspzap-zap-b9dc5f9d7-qbm44/mattzap. Reasons: failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/zap2docker-stable@sha256:6c9d3f2cc80470bb4b54fb4b402ff982905e5cb2f13648b571da37e277540f00': unable determine image source.
Failed to scan image "uk.icr.io/sbu-pipeline/nginx-unprivileged:1.21.4-alpine-sbu". Effected pods: newzap-owaspzap-zap-b9dc5f9d7-qbm44/mattzap. Reasons: failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/nginx-unprivileged@sha256:e86606220600fb7665e74453ca4e4b46a03215ea312e621c02809d2242a4bea2': unable determine image source.

So I've now done:
$ podman pull alpine:3.14.3
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:3.14.3...
Getting image source signatures
Copying blob 97518928ae5f done
Copying config 0a97eee804 done
Writing manifest to image destination
Storing signatures
0a97eee8041e2b6c0e65abb2700b0705d0da5525ca69060b9e0bde8a3d17afdb

$ podman tag alpine:3.14.3 uk.icr.io/sbu-pipeline/alpinetest:3.14.3

$ podman push uk.icr.io/sbu-pipeline/alpinetest:3.14.3
Getting image source signatures
Copying blob 1a058d5342cc done
Copying config 0a97eee804 done
Writing manifest to image destination
Storing signatures

And cleared down the namespace:
$ oc get secret -n mattzap | grep sbu
sbu-pipeline               kubernetes.io/dockerconfigjson        1      22m

$ oc get pod -n mattzap
No resources found in mattzap namespace.

Then I deploy:
$ oc create -f new-alpine-deployment.yaml
deployment.apps/alpine created
serviceaccount/alpine created

And pod starts, using the sbu-pipeline secret as imagePull:
$ oc get pod -n mattzap
NAME                      READY   STATUS    RESTARTS   AGE
alpine-74d9957b8d-gn4ct   1/1     Running   0          8s

And this is the deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: alpine
spec:
  selector:
    matchLabels:
      app: alpine
  replicas: 1
  template:
    metadata:
      labels:
        app: alpine
        version: "v3.14.3"
    spec:
      serviceAccountName: alpine
      imagePullSecrets:
      - name: sbu-pipeline
      containers:
        - name: alpine
          image: uk.icr.io/sbu-pipeline/alpinetest:3.14.3
          imagePullPolicy: IfNotPresent
          command: [ "sleep" ]
          args: [ "infinity" ]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: alpine

Logs show:
time="2022-04-27T16:28:57Z" level=info msg="Start scanning..."  func=github.com/cisco-open/kubei/shared/pkg/utils/k8s.GetMatchingSecretName file="/build/shared/pkg/utils/k8s/k8s_utils.go:71"
time="2022-04-27T16:28:57Z" level=info msg="Total 1 unique images to scan" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).initScan" file="/build/runtime_scan/pkg/scanner/scanner.go:255" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:28:57Z" level=debug msg="Created job=&Job{ObjectMeta:{scanner-alpinetest-1b21b6dc-1e25-45fa-a94f-5993c5109577  mattzap    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[app:scanner sidecar.istio.io/inject:false] map[] [] []  []},Spec:JobSpec{Parallelism:nil,Completions:nil,ActiveDeadlineSeconds:nil,Selector:nil,ManualSelector:nil,Template:{{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[app:scanner sidecar.istio.io/inject:false] map[] [] []  []} {[{tmp-volume {nil EmptyDirVolumeSource{Medium:,SizeLimit:<nil>,} nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil}}] [] [{vulnerability-scanner ghcr.io/cisco-open/kubeclarity-runtime-k8s-scanner:latest [] [scan --log-level debug]  [] [] [{RESULT_SERVICE_ADDR kubeclarity-kubeclarity.kubeclarity:8888 nil} {SBOM_DB_ADDR kubeclarity-kubeclarity-sbom-db.kubeclarity:8080 nil} {ANALYZER_LIST syft gomod nil} {ANALYZER_SCOPE squashed nil} {SCANNERS_LIST grype nil} {SCANNER_GRYPE_MODE REMOTE nil} {REGISTRY_SKIP_VERIFY_TLS false nil} {REGISTRY_USE_HTTP false nil} {SCANNER_REMOTE_GRYPE_SERVER_ADDRESS kubeclarity-kubeclarity-grype-server.kubeclarity:9991 nil} {SCANNER_REMOTE_GRYPE_SERVER_TIMEOUT 2m nil} {SCAN_UUID a3033112-a35d-4574-8532-4112bec76318 nil} {IMAGE_ID_TO_SCAN uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577 nil} {IMAGE_HASH_TO_SCAN 213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577 nil} {IMAGE_NAME_TO_SCAN uk.icr.io/sbu-pipeline/alpinetest:3.14.3 nil}] {map[cpu:{{1000 -3} {<nil>}  DecimalSI} memory:{{1048576000 0} {<nil>}  BinarySI}] map[cpu:{{50 -3} {<nil>} 50m DecimalSI} memory:{{52428800 0} {<nil>} 50Mi BinarySI}]} [{tmp-volume false /tmp  <nil> }] [] nil nil nil nil   Always &SecurityContext{Capabilities:&Capabilities{Add:[],Drop:[all],},Privileged:*false,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:*true,ReadOnlyRootFilesystem:*true,AllowPrivilegeEscalation:*false,RunAsGroup:nil,ProcMount:nil,WindowsOptions:nil,SeccompProfile:nil,} false false false}] [] Never <nil> <nil>  map[]   <nil>  false false false <nil> nil []   nil  [] []  <nil> nil [] <nil> <nil> <nil> map[] [] <nil> nil}},BackoffLimit:*0,TTLSecondsAfterFinished:*300,CompletionMode:nil,Suspend:nil,},Status:JobStatus{Conditions:[]JobCondition{},StartTime:<nil>,CompletionTime:<nil>,Active:0,Succeeded:0,Failed:0,CompletedIndexes:,UncountedTerminatedPods:nil,Ready:nil,},}" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).runJob" file="/build/runtime_scan/pkg/scanner/job_managment.go:164" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:28:57Z" level=info msg="Running job mattzap/scanner-alpinetest-1b21b6dc-1e25-45fa-a94f-5993c5109577 to scan imageID uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).runJob" file="/build/runtime_scan/pkg/scanner/job_managment.go:166" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:28:57Z" level=info msg="Waiting for result. imageID=uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).waitForResult" file="/build/runtime_scan/pkg/scanner/job_managment.go:135" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:29:06Z" level=info msg="Vulnerabilities result was set for imageID \"uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577\"" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).HandleScanResults" file="/build/runtime_scan/pkg/scanner/scanner.go:392" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:29:06Z" level=warning msg="Vulnerabilities scan of imageID \"uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577\" has failed: &{failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577': unable determine image source TBD}" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).HandleScanResults" file="/build/runtime_scan/pkg/scanner/scanner.go:399" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:29:06Z" level=info msg="Image scanned result has arrived. imageID=uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).waitForResult" file="/build/runtime_scan/pkg/scanner/job_managment.go:139" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:29:06Z" level=info msg="All jobs has finished" func="github.com/cisco-open/kubei/runtime_scan/pkg/scanner.(*Scanner).jobBatchManagement" file="/build/runtime_scan/pkg/scanner/job_managment.go:93" scanner id=531f4af4-60e3-4077-a0b1-5984b862e080
time="2022-04-27T16:29:06Z" level=info msg="Succeeded to apply runtime scan results. app ids=[], failures=[Failed to scan image \"uk.icr.io/sbu-pipeline/alpinetest:3.14.3\".\nEffected pods: alpine-74d9957b8d-gn4ct/mattzap.\nReasons: failed to analyze image: failed to run job manager: failed to run job: failed to create source analyzer=syft: could not fetch image 'uk.icr.io/sbu-pipeline/alpinetest@sha256:213d60a32697894f9a1dbe3f309a5b5a737266a1b7866594937038514ebdc577': unable determine image source.]" func="github.com/cisco-open/kubei/backend/pkg/rest.(*Server).startScan.func1" file="/build/backend/pkg/rest/runtime_scan_controller.go:255"

@mtcolman, thank you for the detailed information.
There are several checks that are being done for the image pull secret to make sure that it can be used:
https://github.com/cisco-open/kubei/blob/ea46fc3cbe0dc819e57c18511dc0c96bb24e48b2/shared/pkg/utils/k8s/k8s_utils.go#L49
From the code, I see that if the password and the username are both empty, the image pull secret is being ignore, disregarding the additional Auth property.
Can you please check if that's indeed the case in the sbu-pipeline secret.
There are some additional checks that the auth corresponds to the image, that might also cause the mismatch, but i'm doubted as K8s manages to pull the image and it uses the same pull secret code as we do.
The matching logic is tested in this unit test:
https://github.com/cisco-open/kubei/blob/ea46fc3cbe0dc819e57c18511dc0c96bb24e48b2/shared/pkg/utils/k8s/k8s_utils_test.go#L65
maybe you can add your specific structure to the unit test to see that it's matched. Also, we can test it if you can strip all sensitive information (e.g. replace with XXX) and share the secret json.
Thanks!!!

@akpsgit the username and password are both supplied in sbu-pipeline and this is validated by the fact the image can be pulled when the pod is deployed.

Here is the secret:
$ oc get secret sbu-pipeline -n mattzap -oyaml
apiVersion: v1
data:
  .dockerconfigjson: <base64-redacted-by-me>
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{".dockerconfigjson":"<base64-redacted-by-me>"},"kind":"Secret","metadata":{"annotations":{},"creationTimestamp":null,"name":"sbu-pipeline","namespace":"mattzap"},"type":"kubernetes.io/dockerconfigjson"}
  creationTimestamp: "2022-04-27T16:05:45Z"
  name: sbu-pipeline
  namespace: mattzap
  resourceVersion: "706789537"
  uid: da8364a4-d023-4281-a2a9-22b2b88bfaac
type: kubernetes.io/dockerconfigjson

Here is me showing the decoded base64:
$ echo -n <base64-redacted-by-me> | base64 -d
{"auths":{"uk.icr.io/sbu-pipeline":{"username":"iamapikey","password":"<redacted-by-me>","email":"unused","auth":"<base64-encoded-iamapikey:password>"}}}

@mmurhamm sorry for the inconvenience, it seems like that if you will use registry name uk.icr.io or the full target name uk.icr.io/sbu-pipeline/alpinetest in the image pull secret it will work.
We need to dig more to understand what was changes between the old logic and the new one.
{"auths":{"uk.icr.io":{"username":"iamapikey","password":"<redacted-by-me>","email":"unused","auth":"<base64-encoded-iamapikey:password>"}}}

OR
{"auths":{"uk.icr.io/sbu-pipeline/alpinetest":{"username":"iamapikey","password":"<redacted-by-me>","email":"unused","auth":"<base64-encoded-iamapikey:password>"}}}

Hi @mtcolman v2.2.0 just released, can we close the issue?

@FrimIdan tested and looks good, yes I believe you can close. Thanks for speedy fix.


Add methods.rst example to the documentation guidelines

To address review comments of #146 , it would be helpful to add a methods.rst example under docs/sphinx-guide/

Fixed by https://github.com/Qiskit/qiskit_sphinx_theme/pull/265


[docker-compose-update] Shows warning on test run

WARNING  root:docker_compose_update.py:377 Env variable DOCKER_HOST_NAME is not set, defaulting to hostname

No longer an issue


[multicast_dns] Exception thrown on calling client.start() on real iOS device: OSError (OS Error: Address already in use, errno = 48)

Is there an existing issue for this?

[x] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce

Run the provided code on a real iOS device.
Observe the exception being thrown.

Actual results
Issue Description
When running the following code on a real iOS device, the client.start() method is throwing an exception with the message OSError (OS Error: Address already in use, errno = 48). It works perfectly on the iOS simulator and real Android devices and emulators. It just wont work on real iOS devices.
Code Snippet
import 'package:multicast_dns/multicast_dns.dart';

Future<String?> findMdns() async {
  const String name = '_hyperiond-protobuf._tcp';
  final MDnsClient client = MDnsClient();

  await client.start();
  await for (final PtrResourceRecord ptr in client
      .lookup<PtrResourceRecord>(ResourceRecordQuery.serverPointer(name))) {
    await for (final SrvResourceRecord srv in client.lookup<SrvResourceRecord>(
        ResourceRecordQuery.service(ptr.domainName))) {
      await for (final IPAddressResourceRecord ip
          in client.lookup<IPAddressResourceRecord>(
              ResourceRecordQuery.addressIPv4(srv.target))) {
        return ip.address.address;
      }
    }
  }
  client.stop();
  return null;
}

Logs
No response
Flutter Doctor output

Doctor output

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.13.8, on macOS 14.0 23A344 darwin-arm64, locale en-NL)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.3)
[✓] VS Code (version 1.83.1)
[✓] Connected device (3 available)
[✓] Network resources

• No issues found!

Hi @SylberG
I can run the example normally without issue on my physical iOS device. Taking look at your flutter doctor output, there is an issue with your connection to device. Please make sure there is no issue and retry.

Hi @SylberG I can run the example normally without issue on my physical iOS device. Taking look at your flutter doctor output, there is an issue with your connection to device. Please make sure there is no issue and retry.

Hi @huycozy ,
After updating my iPhone 12 Pro to the latest version 17.0.3, the flutter doctor output appears clean with no apparent issues. However, despite this update, the problem persists. To investigate further, I retrieved an old iPhone 7 from my drawer. Testing it with iOS version 15.7.9, and it functions perfectly on this device.

I'm also using iPhone 7, iOS 15.7.9, and don't see the issue there. I don't have a newer device/iOS version to check this.
Could you share the multicast_dns package version in use and the entire output exception?

I'm also using iPhone 7, iOS 15.7.9, and don't see the issue there. I don't have a newer device/iOS version to check this.
Could you share the multicast_dns package version in use and the entire output exception?

I am using multicast_dns: ^0.3.2+4
And this is the output of the catch/exception:
Restarted application in 613ms.
flutter: Exception: OS Error: Address already in use, errno = 48
flutter: Stack trace: #0      _NativeSocket.nativeJoinMulticast (dart:io-patch/socket_patch.dart:1793:68)
#1      _NativeSocket.joinMulticast (dart:io-patch/socket_patch.dart:1712:5)
#2      _RawDatagramSocket.joinMulticast (dart:io-patch/socket_patch.dart:2589:13)
#3      MDnsClient.start
<asynchronous suspension>
#4      findMdns
<asynchronous suspension>
#5      HyperionDeviceCubit.detectHyperion
<asynchronous suspension>

Although it presents differently, this is technically the same issue as https://github.com/flutter/flutter/issues/78937, so closing as a duplicate.

Although it presents differently, this is technically the same issue as https://github.com/flutter/flutter/issues/78937, so closing as a duplicate.


Add Awesome list to Pixel Art Tools

Thank you for contributing! Please confirm this pull request meets the following requirements:

[x] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md
[x] I have no affiliation with the project I am suggesting (as a maintainer, creator, contractor, or employee).

Which change are you proposing?

[x] Suggesting edits to an existing topic or collection
[ ] Curating a new topic or collection

Editing an existing topic or collection
I'm suggesting these edits to an existing topic or collection:

[ ] Image (and my file is *.png, square, dimensions 288x288)
[x] Content (and my changes are in index.md)

An Awesome list of pixel art with tutorials and inspirations such as games and artists.

Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

I noticed this repository is already in a topic (Awesome List). And that is not a tool, but a reference!


[Bug Report] Tree Component check-strictly=true select parent node faild

Element UI version
1.4.0
OS/Browsers version
Chrome 56
Vue version
2.4.2
Reproduction Link
https://jsfiddle.net/fxa075uL/
Steps to reproduce
checked all children node except they parent.
then you can't select the parent node.
What is Expected?
the parent node can be checked when i checked all children node
What is actually happening?
the parent node can't be checked when i checked all children node

Fixed in #6034. Will be available this week.


chore(main): release 8.4.1

:robot: I have created a release beep boop
8.4.1 (2024-10-16)
Bug Fixes

custom tools and slash commands fail to load (0f2e8de)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v8.4.1
:sunflower:


Update contract example

Codecov Report

Merging #115 into release-0.2 will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release-0.2     #115   +/-   ##
==============================================
  Coverage          39.62%   39.62%
  Complexity           599      599
==============================================
  Files                140      140
  Lines               4422     4422
  Branches             324      324
==============================================
  Hits                1752     1752
  Misses              2542     2542
  Partials             128      128

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 12e8819...b341f67. Read the comment docs.


tarpaulin stopped working for veloren

Hi xd009642,
Veloren stopped working with tarpaulin a few weeks ago.
And i am investigating what caused this problem.
I am currently debugging tarpaulin and wonder if i found a bug.
Situation.
When you compile veloren (steps to reproduce below) you'll see that the compilcation will never finish. it will just halt.
I attached gdb to my local cargo-tarpaulin, wait for it to get stuck and i'll see:
(gdb) bt
#0  0x00007ffff7a2feaa in wait4 () from /usr/lib/libc.so.6
#1  0x000055555639b270 in std::sys::unix::process::process_inner::Process::wait::{{closure}} () at src/libstd/sys/unix/process/process_unix.rs:438
#2  std::sys::unix::cvt_r () at src/libstd/sys/unix/mod.rs:152
#3  std::sys::unix::process::process_inner::Process::wait () at src/libstd/sys/unix/process/process_unix.rs:438
#4  std::process::Child::wait () at src/libstd/process.rs:1394
#5  0x00005555559a80ff in cargo_tarpaulin::cargo::run_cargo (metadata=0x7fffffff4e28, manifest=..., config=0x55555681c9f0, ty=..., result=0x7fffffff4df0) at src/cargo.rs:160
#6  0x00005555559a6eb9 in cargo_tarpaulin::cargo::get_tests (config=0x55555681c9f0) at src/cargo.rs:116
#7  0x00005555558b83ab in cargo_tarpaulin::launch_tarpaulin (config=0x55555681c9f0, logger=0x7fffffff6cd8) at src/lib.rs:144
#8  0x00005555558b50e9 in cargo_tarpaulin::trace (configs=...) at src/lib.rs:65
#9  0x00005555558b6593 in cargo_tarpaulin::run (configs=...) at src/lib.rs:100
#10 0x00005555556a5125 in cargo_tarpaulin::main () at src/main.rs:194

Line 5 suggests its stuck in src/cargo.rs:160.
Looking at the code: https://github.com/xd009642/tarpaulin/blob/develop/src/cargo.rs#L160
Okay my guess is, that tarpaulin just calls the system cargo here, and tarpaulin does just wait on cargo. So maybe the problem is not with tarpaulin but with cargo ???
Okay, i want to investigate further and analyse what cargo is doing. so i grap the PID from the child and attach a gdb there:
Sep 29 14:30:05.716 TRACE cargo_tarpaulin::cargo: Running command "cargo" "test" "--no-run" "--message-format" "json" "--manifest-path" "/mnt/nfs/marcel/Entw/Rust/veloren/Cargo.toml" "--tests" "-vvv" "--target-dir" "/mnt/games/cargo-build/"
[Detaching after vfork from child process 167525]

GDB of the 2nd process, the cargo process:
^C
Thread 1 "cargo" received signal SIGINT, Interrupt.
0x00007ffff7e99f9f in write () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7e99f9f in write () from /usr/lib/libc.so.6
#1  0x0000555555fc9e6d in std::sys::unix::fd::FileDesc::write () at library/std/src/sys/unix/fd.rs:139
#2  <std::sys::unix::stdio::Stdout as std::io::Write>::write () at library/std/src/sys/unix/stdio.rs:38
#3  <std::io::stdio::StdoutRaw as std::io::Write>::write () at library/std/src/io/stdio.rs:117
#4  <std::io::buffered::BufWriter<W> as std::io::Write>::write () at library/std/src/io/buffered.rs:758
#5  <std::io::buffered::LineWriterShim<W> as std::io::Write>::write () at library/std/src/io/buffered.rs:1003
#6  <std::io::buffered::LineWriter<W> as std::io::Write>::write () at library/std/src/io/buffered.rs:1396
#7  <std::io::stdio::StdoutLock as std::io::Write>::write () at library/std/src/io/stdio.rs:642
#8  0x0000555555fc97c7 in <&std::io::stdio::Stdout as std::io::Write>::write () at library/std/src/io/stdio.rs:616
#9  <std::io::stdio::Stdout as std::io::Write>::write () at library/std/src/io/stdio.rs:590
#10 0x000055555584137a in <termcolor::LossyStandardStream<W> as std::io::Write>::write ()
#11 0x0000555555811dc5 in std::io::Write::write_all ()
#12 0x0000555555714b81 in <std::io::Write::write_fmt::Adaptor<T> as core::fmt::Write>::write_str ()
#13 0x0000555555fff13c in core::fmt::write () at library/core/src/fmt/mod.rs:1080
#14 0x0000555555812105 in std::io::Write::write_fmt ()
#15 0x000055555594a466 in cargo::core::compiler::job_queue::DrainState::drain_the_queue ()
#16 0x00005555558510b3 in std::panic::catch_unwind ()
#17 0x00005555557c9197 in crossbeam_utils::thread::scope ()
#18 0x0000555555948195 in cargo::core::compiler::job_queue::JobQueue::execute ()
#19 0x0000555555794c7f in cargo::core::compiler::context::Context::compile ()
#20 0x0000555555726bdc in cargo::ops::cargo_compile::compile_ws ()
#21 0x000055555572693e in cargo::ops::cargo_compile::compile ()
#22 0x0000555555addd22 in cargo::ops::cargo_test::compile_tests ()
#23 0x0000555555adaadf in cargo::ops::cargo_test::run_tests ()
#24 0x00005555556be3fd in cargo::commands::test::exec ()
#25 0x00005555556da8e2 in cargo::cli::main ()
#26 0x0000555555677008 in cargo::main ()
#27 0x00005555556ca223 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#28 0x00005555556ca489 in std::rt::lang_start::{{closure}} ()
#29 0x0000555555fd93e0 in core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once () at /rustc/623fb90b5a1f324e0ec44085116bf858cef19a00/library/core/src/ops/function.rs:259
#30 std::panicking::try::do_call () at library/std/src/panicking.rs:381
#31 std::panicking::try () at library/std/src/panicking.rs:345
#32 std::panic::catch_unwind () at library/std/src/panic.rs:382
#33 std::rt::lang_start_internal () at library/std/src/rt.rs:51
#34 0x0000555555679b32 in main ()

and i'll see that the cargo process started by tarpaulin is waiting on some write.
Which sounds really strange to me. I checked my harddrive, but it's not writing to disk. also in line 8 i see stdio which lets me to my hypothesis: Running the cargo command manually, also finished. but running it from tarpaulin doesn't finish. which seems super weird to me.
tarpaulin starts cargo and waits for its result.
cargo wants to write something in a pipe back to tarpaulin. but this pipe is full. cargo waits for this pipe is cleared.
tarpaulin doesn't read from the pipe but wants to wait till the process is finished...
Voila we got a deadlock.
this would only occur on big projects (like veloren is) and could be solved by tarpaulin not just waiting, but also storing the stdio somewhere.
Do you think that could be a realistic root cause ?

That does sound like a potential issue, I'd have to double check the docs but given there it's returning with an error it should be okay to not wait and just let the child be dropped, it should detach on drop and then any pipes will close and we won't be left with a zombie (I think).

Oh sorry. i forgot to add the steps to repdoduce.
So it does not fail. It just generates a HUGE output. Thats why the child will never be dropped.
So here's how to reproduce.

Grab veloren https://gitlab.com/veloren/veloren and checkout xMAC94x/fix-tarpaulin. save this in /tmp/veloren.
run

cargo" "test" "--no-run" "--message-format" "json" "--manifest-path" "/tmp/veloren/Cargo.toml" "--tests" "-vvv"

it works.
3. run tarpaulin. It will hang forever.

So I'll try to look at this properly later in the week or the weekend. But my suggestion was more along the lines of deleting the call to wait  at https://github.com/xd009642/tarpaulin/blob/develop/src/cargo.rs#L160 and wondering if that could just solve all the issues just through what happens when a Command is dropped 🤔

@xd009642  i created a minimal reproduction scenario (just include vek with platform_intrinsics
https://github.com/xMAC94x/testtarpaulin
it shows additional logs with the PR i just created.

well the issue is -C link-dead-code not working with vek. I wonder if this is an issue that should be raised in the compiler :thinking: as for the hang I'm going to work on a solution. For the meantime with veloren I guess the easiest solution would be to make platform_intrinsics an optional (still can be a default feature) and then run tarpaulin without that feature enabled.

sounds reasonable.
But do you know how to change:
vek = {version = "0.12.0", features = ["platform_intrinsics", "serde"]}
so, hat serde is always requiered, but platform_intrinsics is depending on a feature ?
Btw the MR i created traces the information, it might make sense for other people that face similar issues to get more information that just a endless wait.

I don't know how to solve that feature issue, a quick google pointed me towards an RFC so it might not be possible. Also, the fix I'm working on changes the bit of code where your PR is and might make it unneeded, I was just going to run some tests first :eyes:

I've pushed a change to cargo_hang I need to figure out a bit more since the error logs I added for debugging didn't happen as I'd expect :thinking: but if you want to try it locally and confirm it "fixes" things on veloren regarding the hang. Also, I raised this issue https://github.com/rust-lang/rust/issues/77529

@xd009642  just tested it, the branch cargo_hang fixes the endless loop situation but the error still exists.
Thanks for opening the issue :)

Cool I'll merge in cargo_hang then and just keep this issue open to remind me to keep checking up on the dead-code issue :+1:

Thanks for fixing this! Any recommendations on the best way to get this into a repo (maybe a release)? (e.g. https://github.com/rust-bio/rust-bio/issues/374 is potentially caused by this)

I can always do a release this week. Or there are tarpaulin docker images built against the develop branch or cargo can install given a git URL and branch name. If I have some time tonight I'll try to look at your repo and find out which features cause the issue

Cool, thanks. It's probably not a big deal to go one of those ways if you can't do a release in the intermediate. The package uses the rust github action to install tarpaulin, so being able to go that way but would be nice, but like you mention, several workarounds.

It seems like we no longer have the timeouts over at rust-bio. But we do have a compilation error of tests, now, that only occurs when using tarpaulin and not when using regular cargo test. So it could be that this error simply triggers before any timeout.

@dlaehnemann  IIRC tarpalin was fixed so that it no longer deadlocks on this error (for us it was a deadlock, not a timeout). And we have a similar error in our pipeline now, i think the rustlang error posted above is a reason for this error

@xMAC94x just released a new version of tarpaulin, if you could let me know if there are any issues with it and veloren :smile:

Closing this issue as the llvm coverage backend is now released as an alternative and there haven't been any updates here in over a year (as always feel free to reopen if it's been closed in haste)

Closing this issue as the llvm coverage backend is now released as an alternative and there haven't been any updates here in over a year (as always feel free to reopen if it's been closed in haste)

Is -C link-dead-code not necessary or less important with the llvm coverage backend? Asking since it seems to be implied but I haven't found any information on this.


{Service Connector} add new client type: dotnet-interal

Related command

Description

Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Service Connector

hi @kairu-ms, the pr is ready for review, can you please help?


Documentation is Out of Date

The chart with the supported VM sizes is out of date. As per this newer document for the VM size, https://docs.microsoft.com/en-us/azure/virtual-machines/nva10v5-series, the NVadsA10 v5-series does support Ultra disk, and the older Ultra Disk document, the one I'm leaving feedback on here, does not show this series in the chart. I also reported this for the https://docs.microsoft.com/en-us/azure/virtual-machines/disks-enable-ultra-ssd?tabs=azure-portal#cli document as well.

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

ID: 1b4f48bd-e5e9-ebca-e29e-9dec927bc2d3
Version Independent ID: 2e032831-dbb6-aaf2-15ce-ac072ef36727
Content: Select a disk type for Azure IaaS VMs - managed disks - Azure Virtual Machines
Content Source: articles/virtual-machines/disks-types.md
Service: storage
Sub-service: disks
GitHub Login: @roygara
Microsoft Alias: rogarana

@camaier Thanks for the question! We are investigating and will update you shortly.

Closing, as a duplicate of https://github.com/MicrosoftDocs/azure-docs/issues/95613
#please-close


The screen is not responsive.

I disregard eye-glasses, despite my miopy.  In contrast, I magnify the Screen Desktop, as well the zoom in Browser too. Consider apply changes in your CSS.

@GiovanniHD201E What's up with the Issue ^^?
Wrong Repository?

Friend, what page are you referring to? There's no CSS or layout involved in this repository, so we're a little confused.


[don't merge] debug ci issues

PR to fix ci issues - will delete manually when done

TODO: Close this PR after #11140 is merged

Closing this PR because https://github.com/celo-org/celo-monorepo/pull/11140 is merged ✅


A lot of warnings

A lot of warnings come from line search (branch issue24)
┌ Warning: Function change is too small, using parabolic approximation
│   Δyp = -5.078140390443264e-9
│   Δy = -5.077506415318567e-9
└ @ Downhill ~/.julia/dev/Downhill/src/linesearch.jl:70
┌ Warning: Function change is too small, using parabolic approximation
│   Δyp = -4.152333226039501e-9
│   Δy = -4.15183620816606e-9
└ @ Downhill ~/.julia/dev/Downhill/src/linesearch.jl:70
┌ Warning: Function change is too small, using parabolic approximation
│   Δyp = -3.3793413183067366e-9
│   Δy = -3.3790215070439444e-9
└ @ Downhill ~/.julia/dev/Downhill/src/linesearch.jl:70
┌ Warning: Function change is too small, using parabolic approximation
│   Δyp = -2.7361828176819865e-9
│   Δy = -2.7360016474631266e-9
└ @ Downhill ~/.julia/dev/Downhill/src/linesearch.jl:70

Must be fixed by #27

Fixed by #27


feat: Expand grafana dashboard, bump to schemaVersion 38

Description

Relates to https://github.com/kubewarden/policy-server/issues/597

Bump dashboard to schemaVersion 38, from Grafana vesion 10.2.0.
Filter the preexisting visualizations with request_origin="validate".
Add new visualizations pertaining audit requests, filtering with request_origin="audit".
Leave latency, pod visualizations untouched.

Test

Tested by deploying grafana with docker compose, and editing the dashboard via the UI. The UI has a linter and informs if the queries fail to parse or are invalid.
Still would be good to test it against an audit scanner + opentelemetry deployment.

Additional Information
Tradeoff

Potential improvement

This is the current version. Tested it against a full deployment.


About Firebase

I've noticed that there are Firebase related configurations in FlutterFlow. Are there any tutorials on how to configure it? Or can I just create a Firebase project with the default settings? Additionally, I hope it can support Supabase because it allows for self-hosting. Thanks. :)

Hi, the App with Wearable no longer has Firebase Integration for simplicity

Hey @ZeusFunk - removed it for simplicity


update: implement a responsive navigation bar for React site

This pill request will close this issue.
This PR will use CSS media queries to make the navigation bar follow the Responsive Web Designs. The hamburger icon will be displayed when the device resolution falls below a 640px width.

Thanks.
I have changed the branch


Update Reviewers/Approvers for localized READMEs

This is a Feature Request
What would you like to be added

Update Reviewers/Approvers for localized READMEs

Why is this needed
k/website repository has localized READMEs, but the ownership of these files belongs tosig-docs-website-owners, not to l10n teams.
https://github.com/kubernetes/website/blob/b2c8d81871f543c6506829db8a520faf55cb183f/OWNERS#L3-L7
This means that when we update a localized README, the PR is assigned to sig-docs-website-owners as reviewers / approvers, not to l10n reviewers. (e.g., https://github.com/kubernetes/website/pull/46256)
I think these PRs should be assigned to and approved by l10n teams.
Comments

/area localization

/assign

cc @seokho-son @a-mccarthy

Hi @Okabe-Junya :)
Thank you for bringing up this issue. To implement this, we need to assign individual OWNERS for each README-xx.md file. However, since we currently utilize directory-based OWNERS, it’s challenging to assign separate l10n OWNERS for the README-xx.md files located at the root path.
My suggestion is to move the README-xx.md files into an internal directory, so that they can be managed by the l10n reviewers/approvers. (Creating new directories is not ideal from an OWNERS file management perspective, so I would prefer to avoid that.)
Perhaps moving them to /data/i18n/xx (i.e., https://github.com/kubernetes/website/tree/main/data/i18n/ja) or /content/xx (i.e., https://github.com/kubernetes/website/tree/main/content/ja) would be a good solution. Then, we can update the links to the localized README files in the root README.md.
What do you think? :)

Thanks, @seokho-son!
I have already worked on this issue and resolved it by using the "filter" feature of the OWNERS file – there is no need to move the README-*.md files.

Opened PR: https://github.com/kubernetes/website/pull/47763/files
(FYI) Filters feature: https://www.kubernetes.dev/docs/guide/owners/#filters

An (unofficial) review has already been conducted, and it seems to be working well :) Any thought? Thanks!

However, (though unrelated to this issue) I think it would be a good idea to mov localized READMEs directories.
Just IMO, I'm not a fan of having too many files in the root of the repository – especially if many of those files are irrelevant to most people.

@Okabe-Junya
I agree with your opinion. :)

Just IMO, I'm not a fan of having too many files in the root of the repository – especially if many of those files are irrelevant to most people.

Additionally, even though we now have the "filter" feature for the OWNDERS file, I'm not in favor of managing many filter options within the OWNDERS file either. I believe this could also lead to maintenance issues. Considering this, I would prefer to move the README-xx.md files to other existing directories managed by the l10n teams.

#47763

Thank you for the good feedback! Your insights are always wonderful and helpful to us, and me!
To make it easier to track, let’s continue the discussion in the PR :)


Inverse the bootstrap option from prep.sh

With the removal of the runtime portable build, you must now run prep.sh --bootstrap if you are running on a rid that does not match the rid of the previous source-built artifacts Microsoft provides.  Right now these are CentOS Stream 9 based in the main branch.  Given the canonical usage of prep.sh now requires the bootstrap option, the behavior should be inverted so the option is the default behavior.
The long term plan is for source-build to support portable builds at which point the Microsoft artifacts would be portable so that they can be used to build and bootstrap a wide range of distros.

[Triage] After discussing this, we feel it would be best to have prep.sh always run the bootstrap flow and not provide an option to opt out.


Name change suggestion despite preserveTags?

URL
https://www.openstreetmap.org/edit?node=5579307932
How to reproduce the issue?
After clicking the link, iD suggests changing the name.
Screenshot(s) or anything else?
Originally posted by @kjonosm in https://github.com/osmlab/name-suggestion-index/issues/6085#issue-1105024965
I get a suggestion to also change the name of an office=association despite preserveTags being set in NSI, see screenshot.

Expected behavior
The name should not get suggested to be changed, similarly to how brands for tourism=hotel also preserve names.
Which iD Editor versions do you see the issue on?
Released version at openstreetmap.org/edit
Which browsers are you seeing this problem on?
No response

:thinking:
As far as I can tell, it works as intended:
The nsi entry defines its own preserveTags on line 73, which doesn't include the name tag. This overwrites the value specified for the nsi category (defined on line 4). The NSI documentation isn't super clear if the values for  preserveTags should be combined in such cases or not, but since @bhousel wrote the code of this module in iD, I would assume the way iD handles it is correct. FWIW, the way it is implemented in iD does make sense, because otherwise there would be no way for an nsi entry to override any preserveTags value set as default for the whole category.

Yes thanks for investigation @tyrasd , this is indeed working as intended - it looks like the preserveTags properties should be adjusted in the NSI data.


Rule-based overrides for log configs

Add capability of doing rule-based (currently only exact match) override of log configs
Can be done by setting configOverrideDir in singer.properties and have property files in that directory with match.config.name set to the config name to be matched, and match.config.value to the config value; add override. prefix to the configs that need to be overriden

Can you add an example in the description to show the impact of this change?


Error converting value "ERR_INVOKE_ACTOR" to type 'System.Nullable

Expected Behavior
i expected my program running correctly
Actual Behavior
whenever run，it's throw an error like this :
Error converting value "ERR_INVOKE_ACTOR" to type 'System.Nullable`1[Dapr.Actors.DaprErrorCodes]
Steps to Reproduce the Problem
i think the class "DaprErrorCodes" missing enumeration for "ERR_INVOKE_ACTOR"

@i542873057  Are you still seeing the issue with new dapr release and new nuget packages


Format and fix README

This pull request updates and fixes the README. The changes are as follows:

Move to markdown
Update OS name (Mac OS X -> macOS)
Format to markdown and fix all URLs

RWMIDI is grabbed with wayback machine due to the website no longer being available.

Change all compatible urls to HTTPS
Format commands into table

@corbanbrook Is there anything I need to fix?

@corbanbrook Is there anything I need to fix?


Added LogMeIn.LastPass v<IP_ADDRESS>5

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

This requires Administrator https://github.com/microsoft/winget-cli/issues/152, but since it was already added i'm just updating it


ensemble numpass confusion

When running ensemble variant calling using "numpass: 1" I notice that variants identified by only one caller but which fail filters still become included in the final call as PASS. Perhaps true also for higher numpass settings? Is this by intention? if so, the name of the setting (numpass) becomes somewhat confusing.
Information that would be great to have in the ensemble vcf  INFO field is also what callers that actually picked up a variant.
cheers, Pär

Pär;
Sorry about the confusion with this. For calling on germline samples, the current approach in bcbio is to keep filtered samples with the idea of providing evidence in cases where a caller "almost" identifies a variant to support a place where it is called in another caller. When validating with a larger number of callers (3+) this helped improve sensitivity.
Practically though, I've been contemplating deprecating ensemble calling for germline samples. FreeBayes and HaplotypeCaller are quite good and the ensemble only provides a small improvement over them at the cost of more complex integration maintenance and fixes.
In your case specifically, numpass: 1 setting would basically take a union of all called variants including pulling in all false positives from all callers. Is this your intention with this setting? I'm just trying to understand the use cases and decide the best plan moving forward.
For somatic calling, we currently still find value in ensemble validations and remove filtered variants as leaving them in keeps a lot of germline noise. Longer term, we're hoping to evaluate and move to another ensemble callers like SomaticSeq (https://github.com/bioinform/somaticseq) to continue to contribute to other open source projects.
Happy to hear your thoughts and hope this helps some with current thinking on ensemble calling.

Hi Brad,
Here at Umeå University Hospital, Sweden, We're using bcbio-nextgen for clinical variant calling of germline variants using a Haloplex panel. Variants likely to be disease-causing are first checked by visual inspection of the alignments and later also confirmed by Sanger. So, I'm more afraid of false negatives (poor sensitivity) than of false positives. But It's true that "numpass 1" gives many false positives, so I've actually switched to "numpass 2" (four callers).
A general problem for most labs (if not all) in this area is availability of well-characterized reference materials. Although we have validated the pipeline against samples where we also have Sanger data. My opinion is, however, that these validation sets are too small and It's better to be on the safe side and generate false positives that are filtered out downstream rather than missing something potentially important.
I've made a system here that integrates bcbio-nextgen with a local variant database and Alamut, a tool use by most clinical genetics labs for interpretation I believe. The system annotates the variants using various dbs, including the local, and generates a report in excel format that includes all variants relevant to the medical hypothesis/indication (based on gene lists), other relevant qc information, and provenance. Hyperlinks in the excel sheets then allows us to quickly open bam files and regions for assessment of variants and quality. Simplistic but it works. Planning to put everything on github and submit a paper.

Pär;
Thanks much for the details, this helps so much in understanding your use case. I'd still like to think about larger scale validations to determine the utility of ensemble, but it seems like we can try a few tweaks to improve your workflow now:

Not trying to "rescue" filtered variants and remove those by default from the ensemble overlaps.
Doing full scale benchmarking of this to be sure ensemble is performing better in sensitivity than individual callers with this tweak.
Adding in information about supported callers in the final ensemble VCF.

The clinical reporting system is really interesting and I know would be of use to many users with similar needs. I'd love to include links to it from the documentation when it's available and also happy to try and make changes to bcbio to fit better with this type of downstream annotation and reporting. Thanks again.

Brilliant! We are really grateful for your help and effort!
Maybe "rescuing" is still a good idea if details were provided in the INFO field on the filters?
Yes, I figured that others might be interested in the clinical interpretation / reporting system as well. There are some other alternatives out there (Scout from Scilife for example), each with their own merits and limitations. Alamut integration was important for us, and flexibility. Diversity is a good thing I guess.

Pär, a +1 for me for being excited about the clinical reporting code be made available. Even if it's just a starting point it would make clinicians happy here in Glasgow/NHS.

We'd like to have a look at it, too, +1

@ohofmann @schelhorn @chapmanb: Thanks for your interest. We're using it in production but I have some tidying up and documentation to take care of for repo. Will let you know when when things are ready.

Pär;
Apologies about the delay in finalizing this but the latest development version of bcbio now avoids trying to "rescue" filtered variants for germline and annotates ensemble calls with a CALLERS tag that indicates the supporting callers. If you update with:
bcbio_nextgen.py upgrade -u development --tools

Hope this provides what you need and please let us know if you have any problems at all. Thanks again and looking forward to talking more about the reporting system when that's ready.

Muchas gracias! Will test asap!
Working on cleaning up the code for the reporting system and documentation. Will let you know as soon as things are reasonably tidy.

Pär


Fix JellyPlayer info in CLIENT.MD

Fix JellyPlayer info

Hello @prayag17, thank you for your contribution!
However, the CLIENTS.md file is automatically generated from the clients.yaml. Can you please revert the change from the CLIENTS.md and fix the spelling directly in the clients.yaml - Thank you! :)


Custom brushes get drawn outside of selection

When the users have selected a part of the sprite, they can only draw inside of that part when using the normal pixel brush. However, I haven't managed to do the same with custom brushes because they are images that are being added to the main image layer, and not individual pixels like the pixel brush. As such, I'm not sure how to restrict the brush image's pixels to only draw inside the selection.

Resolved as of 420ec63aeb82258f097c845c3880d5558bd0df50

Still doesn't work if the selection is smaller than the brush.

Resolved as of e18389d8c42a9a088bd7d609b44eb14f8560331a. For real this time, I hope.


Impossible to connect locally to a distributed database but work with remote engine

OrientDB Version: 3.1.5
Java Version: <IP_ADDRESS>
OS: Debian 10.7 (Buster)
Expected behavior
OrientDB console v.3.1.5 - Veloce (build 846eeb77dcb175a9fbd7ed534e039424322f44a7, branch 3.1.x) https://www.orientdb.com
Type 'help' to display all the supported commands.
orientdb> CONNECT embedded:../databases/HUB admin **********

Connecting to database [embedded:../databases/HUB] with user 'admin'...OK
orientdb {db=HUB}>

Actual behavior
OrientDB console v.3.1.5 - Veloce (build 846eeb77dcb175a9fbd7ed534e039424322f44a7, branch 3.1.x) https://www.orientdb.com
Type 'help' to display all the supported commands.
orientdb> CONNECT embedded:../databases/HUB admin *********
Warning: Nashorn engine is planned to be removed from a future JDK release

Connecting to database [embedded:../databases/HUB] with user 'admin'...
Error: com.orientechnologies.orient.core.exception.ODatabaseException: Cannot open database 'HUB'

Error: java.lang.RuntimeException: java.nio.file.AccessDeniedException: /orientdb/bin/../databases/HUB/HUB.wmr

Error: java.nio.file.AccessDeniedException: /orientdb/bin/../databases/HUB/HUB.wmr

orientdb {server=embedded:../databases/HUB}>

Steps to reproduce

Launch 3 distributed nodes with MASTER/MASTER replication
On one of them go to the web console and then create a new database.
You should now be able to access it with /$ORIENTDB_HOME/bin/console.sh on every nodes of the replication set and can execute CONNECT embedded:../databases/<YOUR_DATABASE> <USER> <PASSWORD> wich are by default admin/admin

You cannot connect to an open database (by the server running distributed). The only way is to use remote, or stop the server and you can connect as embedded.


Sorted the cards in alphabetical order.

Fixes Issue
Closes #55

Proposed Changes

Screenshots
Image 1:

Image 2:

Image 3:

Notes for Reviewers

@Ameya02, Please check