text:
Auto highlight won't end with this file

// !$UTF8$!
{
archiveVersion = 1;
classes = {
};
objectVersion = 46;
objects = {
/* Begin PBXBuildFile section /
E32D37AE1AB426260019547B / AppDelegate.swift in Sources / = {isa = PBXBuildFile; fileRef = E32D37AD1AB426260019547B / AppDelegate.swift /; };
E32D37B01AB426260019547B / ViewController.swift in Sources / = {isa = PBXBuildFile; fileRef = E32D37AF1AB426260019547B / ViewController.swift /; };
E32D37B31AB426260019547B / Main.storyboard in Resources / = {isa = PBXBuildFile; fileRef = E32D37B11AB426260019547B / Main.storyboard /; };
E32D37B51AB426260019547B / Images.xcassets in Resources / = {isa = PBXBuildFile; fileRef = E32D37B41AB426260019547B / Images.xcassets /; };
E32D37B81AB426260019547B / LaunchScreen.xib in Resources / = {isa = PBXBuildFile; fileRef = E32D37B61AB426260019547B / LaunchScreen.xib /; };
E32D37C41AB426260019547B / HelloWorldTests.swift in Sources / = {isa = PBXBuildFile; fileRef = E32D37C31AB426260019547B / HelloWorldTests.swift /; };
/ End PBXBuildFile section */
/* Begin PBXContainerItemProxy section /
E32D37BE1AB426260019547B / PBXContainerItemProxy / = {
isa = PBXContainerItemProxy;
containerPortal = E32D37A01AB426260019547B / Project object /;
proxyType = 1;
remoteGlobalIDString = E32D37A71AB426260019547B;
remoteInfo = HelloWorld;
};
/ End PBXContainerItemProxy section */
/* Begin PBXFileReference section /
E32D37A81AB426260019547B / HelloWorld.app / = {isa = PBXFileReference; explicitFileType = wrapper.application; includeInIndex = 0; path = HelloWorld.app; sourceTree = BUILT_PRODUCTS_DIR; };
E32D37AC1AB426260019547B / Info.plist / = {isa = PBXFileReference; lastKnownFileType = text.plist.xml; path = Info.plist; sourceTree = ""; };
E32D37AD1AB426260019547B / AppDelegate.swift / = {isa = PBXFileReference; lastKnownFileType = sourcecode.swift; path = AppDelegate.swift; sourceTree = ""; };
E32D37AF1AB426260019547B / ViewController.swift / = {isa = PBXFileReference; lastKnownFileType = sourcecode.swift; path = ViewController.swift; sourceTree = ""; };
E32D37B21AB426260019547B / Base / = {isa = PBXFileReference; lastKnownFileType = file.storyboard; name = Base; path = Base.lproj/Main.storyboard; sourceTree = ""; };
E32D37B41AB426260019547B / Images.xcassets / = {isa = PBXFileReference; lastKnownFileType = folder.assetcatalog; path = Images.xcassets; sourceTree = ""; };
E32D37B71AB426260019547B / Base / = {isa = PBXFileReference; lastKnownFileType = file.xib; name = Base; path = Base.lproj/LaunchScreen.xib; sourceTree = ""; };
E32D37BD1AB426260019547B / HelloWorldTests.xctest / = {isa = PBXFileReference; explicitFileType = wrapper.cfbundle; includeInIndex = 0; path = HelloWorldTests.xctest; sourceTree = BUILT_PRODUCTS_DIR; };
E32D37C21AB426260019547B / Info.plist / = {isa = PBXFileReference; lastKnownFileType = text.plist.xml; path = Info.plist; sourceTree = ""; };
E32D37C31AB426260019547B / HelloWorldTests.swift / = {isa = PBXFileReference; lastKnownFileType = sourcecode.swift; path = HelloWorldTests.swift; sourceTree = ""; };
/ End PBXFileReference section */
/* Begin PBXFrameworksBuildPhase section /
E32D37A51AB426260019547B / Frameworks / = {
isa = PBXFrameworksBuildPhase;
buildActionMask = 2147483647;
files = (
);
runOnlyForDeploymentPostprocessing = 0;
};
E32D37BA1AB426260019547B / Frameworks / = {
isa = PBXFrameworksBuildPhase;
buildActionMask = 2147483647;
files = (
);
runOnlyForDeploymentPostprocessing = 0;
};
/ End PBXFrameworksBuildPhase section */
/* Begin PBXGroup section /
E32D379F1AB426260019547B = {
isa = PBXGroup;
children = (
E32D37AA1AB426260019547B / HelloWorld /,
E32D37C01AB426260019547B / HelloWorldTests /,
E32D37A91AB426260019547B / Products /,
);
sourceTree = "";
};
E32D37A91AB426260019547B / Products / = {
isa = PBXGroup;
children = (
E32D37A81AB426260019547B / HelloWorld.app /,
E32D37BD1AB426260019547B / HelloWorldTests.xctest /,
);
name = Products;
sourceTree = "";
};
E32D37AA1AB426260019547B / HelloWorld / = {
isa = PBXGroup;
children = (
E32D37AD1AB426260019547B / AppDelegate.swift /,
E32D37AF1AB426260019547B / ViewController.swift /,
E32D37B11AB426260019547B / Main.storyboard /,
E32D37B41AB426260019547B / Images.xcassets /,
E32D37B61AB426260019547B / LaunchScreen.xib /,
E32D37AB1AB426260019547B / Supporting Files /,
);
path = HelloWorld;
sourceTree = "";
};
E32D37AB1AB426260019547B / Supporting Files / = {
isa = PBXGroup;
children = (
E32D37AC1AB426260019547B / Info.plist /,
);
name = "Supporting Files";
sourceTree = "";
};
E32D37C01AB426260019547B / HelloWorldTests / = {
isa = PBXGroup;
children = (
E32D37C31AB426260019547B / HelloWorldTests.swift /,
E32D37C11AB426260019547B / Supporting Files /,
);
path = HelloWorldTests;
sourceTree = "";
};
E32D37C11AB426260019547B / Supporting Files / = {
isa = PBXGroup;
children = (
E32D37C21AB426260019547B / Info.plist /,
);
name = "Supporting Files";
sourceTree = "";
};
/ End PBXGroup section */
/* Begin PBXNativeTarget section /
E32D37A71AB426260019547B / HelloWorld / = {
isa = PBXNativeTarget;
buildConfigurationList = E32D37C71AB426260019547B / Build configuration list for PBXNativeTarget "HelloWorld" /;
buildPhases = (
E32D37A41AB426260019547B / Sources /,
E32D37A51AB426260019547B / Frameworks /,
E32D37A61AB426260019547B / Resources /,
);
buildRules = (
);
dependencies = (
);
name = HelloWorld;
productName = HelloWorld;
productReference = E32D37A81AB426260019547B / HelloWorld.app /;
productType = "com.apple.product-type.application";
};
E32D37BC1AB426260019547B / HelloWorldTests / = {
isa = PBXNativeTarget;
buildConfigurationList = E32D37CA1AB426260019547B / Build configuration list for PBXNativeTarget "HelloWorldTests" /;
buildPhases = (
E32D37B91AB426260019547B / Sources /,
E32D37BA1AB426260019547B / Frameworks /,
E32D37BB1AB426260019547B / Resources /,
);
buildRules = (
);
dependencies = (
E32D37BF1AB426260019547B / PBXTargetDependency /,
);
name = HelloWorldTests;
productName = HelloWorldTests;
productReference = E32D37BD1AB426260019547B / HelloWorldTests.xctest /;
productType = "com.apple.product-type.bundle.unit-test";
};
/ End PBXNativeTarget section */
/* Begin PBXProject section /
E32D37A01AB426260019547B / Project object / = {
isa = PBXProject;
attributes = {
LastUpgradeCheck = 0620;
ORGANIZATIONNAME = v_hasu;
TargetAttributes = {
E32D37A71AB426260019547B = {
CreatedOnToolsVersion = 6.2;
};
E32D37BC1AB426260019547B = {
CreatedOnToolsVersion = 6.2;
TestTargetID = E32D37A71AB426260019547B;
};
};
};
buildConfigurationList = E32D37A31AB426260019547B / Build configuration list for PBXProject "HelloWorld" /;
compatibilityVersion = "Xcode 3.2";
developmentRegion = English;
hasScannedForEncodings = 0;
knownRegions = (
en,
Base,
);
mainGroup = E32D379F1AB426260019547B;
productRefGroup = E32D37A91AB426260019547B / Products /;
projectDirPath = "";
projectRoot = "";
targets = (
E32D37A71AB426260019547B / HelloWorld /,
E32D37BC1AB426260019547B / HelloWorldTests /,
);
};
/ End PBXProject section */
/* Begin PBXResourcesBuildPhase section /
E32D37A61AB426260019547B / Resources / = {
isa = PBXResourcesBuildPhase;
buildActionMask = 2147483647;
files = (
E32D37B31AB426260019547B / Main.storyboard in Resources /,
E32D37B81AB426260019547B / LaunchScreen.xib in Resources /,
E32D37B51AB426260019547B / Images.xcassets in Resources /,
);
runOnlyForDeploymentPostprocessing = 0;
};
E32D37BB1AB426260019547B / Resources / = {
isa = PBXResourcesBuildPhase;
buildActionMask = 2147483647;
files = (
);
runOnlyForDeploymentPostprocessing = 0;
};
/ End PBXResourcesBuildPhase section */
/* Begin PBXSourcesBuildPhase section /
E32D37A41AB426260019547B / Sources / = {
isa = PBXSourcesBuildPhase;
buildActionMask = 2147483647;
files = (
E32D37B01AB426260019547B / ViewController.swift in Sources /,
E32D37AE1AB426260019547B / AppDelegate.swift in Sources /,
);
runOnlyForDeploymentPostprocessing = 0;
};
E32D37B91AB426260019547B / Sources / = {
isa = PBXSourcesBuildPhase;
buildActionMask = 2147483647;
files = (
E32D37C41AB426260019547B / HelloWorldTests.swift in Sources /,
);
runOnlyForDeploymentPostprocessing = 0;
};
/ End PBXSourcesBuildPhase section */
/* Begin PBXTargetDependency section /
E32D37BF1AB426260019547B / PBXTargetDependency / = {
isa = PBXTargetDependency;
target = E32D37A71AB426260019547B / HelloWorld /;
targetProxy = E32D37BE1AB426260019547B / PBXContainerItemProxy /;
};
/ End PBXTargetDependency section */
/* Begin PBXVariantGroup section /
E32D37B11AB426260019547B / Main.storyboard / = {
isa = PBXVariantGroup;
children = (
E32D37B21AB426260019547B / Base /,
);
name = Main.storyboard;
sourceTree = "";
};
E32D37B61AB426260019547B / LaunchScreen.xib / = {
isa = PBXVariantGroup;
children = (
E32D37B71AB426260019547B / Base /,
);
name = LaunchScreen.xib;
sourceTree = "";
};
/ End PBXVariantGroup section */
/* Begin XCBuildConfiguration section /
E32D37C51AB426260019547B / Debug / = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CLANG_CXX_LANGUAGE_STANDARD = "gnu++0x";
CLANG_CXX_LIBRARY = "libc++";
CLANG_ENABLE_MODULES = YES;
CLANG_ENABLE_OBJC_ARC = YES;
CLANG_WARN_BOOL_CONVERSION = YES;
CLANG_WARN_CONSTANT_CONVERSION = YES;
CLANG_WARN_DIRECT_OBJC_ISA_USAGE = YES_ERROR;
CLANG_WARN_EMPTY_BODY = YES;
CLANG_WARN_ENUM_CONVERSION = YES;
CLANG_WARN_INT_CONVERSION = YES;
CLANG_WARN_OBJC_ROOT_CLASS = YES_ERROR;
CLANG_WARN_UNREACHABLE_CODE = YES;
CLANG_WARN__DUPLICATE_METHOD_MATCH = YES;
"CODE_SIGN_IDENTITY[sdk=iphoneos]" = "iPhone Developer";
COPY_PHASE_STRIP = NO;
ENABLE_STRICT_OBJC_MSGSEND = YES;
GCC_C_LANGUAGE_STANDARD = gnu99;
GCC_DYNAMIC_NO_PIC = NO;
GCC_OPTIMIZATION_LEVEL = 0;
GCC_PREPROCESSOR_DEFINITIONS = (
"DEBUG=1",
"$(inherited)",
);
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
GCC_WARN_64_TO_32_BIT_CONVERSION = YES;
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR;
GCC_WARN_UNDECLARED_SELECTOR = YES;
GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE;
GCC_WARN_UNUSED_FUNCTION = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
IPHONEOS_DEPLOYMENT_TARGET = 8.2;
MTL_ENABLE_DEBUG_INFO = YES;
ONLY_ACTIVE_ARCH = YES;
SDKROOT = iphoneos;
SWIFT_OPTIMIZATION_LEVEL = "-Onone";
TARGETED_DEVICE_FAMILY = "1,2";
};
name = Debug;
};
E32D37C61AB426260019547B /* Release / = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CLANG_CXX_LANGUAGE_STANDARD = "gnu++0x";
CLANG_CXX_LIBRARY = "libc++";
CLANG_ENABLE_MODULES = YES;
CLANG_ENABLE_OBJC_ARC = YES;
CLANG_WARN_BOOL_CONVERSION = YES;
CLANG_WARN_CONSTANT_CONVERSION = YES;
CLANG_WARN_DIRECT_OBJC_ISA_USAGE = YES_ERROR;
CLANG_WARN_EMPTY_BODY = YES;
CLANG_WARN_ENUM_CONVERSION = YES;
CLANG_WARN_INT_CONVERSION = YES;
CLANG_WARN_OBJC_ROOT_CLASS = YES_ERROR;
CLANG_WARN_UNREACHABLE_CODE = YES;
CLANG_WARN__DUPLICATE_METHOD_MATCH = YES;
"CODE_SIGN_IDENTITY[sdk=iphoneos]" = "iPhone Developer";
COPY_PHASE_STRIP = NO;
ENABLE_NS_ASSERTIONS = NO;
ENABLE_STRICT_OBJC_MSGSEND = YES;
GCC_C_LANGUAGE_STANDARD = gnu99;
GCC_WARN_64_TO_32_BIT_CONVERSION = YES;
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR;
GCC_WARN_UNDECLARED_SELECTOR = YES;
GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE;
GCC_WARN_UNUSED_FUNCTION = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
IPHONEOS_DEPLOYMENT_TARGET = 8.2;
MTL_ENABLE_DEBUG_INFO = NO;
SDKROOT = iphoneos;
TARGETED_DEVICE_FAMILY = "1,2";
VALIDATE_PRODUCT = YES;
};
name = Release;
};
E32D37C81AB426260019547B /* Debug / = {
isa = XCBuildConfiguration;
buildSettings = {
ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
INFOPLIST_FILE = HelloWorld/Info.plist;
LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks";
PRODUCT_NAME = "$(TARGET_NAME)";
};
name = Debug;
};
E32D37C91AB426260019547B / Release / = {
isa = XCBuildConfiguration;
buildSettings = {
ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
INFOPLIST_FILE = HelloWorld/Info.plist;
LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks";
PRODUCT_NAME = "$(TARGET_NAME)";
};
name = Release;
};
E32D37CB1AB426260019547B / Debug / = {
isa = XCBuildConfiguration;
buildSettings = {
BUNDLE_LOADER = "$(TEST_HOST)";
FRAMEWORK_SEARCH_PATHS = (
"$(SDKROOT)/Developer/Library/Frameworks",
"$(inherited)",
);
GCC_PREPROCESSOR_DEFINITIONS = (
"DEBUG=1",
"$(inherited)",
);
INFOPLIST_FILE = HelloWorldTests/Info.plist;
LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks @loader_path/Frameworks";
PRODUCT_NAME = "$(TARGET_NAME)";
TEST_HOST = "$(BUILT_PRODUCTS_DIR)/HelloWorld.app/HelloWorld";
};
name = Debug;
};
E32D37CC1AB426260019547B / Release / = {
isa = XCBuildConfiguration;
buildSettings = {
BUNDLE_LOADER = "$(TEST_HOST)";
FRAMEWORK_SEARCH_PATHS = (
"$(SDKROOT)/Developer/Library/Frameworks",
"$(inherited)",
);
INFOPLIST_FILE = HelloWorldTests/Info.plist;
LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks @loader_path/Frameworks";
PRODUCT_NAME = "$(TARGET_NAME)";
TEST_HOST = "$(BUILT_PRODUCTS_DIR)/HelloWorld.app/HelloWorld";
};
name = Release;
};
/ End XCBuildConfiguration section */
/* Begin XCConfigurationList section /
E32D37A31AB426260019547B / Build configuration list for PBXProject "HelloWorld" / = {
isa = XCConfigurationList;
buildConfigurations = (
E32D37C51AB426260019547B / Debug /,
E32D37C61AB426260019547B / Release /,
);
defaultConfigurationIsVisible = 0;
defaultConfigurationName = Release;
};
E32D37C71AB426260019547B / Build configuration list for PBXNativeTarget "HelloWorld" / = {
isa = XCConfigurationList;
buildConfigurations = (
E32D37C81AB426260019547B / Debug /,
E32D37C91AB426260019547B / Release /,
);
defaultConfigurationIsVisible = 0;
};
E32D37CA1AB426260019547B / Build configuration list for PBXNativeTarget "HelloWorldTests" / = {
isa = XCConfigurationList;
buildConfigurations = (
E32D37CB1AB426260019547B / Debug /,
E32D37CC1AB426260019547B / Release /,
);
defaultConfigurationIsVisible = 0;
};
/ End XCConfigurationList section /
};
rootObject = E32D37A01AB426260019547B / Project object */;
}

highlightAuto won't terminate on line 47 of this file, which is:
runOnlyForDeploymentPostprocessing = 0;

You can run this script with node.js:
var h=require('highlight.js');

console.log('begin');
result = h.highlightAuto('runOnlyForDeploymentPostprocessing = 0;');
console.log('never come here');

console.log(result.value);

Could you try it with the current master code, not the latest released version. We fixed a couple of hanging bugs in the last iteration.

I'm working with highlight.js npm package, with version is 8.4.0. Maybe too old, it's published 4 months ago...

Yes, that's why I'm asking to check it with the new code. I can't reproduce it on my machine so it's probably fixed but I wanted to make sure it works for you too.

Cannot reproduce this with current master and v8.5.
I've added rendering time stats to developers tool (aa342e01f239163aad60d8f4d540b1ec6da6ad64), it takes about 500 ms on my PC.

authors: Sannis harttle isagalaev


text:
ImportError: numpy.core.multiarray failed to import

I am running into the following error whenever I try to execute the program ismrmrdviewer from the command line.
File "/home/user/miniconda3/envs/ismrmrdViewer/lib/python3.8/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 146, in _import ImportError: numpy.core.multiarray failed to import
I have installed ismrmrdviewer inside a conda virtual env with python 3.8.5
I have installed the requirement.txt dependencies and ran python3 setup.py install
Are there any particular python versions or particular versions of the dependencies that need to be installed in order for it to run correctly?

Apparently this issue comes up with early numpy versions, I solved it by installing numpy version 1.21.0

source: gharchive/issue

repo: ismrmrd/ismrmrdviewer

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 Cartama.isolucion.co is down

In ecf2e89, Cartama.isolucion.co (https://Cartama.isolucion.co) was down:

HTTP code: 500
Response time: 6784 ms

Resolved: Cartama.isolucion.co is back up in 00838cd.

repo: isolucionco/EstadoIsolucionHosting


text:
🛑 Grupoafin.isolucion.co is down

In 599e0e4, Grupoafin.isolucion.co (https://Grupoafin.isolucion.co) was down:

HTTP code: 503
Response time: 6522 ms

Resolved: Grupoafin.isolucion.co is back up in b137f80 after 14 minutes.


text:
🛑 dane.isolucion.co is down

In 989c186, dane.isolucion.co (https://dane.isolucion.co) was down:

HTTP code: 0
Response time: 0 ms

Resolved: dane.isolucion.co is back up in fca8363.


text:
Fix asset pipeline flags

This PR ensures that the flags sprite image goes through asset compilation and gets a fingerprinted filename.
Fixes #4

Does this create a dependency for the sass-rails gem?

I guess so. I'm trying to find what other similar gems define as dependencies, but they're inconsistent. X-editable-rails only specifies "railties", even though they use scss and its image-url helper.

I guess is that most gem authors just neglect to specify what they need in production. They usually get away with it, because stuff are already there and nobody notices; especially when very common dependencies are involved. Let's be explicit and specify our dependency here. I think something like spec.add_dependency "sass-rails" will suffice.

There you go

source: gharchive/pull-request

authors: ispyropoulos teoulas

repo: ispyropoulos/intl-tel-input-rails

license: mit

license_source: bigquery


text:
Add relatedImages to ClusterServiceVersion

We want to add relatedImages to the Sail Operator ClusterServiceVersion ( cf. #216 )

PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@bmangoen: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

scorecard_sail-operator_main
0b49b7d7a65c3f3442b0982b0df9e403fe4b3b81
link
true
/test scorecard

gencheck_sail-operator_main
0b49b7d7a65c3f3442b0982b0df9e403fe4b3b81
link
true
/test gencheck

unit-tests_sail-operator_main
0b49b7d7a65c3f3442b0982b0df9e403fe4b3b81
link
true
/test unit-tests

lint_sail-operator_main
0b49b7d7a65c3f3442b0982b0df9e403fe4b3b81
link
true
/test lint

e2e-kind_sail-operator_main
0b49b7d7a65c3f3442b0982b0df9e403fe4b3b81
link
true
/test e2e-kind

unit-tests-arm64_sail-operator_main
0b49b7d7a65c3f3442b0982b0df9e403fe4b3b81
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

I tried to run the script in our fork and it adds olm.relatedImage fields to already existing images fields which is not correct. I'm not sure what is the best solution but we need to make sure this change will not break downstream builds

maybe we can add an env var to control whether the related images are added? then we can disable it in the fork

@FilipB @dgn make -e GENERATE_RELATED_IMAGES=false gen should not generate the annotations olm.relatedImage.<version>.<component_name> and the relatedImages part

@FilipB @dgn make -e GENERATE_RELATED_IMAGES=false gen should not generate the annotations olm.relatedImage.<version>.<component_name> and the relatedImages part

The annotations should stay - but it looks to me like they will?

Added https://github.com/openshift-service-mesh/sail-operator/pull/112 to disable this in our fork.

authors: FilipB bmangoen dgn istio-testing

repo: istio-ecosystem/sail-operator


text:
DO NOT MERGE! Fast Forward stable to 48cc30b9d4b924c4fb9dcbd0345230b9721017c5.

This PR will be merged automatically once checks are successful.

Jenkins job auth/postsubmit passed

repo: istio/auth


text:
Fix int values when customizing metrics

Signed-off-by: Nupur Garg gargnupur@google.com
For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Ref: https://github.com/istio/istio/issues/23782#event-3330178812
Description: Fix int values when customizing metrics
Risk Level: Low
Testing: Verified with a test in istio/proxy
Docs Changes:
Release Notes:
[Optional Fixes #Issue]
[Optional Deprecated:]

Hi! I think this is probably going to break other uses of value serialization (e.g. reading attributes directly). I suggest we use string(int_value) expressions for now, until we have either type declarations passed as input or inferred.

@gargnupur: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

test-tsan_envoy
e18dbe549a88fdcefa7ac5e03949a4b75285c83f
link
/test test-tsan_envoy

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@gargnupur: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

test-tsan_envoy
e18dbe549a88fdcefa7ac5e03949a4b75285c83f
link
/test test-tsan_envoy

test-asan_envoy
e18dbe549a88fdcefa7ac5e03949a4b75285c83f
link
/test test-asan_envoy

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@gargnupur: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

test-tsan_envoy
e18dbe549a88fdcefa7ac5e03949a4b75285c83f
link
/test test-tsan_envoy

test-asan_envoy
e18dbe549a88fdcefa7ac5e03949a4b75285c83f
link
/test test-asan_envoy

test-release_envoy
e18dbe549a88fdcefa7ac5e03949a4b75285c83f
link
/test test-release_envoy

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@kyessenov , @mandarjog : agreed, just saw it is used at other places like getProperty.. so closing. this pr and trying to add. string(int_value) in expression itself

authors: gargnupur istio-testing kyessenov

repo: istio/envoy


text:
admin: add host priority and hostname to cluster response

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
[Optional Fixes #Issue]
[Optional Deprecated:]

/cc @duderino

CLA: cherrypick, CLA signed-off in original commits.

authors: crazyxy fpesce


text:
Update Telemetry Tasks

Updated Distributed Tracing Task with new screenshots

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: gargnupur
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: sdake
Assign the PR to them by writing /assign @sdake in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

content/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/cc @geeknoid @douglas-reid

/cc @andraxylia

/ok-to-test

Many linter errors need to be fixed in this PR before it can be merged.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: gargnupur
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: frankbu
Assign the PR to them by writing /assign @frankbu in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@geeknoid : Can you please take a look again.. fixed the linter errors

@douglas-reid Please give this a once over.

@gargnupur: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Circleci failure is about an external link not reachable..

The Ci failures are unrelated to this PR and have been fixed.

Ready to merge? There are several issues being opened about items resolved in this PR. It'd be nice to have this in.

@douglas-reid : Yes, circleci failures are not related to this PR but some external site not being reachable.

please merge to the latest, I fixed those errors with a PR yesterday. If you see similar, it means the links are broken and you need to update them.

@andraxylia : Merged to latest and these are the 4 new links failing now:
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/mongo https://archive.istio.io/v0.7/docs/reference/config/istio.routing.v1alpha1/ https://www.envoyproxy.io/docs/envoy/latest/api-v1/cluster_manager/sds https://docs.helm.sh/using_helm/
They are all valid links and looks like test server is not able to curl them

Those links are indeed valid. I rebuilt the circleci, if it keeps failing , you need an admin to look into this.

@andraxylia : Thanks, circleci is passing now!
@douglas-reid @geeknoid : Can you please review and approve PR ?

@mandarjog : Can you please help merge this PR?

/lgtm

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: andraxylia, gargnupur
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: frankbu
Assign the PR to them by writing /assign @frankbu in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Please lgtm:
@geeknoid
@linsun
@frankbu

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: andraxylia, gargnupur, geeknoid, sdake
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [geeknoid]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

authors: andraxylia douglas-reid gargnupur geeknoid istio-testing


text:
Translate /content/docs/tasks/security/https-overlay/index.md

Translate /content/docs/tasks/security/https-overlay/index.md
@fleeto

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: xieydd
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: rootsongjc
Assign the PR to them by writing /assign @rootsongjc in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

content_zh/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @xieydd. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@fleeto sleep-nginx需要保持原样吗？

authors: istio-testing xieydd


text:
TestMultipartEvents is flaky

https://circleci.com/gh/istio/istio/360223?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
     --- PASS: TestMultipartEvents/Add/event_2 (0.00s)
    --- FAIL: TestMultipartEvents/Delete (0.00s)
        testing_t_support.go:22:
            	/go/src/istio.io/istio/vendor/github.com/onsi/gomega/internal/assertion/assertion.go:69 +0x1ed
            istio.io/istio/vendor/github.com/onsi/gomega/internal/assertion.(*Assertion).To(0xc00040e840, 0x186a960, 0xc0004add30, 0x0, 0x0, 0x0, 0x187d920)
            	/go/src/istio.io/istio/vendor/github.com/onsi/gomega/internal/assertion/assertion.go:35 +0xaf
            istio.io/istio/galley/pkg/source/fs_test.TestMultipartEvents.func2(0xc00051a500)
            	/go/src/istio.io/istio/galley/pkg/source/fs/source_test.go:468 +0x36f
            testing.tRunner(0xc00051a500, 0xc00040e700)
            	/usr/local/go/src/testing/testing.go:827 +0xbf
            created by testing.(*T).Run
            	/usr/local/go/src/testing/testing.go:878 +0x353

            Expected
                <resource.Event>: {
                    Kind: 3,
                    Entry: {
                        Metadata: {
                            CreateTime: 0001-01-01T00:00:00Z,
                            Labels: nil,
                            Annotations: nil,
                        },
                        ID: {
                            Key: {
                                Collection: {
                                    string: "istio/config/v1alpha2/legacy/deniers",
                                },
                                FullName: {
                                    string: "some.mixer.denier",
                                },
                            },
                            Version: "v0",
                        },
                        Item: nil,
                    },
                }
            to equal
                <resource.Event>: {
                    Kind: 3,
                    Entry: {
                        Metadata: {
                            CreateTime: 0001-01-01T00:00:00Z,
                            Labels: nil,
                            Annotations: nil,
                        },
                        ID: {
                            Key: {
                                Collection: {
                                    string: "istio/policy/v1beta1/rules",
                                },
                                FullName: {
                                    string: "some.mixer.rule",
                                },
                            },
                            Version: "v0",
                        },
                        Item: nil,
                    },
                }

This no longer appears to be flakey on testgrid. Also not able to reproduce.  Closing for now.

authors: nmittler ozevren

repo: istio/istio


text:
Unable to Use mTLS with TCP Connections

Bug description
I am able to use mTLS for HTTP connections but not for TCP connections. I am using Kiali to observe whether mTLS is used or not. I am aware of the issue with Kiali not displaying the badge for mTLS on TCP but am using a recent version (1.2.13).

(the black squares on the connections are mTLS badges, they just turn into squares as you zoom out)
In the above screenshot, httpbin is HTTP and echo is TCP.
Expected behavior
TCP traffic uses mTLS.
Steps to reproduce the bug
The following is a basic configuration to reproduce the bug:
kind: Namespace
metadata:
  name: test
  labels:
    istio-injection: enabled
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
  namespace: test
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: test
  labels:
    app: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
  namespace: test
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  namespace: test
  labels:
    app: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
      - name: sleep
        #image: governmentpaas/curl-ssl
        image: markeijsermans/debug
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
---
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "httpbin-istio-client-mtls"
  namespace: test
spec:
  host: httpbin.test.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
---
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "echo-istio-client-mtls"
  namespace: test
spec:
  host: echo.test.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
---
apiVersion: v1
kind: Service
metadata:
  name: echo
  namespace: test
  labels:
    app: echo
spec:
  ports:
  - port: 2701
    name: tcp
  selector:
    app: echo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
      - name: echo
        image: cjimti/go-echo
        imagePullPolicy: IfNotPresent
        env:
        - name: TCP_PORT
          value: "2701"
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: echo
  namespace: test

To send some HTTP traffic use:
kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin: %{http_code}\n"

To send some TCP traffic, first install telnet on the pod:
kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- apt install telnet -y

Then send some data by running telnet on the pod:
kubectl exec -it $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- telnet echo 2701

Send some data and the pod should echo it back:
Trying 10.0.33.180...
Connected to echo.test.svc.cluster.local.
Escape character is '^]'.
hello
hello

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
istioctl version --remote:
client version: 1.4.3
citadel version: 1.4.3
egressgateway version: 1.3.4
galley version: 1.4.3
ingressgateway version: 1.4.3
pilot version: 1.4.3
policy version: 1.4.3
sidecar-injector version: 1.4.3
telemetry version: 1.4.3
data plane version: 1.4.3 (22 proxies), 1.3.4 (1 proxies)

kubectl version:
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:54Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.10", GitCommit:"37d169313237cb4ceb2cc4bef300f2ae3053c1a2", GitTreeState:"clean", BuildDate:"2019-08-19T10:44:49Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"

How was Istio installed?
Using Helm chart exported to template and then using kubectl apply.
Environment where bug was observed (cloud vendor, OS, etc)
Azure AKS

Trying to understand the issue, your report is the kiali does not show it as mtls, but nothing demonstrated the traffic is not encrypted right?
I mean if you do tcpdump on the destination pod, istio-proxy container, inbound port 15001 (? can't remember) are you seeing clear text?

Hi inclfy,
I seem unable to to run tcpdump in the istio-proxy container as you need root:
istio-proxy@echo-76788756f5-mc4fh:/$ tcpdump
tcpdump: eth0: You don't have permission to capture on that device
(socket: Operation not permitted)
istio-proxy@echo-76788756f5-mc4fh:/$
istio-proxy@echo-76788756f5-mc4fh:/$
istio-proxy@echo-76788756f5-mc4fh:/$ sudo tcpdump
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

I could run tcpdump in another container in the pod but by then the traffic would have been decrypted by the proxy by that point.
Apologies but I missed this out in the original issue: I'm leaning towards believing that the traffic is not encrypted as, in Prometheus, the search istio_tcp_sent_bytes_total{destination_app="echo"} only returns results with

connection_security_policy="none" or
connection_security_policy="unknown".

My (albiet limited) understanding is that it should return connection_security_policy="mtls".

https://istio.io/docs/tasks/security/authentication/mtls-migration/
provides a tcpdump verification, if you see encryption but not the metrics does not show that, trust tcpdump, and it should be a bug on our telemetry component.


text:
Tracing regression in 1.5.x - nested traces are intermittently incomplete

Bug description
We are having a problem where traces aren't coming through to Jaeger correctly, where the spans are complaining that the parentSpanId is missing.
This is only an issue on 1.5.1, using a 1.4.6 sidecar (with 1.5.1 control plane) this traces are always complete.  Therefore I believe this to be a 1.5 regression.
It'd be great if someone who more deeply understands istio/envoy/zipkin and the istio debug logs could help me wade through the information here to see what is up.  If you're struggling to reproduce i'm more than happy to remote share with you to debug this.
Example failure
As an example, we have a simple app setup of:
nginx -> istio-test-app-1 -> istio-test-app-2 ->istio-test-app-3
Which has been around since istio 1.0 days, to help us test these sorts of things, nothing has changed in them with regards to header forwarding logic.
As you can see in Jaeger the trace for 38e310d5619723f6 is messed up:

The istio-test-app-2 span is missing.
Another example here on trace 64f13d7f39b4a5f2:

In this case, the span for istio-test-app-1 is missing.
I have captured istio-proxy-debug logs for each of the test apps, which contain the requests mentioned above (as well as some other noise, sorry).
istio-test-app-1.log
istio-test-app-2.log
istio-test-app-3.log
Expected behavior
Traces to be complete
Steps to reproduce the bug
For us, it's using a 1.5.1 sidecar
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
1.5.1
How was Istio installed?
Helm
Environment where bug was observed (cloud vendor, OS, etc)

This needs to be fixed for 1.5.x releases as well.
@fpesce is it better to make this a 1.5 milestone or leave it as 1.6 ?

@douglas-reid if this is considered a regression, I think it would be better to fix it in 1.5.x.

@bianpengyuan can you investigate ?

@objectiser if you have any insights here, that'd also be appreciated.

I was able to reproduce this in my test environment. Looks like the drop is random. I need to dig more.

@douglas-reid Jaeger has various queues in its architecture where spans may be dropped if the component gets flooded by spans being reported - the collector being one of them. However, as @Stono pointed out, this only occurs when using a specific version of the proxy.
The other interesting point is that, rather than one span randomly going missing, which might happen occasionally - in both the example failures shown in the description, the 2 spans from the same service are missing.
So in the first failure - two spans (server and client) are missing for istio-test-app-2, whereas the second failure has two spans (server and client) for istio-test-app-1 missing.
Trace context is still being propagated successfully, so doesn't appear to be a problem with whether the trace is being sampled or not.

Hi,
Just to clarify a couple of things.  Istio test app 1,2 and 3 are the same code base and we’ve used them to test istio for almost a year.
In terms of load, this is on a testing cluster under no load, to an in memory jaeger collector.  The same behaviour manifests on all other clusters on 1.5.1 which back onto elasticsearch.
In terms of the correlation that it was the second span, that’s just coincidental I believe, as on other tests it’s spans at various levels that disappear.  I will share some other examples just to confirm when I’m back at my desk

@objectiser @bianpengyuan @douglas-reid i've tried to extract from the logs everything for trace 38e310d5619723f6, which from the information span 9fa88920d6b8778a was reporting a parent span of 70818c6c00118cea, which was missing.
However from the l
istio-test-app-1 (sidecar receiving request):
 - 'x-b3-spanid', 'ac7b27f7f9160c5e'
 - 'x-b3-parentspanid', 'e7008aa18fd4c5f6'

istio-test-app-1 (sidecar)-> istio-test-app-1 (app):
 - 'x-b3-spanid', '45749a1e06c2512d'
 - 'x-b3-parentspanid', 'ac7b27f7f9160c5e'

istio-test-app-1 (app) -> istio-test-app-1 (sidecar):
 - 'x-b3-spanid', '45749a1e06c2512d'
 - 'x-b3-parentspanid', 'ac7b27f7f9160c5e'

istio-test-app-1 (sidecar) -> istio-test-app-2 (sidecar):
 - 'x-b3-spanid', '9862709f56a411ae'
 - 'x-b3-parentspanid', '45749a1e06c2512d'

istio-test-app-2 (sidecar receiving request):
 - 'x-b3-spanid', '9862709f56a411ae'
 - 'x-b3-parentspanid', '45749a1e06c2512d'

istio-test-app-2 (sidecar) -> istio-test-app-2 (app):
 - 'x-b3-spanid', '6275ede08ea50c4a'
 - 'x-b3-parentspanid', '9862709f56a411ae'

istio-test-app-2 (app) -> istio-test-app2 (sidecar):
 - 'x-b3-spanid', '6275ede08ea50c4a'
 - 'x-b3-parentspanid', '9862709f56a411ae'

istio-test-app-2 (sidecar) -> istio-test-app-3 (sidecar):  <---- MISSING SPAN
 - 'x-b3-spanid', '70818c6c00118cea'
 - 'x-b3-parentspanid', '6275ede08ea50c4a'

istio-test-app-3 (sidecar receiving request):
 - 'x-b3-spanid', '70818c6c00118cea'
 - 'x-b3-parentspanid', '6275ede08ea50c4a'

istio-test-app-3 (sidecar) -> istio-test-app-3 (app):
 - 'x-b3-spanid', '9fa88920d6b8778a'
 - 'x-b3-parentspanid', '70818c6c00118cea'

So looking at the logs for istio-test-app-2, you can see the request from istio-test-app-2 -> istio-test-app-3 on line 178, at 18:50:25.302.   So I decided to follow down to where the Jaeger POST to report the spans happened and I saw this:
[Envoy (Epoch 0)] [2020-04-15 18:50:27.428][28][debug][router] [external/envoy/source/common/router/router.cc:614] [C0][S17259990231804564098] router decoding headers:
':method', 'POST'
':path', '/api/v2/spans'
':authority', 'zipkin'
':scheme', 'http'
'content-type', 'application/json'
'x-envoy-internal', 'true'
'x-forwarded-for', '10.206.8.124'
'x-envoy-expected-rq-timeout-ms', '5000'

[Envoy (Epoch 0)] [2020-04-15 18:50:27.428][28][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:104] [C15] using existing connection
[Envoy (Epoch 0)] [2020-04-15 18:50:27.428][28][debug][router] [external/envoy/source/common/router/router.cc:1711] [C0][S17259990231804564098] pool ready
[Envoy (Epoch 0)] [2020-04-15 18:50:27.429][28][debug][router] [external/envoy/source/common/router/router.cc:1115] [C0][S17259990231804564098] upstream headers complete: end_stream=false
[Envoy (Epoch 0)] [2020-04-15 18:50:27.429][28][debug][http] [external/envoy/source/common/http/async_client_impl.cc:95] async http request response headers (end_stream=false):
':status', '400'
'content-type', 'text/plain; charset=utf-8'
'vary', 'Origin'
'x-content-type-options', 'nosniff'
'date', 'Wed, 15 Apr 2020 18:50:27 GMT'
'content-length', '133'
'x-envoy-upstream-service-time', '0'

[Envoy (Epoch 0)] [2020-04-15 18:50:27.429][28][debug][client] [external/envoy/source/common/http/codec_client.cc:104] [C15] response complete
[Envoy (Epoch 0)] [2020-04-15 18:50:27.429][28][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:201] [C15] response complete
[Envoy (Epoch 0)] [2020-04-15 18:50:27.429][28][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:239] [C15] moving to ready

Note the 400 BAD REQUEST with a upstream-service-time of 0?  Feels like for whatever reason envoy rejected this request with a 400.
Looking through the logs further, we occasionally see these 400's after a POST to jaeger and it marries up with traces that are missing spans.

So i then followed this through to the jaeger collector and TCP dumped out the incoming requests and was able to see the 400s:
09:42:04.259148 IP 10.206.8.127.39940 > istio-tracing-5845b6fbd4-7br5j.9411: Flags [P.], seq 4163815308:4163820027, ack 504468475, win 333, options [nop,nop,TS val 2061904836 ecr 175011169], length 4719
E.....@.?.(=
...
..u..$............M9%.....
z.+.
nuaPOST /api/v2/spans HTTP/1.1
host: zipkin
content-type: application/json
x-envoy-internal: true
x-forwarded-for: 10.206.8.127
x-envoy-expected-rq-timeout-ms: 5000
transfer-encoding: chunked

119c
[{"traceId":"c71df96d08ec50ef","name":"app.istio-test-app-2.svc.cluster.local:80/*","timestamp":1.58703012360987e+15,"duration":7912,"kind":"CLIENT","localEndpoint":{"port":0,"serviceName":"istio-test-app-1","ipv4":"10.206.8.127"},"id":"aa29007755b8cbac","tags":{"upstream_cluster":"outbound|80||app.istio-test-app-2.svc.cluster.local","guid:x-request-id":"6ce4516f-0da3-48b4-8b24-17e2a54da720","http.protocol":"HTTP/1.1","component":"proxy","http.url":"http://app.istio-test-app-2/downstream?servers=app.istio-test-app-3/instant","user_agent":"-","downstream_cluster":"-","request_size":"0","response_flags":"-","response_size":"428","node_id":"sidecar~10.206.8.127~istio-test-app-1-cd9cd559d-m9hql.istio-test-app-1~istio-test-app-1.svc.cluster.local","http.status_code":"200","http.method":"GET"},"parentId":"6c2b3d8c42f24f05"},{"id":"6c2b3d8c42f24f05","tags":{"response_size":"633","node_id":"sidecar~10.206.8.127~istio-test-app-1-cd9cd559d-m9hql.istio-test-app-1~istio-test-app-1.svc.cluster.local","http.status_code":"200","http.method":"GET","upstream_cluster":"inbound|80|http-web|app.istio-test-app-1.svc.cluster.local","guid:x-request-id":"6ce4516f-0da3-48b4-8b24-17e2a54da720","http.protocol":"HTTP/2","component":"proxy","http.url":"https://app.istio-test-app-1.testing.k8.atcloud.io/downstream?servers=app.istio-test-app-2/downstream?servers=app.istio-test-app-3/instant","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36","downstream_cluster":"-","response_flags":"-","request_size":"0"},"parentId":"0b45ec791cb2b9d9","traceId":"c71df96d08ec50ef","name":"app.istio-test-app-1.svc.cluster.local:80/*","timestamp":1587030123608213,"duration":11523,"kind":"CLIENT","localEndpoint":{"port":0,"serviceName":"istio-test-app-1","ipv4":"10.206.8.127"}},{"duration":8036,"kind":"CLIENT","localEndpoint":{"port":0,"serviceName":"istio-test-app-1","ipv4":"10.206.8.127"},"id":"2271a862646ef79b","tags":{"downstream_cluster":"-","user_agent":"-","response_flags":"-","request_size":"0","response_size":"428","node_id":"sidecar~10.206.8.127~istio-test-app-1-cd9cd559d-m9hql.istio-test-app-1~istio-test-app-1.svc.cluster.local","http.status_code":"200","http.method":"GET","upstream_cluster":"outbound|80||app.istio-test-app-2.svc.cluster.local","guid:x-request-id":"9c0c4bbc-777b-4414-a36b-e2ff6a0aa30b","http.protocol":"HTTP/1.1","component":"proxy","http.url":"http://app.istio-test-app-2/downstream?servers=app.istio-test-app-3/instant"},"parentId":"514b42930dfd5f51","traceId":"b10d0bc09ddd3574","name":"app.istio-test-app-2.svc.cluster.local:80/*","timestamp":1587030124065573},{"traceId":"b10d0bc09ddd3574","name":"app.istio-test-app-1.svc.cluster.local:80/*","timestamp":1587030124063938,"duration":11654,"kind":"CLIENT","localEndpoint":{"port":0,"serviceName":"istio-test-app-1","ipv4":"10.206.8.127"},"id":"514b42930dfd5f51","tags":{"http.url":"https://app.istio-test-app-1.testing.k8.atcloud.io/downstream?servers=app.istio-test-app-2/downstream?servers=app.istio-test-app-3/instant","downstream_cluster":"-","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36","response_flags":"-","request_size":"0","response_size":"633","node_id":"sidecar~10.206.8.127~istio-test-app-1-cd9cd559d-m9hql.istio-test-app-1~istio-test-app-1.svc.cluster.local","http.status_code":"200","http.method":"GET","upstream_cluster":"inbound|80|http-web|app.istio-test-app-1.svc.cluster.local","guid:x-request-id":"9c0c4bbc-777b-4414-a36b-e2ff6a0aa30b","http.protocol":"HTTP/2","component":"proxy"},"parentId":"a663b2da260c5333"},{"localEndpoint":{"port":0,"serviceName":"istio-test-app-1","ipv4":"10.206.8.127"},"id":"ea393e07f90061e6","tags":{"http.method":"GET","upstream_cluster":"outbound|80||app.istio-test-app-2.svc.cluster.local","guid:x-request-id":"45501d11-f9cc-442f-b7b7-8e2822de8469","http.protocol":"HTTP/1.1","component":"proxy","http.url":"http://app.istio-test-app-2/downstream?servers=app.istio-test-app-3/instant","downstream_cluster":"-","user_agent":"-","request_size":"0","response_flags":"-","response_size":"428","node_id":"sidecar~10.206.8.127~istio-test-app-1-cd9cd559d-m9hql.istio-test-app-1~istio-test-app-1.svc.cluster.local","http.status_code":"200"},"parentId":"334d87d8578e0e3e","traceId":"dac5d6d050bbf254","name":"app.istio-test-app-2.svc.cluster.local:80/*","timestamp":1587030124251379,"duration":7252,"kind":"CLIENT"}]
0

09:42:04.259428 IP istio-tracing-5845b6fbd4-7br5j.9411 > 10.206.8.127.39940: Flags [P.], seq 1:308, ack 4719, win 331, options [nop,nop,TS val 175039204 ecr 2061904836], length 307
E..g..@.@.).
..u
...$..............K'......

n..z.+.HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
Vary: Origin
X-Content-Type-Options: nosniff
Date: Thu, 16 Apr 2020 09:42:04 GMT
Content-Length: 133

Unable to process request body: json: cannot unmarshal number 1.58703012360987e+15 into Go struct field Span.timestamp of type int64

I think this is the relevant issue. It relates to a couple of changes made to the zipkin v2 timestamp field, and it refers to a comment about the format: https://github.com/openzipkin/zipkin-go/pull/161#issuecomment-598558072
So potentially need to upgrade to latest envoy commit.

great sleuthing @Stono .
Does this mean every request should fail ? With HTTP_JSON endpoint,  every timestamp should be scientific notation, or does it change from number to scientific dynamically ?

Summarizing offline conversations, etc.: In the linked issue, it looks like others were reporting the it sometimes uses scientific notation. A patch was just merged and we need to verify and then cherry-pick to the impacted releases.

1.5 cherry-pick PR: https://github.com/istio/envoy/pull/194

Summarizing offline conversations, etc.: In the linked issue, it looks like others were reporting that it sometimes uses scientific notation. A patch was just merged and we need to verify and then cherry-pick to the impacted releases.

@douglas-reid I'm confused as to why this will cause intermittent failures?

@bianpengyuan the cherry-pick is only on master, not 1.5

@mandarjog not sure I follow. This needs to be fix on 1.5 right? the linked pr is to cherry-pick fix into istio/envoy release-1.5.
@nrjpoddar It is random behavior from protobuf struct -> json serialization with large integer.

Summarizing offline conversations, etc.: In the linked issue, it looks like others were reporting that it sometimes uses scientific notation. A patch was just merged and we need to verify and then cherry-pick to the impacted releases.

@douglas-reid I'm confused as to why this will cause intermittent failures?

@nrjpoddar i haven't looked closely at the patch so I don't know the underlying cause, but https://github.com/envoyproxy/envoy/issues/9341#issuecomment-577051483 shows that others have observed intermittent failures.

Sorry to be that naggy person but this is causing us quite a few ops issues.  When do you anticipate being able to cut a 1.5.2 with the fix?
I ask because if it’s far away I’m going to have to look at rolling back everywhere to 1.4.6
Cheers for your help!

This has been cherry-picked into 1.5 and will be released with 1.5.2. I've verified the fix in my test env. @Stono Please try out gcr.io/istio-testing/proxyv2:1.5-alpha.287e52ea3c53f7a15853db550edef4dbe243b4ca in your env when you have a chance, thanks!

@fpesce ^^ about 1.5.2 eta.

ETA for 1.5.2 is realistically Wednesday, we are fixing https://github.com/istio/istio/issues/23038 right now, I'll probably trigger the build when https://github.com/istio/istio/pull/23037 is tested and merged

Thank you for the update both.  I’ll test that image shortly

@fpesce @bianpengyuan I've tested the above image on the deployment setup I used to replicate this issue and can confirm the issue is resolved.
This deployment has constant load at it and is also patch restarted every 5-10 minutes to generate churn so i'll leave it there for a good few days and let you know if I spot anything untoward.
Ta

@bianpengyuan and just to be clear, that envoy patch is definitely included in 1.6 moving forward ?

@douglas-reid with https://github.com/istio/envoy/pull/196 it should be.

This should be fixed in 1.6. I will use this issue to track how to make the test more strict in order to catch a random bug like this.

Close in favor of https://github.com/istio/istio/issues/23260

Bad news, looks like this is still broken.
Please can we reopen it @bianpengyuan @douglas-reid @fpesce and i'll try and debug more tomorrow

Is it still broken with 1.5.2?

Seems so yes :-(

Ok thanks! I will also try out 1.6 installation and see if I can reproduce.

How often does it happen in your env? I cannot find any occurrence of this bug in my cluster installed head. If I remembered correctly it happened quite often before the fix. So not sure if it is just a transient error that you caught.

No unfortunately I have a lot of examples.  It's quite late here so I'll collect more information for you tomorrow.

08:11:16.180772 IP 10.194.46.22.47740 > istio-tracing-54f89c8554-ldvkv.9411: Flags [P.], seq 38021791:38026659, ack 73850609, win 4416, options [nop,nop,TS val 1276055718 ecr 244643951], length 4868
E..8..@.>...
...
.'..|$..D*..f.....@~x.....
L......oPOST /api/v2/spans HTTP/1.1
host: zipkin
content-type: application/json
x-envoy-internal: true
x-forwarded-for: 10.194.46.22
x-envoy-expected-rq-timeout-ms: 5000
transfer-encoding: chunked

1231
[{"localEndpoint":{"port":0,"serviceName":"ingress-nginx-external","ipv4":"10.194.46.22"},"id":"90baa147bf5ed88a","tags":{"http.status_code":"200","http.method":"GET","upstream_cluster":"outbound|80||app.consumer-gateway.svc.cluster.local","guid:x-request-id":"58c807e0dbabe597-MAN","http.protocol":"HTTP/1.1","component":"proxy","http.url":"https://www.autotrader.co.uk/json/finance-calculator?useDefault=true&advertId=202004309122948&selectedDid=21342&includePartEx=true&channel=cars","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36","downstream_cluster":"-","request_size":"0","response_flags":"-","response_size":"1351","node_id":"sidecar~10.194.46.22~ingress-nginx-external-controller-6758c68b6f-ccjzm.ingress-nginx~ingress-nginx.svc.cluster.local"},"parentId":"4a9ad30d09410d00","traceId":"0d645df36d72d419","name":"app.consumer-gateway.svc.cluster.local:80/*","timestamp":1.58832067599851e+15,"duration":143176,"kind":"CLIENT"},{"localEndpoint":{"port":0,"serviceName":"ingress-nginx-external","ipv4":"10.194.46.22"},"id":"91a4b9d86579e01c","tags":{"component":"proxy","http.url":"https://www.autotrader.co.uk/","downstream_cluster":"-","user_agent":"Mozilla/5.0 (iPhone; CPU iPhone OS 13_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Mobile/15E148 Safari/604.1","response_flags":"-","request_size":"0","response_size":"47157","node_id":"sidecar~10.194.46.22~ingress-nginx-external-controller-6758c68b6f-ccjzm.ingress-nginx~ingress-nginx.svc.cluster.local","http.status_code":"200","http.method":"GET","upstream_cluster":"outbound|80||app.consumer-gateway.svc.cluster.local","guid:x-request-id":"58c807e17f61ce1f-LHR","http.protocol":"HTTP/1.1"},"parentId":"cfefa6fc30ac0959","traceId":"14d19010d8cf9c61","name":"app.consumer-gateway.svc.cluster.local:80/*","timestamp":1588320676096608,"duration":45625,"kind":"CLIENT"},{"id":"462cb9066426f1c7","tags":{"http.status_code":"204","http.method":"POST","upstream_cluster":"outbound|80||app.consumer-gateway.svc.cluster.local","guid:x-request-id":"58c807e1d9e60686-LHR","http.protocol":"HTTP/1.1","component":"proxy","http.url":"https://www.autotrader.co.uk/json/js-log/error","downstream_cluster":"-","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362","response_flags":"-","request_size":"35","response_size":"0","node_id":"sidecar~10.194.46.22~ingress-nginx-external-controller-6758c68b6f-ccjzm.ingress-nginx~ingress-nginx.svc.cluster.local"},"parentId":"8d2b9c59742c31c6","traceId":"b769794e36f7a05c","name":"app.consumer-gateway.svc.cluster.local:80/*","timestamp":1588320676152718,"duration":5986,"kind":"CLIENT","localEndpoint":{"port":0,"serviceName":"ingress-nginx-external","ipv4":"10.194.46.22"}},{"tags":{"http.status_code":"204","http.method":"POST","upstream_cluster":"outbound|80||app.consumer-gateway.svc.cluster.local","guid:x-request-id":"58c807e1ed67d210-MAN","http.protocol":"HTTP/1.1","component":"proxy","http.url":"https://www.autotrader.co.uk/json/js-log/error","downstream_cluster":"-","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18363","response_flags":"-","request_size":"35","response_size":"0","node_id":"sidecar~10.194.46.22~ingress-nginx-external-controller-6758c68b6f-ccjzm.ingress-nginx~ingress-nginx.svc.cluster.local"},"parentId":"20a6a93d1f52ec6c","traceId":"6d16137acf04708a","name":"app.consumer-gateway.svc.cluster.local:80/*","timestamp":1588320676165394,"duration":4196,"kind":"CLIENT","localEndpoint":{"port":0,"serviceName":"ingress-nginx-external","ipv4":"10.194.46.22"},"id":"e6a586c45cef35f7"},{"tags":{"downstream_cluster":"-","user_agent":"swcd (unknown version) CFNetwork/1125.2 Darwin/19.4.0","response_flags":"-","request_size":"0","response_size":"0","node_id":"sidecar~10.194.46.22~ingress-nginx-external-controller-6758c68b6f-ccjzm.ingress-nginx~ingress-nginx.svc.cluster.local","http.status_code":"301","http.method":"GET","upstream_cluster":"outbound|80||app.consumer-gateway.svc.cluster.local","guid:x-request-id":"58c807e1ea780070-LHR","http.protocol":"HTTP/1.1","component":"proxy","http.url":"https://autotrader.co.uk/.well-known/apple-app-site-association"},"parentId":"4caa0bdd26697db3","traceId":"d174821f86615120","name":"app.consumer-gateway.svc.cluster.local:80/*","timestamp":1588320676162625,"duration":17704,"kind":"CLIENT","localEndpoint":{"port":0,"serviceName":"ingress-nginx-external","ipv4":"10.194.46.22"},"id":"580389b9404e3ee7"}]
0

08:11:16.181063 IP istio-tracing-54f89c8554-ldvkv.9411 > 10.194.46.22.47740: Flags [P.], seq 1:308, ack 4868, win 331, options [nop,nop,TS val 244644002 ecr 1276055718], length 307
E..g..@.@...
.'.
...$..|.f...D=....Kl......
....L...HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
Vary: Origin
X-Content-Type-Options: nosniff
Date: Fri, 01 May 2020 08:11:16 GMT
Content-Length: 133

The source pod:
❯ k get pods --all-namespaces -o wide| grep 10.194.46.22
ingress-nginx                              ingress-nginx-external-controller-6758c68b6f-ccjzm                                            2/2     Running             0          22d     10.194.46.22    gke-delivery-platform-core-20191114-af4e6139-61hg     <none>           1/1

Which is actually on 1.5.1!  Some how, it's been missed during our sidecar rollout...
2020-04-08T17:58:10.931836Z	info	Version 1.5.1-9d07e185b0dd50e6fb1418caa4b4d879788807e3-Clean
2020-04-08T17:58:10.931956Z	info	Obtained private IP [10.194.46.22]
2020-04-08T17:58:10.931989Z	info	Proxy role: &model.Proxy{ClusterID:"", Type:"sidecar", IPAddresses:[]string{"10.194.46.22", "10.194.46.22"}, ID:"ingress-nginx-external-controller-6758c68b6f-ccjzm.ingress-nginx", Locality:(*envoy_api_v2_core.Locality)(nil), DNSDomain:"ingress-nginx.svc.cluster.local", ConfigNamespace:"", Metadata:(*model.NodeMetadata)(nil), SidecarScope:(*model.SidecarScope)(nil), MergedGateway:(*model.MergedGateway)(nil), ServiceInstances:[]*model.ServiceInstance(nil), WorkloadLabels:labels.Collection(nil), IstioVersion:(*model.IstioVersion)(nil)}

Sorry for the false positive guys!

I'm still facing this issue on istio 1.5.2, using opentelemetry library 0.7.0, and nodejs 8.9.4

@romil-punetha Please check and make sure all of your proxies are updated to 1.5.2.

I checked. Both the services and the gateway from the above image are using envoy:1.5.2

I've tried to reproduce this with 1.5.2 but did not see this anymore. Could you use @Stono's TCP dump command https://github.com/istio/istio/issues/22968#issuecomment-614537948 and see if you can capture any 400s? Then it would be nice to check that the proxy sending the trace is also 1.5.2.

@bianpengyuan This is currently marked as a release blocker on the spreadsheet. If it's no longer a release blocker please either change the priority or mark it as closed.

@brian-avery I believe this is a release blocker, and it is currently marked closed. However, I think we are trying to determine if it should in fact be considered closed, or if more work is needed.

I was not able to reproduce this with either 1.6.0-beta.0 or 1.5.2. I tend to treat this as fixed and not blocking, unless there are evidences show otherwise.

@bianpengyuan I was able to fix this by configuring the Jaeger propagator in Opentelemetry library to use jaeger-agent.istio-system:6832 as the backend.

authors: Stono bianpengyuan brian-avery douglas-reid fpesce mandarjog nrjpoddar objectiser romil-punetha


text:
istio ingressgateway access.log didn't log anything for bad request

Hi Team,
I found one kind of issue that istio ingressgateway won't log anything in access.log for bad request, e.g. there is illeagl characters in header name.
I tried to increase the log level to Debug or trace but no luck.
anything else i can do?
Istio version: 1.5.0

Can you try on newer version? We have improved the access logs for exactly this behavior and 1.5 is not supported: https://istio.io/latest/news/support/announcing-1.6-eol/
Additionally, if you could provider the request you are sending to trigger this it would help. thanks.

Thanks i will test it with latest version.
to reproduce it, you just need to add some illegal character in the header name like Chinease.

curl ingress/productpage -H "Host: 文"
[2021-02-03T20:14:37.105Z] "- - HTTP/1.1" 400 DPE "-" 0 11 0 - "-" "-" "-" "-" "-" - - 10.36.1.146:8080 10.36.1.1:51981 -

Seems to log for me. Ithink DPE log is new, so maybe its fixed now

you're right. i'm able to see the log now after upgrading version to 1.8


text:
Locality weighted distribution does not work with outlier detection

Hi
I have configured locality weighted distribution and it works fine based on the percentage distribution. When there is a failure, I do not see the traffic is getting sent to the other region. It seems like outlier detection is not working with locality weighted distribution. I see regular locality based failover working without weighted distribution.
Following is a sample destination rule I used:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: eu-frontend-weight
spec:
host: whereami-frontend.frontend.svc.cluster.local
trafficPolicy:
loadBalancer:
localityLbSetting:
enabled: true
distribute:
- from: "*"
to:
"us-central1": 100
outlierDetection:
consecutive5xxErrors: 3
interval: 5s
baseEjectionTime: 5s
Thanks
Sreenivas

Isn't it expected? The setting means all traffic from any region goes to us-central1.

In the default scenario where there is no failure in us-central1, its expected that all traffic go to us-central1. When there is a failure in us-central1, I am expecting the traffic to failover to other region. Isn't that the reason that we are specifying outlier detection?

Distribution is used to satisfy cases when the source and servers are not evenly scheduled. You should specify locality failover in this case.

I needed a usecase like this:
Have 1 service as Active and another as Standby and when Active fails, I wanted Standby to takeover. Is there a way to achieve this?
I was thinking to use weighted distribution with failover, but the failover part does not seem to be working. Maybe, this is not the right usecase for this.

Locality failover should work well for this.

This is what I tried with Locality failover:
External -> Load balancer -> Istio ingress(region US) -> service
-> Istio ingress(region EU) -> service
With locality based load balancing:
When traffic comes from external world to US region, traffic stays within US.
When traffic comes from external world to EU region, traffic stays within EU.
When traffic comes from EU, traffic does not get routed to US which is what I want in A/S configuration where all traffic has to go to primary site and then get switched over only when there is a failure.
I was hoping that having weighted distribution with outlier detection based failover can solve my usecase. But outlier detection does not seem to work with weighted distribution.

authors: hzxuzhonghu smakam


text:
Istio GW has istio_mutual and i get authentication_denied

Hello
I am using istio version 1.9.16
I have a GW as follows
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: shared-istio-gateway
  namespace: mysps
  resourceVersion: "28916480"
  uid: 42f4b8de-5cf0-486b-a7d1-713f5264cab6
spec:
  selector:
    app: arunsps
  servers:
  - hosts:
    - '*'
    port:
      name: http-80
      number: 80
      protocol: HTTP
  - hosts:
    - '*'
    port:
      name: https-443
      number: 443
      protocol: HTTPS
    tls:
      mode: ISTIO_MUTUAL

When i a curl request with my client certs
curl --cacert ./cacert.pem --cert ./client.crt --key ./client.key -vk https://site1-samson.dyn.nesc.nokia.net/soap/monitoring
I do see this error in istio ingress logs and i get a 401.
[2021-09-15T14:27:09.556Z] "GET /soap/monitoring HTTP/1.1" 401 - istio_authn_access_denied - "-" 0 27 0 - "10.139.155.152" "curl/7.29.0" "870c9a99-31ab-9880-b867-2b9ab3344cfa" "site1-samson.dyn.nesc.nokia.net" "-" - - 172.18.162.164:443 10.139.155.152:33910 site1-samson.dyn.nesc.nokia.net -
Am i missing anything here ?
I do not have any authorization policies at all in the system.

Do you have any RequestAuthentication set up in your cluster?

No
kubectl get requestauthentication -A
No resources found

You should not use ISTIO_MUTUAL in gateway, if you want to terninate tls in gateway. Please refer: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#configure-a-mutual-tls-ingress-gateway

Thanks for your answer. So ISTIO_MUTUAL only meant for istio components to talk to each other.. If i need a non ISTIO component to talk then should i be using MUTUAL only ? Is that what you mean ?

Yes, never use ISTIO_MUTUAL  if one peer is mesh external

Thank you.

authors: arunpmohan bianpengyuan hzxuzhonghu


text:
Support failover cluster in DestinationRule

This is related with https://github.com/istio/istio/issues/38105 for the failover feature.
Currently we only support locality based failover but we would like to extend this feature to support failover to a specified cluster for a given route. This is very helpful if the destination upstream cluster is down and we can failover to a default service, for example the homepage service.
Since VirtualService is not the right place, I would re-propose DestinationRule.
Option 1:Add defaultService in the failover field.
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: helloworld
spec:
  host: helloworld.sample.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      localityLbSetting:
        enabled: true
        failover:
          - defaultService: homepage.sample.svc.cluster.local

Option 2: Using Envoy Aggregate Cluster with a large enough overprovisioning_factor value can archive the fallback effect.
Looks like defining the failover destination in DestinationRule's LoadBalancerSettings could be a better choice:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: helloworld
spec:
  host: helloworld.sample.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      failover:
        failoverFactor: 5 # when healthy endpoint lower than this percentage, start to failover;
                          # this is used to calculate Aggregate Cluster's primary cluster's overprovisioning_factor
        destination:
          host: homepage.sample.svc.cluster.local
          subset: v2
          port:
            number: 8080

When failover is defined, the outbound cluster can be generated as an Envoy Aggregate Cluster, with native destination as primary cluster, and the failover destination as Secondary cluster.
Actually both options leverage the envoy priority level but implemented through different spec.
[ ] Docs
[ ] Installation
[ x] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

@howardjohn  any comment?

@howardjohn  @hzxuzhonghu  We plan to implement this function in Istio to support failover to a specified cluster. It makes sense to specify the failover cluster in the DestinationRule but would result to api change. Another option is that we can add two annotations in DestinationRule to avoid the api change:
    traffic.istio.io/defaultCluster: "homepage-svc"
    traffic.istio.io/failoverFactor: "5" # when healthy endpoint lower than this percentage, start to failover;

Failover with conditions/context  may also need to be considered, such as:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-app
  namespace: default
spec:
  hosts:
    - example
  http:
  - match:
    - uri:
       prefix: /a
    route:
    - destination:
         host: example
         subset: v2
      fallback:
         target:
           host: example
           subset: base
  - route:
    - destination:
        host: example
        subset: v2
      fallback:
        case: noinstances|noavailabled
        target:
          host: example
          subset: v1

@zengyuxing007 If fallback and route are bound together, which configuration in envoy is used to achieve this capability? We recently encountered a similar requirement in our environment and would like to understand how to implement it.

authors: fatedier shonecyx zengyuxing007


text:
Lack of support for globs with file extension in AuthPolicy

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
I expected path template /videos/{*}.m4s to work in paths field in AuthorizationPolicy.
Instead I got an error:
failde to parse CRD: configuration is invalid: invalid policy httpbin-1.foo: invalid or unsupported path videos/{*}.m4s, found in Paths. Contains '{' or '}' beyond a supported path template

Version
1.24.1
Tested it on current master version by modifying tests, after reading documentation and seeing discrepancy with Envoy docs.

Additional Information
Path templating support was added in https://github.com/istio/istio/pull/50365.
I don't see anywhere in the discussion a mention of supporting globs with file extension, which is supported by Envoy:
/videos/*/*/*.m4s would match videos/123414/hls/1080p5000_00001.m4s

Is there any reason for this?

I believe the current implement is only allow globing of path segments (foo/{*}/bar) not a part of a path segment
cc @jaellio

Yes, in Envoy it works almost the same, with only difference being if it's the last path segment - in that case you can match glob with file extension.
Example configuration of envoy:
static_resources:

  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                access_log:
                  - name: envoy.access_loggers.stdout
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
                http_filters:
                  - name: rbac
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
                      rules:
                        action: ALLOW
                        policies:
                          foo:
                            permissions:
                              - uri_template:
                                  name: envoy.path.match.uri_template.uri_template_matcher
                                  typed_config:
                                    "@type": type.googleapis.com/envoy.extensions.path.match.uri_template.v3.UriTemplateMatchConfig
                                    path_template: "/extension/*.js"
                            principals:
                              - any: true
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            host_rewrite_literal: www.envoyproxy.io
                            cluster: service_envoyproxy_io

  clusters:
    - name: service_envoyproxy_io
      type: LOGICAL_DNS
      # Comment out the following line to test on v6 networks
      dns_lookup_family: V4_ONLY
      load_assignment:
        cluster_name: service_envoyproxy_io
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: www.envoyproxy.io
                      port_value: 443
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
          sni: www.envoyproxy.io

In this case, path_template: "/extension/*.js" will match /extension/file.js, but not /extension/file.
My question is: was it a conscious decision and in Istio it's not supposed to work? Are you against it or is it ok to implement?

authors: howardjohn kozjan


text:
Case-insensitive DNS names

We notice that DNS validation in Pilot's model validation is using a regex which does not support uppercase dns entries. There is a newer RFC 4343 which states that the DNS names are case insensitive. Also in kubernete's DNS validation this change has already taken place.
Is this a potential change that we could PR?

@rshriram

Shouldn’t make a difference in current code. Go for it

Fixed by #5528

authors: Nino-K rshriram shalako ymesika


text:
istioctl kube-inject 0.2.0 references images which do not exist

    image: docker.io/istio/proxy_debug:0.2.0
    image: docker.io/istio/proxy_init:0.2.0

can we push those images asap (or make a 0.2.1 with working images/kube-inject) ?
(I guess it's somewhat related to, but not a dup of (imo) #538 but somewhat more acute as it's not working at the moment)

Done created those 2.

thanks a lot ! super fast fix !

Can you also create https://hub.docker.com/r/istio/proxy/tags/ 0.2.0?

@mclarke47 curious, why ? (only proxy_init and proxy_debug are referenced as far as I can tell)

It's just the non debug version of the debug proxy image I think

Pushed  docker.io/istio/proxy:0.2.0

authors: ldemailly mclarke47 sebastienvas


text:
Telemetry: An error has occurred during metrics gathering: label dimensions inconsistent with previously collected metrics in the same metric family

Describe the bug
Istio Telemetry starts to fail on /metrics endpoint for prometheus metrics
Expected behavior
Consistent labels should exist
Steps to reproduce the bug
Install istio in a system that emits metrics and wait I guess?
Version
Kubernets 1.9 + Istio 1.0
Installation
Helm installation with slight modification
Environment
AWS w/ Kube-AWS
Cluster state
The amount of data the tool exposes about our cluster is unacceptable for me to post here.
Full error:
An error has occurred during metrics gathering:

2 error(s) occurred:
* collected metric istio_request_bytes label:<name:"connection_security_policy" value:"unknown" > label:<name:"destination_app" value:"permissions" > label:<name:"destination_principal" value:"unknown" > label:<name:"destination_service" value:"permissions-public.applications.svc.cluster.local" > label:<name:"destination_service_name" value:"permissions-public" > label:<name:"destination_service_namespace" value:"applications" > label:<name:"destination_version" value:"8" > label:<name:"destination_version" value:"8" > label:<name:"destination_workload" value:"permissions-grpc-v008" > label:<name:"reporter" value:"source" > label:<name:"request_protocol" value:"grpc" > label:<name:"response_code" value:"200" > label:<name:"source_app" value:"benefits" > label:<name:"source_principal" value:"unknown" > label:<name:"source_version" value:"unknown" > label:<name:"source_workload" value:"benefits-grpc" > label:<name:"source_workload_namespace" value:"applications" > histogram:<sample_count:105 sample_sum:4515 bucket:<cumulative_count:0 upper_bound:1 > bucket:<cumulative_count:0 upper_bound:10 > bucket:<cumulative_count:105 upper_bound:100 > bucket:<cumulative_count:105 upper_bound:1000 > bucket:<cumulative_count:105 upper_bound:10000 > bucket:<cumulative_count:105 upper_bound:100000 > bucket:<cumulative_count:105 upper_bound:1e+06 > bucket:<cumulative_count:105 upper_bound:1e+07 > bucket:<cumulative_count:105 upper_bound:1e+08 > >  has label dimensions inconsistent with previously collected metrics in the same metric family
* collected metric istio_request_bytes label:<name:"connection_security_policy" value:"unknown" > label:<name:"destination_principal" value:"unknown" > label:<name:"destination_service" value:"sessions-grpc-gateway.applications.svc.cluster.local" > label:<name:"destination_service_name" value:"sessions-grpc-gateway" > label:<name:"destination_service_namespace" value:"applications" > label:<name:"destination_version" value:"unknown" > label:<name:"destination_version" value:"unknown" > label:<name:"destination_workload" value:"sessions" > label:<name:"destination_workload_namespace" value:"applications" > label:<name:"reporter" value:"source" > label:<name:"request_protocol" value:"http" > label:<name:"response_code" value:"200" > label:<name:"source_app" value:"unknown" > label:<name:"source_principal" value:"unknown" > label:<name:"source_version" value:"unknown" > label:<name:"source_workload" value:"sessions" > label:<name:"source_workload_namespace" value:"applications" > histogram:<sample_count:29 sample_sum:275 bucket:<cumulative_count:28 upper_bound:1 > bucket:<cumulative_count:28 upper_bound:10 > bucket:<cumulative_count:28 upper_bound:100 > bucket:<cumulative_count:29 upper_bound:1000 > bucket:<cumulative_count:29 upper_bound:10000 > bucket:<cumulative_count:29 upper_bound:100000 > bucket:<cumulative_count:29 upper_bound:1e+06 > bucket:<cumulative_count:29 upper_bound:1e+07 > bucket:<cumulative_count:29 upper_bound:1e+08 > >  has label dimensions inconsistent with previously collected metrics in the same metric family

The labels being generated are definitely different. Do you have two differing configs for istio_requests_total in your prometheus adapter config OR do you have two different requestcount.metric definitions deployed to the API server?

There is other weirdness here too:
label:<name:"destination_version" value:"8" > label:<name:"destination_version" value:"8" >
Why is destination_version in the labelset twice?  Do you have config that is attempting to do that?

There is other weirdness here too:
label:<name:"destination_version" value:"8" > label:<name:"destination_version" value:"8" >
Why is destination_version in the labelset twice? Do you have config that is attempting to do that?

Nope, this is a fresh install of Istio actually:
➜  ~ int20 get handlers.config.istio.io --all-namespaces
No resources found.
➜  ~ int20 get metrics.config.istio.io --all-namespaces
NAMESPACE      NAME              AGE
istio-system   requestcount      3h
istio-system   requestduration   3h
istio-system   requestsize       3h
istio-system   responsesize      3h
istio-system   tcpbytereceived   3h
istio-system   tcpbytesent       3h
➜  ~ int20 get prometheuses.config.istio.io --all-namespaces
NAMESPACE      NAME      AGE
istio-system   handler   3h

Here's how I got here: I saw our metrics in datadog stopped being reported (we're using the DataDog istio integration). I started to investigate and noticed that the istio-telemetry pod was throwing 500s for all requests.
I port forwarded the single istio-telemetry pod locally using kubectl port-forward and grabbed the content and posted it in this ticket. I haven't done anything else.

@bobbytables which version of Istio are you testing on?
@mandarjog have there been any changes to any of the instance creation code, etc., for the gRPC work that could be creating memory corruption in instances or config?
In the example above, the instances sent to the prometheus adapter has duplicate labels (
destination_version) and one is missing a label destination_app.

@douglas-reid v1.0.0 - also. Just refreshed telemetry output and a new metric popped in (from 2 to 3 errors in prometheus now)
3 error(s) occurred:
* collected metric istio_response_bytes label:<name:"connection_security_policy" value:"none" > label:<name:"destination_app" value:"payrollsteps" > label:<name:"destination_app" value:"payrollsteps" > label:<name:"destination_app" value:"payrollsteps" > label:<name:"destination_principal" value:"unknown" > label:<name:"destination_service" value:"payrollsteps-public.applications.svc.cluster.local" > label:<name:"destination_service_name" value:"payrollsteps-public" > label:<name:"destination_service_namespace" value:"applications" > label:<name:"destination_workload" value:"payrollsteps-public" > label:<name:"destination_workload_namespace" value:"applications" > label:<name:"request_protocol" value:"http" > label:<name:"response_code" value:"422" > label:<name:"source_app" value:"unknown" > label:<name:"source_principal" value:"unknown" > label:<name:"source_version" value:"unknown" > label:<name:"source_workload" value:"unknown" > label:<name:"source_workload_namespace" value:"unknown" > histogram:<sample_count:1 sample_sum:82 bucket:<cumulative_count:0 upper_bound:1 > bucket:<cumulative_count:0 upper_bound:10 > bucket:<cumulative_count:1 upper_bound:100 > bucket:<cumulative_count:1 upper_bound:1000 > bucket:<cumulative_count:1 upper_bound:10000 > bucket:<cumulative_count:1 upper_bound:100000 > bucket:<cumulative_count:1 upper_bound:1e+06 > bucket:<cumulative_count:1 upper_bound:1e+07 > bucket:<cumulative_count:1 upper_bound:1e+08 > >  has label dimensions inconsistent with previously collected metrics in the same metric family
* collected metric istio_request_bytes label:<name:"connection_security_policy" value:"unknown" > label:<name:"destination_app" value:"permissions" > label:<name:"destination_principal" value:"unknown" > label:<name:"destination_service" value:"permissions-public.applications.svc.cluster.local" > label:<name:"destination_service_name" value:"permissions-public" > label:<name:"destination_service_namespace" value:"applications" > label:<name:"destination_version" value:"8" > label:<name:"destination_version" value:"8" > label:<name:"destination_workload" value:"permissions-grpc-v008" > label:<name:"reporter" value:"source" > label:<name:"request_protocol" value:"grpc" > label:<name:"response_code" value:"200" > label:<name:"source_app" value:"benefits" > label:<name:"source_principal" value:"unknown" > label:<name:"source_version" value:"unknown" > label:<name:"source_workload" value:"benefits-grpc" > label:<name:"source_workload_namespace" value:"applications" > histogram:<sample_count:106 sample_sum:4558 bucket:<cumulative_count:0 upper_bound:1 > bucket:<cumulative_count:0 upper_bound:10 > bucket:<cumulative_count:106 upper_bound:100 > bucket:<cumulative_count:106 upper_bound:1000 > bucket:<cumulative_count:106 upper_bound:10000 > bucket:<cumulative_count:106 upper_bound:100000 > bucket:<cumulative_count:106 upper_bound:1e+06 > bucket:<cumulative_count:106 upper_bound:1e+07 > bucket:<cumulative_count:106 upper_bound:1e+08 > >  has label dimensions inconsistent with previously collected metrics in the same metric family
* collected metric istio_request_bytes label:<name:"connection_security_policy" value:"unknown" > label:<name:"destination_principal" value:"unknown" > label:<name:"destination_service" value:"sessions-grpc-gateway.applications.svc.cluster.local" > label:<name:"destination_service_name" value:"sessions-grpc-gateway" > label:<name:"destination_service_namespace" value:"applications" > label:<name:"destination_version" value:"unknown" > label:<name:"destination_version" value:"unknown" > label:<name:"destination_workload" value:"sessions" > label:<name:"destination_workload_namespace" value:"applications" > label:<name:"reporter" value:"source" > label:<name:"request_protocol" value:"http" > label:<name:"response_code" value:"200" > label:<name:"source_app" value:"unknown" > label:<name:"source_principal" value:"unknown" > label:<name:"source_version" value:"unknown" > label:<name:"source_workload" value:"sessions" > label:<name:"source_workload_namespace" value:"applications" > histogram:<sample_count:29 sample_sum:275 bucket:<cumulative_count:28 upper_bound:1 > bucket:<cumulative_count:28 upper_bound:10 > bucket:<cumulative_count:28 upper_bound:100 > bucket:<cumulative_count:29 upper_bound:1000 > bucket:<cumulative_count:29 upper_bound:10000 > bucket:<cumulative_count:29 upper_bound:100000 > bucket:<cumulative_count:29 upper_bound:1e+06 > bucket:<cumulative_count:29 upper_bound:1e+07 > bucket:<cumulative_count:29 upper_bound:1e+08 > >  has label dimensions inconsistent with previously collected metrics in the same metric family

I just deleted the istio-system namespace and redeployed with some config updates (this is an integration cluster internally for our org) today, but we've been running 1.0 on this cluster since it dropped a few months ago.
However, this update was to get metrics into DataDog so I turned on telemetry pod.
https://gist.github.com/bobbytables/2a22f819e05f66ecec5a553b7a52f0e3

Looks like the prometheus handler isn't even defining this metric we're receiving looking closely.

@bobbytables correct. the prometheus handler is saying which labels should be there, but the instance is defined by the metric config. both of those look fine from a quick glance, which means something else is wonky. i was hoping that there would be some sort of mangled config to make debugging this easier.

Same :)
I'm wondering if this cluster has a demon of some sort from previous versions of istio that we've installed on it (This cluster has had 0.5 to 1.0 on it)

@bobbytables i never close my mind to the possibilities of demons wrecking havoc on deployments. Especially given how wonky the upgrade story has been in those generations.

@bobbytables I hesitate to ask this, but... what happens if you kill the istio-telemetry pod? Do things get better?

Yup, just deleted it and all of the metrics are back.

I imagine something somwhere will post a metric that is invalid and it'll break soon.

I think Telemetry has a bug with its consistency, the errors are variable in number. Here's a vid to show you what I mean.
https://youtu.be/Qniiv6H2Tis

Can you post telemetry logs? What surprises me is that this happens on a fresh install.
@douglas-reid grpc should not (tm) affect the static flow.

@mandarjog if this wasn't impacted by work done for grpc, I'm concerned that the (newer) runtime has some issue in the instance creation logic. There was a second report of something similar happening recently on the mailing-list. It looks, superficially, like memory reuse issues or related.

@bobbytables that video could perhaps be explained by different Report batches being sent to Mixer, I suppose. I don't know what your traffic looks like. I believe however that isn't the root cause of this issue.

@douglas-reid @mandarjog - I think there might be a race or something in Telemetry, as we noticed, the metrics in the error output has duplicate labels in it. So here's what I did.

Bounced telemetry pod which revived it.
Port-forwarded new telemetry pod and grabbed /metrics output
Waited for it to fail and grabbed the error output
Compared the erroring metric labels to old labels from step 2

Here's the result
Original Metric Labels (When Telemetry is working just fine)
connection_security_policy="none"
destination_app="payrollsteps"
destination_principal="unknown"
destination_service="payrollsteps-public.applications.svc.cluster.local"
destination_service_name="payrollsteps-public"
destination_service_namespace="applications"
destination_version="unknown"
destination_workload="payrollsteps-public"
destination_workload_namespace="applications"
reporter="destination"
request_protocol="http"
response_code="200"
source_app="unknown"
source_principal="unknown"
source_version="unknown"
source_workload="unknown"
source_workload_namespace="unknown"

New Metric Labels (Failing Metric in Prometheus Endpoint)
label:<name:"connection_security_policy" value:"none" <---------- Duplicate!
label:<name:"connection_security_policy" value:"none"
label:<name:"destination_app" value:"payrollsteps"
label:<name:"destination_app" value:"payrollsteps" <---------- Duplicate!
label:<name:"destination_principal" value:"unknown"
label:<name:"destination_service" value:"payrollsteps-public.applications.svc.cluster.local"
label:<name:"destination_service_name" value:"payrollsteps-public"
label:<name:"destination_service_namespace" value:"applications"
label:<name:"destination_version" value:"unknown"
label:<name:"destination_workload_namespace" value:"applications"
label:<name:"request_protocol" value:"http"
label:<name:"response_code" value:"302"
label:<name:"source_app" value:"unknown"
label:<name:"source_principal" value:"unknown"
label:<name:"source_version" value:"unknown"
label:<name:"source_workload" value:"unknown"
label:<name:"source_workload_namespace" value:"unknown"
histogram:<sample_count:3 sample_sum:0 bucket:<cumulative_count:3 upper_bound:1

This smells like a race condition or something that isn't maintaining dimensions correctly in Istio.

@bobbytables do you have another cluster that you can replicate this issue in? i'm not able to repro with any of my long term clusters. Also, when you have the errors, do you have the corresponding stdio logs from the telemetry pod?  Do those show duplication in labels?

I turned on debug level logs for telemetry and it doesn't include the attribute bag details:
It just says it's dispatching and that it's done
2018-09-25T17:07:27.149825Z	debug	begin dispatch: destination='kubernetes:handler.kubernetesenv.istio-system(kubernetesenv)'
2018-09-25T17:07:27.149897Z	debug	complete dispatch: destination='kubernetes:handler.kubernetesenv.istio-system(kubernetesenv)' {err:<nil>}

Do you have any logs generated by the stdio for the same request?  They should look something like:
{"sourceIp":"10.36.2.8","requestId":"aba5a631-6f95-93c0-b422-4a1d78368f24","sourceWorkload":"istio-ingressgateway","clientTraceId":"","reporter":"source","destinationIp":"10.36.1.7","httpAuthority":"35.199.189.190:15031","apiClaims":"","latency":"3.584311ms","level":"info","receivedBytes":836,"desti…

@bobbytables apologies. I believed these issues were being seen in mixer dispatch. A closer look reveals that these are being generated in the prometheus client library during a Gather(). This is likely a different issue -- and digging is still needed to figure out what could be causing that issue.

I've posted a question to prometheus-users about this issue to see if we can get some additional help in troubleshooting.

@beorn7 - Neat. If this week has enough hours for me to do that (point istio at tip) we can do a build of Istio and install it in our lower level cluster.

I have just merged https://github.com/prometheus/client_golang/pull/474 . With that one in, you should get the correct error message if your case still occurs with the current state of client_golang.

@bobbytables any update on replication with the latest client_golang?

Yeah, I would be very interested in the results of that...

https://github.com/prometheus/client_golang/pull/478 suggests current client_golang is working fine.

I'm seeing this too, in a close-to-stock installation of 1.0.2 in our staging cluster.
More info here: https://groups.google.com/d/msg/istio-users/lsdhM2meMhM/Wwx7lCAXBAAJ

Any update on this thread? We are experiencing this with Istio 1.0.1. When I delete the telemetry pod, it will then work for ~1 hour before hitting this again. We were using Istio 0.8, and build our dashboards based on this. In 0.8 we never ran into any issues. Any update on this would be great as its blocking us :)

Also facing this issue with Istio 1.0.1.
Is there any update or any way to mitigate this?

This can be closed, we updated to 1.0.4 and have seen stable telemetry metrics.

Nope, still seeing this:
* collected metric "istio_requests_total" { label:<name:"connection_security_policy" value:"unknown" > label:<name:"destination_app" value:"locator" > label:<name:"destination_service" value:"locator.applications.svc.cluster.local" > label:<name:"destination_service_name" value:"locator" > label:<name:"destination_service_namespace" value:"applications" > label:<name:"destination_version" value:"unknown" > label:<name:"destination_version" value:"unknown" > label:<name:"destination_workload" value:"locator-grpc" > label:<name:"destination_workload_namespace" value:"applications" > label:<name:"reporter" value:"source" > label:<name:"request_protocol" value:"grpc" > label:<name:"response_code" value:"200" > label:<name:"source_app" value:"hcm-web" > label:<name:"source_principal" value:"unknown" > label:<name:"source_version" value:"unknown" > label:<name:"source_workload" value:"hcm-web-public" > label:<name:"source_workload_namespace" value:"applications" > counter:<value:8 > } has two or more labels with the same name: destination_version

For those following along, I mentioned this on the related issue, but here it is again: https://github.com/prometheus/client_golang/pull/511

same issue with istio-1.0.4 + kubernetes 1.9

authors: 01deyishu beorn7 bobbytables corey-aloia-sap douglas-reid mandarjog mhamrah michaelkipper sebarys


text:
fix typo in release script

fix typo in release script

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: rkpagadala
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

release/OWNERS [rkpagadala]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

authors: istio-testing rkpagadala