text:
Fix controller widget so analog axes are visible.

CC @SylvainCorlay.

@afshin - I finally got a game controller so I could test this!

Cool!

authors: afshin jasongrout

repo: ipython/ipywidgets


text:
Progress animation and display

I currently have two problems with the circular progress path:

It is displaying as a full circle no matter what percentage is set.  For example, with this:
 <CircularProgressbar percentage={60.2} initialAnimation={true}/>

A full circle is displayed rather than just 60.2% even though the text does display as 60.2%.

There is no initial animation on refresh even though it is set to true.

Can you advise, @iqnivek ?
Thanks.

I can't reproduce the "full circle" issue - I'm guessing your full circle issue is due to whatever custom styling you're using. If .CircularProgressbar-trail is the same color as .CircularProgressbar-path, for instance, it'd look like a full circle is displayed for all percentages. Make sure the stroke colors are different for those two CSS classes - the example CSS should give you an idea of it.
The initialAnimation issue might also be caused by your styling - you need a CSS transition in order to have it work. Again, see the example CSS. If you're still having problems, please send your HTML/CSS/JS setup so I can take a look at what's wrong. Thanks.

source: gharchive/issue

authors: flamencoflsh iqnivek

repo: iqnivek/react-circular-progressbar

license: MIT

license_type: permissive

license_source: github-api


text:
Error Uncaught RuntimeException

Hello, I got an error when running JIT and AOT. It is only working properly for the VM.
Did I miss something here?
Used Repo
commit 3ed4119240bbcbde885dcd74a39d6958aa9389ef (HEAD -> master, origin/master, origin/HEAD)
Author: Anthony Ferrara <ircmaxell@gmail.com>
Date:   Mon Apr 22 10:18:07 2019 -0400

    Improve performance drastically by updating phpllvm

test.php
<?php
echo "Hello World\n";

Error JIT
ammarfaizi2@berlin:~/project/now/php-compiler$ ../php7.4/sapi/cli/php bin/jit.php test.php

Fatal error: Uncaught RuntimeException: Module verification failed due to Intrinsic has incorrect argument type!
void (i8*, i8, i64, i32, i1)* @llvm.memset.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8, i64, i32, i1)* @llvm.memset.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
 in /home/ammarfaizi2/project/now/php-compiler/vendor/ircmaxell/php-llvm/lib/LLVMAbstract/Module.php:180
Stack trace:
#0 /home/ammarfaizi2/project/now/php-compiler/lib/JIT/Context.php(210): PHPLLVM\LLVMAbstract\Module->verify(4, 'Intrinsic has i...')
#1 /home/ammarfaizi2/project/now/php-compiler/lib/JIT/Context.php(182): PHPCompiler\JIT\Context->compileCommon()
#2 /home/ammarfaizi2/project/ in /home/ammarfaizi2/project/now/php-compiler/vendor/ircmaxell/php-llvm/lib/LLVMAbstract/Module.php on line 180
ammarfaizi2@berlin:~/project/now/php-compiler$

Error compile
ammarfaizi2@berlin:~/project/now/php-compiler$ ../php7.4/sapi/cli/php bin/compile.php test.php

Fatal error: Uncaught RuntimeException: Module verification failed due to Intrinsic has incorrect argument type!
void (i8*, i8, i64, i32, i1)* @llvm.memset.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8, i64, i32, i1)* @llvm.memset.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
Intrinsic has incorrect argument type!
void (i8*, i8*, i64, i32, i1)* @llvm.memcpy.p0i8.p0i8.i64
 in /home/ammarfaizi2/project/now/php-compiler/vendor/ircmaxell/php-llvm/lib/LLVMAbstract/Module.php:180
Stack trace:
#0 /home/ammarfaizi2/project/now/php-compiler/lib/JIT/Context.php(210): PHPLLVM\LLVMAbstract\Module->verify(4, 'Intrinsic has i...')
#1 /home/ammarfaizi2/project/now/php-compiler/lib/JIT/Context.php(167): PHPCompiler\JIT\Context->compileCommon()
#2 /home/ammarfaizi2/project/ in /home/ammarfaizi2/project/now/php-compiler/vendor/ircmaxell/php-llvm/lib/LLVMAbstract/Module.php on line 180
ammarfaizi2@berlin:~/project/now/php-compiler$

PHP Version
PHP 7.4.0-dev (cli) (built: Apr 23 2019 08:25:48) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0-dev, Copyright (c) Zend Technologies

OS Details
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Linux Lite 4.0"
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Kernel Details
ammarfaizi2@berlin:~/project/now/php-compiler$ uname -vrpios
Linux 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 GNU/Linux

What LLVM version?

So, that error signifies that you have an LLVM version mismatch. The syntax for the intrinsics memcpy and memset had their syntax change sometime between LLVM 4 and LLVM 7. In LLVM4 they had an additional alignment parameter, and it was removed by LLVM7.
I found the bug in PHP-LLVM where LLVM8 was using the old version instead of the new one.
So I assume you're using LLVM8? If so, try doing a composer update to fetch the bug fix in PHP-LLVM and try again.

Yes, I use LLVM8.
I did composer update and it still the same. I even tried to delete the vendor dir including composer.lock and did the composer install again.
Latest commit for php-llvm in vendor dir
ammarfaizi2@berlin:~/project/now/php-compiler/vendor/ircmaxell/php-llvm$ git log -n 1
commit 000910a47e3e15d134502b689e02ba03f5f2ecd1 (HEAD -> master, origin/master, origin/HEAD, composer/master)
Author: Anthony Ferrara <ircmaxell@gmail.com>
Date:   Tue Apr 23 09:14:13 2019 -0400

    Fix issue with LLVM8 using the wrong factory
ammarfaizi2@berlin:~/project/now/php-compiler/vendor/ircmaxell/php-llvm$

LLVM Version
ammarfaizi2@berlin:~/project/now/php-compiler$ llvm-config --version
8.0.1
ammarfaizi2@berlin:~/project/now/php-compiler$

Still get the same error

Confirming LLVM version to be used
I also tried to confirm the LLVM version choosed by PHPLLVM chooser.

I was able to reproduce and have fixed locally with https://github.com/ircmaxell/php-llvm/commit/fb89dc0253d0f2c2875007706a551d00490a0920
Can you confirm this works for you?

Nice, thanks.
The JIT is now fixed.
But the AOT needs to use clang-4.0. Do we have some reasons of why we must use clang-4.0?

Can you test https://github.com/ircmaxell/php-compiler/pull/66 ?

Nice, thanks.
It works.

Sweet, thanks!!!

authors: ammarfaizi2 driusan ircmaxell

repo: ircmaxell/php-compiler

license: mit

license_source: bigquery


text:
Failed to legalize operation 'tosa.gather'

What happened?
When importing fsaf-cppe5_1.tflite, getting the error:
fsaf-cppe5_1.tflite:0:0: error: 'tosa.gather' op operand #1 must be 2D tensor of 32-bit signless integer values, but got 'tensor<1x1000xi64>'
fsaf-cppe5_1.tflite:0:0: note: see current operation: %7253 = "tosa.gather"(%7252, %7251) : (tensor<1x3800x4xf32>, tensor<1x1000xi64>) -> tensor<1x1000x4xf32>

This model is very similar to the RetinaNet-ResNeXT50 800x800 in our performance focus set.
Steps to reproduce your issue
iree-import-tflite [path to tflite file] -o [path to mlir file]
TFLite file: https://storage.googleapis.com/iree-model-artifacts/fsaf-cppe5_1.tflite
Original source: https://tfhub.dev/rishit-dagli/fsaf-cppe5/1
What component(s) does this issue relate to?
Frontends

Ah okay, I see the failure. Technically we only support gathers on i32 values at most. This is a TOSA limitation. There are actually other failures as well (e.g. topk has no lowering).  There are a bunch of other issues in this model so it will be quite a long time until we can find a solution.
It is possible we can fix it by making a bunch of changes to the quantized lowerings but it will be significant work.

