text:
run_tv_casting_test.py is flaky for commissioner generated passcode

In CI, it seems like python3 ./scripts/tests/run_tv_casting_test.py --commissioner-generated-passcode=True is flaky.
Example:
https://github.com/project-chip/connectedhomeip/actions/runs/10148134972/job/28060156339
Error seems timeouts on
TestStepException: commissioner_generated_passcode_test - Did not find the expected output string(s) in the tv-app subprocess within the timeout: ['Commissioner Declaration Start', 'commissioner passcode: true', 'Commissioner Declaration End']

from the application logs, sometimes all the strings are missing and sometimes only a subset of strings are missing.

All the errors I find so far seems to be related to BLE, which TV Casting should be using at all:
ERROR - [1722271704.592] [6919:6921] [DL] FAIL: Get D-Bus system bus: Could not connect: No such file or directory
ERROR - [1722271704.592] [6919:6919] [DL] Disabling CHIPoBLE service due to error: src/platform/Linux/bluez/BluezObjectManager.cpp:169: CHIP Error 0x000000AC: Internal error

ERROR - > [1722271705.108] [6923:6923] [DL] Long dispatch time: 503 ms, for event type 2
ERROR - [1722[271](https://github.com/project-chip/connectedhomeip/actions/runs/10148134972/job/28060156339#step:9:272)705.110] [6923:6927] [DL] FAIL: Get D-Bus system bus: Could not connect: No such file or directory
ERROR - [1722271705.110] [6923:6923] [DL] Disabling CHIPoBLE service due to error: src/platform/Linux/bluez/BluezObjectManager.cpp:169: CHIP Error 0x000000AC: Internal error

Final error:
TestStepException: commissioner_generated_passcode_test - Did not find the expected output string(s) in the tv-app subprocess within the timeout: ['Commissioner Declaration Start', 'commissioner passcode: true', 'Commissioner Declaration End']

source: gharchive/issue

repo: project-chip/connectedhomeip

license_type: permissive

license_source: github-api


text:
chip-tool api has been changed?

Hi,  I am very new to CHIP and I am excited about it.
I tested it on two raspaberry pi 4b for lighting-app.

Refer to  the
link, I built the chip-lighting-app on PI-2:

ubuntu@pi-2:~/git/connectedhomeip/examples/lighting-app/linux$ sudo out/debug/chip-lighting-app --ble-device 1
SetupPINCode: [12345678]
SetupQRCode:  [CH:I34DV*700 0C9SS0]
CHIP:ZCL: Using ZAP configuration...
CHIP:ZCL: deactivate report event
CHIP:IN: TransportMgr initialized
CHIP:IN: local node id is 12344321

CHIP:DL: wpa_supplicant: _IsWiFiStationProvisioned: interface not connected
CHIP:BLE: Waiting for PBKDF param request
CHIP:DIS: CHIP minimal mDNS configured as 'Commisioning device'.
CHIP:DIS: CHIP minimal mDNS started advertising.
CHIP:DIS: Replying to DNS-SD service listing request
CHIP:DIS: Broadcasting mDns reply
CHIP:DIS: Broadcasting mDns reply
CHIP:DIS: Replying to DNS-SD service listing request
CHIP:DIS: Broadcasting mDns reply
CHIP:DIS: Broadcasting mDns reply
CHIP:SVR: Server Listening...
CHIP:DL: TRACE: Bluez mainloop starting Thread
CHIP:DL: TRACE: Bus acquired for name CHIP-3840
CHIP:DL: CREATE service object at /chipoble/2d19/service
CHIP:DL: Create characteristic object at /chipoble/2d19/service/c1
CHIP:DL: Create characteristic object at /chipoble/2d19/service/c2
CHIP:DL: CHIP BTP C1 /chipoble/2d19/service
CHIP:DL: CHIP BTP C2 /chipoble/2d19/service
CHIP:DL: CHIP_ENABLE_ADDITIONAL_DATA_ADVERTISING is TRUE
CHIP:DL: Create characteristic object at /chipoble/2d19/service/c3
CHIP:DL: rotatingDeviceId: 00007C5F6E176CD40F68685D100A1CF8A98B
CHIP:DL: CHIP BTP C3 /chipoble/2d19/service
CHIP:DL: PlatformBlueZInit init success
CHIP:DL: BluezPeripheralRegisterAppDone done
CHIP:DL: HandlePlatformSpecificBLEEvent 16391
CHIP:DL: Create adv object at /chipoble/2d19/advertising
CHIP:DL: SET service data to {'0xFEAF': <[byte 0x00, 0x00, 0x0f, 0x5a, 0x23, 0xff, 0xfe]>}
CHIP:DL: HandlePlatformSpecificBLEEvent 16392
CHIP:DL: CHIPoBLE advertising config complete
CHIP:DL: RegisterAdvertisement complete
CHIP:DL: HandlePlatformSpecificBLEEvent 16393
CHIP:DL: New BLE connection 0xffff78035b70, device B8:27:EB:4F:32:C9, path /org/bluez/hci1/dev_B8_27_EB_4F_32_C9
CHIP:DL: BluezCharacteristicAcquireWrite is called, conn: 0xffff78035b70
CHIP:DL: c1 BluezCharacteristicWriteFD mtu, 517
CHIP:DL: FAIL: short read in BluezCharacteristicWriteFD (0)
CHIP:DL: CHIPoBLE subscribe received
CHIP:BLE: no endpoint for sub recvd
CHIP:DL: HandlePlatformSpecificBLEEvent 32777
CHIP:DL: Receive kCHIPoBLEConnectionEstablished

And I referred to link to compile chip-tool.
When I am pairing ble-device on pi-2 with it, I am confused about:

ubuntu@ubuntu-1:~/connectedhomeip/examples/chip-tool$ sudo out/debug/chip-tool pairing ble  12345678 3840
CHIP:ZCL: Using ZAP configuration...
CHIP:ZCL: deactivate report event
CHIP:TOO: InitArgs: Wrong arguments number: 2 instead of 4
Usage:
  out/debug/chip-tool pairing ble ssid password setup-pin-code discriminator

Where do ssid and passwd come from? Can it generate an AP with ble-device?
My final goal is very easy, it is to enable communication with each other pi 4b with CHIP arch.
I try it many ways but fail to do it.
Any ideas are appreciated. Thank you.

Ok, I don't know where ssid and passwd come from, though. I fill them with an AP, which is two pi ap also. It display:
ubuntu@ubuntu-1:~/connectedhomeip/examples/chip-tool$ sudo out/debug/chip-tool pairing ble AP AP_PASSWD   12345678 3840
CHIP:ZCL: Using ZAP configuration...
CHIP:ZCL: deactivate report event
CHIP:IN: TransportMgr initialized
CHIP:IN: local node id is 112233

CHIP:ZCL: Using ZAP configuration...
CHIP:ZCL: deactivate report event
CHIP:DL: CHIP task running
CHIP:DL: TRACE: Bus acquired for name C-1726
CHIP:DL: TRACE: Bluez mainloop starting BluezMainLoop
CHIP:DL: PlatformBlueZInit init success
CHIP:DL: Long dispatch time: 1000 ms
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service0006
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: Char1 /org/bluez/hci0/dev_B8_27_EB_A0_97_2B/service002e
CHIP:DL: New BLE connection 0xffff74003aa0, device B8:27:EB:A0:97:2B, path /org/bluez/hci0/dev_B8_27_EB_A0_97_2B
CHIP:DL: Device already discovered
CHIP:DL: HandlePlatformSpecificBLEEvent 16385
CHIP:DL: HandlePlatformSpecificBLEEvent 16386
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:BLE: subscribe complete, ep = 0xaaaabdffcbe8
CHIP:BLE: connect handshake timed out, closing ep 0xaaaabdffcbe8
CHIP:TOO: Pairing Failure: Ble Error 6021 (0x00001785): Connect handshake timed out
CHIP:CTL: Shutting down the commissioner
CHIP:CTL: Shutting down the controller
ubuntu@ubuntu-1:~/connectedhomeip/examples/chip-tool$

Currently ssid and password are the ssid/password of the wifi network you want the device to connect to. So those are not the ssid/password of the SoftAp of the device itself.

authors: vivien-apple yuzibo


text:
Feature/ci ncp mg12 wifi

Problem
Missing CI build for NCP i.e, MG12+WF200 and MG12+RS911x
Change overview
Adding MG12+RS911x and MG12+WF200 for CI build
Testing
How was this tested? (at least one bullet point required)

If integration tests were added, how do they verify this change?
Ran dry run on my local machine to make sure the commands were running

Note: .github/workflows/darwin-tests.yaml#45 yaml formatting error

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

source: gharchive/pull-request

authors: CLAassistant chirag-silabs


text:
Returns EXIT_FAILURE is something went wrong inside chip-tool

Problem
Currently chip-tool returns EXIT_SUCCESS as long as the command has been parsed and sent. It does not use the result of the command to update its status.
It's not very useful to write tests. For example
Summary of Changes

Use the status of the response

Reminder to click the "re-request review" button (next to reviewer's name) after addressing comments.

authors: mspang vivien-apple


text:
No issue: collaboration invite

Hello matter-rs,
sorry for creating a non-issue. Please simply close it if that is not interesting for you.
I‘m one of the maintainers of matter.js (also project under project-chip orga) and we implement matter in JavaScript/typescript.
To support the open source community in developing with and for matter I also created a discord called „matter-integrators“ where I would like to invite you. There are already other open source projects like the tasmota matter implementations in and beside building a developer community it also started to be a good place to exchange opinions on matter specs and how to read/interpret it ;-).
Thank you and maybe see you there ;-)
Ingo

(As an extra viewpoint - I'm looking at Matter in Rust as well, and am over on the Discord - I'd love to have a place to chat with others doing similar things!)

@Apollon77 that's great to hear, would love to participate. Is this a public room, I couldn't find one, maybe share a link for the same?
@kolektiv great, you can join the matter-rs room here #matter-rs:matrix.org (https://matrix.to/#/#matter-rs:matrix.org) , most of the discussion is currently person-to-person, but I guess moving to this room will help.

Hehe, I created a link but forgot to add to the post ....aahhhhh ;-)
Here we go (and yes open server)
https://discord.gg/qW2feSxmN8

