text:
operator verticadb-operator (1.10.2)

Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[ ] Did you create a ci.yaml file according to the update instructions?
[ ] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/merge possible

/merge possible

authors: framework-automation spilchen


text:
operator mongodb-enterprise (1.20.1)

operator mongodb-enterprise (1.20.1)

/retest

/ok-to-test

/retest

/merge possible

/merge possible

source: gharchive/pull-request

authors: framework-automation irajdeep lsierant mircea-cosbuc

license_type: permissive

license_source: github-api


text:
operator dapr-kubernetes-operator (0.0.8)

Signed-off-by: Luca Burgazzoli lburgazzoli@gmail.com
Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/merge possible

/merge possible

authors: framework-automation lburgazzoli


text:
Fix alpine 3.13 APK proxy build issue

Alpine 3.13 set APK repositories to https instead of http.
APK does not work with https proxy because of libfetch issue.
Set alpine to 3.12 until issue is resolved.
Signed-off-by: Kennelly, Martin martin.kennelly@intel.com
See:
https://github.com/alpinelinux/docker-alpine/issues/136
https://github.com/alpinelinux/docker-alpine/issues/98
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220468
Partially fixes #315

This also aligns build image with final image.
once the issue is resolved we can update both hopefully

Yes, it was a mistake not setting the images to a specific version. We should only upgrade once images are tested.
I think a patch version increment is needed once this is merged - so v3.3.1. WDYT?

This also aligns build image with final image.
once the issue is resolved we can update both hopefully

Yes, it was a mistake not setting the images to a specific version. We should only upgrade once images are tested.
I think a patch version increment is needed once this is merged - so v3.3.1. WDYT?

essentially building from tag v3.3 is broken right ? so yes i think its a good idea,

essentially building from tag v3.3 is broken right ? so yes i think its a good idea,

essentially building from tag v3.3 is broken right ? yes i think its a good idea,

yes - within proxy environments. Alpines APK repos were changed from http to https. This is a good thing but there is a bug in libfetch with respecting proxy settings it seems which APK depends on. So upgrading libfetch is a must and they are working on it.

essentially building from tag v3.3 is broken right ? yes i think its a good idea,

yes - within proxy environments. Alpines APK repos were changed from http to https. This is a good thing but there is a bug in libfetch with respecting proxy settings it seems which APK depends on. So upgrading libfetch is a must and they are working on it.

authors: adrianchiris martinkennelly


text:
Add a costume junit reporter to the conformance suite

Currently, the conformance test can be invoked with ginkgo's --junit-report
flag and produce a default junit report.
This commit adds a non-default junit report to the conformance suite
and configures it with specific configurations to produce
clean and easy-to-read report.
Added a "junit" flag, that when is not empty, will
produce the junit report in the given path, with the
report name "junit_sriov_conformance.xml"

Pull Request Test Coverage Report for Build 4980300528

0 of 0   changed or added relevant lines in 0 files are covered.
10 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.1%) to 25.54%

Files with Coverage Reduction
New Missed Lines
%

controllers/sriovibnetwork_controller.go
2
66.04%

controllers/sriovnetwork_controller.go
2
63.81%

api/v1/helper.go
6
41.32%

Totals

Change from base Build 4843162397:
-0.1%

Covered Lines:
1929

Relevant Lines:
7553

💛  - Coveralls

authors: coveralls liornoy


text:
fix(chart): Allow usage of helm built-in namespaces