gather 1x1000xi64 is odd - does it actually need to be 64-bit? (that's very rare)
of course it'd be good to support as-is but if we want to flush out other issues maybe fixing the model to not have i64 gathers would help reveal other latent issues

There is a decent amount of "why does this model do X". I doubt i64s actually matter. There are also some issues where we assume an operation runs on floats and mess-up on the integer case. Determining how to handle the i64 case is going to be much more frustrating.

authors: benvanik mariecwhite rsuderman

repo: iree-org/iree


text:
VMVX compilation fails since iree candidate-20221214.358

What happened?
Since iree release candidate-20221214.358, iree-compile fails to compile the imported TOSA MLIR into vmfb for the VMVX backend. It worked okay for candidate-20221213.357.
A failed tflite example is the person detection model: https://storage.googleapis.com/iree-model-artifacts/person_detect.tflite
Steps to reproduce your issue

Build IREE
Import TFLite model (use person.detect.tflite as an example)
path/to/iree-import-tflite path/to/person_detect.tflite -o=/tmp/person_detect.mlir
Use iree-compile to compile TOSA MLIR
path/to/iree-compile -iree-input-type=tosa -iree-hal-target-backends=vmvx /tmp/person_detect.mlir -o /tmp/person_detect.vmfb
See error
error: failed to legalize operation 'arith.fptosi' that was explicitly marked illegal ...

What component(s) does this issue relate to?
Compiler
Version information
iree candidate-20221214.358
Additional context
No response

@jpienaar @hcindyl

PR to fix under review in https://github.com/iree-org/iree/pull/11553 - there are still issues here so I wouldn't use VMVX for anything below 32-bit yet.

Should be fixed and working in next nightly. Keeping it open until next nightly.

Confirmed it has been fixed. Thanks!

authors: jpienaar lundong


text:
Integrate llvm-project and bump dependencies

llvm-project: 5ae0472694f5
mlir-hlo: f6f29b1eb37e0601b1a06a3d3b0eb50c5c2b2b18

cherry-picked ea5b21f8f9cdd7cc97965a02d27967fe3c68cec1

tensorflow: c8efbf27244b2a3ea4856654d52bd821ad3cf5a8

There are several cmake changes in the upstream, which break the build. Looking into it.

The cmake issue is fixed, but now I have errors with TF.
ERROR: /home/kbuilder/.cache/bazel/_bazel_kbuilder/1900d0fac5123d725c8d2e08b3f8c209/external/org_tensorflow/tensorflow/core/kernels/mkl/BUILD:280:22: Compiling tensorflow/core/kernels/mkl/mkl_dequantize_op.cc failed: (Exit 1): clang failed: error executing command /usr/lib/llvm-9/bin/clang -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 355 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox
external/org_tensorflow/tensorflow/core/kernels/mkl/mkl_dequantize_op.cc:59:53: error: use 'template' keyword to treat 'flat' as a dependent template name
      const float min_range = ctx->input(kMinIndex).flat<float>()(0);
                                                    ^
                                                    template
external/org_tensorflow/tensorflow/core/kernels/mkl/mkl_dequantize_op.cc:60:53: error: use 'template' keyword to treat 'flat' as a dependent template name
      const float max_range = ctx->input(kMaxIndex).flat<float>()(0);
                                                    ^
                                                    template
2 errors generated.

The code using only flat was introduced by https://github.com/milpuz01/tensorflow/commit/b601c0560402354bc3337cb51d94ca407102969c in May. I am not sure why the errors appear now.

Okay, the code was made in May and pulled into tensorflow yesterday.

This is the breaking PR. I asked the author to revert and fix it.
https://github.com/tensorflow/tensorflow/pull/56086

The issues with TF and mhlo were resolved in the upstreams. Abandoning this PR to handle them in a different PR with the latest changes.

source: gharchive/pull-request


text:
mseed3-json invalid on multiple records

A mseed3 file with multiple records should still generate valid json.
Example using reference-data:
cat reference-sinusoid-int32.xseed reference-sinusoid-int16.xseed > combine.xseed
mseed2json combine.xseed
{
    "SID": "XFDSN:XX_TEST__L_H_Z",
    "RecordLength": 2060,
    "FormatVersion": 3,
    "Flags": {
        "RawUInt8": 4,
        "ClockLocked": true
    },
    "StartTime": "2012-01-01T00:00:00.000000000Z",
    "EncodingFormat": 3,
    "SampleRate": 1,
    "SampleCount": 500,
    "CRC": "0x727BF4BD",
    "PublicationVersion": 1,
    "ExtraLength": 0,
    "DataLength": 2000
},{
    "SID": "XFDSN:XX_TEST__L_H_Z",
    "RecordLength": 860,
    "FormatVersion": 3,
    "Flags": {
        "RawUInt8": 4,
        "ClockLocked": true
    },
    "StartTime": "2012-01-01T00:00:00.000000000Z",
    "EncodingFormat": 1,
    "SampleRate": 1,
    "SampleCount": 400,
    "CRC": "0x106EAFA5",
    "PublicationVersion": 1,
    "ExtraLength": 0,
    "DataLength": 800
}%

It looks like this was meant to be a json array at the top level, but the open and close brackets [ ] are not there.

Agreed, that should be an array and legit JSON.

An option now exists -B to print "bare" output, omitting the enclosing array brackets.  By default all records are in an [] array.

With the -B option, you might want to avoid the comma between records as well.

authors: chad-iris crotwell


text:
Allow customization of Access Token Scope

We should allow the user to specify additional scopes along with the default oidc scope for further flexibility.
Example (Implementation may be different):
"openid_connect": {
  "additional_scopes": ["irods", "custom", "misc"]
}

Perhaps even allow the oidc scope to be optional?

We haven't spent any time thinking through the details due to other priorities, but we'll address this once work on 0.4.0 begins.

By validating scopes (a scope mapping could be added in the conf to establish a relation between scope names and API ops), the resource server will expose only those API endpoints compatible with them, increasing security and providing a way of restricting API access dynamically.

True. iRODS already has a permission model though. Admins can already block access to endpoints (e.g. /data-objects) through the use of a proxy (e.g. nginx or httpd). While we can certainly improve the use of scopes, it's difficult to determine whether it'll prove to be useful to people.
That's just my initial thoughts.
We haven't made any decisions regarding this yet. We're very much open to hearing use-cases from people. Feel free to post your thoughts and ideas here.

Thanks. This is good feedback. We'll keep this in mind as we approach the next release.
If you think of anything else, please post it here.


text:
Made format command name tool-agnostic

@ironcladlou

How about self.format_backend to be consistent?

Took that and ran with it a little further. goto_def_backend and format_backend now.

Thanks!

authors: ironcladlou stevekuznetsov

repo: ironcladlou/GoTools


text:
KAMI is no longer functioning properly.

I had the injector working pretty much perfectly with MGS4, but now I'm running into a dilemma.
When I first start MGS4, the emulator is like this, but it shows that the "Emu status" is "Shutdown" for some reason.

And exactly after a moment or two, it switches to the image belowand is no longer functioning.

When I start KAMI then open RPCS3, it shows the following:

And pressing the On/off button (in my case, subtract [-]) the program freezes for a moment before basically crashing with no messages.
I reinstalled all the .NET components I could think of but so far nothing. I'd appreciate a feedback!

having the exact same problem, it worked only once after installing and now every time I boot up the emulator / game I get this exact problem

alright I found a fix/workarround (maybe its the intended way idk at this point), just start your emulator and then boot mgs4 and once your ingame just start kami go back into your emulator and then re-enable your IPC server and boom now it works (atleast for me)

alright I found a fix/workarround (maybe its the intended way idk at this point), just start your emulator and then boot mgs4 and once your ingame just start kami go back into your emulator and then re-enable your IPC server and boom now it works (atleast for me)

This actually works, I have discovered this way earlier but it was too tiresome (for me) because I have to disable IPC before closing the game, next time I open the game I have to wait until it loads, open KAMI, enable IPC again (every single time) and I ended up opting for mapping the mouse for the right analog stick because honestly at this point it was more efficient than KAMI, besides, there was a certain codec conversation in Act 2 that caused the camera to switch suddenly, this created an interference with KAMI and caused the game to crash (unless KAMI wasn't enabled), so... Until it's more stable, I'd stick to what I have for now.

oh my god I just spent half an hour fixing the codec call crash in Act 2 you were talking about, in the end I found a different solution but after testing it again turning kami off would have fixed it aswell

alright never mind after receiving the codec call from then on kami sadly keeps crashing the game

alright never mind after receiving the codec call from then on kami sadly keeps crashing the game

Having progressed till the end of Act 3, so far the game is playable to a very acceptable extent without KAMI, thankfully. However, I do hope for this injector to become better and far more stable in the future because it has lots of potential.

alright I found a fix/workarround (maybe its the intended way idk at this point), just start your emulator and then boot mgs4 and once your ingame just start kami go back into your emulator and then re-enable your IPC server and boom now it works (atleast for me)

Not sure if this is still in an issue in the current release (V0.0.6), but the work around stated above works, however, at least with Killzone 2, I get the message that "Game with ID BCUS98116 is not implemented" and using the hotkey I have set for "On/Off", as soon as I press it, KAMI closes and no error message or anything. Mouse input not working. Trying to open KAMI again, the Emu status is set to shutdown and still doesn't work. Anyone know if this is getting looked at?

repo: isJuhn/KAMI


text:
npm audit returns error with v2.1.7

npm audit errors have been observed with oas-tools 2.1.7
Our Jenkins CI nodes generally run nodejs 10.15.3 (npm 6.4.1) or 10.16.3 (npm 6.9.0).
With npm 6.4.1 (locally or in Jenkins) we get the following error
npm ERR! code E400
npm ERR! 400 Bad Request - POST https://registry.npmjs.org/-/npm/v1/security/audits

With npm 6.9.0 (locally or in Jenkins)
npm ERR! code ENOAUDIT
npm ERR! audit Your configured registry (https://registry.npmjs.org/) does not support audit requests, or the audit endpoint is temporarily unavailable.

Workaround: use oas-tools 2.1.6

Verified with a minimal project
➜  test-oas-tools npm install --save oas-tools
...
+ oas-tools@2.1.7
added 530 packages from 427 contributors in 157.772s
➜  test-oas-tools npm -v
6.11.3
➜  test-oas-tools nvm use lts/dubnium
Now using node v10.16.3 (npm v6.9.0)
➜  test-oas-tools npm audit --registry=https://registry.npmjs.com/
npm ERR! code ENOAUDIT
npm ERR! audit Your configured registry (https://registry.npmjs.com/) does not support audit requests, or the audit endpoint is temporarily unavailable.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/n0357581/.npm/_logs/2019-10-11T11_24_32_125Z-debug.log
➜  test-oas-tools nvm use lts/carbon
Now using node v8.16.1 (npm v6.4.1)
➜  test-oas-tools npm audit --registry=https://registry.npmjs.com/
npm ERR! code E400
npm ERR! 400 Bad Request - POST https://registry.npmjs.com/-/npm/v1/security/audits

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/n0357581/.npm/_logs/2019-10-11T11_25_04_557Z-debug.log
➜  test-oas-tools cat package.json
{
  "name": "test-oas-tools",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "oas-tools": "^2.1.7"
  }
}

➜  test-oas-tools npm install --save oas-tools
...

oas-tools@2.1.7
added 530 packages from 427 contributors in 157.772s
➜  test-oas-tools npm -v
6.11.3
➜  test-oas-tools nvm use lts/dubnium
Now using node v10.16.3 (npm v6.9.0)
➜  test-oas-tools npm audit --registry=https://registry.npmjs.com/
npm ERR! code ENOAUDIT
npm ERR! audit Your configured registry (https://registry.npmjs.com/) does not support audit requests, or the audit endpoint is temporarily unavailable.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/user/.npm/_logs/2019-10-11T11_24_32_125Z-debug.log
➜  test-oas-tools nvm use lts/carbon
Now using node v8.16.1 (npm v6.4.1)
➜  test-oas-tools npm audit --registry=https://registry.npmjs.com/
npm ERR! code E400
npm ERR! 400 Bad Request - POST https://registry.npmjs.com/-/npm/v1/security/audits
npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/user/.npm/_logs/2019-10-11T11_25_04_557Z-debug.log
➜  test-oas-tools cat package.json
{
"name": "test-oas-tools",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"oas-tools": "^2.1.7"
}
}

This might be weird proxy issues within my organisation, which we're trying to diagnose. Will update/close issue when I find out more.

Did you find out the issue? I cannot seem to reproduce this behaviour.

authors: johnnygf raffrearaUS

repo: isa-group/oas-tools


text:
Add input for the LLM question marking formulas

Marking formulae for LLM questions can be expression in forms such as the following:
MIN(maxMarks, MIN(1, SUM(advantageMoreCharacters, advantageForeignAlphabets, advantageEmojis, advantageOther)), MIN(1, SUM(disadvantageMoreStorage, disadvantageOther))) - (essentially 1 mark for an advantage, 1 mark for a disadvantage)
For processing, they are most effectively stored as a json AST as this is how the API processes them. These AST are quite unwieldy to type manually, hence this custom input.
Input can be formatted either by manually typing or with button inputs (or a combination of the two). These buttons are context-sensitive, such that commas are added between arguments of a function but not at the beginning of one - so a full formula can be written with only these buttons.
These functions should suffice to technically allow any input we want, but for easier writing and more condensed formulae, I'm looking to add more such as AND or MULT. This will require an API change so I'll handle it separately later.

I didn't add CRACO/nearley/moo myself so I can't explain the exact motivations behind them, but I'm quite well convinced that they've been added correctly and do work as intended.

Also removes "choices" and "answer" in template for LLM questions as they don't work when present, so had to be removed manually for each question otherwise.

Most of these problems seem to be from my hasty addition of evaluating marked examples. I added them to show Ada/Harriet how the formulae work and then never cleaned up my code afterwards 😔
On the testing front, I agree that this could do with some unit tests and I'll add some now in a dedicated file - however the content editor in general isn't really set up well for testing (we could certainly do with more than one file worth!). I suppose that's something to look at in the future

repo: isaacphysics/isaac-content-editor


text:
Hide previous question attempts

This change requires the following addition to the segue config: DISPLAY_SETTING=...,HIDE_QUESTION_ATTEMPTS.

This PR allows users to opt-in to having all previous best attempts to questions hidden if and when they revisit them.
I noticed a page crash when testing this locally - I can't reproduce it or work out what the issue might be (the code seems solid), so unhandled race conditions might be something to look out for (I couldn't find any myself).
Message displayed if best attempt has been hidden, only displayed if there is no current attempt: (the 2nd-to-last commit adds "Your" to the beginning of this message)

Beta feature tab on user account, with the checkbox to enable this feature:

The tooltip reads: "This feature is helpful for revision for example - you can attempt all of the questions on the platform again, without seeing your previous answers (correct or not)."

I'd like those wording changes made; I'm interested in opinions on message-at-top vs message-inline but have no real preference and so once the types thing is sorted and the wording updated I think this is good to go.

repo: isaacphysics/isaac-react-app


text:
How to update json in BodyParameters

I want to change post parameters according to the condition.
I tried to update the value in the following way.
However, I can't.

update json value

        var bodyParameters: BodyParameters? {
            var json:[String:Any] = [
                "name":createTalkParam.name,
                "is_public": createTalkParam.isPublic,
                "description":createTalkParam.description
            ]
            if let sportId = createTalkParam.sportId {
                json.updateValue(sportId, forKey: "sport_id")
            }
            if let cityId = createTalkParam.cityId {
                json.updateValue(cityId, forKey: "city_id")
            }
            if let imageUrl = createTalkParam.imageUrl {
                json.updateValue(imageUrl, forKey: "image_url")
            }
            if let subImageUrls1 = createTalkParam.subImageUrls1 {
                json.updateValue(subImageUrls1, forKey: "sub_image_urls_1")
            }
            if let subImageUrls2 = createTalkParam.subImageUrls2 {
                json.updateValue(subImageUrls2, forKey: "sub_image_urls_2")
            }
            if let subImageUrls3 = createTalkParam.subImageUrls3 {
                json.updateValue(subImageUrls3, forKey: "sub_image_urls_3")
            }
            if let subImageUrls4 = createTalkParam.subImageUrls4 {
                json.updateValue(subImageUrls4, forKey: "sub_image_urls_4")
            }
            return JSONBodyParameters(JSONObject: json)
        }

error message

APIKit.SessionTaskError.requestError(Error Domain=NSCocoaErrorDomain Code=3840 "データのフォーマットが正しくないため、読み込めませんでした。")

Succeeds if there is no updateValue.
How to update json parameter?

try this
var bodyParameters: BodyParameters? {
    var json: [String:Any] = [
        "name": createTalkParam.name,
        "is_public": createTalkParam.isPublic,
        "description":createTalkParam.description
    ]

    if let sportId = createTalkParam.sportId {
        json["sport_id"] = sportId
    }

    return JSONBodyParameters(JSONObject: json)
}

You can print the json or JSONSerialization.isValidJSONObject(JSONObject) before return to check the json format.

Thank you!
I can add post param.

You can print the json or JSONSerialization.isValidJSONObject(JSONObject) before return to check the json format.
I try when I have program in the future.

Yeah JSONSerialization.isValidJSONObject will be a help. I suspect that you are putting URL or [URL] values directly to a json dictionary. You should convert them to String or [String].

Thanks!
I also had the problem.
I didn't understand the JSON specification.
Thank you very much.

authors: damozhang entaku19890818 ikesyo

repo: ishkawa/APIKit


text:
TODO

[ ] Option to parse false as null on boolean. [WIP]
[x] Provide props to SectionWrapper for array manipulation. [WIP]
[ ] Avoid usign for(.. in ..) {} because of IE
[ ] Support arrays at top-level or give a nice error message in case of wrong usage.
[ ] Throw error on invalid type
[ ] Ensure string type as default everywhere.
[ ] Improve demo page 💄
[ ] Add a CONTRIBUTING.md file as a guide to help possible contributors

Any plans on updating the npm package soon :)  ?

I want to at least have "Option to parse false as null on boolean." before releasing, for backward compatibility.

Are you still working on this project?

All good man, thanks for the heads up 👍 I know we all get busy with other things, happens with me too :)