Ps: if helpful I can also create a closed private room for your project in that discord so you have a channel to collaborate more internally on the rust project. Just write me in discord if you want it.

I would also close here, thanks for joining.

authors: Apollon77 kedars kolektiv

repo: project-chip/matter-rs


text:
Move APIs to codeflare.dev groups

Part of project-codeflare/adr#7.
Closes #341.

I've built the MCAD image and helm-installed it - I'm able to successfully deploy perf-test appwrappers.  It's a huge PR though, not sure how to fully test everything to ensure it all works with InstaScale, etc...
oc get pods |grep mcad
mcad-controller-78df9fb9d4-njbmx          1/1     Running   0             10m

and
test/perf-test/perf.sh
....
How many appwrapper jobs do you want?10
jobs number is 10

Jobs started at: 11:37:54

Submitting job 1
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-1 created
Submitting job 2
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-2 created
Submitting job 3
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-3 created
Submitting job 4
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-4 created
Submitting job 5
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-5 created
Submitting job 6
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-6 created
Submitting job 7
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-7 created
Submitting job 8
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-8 created
Submitting job 9
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-9 created
Submitting job 10
appwrapper.workload.codeflare.dev/defaultaw-schd-spec-with-timeout-10 created
No resources found in default namespace.
Number of completed jobs is:  0  and the goal is:  10
No resources found in default namespace.
Number of completed jobs is:  0  and the goal is:  10
Number of completed jobs is:  4  and the goal is:  10
Number of completed jobs is:  8  and the goal is:  10

All 10 jobs finished: 11:38:41
Total amount of time for 10 appwrappers is: 47 seconds

(Note, I had to make a modification to the preempt-exp.yaml, commenting out the Items: [] line due to some recent change, doesn't seem related to this PR... I'll create an issue to fix this.)

@asm582, is there additional/better ways to test other than building and helm installing?

@asm582, is there additional/better ways to test other than building and helm installing?

@jbusche I thought we were moving away from helm and planned to use only codeflare operator to deploy MCAD.
Anyways I think for now helm seems an easy way.
We would have to run manual tests for MCAD + InstaScale:

Deploy MCAD through the helm
Deploy InstaScale using the steps mentioned in the repo
Fire AW that needs resources and check if InstaScale picks up the AW (Note we only check logs whether InstaScale got invoked without actually adding resources to the cluster)

Tried some appwrappers with 100 fake KWOK nodes too - seems slower, but is completing.

Sure @asm582, let me try with helm and InstaScale - I'd have to think how I'd get a KFDEF deployed with this MCAD branch...