This patch should resolve https://github.com/k8tz/k8tz/issues/5#issuecomment-950362169 using the existing ignore-namespace feature to resolve both. True, it's not backwards compatible, and if required, we can achieve this, but it should allow to use this helm chart, without requiring the chart to be used to create the namespace.
BREAKING CHANGE: Drop in-chart namespace creation
(One of the main reason to implement this change for me, is that I don't leave namespace creation to helm charts due to enforcing PSS and alike.)

I also built a fully backwards compatible version, but I think it just introduced unnecessary complexity: https://github.com/SISheogorath/k8tz/tree/fix/namespace-issues-compatible

Hi @SISheogorath,
sorry for the late reply.
we can't just break compatibility like that, unfortunately it is a feature from now on.
I did like most of your backward compatible approach, but there is a slightly nicer way imo. I started working on that in #92.
Please help to check and review if you can.
Thanks!

authors: SISheogorath yonatankahana


text:
feature: Allow sharing to individual K9 contact

It would be neat if I could share things from other apps as an email to an individual contact in K9. Currently, when I tap the share icon somewhere, I only see the K9 app itself. Other apps, like Signal for example, expose individual contacts, which I can then share directly to (typically displayed in recently-shared-to order, I guess; I'm on Cyanogenmod 12.x, Android 5.x).
I guess this feature should not send the email automatically, but rather pop up K9 with To: (and body) properly filled out, so one can just tap Send.

Great work, thanks!

source: gharchive/issue


text:
【質問】エクセルVBAモジュール内で時価PUSH配信を利用する方法

お世話になります。
エクセルのVBAモジュール内で時価PUSH配信の値を利用する方法は、シート関数として用意されたWEBSOCKETでセル上に値を一旦表示させて、そのセルの値を参照するしかないのでしょうか。
VBAのモジュール内でWorksheetFunctionにより.WEBSOCKET関数を利用しようとすると、「オブジェクトは、このプロパティまたはメソッドをサポートしていません。」とエラーがでます。
WEBSOCKET関数のコードは参照することができないので、参考にするものがなく手が出せない状況です。
エラーが出るテストコード
Sub test()
　a = WorksheetFunction.WEBSOCKET(7203, 1, "現値")
End Sub
VBAのモジュール内で直接時価PUSH配信の値を取得する方法を教えていただけると助かります。
よろしくお願いいたします。

全く回答いただけませんが、確認いただいていますでしょうか？

エクセルのアドインはXLLであるため、下記の記載で取得可能かと思われます。
お試しください
Application.Run("WebSocket", 9984, 1, "現値")

お世話になります。
期待していた動作を確認しました。
回答ありがとうございます。
大変助かりました。

authors: kabucomapi yasuyuki-nakazawa

repo: kabucom/kabusapi

license: MIT


text:
add docs

PR checklist:

[ ] Test coverage for the proposed changes
[ ] PR description contains example output from repl interaction or a snippet from unit test output
[ ] Any changes that could be relevant to users have been recorded in the changelog

Additionally, please justify why you should or should not do the following:

[ ] Confirm replay/back compat
[ ] Benchmark regressions
[ ] (For Kadena engineers) Run integration-tests against a Chainweb built with this version of Pact

closing as #122 captures the content\builtins

authors: rsoeldner sstraatemans


text:
Add benhofferber.com and blog.stablediscussion.com

Ben Hofferber is a personal blog about web development, work culture, and game dev.
Stable Discussion is a small podcast and publication about AI for a general audience.

@hoffination

Blog is fine but per guidelines if you are submitting your own, submit two others that are not
We do not take substack sites (not really 'small web')

@vprelovac Updated and added two other blogs

authors: hoffination vprelovac

repo: kagisearch/smallweb


text:
Recovery doesnt work

recovery grub entry seems to have a rd.cos.disable on it? Which disables immucore... not sure how it works.
Still, needs to work in immucore

problem seems to be that we pass root=live:LABEL=COS_RECOVERY in the cmdline for some reason...I guess so systemd loads it automatically. Sucks.

repo: kairos-io/immucore


text:
How do i install this onto my Ubutnu

How do i install this in my Ubuntu terminal.

Open ~/.bashrc in your favourite text editor and just add the script in it.
Closing this since it isn't a technical issue.

authors: ghost kalbhor

repo: kalbhor/thirsty


text:
Add the ability to crouch

Implement crouch animations, crouch walking and crouch sprinting

Working on this now

Added idle crouch, all other animations needs to be made. Slowed movement speed when crouched.

repo: kalindudc/PlayerController


text:
Allow setting Name of output

I have multiple output devices in the same room and they show up like this:

It would be nice if I could change the name of them so I don't have to remember which one Living Room (2) is.

Also looking for this option.
Did you implement this this?
If yes, how can I change them?

repo: kalkih/forked-daapd-card


text:
Unable to find vendored packages

I have some tools for which I'm overriding golang.org/x/crypto/openpgp inside my local codebase (with a directory src/mypackage/vendor/golang.org/x/crypto/openpgp).
go build works correctly, but go2nix save fails with cannot find package "golang.org/x/crypto/openpgp".
A symlink (to mypackage/vendor/golang.org from src/golang.org) works around the issue -- but is this something that should be needed?

this doesn't save https://gitea.com/gitea/tea for example and linking doesn't help either,  says 'Cannot find repo root for'

authors: charles-dyfis-net voobscout

license: mit

license_source: bigquery


text:
🛑 Covid19-nagano is down

In 4638553, Covid19-nagano (https://covid19-nagano.info) was down:

HTTP code: 429
Response time: 1048 ms

Resolved: Covid19-nagano is back up in e2d36ab after 26 minutes.


text:
Links and routes and hashroutes

Check if when added as a DHIS2 app it will work correctly with the links

Implemented Hash router


text:
KAS-4684 model changes

https://github.com/kanselarij-vlaanderen/frontend-kaleidos/pull/2175

pair review with Tom

repo: kanselarij-vlaanderen/app-kaleidos


text:
Docs_chroma_embedding_function

Docs change to include example of how a user would set execution provider for ONNX

thanks!

authors: ashishdatta kantord

repo: kantord/SeaGOAT


text:
代码组织与可读性问题

提个小建议，感觉源码阅读起来还是很吃力的，大部分都是 Vue 的源码，不知道 megalo 的代码具体分布在哪里， 开源的目的应该就是要让大家发现问题找到问题， 这样好像不太好提 pr😂

megalo 的源码全在 src/platforms/mp 目录下，src/core 部分没有修改。有些模块 Vue 原本不提供修改接口，我们将部分 core 的源码拷贝到  src/platforms/mp 目录下，例如 path 的逻辑是拷贝到 src/platforms/mp/runtime/vdom/patch.js 再作修改，这类代码相对较少。

repo: kaola-fed/megalo


text:
Image flickers within any tab on first visit

First, let me thank you for this awesome plugin. I am using the plugin to create a timeline. It works great but I have a problem. Each tab contains an image and some text. when I click any title to go to that tab, the image flickers. However; if I visit the same tab again it doesn't flicker. You can find this issue on this page in the Our Story section only on mobile devices. So please open the browser emulator to see it. I'd appreciate any help. Thank you

Hi!
I think this problem is not related to the plugin.
At the first call the browser asynchronously downloads the image, so there is such a flicker. On subsequent transitions, the picture is taken from the cache, so there is no flicker.
Set the minimum height for the parent container of the image so that at the time of loading there are no content twitches.

@karambafe Thanks a lot for the tip. Works like a charm :+1:

repo: karambafe/vue-tabs-with-active-line


text:
fix mypy errors

this fixes two distinct mypy errors
one where NamedTuple/dataclassees can't be
defined locally
https://github.com/python/mypy/issues/7281
which happens when you run mypy like
mypy -p my.core on warm cache
the second error is the core/types.py file shadowing the
stdlib types module

Ah, forgot to include it in the commit; error for reference
Traceback (most recent call last):
  File "/usr/bin/mypy", line 33, in <module>
    sys.exit(load_entry_point('mypy==0.812', 'console_scripts', 'mypy')())
  File "/usr/lib/python3.9/site-packages/mypy/__main__.py", line 11, in console_entry
    main(None, sys.stdout, sys.stderr)
  File "/usr/lib/python3.9/site-packages/mypy/main.py", line 90, in main
    res = build.build(sources, options, None, flush_errors, fscache, stdout, stderr)
  File "/usr/lib/python3.9/site-packages/mypy/build.py", line 179, in build
    result = _build(
  File "/usr/lib/python3.9/site-packages/mypy/build.py", line 253, in _build
    graph = dispatch(sources, manager, stdout)
  File "/usr/lib/python3.9/site-packages/mypy/build.py", line 2638, in dispatch
    process_graph(graph, manager)
  File "/usr/lib/python3.9/site-packages/mypy/build.py", line 2955, in process_graph
    process_fresh_modules(graph, prev_scc, manager)
  File "/usr/lib/python3.9/site-packages/mypy/build.py", line 3033, in process_fresh_modules
    graph[id].fix_cross_refs()
  File "/usr/lib/python3.9/site-packages/mypy/build.py", line 1977, in fix_cross_refs
    fixup_module(self.tree, self.manager.modules,
  File "/usr/lib/python3.9/site-packages/mypy/fixup.py", line 26, in fixup_module
    node_fixer.visit_symbol_table(tree.names, tree.fullname)
  File "/usr/lib/python3.9/site-packages/mypy/fixup.py", line 77, in visit_symbol_table
    stnode = lookup_qualified_stnode(self.modules, cross_ref,
  File "/usr/lib/python3.9/site-packages/mypy/fixup.py", line 301, in lookup_qualified_stnode
    return lookup_fully_qualified(name, modules, raise_on_missing=not allow_missing)
  File "/usr/lib/python3.9/site-packages/mypy/lookup.py", line 47, in lookup_fully_qualified
    assert key in names, "Cannot find component %r for %r" % (key, name)
AssertionError: Cannot find component 'A@146' for 'my.core.serialize.A@146'

repo: karlicoss/HPI


text:
🛑 DIAN is down

In d335328, DIAN (https://www.dian.gov.co) was down:

HTTP code: 0
Response time: 0 ms

Resolved: DIAN is back up in d6b99be.


text:
Cannot read property '33038646' of null - karma-junit-reporter/index.js:93:22

reproduced here
https://github.com/el-net/bs_karma_eval
when run locally as:
karma start karma/lc.js

reproduction is inconsistent :-(
full error:

Missing error handler on `socket`.
TypeError: Cannot read property '30193015' of null
    at specSuccess.specSkipped.specFailure (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma-junit-reporter/index.js:93:22)
    at onSpecComplete (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/lib/reporters/base.js:78:12)
    at null.<anonymous> (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/lib/events.js:13:22)
    at emit (events.js:129:20)
    at onResult (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/lib/browser.js:216:13)
    at Socket.<anonymous> (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/lib/events.js:13:22)
    at Socket.emit (events.js:129:20)
    at Socket.onevent (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/node_modules/socket.io/lib/socket.js:330:8)
    at Socket.onpacket (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/node_modules/socket.io/lib/socket.js:290:12)
    at Client.ondecoded (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/node_modules/socket.io/lib/client.js:193:14)
    at Decoder.Emitter.emit (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/node_modules/socket.io/node_modules/socket.io-parser/node_modules/component-emitter/index.js:134:20)
    at Decoder.add (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/node_modules/socket.io/node_modules/socket.io-parser/index.js:247:12)
    at Client.ondata (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/node_modules/socket.io/lib/client.js:175:18)
    at Socket.emit (events.js:107:17)
    at Socket.onPacket (/Users/osher/ws/POC/bs_karma_eval/node_modules/karma/node_modules/socket.io/node_modules/engine.io/lib/socket.js:99:14)
    at WebSocket.emit (events.js:129:20)

hmm. I noted that in some browsers, each time karma launches the browser - a new tab is added to the browser, so I end up running the test on the browser X times - and that could be the source of a race-condition:
It could be that one tab reported results and the test is closed, and then another tab opened to the karma server ends test and tries to report results.
I can propose two alternatives:
1 - hook on registering browsers, as opposed to hook on launched browsers.
Karma will accept any browser tab that opens onto it...
2 - if ending the test nulls the suites object - then it could not be accessed naively in the named line.
perhaps closing the test and nulling it should implement wiser checks.

This is flaking on us as well. We get a different number of course.

Can you elaborate on the solutions that you proposed?
With the newest version 0.3.8 I get the following error:
var suite = suites[browser.id]
                  ^

TypeError: Cannot read property '72831859' of null
at [object Object].onBrowserComplete (h:\Projects\WDP\src\web\node_modules\karma-junit-reporter\index.js:102:23)
at [object Object]. (h:\Projects\WDP\src\web\node_modules\karma\lib\events.js:13:22)
at [object Object].emit (events.js:117:20)
at [object Object]._onTimeout (h:\Projects\WDP\src\web\node_modules\karma\lib\browser.js:50:15)
at Timer.listOnTimeout [as ontimeout] (timers.js:112:15)

I was getting this error regularly in a file watcher scenario. It would work the first time but fail often on subsequent runs. So I did some simple debugging and I found there are three functions at play. onRunStart, onBrowserStart, onRunComplete; they are intended to execute in that order.
I found this error occurs when onRunComplete executes before onBrowserStart.
As soon as I took restartOnFileChange out of my config file. I stopped getting the error.

Related: https://github.com/karma-runner/karma-junit-reporter/issues/20

@StanleyGoldman
I already have this in my karma-junit-reporter code: https://github.com/robrich/karma-junit-reporter/commit/836f89f04fc95f48278ac1780239127b0dfa81d7 but this hasn't solved my problem.
Can you elaborate on restartOnFileChange flag I cannot find it in karma-junit-reporte plugin doc. Do you have it in karma.config?
Thanks!

It's a karma setting that I put in my karma.conf.
Taking it out seemed to abate the issue.

Thanks @StanleyGoldman
I don't have this option enabled and I still get this error from time to time

I get this error too at random times on our Jenkins server

+1

Is https://github.com/karma-runner/karma-junit-reporter/issues/38 also related?

This is flaking for us as well.

Encountered this issue after this update:
"karma-phantomjs-launcher": "^0.2.1" ->  "karma-phantomjs-launcher": "^1.0.0"
"phantomjs": "^1.9.18"	 -> "phantomjs-prebuilt": "^2.1.7"
karma-junit version not changed and is 3.8.0
Bug reproduced on both linux (arch, ubuntu 14.04) and windows (10) with different bersions of node (4.2, 4.3) and npm (2.x, 3.x).
All tests are correct and karma works correctly without junit.
SUMMARY:
✔ 147 tests completed
[23:04:20] Finished 'test-single' after 8.9 s
07 04 2016 23:04:29.413:WARN [PhantomJS 2.1.1 (Linux 0.0.0)]: Disconnected (1 times), because no message in 10000 ms.
/home/doc/lab/test/Source/Web/node_modules/karma-junit-reporter/index.js:102
    var suite = suites[browser.id]
                      ^

TypeError: Cannot read property '30530595' of null
    at onBrowserComplete (/home/doc/lab/test/Source/Web/node_modules/karma-junit-reporter/index.js:102:23)
    at null.<anonymous> (/home/doc/lab/test/Source/Web/node_modules/karma/lib/events.js:13:22)
    at emitOne (events.js:95:20)
    at emit (events.js:182:7)
    at null._onTimeout (/home/doc/lab/test/Source/Web/node_modules/karma/lib/browser.js:50:15)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

I fixed the Disconnected (1 times), because no message in 10000 ms. problem by increasing the browserNoActivityTimeout setting in karma.config. The default value is 10000 but I found my browser (PhantomJS) was consistently closing due to the TypeError: Cannot read property '30530595' of null  before the tests finished running. Increasing to 30000 solved the issue for me.

I already reported it on the karma-runner-project, but maybe that was wrong: github-karma
Seems the error only occurs with the karma-junit-reporter:
PhantomJS 2.1.1 (Mac OS X 0.0.0): Executed 3281 of 3302 (skipped 21) SUCCESS (25.1 secs / 23.617 secs)
Missing error handler on 'socket'.
TypeError: Cannot read property '93062136' of null
  at onBrowserComplete (/PATH-TO/node_modules/karma-junit-reporter/index.js:120:23)
  at .<anonymous> (/PATH-TO/node_modules/karma/lib/events.js:13:22)
  at emitTwo (events.js:111:20)
  at emit (events.js:191:7)
  at onComplete (/PATH-TO/node_modules/karma/lib/browser.js:143:13)
  at Socket.<anonymous> (/PATH-TO/node_modules/karma/lib/events.js:13:22)
  at emitTwo (events.js:111:20)
  at Socket.emit (events.js:191:7)
  at Socket.onevent (/PATH-TO/node_modules/socket.io/lib/socket.js:335:8)
  at Socket.onpacket (/PATH-TO/node_modules/socket.io/lib/socket.js:295:12)
  at Client.ondecoded (/PATH-TO/node_modules/socket.io/lib/client.js:193:14)
  at Decoder.Emitter.emit (/PATH-TO/node_modules/component-emitter/index.js:134:20)
  at Decoder.add (/PATH-TO/node_modules/socket.io-parser/index.js:247:12)
  at Client.ondata (/PATH-TO/node_modules/socket.io/lib/client.js:175:18)
  at emitOne (events.js:96:13)
  at Socket.emit (events.js:188:7)
  at Socket.onPacket (/PATH-TO/node_modules/engine.io/lib/socket.js:101:14)
  at emitOne (events.js:96:13)
  at WebSocket.emit (events.js:188:7)
  at WebSocket.Transport.onPacket (/PATH-TO/node_modules/engine.io/lib/transport.js:104:8)
  at WebSocket.Transport.onData (/PATH-TO/node_modules/engine.io/lib/transport.js:115:8)
  at WebSocket.onData (/PATH-TO/node_modules/engine.io/lib/transports/websocket.js:76:30)
  at emitTwo (events.js:106:13)
  at WebSocket.emit (events.js:191:7)
  at Receiver.ontext (/PATH-TO/node_modules/ws/lib/WebSocket.js:816:10)
  at /PATH-TO/node_modules/ws/lib/Receiver.js:477:18
  at Receiver.applyExtensions (/PATH-TO/node_modules/ws/lib/Receiver.js:364:5)
  at /PATH-TO/node_modules/ws/lib/Receiver.js:466:14
  at Receiver.flush (/PATH-TO/node_modules/ws/lib/Receiver.js:340:3)
  at Receiver.opcodes.1.finish (/PATH-TO/node_modules/ws/lib/Receiver.js:482:12)
  at Receiver.expectHandler (/PATH-TO/node_modules/ws/lib/Receiver.js:451:33)
  at Receiver.add (/PATH-TO/node_modules/ws/lib/Receiver.js:95:24)
  at Socket.realHandler (/PATH-TO/node_modules/ws/lib/WebSocket.js:800:20)
  at emitOne (events.js:96:13)
  at Socket.emit (events.js:188:7)
  at readableAddChunk (_stream_readable.js:172:18)
  at Socket.Readable.push (_stream_readable.js:130:10)
  at TCP.onread (net.js:542:20)

PhantomJS 2.1.1 (Mac OS X 0.0.0) ERROR
  Disconnectedundefined

+1

https://github.com/karma-runner/karma/issues/1292

seems  to be related to usage of the karma-jasmine-html-reporter. If i exclude this reporter in karma everything is working

Mm. I've gotten this and never used the jasmine reporter.

Same here. i use the mocha reporter, the junit reporter, and sometimes the coverage reporter.

+1 Here
I use karma 1.3.0 and karma-junit-reporter 1.1.0

The same for me with "karma-htmlfile-reporter".
I use "karma" 1.3.0 and "karma-htmlfile-reporter" 0.3.4 and "phantomjs" 2.1.7.

+1
This one is pretty annoying. We also use karma-junit-reporter and karma-jasmine, but no jasmine reporter.
Increasing that timeout appears to do nothing for us either.

Alright. A little poking around in index.js seems to confirm that this bug lives in the karma-junit-reporter.
Adding the following snippet in various places that the suites object is accessed seems to help.
if( suites == null )
suites = Object.create(null)
Basically initializing that thing if events fire in a different order.

Any chance we can get a PR for this?

I can reproduce this consistently as described in https://github.com/karma-runner/karma-junit-reporter/issues/99#issuecomment-263997704. Fix #110 is already merged into master, see if that works for you?

I have that fix (https://github.com/karma-runner/karma-junit-reporter/pull/110). It doesn't help, unfortunately. Not sure why though.
I will have to look into it monday when I get back to work ;)

@randakar did you check out the code from master, rather than doing an npm install as the code with the fix hasn't been released yet. I will also look into it on Monday as it seems to be blocking all of our mac users from running their unit tests.
Not sure if this helps anything, but we have about 100 devs on Windows 7 and eight Redhat CI boxes and none of them seem to have been affected by the latest occurrence of this bug.

Yes. I checked out master when I built that patch and tested it. I will need to do some vesting to verify various potential solutions though. I wonder what is happening exactly and why.

.. testing. Silly autocorrect.

Alright. Quick testing seems to indicate that the commit in master actually changes the behaviour in question.
So my quick-and-dirty patch isn't necessary to fix this.
Nonetheless, I'm still getting the error listed above, so I would not be surprised if something else breaks now due to things running concurrently.
Also, I will send a new PR to implement robinj's suggestion to initialize suites earlier. It doesn't hurt, the whole way it's initialized now is slower and doing it early makes it pretty much immune to races.

@dignifiedquire I think this can be closed out now given the latest 1.2.0 release

This should be fixed, going to close this - comment here if it appears again with 1.2.0+ and we can reinvestigate.

I'm still getting this error for onBrowserComplete firing after onRunComplete. It only happens when I also add the "coverage" reporter/plugin, possibly because some lag is getting exacerbated by the extra overhead?

As I've mentioned before: lots of modules have this problem. "var suites" got copied all over the place. I bet the coverage reporter has it's own incarnation of it.

authors: Caradonna9 StanleyGoldman TheSavior TomaszScisloGS WuDo dcbrwn hypery2k ianwremmel ibbatta johnament mathiasmoeller mlc-mlapis nemoDreamer osherx pfrandsen randakar robinj shoesel stramel thatmarvin theBull wesleycho

repo: karma-runner/karma-junit-reporter


text:
TypeError: Cannot read property 'log' of undefined

07 11 2018 10:00:32.674:ERROR [karma-server]: TypeError: Cannot read property 'log' of undefined
    at TeamcityReporter.getLog (C:\repos\bitbucket\iicewebmdm\node_modules\karma-teamcity-reporter\index.js:126:29)
    at TeamcityReporter.specSuccess (C:\repos\bitbucket\iicewebmdm\node_modules\karma-teamcity-reporter\index.js:81:20)

karma-teamcity-reporter: 1.1.0
karma: 3.1.1
Angular: 7
karma-phantomjs-launcher: 1.0.4
I'm getting this error pretty consistently when running angular tests in parallel off phantomjs.  Is this an issue? Any possible fixes / workaround?

+1 Also experiencing this. Although it seems flaky.

+1, this is an issue for me.

Setting logLevel DEBUG http://karma-runner.github.io/3.0/config/configuration-file.html might help you debug this (I don't use this plugin).

Still facing it with karma-parallel.
logLevel DEBUG didn't help, but this comment did https://github.com/karma-runner/karma/issues/3342#issuecomment-513018754

Got the same issue with ChromeHeadless,
10 07 2020 12:24:59.551:ERROR [karma-server]: TypeError: Cannot read property 'log' of undefined     at TeamcityReporter.getLog (X:\work\1536afa0d351403c\Web\node_modules\karma-teamcity-reporter\index.js:126:29)     at TeamcityReporter.specSuccess (X:\work\1536afa0d351403c\Web\node_modules\karma-teamcity-reporter\index.js:81:20)     at TeamcityReporter.BaseReporter.onSpecComplete (X:\work\1536afa0d351403c\Web\node_modules\karma\lib\reporters\base.js:107:12)     at Server.<anonymous> (X:\work\1536afa0d351403c\Web\node_modules\karma\lib\events.js:40:26)     at Server.emit (events.js:187:15)     at Browser.onResult (X:\work\1536afa0d351403c\Web\node_modules\karma\lib\browser.js:159:20)     at Socket.socket.on (X:\work\1536afa0d351403c\Web\node_modules\karma\lib\browser.js:209:42)     at Socket.emit (events.js:182:13)     at X:\work\1536afa0d351403c\Web\node_modules\socket.io\lib\socket.js:528:12     at process._tickCallback (internal/process/next_tick.js:61:11)

I'm experiencing the same issue when running Karma with karma-teamcity-reporter (see the error below).
karma-teamcity-reporter: 1.1.0
karma: 5.1.1
angular: 10.0.2
karma-chrome-launcher: 3.1.0 with ChromeHeadless
I enabled DEBUG mode and the only thing that I can see is that the socket disconnects. I tried to dig in the report and could observe that when it crashes, the function onBrowserStart() is not called which won't initialise the browser at the beginning. Therefore, at the moment of reporting a message this.browserResults[browser.id] from getLog() won't be available and browserResult.log will be undefined.
The question is what could be the reason why Karma doesn't report the browser informations at startup and always call onBrowserStart() ?
[16:44:23][JavaScript Unit Tests] 07 08 2020 14:41:12.249:ERROR [karma-server]: UncaughtException:: Cannot read property 'log' of undefined [16:44:23][JavaScript Unit Tests] 07 08 2020 14:41:12.249:ERROR [karma-server]: TypeError: Cannot read property 'log' of undefined [16:44:23][JavaScript Unit Tests]     at TeamcityReporter.getLog (/opt/jetbrains/TeamcityBuildAgent/work/a0c7df66c0e3b0de/client/node_modules/karma-teamcity-reporter/index.js:126:29) [16:44:23][JavaScript Unit Tests]     at TeamcityReporter.specSuccess (/opt/jetbrains/TeamcityBuildAgent/work/a0c7df66c0e3b0de/client/node_modules/karma-teamcity-reporter/index.js:81:20) [16:44:23][JavaScript Unit Tests]     at TeamcityReporter.BaseReporter.onSpecComplete (/opt/jetbrains/TeamcityBuildAgent/work/a0c7df66c0e3b0de/client/node_modules/karma/lib/reporters/base.js:107:12) [16:44:23][JavaScript Unit Tests]     at Server.<anonymous> (/opt/jetbrains/TeamcityBuildAgent/work/a0c7df66c0e3b0de/client/node_modules/karma/lib/events.js:40:26) [16:44:23][JavaScript Unit Tests]     at Server.emit (events.js:203:15) [16:44:23][JavaScript Unit Tests]     at Browser.onResult (/opt/jetbrains/TeamcityBuildAgent/work/a0c7df66c0e3b0de/client/node_modules/karma/lib/browser.js:159:20) [16:44:23][JavaScript Unit Tests]     at Socket.socket.on (/opt/jetbrains/TeamcityBuildAgent/work/a0c7df66c0e3b0de/client/node_modules/karma/lib/browser.js:209:42) [16:44:23][JavaScript Unit Tests]     at Socket.emit (events.js:198:13)

To conclude: onBrowserStart and onRunStart sporadically don't get triggered when running a headless browser in TC. I don't know enough to estimate if this is a TC, Karma or browser problem.
A ugly fix could be checking if browserResult is undefined in this.getLog and call initializeBrowser if it is the case.

Just made a workaround, in karma.conf.js, patch the code like this
const tcReporterPlugin = require("karma-teamcity-reporter"); const TCReporter = tcReporterPlugin['reporter:teamcity'][1]; const specSuccess = TCReporter.specSuccess; const specFailure = TCReporter.specFailure; const specSkipped = TCReporter.specSkipped; TCReporter.specSuccess = function (browser, result) {   this.browserResults[browser.id] && specSuccess(browser, result); }; TCReporter.specFailure = function (browser, result) {   this.browserResults[browser.id] && specFailure(browser, result); }; TCReporter.specSkipped = function (browser, result) {   this.browserResults[browser.id] && specSkipped(browser, result); };
in plugins use like this:
plugins: [     require("karma-jasmine"),     tcReporterPlugin, ]

Just made a workaround, in karma.conf.js, patch the code like this
const tcReporterPlugin = require("karma-teamcity-reporter"); const TCReporter = tcReporterPlugin['reporter:teamcity'][1]; const specSuccess = TCReporter.specSuccess; const specFailure = TCReporter.specFailure; const specSkipped = TCReporter.specSkipped; TCReporter.specSuccess = function (browser, result) {   this.browserResults[browser.id] && specSuccess(browser, result); }; TCReporter.specFailure = function (browser, result) {   this.browserResults[browser.id] && specFailure(browser, result); }; TCReporter.specSkipped = function (browser, result) {   this.browserResults[browser.id] && specSkipped(browser, result); };
in plugins use like this:
plugins: [     require("karma-jasmine"),     tcReporterPlugin, ]

I made a workaround by creating a patcher like this in karma-teamcity-reporter-patcher.js:
module.exports = function(tcReporterPlugin) {

  const TCReporter = tcReporterPlugin['reporter:teamcity'][1];

  var newTCReporter = function(baseReporterDecorator) {
    TCReporter.call(this, baseReporterDecorator);

    var specSuccess = this.specSuccess;
    var specFailure = this.specFailure;
    var specSkipped = this.specSkipped;

    this.specSuccess = function(browser, result) {
      this.browserResults[browser.id] && specSuccess.call(this, browser, result);
    }

    this.specFailure = function(browser, result) {
      this.browserResults[browser.id] && specFailure.call(this, browser, result);
    }

    this.specSkipped = function(browser, result) {
      this.browserResults[browser.id] && specSkipped.call(this, browser, result);
    }
  }

  newTCReporter.$inject = TCReporter.$inject;

  tcReporterPlugin['reporter:teamcity'][1] = newTCReporter;

  return tcReporterPlugin;
}

Then in karma.config.js, use it like this:
const patcher = require("./karma-teamcity-reporter-patcher.js");
...

plugins: [
      require("karma-jasmine"),
      require("karma-chrome-launcher"),
      require("karma-firefox-launcher"),
      require("karma-coverage-istanbul-reporter"),
      teamcityReporterPatcher(require("karma-teamcity-reporter")),
      require("karma-spec-reporter"),
      require("@angular-devkit/build-angular/plugins/karma")
    ],

I made a workaround by creating a patcher like this in karma-teamcity-reporter-patcher.js:
module.exports = function(tcReporterPlugin) {

  const TCReporter = tcReporterPlugin['reporter:teamcity'][1];

  var newTCReporter = function(baseReporterDecorator) {
    TCReporter.call(this, baseReporterDecorator);

    var specSuccess = this.specSuccess;
    var specFailure = this.specFailure;
    var specSkipped = this.specSkipped;

    this.specSuccess = function(browser, result) {
      this.browserResults[browser.id] && specSuccess.call(this, browser, result);
    }

    this.specFailure = function(browser, result) {
      this.browserResults[browser.id] && specFailure.call(this, browser, result);
    }

    this.specSkipped = function(browser, result) {
      this.browserResults[browser.id] && specSkipped.call(this, browser, result);
    }
  }

  newTCReporter.$inject = TCReporter.$inject;

  tcReporterPlugin['reporter:teamcity'][1] = newTCReporter;

  return tcReporterPlugin;
}

Then in karma.config.js, use it like this:
const patcher = require("./karma-teamcity-reporter-patcher.js");
...

plugins: [
      require("karma-jasmine"),
      require("karma-chrome-launcher"),
      require("karma-firefox-launcher"),
      require("karma-coverage-istanbul-reporter"),
      teamcityReporterPatcher(require("karma-teamcity-reporter")),
      require("karma-spec-reporter"),
      require("@angular-devkit/build-angular/plugins/karma")
    ],

@dignifiedquire Is this repo still supported? E.g. this issue here is open for 2 and a half years now...

thanks @andy-maca! our first run with this patch was green - hopefully things stay green!

authors: Franziskus1988 Pringels andy-maca bobbyg603 hazems johnjbarton marius-hi nickbullock tmjeee

repo: karma-runner/karma-teamcity-reporter


text:
[cudnn_frontend] Error: No execution plans support the graph.

necktwi@CheapFellow:~/workspace/llm.c$ make train_gpt2cu USE_CUDNN=1 CUDNN_FRONTEND_PATH="/home/necktwi/workspace/cudnn-frontend/include"

necktwi@CheapFellow:~/workspace/llm.c$ ./train_gpt2cu
Multi-GPU support is disabled. Using a single GPU.
+-----------------------+----------------------------------------------------+
| Parameter             | Value                                              |
+-----------------------+----------------------------------------------------+
| train data pattern    | dev/data/tinyshakespeare/tiny_shakespeare_train.bin |
| val data pattern      | dev/data/tinyshakespeare/tiny_shakespeare_val.bin  |
| output log dir        | NULL                                               |
| checkpoint_every      | 0                                                  |
| resume                | 0                                                  |
| micro batch size B    | 4                                                  |
| sequence length T     | 1024                                               |
| total batch size      | 4096                                               |
| LR scheduler          | cosine                                             |
| learning rate (LR)    | 3.000000e-04                                       |
| warmup iterations     | 0                                                  |
| final LR fraction     | 1.000000e+00                                       |
| weight decay          | 0.000000e+00                                       |
| skip update lossz     | 0.000000                                           |
| skip update gradz     | 0.000000                                           |
| max_steps             | -1                                                 |
| val_loss_every        | 20                                                 |
| val_max_steps         | 20                                                 |
| sample_every          | 20                                                 |
| genT                  | 64                                                 |
| overfit_single_batch  | 0                                                  |
| use_master_weights    | enabled                                            |
| gelu_fusion           | 0                                                  |
| recompute             | 1                                                  |
+-----------------------+----------------------------------------------------+
| device                | NVIDIA GeForce RTX 2060                            |
| peak TFlops           | -1.0                                               |
| precision             | BF16                                               |
+-----------------------+----------------------------------------------------+
| weight init method    | gpt2_124M_bf16.bin                                 |
| max_sequence_length T | 1024                                               |
| vocab_size V          | 50257                                              |
| padded_vocab_size Vp  | 50304                                              |
| num_layers L          | 12                                                 |
| num_heads NH          | 12                                                 |
| channels C            | 768                                                |
| num_parameters        | 124475904                                          |
+-----------------------+----------------------------------------------------+
| train_num_batches     | 74                                                 |
| val_num_batches       | 20                                                 |
+-----------------------+----------------------------------------------------+
| run hellaswag         | no                                                 |
+-----------------------+----------------------------------------------------+
| Zero Optimization is disabled                                              |
| num_processes         | 1                                                  |
| zero_stage            | 0                                                  |
+-----------------------+----------------------------------------------------+
num_parameters: 124475904 => bytes: 248951808
allocated 237 MiB for model parameters
batch_size B=4 * seq_len T=1024 * num_processes=1 and total_batch_size=4096
=> setting grad_accum_steps=1
allocating 237 MiB for parameter gradients
allocating 1326 MiB for activations
allocating 474 MiB for AdamW optimizer state m
allocating 474 MiB for AdamW optimizer state v
allocating 474 MiB for master copy of params
device memory usage: 3652 MiB / 5740 MiB
memory per sequence: 331 MiB
 -> estimated maximum batch size: 10
[CUDNN ERROR] at file llmc/cudnn_att.cpp:120:
[cudnn_frontend] Error: No execution plans support the graph.

 ~/e/llm.c  master !1 ▓▒░ make train_gpt2cu USE_CUDNN=1                                          ░▒▓ 2 ✘  base Py  tesla@tesla  1 task  11:15:15 AM

CUDNN_FRONTEND_PATH = /usr/local/include/cudnn_frontend
---------------------------------------------
CUDNN_FRONTEND_PATH = /usr/local/include/cudnn_frontend
SHELL_UNAME = Linux
HOME = /home/tesla
Checking for cuDNN frontend path at /usr/local/include/cudnn_frontend
✓ cuDNN found, will run with flash-attention
✓ OpenMP found
✓ NCCL found, OK to train with multiple GPUs
✓ MPI enabled
✓ nvcc found, including GPU/CUDA support
---------------------------------------------
/usr/local/cuda/bin/nvcc -c --threads=0 -t=0 --use_fast_math -std=c++17 -O3 -DENABLE_CUDNN -DMULTI_GPU -DUSE_MPI -DENABLE_BF16 llmc/cudnn_att.cpp -I/usr/local/include/cudnn_frontend -I/usr/lib/x86_64-linux-gnu/openmpi/include/ -o build/cudnn_att.o
/usr/local/cuda/bin/nvcc --threads=0 -t=0 --use_fast_math -std=c++17 -O3 -DENABLE_CUDNN -DMULTI_GPU -DUSE_MPI -DENABLE_BF16 train_gpt2.cu build/cudnn_att.o -lcublas -lcublasLt -lnvidia-ml -lcudnn -L/usr/lib/x86_64-linux-gnu/openmpi/lib/ -I/usr/local/include/cudnn_frontend -I/usr/lib/x86_64-linux-gnu/openmpi/include/ -lnccl -lmpi -o train_gpt2cu

 ~/e/llm.c  master !1 ▓▒░ ./train_gpt2cu                                                     ░▒▓ ✔  33s  base Py  tesla@tesla  1 task  11:15:54 AM
+-----------------------+----------------------------------------------------+
| Parameter             | Value                                              |
+-----------------------+----------------------------------------------------+
| train data pattern    | dev/data/tinyshakespeare/tiny_shakespeare_train.bin |
| val data pattern      | dev/data/tinyshakespeare/tiny_shakespeare_val.bin  |
| output log dir        | NULL                                               |
| checkpoint_every      | 0                                                  |
| resume                | 0                                                  |
| micro batch size B    | 4                                                  |
| sequence length T     | 1024                                               |
| total batch size      | 4096                                               |
| LR scheduler          | cosine                                             |
| learning rate (LR)    | 3.000000e-04                                       |
| warmup iterations     | 0                                                  |
| final LR fraction     | 1.000000e+00                                       |
| weight decay          | 0.000000e+00                                       |
| skip update lossz     | 0.000000                                           |
| skip update gradz     | 0.000000                                           |
| max_steps             | -1                                                 |
| val_loss_every        | 20                                                 |
| val_max_steps         | 20                                                 |
| sample_every          | 20                                                 |
| genT                  | 64                                                 |
| overfit_single_batch  | 0                                                  |
| use_master_weights    | enabled                                            |
| gelu_fusion           | 0                                                  |
| recompute             | 1                                                  |
+-----------------------+----------------------------------------------------+
| device                | NVIDIA GeForce RTX 2060                            |
| peak TFlops           | -1.0                                               |
| precision             | BF16                                               |
+-----------------------+----------------------------------------------------+
| weight init method    | gpt2_124M_bf16.bin                                 |
| max_sequence_length T | 1024                                               |
| vocab_size V          | 50257                                              |
| padded_vocab_size Vp  | 50304                                              |
| num_layers L          | 12                                                 |
| num_heads NH          | 12                                                 |
| channels C            | 768                                                |
| num_parameters        | 124475904                                          |
+-----------------------+----------------------------------------------------+
| train_num_batches     | 74                                                 |
| val_num_batches       | 20                                                 |
+-----------------------+----------------------------------------------------+
| run hellaswag         | no                                                 |
+-----------------------+----------------------------------------------------+
| Zero Optimization is disabled                                              |
| num_processes         | 1                                                  |
| zero_stage            | 0                                                  |
+-----------------------+----------------------------------------------------+
num_parameters: 124475904 => bytes: 248951808
allocated 237 MiB for model parameters
batch_size B=4 * seq_len T=1024 * num_processes=1 and total_batch_size=4096
=> setting grad_accum_steps=1
allocating 237 MiB for parameter gradients
allocating 1326 MiB for activations
allocating 474 MiB for AdamW optimizer state m
allocating 474 MiB for AdamW optimizer state v
allocating 474 MiB for master copy of params
device memory usage: 3566 MiB / 5919 MiB
memory per sequence: 331 MiB
 -> estimated maximum batch size: 11
[CUDNN ERROR] at file llmc/cudnn_att.cpp:120:
[cudnn_frontend] Error: No execution plans support the graph.

The error is due to cudnn-frontend? or something else?

i meet the error too, have you slove it?  it's look like error from cudnn-frontend

Anyone having an idea how to address this? Using Ubuntu, CUDA 12.6 and cuDNN the same problem occurs.
(Without cuDNN extremely slow)

authors: Necktwi alphapibeta hotpotWithoutHemorrhoids kschmid


text:
crud增加字段说明

用 "=>" 标识字段说明，在 add/edit 界面的字段下方以 class="help-block" 的样式显示字段说明。
例：数据库字段注释为“开关=>开关关闭后前端不显示”，crud 后在 add/edit 对应字段底下显示灰色的说明文字“开关关闭后前端不显示”。

通过其他方式实现

repo: karsonzhang/fastadmin


text:
Default dark mode doesn't render properly

Do not fret! I fixed it!

repo: kartik-madhak/noter


text:
Format PDF

Problem
The current formatting of the pdf is making it hard to access the actual data.
Solution
Use email from a previous version, as supplied by client to improve the formatting. We should use the same code here and place it into the model.

This task is related to #101

repo: kartoza/watchkeeper


text:
Automatically sets orientation to portrait

Please fix this. The user wouldn't want to be forced to a different orientation than what they are already in.

I need to set "landscape", Same problem

Okay, good feedback. I'll add support for landscape in next version, pull requests for the same are appreciated.

authors: HosseinKurd kashifo rickyManalo

repo: kashifo/android-folder-picker-library


text:
Export improvements

It is currently not possible to export table properties in JSON – it should be enough to add the appropriate processor.
Export should be also documented better and properly tested for all the datasets (cf. #29).

Also add a checkbox "Export with properties". This can be integrated for both HTML and XLSX (although not CSV because the number of columns would not fit).

repo: kasnerz/tabgenie


text:
Improvements for release documentation

Our release documentation has gotten a bit stale and needs updating. Some of the issues I have identified:

[x] Update release cadence and add description about alpha releases/release candidate in Stable-Branch-Strategy.md. (https://github.com/kata-containers/documentation/issues/598)
[ ] Releases.md has gotten stale and needs to be revisited, perhaps combined with Stable-Branch-Strategy.md
Releases.md (https://github.com/kata-containers/documentation/blob/master/Releases.md) has a release checklist that certainly needs an update.
[ ]  We need to add documentation about release process using github actions.

cc @jodh-intel @egernst

Release documentation produces a dependency problem on Debian 10 Buster;
The following packages have unmet dependencies:
 kata-runtime : Depends: qemu-vanilla (= 4.1.1+git.99c5874a9b-46) but 4.1.0+git.9e06029aea-45 is to be installed
E: Unable to correct problems, you have held broken packages.

This error prevents me from installing the kata container runtime and other binaries, like shim.

@amshinde @jcvenegas - is this the package build issue that got fixed yesterday?

Hi @jeremiah - I've just installed on a Debian 10.3.0 system using https://github.com/kata-containers/documentation/blob/master/install/installing-with-kata-manager.md#full-installation with no issues.
Please could you raise a bug at https://github.com/kata-containers/packaging/issues/new including as much detail as you can on the problem.
Ironically, the kata-runtime package contains a problem determination script (https://github.com/kata-containers/runtime/blob/master/data/kata-collect-data.sh.in as /usr/bin/kata-collect-data.sh) but that won't be installed for you. You can build and run it though easily:
$ git clone https://github.com/kata-containers/runtime
$ cd runtime
$ make data/kata-collect-data.sh
$ sudo sh data/kata-collect-data.sh > /tmp/data.md

Thank you @jodh-intel! I will follow the instructions you provided!

@jeremiah We had seen the issue you mentioned, but have fixed it since then. Let us know if you are still seeing issues.

I hope to work on my installation today, thanks all for the response.

I installed kata-manager and everything installed fine but I couldn't restart docker. Trying to start the docker daemon manually gave me some useful output, the journal was vague and unhelpful. This was the error;
unable to configure the Docker daemon with file /etc/docker/daemon.json: the following directives are specified both as a flag and in the configuration file: default-runtime: (from flag: kata-runtime, from file: kata-runtime)
/etc/docker/daemon.json was removed and then Docker restarted successfully. I don't think your install process installs that file, though I'm not 100% sure, in any case, it causes problems. :-)

@jeremiah - indeed, docker (understandably) won't accept conflicting settings coming from both the config file and the command line. iirc, our installer is only smart enough to edit one of them, and if the other already has settings in it, there can be a conflict :-(
@amshinde - just want to check, should this issue be closed, as I think the original entry covered a few document updates, not all of which are 'ticked'.

@grahamwhaley All are ticked now :)

authors: amshinde grahamwhaley jeremiah jodh-intel

repo: kata-containers/documentation


text:
docs: Add a link to document describing how to use annotations

Add a link to the document listing the available annotations
Fixes: #756
Signed-off-by: Christophe de Dinechin dinechin@redhat.com

/test


text:
rootfs: fix golang version detection

When the rootfs creation is used for PRs there is
not a match with a kata runtime version, in this
case lets clone the runtime repository and checkout
to the kata branch target. If is already cloned
this mean this was set by depens-on script or the user.
Fixes: #326
Signed-off-by: Jose Carlos Venegas Munoz jose.carlos.venegas.munoz@intel.com

/test

/test

authors: egernst jcvenegas

repo: kata-containers/osbuilder


text:
vfio(sriov+switchdev) device passthrough fails with “Operation not permitted”

Description of problem
Using kata-runtime from with latest version(1.11.1), I test sriov NIC with config "sandbox_cgroup_only=true", also report error with “Operation not permitted”, and qemu vm started failed. But if I set sandbox_cgroup_only=false，there is no error, vm is started successfully.
I use k8s+containerd+kata-runtime-shimv2+qemu and network mode is switchdev+sriov. Kata-runtime consider the sriov interface in the sandbox netns as physical interface, so it use vfio to mount into the vm.
Expected result
The pod  starts and has sriov device(/dev/vfio/{id}) attached.
Actual result
The same error.
Warning FailedCreatePodSandBox 2s (x4 over 46s) kubelet, Failed create pod sandbox: rpc error: code = Unknown desc = failed to create containerd task: failed to launch qemu: exit status 1, error messages from qemu log: qemu-system-x86_64: -device vfio-pci,host=0000:3b:00.4,x-pci-vendor-id=0x15b3,x-pci-device-id=0x1018,romfile=: vfio error: 0000:3b:00.4: failed to open /dev/vfio/84: Operation not permitted
The log belows:
Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.767948982+08:00" level=info msg="loaded configuration" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 file=/data/kata/share/defaults/kata-containers/configuration-qemu.toml format=TOML source=katautils Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.768039539+08:00" level=debug ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 default-kernel-parameters="systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket" source=katautils Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.768465049+08:00" level=debug msg="container rootfs: /root/tce/containerd/run/daemon/io.containerd.runtime.v2.task/k8s.io/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/rootfs" source=virtcontainers subsystem=oci Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.770638839+08:00" level=debug msg="restore sandbox failed" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 error="open /run/vc/sbs/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/persist.json: no such file or directory" sandbox=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=sandbox Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.770685291+08:00" level=debug msg="Creating bridges" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=qemu Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.77070504+08:00" level=debug msg="Creating UUID" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=qemu Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.771238099+08:00" level=debug msg="Disable nesting environment checks" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 inside-vm=false source=virtcontainers subsystem=qemu Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.771565033+08:00" level=info msg="adding volume" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=qemu volume-type=virtio-9p Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.772286581+08:00" level=info msg="Physical network interface found" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 interface=eth0 source=virtcontainers subsystem=network Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.772815577+08:00" level=info msg="Endpoints found after scan" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 endpoints="[0xc0000f2a00]" source=virtcontainers subsystem=network Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.7728695+08:00" level=info msg="Attaching endpoint" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 endpoint-type=physical hotplug=false source=virtcontainers subsystem=network Jun 12 11:14:40 kata[1850343]: time="2020-06-12T11:14:40.772894941+08:00" level=info msg="Unbinding device from driver" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 device-bdf="0000:3b:00.3" driver-path="/sys/bus/pci/devices/0000:3b:00.3/driver/unbind" source=virtcontainers subsystem=device Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.3118116+08:00" level=info msg="Writing vendor-device-id to vfio new-id path" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=device vendor-device-id="0x15b3 0x1018" vfio-new-id-path=/sys/bus/pci/drivers/vfio-pci/new_id Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.312110237+08:00" level=info msg="Binding device to vfio driver" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 device-bdf="0000:3b:00.3" driver-path=/sys/bus/pci/drivers/vfio-pci/bind source=virtcontainers subsystem=device Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.312243935+08:00" level=debug msg="Network added" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=network Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.334822937+08:00" level=info msg="Starting VM" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 sandbox=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=sandbox Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.334915029+08:00" level=debug ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 default-kernel-parameters="tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug" source=virtcontainers subsystem=qemu Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.335072446+08:00" level=info msg="launching /data/kata/bin/qemu-system-x86_64 with: [-name sandbox-3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 -uuid 767679a8-99d6-4e64-877c-3fa806398490 -machine pc,accel=kvm,kernel_irqchip,nvdimm -cpu host -qmp unix:/run/vc/vm/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/qmp.sock,server,nowait -m 2048M,slots=10,maxmem=386179M -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= -device virtio-serial-pci,disable-modern=false,id=serial0,romfile= -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/console.sock,server,nowait -device nvdimm,id=nv0,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/data/kata/share/kata-containers/kata-containers.img,size=402653184 -device virtio-scsi-pci,id=scsi0,disable-modern=false,romfile= -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0,romfile= -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 -chardev socket,id=charch0,path=/run/vc/vm/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/kata.sock,server,nowait -device virtio-9p-pci,disable-modern=false,fsdev=extra-9p-kataShared,mount_tag=kataShared,romfile= -fsdev local,id=extra-9p-kataShared,path=/run/kata-containers/shared/sandboxes/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/shared,security_model=none -device vfio-pci,host=0000:3b:00.3,x-pci-vendor-id=0x15b3,x-pci-device-id=0x1018,romfile= -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic -daemonize -object memory-backend-ram,id=dimm1,size=2048M -numa node,memdev=dimm1 -kernel /data/kata/share/kata-containers/vmlinuz-4.19.86-60 -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug panic=1 nr_cpus=96 agent.use_vsock=false systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket scsi_mod.scan=none rw -pidfile /run/vc/vm/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/pid -D /run/vc/vm/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/qemu.log -smp 1,cores=1,threads=1,sockets=96,maxcpus=96]" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=qmp Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.370674027+08:00" level=error msg="Unable to launch /data/kata/bin/qemu-system-x86_64: exit status 1" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=qmp Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.370727817+08:00" level=error ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=qmp Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.370769312+08:00" level=error msg="failed to launch qemu: qemu-system-x86_64: -device vfio-pci,host=0000:3b:00.3,x-pci-vendor-id=0x15b3,x-pci-device-id=0x1018,romfile=: vfio error: 0000:3b:00.3: failed to open /dev/vfio/83: Operation not permitted\n" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 error="exit status 1" source=virtcontainers subsystem=qemu Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.370873008+08:00" level=info msg="Detaching endpoint" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 endpoint-type=physical source=virtcontainers subsystem=network Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.370898209+08:00" level=info msg="Unbinding device from driver" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 device-bdf="0000:3b:00.3" driver-path="/sys/bus/pci/devices/0000:3b:00.3/driver/unbind" source=virtcontainers subsystem=device Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.371167118+08:00" level=info msg="Binding back device to host driver" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 device-bdf="0000:3b:00.3" driver-path=/sys/bus/pci/drivers/mlx5_core/bind source=virtcontainers subsystem=device Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.765714726+08:00" level=debug msg="Network removed" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=network Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.765764816+08:00" level=debug msg="Deleting sandbox cgroup" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 sandbox=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 source=virtcontainers subsystem=sandbox Jun 12 11:14:41 kata[1850343]: time="2020-06-12T11:14:41.7858325+08:00" level=info msg="cleanup agent" ID=3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074 path=/run/kata-containers/shared/sandboxes/3656ccc016ed2c4efca0795472f14e055c89be54fd8ef260e9c29d52576fc074/shared source=virtcontainers subsystem=kata_agent

#2605

@yadzhang please take a look https://github.com/kata-containers/runtime/pull/2775

authors: devimc yadzhang

repo: kata-containers/runtime


text:
runtime: Do not error if only initrd/rootfs image installed

If only initrd or rootfs image is installed,
allow to start Kata Containers without erroring
out.
Fixes:  #1174
Signed-off-by: Nitesh Konkar niteshkonkar@in.ibm.com

/retest

/retest

Ping for review. cc @grahamwhaley @jodh-intel
@Pennyzct ARM CI is failing due to non-PR related issues.

@GabyCT @chavafg ping

/retest

Good to merge? @grahamwhaley @jodh-intel

has two acks.
Failed CIs are known issues (ARM, fc)
pullapprove is dead, long live pullapprove
the zuul WIP/SoB have not reported - but, I've manually checked they are present etc.
So, force merging..

authors: grahamwhaley nitkon ydjainopensource


text:
Create 0000-01-02-kavehbrj.md

plz check what I have done:
created a branch, created a file and made a commit, and opened a pull request

first marge

repo: kavehbrj/github-slideshow


text:
pypika release on PyPI missing join convenience methods

I installed pypika with pip install pypika, which installs version PyPika==0.35.15. I tried to use the left_join method mentioned in the README with the example query in the tests:
>>> from pypika import JoinType, Query, Tables
>>> table0, table1, hij = Tables('abc', 'efg', 'hij')
>>> Query.from_(table0).join(table1, how=JoinType.left).on(table0.foo == table1.bar).select("*")
SELECT * FROM "abc" LEFT JOIN "efg" ON "abc"."foo"="efg"."bar"

>>> Query.from_(table0).left_join(table1).on(table0.foo == table1.bar).select("*")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'Field' object is not callable

The latest version of pypika on PyPI (https://pypi.org/project/PyPika/0.35.15/) does not contain the join convenience methods. Would it be possible to update the version of pypika on PyPI?
Thank you for creating the library!

Those functions were added in 0.35.16... maybe I forgot to publish it.. let me check

ok yeah looks like there was a compile error in the README.rst that prevented the publish. Fixed now and published.

repo: kayak/pypika


text:
SLF4J related message

When I executed com/kazurayam/materialstore/demo/OpenWeatherMapClinet, I saw the following messages in the console. I want to get rid of them.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

http://www.slf4j.org/codes.html#StaticLoggerBinder

This happens when no appropriate SLF4J binding could be found on the class path. Placing one (and only one) of slf4j-nop.jar slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should solve the problem.

in the build.gradle, i added
// https://mvnrepository.com/artifact/ch.qos.logback/logback-classic
testImplementation group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.3'

I see no longer see the message when I execute the OpenWeatherMapClient

repo: kazurayam/materialstore


text:
Hyphenation in safari

If I insert a raw line of long-sized code, then editing becomes impossible.

example code:
<script type="text/javascript">
     (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
     ga('create', 'UA-1111111111-1’, 'auto');
     ga('require', 'ecommerce');
     ga('require', 'displayfeatures');
     ga('send', 'pageview');
</script>

Looks like a bug restricted to Safari. Chrome and FF worked flawlessly. Probably something with the white-space or line-break properties. Will dig into it.

authors: kazzkiq tabuna

repo: kazzkiq/CodeFlask


text:
Implement Tracing

closes #52

Ready to review @Meir017

Ready to review @Meir017

repo: kblok/puppeteer-sharp


text:
chore: bump lib to v0.8.5

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[x] N
[ ] Y

chore: bump lib to v0.8.5

2. What is the scope of this PR (e.g. component or file name):

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Other

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

[ ] N
[ ] Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

[ ] Unit test
[ ] Integration test
[ ] Benchmark (add benchmark stats below)
[ ] Manual test (add detailed scripts or steps below)
[ ] Other

Pull Request Test Coverage Report for Build 8755112985
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 37.003%

Totals

Change from base Build 8660186599:
0.0%

Covered Lines:
121

Relevant Lines:
327

💛  - Coveralls

authors: Peefy coveralls

repo: kcl-lang/cli


text:
chore: bump kcl version to 0.10.6

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[x] N
[ ] Y

chore: bump kcl version to 0.10.6

Pull Request Test Coverage Report for Build 11491755971
Details

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.004%) to 70.51%

Files with Coverage Reduction
New Missed Lines
%

kclvm/sema/src/core/scope.rs
3
68.33%

kclvm/sema/src/core/symbol.rs
3
53.48%

Totals

Change from base Build 11491506425:
-0.004%

Covered Lines:
51737

Relevant Lines:
73375

💛  - Coveralls

repo: kcl-lang/kcl


text:
🛑 营销平台API is down

In aec91a0, 营销平台API (https://api.dgshare.com) was down:

HTTP code: 502
Response time: 2297 ms

Resolved: 上海购物API is back up in dbe21a8.

repo: kdcer/upptime


text:
Error running lua:

Getting the following error in CI on github:
Error running Lua:
No render function for Block value 'Figure';
define a function `Writer.Block.Figure` that returns a string or Doc.
stack traceback:
	/scripts/panvimdoc.lua:61: in upvalue 'blocks'
	/scripts/panvimdoc.lua:196: in function 'pandoc.scaffolding.Writer.Pandoc'
	while rendering Pandoc
stack traceback:

I dont think this is solved. I am getting this now:
No render function for Inline value 'Quoted';
define a function `Writer.Inline.Quoted` that returns a string or Doc.
stack traceback:
      /scripts/panvimdoc.lua:52: in upvalue 'inlines'
      /scripts/panvimdoc.lua:261: in function 'pandoc.scaffolding.Writer.Block.Para'
      /scripts/panvimdoc.lua:61: in upvalue 'blocks'
      /scripts/panvimdoc.lua:195: in function 'pandoc.scaffolding.Writer.Pandoc'
      while rendering Pandoc

Can you point me to the README file that is causing the error? If I'm able to test it locally I should be able to fix it.

Thank you.
Seems to be solved now.

authors: kdheepak tzachar

repo: kdheepak/panvimdoc


text:
Moving the repo to an organization

Dear colleagues,
I'm planning to move this repository to an organization. I would still like to retain control of merges for now (to maintain consistency and style as we grow), but I think we have enough content in the package where it's important to signal to the community and prospective users that this is now a team effort.
I've reserved "TidierOrg" for now on GitHub. "Tidier" is already taken, and its owner hasn't replied to my outreach. This would be similar to "MakieOrg" and would help distinguish the organization from the underlying packages. We could ask to join an existing organization as well but I think we will be wrapping packages across the ecosystem and thus it may make sense to keep this as a separate (but parallel) effort.
Thoughts on TidierOrg?
Cc: @pdimens @lazarusA @camilogarciabotero @rdboyes @pitmonticone @zhezhaozz

I'm anticipating we will have at least 3 packages in the near future:

Tidier.jl (meta-package)
TidierData.jl (all the DataFrame-oriented macros/functions in one place)
TidierPlots.jl (all the AoG-based plotting functions in one place)

And potentially... TidierTools.jl, which would make it easier for other folks to write Tidier-style macros.

Honestly, I think it should be part of JuliaData where also DataFrames.jl currently lives in. I feel that having another org will split the Julia Ecosystem ever further. But, that's just my opinion.

Appreciate the idea, @lazarusA. My main hesitations re: this are:

The package is likely to expand into plotting, which currently lives outside of JuliaData
The package uses a non-idiomatic coding style, which I think may be better co-located in a separate org

I personally view this package as a front-end to a number of other packages (and thus interdependent w/ other packages), not something intended to split the community further.

The package is likely to expand into plotting, which currently lives outside of JuliaData
The package uses a non-idiomatic coding style, which I think may be better co-located in a separate org

Agree with @kdpsingh, Tidier is not only about data manipulation in the future, and it's more a front-end to a number of other packages. I just feel that it would be a little strange to co-locate with other packages that have completely different coding style and design philosophy.

I think a separate organization is OK. TidierOrg makes sense. I guess we would make it explicit that the ecosystem is meant to make it easy for R users to make transition to Julia in as frictionless way as possible. Right?

Thanks @bkamins. Yes, the explicit intent of the org would be to make it easier for R users to transition to Julia.
We will make sure to place a spotlight on the underlying packages we are wrapping to ensure that folks can make the transition to idiomatic Julia packages.

folks can make the transition to idiomatic Julia packages

I see it as opt-in. I think many folks will be happy enough with focusing on learning TidierOrg only.

Hi everyone, welcome to TidierOrg!

authors: bkamins kdpsingh lazarusA zhezhaozz


text:
Fixed bug in response mapping

Jira: https://keboola.atlassian.net/browse/PSGO-260
Slack: https://keboolaglobal.slack.com/archives/C0553EM2RGX/p1691058230258039
Changes:

Fixed bug in response mapping:

type ColumnMetadata map[string]MetadataDetail
:arrow_right:
type ColumnMetadata map[string][]MetadataDetail

Improved tests.

Added operation: CreateOrUpdateTableMetadata

It will be used also in Stream UI backend changes, to mark tables used by the Stream API (for UI).

@zajca lebo pri zakladani novej tabulky (noveho exportu) tam ziadne metadata nemas, v tickete sa snazia pouzit existujucu + ma metadata.

repo: keboola/go-client


text:
BIG-250 set primary key table constrain when creating table

Jira: BIG-250
Connection PR: XXX
SAPI PR: XXX

👁

authors: romanbracinik zajca

repo: keboola/php-storage-driver-bigquery


text:
Shared aliases

https://github.com/keboola/connection/pull/1650
Testy
Čtení z aliasů

[ ] řetezení aliasu 2x, 3x a test export aliasu
[ ] řetezení aliasu 2x, 3x a test load do workspace
[ ] řetezení aliasu 2x, 3x a test load clone do workspace
[ ] sdílení aliasu a test export aliasu
[ ] sdílení aliasu a test load do workspace
[ ] sdílení aliasu a test clone do workspace

Propagace změn a omezení

[ ] smazání zdrojové tabulky
[ ] zápis do zdrojové tabulky - propagace event aliasům
[ ] smazání aliasu který má pod sebou aliasy
[ ] smazání sloupce zdrojové tabulky a propagace do aliasů (alespoň 2x aliasované)
[ ] není možné nastavit filtr aliasu který má pod sebou aliasy
[ ] není možné odebrat columns autosync aliasu který má pod sebou aliasy
[ ] není možné aliasovat alias bez nastaveného columns autosync
[ ] není možné aliasovat alias s nastaveným filtrem

nahrazuju https://github.com/keboola/storage-api-php-client/pull/286

authors: Actimel Halama

repo: keboola/storage-api-php-client


text:
Fallback wrapper scaler

Proposal
A metrics source can become unavailable. This causes it to be ignored if there are multiple scalers present. The proposal is to add a new scaler that would delegate to a wrapped instance of another scaler. If that delegate fails, it would provide a fallback metrics of fallbackReplicas/currentReplicas (a little like the cron scaler).
Scaler Source
A delegate scaler, falling back to a configured replica value
Scaling Mechanics
A proposed configuration could look something like the following:
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: feed-ingress
  namespace: feed-main-elb
spec:
  scaleTargetRef:
    deploymentName: feed-ingress
  minReplicaCount: 2
  maxReplicaCount: 10
  triggers:
    - type: fallback
      metadata:
        fallbackReplicas: 8
        delegate:
          type: prometheus
          metadata:
            serverAddress: http://prometheus.hpa-test.svc:9090/
            metricName: feed_ingress_ingress_requests
            threshold: '100'
            query: sum(rate(feed_ingress_ingress_requests{namespace="feed-main-elb"}[2m]))

The catch with this is the current type of TriggerMetadata is map[string]string. Because of this, either that type has to be changed to handle arbitrary object values, or the config has to be flattened. I think the former is preferred to avoid awkward config for users.
Authentication Source
Delegate
Anything else?
This is a continuation of some thoughts from https://github.com/kedacore/keda/issues/965
We are happy to contribute this, but would like some discussion about the approach

So to summarize, if it can't get metrics for Prometheus you want it to fallback to 8 instances, is that correct?

Just to refine that; we would like this trigger/scaler to present as "8 instances" from the HPA. Other scalers would continue to work as normal and HPA would just take the maximum of all of them.

In that case, have you considered to change the configuration the other way around?
Something like this:
triggers:
- type: prometheus
  metadata:
    # Required
    serverAddress: http://<prometheus-host>:9090
    metricName: http_requests_total
    query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response
    threshold: '100'
  fallback:
    # Optional
    replicas: 8

I think that looks good, but maybe we should even flatten to fallbackReplicas as a single property.
Without forgetting about implementation, I think this also simplifies the approach. A new scaler that acts with a delegate probably still makes sense.

The reason why I'm not keeping it flat is so that we can add more things alter on if we want to. For example, send a notification or something.

That makes sense. Implementation-wise we've realised it might be a bit difficult to define the target  (GetMetricsSpecForScaling) when the delegate GetMetrics call fails. The cron scaler works off the premise that the underlying metric will always be the average, but we can't assume that for an arbitrary delegate. :thinking:

This feels like a very overcomplicated solution? We would we not just let the current scale stay when things are broken? That seems like a safer behavior. Having a pinned fallback like this could get very flappy during partial failure scenarios.

I think you would want more safety when your metrics sources are not available. If your application is scaled to its minimum replicas, and is suddenly hit with load while your metrics sources are down, it could easily be overloaded. If you have a safe fallback (it could be your maximum replicas to be extra safe), then you will always be able to handle that load.

My worry is if Prom (or anything else) is overloaded and timing out on ~50% of requests, you could suddenly have a situation where your replica count is rapidly shifting between whatever it's supposed to be at and the fallback number. This would likely put a lot of stress on things. I guess that's fine as long as recommend people set their HPA cooldown parameters when using this feature? That way it would stay at the higher one until things stabilize (or until the cooldown expires).

Yeah, that situation makes sense. But I think the fact that by default HPA scales up immediately when it needs to and has a default stabilisation window of 5 minutes would alleviate this. Yes, it might be worth documenting that aggressive scale-down configurations should be avoided when using this feature.

This feels like a very overcomplicated solution? We would we not just let the current scale stay when things are broken? That seems like a safer behavior. Having a pinned fallback like this could get very flappy during partial failure scenarios.

I do get your concern but like @mishamo is saying I can see value in specifying a fallback. However, it should only kick in after x cycles of checking, not for every failure imo, and come with the required bells and whistles around it such as putting the SO in degraded state or so and emit kubernetes events.

Yes. I was thinking about this myself and came to the same conclusion; we would only want this to happen after a few (configurable) consecutive failed attempts. This likely complicates the implementation somewhat but is probably the right move.

Why not both? :)
In the fallback section, users could specify either the exact number of replicas or an option to stay on the current replicas number.
I agree with Tom's suggestion on keeping the configuration simple in this comment: https://github.com/kedacore/keda/issues/1872#issuecomment-857621978

In the fallback section, users could specify either the exact number of replicas or an option to stay on the current replicas number.

Isn't this the existing behaviour? If so, that would be the same as not including the fallback section at all.

In the fallback section, users could specify either the exact number of replicas or an option to stay on the current replicas number.

Isn't this the existing behaviour? If so, that would be the same as not including the fallback section at all.

If there's a problem in connecting the scaler isActive() returns false and the replicas will by scaled to minReplicaCount.
And this is the problem we are trying to solve here, right? So I thought that as a fallback, there could be a specific number of replicas (eg my Prometheus is down, let's not scale to min, but scale for example to 3 replicas, to handle average load) or the second option could be to stay on the current replicas.

It will stay on the current replicas, but not one you can define

why?

There's two separate issues:

If there's an issue with isActive, then things stay the same unless your minReplicas is set to 0 as per the logic here: https://github.com/kedacore/keda/blob/fb76638a5a8001b2fdc6417a4724c9df082d5cd8/pkg/scaling/executor/scale_scaledobjects.go#L57 . This only really applies if all scalers are inactive/broken due to this loop https://github.com/kedacore/keda/blob/fb76638a5a8001b2fdc6417a4724c9df082d5cd8/pkg/scaling/scale_handler.go#L227. I have code to potentially address this issue here: https://github.com/mishamo/keda/commit/8aca785e1abba46e79809f28bc81dc2de5fc7c59
If you have multiple triggers/sources of metrics (e.g. two separate prometheus instances) and only one is failing, then that failing one will be completely ignored. This issue is to address that source; if it is down, then the HPA for that source should instruct k8s to scale to a fallback number of replicas. More generally I think this concerns the call to GetMetrics rather than IsActive and wrapping that in some fallback logic.

It will stay on the current replicas, but not one you can define

why?

That is how it is today, no? You cannot define what to scale to on failure

Ok. I think we have an approach that should work and feels acceptable to us. It is as follows:

We add an optional fallback config at the same level as triggers:

...
fallback:
  failureThreshold: 3
  fallbackReplicas: 10
triggers:
...

We also add an array of nameOfMetric -> FallbackStatus to the ScaledObject Status. Something like:

 status:
   ...
   fallback:
     some_metric_name:
       numberOfFailures: 2
       status: Pending

We house the fallback logic in provider.go, which, for each scaler, would call GetMetrics on it, update the fallback status on the relevant metric name in the status map and return a normalised (fallbackReplicas * targetMetricFromSpec) value as the metric if fallback has been triggered.
If fallback is defined, it would apply to all triggers within a ScaledObject.
This feature is only compatible with metrics whose spec type is AverageValue (all current scalers except cpu/memory, and possibly the external ones).

Ok. I think we have an approach that should work and feels acceptable to us. It is as follows:

We add an optional fallback config at the same level as triggers:

...
fallback:
  failureThreshold: 3
  fallbackReplicas: 10
triggers:
...

I would propose this instead: (nit)
...
fallback:
  failureThreshold: 3
-  fallbackReplicas: 10
+  replicas: 10
triggers:
...

In terms of the status, does it have to fall in the fallback category? Imagine I'm not using it, I would still be interested to see the # of failures in the status field.

No issue with the change of fallbackReplicas -> replicas.
   fallback:
     - some_metric_name:
         numberOfFailures: 2
         status: Pending

The only limitation with moving the map out of fallback, is the status field we added. The current idea for this is that there would be three states of Happy, Pending and Failing, where Pending would be in place until the failureThreshold was reached. If the user isn't using the fallback feature, then no failureThreshold would be defined. I suppose it would be possible to  either remove the Pending state completely or simply go straight to Failing when no fallback config is defined. Reasonably happy with either approach. Also if it doesn't sit under fallback, it would still have to sit under some name, as the data structure is a map; possibly scalers?

What if we can it health because it basically comes down to that?
What do you think @zroubalik ?

Sorry for the long response time, I was overhelmed with other stuff.
Pardon my ingorance, I am still trying to understand what is the specific ask, what is the scenario you'd like to cover? You want to define the fallback per ScaledObject or per Scaler(trigger)?
Let's say we have these triggers in a ScaledObject:
scaler1: 10
scaler2: 5
scaler3: failure

You can have one trigger or mutliple triggers and if one of the external sources are failing or are unavailable, then you'd like to set some fallback metric number for that particular scaler?
In our case mentioned above the HPA will calculate the desired replicas count based on the numbers from each scaler and it will use fallback number for the failing scaler3, eg 6. In this case the greatest number - scaler1 will win)

Or do you want to convice HPA to use fallback as a desired number if there is some problem and don't do the calculation for other scalers? So if fallback is 6, then this will be used by HPA and not the greatest number (scaler1)

Hi @zroubalik, the original idea was to define the fallback per Scaler (trigger), but as this was more complicated to implement, we decided to shift the fallback definition to the ScaledObject (which is still a fallback per scaler, it's just that the same fallback would be used for all scalers on that object).
The use case described in 1. looks correct to me.

@mishamo  okay. Sounds good

How do you plan to count the number of failures? For example if you have 3 scalers and first one starts to fail and then another scaler starts to fail as well?

The plan is to maintain a map of external_metric_name -> fallback_status in the Status field in k8s. Then the scalers can be looked up by their relative metric names and the number of failures can be read/bumped up/reset etc

Okay, so you don't plan to sum the failures from all scalers, ack.
Anything else you'd like to discuss? The proposal looks good for me 👍

Nope, I think we're all good for now. We have some code that should work on https://github.com/mishamo/keda/tree/fallback-scaler, but there's quite a lot of testing to be done before we create a PR. Just to clarify there's 2 pieces of work:

defaultReplicas behaviour when IsActive throws an error (from #965), which is currently on the master branch of the fork linked above.
The work discussed in this issue when GetMetrics throws an error.

When we come to it, should we PR these as separate PRs or is it OK to PR as one?

I think that one PR is fine (if it is not huge, because reviewing is a bit harder in that case).
Yeah, those are all valid concerns. Thanks a lot for the investigation and the work on this. Once you feel that you are somehow happy with the solution, open a PR and we can follow up the discussion over there.

Re-opening since code wasn't merged yet

authors: coderanger mishamo tomkerkhove zroubalik

repo: kedacore/keda


text:
Possible connections leak in kafka scaler

Report
There appears to be a connections leak in the kafka scaler.
Scenario:
We had keda working fine with a kafka scaler.  The MSK cluster ran out of disk space which caused it to be unaccessible to keda.  We resolved the disk space issue by scaling the broker storage.  After this keda appears to have returned to normal, however one of the MSK brokers was reporting an unusually high amount of connections and requests from the keda metrics apiserver (thousands of requests and connections in a 5m period).  upon restart of the apiserver pod, the connection and request count goes back to normal (<30 conn/requests in a 5m period to the brokers)
We have two different keda deployments pointing to this MSK cluster (watching different consumer groups).  Both behaved the same way.  This is a problem we've been trying to root cause for 2wks now and only today were able to track down the source of the connections to keda.  I have cloudwatch graph of the past 2wks where we tried rebooting brokers, etc. but nothing seemed to eliminate the tcp connections until today when we rebooted the two keda metrics apiserver pods.
I can try and obtain the logs from these pods if it may be useful.  But they may be extremely verbose and large (we have trace logging enabled still as we only recently started using keda and were having issues properly configuring scaled objects for kafka).  Please lmk what may be useful for troubleshooting this further if this has not been enough data.
Expected Behavior
Interruptions in kafka server availability do not inadvertantly degrade the clusters performance upon renewal of service
Actual Behavior
Once the cluster was restored, the increase in connections from the scaler caused the MSK cluster to be in an extremely poor state.  These specific brokers(instance types) are not designed to handle the thousands of connections the apiserver was throwing at it.
Steps to Reproduce the Problem

See description

Logs from KEDA operator
See description
KEDA Version
2.7.1
Kubernetes Version
1.21
Platform
Amazon Web Services
Scaler Details
Apache Kafka
Anything else?
No response

Thanks for reporting this!
To clarify, you can see those connections only in KEDA Metrics Server not in the Operator, right? We need to track down, whether this is bad behavior in KEDA or whether the problem is in the Sarama client itself 🤔

1 SO and thousands of connections? 🤔 That's not good. Would be great if we can somehow isolate the problem and have reproducer that doesn't depend on your setup, Strimzi or something like that.

1 SO and thousands of connections? 🤔 That's not good. Would be great if we can somehow isolate the problem and have reproducer that doesn't depend on your setup, Strimzi or something like that.

Technically for the kafka cluster, there were two SOs pointing at it.  Two different k8s clusters with the SO above running with only the topic and consumer group being different.

Yeah. And until there aren't any problems with the broker you don't see any rise in the number of connections, right?

Correct.  Until we ran out of storage space on the brokers, the connection count from the apiserver was minimal.

Are you able to somehow reproduce the problem? It would be awesome if you can do so. There's one part of code which could be the potential problem, though I'd need to have a way how to reproduce the problem to clarify that I am right and that the proposed fix works as expected.

Sorry, no.  We do not have a test environment where I can reproduce this issue.  This happened on a semi-important system and we cant have another outage like this.

Just for a reference adding the link to the potential problem:
https://github.com/kedacore/keda/blob/af80d84b4e95536bde4d3b4ee51785214d01dac9/pkg/scaling/cache/scalers_cache.go#L209
        sb := c.Scalers[id]
	ns, err := sb.Factory()
	if err != nil {
		return nil, err
	}

	c.Scalers[id] = ScalerBuilder{
		Scaler:  ns,
		Factory: sb.Factory,
	}
	sb.Scaler.Close(ctx)

	return ns, nil

->
        defer sb.Scaler.Close(ctx)
        sb := c.Scalers[id]
	ns, err := sb.Factory()
	if err != nil {
		return nil, err
	}

	c.Scalers[id] = ScalerBuilder{
		Scaler:  ns,
		Factory: sb.Factory,
	}

	return ns, nil

I'm trying to replicate this issue but I cannot do it. Could you give me any tip to reproduce this? I'm trying dropping the cluster connection but I can't see any connection leak. I'm deploying a MSK and I'll try to replicate disk issues, but maybe you can give me some tips

I have tried the same, locking the disks filling them (with KEDA connected all the time) and I haven't been able to reproduce your issue, once I have solved the issues with disks increasing the disk size, KEDA has started again without any huge increase of connections. I'd need more info about how to reproduce it to continue.
I have tried with a kafka cluster deployed using strimzi

authors: JorTurFer ryan-dyer-sp zroubalik