repo: ismaelga/react-json-editor


text:
Carousel now sticks to cursor after 0.1.4

Describe the bug
When I click and hold any image to drag, it gets fixed to the cursor.
this was fine in 0.1.38
To Reproduce
all carousels are affected like this
<Carousel :autoplay="7000" :wrapAround='true' :breakpoints="breakpoints" snapAlign="center">
            <Slide v-for="slide in showcasePhotos" :key="slide">

            </Slide>
</Carousel>

Expected behavior
It shouldn't stick
Desktop (please complete the following information):

OS: Windows 11
Browser Chrome
Version 102

Any update on this. Experiencing this as well.

@gerardfollano I couldn't find any usable solution in the current version, I just reverted to 0.1.38.

Same problem

authors: alisaliso gerardfollano xrayian


text:
Added INVERSION_WINDOWS to presolve and main configs

In apply_oe, EMIT and AVIRIS-3 have custom inversion windows that differ from the default windows, but they are not being used when generating configs. This PR adds the INVERSION_WINDOWS variable as an argument when calling build_main_config and build_presolve_config.

Thanks for the fix!  This is definitely the intended behavior.

authors: adamchlus pgbrodrick

repo: isofit/isofit


text:
🛑 angiografia.isolucion.co is down

In 373eaa6, angiografia.isolucion.co (https://angiografia.isolucion.co) was down:

HTTP code: 0
Response time: 0 ms

Resolved: angiografia.isolucion.co is back up in e36a8bb.

repo: isolucionco/EstadoIsolucionHosting


text:
🛑 apiiso01com.isolucion.com is down

In 12bc889, apiiso01com.isolucion.com (https://apiiso01com.isolucion.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: apiiso01com.isolucion.com is back up in 053b241 after 13 minutes.


text:
🛑 USABarranquilla.isolucion.co is down

In a61620e, USABarranquilla.isolucion.co (https://USABarranquilla.isolucion.co) was down:

HTTP code: 0
Response time: 0 ms

Resolved: USABarranquilla.isolucion.co is back up in e33874e.


text:
Error: I/O Error in DHCP: Address already in use (os error 98)

Hi,
Here a progress report from my exploring erbium expedition ;-).
I'm stuck at
Error: I/O Error in DHCP: Address already in use (os error 98)

But I don't understand that fatal error message.
With sudo strace target/debug/erbium I can see
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 15
bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 \
  EADDRINUSE (Address already in use)
close(15)

With ss -n | grep :67  I did found a dhcp client, but after switching network configuration of my Linux laptop to static config, the error persists.
What should be done to get beyond the EADDRINUSE?

Hmm.  This is saying that something is already using that port.  What does ss -nulp | grep :67 say?  It should list the process name/pids of things that have that port already open.

Hmm.  This is saying that something is already using that port.  What does ss -nulp | grep :67 say?  It should list the process name/pids of things that have that port already open.

Yes, the l of listen  makes the difference.
$ sudo ss -n | grep :67
$ sudo ss -nl | grep :67 | sed -e 's/    / /g'
udp   UNCONN 0   0                         0.0.0.0%virbr0:67       0.0.0.0:*
udp   UNCONN 0   0                         0.0.0.0%ovsbr0:67       0.0.0.0:*
$

Silly me.
Running the request test:
$ sudo ss -nulp | grep :67 | sed -e 's/    / /g'
UNCONN 0   0           0.0.0.0%virbr0:67   0.0.0.0:* users:(("dnsmasq",pid=1621,fd=3))
UNCONN 0   0           0.0.0.0%ovsbr0:67   0.0.0.0:* users:(("dnsmasq",pid=1393,fd=4))

That indeed does explain the EADDRINUSE.  Now how to get beyond it  :smiley:
dnsmasq does bind on interface name and each dnsmasq only claims one interface.
To get ( to trick? ) erbium to only use eth0  I have in erbium.conf this line
  addresses: [ 172.24.0.37/26 ]

because
$ ip -4 address show dev eth0
7: enxe4b97a90028f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.24.0.37/26 brd 172.24.0.63 scope global noprefixroute enxe4b97a90028f
       valid_lft forever preferred_lft forever

I think the strace shown
bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("0.0.0.0")}, 16)