Tried some appwrappers with 100 fake KWOK nodes too - seems slower, but is completing.

Thanks, it is great that we are using KWOK. can you please create a documentation issue on using KWOK to do scale tests please?
Also, a simple shell script would be great if we can do it, based on your previous perf script, KWOK enabled shell script should ask something like:

How many nodes do you need?
How many GPUs per node do you need?
Default num pods should be 110 per node
Finally should ask, How many AWs do you need?
Fire those many AWs and produce a report.

I am thinking if we can reuse this PR: https://github.com/project-codeflare/multi-cluster-app-dispatcher/pull/469/files

/hold

OK - I just tested this MCAD PR 591 together with the InstaScale PR 127, building images for both and using helm install to deploy of each specific branch, and it's looking good to me.  Note, I don't actually have a real scalable cluster that can leverage InstaScale, but InstaScale IS picking up the appwrappers:
oc logs -f instascale-7bd6d676b9-trk9z
I0824 23:50:11.983705       1 request.go:690] Waited for 1.037949519s due to client-side throttling, not priority and fairness, request: GET:https://172.30.0.1:443/apis/operators.coreos.com/v1alpha1?timeout=32s
2023-08-24T23:50:14Z	INFO	controller-runtime.metrics	Metrics server is starting to listen	{"addr": ":8080"}
E0824 23:50:14.092261       1 appwrapper_controller.go:165] Got config map named instascale-config from namespace kube-system that configures max nodes in cluster to value 15
E0824 23:50:14.094696       1 appwrapper_controller.go:189] Error getting instascale-ocm-secret from namespace default: secrets "instascale-ocm-secret" not found
I0824 23:50:14.094712       1 appwrapper_controller.go:190] If you are looking to use OCM, ensure that the 'instascale-ocm-secret' secret is available on the cluster within namespace default
I0824 23:50:14.094717       1 appwrapper_controller.go:191] Setting useMachineSets to true.
2023-08-24T23:50:14Z	INFO	setup	starting manager
2023-08-24T23:50:14Z	INFO	Starting server	{"path": "/metrics", "kind": "metrics", "addr": "[::]:8080"}
2023-08-24T23:50:14Z	INFO	Starting server	{"kind": "health probe", "addr": "[::]:8081"}
2023-08-24T23:50:14Z	INFO	Starting EventSource	{"controller": "appwrapper", "controllerGroup": "workload.codeflare.dev", "controllerKind": "AppWrapper", "source": "kind source: *v1beta1.AppWrapper"}
2023-08-24T23:50:14Z	INFO	Starting Controller	{"controller": "appwrapper", "controllerGroup": "workload.codeflare.dev", "controllerKind": "AppWrapper"}
2023-08-24T23:50:14Z	INFO	Starting workers	{"controller": "appwrapper", "controllerGroup": "workload.codeflare.dev", "controllerKind": "AppWrapper", "worker count": 1}
I0824 23:51:46.063611       1 appwrapper_controller.go:242] Found Appwrapper named defaultaw-schd-spec-with-timeout-1 that has status Pending
I0824 23:51:46.063637       1 appwrapper_controller.go:293] Found AW defaultaw-schd-spec-with-timeout-1 that cannot be scaled due to missing orderedinstance label
I0824 23:51:46.063646       1 machineset.go:225] The nodes allowed: 15 and total nodes in cluster after node scale-out 0
I0824 23:51:46.063651       1 appwrapper_controller.go:328] Completed Scaling for defaultaw-schd-spec-with-timeout-1
I0824 23:51:46.349739       1 appwrapper_controller.go:242] Found Appwrapper named defaultaw-schd-spec-with-timeout-2 that has status
I0824 23:51:46.715860       1 appwrapper_controller.go:242] Found Appwrapper named defaultaw-schd-spec-with-timeout-3 that has status
I0824 23:51:47.085314       1 appwrapper_controller.go:242] Found Appwrapper named defaultaw-schd-spec-with-timeout-4 that has status
I0824 23:51:47.451514       1 appwrapper_controller.go:242] Found Appwrapper named defaultaw-schd-spec-with-timeout-5 that has status
I0824 23:52:06.778000       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0824 23:52:11.878350       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0824 23:52:11.953459       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0824 23:52:12.658344       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0824 23:52:13.598901       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0824 23:52:23.954608       1 appwrapper_controller.go:396] Appwrapper defaultaw-schd-spec-with-timeout-1 deleted, scaling down machines
I0824 23:52:24.068309       1 appwrapper_controller.go:396] Appwrapper defaultaw-schd-spec-with-timeout-2 deleted, scaling down machines
I0824 23:52:24.182505       1 appwrapper_controller.go:396] Appwrapper defaultaw-schd-spec-with-timeout-3 deleted, scaling down machines
I0824 23:52:24.291684       1 appwrapper_controller.go:396] Appwrapper defaultaw-schd-spec-with-timeout-4 deleted, scaling down machines
I0824 23:52:24.390921       1 appwrapper_controller.go:396] Appwrapper defaultaw-schd-spec-with-timeout-5 deleted, scaling down machines

Deployed with 20 fake kwok nodes, and both MCAD and InstaScale detected and processed the appwrappers:
oc logs -f instascale-7bd6d676b9-trk9z
...
I0825 00:13:34.160127       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0825 00:13:47.903276       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0825 00:13:47.993945       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0825 00:13:48.619900       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0825 00:13:49.568952       1 appwrapper_controller.go:263] Job completed, deleting resources owned
I0825 00:14:05.074198       1 appwrapper_controller.go:396] Appwrapper fake-defaultaw-schd-spec-with-timeout-1 deleted, scaling down machines
I0825 00:14:05.191447       1 appwrapper_controller.go:396] Appwrapper fake-defaultaw-schd-spec-with-timeout-2 deleted, scaling down machines
I0825 00:14:05.314616       1 appwrapper_controller.go:396] Appwrapper fake-defaultaw-schd-spec-with-timeout-3 deleted, scaling down machines
I0825 00:14:05.462589       1 appwrapper_controller.go:396] Appwrapper fake-defaultaw-schd-spec-with-timeout-4 deleted, scaling down machines
I0825 00:14:05.550734       1 appwrapper_controller.go:396] Appwrapper fake-defaultaw-schd-spec-with-timeout-5 deleted, scaling down machines

@jbusche thanks a lot for the testing and feedback. I think it's safe to assume that the rest of the InstaScale auto-scaling logic should not be impacted, as long as it can process the AppWrapper in the new API group. So I think that's enough to validate this PR, so we can start rolling the migration in downstream components.
Let's wait for the upcoming release, and unhold / merge this at the beginning of the next iteration.

/lgtm

quota borrowing tests which was a recently merged PR are failing, I think we missed something during the merge. borrow quota trees are not found in the build.

/unhold

quota borrowing tests which was a recently merged PR are failing, I think we missed something during the merge. borrow quota trees are not found in the build.

Ah good catch, thanks. I've updated the tests.

/lgtm

/approve

authors: anishasthana asm582 astefanutti jbusche


text:
Aseem experiments

#16

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: prasadrayana sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: msftclas prasadrayana

repo: project-everest/vale

license_source: bigquery


text:
Change radio buttons so they are stacked and input field is moved closer

Closes: https://issues.redhat.com/browse/COST-1738

Codecov Report

Merging #2055 (93badbb) into master (c7cf981) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff            @@
##           master    #2055    +/-   ##
========================================
  Coverage   70.68%   70.68%
========================================
  Files         404      404
  Lines        7347     7347
  Branches     1573     1441   -132
========================================
  Hits         5193     5193
- Misses       2128     2130     +2
+ Partials       26       24     -2

Impacted Files
Coverage Δ

src/pages/costModels/costModel/costCalc.styles.ts
100.00% <ø> (ø)

.../pages/costModels/createCostModelWizard/markup.tsx
46.66% <0.00%> (ø)

src/components/charts/costChart/costChart.tsx
9.37% <0.00%> (ø)

...omponents/charts/dailyCostChart/dailyCostChart.tsx
7.89% <0.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 c7cf981...93badbb. Read the comment docs.

repo: project-koku/koku-ui


text:
fix typos found by spellchecker

Hi. I ran some of the files in the repo through a spell checker and fixed a few more typos (couldn't help it 😬. Hope you won't mind).
Not sure if any of the 'fixes' are in fact wrong though.

Thanks!

authors: blaxill ju-sh

repo: project-oak/silveroak


text:
Automatically log errors when program fails

Programs should convert the error code into the #[msg("<msg>")] string and log it via msg!.

potential spec (not sure if it could actually work like this) which builds on some of the ideas of @cqfd 's PR but includes file and line information and more dynamic errors that show what exactly went wrong.

create an AnchorError and an AnchorResult<(), AnchorError>

AnchorError is a struct with a msg:String field, an error_code:u64 field, a line number field, and a file field
implements From and ProgramError implements From
autogenerated derive(Accounts) code will throw AnchorErrors showing exactly on which accounts and how a constraint was violated
inside-handler user code will use an error! macro that takes a string and an error code and creates an AnchorError that also includes the line number and file name

if dispatch returns an error

anchor logs the error information once in human readable form
and once in base64 encoded form
converts the anchorerror back into a programerror and returns it

I would also suggest merging #789 and #823 for one issue that fully designs and implements proper error reporting, I think that will be easier to develop and better designed

open question: how do we make error msgs dynamic?
e.g. error #msg[..] could be defined with "{}" syntax like format!. the new error creation macro then takes args that fill the {}

another feature that could be added as part of this milestone: more require statements
e.g. require_mut(account), require_signer(account), require_owner(account, owner) etc.
This is useful for instructions that use remaining_accounts

We should talk more about specification of this issue
The following code
pub fn initialize(ctx: Context<Initialize>) -> AnchorResult<()> {
        error!(MyError::SomeError)
}

results in the following logs
Program log: AnchorError thrown in programs/compute/src/lib.rs:9 in program: Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS. Error Code: SomeError. Error Number: 6000. Error Message: Some error has been thrown.

which is the type of error (AnchorError vs ProgramError). The file and line. The ErrorCode/ErrorName, the error number, and the error message.
This information seems pretty good to me.  Im going to adjust the error msgs to make them dynamic so then youd have even more freedom. I added the program id so errors are useful even if CPIs are happening
the question is, what's the best way to log this? I think we should definitely provide an option to just log it like this. It's very useful for developing and would also be useful info in the explorer. But maybe there should be an option to turn this off.
but imo we also need something more machine friendly. We could do what events do and encode and then log the encoded error as well.
Also, the error msg above costs ~ 14K compute units which is pretty expensive. However, about 12K of those come from turning the public key into a string. This is not necessary because we can hardcode the string somewhere.

Note that logging the program id is redundant, because it can be easily inferred when looking at the log context (every CPI shows the program being invoked).
The machine readable / structured error would be useful (and preferred) for funneling error messages to the client, rather than what we do now which is parse error codes. Defining a error type that is logge din the same way we do events sounds good.
E.g.
#[derive(AnchorSerialize, AnchorDeserialize)]
pub struct ErrorEvent {
  line: u64,
  msg: String,
  code: u32,
  ...
}

One question is do we want to add a unique header to such an error event like we do for regular events. I think so, so that we can parse it from the logs easily. Something simple like sha256("internal:error")[..4] as the discriminator with the new header. Might be good to do this as a separate change, since it will also require client plumbing.
Related https://github.com/project-serum/anchor/issues/126#issuecomment-815466853.

authors: armaniferrante paul-schaaf

repo: project-serum/anchor


text:
redirect blob download to s3 server

What type of PR is this?

Which issue does this PR fix:
Issue #494
Closes #494
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades?
Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Need to check if clients handle http redirects on a common basis. Need to check if OCI dist spec mentions redirects.
After we validate the above, we need a rebase

@laurentiuNiculae is this PR still valid, else we should close it.

Is this still relevant? I am looking forward to this feature... Is there any reason why haven't this PR been merged yet?

Is this still relevant? I am looking forward to this feature... Is there any reason why haven't this PR been merged yet?

@KuxaBeast, we plan to merge this PR in a future milestone. Meanwhile, could you give us more details about your use case?

@rchincha, it's just a home-lab setup for now. I was thinking about making use of the Backblaze storage and Cloudflare, utilizing the Bandwidth Alliance, making the download costs essentially zero. But then I found that it might also be a good idea to offload downloads directly to Cloudflare, instead of bombing the Zot instance on my K8s cluster.

authors: KuxaBeast andaaron laurentiuNiculae rchincha

repo: project-zot/zot


text:
Add navigation from annotation files into their targets in the text

Now that we can see the annotation markers in the text, they can be targets for navigation from the annotation file, as we already do with collation apps. Add those links in the annotation pages.

This is now working; closing the ticket.

repo: projectLEMDO/lemdoIssues