should become something like
bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("172.24.0.37")}, 16)

to honor
  addresses: [ 172.24.0.37/26 ]

from erbium.conf.

Yes, the l of listen  makes the difference.
$ sudo ss -n | grep :67
$ sudo ss -nl | grep :67 | sed -e 's/    / /g'
udp   UNCONN 0   0                         0.0.0.0%virbr0:67       0.0.0.0:*
udp   UNCONN 0   0                         0.0.0.0%ovsbr0:67       0.0.0.0:*
$

Silly me.
Running the request test:
$ sudo ss -nulp | grep :67 | sed -e 's/    / /g'
UNCONN 0   0           0.0.0.0%virbr0:67   0.0.0.0:* users:(("dnsmasq",pid=1621,fd=3))
UNCONN 0   0           0.0.0.0%ovsbr0:67   0.0.0.0:* users:(("dnsmasq",pid=1393,fd=4))

That indeed does explain the EADDRINUSE.  Now how to get beyond it  :smiley:
dnsmasq does bind on interface name and each dnsmasq only claims one interface.
To get ( to trick? ) erbium to only use eth0  I have in erbium.conf this line
  addresses: [ 172.24.0.37/26 ]

because
$ ip -4 address show dev eth0
7: enxe4b97a90028f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.24.0.37/26 brd 172.24.0.63 scope global noprefixroute enxe4b97a90028f
       valid_lft forever preferred_lft forever

I think the strace shown
bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("0.0.0.0")}, 16)

should become something like
bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("172.24.0.37")}, 16)

to honor
  addresses: [ 172.24.0.37/26 ]

from erbium.conf.