license: MIT


text:
language: correct 'vice versa' in docs

Signed-off-by: Ed Santiago santiago@redhat.com

LGTM

Why is this failing

That was my question too. I don't have a sense for libpod CI yet, but was hoping to hear this was a transient system problem.

Cloud podman is allowed to fail, that's our podman-in-podman test suite and the tests aren't quite 100% there

Ok I can force the merge since this is definitely not breaking anything.

authors: edsantiago mheon rhatdan

repo: projectatomic/libpod


text:
Override and pin braces package version to 3.0.3 to override vulnerab…

…le version

@gunnigylfa  Can we merge this ?

Sorry, forgot to merge this. Has since been resolved with #115

repo: projectawakening/world-chain-contracts


text:
Resource limits for self-hosted manfests

We should be setting resource limits in the self-hosted manifests.
Currently blocked by deciding what those limits should be.

We should also have a table of recommended values for various levels of scale.

Would be useful to know this for the calico-dcos install as well.

authors: caseydavenport djosborne

repo: projectcalico/calico


text:
Cannot manage to Deny connection based on namespaceSelector

Hi!
I'm trying to deny access to kube-system to all namespace with a specific label, on AWS EKS.
There's also a NetworkPolicy inside the namespace to restrict access to AWS metadata.
The network policy inside kube-system:
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  annotations:
  name: kube-system-network-policy
  namespace: kube-system
spec:
  egress:
  - action: Allow
  ingress:
  - action: Deny
    destination:
      selector: all()
    source:
      namespaceSelector: "sample-label-key == 'sample-label-value'"
      selector: all()
  - action: Allow
  order: 499

namespace from which we want to restrict network:
apiVersion: v1
kind: Namespace
metadata:
  labels:
    sample-label-key: sample-label-value
  name: sample-namespace

Existing network policy inside namespace:
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: sample-namespace-network-policy
  namespace: sample-namespace
spec:
  egress:
  - action: Deny
    destination:
      nets:
      - 169.254.169.254/32
  - action: Allow
  order: 500

When I spawn a pod inside sample-network I can curl an endpoint in kube-system.
Any idea what I did wrong?
Thanks for your help.

Side note, I also tried to achieve this by Denying egress in the sample-namespace:
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: sample-namespace-network-policy
  namespace: sample-namespace
spec:
  egress:
  - action: Deny
    destination:
      nets:
      - 169.254.169.254/32
  - action: Deny
    destination:
      namespaceSelector: "projectcalico.org/name == 'kube-system'"
  - action: Allow
  order: 500

When I spawn a pod inside sample-network I can curl an endpoint in kube-system.

What endpoint specifically are you trying to access? Note that a lot of the pods in kube-system are host networked, which means they are outside of network policies and you would need to use Calico host protection / host endpoints to apply policies to them.

Thanks for the support, pods I was testing was indeed host networked. Will try using host endpoints!

authors: caseydavenport thibaudio


text:
Calicoctl.exe ipam return error on Windows node

Calling Calicoctl ipam on a Windows node return error.
C:\etc\CalicoWindows> .\calicoctl.exe ipam configure --strictaffinity=true
Error: global strict affinity should not be false for Windows node

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Calico version
Orchestrator version (e.g. kubernetes, mesos, rkt):
Operating System and version:
Link to your project (optional):

Hi,
If you look a the docs https://docs.projectcalico.org/getting-started/windows-calico/quickstart
there is :
Configure strict affinity for clusters using Calico networking
For Linux control nodes using Calico networking, strict affinity must be set to true. This is required to prevent Linux nodes from borrowing IP addresses from Windows nodes:
calicoctl ipam configure --strictaffinity=true

@song-jiang sounds like this has been fixed since you raised it?

I currently face a similar or same issue. I want to change the affinity setting on my cluster (from a windows machine) and get the following error on various commands

Error: global strict affinity should not be false for Windows node

Also on just showing the current configuration I already get this error:

kubectl calico ipam show --show-configuration --config=calico.cfg.yaml --allow-version-mismatch

On the cluster there is calico 3.20 and I try to use the 3.24.5 client (because I could not find a 3.20 calicoctl windows binary in the GitHub Releases).
Could the client/cluster version mismatch be the reason or is there still a problem open?

authors: Danielku15 aarnaud caseydavenport song-jiang


text:
ChecksumOffloadBroken autodetection doesn't necessarily detect all cases

Expected Behavior
Pod-pod and pod-service communication across nodes should work.
Current Behavior
All traffic between pods across nodes is dropped (with the exception of ICMP).
Possible Solution
VMware recommends to either:

Change the VXLAN port to 8472 (when NSX is not used) or 4789 (when NSX is used)
Disable the VXLAN hardware offload feature on the VMXNET3 NIC (which recent Linux driver version enable by default)

Since a port change is not feasible for Calico Windows (which requires 4789) disabling the hardware offload feature is the only feasible solution. Since this feature was not even supported by earlier Linux versions for that particular NIC device there is no performance impact of disabling it.
Given that the NIC firmware configuration is not something most users are used to manage i suggest to implement a transparent solution in Calico that disables the offload feature when Calico configures VXLAN on host interfaces backed by a VMXNET3 device.
To that effect: It looks like Calico already configures NIC driver settings: https://github.com/projectcalico/felix/blob/master/ethtool/ethtool.go
Steps to Reproduce (for bugs)

Provision VMs on vSphere version 6.7u2 or later using one of the following operating systems: CentOS/RHEL/Oracle 8.3, SLES 15 SP2/SP3
Install Kubernetes cluster on the nodes
Install Calico with VXLAN overlay following official docs, e.g.:

https://docs.projectcalico.org/networking/vxlan-ipip
https://docs.projectcalico.org/getting-started/windows-calico/kubernetes/standard

Context
VXLAN packets are dropped on the Linux network stack due to incorrect checksums of inner packets. These incorrect checksums occur when enabling VXLAN hardware offload on the VMXNET3 interface (which recent Linux version do by default) and creating a VXLAN overlay network in the guest OS on ports other than 8472 (when NSX is not used) or 4789 (when NSX is used).
References:

https://github.com/rancher/rancher/issues/33399
https://bugzilla.redhat.com/show_bug.cgi?id=1935539
https://bugzilla.redhat.com/show_bug.cgi?id=1941714 (not public)

Your Environment

Calico version 3.19.1
Orchestrator version: Kubernetes 1.19.12 (RKE)
Operating System and version: CentOS/RHEL 8.3, SLES 15 SP2