erbium, currently, always listens on 0.0.0.0.  I want to support interfaces coming and going without needing to restart erbium, as well as erbium dropping permissions (which, to be fair, it doesn't do at the moment), so it wouldn't be able to start listening on a new interface after startup.
I could, I guess, add a "dhcp-listen-addresses: [192.0.2.1]" or similar for people who specifically don't want it to listen on all interfaces.

erbium, currently, always listens on 0.0.0.0.  I want to support interfaces coming and going without needing to restart erbium, as well as erbium dropping permissions (which, to be fair, it doesn't do at the moment), so it wouldn't be able to start listening on a new interface after startup.
I could, I guess, add a "dhcp-listen-addresses: [192.0.2.1]" or similar for people who specifically don't want it to listen on all interfaces.

FWIW:

When an interface goes, it is fine that it takes erbium with it.
I have no idea how network daemons should cope with bouncing interfaces, but I fear the idea of a running network daemon that is unaware of a returned network interface.
Listening on 1  interface will allow running  various erbium instances for various interfaces.

FWIW:

When an interface goes, it is fine that it takes erbium with it.
I have no idea how network daemons should cope with bouncing interfaces, but I fear the idea of a running network daemon that is unaware of a returned network interface.
Listening on 1  interface will allow running  various erbium instances for various interfaces.

Listening on 1 interface will allow running various erbium instances for various interfaces.

is to express that

I could, I guess, add a "dhcp-listen-addresses: [192.0.2.1]" or similar for people who specifically don't want it to listen on all interfaces

is indeed a solution to Error: I/O Error in DHCP: Address already in use (os error 98)

I've given this quite a bit of thought over the last few weeks, trying to figure out the right balance.

Do I have a global listen-addresses (or possibly listen-interfaces) for all protocols?   Or do I have a per protocol dhcp-listen-addresses / radv-listen-addresses / dns-listen-addresses (or their equivalent ${protocol}-listen-interfaces)?  Or both?  What should the semantics be if you, say, specify listen-interface: ['eth0'] and dhcp-listen-address: 192.0.2.1?  Are you interested in listening on an interface, or listening on an address?

Having one erbium process process per interface is a bit odd when I finish up the DNS support, as you'll end up with an unique DNS cache per interface.  Is this the right thing to do?

I still would like to make it that you can (although don't necessarily have to)  start erbium before an interface is available, and let erbium handle the interface coming and going.

authors: isomer stappersg

repo: isomer/erbium


text:
Issue with Copy and Paste

Bug description

The main reason for the contact is the issue that has started recently. Unfortunately I can’t tell you which build it started with.
Normally I use to highlight the text above and copy, then paste and it would append the string to the end of what was being typed. For some reason now, copying and pasting overwrites what is written. It appends if I copy, type and then paste. But if I type, copy, paste then it overwrites.

From Peter

Available on the latest beta release : https://testflight.apple.com/join/QSrBK59z


text:
nyc does not work with symlinks

I reproduced the issue in this repo: https://github.com/aalexgabi/nyc-symlink-problem/commit/3ce1fe85f2f8bb723a2ede92bf1d9a324655c8e2
When I don't use a symlink it does work: https://github.com/aalexgabi/nyc-symlink-problem/commit/9da9355e8111233e8efa38f85aef9de2f6fd713c
This was reported many times (not sure all issues here are due to symlinks) but not fixed:

https://github.com/istanbuljs/nyc/issues/962
https://github.com/istanbuljs/nyc/issues/472
https://github.com/istanbuljs/nyc/issues/741
https://github.com/istanbuljs/nyc/issues/833

Expected Behavior
I should have symlinked files from node_modules included:
running
working
ran
-----------------------|---------|----------|---------|---------|-------------------
File                   | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
-----------------------|---------|----------|---------|---------|-------------------
All files              |     100 |      100 |     100 |     100 |
 src                   |     100 |      100 |     100 |     100 |
  test.js              |     100 |      100 |     100 |     100 |
 src/node_modules/work |     100 |      100 |     100 |     100 |
  index.js             |     100 |      100 |     100 |     100 |
-----------------------|---------|----------|---------|---------|-------------------

Observed Behavior
I don't have symlinked files from node_modules included:
running
working
ran
----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |     100 |      100 |     100 |     100 |
 test.js  |     100 |      100 |     100 |     100 |
----------|---------|----------|---------|---------|-------------------

Troubleshooting steps

[x] still occurring when I put cache: false in my nyc config

Environment Information
% npx envinfo@latest --preset nyc
npx: installed 1 in 0.741s

  System:
    OS: Linux 5.5 Manjaro Linux
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 887.34 MB / 15.52 GB
  Binaries:
    Node: 13.7.0 - ~/.fnm/current/bin/node
    Yarn: 1.22.0 - /usr/bin/yarn
    npm: 6.13.6 - ~/.fnm/current/bin/npm
  npmPackages:
    nyc: ^15.0.1 => 15.0.1

Please alter your include option, instead of node_modules/work/** you need work/**.  For this you don't need excludeNodeModules: true because the realpath is not within in node_modules.

@coreyfarrell In my project the work folder is a library located outside the project directory as a sibling. The library is linked using npm link inside my project folder node_modules.
So this solution won't work because nyc is ran from the project folder.
So to better illustrate my structure I have updated the repo: https://github.com/aalexgabi/nyc-symlink-problem/commit/5eba65dc91acf459f377d9c99ce2f7a7fae75cd1
It tried with this include patterns but it still does not work:

Coverage of files outside the project isn't supported.  It might work for you to tweak your settings as follows:
"cwd": "..",
"include": [
  "project/src/**",
  "lib/**"
]

The cwd says that the project root is the directory above process.cwd(), the include options are modified to be relative to the explicitly set cwd.  Note that unlike other options the cwd option has slightly different meaning when provided to CLI vs when provided in config.  If you ran nyc --cwd .. then this would prevent nyc from finding project/.nycrc.  Thus you have to put the cwd option into project/.nycrc.

@coreyfarrell Thank you for the cwd option (I found it in the meanwhile here: https://stackoverflow.com/questions/53399098/enabling-nyc-istanbul-code-coverage-for-files-outside-the-package-directory).
It would be nice if the cwd option would be documented.
The files are inside the project folder in node_modules through a symlink. From a functional perspective the symlink should not change anything for nyc in my opinion. I get that the node uses realpath to determine if two modules are the same file but I think that nyc should abstract that away because it adds a lot of complexity in the configuration and also it forces the user to mix paths between projects otherwise.
nyc should work the same if a package is downloaded from npm or is linked locally in development. The current behavior requires manually changing the .nycrc file each time you switch from using links to downloading a module.

nyc works with realpaths.  Changing this would be a major breaking change (IE for monorepos).  I'd think you can configure nyc to include both paths (the locally linked any the npm install), but be aware that instrumenting packages downloaded from npm is a non-goal of this project (thus why node_modules is ignored by default).
I appreciate that nyc is not working exactly as you would like but it is working the way it needs to work to support normal project configurations.  What you are asking for may simplify what you are trying to do but for others (again monorepo projects is the major issue), including packages/** is much easier than disabling the excludeNodeModules and explicitly enabling specific node_modules/package-name paths.
@AndrewFinlay any thoughts on clarifications to the README for the cwd option?  If you don't have time to look don't worry I'm tagging you as you've provided high quality documentation improvements.

Changing this would be a major breaking change (IE for monorepos)

Not necessarily. It all depends on how the change is implemented.

What you are asking for may simplify what you are trying to do but for others (again monorepo projects is the major issue), including packages/** is much easier than disabling the excludeNodeModules and explicitly enabling specific node_modules/package-name paths.

I am not asking to make it more difficult at all. I am asking that:

From a functional perspective the symlink should not change anything for nyc

It would be very useful if nyc would have support for both symlinks and realpaths because they are both valid from a functional perspective. There would be no breaking change because adding support for symlinks does not mean removing support for realpaths.

If someone wants to create a patch for this I would review it for potential merge as long as it does not introduce any changes to existing projects (current realpath functionality must be default).  I do worry about the potential for errors that using this option might cause.
I believe the process for enabling what you've requested would be:

Patch test-exclude to support a useRealpath option (must be enabled by default unless explicitly set to false).
Patch nyc to pass the useRealpath option from nyc to test-exclude.
Patch @istanbuljs/schema to publish the useRealpath option with the other test-exclude options.

@coreyfarrell thanks for the cwd suggestion - it worked like a charm! Now I can test coverage across multiple packages in my monorepo (a yarn workspace):
"cwd": "..",
"include": [
  "packageA",
  "packageBRequiresPackageA"
]

Think it would be worth documenting this as for people using monorepos

authors: aalexgabi coreyfarrell rwalle61

repo: istanbuljs/nyc

license: isc


text:
fix: babylon misconfiguration

When using ES6 modules in source/test code, I get this message:
failed to instrument /Users/kdodds/Developer/starwars-names/src/index.js with error: 'import' and 'export' may appear only with 'sourceType: module' (1:0)

The coverage report is still generated, but I think that we probably don't want this error message. Let me know if I'm misunderstanding something.

Is there a situation where this might need to be false and, if so, should this be a config option?

@gotwarlost, I figured that'd be needed. Thought I'd open the PR with minimal requirements and we can iterate. Any suggestions from anyone on @istanbuljs/nyc about where/how this should work? What should be the default?

It would be false when when instrumenting ES5 code. When instrumenting ES2015+ modules I've been using the babel-plugin-istanbul with nyc's instrumentation turned off as specified in the readme without too many issues.

Huh... Somehow I missed that requirement of the 7.0.0 breaking changes... This makes me sad. nyc went from: "just stick nyc before npm test" to a whole bunch of config. Oh well...

@kentcdodds for native ES6 stuff (whatever is currently supported on the Node bleeding edge), It should continue being nyc npm test. Using babel-plugin-instanbul should only be necessary when you're using a compile step to pull in ES2015 features outside what's currently supported by Node.

Understood. There are definitely several use cases for transpiling with babel. Almost everything I do uses babel for several features (even when Node6 is available). No worries though. I still love nyc.

@kentcdodds I'd love to start a conversation about how we could make things work out of the box. also maybe it's worth adding some documentation that points out that ES6 can work if you're using newer V8 builds...
It seems like we're experiencing a cambrian explosion of approaches to instrumenting ES2015 currently, so I do want to be careful that nyc isn't too prescriptive ... I also want to keep things simple. feels like we need to find a balance.

Yeah, honestly, with how powerful and flexible our tools are, it's important that we avoid being prescriptive. I was going to suggest that we have a special binary that sets some defaults (nyc-babel for example). That may not be a bad idea. We'd cover a bunch of use cases that way I think...

authors: JaKXz bcoe gotwarlost kentcdodds


text:
Test node 6 on travis

node@6 is the current LTS. "stable" is node@7
Might want to consider dropping 0.10, 0.12 and 5 as they are EOL, but as a testing tool, maybe not? 😄

Changes Unknown when pulling b79aac70d284bf14661ee5168711c4d38297154e on SimenB:patch-1 into ** on istanbuljs:master**.

Thanks @SimenB! I also made some updates that clean up our tested versions.
@bcoe didn't we drop support for v0.10 at some point? or not yet?

I tried to look through the changelog, but saw no mention of dropped node versions

Ok cool, I guess that will happen when yargs drops it. Thanks!

Changes Unknown when pulling 99112e5a15fe57657fa89adf34a7d0173ca1b8b6 on SimenB:patch-1 into ** on istanbuljs:master**.

authors: JaKXz SimenB coveralls


text:
istio/proxy can not build

Bug description
Download from https://github.com/eile/tclap/archive/tclap-1-2-1-release-final.tar.gz failed: class com.google.devtools.build.lib.bazel.repository.downloader.UnrecoverableHttpException GET returned 404 Not Found
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
How was Istio installed?
Environment where bug was observed (cloud vendor, OS, etc)

Should have been fixed master.

Should have been fixed in master.

I'm using version 1.4.0

Yeah, try fetch latest 1.4, it is also fixed there.

Yeah, try fetch latest 1.4, it is also fixed there.

我用的就是1.4.0的版本，然后报的这个错误，我在github上发现这个包确实没了

It was fixed by https://github.com/istio/proxy/commit/6ce5512ce09b760f79e33a06c2565f5974362edc, which is not in 1.4.0.

Yeah, try fetch latest 1.4, it is also fixed there.

I will manually modify the code and continue to try

Ok. Feel free to reopen, but this specific issue should have been fixed in all branches.

authors: AL-Cui bianpengyuan

repo: istio/istio


text:
Mixer has an excessive number of disk writes impacting overall performance

@jnativio commented on Wed Dec 06 2017

Is this a BUG or FEATURE REQUEST?:
Did you review existing epics or issues to identify if this already being worked on? (please try to add the correct labels and epics):
Bug:
Y
What Version of Istio and Kubernetes are you using, where did you get Istio from, Installation details
istioctl version: 0.2.12
kubectl version: v1.7.4-2+eb9172c211dc41

Is Istio Auth enabled or not ?
istio.yaml was installed.
What happened:
I installed istio.yaml 0.2.12  as is initially and then I changed some properties in order to minimize the performance impact on the workload. Even with all known tuning options it was observed a large number of disk writes during the load as well large CPU usage, causing the throughput to be a fraction of what obtained without the mixer.
What you expected to happen:
Less performance impact.
How to reproduce it:
Drive some workload to a microservices app using Istio with and without the mixer to compare the performance impact.
Feature Request:
N
Describe the feature:

cc @jnativio - I added you to the org so you can create/work on issues directly in istio/istio
(istio/issues/issues is for users)

@jnativio, could you give more detailed repro steps & configuration changes you've made?

Here is the document that has all the details of our Istio Performance with some low level data
Istio 0.2.12 Performance Measurements.pdf

Great, thank you!
On Wed, Dec 20, 2017 at 9:34 AM, Surya Duggirala notifications@github.com
wrote:

Here is the document that has all the details of our Istio Performance
with some low level data
Istio 0.2.12 Performance Measurements.pdf
https://github.com/istio/istio/files/1576491/Istio.0.2.12.Performance.Measurements.pdf
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/2025#issuecomment-353130469, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQR8IxDhC9rzrxDaNomkMWUwZyLyA8MLks5tCUU2gaJpZM4Q6YVy
.

@suryadu It looks like the graphana dashboard does not record disk IO, only records CPU/memory. Did I miss something?

@mandarjog  We developed a custom grafana dashboard for performance analysis of Istio where we could get the disk IO as well as shown below. The worker node .130 has only Istio components like Mixer and as you can see the disk IO changes from 7 MB/sec to less than 2 MB/sec when we disabled the mixer all together. We have not dissected the 2 containers (mixer and statsd) disk IO from mixer POD which we will next as we discussed in our WG call today.

Has there been follow-up on this problem?

Yes, and it is also one of the areas for the perf swat team to dig further. @mandarjog is on point for that part.

@douglas-reid has a PR that introduces sampled output to the stdio logger. Is that part of addressing this issue?
We could also put a buffering layer in front of zap. I believe every log statement in zap is pushed all the way out with no intermediary buffering. Adding just a few ks of buffer would go a long way.

authors: geeknoid ldemailly mandarjog ozevren suryadu


text:
readinessProbe fails in cluster-local-gateway when envoy metrics grow much bigger

Bug description
After running 2 or 3 days, readinessProbe check started failing in cluster-local-gateway and istio-ingressgateway pods
2020-08-10T02:40:41.318531Z	info	Envoy proxy is NOT ready: failed to get server info: Get http://127.0.0.1:15000/stats?usedonly&filter=server.state: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

I logged in cluster-local-gateway pod (kubectl exec) and found the envoy process was running actually, but if I curl http://127.0.0.1:15000/stats?usedonly&filter=server.state, there returned the result pretty slow which took more than 1 seconds.
If I curl without filter=server.state, there returned around 18700 metrics entries (19M size) like below, but it can be returned within 1 second
reporter=.=source;.;source_workload=.=cluster-local-gateway;.;source_workload_namespace=.=istio-system;.;source_principal=.=unknown;.;source_app=.=cluster-local-gateway;.;source_version=.=unknown;.;source_canonical_service=.=cluster-local-gateway;.;source_canonical_revision=.=latest;.;destination_workload=.=unknown;.;destination_workload_namespace=.=unknown;.;destination_principal=.=unknown;.;destination_app=.=unknown;.;destination_version=.=unknown;.;destination_service=.=application-test-20200806153911-b9h19-1.f9ecfdc4-77f6.svc.cluster.local;.;destination_service_name=.=application-test-20200806153911-b9h19-1.f9ecfdc4-77f6.svc.cluster.local;.;destination_service_namespace=.=unknown;.;destination_canonical_service=.=unknown;.;destination_canonical_revision=.=latest;.;request_protocol=.=http;.;response_code=.=200;.;grpc_response_status=.=;.;response_flags=.=-;.;connection_security_policy=.=unknown;.;_istio_response_bytes: P0(nan,180) P25(nan,182.5) P50(nan,185) P75(nan,187.5) P90(nan,189) P95(nan,189.5) P99(nan,189.9) P99.5(nan,189.95) P99.9(nan,189.99) P100(nan,190)

But from istio code https://github.com/istio/istio/blob/master/pilot/cmd/pilot-agent/status/util/util.go#L25, there hardcoded 1 second as the request timeout. Actually, we don't have too many services running in the cluster, only around 100. The reason of why there are so many metrics is that we run some service performance test more often in this cluster, like creating 1000 services and deleting them later on. Most of metrics returned are the  metrics of services which were already not existed.
I think we didn't see this problem in Istio 1.4.x, because it didn't query filter in 1.4.x, just query the full stats, but since 1.5.x, the code is changed to query with a filter, which consumed longer time. So looked like the filter took much longer time.
Query the full stats without the filter
root@cluster-local-gateway-65bff8bcd9-2btwd:/# time curl "http://127.0.0.1:15000/stats?usedonly" > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 22.9M    0 22.9M    0     0  74.6M      0 --:--:-- --:--:-- --:--:-- 74.9M

real	0m0.317s
user	0m0.008s
sys	0m0.023s

Query the stats with the filter
root@cluster-local-gateway-65bff8bcd9-2btwd:/# time curl "http://127.0.0.1:15000/stats?usedonly&filter=server.state" > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    16    0    16    0     0     13      0 --:--:--  0:00:01 --:--:--    13

real	0m1.241s
user	0m0.002s
sys	0m0.010s

I think the solution might be to revert to query the stats without filter if we can't improve the performance of filter from proxy side. Thanks.
[ ] Docs
[ ] Installation
[ ] Networking
[x] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
Steps to reproduce the bug
Keep creating/deleting services, you can see the metrics of envoy in cluster-local-gateway and istio-ingressgateway pods will be growing fast, so requesting the metrics will get slower.
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
cluster-local-gateway version:
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
pilot version: 1.5.4
pilot version: 1.5.4
pilot version: 1.5.4
data plane version: 1.5.4 (20 proxies)

How was Istio installed?
Environment where bug was observed (cloud vendor, OS, etc)
Knative

@mattcui can you get debug level log from the proxy? as well as non-filtered stats. Or an instruction to reproduce will be also appreciated.

@lizan Thanks for your reply, I will try to see if I can get debug log of the proxy. For the step to reproduce, I gave a rough description above:
Steps to reproduce the bug
Keep creating/deleting services, you can see the metrics of envoy in cluster-local-gateway and istio-ingressgateway pods will be growing fast, so requesting the metrics will get slower.

I think you could run a script to create/delete a large number of services (we created knative services as our platform is based on the knative), you could login the local gateway pod and run time curl http://127.0.0.1:15000/stats?usedonly&filter=server.state, you may see it's getting slower when you create/delete services more and more, and eventually, the local gateway pod will be shown as unready as it can't get the return of metrics querying within 1 second. I think you could reach to it when you create/delete 1500-2000 services.
cluster-local-gateway-9d89bf6b4-5l8kw   0/1     Running   0          2d11h
cluster-local-gateway-9d89bf6b4-6n7c8   0/1     Running   0          2d12h
cluster-local-gateway-9d89bf6b4-9b5c8   0/1     Running   0          2d12h
cluster-local-gateway-9d89bf6b4-9vflt   0/1     Running   2          2d12h
cluster-local-gateway-9d89bf6b4-j6wth   0/1     Running   0          2d10h
cluster-local-gateway-9d89bf6b4-lgnmp   0/1     Running   0          2d12h
cluster-local-gateway-9d89bf6b4-p7gs4   0/1     Running   2          2d12h
cluster-local-gateway-9d89bf6b4-w2j86   0/1     Running   0          2d15h
cluster-local-gateway-9d89bf6b4-zg7tn   0/1     Running   0          2d13h
cluster-local-gateway-9d89bf6b4-zw8jr   0/1     Running   0          2d14h
```

@lizan I had some more findings and update the issue description, I think the key is "filter", for istio 1.4.x, there just query the stats without any filter, it can be returned within one second even though there are a large number of metrics, but since 1.5.x, the proxy-agent changed to query the stats with a filter, which consumed much longer time. So need your advice if we could revert to just query the stats like istio 1.4.x or try to improve the performance of filter from the proxy side. Thanks.

Yeah that might be the case. @mattcui can you share the unfiltered /stats output? I'd like to see what grows the number of stats that big.
cc @ramaraochavali

@lizan , I posted first lines of /stats here,
cluster.xds-grpc.circuit_breakers.default.rq_open: 0
cluster.xds-grpc.circuit_breakers.default.rq_pending_open: 0
cluster.xds-grpc.default.total_match_count: 1030
cluster.xds-grpc.internal.upstream_rq_200: 188
cluster.xds-grpc.internal.upstream_rq_2xx: 188
cluster.xds-grpc.internal.upstream_rq_503: 5
cluster.xds-grpc.internal.upstream_rq_5xx: 5
cluster.xds-grpc.internal.upstream_rq_completed: 193
cluster.xds-grpc.lb_healthy_panic: 1
cluster.xds-grpc.max_host_weight: 1
cluster.xds-grpc.membership_change: 1
cluster.xds-grpc.membership_degraded: 0
cluster.xds-grpc.membership_excluded: 0
cluster.xds-grpc.membership_healthy: 1
cluster.xds-grpc.membership_total: 1
cluster.xds-grpc.update_attempt: 1030
cluster.xds-grpc.update_no_rebuild: 1029
cluster.xds-grpc.update_success: 1030
cluster.xds-grpc.upstream_cx_active: 1
cluster.xds-grpc.upstream_cx_close_notify: 175
cluster.xds-grpc.upstream_cx_connect_fail: 4
cluster.xds-grpc.upstream_cx_destroy: 191
cluster.xds-grpc.upstream_cx_destroy_remote: 191
cluster.xds-grpc.upstream_cx_destroy_remote_with_active_rq: 187
cluster.xds-grpc.upstream_cx_destroy_with_active_rq: 187
cluster.xds-grpc.upstream_cx_http2_total: 192
cluster.xds-grpc.upstream_cx_none_healthy: 1
cluster.xds-grpc.upstream_cx_rx_bytes_buffered: 43
cluster.xds-grpc.upstream_cx_rx_bytes_total: 24294044563
cluster.xds-grpc.upstream_cx_total: 192
cluster.xds-grpc.upstream_cx_tx_bytes_buffered: 0
cluster.xds-grpc.upstream_cx_tx_bytes_total: 7736740356
cluster.xds-grpc.upstream_flow_control_backed_up_total: 8
cluster.xds-grpc.upstream_flow_control_drained_total: 8
cluster.xds-grpc.upstream_rq_200: 188
cluster.xds-grpc.upstream_rq_2xx: 188
cluster.xds-grpc.upstream_rq_503: 5
cluster.xds-grpc.upstream_rq_5xx: 5
cluster.xds-grpc.upstream_rq_active: 1
cluster.xds-grpc.upstream_rq_completed: 193
cluster.xds-grpc.upstream_rq_pending_active: 0
cluster.xds-grpc.upstream_rq_pending_failure_eject: 191
cluster.xds-grpc.upstream_rq_pending_total: 192
cluster.xds-grpc.upstream_rq_total: 188
cluster_manager.active_clusters: 478
cluster_manager.cds.update_attempt: 34889
cluster_manager.cds.update_failure: 191
cluster_manager.cds.update_success: 34697
cluster_manager.cds.version: 2214976834056690684
cluster_manager.cluster_added: 43043
cluster_manager.cluster_modified: 64731
cluster_manager.cluster_removed: 42565
cluster_manager.cluster_updated: 103163
cluster_manager.warming_clusters: 0
component.proxy.tag.1.5.4;._istio_build: 1
listener_manager.lds.update_attempt: 43746
listener_manager.lds.update_failure: 191
listener_manager.lds.update_success: 43554
listener_manager.lds.version: 2214976834056690684
listener_manager.listener_added: 2
listener_manager.listener_create_success: 32
listener_manager.total_listeners_active: 2
listener_manager.total_listeners_warming: 0
listener_manager.workers_started: 1
reporter=.=source;.;source_workload=.=cluster-local-gateway;.;source_workload_namespace=.=istio-system;.;source_principal=.=unknown;.;source_app=.=cluster-local-gateway;.;source_version=.=unknown;.;source_canonical_service=.=cluster-local-gateway;.;source_canonical_revision=.=latest;.;destination_workload=.=unknown;.;destination_workload_namespace=.=unknown;.;destination_principal=.=unknown;.;destination_app=.=unknown;.;destination_version=.=unknown;.;destination_service=.=app3598-ajwwh-1.07483e15-ee40.svc.cluster.local;.;destination_service_name=.=app3598-ajwwh-1.07483e15-ee40.svc.cluster.local;.;destination_service_namespace=.=unknown;.;destination_canonical_service=.=unknown;.;destination_canonical_revision=.=latest;.;request_protocol=.=http;.;response_code=.=200;.;grpc_response_status=.=;.;response_flags=.=-;.;connection_security_policy=.=unknown;.;_istio_requests_total: 1
reporter=.=source;.;source_workload=.=cluster-local-gateway;.;source_workload_namespace=.=istio-system;.;source_principal=.=unknown;.;source_app=.=cluster-local-gateway;.;source_version=.=unknown;.;source_canonical_service=.=cluster-local-gateway;.;source_canonical_revision=.=latest;.;destination_workload=.=unknown;.;destination_workload_namespace=.=unknown;.;destination_principal=.=unknown;.;destination_app=.=unknown;.;destination_version=.=unknown;.;destination_service=.=app3598-baicm-1.07483e15-ee40.svc.cluster.local;.;destination_service_name=.=app3598-baicm-1.07483e15-ee40.svc.cluster.local;.;destination_service_namespace=.=unknown;.;destination_canonical_service=.=unknown;.;destination_canonical_revision=.=latest;.;request_protocol=.=http;.;response_code=.=0;.;grpc_response_status=.=;.;response_flags=.=DC;.;connection_security_policy=.=unknown;.;_istio_requests_total: 2
reporter=.=source;.;source_workload=.=cluster-local-gateway;.;source_workload_namespace=.=istio-system;.;source_principal=.=unknown;.;source_app=.=cluster-local-gateway;.;source_version=.=unknown;.;source_canonical_service=.=cluster-local-gateway;.;source_canonical_revision=.=latest;.;destination_workload=.=unknown;.;destination_workload_namespace=.=unknown;.;destination_principal=.=unknown;.;destination_app=.=unknown;.;destination_version=.=unknown;.;destination_service=.=app3598-baicm-1.07483e15-ee40.svc.cluster.local;.;destination_service_name=.=app3598-baicm-1.07483e15-ee40.svc.cluster.local;.;destination_service_namespace=.=unknown;.;destination_canonical_service=.=unknown;.;destination_canonical_revision=.=latest;.;request_protocol=.=http;.;response_code=.=200;.;grpc_response_status=.=;.;response_flags=.=-;.;connection_security_policy=.=unknown;.;_istio_requests_total: 10
reporter=.=source;.;source_workload=.=cluster-local-gateway;.;source_workload_namespace=.=istio-system;.;source_principal=.=unknown;.;source_app=.=cluster-local-gateway;.;source_version=.=unknown;.;source_canonical_service=.=cluster-local-gateway;.;source_canonical_revision=.=latest;.;destination_workload=.=unknown;.;destination_workload_namespace=.=unknown;.;destination_principal=.=unknown;.;destination_app=.=unknown;.;destination_version=.=unknown;.;destination_service=.=app3598-icmra-1.07483e15-ee40.svc.cluster.local;.;destination_service_name=.=app3598-icmra-1.07483e15-ee40.svc.cluster.local;.;destination_service_namespace=.=unknown;.;destination_canonical_service=.=unknown;.;destination_canonical_revision=.=latest;.;request_protocol=.=http;.;response_code=.=200;.;grpc_response_status=.=;.;response_flags=.=-;.;connection_security_policy=.=unknown;.;_istio_requests_total: 14

The remaining around 18000 entries are all like:
reporter=.=source;.;source_workload=.=cluster-local-gateway;.;source_workload_namespace=.=istio-system;.;source_principal=.=unknown;.;source_app=.=cluster-local-gateway;.;source_version=.=unknown;.;source_canonical_service=.=cluster-local-gateway;.;source_canonical_revision=.=latest;.;destination_workload=.=unknown;.;destination_workload_namespace=.=unknown;.;destination_principal=.=unknown;.;destination_app=.=unknown;.;destination_version=.=unknown;.;destination_service=.=coligo-e2e-test-1-knservice-7d2034c2-vljyn-1.476027a1-352e.svc.cluster.local;.;destination_service_name=.=coligo-e2e-test-1-knservice-7d2034c2-vljyn-1.476027a1-352e.svc.cluster.local;.;destination_service_namespace=.=unknown;.;destination_canonical_service=.=unknown;.;destination_canonical_revision=.=latest;.;request_protocol=.=http;.;response_code=.=200;.;grpc_response_status=.=;.;response_flags=.=-;.;connection_security_policy=.=unknown;.;_istio_requests_total: 1

As I mentioned in the issue description, all services including non-existed ones (already deleted) were shown in the stats.

Looks like filter=server.state is slow because it is a doing regex match. I am fine reverting that filter and just have usedonly if that helps.

btw, are you using istio telemetry? @mandarjog are those 18000 stats expected?

@ramaraochavali No, we don't enable istio telemetry.

interesting. Let us wait for @mandarjog  to confirm why they are generated when telemetry is not enabled?

Did you create and destroy these services and send traffic thru them? Is this a knative use case?
We have an outstanding issue in telemetry v2 of metric expiry.
https://github.com/istio/istio/issues/21377
We are targeting istio 1.8 to fix it.

The workaround right now is to limit the maximum lifetime of a gateway. Daily restart or 2 restarts a day would let you work around the problem.

@mandarjog Actually, we didn't explicitly enable telemetry or install telemetry addons, but our monitoring system (like sysdig) should scrape metrics from there. As our platform (based on Knative+istio) targets to run 5000+ services, do you think #21377 could address our requirements to support a large number of services, the proxy-agent could retrieve stats/metrics with filter in one second? Thanks.

@ramaraochavali yeah I expected the regex would be slow but it shouldn't be that slow, can we get a quick fix by escaping the ., or not using the regex filter in 1.6 and 1.7?

@lizan https://github.com/istio/istio/pull/26634 PR to not use regex filter

@lizan @ramaraochavali As we have to stay at istio 1.5.x for maybe 1 or 2 months, possible to also patch this fix in 1.5.x stream? Thanks.

@mattcui can you please check if escaping . is helping in your env?

@ramaraochavali don't see promising decrease
root@cluster-local-gateway-644fd5f945-b7tnm:/# time curl "http://127.0.0.1:15000/stats?usedonly&filter=^(server.state|listener_manager.workers_started)" > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    52    0    52    0     0     92      0 --:--:-- --:--:-- --:--:--    92

real	0m0.572s
user	0m0.000s
sys	0m0.011s
root@cluster-local-gateway-644fd5f945-b7tnm:/# time curl "http://127.0.0.1:15000/stats?usedonly&filter=^(server\.state|listener_manager\.workers_started)" > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    52    0    52    0     0    100      0 --:--:-- --:--:-- --:--:--   100

real	0m0.525s
user	0m0.008s
sys	0m0.004s
root@cluster-local-gateway-644fd5f945-b7tnm:/# time curl "http://127.0.0.1:15000/stats?usedonly&filter=^(server.state|listener_manager.workers_started)" > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    52    0    52    0     0    105      0 --:--:-- --:--:-- --:--:--   105

real	0m0.503s
user	0m0.004s
sys	0m0.007s
root@cluster-local-gateway-644fd5f945-b7tnm:/# time curl "http://127.0.0.1:15000/stats?usedonly&filter=^(server\.state|listener_manager\.workers_started)" > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    52    0    52    0     0     84      0 --:--:-- --:--:-- --:--:--    84

real	0m0.628s
user	0m0.006s
sys	0m0.005s

authors: lizan mandarjog mattcui ramaraochavali


text:
BUG: Sidecar scope one domain, but can access all domains in the virtualservice

Bug description
Sidecar scope one domain, but can access all domains in the virtualservice.
In the following example, the pod can access qq.com, which is not expected to happen.
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
only access the host in Sidecar hosts.
Steps to reproduce the bug
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubuntu
spec:
  selector:
    matchLabels:
      app: ubuntu
  template:
    metadata:
      labels:
        app: ubuntu
    spec:
      restartPolicy: Always
      containers:
      - name: ubuntu
        image: ubuntu
        imagePullPolicy: Always
        command:
          - sleep
          - "3600"
---
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: ubuntu
spec:
  workloadSelector:
    labels:
      app: ubuntu
  egress:
  - captureMode: IPTABLES
    hosts:
    - "*/archive.ubuntu.com"
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: ubuntu
spec:
  hosts:
    - "archive.ubuntu.com"
  ports:
  - number: 443
    name: tls
    protocol: TLS
  - number: 80
    name: http
    protocol: HTTP
  location: MESH_EXTERNAL
  resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ubuntu
spec:
  hosts:
    - "*.ubuntu.com"
    - "qq.com"
  http:
  - route:
    - destination:
        host: http-proxy.proxy.svc.cluster.local
        port:
          number: 8080

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
$ istioctl version --remote
client version: 1.7.0-beta.1
control plane version: unknown
data plane version: 1.7.0-beta.1 (3 proxies)
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T23:35:15Z", GoVersion:"go1.14.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.4", GitCommit:"c96aede7b5205121079932896c4ad89bb93260af", GitTreeState:"clean", BuildDate:"2020-06-17T11:33:59Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
How was Istio installed?
istioctl
Environment where bug was observed (cloud vendor, OS, etc)

https://github.com/istio/istio/pull/20408 - Based on this your virtual service destinations are also added as clusters

tested, fixed in 1.7.0-rc.1

authors: liuzheng ramaraochavali


text:
Issue with HTTP communication from Prometheus to Alertmanager

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities
To ask questions about how to use Istio, please visit https://discuss.istio.io)
Bug description
Since the upgrade from Istio 1.7 to 1.8 we're seeing issues with specially the communication from our Prometheus to our Alertmanager (pushing alarms via HTTP).
Error message:
level=error ts=2021-05-31T07:16:45.210Z caller=notifier.go:527 component=notifier alertmanager=http://100.96.9.151:9093/api/v2/alerts count=1 msg="Error sending alert" err="bad response status 404 Not Found"

Both, Prometheus & Alertmanager are installed via the prometheus-operator and therefore two headless Kubernetes Service exist called prometheus-operated & alertmanager-operated, those services are hard-coded into the prometheus-operator and can not be changed.
Next to it each "installation" of those two components has an own service, which is not headless and under full-control by us. (alertmanager-main & prometheus-k8s)
One thing we tried and also worked is to down scale the prometheus-operator to 0 and add the appProtocol tags on the -operated Kubernetes services with the value http which worked, but is overwritten, as long as the operator is not scaled to zero.
If we're setting the appProtocol on the by us controlled service, it is not working out.
Any clue how to to fix it?
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ X ] User Experience
[ ] Developer Infrastructure
[ X ] Upgrade
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
Istio version:
➜ istioctl version --remote
client version: 1.10.0
control plane version: 1.8.5
data plane version: 1.8.5 (78 proxies)

Kubernetes version:
➜ kubectl version --short
Client Version: v1.19.7
Server Version: v1.19.10

How was Istio installed?
via the istio-operator also in version 1.8.5
Environment where the bug was observed (cloud vendor, OS, etc)
Running on a kOps cluster on AWS.
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

Uploading bug-report.tar.gz…

I think the issue is that the command is matching the alertmanager-operated.monitoring.svc.cluster.local:9093 route, which has domains:
  virtualHosts:
  - domains:
    - alertmanager-operated.monitoring.svc.cluster.local
    - alertmanager-operated.monitoring.svc.cluster.local:9093
    - alertmanager-operated
    - alertmanager-operated:9093
    - alertmanager-operated.monitoring.svc.cluster
    - alertmanager-operated.monitoring.svc.cluster:9093
    - alertmanager-operated.monitoring.svc
    - alertmanager-operated.monitoring.svc:9093
    - alertmanager-operated.monitoring
    - alertmanager-operated.monitoring:9093
    - '*.alertmanager-operated.monitoring.svc.cluster.local'
    - '*.alertmanager-operated.monitoring.svc.cluster.local:9093'
    - '*.alertmanager-operated'
    - '*.alertmanager-operated:9093'
    - '*.alertmanager-operated.monitoring.svc.cluster'
    - '*.alertmanager-operated.monitoring.svc.cluster:9093'
    - '*.alertmanager-operated.monitoring.svc'
    - '*.alertmanager-operated.monitoring.svc:9093'
    - '*.alertmanager-operated.monitoring'
    - '*.alertmanager-operated.monitoring:9093'

So the request is probably like curl 100.96.9.151:9093 equivalent, which then doesn't match.
This seems like a bug.

@hzxuzhonghu wdyt?

If you need any additional information, let me know.

The same behaviour can be reproduced with istio 1.8.3

@triantium did you find away around that issue?

@howardjohn @hzxuzhonghu do you have any tips to workaround this issue or even better a fix?

@triantium did you find away around that issue?

Sadly no. I don't know how the hostnames are discovered, but i think that is the place to look for.

We are running many setup with many Prometheus and one Alertmanager, some of these Prometheuses are Istio-enabled, Alertmanager is not. After upgrading to 1.8 we hit this issue when istio-enabled Prometheuses can't reach Alertmanager.
To workaround this issue we've put this into Promethues resource manifest:
spec:
...
  podMetadata:
    annotations:
      traffic.sidecar.istio.io/excludeOutboundPorts: "9093"

authors: guusvw howardjohn sitnik triantium