VXLAN offload works with many 10G NICs, disabling by default will hurt performance for those, and each card can have different offload toggle, for the qede driver + IPIP you need to disable all offload, not just tx-udp_tnl-csum-segmentation for exemple.

Good point, the fix would obviously have to selectively disable VXLAN offload for the interfaces using a driver known to be broken (VMXNET3),.

Thanks @janeczku. So IIUC there is a workaround to disable hardware offloading on those specific NICs that can be done prior to installing Calico for Windows.
Perhaps another way is to document this issue and workaround for Calico vSphere users on https://docs.projectcalico.org
cc @song-jiang

Is there a good way to detect these NICs?  If so, we could arrange for ChecksumOffloadBroken to be set int hat case: https://github.com/projectcalico/felix/blob/master/iptables/feature_detect.go#L116

It should either be documented or the workaround should be applied automatically in Felix by invoking ethtool. Similar to the existing workaround here: https://github.com/projectcalico/felix/pull/2811/files#diff-6e1678cae2b546f107a4a1f780f46a0173509d3a5ed822075aa1407ae528a461R49

Yes, they can be detected by determining NIC model and hw revision via ethtool syscalls

The bug is actually in the new linux driver for vmxnet3. So probably instead of detecting the hardware make it would be enough to detect that it uses the buggy driver version.

Sometimes the bug is with the driver + firmware combination, it's endless.
Best thing would be to have Calico send packets using raw sockets and receive them on another node and see if the checksums are correct, ie really test that it's working.

@fasaxc, et al.,
I have an issue where pods can't communicate with one another across nodes. I've concluded that it's related to this issue.
I was able to verify that on a brand new k3s cluster install adding featureDetectOverride: "ChecksumOffloadBroken=true" to the FelixConfiguration fixes the issue, but I'm unable to get an existing install fixed by applying the change. What needs to be done for the change to take effect?
I have calico installed via the tigera operator v1.23.1 (calico v3.21.0) on k3s v1.21.5+k3s2. OS is Ubuntu 20.04.
-robodude666

I'm hitting this issue on Azure (requires VXLAN) Linux version 5.15.0-1014-azure, using Helm to install Calico in VXLAN mode via operator. Unfortunately, the autodetect doesn't work because my kernel version is > 5.7 (even though Ubuntu 20.04 doesn't appear to have the fix).
However, Calico does not allow configuring Felix directly when using the operator: https://projectcalico.docs.tigera.io/reference/felix/configuration
It would be great if we could either:

Improve the ChecksumOffloadBroken to not rely on a simple kernel version check (since not all distributions have the fix backported) - this would be my preferred solution
Allow configuring Felix via operator / Helm chart values

Hm, that's a bummer that the auto-detection isn't working on newer kernels.

If you have installed Calico using the operator, you cannot modify the environment provided to felix directly. To configure felix, see the FelixConfiguration resource instead.

If you're using the operator, you should look at https://projectcalico.docs.tigera.io/reference/resources/felixconfig to use REST API-based configuration instead of environment variables.
You should be able to modify the default FelixConfiguration resource to set:
spec.featureDetectOverride: "ChecksumOffloadBroken=true"

You should be able to modify the default FelixConfiguration resource

@caseydavenport that's what I'm doing for now and it seems to make the tests happy: https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/2e8e3a790510dacc78bd134610c904218f5f3fa4/templates/addons/calico/felix-override.yaml
Do you know if there is a way to do this directly via the Helm chart though? It'd be easier if I could set the featureDetectOverride in values.yaml instead of having to modify the default FelixConfigurations resource via kubectl apply after the helm install. Maybe I'm missing something?
After doing some research across many GitHub issues on this kernel bug I found https://github.com/rancher/rke2-charts/blob/main-source/packages/rke2-calico/generated-changes/overlay/templates/felixconfig.yaml, seems like rancher folks are doing some sort of overlay to extend the upstream calico template to allow configuring Felix in values.yaml. Would it be valuable to add something like it directly in the official Calico Helm chart?
Thanks so much for the answer and for all your work on the project btw, I've gone through a lot of Calico issues the past few days and your comments were very helpful!

Thanks for the pointer to that overlay file! I didn't realize that.
However, this line . . .  Looks like https://github.com/projectcalico/calico/issues/6412 strikes again!

Would it be valuable to add something like it directly in the official Calico Helm chart?

It definitely would, and were it not for the problems discussed in the above issue I'd probably just do that right now. To be honest I'm tempted to do it anyway since the default FelixConfiguration is a singleton and this would be a nice UX improvement and would actually be abstracted behind helm's values.yaml "API" anyway... I will mull on that :)

Thanks so much...

You're very welcome! and I really appreciate the kind words :smile_cat:

Hey @caseydavenport have you given this any more thought? Looks like others are running into this as well from issue mentions

@fasaxc has a PR which will always disable the offload here: https://github.com/projectcalico/calico/pull/6842
That's probably the best way for now.

Is there a good way to detect these NICs? If so, we could arrange for ChecksumOffloadBroken to be set int hat case: https://github.com/projectcalico/felix/blob/master/iptables/feature_detect.go#L116
Note: Calico feature detction can be overridden with config by setting an override in the FelixConfiguration resource:
featureDetectOverride: "ChecksumOffloadBroken=true"

this only works for VXLAN, not for IPIP;

authors: CecileRobertMichon caseydavenport champtar fasaxc fredkan janeczku lmm robodude666


text:
Remove aws-src-dst-check setting in the default config

Description
Remove awsSrcDstCheck setting in the default config.
This temporary change is to avoid running into installation issues while we investigate the RC.
Related issues/PRs

Todos

[x] Tests - verified that using the proposed change, calico-node becomes ready after the installation.
[ ] ~Documentation~
[ ] Release note

Release Note

None required

Deploy preview for calico ready!
Built with commit 378bff40fa4e99113a64839d0370be11bd24639a
https://deploy-preview-4153--calico.netlify.app

CI failed with --
docker: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit.

I was able to verify locally though.

This change works for me as well - calico-node now comes up with the default calico-vxlan.yaml manifest.

authors: bcreane caseydavenport realgaurav


text:
Remove the Hyrax::SearchBuilder

This class is duplicative of what is already in
app/models/search_builder.rb so it only offers unneeded rediretion.
Also moved search bulders into the Hyrax::My namespace for those that
only show objects deposited by the current user.

Wasn't the point to have a common superclass of all hyrax search builders?

see: https://github.com/projecthydra-labs/hyrax/issues/707#issuecomment-292996882

@atz the reasoning here is that people may want to install blacklight-range-limit or other blacklight plugins which modify ::SearchBuilder.  I think this is better from that regard.  @jrochkind what do you think?

I agree ::SearchBuilder is blacklight's conventional target for modification.  I just want to minimize the number of generators/destroyers we have all trying to kludge our way into the same app class that itself isn't versioned or controlled.  Ideally Hyrax::SearchBuilder inherits from ::SearchBuilder, as you have here.

@jcoyne: I can't completely follow all the implications, I gotta admin. But for starters, def all the SearchBuilders should have parallel inheritance hiearchies. I think this accomplishes that? If so, that's good.
Additionally there should be clear ways to customize search builders. And probably clear ways to customize all search builders.
I think this makes all of them inherit from app local ::SearchBuilder so that customizations there (whether manual and local, or injected by plugins like range limit) will apply to all search builders. This strikes me as an improvement. (But are there any cases where someone is going to accidentally effect all search builders, when they don't mean to?  I don't think there are any big gotchas here, but I don't feel like my mind is completely around the existing architecture and all those dozens of search builders and what they do).
And I think you have tried to provide an easier way to customize individual search builders instead of all of them too? Maybe with the use of the builder = search_builder(controller) formulation?  I think that is a use case that needs to have a path; I don't understand enough of the architecture to know if this is the optimal one, or how it would be intended to be used. Some docs with examples of "effect just specific search builder" use cases is needed, somewhere.
So I am cautiously optimistic about this change, although I don't understand it enough to be sure.
There is existing documentation that will have to be changed, I think. And ideally new docs that explain the use cases for "effect all search builders with custom logic" and "effect just certain search builders with custom logic", as well as ideally providing context for why there are so many search builders and what that architecture is about.

@atz

but I don't understand that we have changed our reasoning from when we originally made Hyrax::SearchBuilder.

If anyone could share what that reasoning was, it would help me understand what's up here. Reasoning like that is a great thing to capture in class head rdoc, for future readers. The code alone can't show reasoning, motivation, or intent.

Here is the original commit for Sufia::SearchBuilder (later renamed Hyrax::SearchBuilder)  https://github.com/projecthydra/sufia/commit/0c22d71198f564fa653166b932c8ffac043d914c It appears that it was created at the time because we only had one search builder for everything.  Now that it's been well decomposed, I don't think it serves any utility.

It might make sense to have all the Hyrax::My search builders inherit from a common My superclass -- which still inherits from ::SearchBuilder for cases where someone wants to add logic to all My search builders, but not to other search builders.  I don't think there's any good way to add logic just to the MySearchBuilderBehavior module.  In fact, if that's true, and a common My superclass is useful, perhaps it should just contain MySearchBuilderBehavior behavior directly, no need for a module concern. (I consider mixins to be effectively multiple inheritance, and super useful in some cases, but not to be used gratuiously).
But I don't totally understand if there is a use case for "add custom logic to all My search builders only".  I don't entirely understand why there are dozens of search builders in the first place, or what each of them is used for.
I think ideally we'd begin with developer use cases here, which the architecture could be tested against, and could also form the nucleous of some docs with examples.
I know I have a use case for blacklight_range_limit, but I don't totally understand if I want/need that injected into all the search builders, which search builders I'd need it injected into, or if there are any it shouldn't be injected into (as opposed to not neccesary but harmless to do so).

@jrochkind

But I don't totally understand if there is a use case for "add custom logic to all My search builders only". I don't entirely understand why there are dozens of search builders in the first place, or what each of them is used for.

I imagine that might be for some custom permissions or admin capability.
@jcoyne

Here is the original commit for Sufia::SearchBuilder (later renamed Hyrax::SearchBuilder) projecthydra/sufia@0c22d71 It appears that it was created at the time because we only had one search builder for everything. Now that it's been well decomposed, I don't think it serves any utility.

I appreciate the context, but that doesn't match my understanding of the intent here, long after that commit in Sufia.  One of the lines you remove said:
# TODO: make this a mixin and generate it into ::SearchBuilder

But this PR doesn't accomplish that, right?   I guess I'm ok w/ inheriting from a ::SearchBuilder that doesn't exist until after generation, but it still feels weird.  Unblocking: if somebody else wants to approve it, fine.

@atz Maybe I'm misunderstanding, but the point of inheriting from ::SearchBuilder that doesn't exist until after generation, is that the local ::SearchBuilder is the place where the user (or other plugins) can add code meant to apply to all app search builders.  Right, are you with me?
I'm not sure if you're thinking there's no need to do this (or that it may even be inappropriate), or if you are considering a different way to do this, or something else entirely.
One way or another, I think a solution is needed to the issues raised in #707. I think maybe this does that -- at least I believe it's intended to?  If you have a different approach in mind though, I'd be definitely interested in hearing it!

I think I like this, and I think it provides an architecture that answers some of the questions/problems in #707.
But I'm reluctant to be the approver myself:

I don't totally understand everything in here, it's a large refactor
I don't totally understand the use cases the original (before this PR) architecture was meant to be solving, why it was like that in the first place, and if this PR breaks any of them.
I am not sure if the backwards incompat implications of this PR, and if they are significant, if there's another way to approach #707 with fewer.

I think ideally a (potentially wider) discussion with words not just code would happen here about the use cases intended to be supported by the way hyrax uses SearchBuilders, and potential backwards compat issues of this change, if any.  But if some other committer wants to approve it as is, I'm not blocking!  Perhaps other people understand this context better than me, I'm just not comfortable approving/merging with my understanding as it is.

But I don't totally understand if there is a use case for "add custom logic to all My search builders only". I don't entirely understand why there are dozens of search builders in the first place, or what each of them is used for.

I imagine that might be for some custom permissions or admin capability.

I think that suggests giving all the My searchbuilders a common superclass, which itself < ::SearchBuilder, so that common superclass is a place to inject behavior you want only for My builders, and not for everything. What do you think, @jcoyne ?

@jcoyne :point_up:

@mjgiarlo @jrochkind isn't that what  Hyrax::My::SearchBuilder is? A common search builder for the My* builders?

@jcoyne you are correct, I missed that, sorry!

@jcoyne Is this something you are still interested in?

@jeremyf Yes, it got stale waiting for an approval.

@jcoyne I'll work on the merge conflicts today

authors: atz jcoyne jeremyf jrochkind mjgiarlo

repo: projecthydra-labs/hyrax


text:
Add Open Annotations vocabulary

See also https://github.com/ruby-rdf/rdf/issues/169
The equivalent yaml for  rdf-vocab/lib/rdf-vocab/config/vocab.yml could be:
oa:
  class_name: OA
  uri: http://www.w3.org/ns/oa#
  source: http://www.openannotation.org/spec/core/20130208/oa.owl

Not entirely sure about the `StrictVocabulary' version, probably should be one of those 8-)

Closing this as it was resolved with https://github.com/projecthydra-labs/rdf-vocab/pull/37

authors: acoburn darrenleeweber

repo: projecthydra-labs/rdf-vocab


text:
Show short exception string as error in monitoring UI for a failed invocation

When a function fails, show the short exception string as an error (aka red balloon). We already do this for the WebJobs SDK Dashboard.
Related: https://github.com/Azure/azure-webjobs-sdk/issues/863

I just spoke with @mikestall, let me try to clarify what we need to do here. This is specifically about the monitoring UI. For a failed invocation, the dashboard API exposes a short exception string. We need that exception string displayed on the righthand pane.
For example, here is the error message that appears in the streaming logs for a function that throws an exception like this:
    throw new Exception("something bad");
2016-10-31T21:10:34.297 Exception while executing function: Functions.HttpTriggerCSharp3. HttpTriggerCSharp3: something bad.
But the string "something bad" never appears on the monitor tab:

Dup of https://github.com/projectkudu/AzureFunctionsPortal/issues/622 ?

Yes this is a Dup of 622

repo: projectkudu/AzureFunctionsPortal


text:
Question: Who is driving this project?

Who on the Microsoft-side is driving this project? I'd like to have a conversation with them. Thank you.

Hi there Rob, I'll reach out via email.

authors: EisenbergEffect paulbatum


text:
Incorrect CSS authoring can cause cli to fail

@media (min-width: 1000px) { ... } missing semi colon here causes the CSS parser to fail. e.g. $ wallace https://www.gatsbyjs.org

SyntaxError: Missed semicolon at line 220, column 539:

  218 | }.css-mj31jj { -webkit-box-align: center; align-items: center; display: flex; z-index: 1; }.css-mj31jj span { color: var(--theme-ui-colors-link-color,#8a4baf); border-bottom: 1px solid var(--theme-ui-colors-link-border,#d9bae8); }a.css-mj31jj { font-weight: normal; }@media (min-width: 1000px) {
  219 |   .css-mj31jj:hover span { border-color: var(--theme-ui-colors-link-hoverBorder,#8a4baf); }
> 220 | }.css-csk973 { border-radius: 100%; display: inline-block; margin: 0rem 0.75rem 0rem 0rem; transform: translateZ(0px); vertical-align: top; }.css-1lxugp9 { align-items: flex-end; background: transparent; bottom: 0px; color: var(--theme-ui-colors-card-color,#78757a); display: flex; -webkit-box-flex: 1; flex-grow: 1; font-size: 0.875rem; left: 0px; padding: 1.25rem; position: absolute; right: 0px; top: 0px; z-index: 0; }.css-1lxugp9:hover { background: yellow; }.css-1lxugp9 svg { height: 1rem; width: 1rem; }.css-1lxugp9 span { color: color:var(--theme-ui-colors-link-color,#8a4baf); border-top-color: ; border-top-style: ; border-top-width: ; border-right-color: ; border-right-style: ; border-right-width: ; border-left-color: ; border-left-style: ; border-left-width: ; border-image-source: ; border-image-slice: ; border-image-width: ; border-image-outset: ; border-image-repeat: ; border-bottom: 1px solid var(--theme-ui-colors-link-border,#d9bae8); font-weight: bold; margin-right: 0.25rem; }@media (min-width: 1000px) {
      |                                                                                ^
  221 |   .css-1lxugp9 { padding: 2rem; }
  222 |   .css-1lxugp9 span:hover { border-color: var(--theme-ui-colors-link-hoverBorder,#8a4baf); }

There seems to be an actual CSS syntax error, so the analyzer doesn't know how to transform the CSS into something to analyze. Did you get this exact error too?

@clanceyp can you confirm that you got this same error message too?

Ah yes,. you're right the CSS is broken. I'll close this ticket

Hello, I'm just facing the same error, but I would really want a way to workaround this, because, I do not control all the css files (so I cannot fix the issue) and the error does not even mention the actual file causing the issue.
So, it would be awesome to have the error mention the broken file (no only line number):
SyntaxError: Missed semicolon at file.css on line 220, column 539:

Also it would be nice to have an option to skip those (as browsers do):
$ wallace --skip-broken https://www.gatsbyjs.org
WARNING: skipping broken file: gatsbyjs.org/file.css
[RESULTS...]

Regards.

@eloyesp This is because the css-analyzer is several major versions behind. Newer versions are very resilient to invalid CSS. I'm planning to release a new version of wallace-cli that has this latest version. Work already started in a v3 branch in this repo branch

authors: bartveneman clanceyp eloyesp

repo: projectwallace/wallace-cli


text:
How to use day view like month and week view

widget.state().edit()
.setCalendarDisplayMode(CalendarMode.MONTHS)
.commit();
similar like above for day view
widget.state().edit()
.setCalendarDisplayMode(CalendarMode.DAY)
.commit();

There is no plan to display day by day calendar


text:
What is the difference between the standard implementation?

What is the difference between the standard implementation and material-calendarview?
the latest support library(platform's implementation) now have a full material look and feel

We made this library to have a Material calendar widget that worked on 4.0+. So this library is to function, at least, as a design back port. It's also meant to be more customizable than the platform's widget android.widget.CalendarView. Even for targeting 5.0 and up, the date picker was updated to Material design, but not platform's calendar widget. It still looks Holo.


text:
Implement integration with DiagnosticSource

We need to propose and implement integration with DiagnosticSource. This integration should provide an easy way to filter and map events into metrics. It might be done as a additional package if this makes sense.

This can help: https://github.com/Chakrygin/DiagnosticsNet

May be not EventSource, but DiagnosticSource would be more suitable for that?
These articles can help (it only in russian):
https://habr.com/ru/company/ozontech/blog/435896/
https://habr.com/ru/company/ozontech/blog/221037/

@Sergey-Terekhin Thank you!

Nobody interested

authors: Sergey-Terekhin phnx47 sanych-sun

repo: prom-client-net/prom-client