text:
Improve code style and remove unneeded language keywords

SwiftLint and Xcode throw warnings when building the code.
Feel free to merge this PR if you agree with the code style and changes.

@alexsteinerde nice, thanks for your update ;)

authors: KennethTsang alexsteinerde

repo: KennethTsang/GrowingTextView


text:
Add syntax highlighting support for inline quote

Indicated by surrounding ``

Done with commit https://github.com/KevinBockelandt/notoire/commit/bfc81d85974fa93573a1b40fd7494ca06f76a49d

source: gharchive/issue

repo: KevinBockelandt/notoire

license: MIT

license_type: permissive

license_source: github-api


text:
Moving extensions directly to HttpResponseMessage class

Hello, thanks a lot for the useful library provided.
Doesn't it make sense to provide extension methods like ReadAndDeserializeFromJsonAsync() directly to HttpResponseMessage class? Usage could be simplified to smth like:
using (var response = await httpClient.SendAsync(request))
{
    Person person = await response.DeserializeAsStreamAsync<Person>();
}

That's a good idea :)  Would add them though, not replace the existing methods.  Would you be willing to provide a PR?  If not I'll just assign myself, no problem either.

Sure, will provide PR soon.

@KevinDockx, provided PR. Please, take a look. #10

Thank you - will be part of the next release :)

repo: KevinDockx/StreamExtensions


text:
Build process error in Chapter 3 build

Hey all, I just did a quick test of a build  on Linux using a "git clone" of the repo, and I get an error when the build process hits Chapter 3:
[ 60%] Generating VertexShader.spv
-V<num> client input semantics: expected attached non-0 number
make[2]: *** [Chapter3/CMakeFiles/OpenXRTutorialChapter3.dir/build.make:75: Chapter3/VertexShader.spv] Error 1
make[1]: *** [CMakeFiles/Makefile2:559: Chapter3/CMakeFiles/OpenXRTutorialChapter3.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

I tried with the Graphics API set to both VULKAN and OPENGL.

Hi @wsherman64, I think the problem lies in how we are calling glslangValidator in the CMake here:
https://github.com/KhronosGroup/OpenXR-Tutorials/blob/708c6d6397c1e480e02b882e6a74366c305769aa/cmake/glsl_shader.cmake#L95
glslangValidator is looking for a char after the -V argument expecting to find the ver number, but in our case, it seems to
be reading a space character.
I think there are two options to resolve this:

-V "${_glsl_spv_INPUT}"
"-V100" "${_glsl_spv_INPUT}"

I'd prefer option 1 as we have already defined the Vulkan version with --target-env, but maybe it might still be tripped up.
Usage:
https://github.com/KhronosGroup/glslang/blob/b820431a2cddd41155d5750e1ae6ec3def2831c0/StandAlone/StandAlone.cpp#L1956-L1961
Error Message:
https://github.com/KhronosGroup/glslang/blob/b820431a2cddd41155d5750e1ae6ec3def2831c0/StandAlone/StandAlone.cpp#L966-L972
Really strange that this never came up in testing. XR_TUTORIAL_GRAPHICS_API doesn't interact with the CMake configuration or generation.

Thanks Andrew, I'm now getting a different error at the same point.  I first tried your solution #1, and when that didn't work tried #2 -- so the results below are from trying #2.  I turned on CMake Verbose with "export VERBOSE=1", so this has more details:
cd /home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127/Chapter3 && /home/wrs1/Utils/GLSlang/glslang_20220223_Install/bin/glslangValidator -o /home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127/Chapter3/VertexShader.spv -S vert -e main -x -gVS "" "" --target-env vulkan1.0 "-V100 /home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127/Chapter3/../Shaders/VertexShader.glsl"
/home/wrs1/Utils/GLSlang/glslang_20220223_Install/bin/glslangValidator: Error: unable to open input file (use -h for usage)
make[2]: *** [Chapter3/CMakeFiles/OpenXRTutorialChapter3.dir/build.make:75: Chapter3/VertexShader.spv] Error 1
make[2]: Leaving directory '/home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127'
make[1]: *** [CMakeFiles/Makefile2:559: Chapter3/CMakeFiles/OpenXRTutorialChapter3.dir/all] Error 2
make[1]: Leaving directory '/home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127'
make: *** [Makefile:136: all] Error 2

It seems glslangValidator can't find the GLSL file. glslangValidator: Error: unable to open input file (use -h for usage)
I think this is being as a single argument not two:
"-V100 /home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127/Chapter3/../Shaders/VertexShader.glsl"

Okay, I think the issue is with the "-gVS" option.  My version of glslangValidator doesn't seem to have that option.  (Was this recently added to the build process?)
Here's the version info from my glslangValidator:
Glslang Version: 10:11.8.0
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 11.8.0
GLSL Version: 4.60 glslang Khronos. 11.8.0
SPIR-V Version 0x00010600, Revision 1
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 10
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100

I did some more experimentation today on the Linux build process, and I discovered that it's not actually the "-gVS" option that is the problem -- it's the two "" and "" that happen because of some null parameters in the CMake setup generate these double-quote pairs, and in the Linux shell, these are seen as actual arguments of strings of length 0, which then glslangValidator thinks is the name of the file, and so can't find the file.
Here are the lines of the cmake/glsl_shader.cmake file that cause this -- based on choosing the CMAKE_BUILD_TYPE whichever one is set gets the associated option, but the other two generate the empty double-quote-pair:
#$<$<CONFIG:Debug>:-Od>
#$<$<CONFIG:Release>:-g0> ```
For my current build I have ```CMAKE_BUILD_TYPE``` set to ```RelWithDebInfo``` so I had to comment out the other two settings to prevent them from adding the doulbe-quote-pair.

Otherwise, the command looks like:
```cd /home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127/Chapter3 && /home/wrs1/Utils/GLSlang/glslang_20220223_Install/bin/glslangValidator -o /home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127/Chapter3/VertexShader.spv -S vert -e main -x -gVS "" "" --target-env vulkan1.0 -V /home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20231127/Chapter3/../Shaders/VertexShader.glsl

Commit 5d0ec59 adds COMMAND_EXPAND_LISTS to all the shader compilations. So if any CMake generator expressions resolve as "", COMMAND_EXPAND_LISTS will expand those "" arguments into nothing.
I referenced this question on Stack Overflow: https://stackoverflow.com/questions/72157973/cmake-generator-expression-evaluated-to-instead-of-nothing
Let me know if this works for you.

@wsherman64 I'm not able to repro the problem on our Linux machine, it seems to work fine with or without Andrew's change.
Can you confirm if this fixes it for you please?

Yes, Andrew's change fixes the problem for me.  I also tried with an empty "CMAKE_BUILD_TYPE" with the previous version to see whether that's why Roderick wasn't seeing the problem at all, but I still got the error with that (again, with the version before Andrew's change).  So I'm not sure why it worked for Roderick.  For the record, I'm running Rocky Linux 8.8, and using CMake version 3.27.1.
I wonder @rvkennedy if you can set "export VERBOSE=1" before doing a build with the old method and report what make outputs when doing the Generating VertexShader.spv step -- which for me happens at 60% of the build process.  For me it was as reported above, where glslangValidator is called with these (and more) arguments: -S vert -e main -x -gVS "" "" --target-env vulkan1.0.  I'm curious as to whether it's something CMake is doing, or `glslangValidator is doing.
BTW, I have a couple other questions regarding the CMake options, plus a question about building for Vulkan, but I'll post those as separate issues.

Looks like if you have glslc, that will be used in preference to glslangvalidator. But even disabling this, and using CMAKE_VERBOSE_MAKEFILE to ensure "export VERBOSE=1" is added, I don't see the quote marks. This is CMake 3.27.1 on Ubuntu 20.04:
/usr/bin/glslangValidator -o /home/roderick/openxr-tutorial-src/build/Chapter3/VertexShader.spv -S vert -e main -x -gVS -Od  --target-env vulkan1.0 -V /home/roderick/openxr-tutorial-src/Chapter3/../Shaders/VertexShader.glsl

Thanks for checking @rvkennedy.  I don't have "glslc" on my system (and it doesn't seem to be in any available packages) -- but I'm not overly worried about that, was just hoping the CMake configuration could be simplified.
Regarding the double quotes -- that does surprise me, given that we're using the same version of CMake, and I don't know what other aspect of Ubuntu vs. Rocky would make a difference.
So I do want to confirm -- that was with the version of the tutorial before Andrew added the COMMAND_EXPAND_LISTS command to the CMake configuration?

Hi @wsherman64, for me, neither version adds spurious double quotes.

Okay, well I'm not sure why I was seeing the double quotes and Roderick isn't, but regardless, Andrew's changes has fixed it for me.

repo: KhronosGroup/OpenXR-Tutorials


text:
Is "OpImageFetch -> vec4" transformed to "OpImageFetch -> float"?

This is documented in https://github.com/KhronosGroup/glslang/issues/1340.
OpImageFetch in SPIR-V says:

Result Type must be a vector of four components

But, it seems something transforms glslang's emission of that into a scalar.

There is not transformation that is suppose to change the result type of an instruction.  If it is doing it is a bug.  When I try running the spir-v from https://github.com/KhronosGroup/glslang/issues/1340 through spirv-opt, I do not see the result type changing.  If there is something else you want me to look at in spir-v please re-open with more details.
I provided the spir-v that I tried below for completeness.
; SPIR-V
; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 4
; Bound: 46
; Schema: 0
               OpCapability Shader
          %2 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Fragment %main "main" %_entryPointOutput
               OpExecutionMode %main OriginUpperLeft
          %1 = OpString "Test1.hlsl"
               OpSource HLSL 500 %1 "// OpModuleProcessed entry-point main
// OpModuleProcessed hlsl-iomap
// OpModuleProcessed client vulkan100
// OpModuleProcessed target-env vulkan1.0
// OpModuleProcessed hlsl-offsets
#line 1
Texture2D<float>  g_depth;
int2 pixelPos;

float4 main() : SV_Target0
{
    float depth = g_depth[pixelPos];
    return depth;
}"
               OpName %main "main"
               OpName %g_depth "g_depth"
               OpName %_Global "$Global"
               OpMemberName %_Global 0 "pixelPos"
               OpName %_ ""
               OpName %_entryPointOutput "@entryPointOutput"
               OpDecorate %g_depth DescriptorSet 0
               OpMemberDecorate %_Global 0 Offset 0
               OpDecorate %_Global Block
               OpDecorate %_ DescriptorSet 0
               OpDecorate %_entryPointOutput Location 0
       %void = OpTypeVoid
          %4 = OpTypeFunction %void
      %float = OpTypeFloat 32
    %v4float = OpTypeVector %float 4
         %14 = OpTypeImage %float 2D 0 0 0 1 Unknown
%_ptr_UniformConstant_14 = OpTypePointer UniformConstant %14
    %g_depth = OpVariable %_ptr_UniformConstant_14 UniformConstant
        %int = OpTypeInt 32 1
      %v2int = OpTypeVector %int 2
    %_Global = OpTypeStruct %v2int
%_ptr_Uniform__Global = OpTypePointer Uniform %_Global
          %_ = OpVariable %_ptr_Uniform__Global Uniform
      %int_0 = OpConstant %int 0
%_ptr_Uniform_v2int = OpTypePointer Uniform %v2int
%_ptr_Output_v4float = OpTypePointer Output %v4float
%_entryPointOutput = OpVariable %_ptr_Output_v4float Output
       %main = OpFunction %void None %4
          %6 = OpLabel
               OpLine %1 6 0
         %39 = OpLoad %14 %g_depth
         %40 = OpAccessChain %_ptr_Uniform_v2int %_ %int_0
         %41 = OpLoad %v2int %40
         %42 = OpImageFetch %v4float %39 %41 Lod %int_0
         %43 = OpCompositeExtract %float %42 0
         %45 = OpCompositeConstruct %v4float %43 %43 %43 %43
               OpStore %_entryPointOutput %45
               OpReturn
               OpFunctionEnd

Hoping to find the cause of the reported behavior before closing; e.g., see a way to reproduce. Maybe it is just an older version, or someone will recall such a transform existed and was then fixed. If it's tied to a specific SDK release, that will be valuable to know.

People can correct me if I am wrong about this.  It looks like the the Vulkan SDK 1.1.70.1 uses commit 23ea3db3e5ea16b4964e9e3b5fee88bfc267fc57 from Feb 12.
When I update glslang to 4425f245a5aaddefa87e005e1b207f5dd2cd9c66, it starts to pass.
There were no bugs in spirv-opt that I am aware of that would have caused this problem.  If I change version of spirv-opt, does not change the behaviour.

I see. Great, thanks.

authors: johnkslang s-perron

repo: KhronosGroup/SPIRV-Tools


text:
validate VUID-StandaloneSpirv-OpImageQuerySizeLod-04659

VUID-StandaloneSpirv-OpImageQuerySizeLod-04659
OpImageQuerySizeLod, and OpImageQueryLevels must only consume an “Image” operand whose type has its “Sampled” operand set to 1
It must be guarded by being in the Vulkan environment.
cc: @sfricke-samsung in case you're trying to do this too somewhere.

Sounds good, also heads up that we just this Monday approved
https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/4316
so you will also want to add OpImageQueryLod to this

Sounds good, also heads up that we just this Monday approved
https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/4316
so you will also want to add OpImageQueryLod to this

Well I'm glad I tagged you!  :-)
Will add ImageQueryLod, thanks.

Well I'm glad I tagged you!  :-)
Will add ImageQueryLod, thanks.


text:
Better handling of attribute errors

Instead of throwing when finding unrecognized attributes, this PR makes sure all attributes are collected and an exception is thrown after all are known. This allows to actually catch the exception and handle it per object instead of just failing.
Note that I did this because TEXCOORD_4 throws exceptions (it's not available in the attribute list) - not sure if this is a bug in itself.
A file to test this with is attached. I'm not entirely sure why it even has TEXCOORD_4, but with this PR the object imports just fine.
wooden_eagle.zip

OK, I added that new exception type (following the pattern for others in Exceptions.cs) and used it to catch those in this PR.

Ok, I just merged in your big change that moved files, so now there is a conflict.  It should be easy for you to fix up (plus my one new comment about tabs) and then we can merge it in.

Yup, fixed

Instead of throwing when finding unrecognized attributes, this PR makes sure all attributes are collected and an exception is thrown after all are known. This allows to actually catch the exception and handle it per object instead of just failing.
Note that I did this because TEXCOORD_4 throws exceptions (it's not available in the attribute list) - not sure if this is a bug in itself.
A file to test this with is attached. I'm not entirely sure why it even has TEXCOORD_4, but with this PR the object imports just fine.
wooden_eagle.zip

But the model loading failed cause in GLTFSceneImporter.cs:881 the GLTFLoadException is from UnityGLTF.GLTFLoadException  (Exceptions.cs:35) and not from the GLTF.GLTFLoadException of the GLTFSerialization part (Exceptions.cs: 29).
Why is GLTFLoadException redefined in UnityGLTF ? Shouldn't you delete the class from UnityGLTF (and keep it in the GLTFSerialization part) ?

I think this might have been an oversight on my end. I searched for the exception type but didn't find an existing one. Feel free to make a PR to correct this, thank you!

source: gharchive/pull-request

repo: KhronosGroup/UnityGLTF


text:
No validation warning for barriers with redundant access flags

The spec says this:

Certain access types are only performed by a subset of pipeline stages. Any synchronization command that takes both stage masks and access masks uses both to define the access scopes - only the specified access types performed by the specified stages are included in the access scope. An application must not specify an access flag in a synchronization command if it does not include a pipeline stage in the corresponding stage mask that is able to perform accesses of that type. The following table lists, for each access flag, which pipeline stages can perform that type of access.

To me this suggests that, for example, the following barrier:
dependencies[1].dstStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
dependencies[1].dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT | VK_ACCESS_SHADER_READ_BIT | VK_ACCESS_TRANSFER_READ_BIT;

Is something an application "must not specify" since there are no stages in the mask that can issue transfer reads. It would be nice to get a validation warning/error for this.
This seems to be the case for both external pass dependencies and vkCmdPipelineBarrier.

See the dependency in the original issue; when used as an external subpass dependency it triggers no warnings/errors

OK, I see what's going on here now. CmdPipelineBarrier etc outside a renderpass validates these masks correctly, but the renderpass path is different and misses it.

Yeah - sorry, I didn't check this thoroughly; CmdPipelineBarrier does issue an error here, so the issue is only with external dependencies.

authors: chrisforbes zeux

license_source: bigquery


text:
No ByteStride

Is it normal that in my exported glTF file there is no ByteStride value in the vertex BufferView ?

As far as I understand, the byte stride is not mandatory (see the schema of buffer views). Moreover, the spec says:

"Buffer view could have byteStride property. It means byte-distance between consequential elements. This field is defined only for buffer views that contain vertex attributes."

If the byte stride is not specified, you assume the stride is the size of the underlying component type of the accessor. Again, see the full details in the data alignment section:

When byteStride of referenced bufferView is not defined, it means that accessor elements are tightly packed, i.e., effective stride equals the size of the element. When byteStride is defined, it must be a multiple of the size of the accessor's component type. byteStride must be defined, when two or more accessors use the same bufferView.

That's correct; the field is optional.

authors: ale64bit donmccurdy ladiszlai

repo: KhronosGroup/glTF-Blender-Exporter


text:
Optimize phone/tablet version

As I promised in #26, these are the screenshots taken from my iPhone that shows the difference between the uno-zen and the default casper theme for mobile devices.

I really don't know if this is a matter of design or it is made on purpose, but I personally think that the default theme looks cleanner and more elegant on the phone. This is a shame cause I love the uno-zen theme and I want to help improving it, let me know what you think on this matter @Kikobeats ;-)

I'm in love with casper mobile view. I tried to make something easy and clean in the current uno zen, but sure, something as casper is welcome as PR :-)
What is your vision of this? do you think that we will work of this in a branch?
IMHO, the handicap is the flowof

Sure, I'm not quite familiar yet with handlebars but I will try to help as
much as I can! 😊
Which is the best flow to follow? Cause right know my commits doesn't
appear until I made the pull request, that's weird 😨
El El jue, 18 jun 2015 a las 17:46, Kiko Beats notifications@github.com
escribió:

I'm in love with casper mobile view. I tried to make something easy and
clean in the current uno zen, but sure, something as casper is welcome as
PR :-)
What is your vision of this? do you think that we will work of this in a
branch?
IMHO, the handicap is the flowof
—
Reply to this email directly or view it on GitHub
https://github.com/Kikobeats/uno-zen/issues/29#issuecomment-113197809.

@kutyel any update of this?

@Kikobeats I'm afraid there is nothing new under the sun. Have been so busy lately :sleepy:

Hey, @Kikobeats & @kutyel I made some minor updates on my version. Have a look at http://robinz.in

@robincsamuel I love it!
Based in your concept I create three mockups for the main views:
Main view

Post view (sidebar close)

Post view (sidebar open)

What do you think? 😁
@robincsamuel could you put the css changes in a PR to have a base of code to work, please?

It looks cool! May be we could open up the sidebar on swipe, and also on click of that little avatar.
And sure, I'd make PR, but before that I have to update my version, and clean it up. Hoping to do it tomorrow morning; well, am on IST.

what's about avoid hamburguer menu?

more in: http://deep.design/the-hamburger-menu

ya, better

I created the branch mobile_redesign for work on this. Also I added the mockup.
Could be awesome if @robincsamuel can make a PR with the cover CSS style and then I can continue with the development :)

Sure, I'll do that. Actually I had made few more updates, so I have to filter them first

More ideas here: https://codyhouse.co/demo/stretchy-navigation/add.html

Another one 😂

:+1:

authors: Kikobeats kutyel robincsamuel

repo: Kikobeats/uno-zen

license: mit


text:
Fix name capitalization of CreditCard in readme

In the list of icons, the credit-card tag is listed 'Creditcard' which returns an error. It's actually 'CreditCard' in the package.

Thanks!

authors: Kilian vslutov

repo: Kilian/react-bytesize-icons


text:
livox mid 360

您好，我想使用在livox mid 360 上，但是map的方向以及准确性好像有点问题，这个因为扫描方法不一样吗？

谢谢回复，这个是我rosbag 链接：
我是在ubuntu20.04 ros noetic上运行的。没有使用/livox/imu (用了更奇怪）。一下我附上hdl_slam结果，虽然在尾部有些drift，但和google map上比较，还算准确。

我大致看了一下 好像问题出在后半部分，我随手重构的这个 确实没试过较大的场景（我当时是写给室内机器人用来着）

IMU是因为 外参的原因，我没写那部分
关于后半部分飘的原因 可能是因为ndt的voxel size设置的需要进行调整，这是我运行的config.yaml 供你参考 【图1，图2 是仅定位使用的话：save_frame_point: 10】

如果是要运行有IMU的算法，我建议可以试一下fast-lio2 比较好，
我这个当时就徒个快和简单，最近我有在考虑要不要深度改进一下 但是时间原因可能悬...
lidar_frame: "livox_frame"
lidar_topic: "livox/lidar"
odom_topic : ""
imu_topic  : ""

# output things ================ >
odom_lidar_topic : "/repub_points"  # sensor_msgs::PointCloud2
output_odom_topic: "/auto_odom"   # nav_msgs::Odometry

debug_print: true  # will republish point with current timestamp
use_odom   : false
use_imu    : false

imu_upside_down: false  # whether inverse the imu axis
odom_inverse: true
incremental_voxel_update: true

# setting -1 mean it will output the whole ndt map ===> FOR THE WHOLE MAP
# setting 10 mean 10*frame_point_num will be saved ===> FOR FAST LOC
save_frame_point: -1

baselink2LiDAR: [0, 0, 0, 0, 1.0, 0] # x,y,z, roll, pitch, yaw

# parameter's for ndt =========================== >
# Cell Size while mapping using ND (meters) (default 1.0)
resolution: 0.3

# Increment value between iterations while matching (default 0.1)
step_size: 0.1

# Value to decide convergence between iterations (meters) (default 0.01)
trans_epsilon: 0.01

# Maximum number of iterations before stopping matching (default 30)
max_iterations: 30

# Voxel Grid Size of the input scan (downsampling) (default 1.0)
leaf_size: 0.3

# Ignore points closer than this value (meters) (default 5.0)
min_scan_range: 0.1

# Ignore points far than this value (meters) (default 200.0)
max_scan_range: 20.0

# Minimum distance between points to be added to the final map (default 1.0)
min_add_scan_shift: 0.3

太感谢了。我之后试试看调整以下参数。fastlio也想试试，但是我rosbag录制的时候直接是转成了pointcloud2的格式，fastlio需要custommsg。我也查看了fastlio issue，是需要修改livox driver launch 里面的模式，目前没办法直接测试，可能需要重新录制一个bag。
ps：发现很早就在b站关注过了。最早看到是inkedin矢量图^ ^

您好，我想使用在livox mid 360 上，但是map的方向以及准确性好像有点问题，这个因为扫描方法不一样吗？

你好，我也是用的mid 360，也遇到了准确性的问题，参数越调效果反而越差。请问你最后有找到合适的参数吗


text:
🛑 FSDH INT is down

In 816d6cf, FSDH INT (https://fsdh-portal-app-int.azurewebsites.net/register) was down:

HTTP code: 0
Response time: 0 ms

Resolved: FSDH INT is back up in 4866ac9 after 10 minutes.

repo: KingBain/proto-datahub-uptime


text:
🛑 FSDH INT is down

In ee802b0, FSDH INT (https://fsdh-portal-app-int.azurewebsites.net/register) was down:

HTTP code: 0
Response time: 0 ms

Resolved: FSDH INT is back up in 82384d8 after 26 minutes.


text:
[FEAT] Change hideous splash screen

Splash screen is ugly, make a better one

#112


text:
อยากรบกวนขอไฟล์ geojson หน่อยครับ

ถ้าไม่รบกวนมากอาจจะใช้ Google drive ก็ได้ครับ ดูแล้วน่าจะติดเรื่อง GitHub purchasing ไม่สามารถดาวโหลดไฟล์ที่เป็น LFS ได้ครับผม

First of all, thank you @edwardmelody for your interest in my repo!
Here is the link you requested:
https://drive.google.com/drive/folders/1tVIGxPkNb7Yysz2kjiANIkG7hTFQNjtq
The files you requested will be all uploaded approx. 8 PM Today.

authors: KittapatR edwardmelody


text:
KCL: Pattern repetitions now pattern instances

@jgomez720 requests pattern calculations take the total number of instances, not the number of extra repetitions to do. This is how we designed the patternTransform API, but we didn't do that for patternLinear/Circular.
Also enforced that the number of instances must be >= 1.
This is a breaking change.

Hell yeah awesome!

repo: KittyCAD/modeling-app


text:
Cannot import package due to exported js files not being modules

package.json specifies type: "module" but the distributed js files are using require so node is throwing when trying to import the package.
See Node docs ESM

Hello. The package exports both a CJS and an ESM entry point, and I use it in another library of mine, so I’m not sure there is an issue with the package itself. Maybe if you share some code, I can check. :)

const focusableSelectors = require('focusable-selectors');

console.log(focusableSelectors());

On Node v18.14.0 try running the file.
./focusableSelectorsTest.js:1
const focusableSelectors = require('focusable-selectors');
                           ^

Error [ERR_REQUIRE_ESM]: require() of ES Module ./node_modules/focusable-selectors/index.js from ./focusableSelectorsTest.js not supported.
index.js is treated as an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which declares all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use dynamic import() which is available in all CommonJS modules, or change "type": "module" to "type": "commonjs" in ./node_modules/focusable-selectors/package.json to treat all .js files as CommonJS (using .mjs for all ES modules instead).

    at Object.<anonymous> (./focusableSelectorsTest.js:1:28) {
  code: 'ERR_REQUIRE_ESM'
}

I can reproduce. I think we need to remove "type": "module" from the package.

Fixed in 0.8.2. Sorry for the delay. :(

authors: KittyGiraudel josh-signal

repo: KittyGiraudel/focusable-selectors


text:
Shorten Slicer-build name

This is becoming to much of a hassle on windows in debug mode.
The name Slicer-build should be shortened to prevent the error when compiling (cl runs out of memory because of too many include directories that are too long).

Fixed with 8de92c65404c98c8a3207d8fd2e64b7c202b8d2c

repo: KitwareMedical/VesselView


text:
rendererConfig#path should support a TypeScript Vite config

Right now the following configuration will not work:
rendererConfig:
  type: vite
  path: src/renderer/vite.config.ts
  src: src/renderer/main.ts
  output: dist/renderer

// src/renderer/vite.config.ts
import {defineConfig} from 'vite';
import reactRefresh from '@vitejs/plugin-react-refresh';

export default defineConfig({
	plugins: [reactRefresh()],
	build: {
		target: 'chrome89',
	},
});

Thanks for the report.
Right now, electron esbuild use require to read the configuration and need to overwrite some options.
electron-esbuild will need to use the same process to build the configuration in memory with esbuild.

I wonder if it's possible to use something like ts-node/register to still be able to require but allow for a TypeScript configuration file.
Thank you for your amazing work on electron-esbuild, you have saved me a lot of time and have made it extremely easy to bootstrap an electron app! 💖

I made a PR #23
This will fix this issue by allowing configurations written in TypeScript, ESM or CJS (vite, esbuild, webpack).
You'll be able to write your esbuild config in TypeScript or ESM!

Thank you!! 🎉

authors: Kiyozz alii

repo: Kiyozz/electron-esbuild


text:
[ContextualAction][Icon][label] Label in contextual action with shape icon is not rendered well

This is a material design issue.
It can be good if the label is convert like a tooltip on mouse over.

The problem is in the button, it should not render any label when the type is icon or fab

Please create another issue for the tooltip

authors: JRLK pierr

repo: KleeGroup/focus-components


text:
[date_component] z-index regression for the calendar popin

The z-index of the calendar popin provided in focus-components.css is setted improperly when used inside a block.

Yeah it's a duplicate but don't forget it does it with the autocomplete too.

Yes, it is induced by the panel, which has been fixed and will be release in 0.7.1

authors: Bernardstanislas JabX durandx


text:
[Search] Highlight search input in results

Current behavior
The search results are displayed plainly
Expected behavior
Within the search results, highlight the text which the user entered as a search

:+1:

@pierbrisson it will be implemented in v3.x.x on focus, in focus-search lib.
it should be possible to use this lib in your project.
https://github.com/get-focus/focus-search/issues/31

This issue was moved to get-focus/focus-search#45

will be done in v3 http://github.com/get-focus/focus-search

authors: TomGallon pierbrisson sgoretti


text:
Make sure channel names are casemapped properly for state tracking

Need to make sure of is that the channel name (the target variable passed to command handlers) is always IRC casemapped properly. This is to make sure that our internal state tracking always refers to the correct channel.
Taking a look at irc3, this may not be automatically done, but I'll need to run some more proper tests to make sure. If it's not being done in the library, I've written some code to do IRC casemapping in the past, so I can port some of that to this.
I can tackle this, just making an issue so I remember to look at it later :)

This is fixed as of #9


text:
few changes to consider

repo reorganization, so that it can be downloaded as a zip and extracted to addons or pinned as a git submodule
dock size increase bug workaround

I looked at these changes and I can't accept the first commit. The current structure is required for the plugin to work when downloaded from AssetLib.
The second one seems to have many unrelated changes, as the base fix is simply enabling the horizontal scroll. I think it's acceptable for now; in 4.0 I could use the new HFlowContainer instead.
So if you remove the first commit and change the second one so that it only removes scroll_horizontal_enabled = false and updates the README, I could merge this.

oh, had no idea about AssetLib - then nvm :)

authors: KoBeWi Scony

repo: KoBeWi/Godot-Instance-Dock


text:
Number Mapping

Elasticsearch supports a bunch of number types, which have a neat 1:1 mapping for Rust numbers.
Use the most detailed number type available:

Rust
Elasticsearch

i64
long

i32
integer

i16
short

u8
byte

f64
double

f32
float

The base work is looking done, just need to add mapping tests now.

repo: KodrAus/elasticsearch-rs


text:
Reloading custom plugins

Custom plugins that are provided with the values plugins.configMaps or plugins.secrets aren't currently reloaded when the underlying resources are updated. This has caused us some confusion on a number of occasions.
We can't use the standard Helm trick of adding a checksum annotation because the plugin files don't belong to the Kong chart. All of the solutions that we've found available to us so far are all pretty fragile:

pre-process the values file to set podAnnotations.checksum/plugins
post-process the chart to set an annotation
update the name of the ConfigMap each time we change the plugins

An alternative solution could be for Kong to recognise and reload plugins when the mounted ConfigMap changes - although that may also be confusing if it's decoupled from normal Helm deployments.
Do you have any other suggestions?

This is an inherent limitation of how Kong handles plugins currently: it loads plugin files at startup, and never looks at them again unless you run kong reload (there's no good way to do so on Kubernetes--you'd need to shell into the individual containers and run it).
Handling this automatically on the fly when ConfigMaps update files on the filesystem would require a feature request to https://github.com/Kong/kong to automatically reload on changes to plugin files.
My recommendation here is to either run rollout restart manually or to build a custom container, i.e. create a Dockerfile based on the kong/kong image and either use luarocks install or copy files directly into /usr/local/share/lua/5.1/kong/plugins, build that, and push an upgrade that uses the new image, ideally from a CD system.
Nothing in the chart will ever be able to trigger an update within running containers, since at best we'd be able to perform a lookup on the ConfigMap to get its version and set an annotation to that value, which will just trigger a Deployment rollout anyway, and not provide any obvious advantage over just running rollout restart.

authors: dcarley rainest

repo: Kong/charts


text:
Ensure environment variables map is ordered

Upgrade fails when runMigrations: true
When running a standard helm upgrade, it fails with error message similar to this:
[tiller] 2020/01/30 15:21:51 warning: Upgrade "kong-tst" failed: Job.batch "kong-tst-kong-app-init-migrations" is invalid: spec.template: Invalid value: <SNIP> : field is immutable

The easy workaround was to set runMigrations: false. But I wanted to investigate this and see if we could run the upgrade cleanly without changing values....
Since we are dealing with maps, there is zero guarantee that the output yaml will
be the same between runs. In most cases this is not an issue, but the env map is
used by jobs. In this case spec.template is immutable and if the env list
order changes, it results in a failed upgrade.
So in the construction of the map, we ensure (by ordering the list of keys) that
it is idempotent.

Branch rebased with with next branch

IIRC there was some reason we handle this a bit unusually, but I think that was more about not making this an initContainer itself. @hbagdi do you recall?

This has been on the todo for a while. We should do init-migrations only on install and delete on success. I can't recall if we had that before and we removed it for some reason. Git spelunking would help here.


text:
KIC: Warn that deploy manifests don't install the admission webhook

Where is the problem?
https://docs.konghq.com/kubernetes-ingress-controller/latest/deployment/admission-webhook/#verify-incorrect-credential-secrets
What happened?
@rkazak ran into an issue with these docs:
The Verify incorrect credential secrets section said that KIC would reject an invalid secret while, when tried, it did not (because KIC was installed from deploy manifests).
What did you expect to happen?
The docs saying that KIC will reject an invalid secret only if installed with the admission webhook (installed by default by the Helm chart but not by deploy manifests).
The scope of this issue is to put the warning in at least the below places:

Quick Start Guide
The Verify incorrect credential secrets section mentioned above (currently unclear to me which guide that is)
Other places that mention webhook rejection/validation

Code of Conduct and Community Expectations

[X] I agree to follow this project's Code of Conduct
[X] I agree to abide by the Community Expectations

Hi @mflendrich.  This has now been addressed in the documentation: https://docs.konghq.com/kubernetes-ingress-controller/latest/deployment/admission-webhook/. The related PR is https://github.com/Kong/docs.konghq.com/pull/6342. The instructions were tested and validated.
Last login: Thu Oct 19 09:57:19 on ttys001
rajakavitha@Rajakavithas-MacBook-Air ~ % orb start k8s
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl get nodes
NAME       STATUS   ROLES                  AGE   VERSION
orbstack   Ready    control-plane,master   13h   v1.27.4+orb1
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/v2.12.x/deploy/single/all-in-one-dbless.yaml

error: unable to read URL "https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/v2.12.x/deploy/single/all-in-one-dbless.yaml", server reported 404 Not Found, status code=404
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/main/deploy/single/all-in-one-dbless.yaml

Warning: resource namespaces/kong is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
namespace/kong configured
Warning: resource customresourcedefinitions/ingressclassparameterses.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/ingressclassparameterses.configuration.konghq.com configured
Warning: resource customresourcedefinitions/kongclusterplugins.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/kongclusterplugins.configuration.konghq.com configured
Warning: resource customresourcedefinitions/kongconsumergroups.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/kongconsumergroups.configuration.konghq.com configured
Warning: resource customresourcedefinitions/kongconsumers.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/kongconsumers.configuration.konghq.com configured
Warning: resource customresourcedefinitions/kongingresses.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/kongingresses.configuration.konghq.com configured
Warning: resource customresourcedefinitions/kongplugins.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/kongplugins.configuration.konghq.com configured
Warning: resource customresourcedefinitions/tcpingresses.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/tcpingresses.configuration.konghq.com configured
Warning: resource customresourcedefinitions/udpingresses.configuration.konghq.com is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/udpingresses.configuration.konghq.com configured
serviceaccount/kong-serviceaccount created
role.rbac.authorization.k8s.io/kong-leader-election created
clusterrole.rbac.authorization.k8s.io/kong-ingress created
clusterrole.rbac.authorization.k8s.io/kong-ingress-crds created
clusterrole.rbac.authorization.k8s.io/kong-ingress-gateway created
rolebinding.rbac.authorization.k8s.io/kong-leader-election created
clusterrolebinding.rbac.authorization.k8s.io/kong-ingress created
clusterrolebinding.rbac.authorization.k8s.io/kong-ingress-crds created
clusterrolebinding.rbac.authorization.k8s.io/kong-ingress-gateway created
service/kong-admin created
service/kong-proxy created
service/kong-validation-webhook created
deployment.apps/ingress-kong created
deployment.apps/proxy-kong created
Warning: resource ingressclasses/kong is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
ingressclass.networking.k8s.io/kong configured
rajakavitha@Rajakavithas-MacBook-Air ~ % curl -sL https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/main/hack/deploy-admission-controller.sh | bash

.....+++++++++++++++++++++++++++++++++++++++*........+.......+..............+....+.........+.....+.+..+...+....+++++++++++++++++++++++++++++++++++++++*.........+..........+........+...+....+.....+......+.........+......+....+........+.+.....+....+...............+...+...++++++
.....+........+...+...+...............+++++++++++++++++++++++++++++++++++++++*.+.............+++++++++++++++++++++++++++++++++++++++*.....+..............+...+.......+...+............+...+..+.............+......+..+.........+...+.......+...+........+...+.+...+..................+........+.........+...+.........+....+..+......................+..+...+.++++++
-----
secret/kong-validation-webhook created
deployment.apps/ingress-kong patched
validatingwebhookconfiguration.admissionregistration.k8s.io/kong-validations created
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl create secret tls kong-validation-webhook -n kong \
    --key tls.key --cert tls.crt

error: failed to create secret secrets "kong-validation-webhook" already exists
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl get deployments -A
NAMESPACE     NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
kong          kong-gateway             1/1     1            1           13h
kube-system   coredns                  1/1     1            1           13h
kube-system   local-path-provisioner   1/1     1            1           13h
kong          kong-controller          1/1     1            1           13h
kong          proxy-kong               2/2     2            2           77s
kong          ingress-kong             1/1     1            1           77s
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl patch deploy -n kong ingress-kong \
    -p '{"spec":{"template":{"spec":{"containers":[{"name":"ingress-controller","env":[{"name":"CONTROLLER_ADMISSION_WEBHOOK_LISTEN","value":":8080"}],"volumeMounts":[{"name":"validation-webhook","mountPath":"/admission-webhook"}]}],"volumes":[{"secret":{"secretName":"kong-validation-webhook"},"name":"validation-webhook"}]}}}}'

deployment.apps/ingress-kong patched (no change)
rajakavitha@Rajakavithas-MacBook-Air ~ % >....
    - configuration.konghq.com
    apiVersions:
    - '*'
    operations:
    - CREATE
    - UPDATE
    resources:
    - kongconsumers
    - kongplugins
  - apiGroups:
    - ''
    apiVersions:
    - 'v1'
    operations:
    - UPDATE
    resources:
    - secrets
  clientConfig:
    service:
      namespace: kong
      name: kong-validation-webhook
    caBundle: $(cat tls.crt  | base64) " | kubectl apply -f -

validatingwebhookconfiguration.admissionregistration.k8s.io/kong-validations configured
rajakavitha@Rajakavithas-MacBook-Air ~ % echo "apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: harry
  annotations:
    kubernetes.io/ingress.class: kong
username: harry" | kubectl apply -f -

kongconsumer.configuration.konghq.com/harry created
rajakavitha@Rajakavithas-MacBook-Air ~ % echo "apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: harry2
  annotations:
    kubernetes.io/ingress.class: kong
username: harry" | kubectl apply -f -

Error from server: error when creating "STDIN": admission webhook "validations.kong.konghq.com" denied the request: consumer already exists
rajakavitha@Rajakavithas-MacBook-Air ~ % echo "
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: request-id
config:
  foo: bar
  header_name: my-request-id
plugin: correlation-id
" | kubectl apply -f -

Error from server: error when creating "STDIN": admission webhook "validations.kong.konghq.com" denied the request: plugin failed schema validation: schema violation (config.foo: unknown field)
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl create secret generic some-credential \
  --from-literal=kongCredType=basic-auth \
  --from-literal=username=foo

secret/some-credential created
rajakavitha@Rajakavithas-MacBook-Air ~ % kubectl create secret generic some-credential \
  --from-literal=kongCredType=wrong-auth \
  --from-literal=sdfkey=my-sooper-secret-key

error: failed to create secret secrets "some-credential" already exists
rajakavitha@Rajakavithas-MacBook-Air ~ %

Closing this issue for now. Please feel to reopen if any other issue needs to be addressed. Related PR: https://github.com/Kong/docs.konghq.com/pull/6342


text:
[DOCU-2771] Konnect OIDC config

Summary

OIDC is now supported in Konnect. We need to update our SSO documentation for Okta and create a new document for Azure (work currently blocked) and generic OIDC.
Reason

DOCU-2771
Testing

Questions for reviewers:

Does anything feel missing from the generic OIDC doc?
Does the title work for the generic OIDC doc?
In the Okta doc, I kind of feel like the "Log in through Okta to test the integration" section is mostly a repeat of the "Test and apply the configuration" section. I'm thinking they could be combined but wanted a second opinion.
In the Okta doc, I was thinking that it would be nice (not 100% needed) to break the "Prerequisites and overview of steps" section into "Prerequisites" and "Overview of steps". The overview is nice, but since the doc covers how to complete all those steps, I don't think they're a prerequisite. Thoughts?

Hi @Guaris - I'm curious why this is part of the Gateway 3.0 milestone?

@rosskukulinski  A mistake. This PR is actually just waiting on Hayden's approval.

authors: Guaris cloudjumpercat rosskukulinski


text:
Add single source docs to the Contributing guide

Summary

Added our internal docs about the single sourced versions and single sourced plugins to the external contributing guide.
Reason

This information is helpful to all contributors, and it was kind of hidden/not in the place contributors would expect to find it. This PR makes it easier to find.
Testing

See the single sourced versions and single sourced plugins pages in the contributor's guide (they're in the Markdown rules and formatting section).
Notes for reviewers:

I only lightly edited these for the sake of getting them published ASAP. Is there any other reformatting that I should do for this initial PR?
Is there any other tech information that is missing from these? @Guaris, I know you mentioned conditional rendering based on product type, but I don't remember how that was done.
I thought about pulling the "Conditional rendering" section out into it's own page since it's related to single sourcing, but feels like there's enough content and it's different enough/used often enough, that it would help to have a separate page. Thoughts?

Can you add https://konghq.atlassian.net/browse/DOCU-2582 to the title/description?

@cloudjumpercat
product conditional rendering looks like this
{% unless page.edition == "konnect" %}
This will be hidden for Konnect
{% endunless %}

I think the docs set would be stronger if conditional rendering was split out into it's own doc like you mentioned.

authors: Guaris cloudjumpercat lena-larionova


text:
Release: Gateway version 3.4.3.3

EE changelog here: https://github.com/Kong/kong-ee/pull/7816

We shouldn't skip docs changelog entries for these, they're records of releases.

authors: Guaris lena-larionova


text:
Fix #2376: remove extra "to" in error

Fixed the typo in the GraphQL error message "Failed to to fetch schema."
Closes #2376

No problem! I'm trying to ease myself into learning about open source contributions.

No problem! I'm trying to ease myself into learning about open source contributions.

Best way to do it 😄 the issues labeled good first issue are excellent starting points

authors: JinayJain develohpanda

repo: Kong/insomnia


text:
fix: only change environment on fresh import

This change makes it so that when switching between debug and design tabs, it only selects the default environment the first time. Subsequent switches will test whether an active environment id has already been set and ignore.
I've updated the comments as well. Since there were no tests around this area, I did not add or edit any - and will not do so since I am not familiar with the tests infrastructure yet.
Closes #2228
Impacts #2680

Welcome @apisaint!

Welcome @apisaint!

Oops, clicked the wrong button by accident 😅
Welcome @apisaint! Great work, I know we have gotten a few reports and requests for this so much appreciated. 🤗

Oops, clicked the wrong button by accident 😅
Welcome @apisaint! Great work, I know we have gotten a few reports and requests for this so much appreciated. 🤗

Oops, clicked the wrong button by accident 😅

I've done it myself many times they are so close to each other!

Welcome @apisaint! Great work, I know we have gotten a few reports and requests for this so much appreciated. 🤗

Thank you! ❤ Hope to see it merged soon so others can benefit

Oops, clicked the wrong button by accident 😅

I've done it myself many times they are so close to each other!

Welcome @apisaint! Great work, I know we have gotten a few reports and requests for this so much appreciated. 🤗

Thank you! ❤ Hope to see it merged soon so others can benefit

Thanks for the contribution! When I functionally tested this (against the steps listed in #2228 (comment)) I still had properties removed in by Base Environment. Is this intended to fix that (I'm assuming so because you said it closes that issue, but I wanted to be sure because otherwise we should track that other part separately).

It is not intended to fix that aspect, only switching. Can create another PR for that later.

authors: apisaint nijikokun


text:
Missing X-Forwarded-Prefix header in 0.10 and 0.11

Summary
I recently upgraded from 0.9.9 to 0.10.3 and it appears the X-Forwarded-Prefix header has been dropped.
I've used this header to identify what the actual URL is the client used so the API can function both behind Kong and on it's own. I use path based routing in Kong, having Kong strip the path prefix before proxying to the API. However, now that the X-Forwarded-Prefix header has been removed I can no longer accurately reconstruct the full URL clients use to reach the API. I've since upgraded to 0.11.1 hoping the issue may have been solved in the latest version, but it doesn't appear to be.
Sample X-* headers from Kong 0.9.9:
X-Consumer-Groups
X-Consumer-Id
X-Consumer-Username
X-Credential-Username
X-Forwarded-For
X-Forwarded-Port
X-Forwarded-Prefix    <---
X-Forwarded-Proto

Sample X-* headers from Kong 0.10.3 and 0.11.1:
X-Consumer-Groups
X-Consumer-Id
X-Consumer-Username
X-Credential-Username
X-Forwarded-For
X-Forwarded-Port
X-Forwarded-Proto

Additional Details

Running under Kong docker images

Hi @bloche,
Yes indeed. Started in 0.10 we decided to drop "non-standard" (I know it sounds redundant) X-Forwarded-* headers, and change the meaning of such forwarded headers to carry information that is commonly conveyed by those headers. That means those headers, as of today, carry more meaning about the typical reverse-proxying flow, and less about Kong-specifics, like "which API" was matched, and "how" it was matched. This is very likely to stay like so.
That said, we do understand the value of providing headers to the upstream services about which API Kong detected and how it did so. However, we believe those headers should be configurable, because not every user will rely on them in their upstream services. As of today, such "matching" information is constrained to the core, and available here for plugins consumption.
If you wish to send such information upstream via HTTP headers, I suggest writing a plugin that adds that information to the upstream HTTP request. It should be extremely straightforward. In the future, we will explore ways of providing this behavior out of the box, possibly in a configurable fashion.

reconstruct the full URL clients use to reach the API

Just curious: how come you don't rely on transparent proxying instead?

@thibaultcha Thanks for clarifying that for me, your quick response is much appreciated.

Just curious: how come you don't rely on transparent proxying instead?

This is the way my colleagues and I started using Kong a while back and haven't had any real problems with it until now. However, we will probably start to move toward a transparent proxy moving forward, as there have been some other minor inconveniences because of it.

authors: bloche thibaultcha

repo: Kong/kong


text:
Docker image hanging on Cassandra access for 30 minutes (Kubernetes only)

Summary
I’m facing a very strange situation: command lines in my (home-made) Docker image of Kong in version 1.0.3 are working correctly, but since version 1.1 (tested on 1.1.1 and 1.1.2), the CLI commands are “hanging” at the very beginning of the process during about 30 minutes before moving forward!
This is the case for the kong start command as well as for much simpler commands such as kong migrations list.
This happens when running Kong with Cassandra, but not with Postgres.
I can reproduce it when running on Kubernetes, but not on plain Docker.
I suspect this could be a side effect of resolutions of https://github.com/Kong/kong/pull/4296 and https://github.com/Kong/kong/pull/4378... introduced in Kong 1.1...
Steps To Reproduce

On a Kubernetes cluster, run a Cassandra in version 2.2 or 3.10
Run a Kubernetes Pod of (my !) Docker image of Kong, with a command as simple as kong migrations list
Pod is hanging for the next 30 minutes!

This happens on my own Docker image... not tested so far with the "official" Docker image of Kong produced through docker-kong.
Additional Details & Logs
With logs sets to “debug”, hanging usually happens at the end of the display of the Kong configuration… but not exactly every time at the exact same location.
2019/04/30 14:31:10 [warn] You are using Cassandra but your 'db_update_propagation' setting is set to '0' (default). Due to the distributed nature of Cassandra, you should increase this value.
2019/04/30 14:31:10 [verbose] Kong: 1.1.2
2019/04/30 14:31:10 [debug] ngx_lua: 10013
2019/04/30 14:31:10 [debug] nginx: 1013006
2019/04/30 14:31:10 [debug] Lua: LuaJIT 2.1.0-beta3
2019/04/30 14:31:10 [verbose] reading config file at /opt/kong/etc/kong.conf
2019/04/30 14:31:10 [debug] reading environment variables
2019/04/30 14:31:10 [debug] KONG_PREFIX ENV found with "/opt/kong/var"
2019/04/30 14:31:10 [debug] KONG_DATABASE ENV found with "cassandra"
2019/04/30 14:31:10 [debug] KONG_CASSANDRA_CONTACT_POINTS ENV found with "cassandra-0"
2019/04/30 14:31:10 [debug] KONG_LOG_LEVEL ENV found with "info"
2019/04/30 14:31:10 [debug] KONG_CASSANDRA_KEYSPACE ENV found with "kong"
2019/04/30 14:31:10 [debug] KONG_NGINX_DAEMON ENV found with "off"
2019/04/30 14:31:10 [debug] admin_access_log = "logs/admin_access.log"
2019/04/30 14:31:10 [debug] admin_error_log = "logs/error.log"
2019/04/30 14:31:10 [debug] admin_listen = {"127.0.0.1:8001","0.0.0.0:8444 ssl"}
2019/04/30 14:31:10 [debug] admin_ssl_cert = "/opt/kong/etc/certs/changeme-kong_kong_com-super-bundle.pem"
2019/04/30 14:31:10 [debug] admin_ssl_cert_key = "/opt/kong/etc/certs/changeme-kong_kong_com-key.pem"
2019/04/30 14:31:10 [debug] anonymous_reports = false
2019/04/30 14:31:10 [debug] cassandra_consistency = "LOCAL_QUORUM"
2019/04/30 14:31:10 [debug] cassandra_contact_points = {"cassandra-0"}
2019/04/30 14:31:10 [debug] cassandra_data_centers = {"dc1:1"}
2019/04/30 14:31:10 [debug] cassandra_keyspace = "kong"
2019/04/30 14:31:10 [debug] cassandra_lb_policy = "RequestRoundRobin"
2019/04/30 14:31:10 [debug] cassandra_local_datacenter = "dc1"
2019/04/30 14:31:10 [debug] cassandra_port = 9042
2019/04/30 14:31:10 [debug] cassandra_repl_factor = 1
2019/04/30 14:31:10 [debug] cassandra_repl_strategy = "NetworkTopologyStrategy"
2019/04/30 14:31:10 [debug] cassandra_schema_consensus_timeout = 120000
2019/04/30 14:31:10 [debug] cassandra_ssl = false
2019/04/30 14:31:10 [debug] cassandra_ssl_verify = false
2019/04/30 14:31:10 [debug] cassandra_timeout = 5000
2019/04/30 14:31:10 [debug] cassandra_username = "kong"
2019/04/30 14:31:10 [debug] client_body_buffer_size = "8k"
2019/04/30 14:31:10 [debug] client_max_body_size = "0"
2019/04/30 14:31:10 [debug] client_ssl = false
2019/04/30 14:31:10 [debug] database = "cassandra"
2019/04/30 14:31:10 [debug] db_cache_ttl = 0
2019/04/30 14:31:10 [debug] db_resurrect_ttl = 30
2019/04/30 14:31:10 [debug] db_update_frequency = 5
2019/04/30 14:31:10 [debug] db_update_propagation = 0
2019/04/30 14:31:10 [debug] declarative_config = "/opt/kong/etc/endpoints/kong-endpoints.yaml"
2019/04/30 14:31:10 [debug] dns_error_ttl = 1
2019/04/30 14:31:10 [debug] dns_hostsfile = "/etc/hosts"
2019/04/30 14:31:10 [debug] dns_no_sync = false
2019/04/30 14:31:10 [debug] dns_not_found_ttl = 30
2019/04/30 14:31:10 [debug] dns_order = {"LAST","SRV","A","CNAME"}
2019/04/30 14:31:10 [debug] dns_resolver = {}
2019/04/30 14:31:10 [debug] dns_stale_ttl = 4
2019/04/30 14:31:10 [debug] error_default_type = "application/json"
2019/04/30 14:31:10 [debug] headers = {"server_tokens","latency_tokens"}
2019/04/30 14:31:10 [debug] log_level = "info"
2019/04/30 14:31:10 [debug] lua_package_cpath = ""
2019/04/30 14:31:10 [debug] lua_package_path = "/opt/kong/lib/?.lua;/opt/kong/lib/?/init.lua;"
2019/04/30 14:31:10 [debug] lua_socket_pool_size = 30
2019/04/30 14:31:10 [debug] lua_ssl_verify_depth = 1
2019/04/30 14:31:10 [debug] mem_cache_size = "128m"
2019/04/30 14:31:10 [debug] nginx_admin_directives = {{value="/opt/kong/lib/my_nginx_admin.conf",name="include"}}
2019/04/30 14:31:10 [debug] nginx_admin_include = "/opt/kong/lib/my_nginx_admin.conf"
2019/04/30 14:31:10 [debug] nginx_daemon = "off"
2019/04/30 14:31:10 [debug] nginx_http_directives = {{value="/opt/kong/lib/my_nginx_http.conf",name="include"}}
2019/04/30 14:31:10 [debug] nginx_http_include = "/opt/kong/lib/my_nginx_http.conf"
2019/04/30 14:31:10 [debug] nginx_optimizations = true
2019/04/30 14:31:10 [debug] nginx_proxy_directives = {{value="/opt/kong/lib/my_nginx_proxy.conf",name="include"}}
2019/04/30 14:31:10 [debug] nginx_proxy_include = "/opt/kong/lib/my_nginx_proxy.conf"
2019/04/30 14:31:10 [debug] nginx_sproxy_directives = {}
2019/04/30 14:31:10 [debug] nginx_stream_directives = {}
2019/04/30 14:31:10 [debug] nginx_user = "bob bob"
2019/04/30 14:31:10 [debug] nginx_worker_processes = "auto"
2019/04/30 14:31:10 [debug] origins = {}
2019/04/30 14:31:10 [debug] pg_database = "kong"
2019/04/30 14:31:10 [debug] pg_host = "127.0.0.1"
2019/04/30 14:31:10 [debug] pg_port = 5432
2019/04/30 14:31:10 [debug] pg_ssl = false
2019/04/30 14:31:10 [debug] pg_ssl_verify = false
2019/04/30 14:31:10 [debug] pg_timeout = 5000
2019/04/30 14:31:10 [debug] pg_user = "kong"
2019/04/30 14:31:10 [debug] plugins = {"bundled","my-verify-jwt","my-verify-roles"}
2019/04/30 14:31:10 [debug] prefix = "/opt/kong/var"
2019/04/30 14:31:10 [debug] proxy_access_log = "logs/access.log"

Then, the process is “hanging” during around 30 minutes (maybe a bit more: 32 to 33 minutes)… and it is finally “unlocked” and continues its processing until the end !! For the kong migrations list, it just displays the remaining logs:
2019/04/30 14:31:10 [debug] proxy_listen = {"127.0.0.1:8000","0.0.0.0:8443 ssl"}
2019/04/30 14:31:10 [debug] real_ip_header = "X-Real-IP"
2019/04/30 14:31:10 [debug] real_ip_recursive = "off"
2019/04/30 14:31:10 [debug] ssl_cert = "/opt/kong/etc/certs/changeme-kong_kong_com-super-bundle.pem"
2019/04/30 14:31:10 [debug] ssl_cert_key = "/opt/kong/etc/certs/changeme-kong_kong_com-key.pem"
2019/04/30 14:31:10 [debug] ssl_cipher_suite = "modern"
2019/04/30 14:31:10 [debug] ssl_ciphers = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
2019/04/30 14:31:10 [debug] stream_listen = {"off"}
2019/04/30 14:31:10 [debug] trusted_ips = {}
2019/04/30 14:31:10 [debug] upstream_keepalive = 60
2019/04/30 14:31:10 [verbose] prefix in use: /opt/kong/var
2019/04/30 15:04:30 [debug] resolved Cassandra contact point 'cassandra-0' to: 172.20.139.20
2019/04/30 15:04:30 [debug] loading subsystems migrations...
2019/04/30 15:04:30 [verbose] retrieving keyspace schema state...
2019/04/30 15:04:30 [verbose] schema state retrieved
2019/04/30 15:04:30 [info] executed migrations:
core: 000_base, 001_14_to_15, 002_15_to_1, 003_100_to_110
rate-limiting: 000_base_rate_limiting, 001_14_to_15, 002_15_to_10
hmac-auth: 000_base_hmac_auth, 001_14_to_15
oauth2: 000_base_oauth2, 001_14_to_15, 002_15_to_10
jwt: 000_base_jwt, 001_14_to_15
basic-auth: 000_base_basic_auth, 001_14_to_15
key-auth: 000_base_key_auth, 001_14_to_15
acl: 000_base_acl, 001_14_to_15
response-ratelimiting: 000_base_response_rate_limiting, 001_14_to_15, 002_15_to_10
2019/04/30 15:04:30 [info] database is up-to-date

Looking to the time of the logs, it looks the resolved Cassandra contact point 'cassandra-0' is the first log displayed after the hanging.
During the blocking situation, jumping into the container, a ps shows:
PID   USER     TIME  COMMAND
    1 bob       0:00 perl /usr/local/openresty/bin/resty /usr/local/bin/kong migrations list --vv -c /opt/kong/etc/kong.conf
    8 bob       0:00 /usr/local/openresty/nginx/sbin/nginx -p /tmp/resty_xOpJBTuZMW/ -c conf/nginx.conf

It looks there is absolutely no activity on process 8 !
No log inside the /tmp/resty_xOpJBTuZMW/logs/error.log
At first, trying to understand the root cause of the blocking situation, I tried to have a look to the file descriptors by running ls -l /proc/8/fd (in case this could be a problem with file access):
lr-x------    1 bob      bob         64 Apr 30 09:23 0 -> pipe:[1708382985]
l-wx------    1 bob      bob         64 Apr 30 09:23 1 -> pipe:[1708382986]
l-wx------    1 bob      bob         64 Apr 30 09:23 2 -> pipe:[1708382987]
lrwx------    1 bob      bob         64 Apr 30 09:23 3 -> anon_inode:[eventpoll]
lrwx------    1 bob      bob         64 Apr 30 09:23 4 -> anon_inode:[eventfd]
lrwx------    1 bob      bob         64 Apr 30 09:23 5 -> socket:[1708412118]
lrwx------    1 bob      bob         64 Apr 30 09:23 6 -> socket:[1708412119]

I honestly don’t know if the 2 anonymous inodes could be the source cause of the issue !
The, I looked to the network by running netstat -a:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 kong-test:38959         kube-dns.kube-system.svc.cluster.local:domain ESTABLISHED
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path

Even more strange, still inside the container, I tried to run the exact same command manually (e.g. kong migrations list)… and it succeeds !!! I can run it as many times, run kong start, etc, everything is ok… except that the one I’m really expected to run (i.e. the one automatically launched at Pod starting time) is still blocked !
Where does this happen ?

This happens when running the Docker image under Kubernetes. However, I did not succeed in reproducing the issue in a plain Docker deployment!
I reproduced the issue on different Kubernetes clusters: on a own deployed Kubernetes, and on an EKS provided by AWS. On these same clusters, exactly the same test with the “equivalent” Docker image in version 1.0.3 and the same Kong configuration is working well all the time.
I reproduced the issue on Cassandra 2.2 and Cassandra 3.10... but not on Postgres. My Cassandra instance is a single node Dockerized Cassandra.

Differences with the “official” Docker image made available through the docker-kong project:

I’m not preparing the kong prefix and then running nginx; I’m “still” using kong start instead, as I used to do that since ages :P and as I did not encounter any issue in using it so far. I however don’t think the current problem is linked to that as I the issue happens with much simpler commands such as “kong migrations list” which does not start Kong… unless a kong prepare shall also be done, even for the simple call of kong migrations ?
Kong is installed in the regular /usr/local/kong but my prefix is not: this is /opt/kong/

Hi again,
Just tested with the official “docker.io/kong:1.1.2-alpine” image… and the issue is there as well (it is not only on my own Docker image !).
Here are complementary investigations we run on our side: it looks the problem is linked to the new DNS query implementation (I’m not saying it is due to it, just linked to it so far :yum:  ). Indeed, we performed many tests, and our current hypothesis is that there might be an issue in the “network layer setup/establishment” that makes the Kong DNS query to Cassandra blocked in the new implementation while it was not in the previous one.
Here are the tests we run (we have screenshots of WireShark available if you want):

Test 1: With Kong version 1.0.3, the DNS queries monitored with WireShark shows 2 type “A” DNS queries: 1 from Kong container to the Core DNS Kubernetes Service IP address (i.e. the Cluster IP of the Core DNS Kubernetes Service), just followed by a second identical query to the IP address of the Pod implementing the Core DNS. This is, I guess, the local relay done by the kube-proxy to the Pod. Answers (again, 2 of them are tracked by WireShark) immediately provide the IP address of Cassandra. Everything works fine.
Note: dns_order was set to the default value: LAST,SRV,A,CNAME, but “A” query came first. Is “SRV” implemented in version 1.0.3?…

Test 2: With Kong 1.1.2, WireShark shows only a single “SVR” DNS query… and nothing else! The second one (the relay done by the kube-proxy) does not appear, nor any answer from the DNS. Kong looks blocked on sending this very first UDP packet (during the next 30 minutes) !
Why are we considering that there is an issue in the “network layer setup/establishment”? Because the 2nd query (i.e. the relay of the first query, made by the kube-proxy) is not caught by WireShark. The original packet is most probably lost during sent time (explains that we don’t have any response) but after WireShark has tracked it; and the client (i.e. Kong) is also most probably blocked on the send call (otherwise we would enter into a retry mechanism that would be faster than 30 minutes).
Note1: dns_order was set to the default value: LAST,SRV,A,CNAME, so “SRV” query came first. In order to check if the issue was coming from the “SRV” implementation, we set dns_order to “A” only, and we saw a “A” query instead or “SRV”… but with exactly the same issue: only one query, Kong being immediately blocked.
Note 2: the “A” query is strictly identical to the one obtained during test 1 => this is consequently not an issue in the implementation of the formatting of the DNS query.

Test 3: What brings us to the hypothesis of a “network layer setup/establishment” issue is the fact that we run exactly the same test as test 2, but inserting a sleep 5 at the beginning of the docker-entrypoint.sh, and this time, everything is working fine !! We gave 5 seconds to the process/environment to setup properly all layers, and then the DNS queries are made correctly !
This also explains why, when Kong is stuck executing a kong migrations list as part of its docker-entrypoint.sh, we can jump into the container and manually run the same kong migrations list and everything goes fine: the container has been launched for several seconds => all network layers are up and running.
Note 1: We tried with 1 seconds and 2 seconds instead of 5… and this is not sufficient !
Note 2: We surprisingly see not only 2 DNS queries… but 8: the 2 first are the one looking for cassandra.default.svc.cluster.local and the response immediately provides the corresponding IP address of Cassandra. We would expect the process to stop here… but indeed 2 other SRV queries are then tracked by WireShark for cassandra.svc.cluster.local, with 2 answers “No such name SRV”, and then 2 others for cassandra.cluster.local, and then 2 for cassandra, all of them with answers “No such name SRV”. This is most probably not linked with the issue we are studying in this thread, but isn’t there a bug in the implementation of the “SVR” which queries all possible options (according to the resolve.conf) while the first request has already returned a valid response?

So, here is our current status: we think there is a problem around the “network layer setup/establishment”. This problem was most probably not visible with the former implementation of the DNS query in Kong, but the new implementation done through #4296 and #4378 is now revealing the bug.
Where is the bug ? In Kong (well, we don't think it is, but at least, the new implementation is revealing the issue as a side effect) In Alpine ? In Kubernetes (we've not seen the issue in raw Docker) ? In the network overlay deployed on Kubernetes (we have a cluster with Calico, but the other one does not have it) ? For the moment, we don’t know… but any idea, any help would be welcome !
We are still not comfortable with:

The fact that a sleep 5 is solving the issue… but not a sleep 1! (Indeed, I've seen it work once with sleep 1, but most of the time it has not...)
Why the blocking situation last 30 minutes? To be more precise, following the logs, it appears to be more precisely 33min and around 20 sec… so maybe a total of 2000 seconds! Where is configured this 30min/2000sec ? We tried to change the dns_not_found_ttl parameter (which default value is … 30 !) to 1 (in case the unit would be minutes instead of seconds :yum:) … but no: still 30 minutes waiting

If you have an easy debugging capability, could you try to see on which call Kong is hanging?
We gonna try to create a very simple process that immediately queries the DNS (out of any Kong context), to check if an Alpine or a Kubernetes issue could be highlighted.

Episode III…
I think we got it!
There are most likely 2 issues:

One on Docker or Kubernetes side (Alpine is out of the game) – still investigating to find exactly where it is –
And One on Kong side, on the new implementation of the DNS query for Cassandra

We have reproduced the exact same behavior explained in the previous posts, but using an “aggressive” Pod which only runs nslookup or dig:

Test 1: Creating a simple Alpine pod that executes the command time dig <ip address of DNS> cassandra-0, we see in the logs that it took 2.5 seconds to get the answer from the DNS. Looking to the traces in Wireshark, we can see that a first “A” query is sent and does not have any response, followed 2.5sec later by a second “A” query that succeeds (i.e. that has a response).
Thanks to that, we identified:
-- The Docker or Kubernetes bug: still to be characterized in more details, but we think that either Kubernetes tells Docker that the network layer is OK before it is in reality, or Docker tells Kubernetes Pod that the network layer is OK before it is in reality.
-- The fact that tools such as dig and nslookup are implementing a timeout on the DNS query (2.5 seconds), and a retry mechanism (so that after these 2.5 seconds without receiving any answer, a retry is done and is working well).

Test 2: we added the options  +time=1 +retry=0 to dig, which sets a timeout to 1 second, and 0 retries. And now dig exits after 1 second (the timeout value) by saying that the server name is not found (DNS resolution failed). In WireShark, we only see the first “A” answer… and nothing else (exactly what we saw in the tests with the Kong images presented in my previous posts: only one request without any answer). As there is no retry, then dig can only exist with "DNS resolution failed"

Test 3: introducing a sleep 5 before the call to dig… well, things are going well whatever the value for the +retry parameter as the network layer anyway had enough time to be set up, before the first attempt to send the “A” query => the retry mechanism is not used in this test.

Test 4, we reproduced the exact same behavior and traces with the official Docker image of Kong (and using nslookup only, as dig is not available in this image):
-- If just running  kong docker-start, Kong starts and is blocked
-- If running the command time nslookup cassandra-0 <ip address of DNS>; kong docker-start then Kong is not blocked but the traces shows that the nslookup is first taking 2.5 seconds (as it internally implements the retry mechanism until the network layer is established, and thus the name resolution is done), and after that, Kong is started normally

Test 5: Trying the same tests again in a plain Docker environment, the nslookup and dig is taking 10 ms only: very far from the second or more in a Kubernetes environment => the network layers are established very fast => the retry mechanism in the client application is never used => Kong is working.

As a sum-up of these tests:

The Official Kong Docker image, as is, cannot be started on Kubernetes (encountered on 3 different clusters using different NCI). This is a quite blocking issue.
This is due to an issue in the establishment of the network layer that is very long on Kubernetes. Still investigating where is the root cause
However, contrary to what is implemented in nslookup or dig, the Kong implementation of the DNS query (for Cassandra) is not resilient and no timeout and retry mechanism is implemented so far. This is not related to the TTL of the query for which there are many configuration parameters already, but this is for a timeout when no answer at all is received for a request.
We have not investigated to know if the former implementation of the DNS query for Cassandra used to have such a retry mechanism (or if the DNS query for Postgres or for the upstream micro-services have such a mechanism), but it is most likely that the answer is “no”

That's quite a read thanks for the very thorough investigation / write up 👍
can you share your k8s yaml (or helm etc) that you're using (is it https://github.com/Kong/kong-dist-kubernetes or closely related?)

Hi @hutchic, you are welcome !!
I confirm what you said in https://github.com/Kong/docker-kong/issues/258#issuecomment-490965438: this is a Cassandra issue only, and on Kubernetes only.
Here is my test yaml file:
kind: Pod
apiVersion: v1
metadata:
  name: "kong-dns-test"
spec:
  containers:
    -
      name: "kong-dns-test"
      image: "docker.io/kong:1.1.2-alpine"
      command: ["kong"]
      args: ["migrations", "list", "--vv"]
      env:
        - name: KONG_LOG_LEVEL
          value: "debug"
        - name: KONG_DATABASE
          value: "cassandra"
        - name: KONG_CASSANDRA_CONTACT_POINTS
          value: "kong-database-2"
  restartPolicy: Never

I made further investigations to locate where the issue could be. It is quite difficult as the logs are not displayed (the freeze of Kong blocks the display of the logs in the middle of the configuration parameter outputs: most probably no flush on stdout is done => none of the logs you could add to check the DNS processing is displayed). I managed it by inserting os.execute ("echo xyz") commands...
At the end, the configuration that is provided to the Resolver looks correct, with a number of retries set to 5 and a timeout set to 2000ms:
{
  search = {
    "default.svc.cluster.local",
    "svc.cluster.local",
    "cluster.local"
  },
  nameservers = {
    "192.168.96.84"
  },
  badTtl = 30,
  order = {
    "LAST",
    "SRV",
    "A",
    "CNAME"
  },
  noSynchronisation = true,
  emptyTtl = 1,
  ndots = 5,
  timeout = 2000,
  hosts = "/etc/hosts",
  enable_ipv6 = true,
  staleTtl = 4,
  retrans = 5
}

What is strange is that the socket that is created by the Resolver is supposed to be configured with the right data: 5 retries and a timeout of 2000 milli-seconds... but when executed, the timeout is indeed of 2000... seconds !!
I fear that this is the overwrite of nxg.socker.udp that is done here https://github.com/Kong/kong/blob/master/kong/db/strategies/cassandra/connector.lua#L66 that is ignoring the timeout (and taking a very long default value), or that has a different behavior in its timeout implementation and expecting the time to be set in seconds instead of milli-seconds !
Indeed, I don't know where this "socket" package comes from (local udp = require("socket").udp(...))

Sorry for only seeing this now. I was about to point to the Cassandra connector's override of the TPC/UDP sockets, but I see that your investigation already led you there @pamiel :)
You will notice that the DNS resolver instantiated there specifies timeout = nil (source). This means that the resolver will use the timeout option specified in resolv.conf (see man 5 resolv.conf). What does this value look like in your pod? It is supposed to be a value in seconds. Otherwise, the default is set here.
Here is the issue though: with cosockets (the OpenResty sockets), the timeout is specified in miliseconds (hence, 2 seconds), but with LuaSocket (since we overrode the sockets to resolve the hostnames in init_by_lua in the Cassandra connector), the argument is specified in seconds, hence, 2000 seconds. cc @Tieske

Note: lua-resty-dns-client may benefit from something like https://github.com/thibaultcha/lua-resty-socket (which is used by lua-cassandra and other driver modules out there).

@thibaultcha , indeed by default myresolv.conf has no option =>this is the default value that is used.
During my numerous tests, I however made some tests setting the timeout in resolv.conf: as far as I remember, I tried setting it with both 2 and 2000... and Kong was hanging in both cases.
Does it mean that this value is not taken into account at all ? I don't know: maybe the value 2 was multiplied by 1000 and considered as seconds instead of milliseconds by Luasocket => 30 min waiting; and 2000 was waiting 2,000,000 seconds !... but I don't remember me waiting until the unlock of the Pod for these tests; sorry for that.

maybe the value 2 was multiplied by 1000 and considered as seconds instead of milliseconds by Luasocket

Yes, I believe (without testing it myself) specifying this value in resolv.conf will have the same effect with the current implementation of the C* connector: you'll still have a 20 or 30 min long timeout because lua-resty-dns-client will still multiply it by 1000.

Hello @pamiel , are you still experiencing this problem, or can we close this issue?

I am closing this due to lack of activity. Please reopen if necessary.

authors: hutchic kikito pamiel thibaultcha


text:
chore(ci) build nightly releases from jenkins instead of travis-ci (#…

Moves the kong nightly builds off of travis-ci onto a internal private jenkins instance.
This has been running on a Kong fork for about a week successfully and jenkins is configured in such a way that it will not report failures back to github

@hutchic I split it into two commits

@hishamhm yeah it occurred to me that I squashed too far but the forgot to tease them apart thanks for that 👍

authors: hishamhm hutchic


text:
chore: simplify tools installation and management with mise

What this PR does / why we need it:

🙇 Please test locally on your machine.

❗ There is a problem with Checks / linters / lint (pull_request_target), because we use workflow from main branch and it uses third_party/go.mod that is removed in this file, so it has to be merged with by-passing and observing on main

Scope

Get rid of dir third_party and dedicated go.mod for managing tooling and all related Makefile config. Use mise to install delve from the source code (a binary is not provided).
gotestsum is handled natively
crd-ref-docs use the same approach for installation as for delve - built from source
setup-envtest is handled natively
staticcheck is handled natively
cleanup leftovers from already removed (see #6563) deprecated looppointer linter.

Which issue this PR fixes:
Follow up for https://github.com/Kong/kubernetes-ingress-controller/pull/6563

I implemented your suggestion @czeslavo and made couple of other improvements, so please check everything again

repo: Kong/kubernetes-ingress-controller


text:
SD1.5 models vs SD_X4Upscaler

Hi there,
I can't figure it out how to solve my issues, newbie here.. Still not understanding everything I do..
I keep receiving the following error, although tried several options (see capture). Please support

[AnimateDiffEvo] - INFO - Loading motion module animatediffMotion_v15.ckpt
!!! Exception during processing!!! Motion module 'animatediffMotion_v15.ckpt' is intended for SD1.5 models, but the provided model is type SD_X4Upscaler.
Traceback (most recent call last):
File "D:\ComfyUI_windows_portable\ComfyUI\execution.py", line 151, in recursive_execute
output_data, output_ui = get_output_data(obj, input_data_all)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable\ComfyUI\execution.py", line 81, in get_output_data
return_values = map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable\ComfyUI\execution.py", line 74, in map_node_over_list
results.append(getattr(obj, func)(**slice_dict(input_data_all, i)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-AnimateDiff-Evolved\animatediff\nodes_gen1.py", line 138, in load_mm_and_inject_params
motion_model = load_motion_module_gen1(model_name, model, motion_lora=motion_lora, motion_model_settings=motion_model_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-AnimateDiff-Evolved\animatediff\model_injection.py", line 1058, in load_motion_module_gen1
raise MotionCompatibilityError(f"Motion module '{mm_info.mm_name}' is intended for {mm_info.sd_type} models, "
ComfyUI-AnimateDiff-Evolved.animatediff.utils_motion.MotionCompatibilityError: Motion module 'animatediffMotion_v15.ckpt' is intended for SD1.5 models, but the provided model is type SD_X4Upscaler.

You cant use AnimateDiff with SD_4XUpscaler model, just like the error says. AnimateDiff works only for SD1.5-based models and in the case of Hotshot/AnimadeDiffSDXL, SDXL-based models. I'll take a look at the guts of SD_4XUpscaler model to see if its architecture is similar enough to SD1.5 to hack something together, but I wouldn't hold my breath.

Thanks for your quick reply.
I'm confused which model to use and where to change it in ComfyUI, I've downloaded huge amount of GBs to pick the right one.
Could you please advise by sharing a link from where to download the right one, I'm just trying to play with feature not intended for something serious, so it is fine each way..
I can see that mainly my issues are generated by 'Load Checkpoint' node + AnimateDiff Loader (Legacy).. so I assume this is where I should provide different input...
Thanks again for kind support.

authors: Kosinkadink mmiittzz

repo: Kosinkadink/ComfyUI-AnimateDiff-Evolved


text:
Dockerize the server & userscript for non-Firefox users

I run the server at https://lesson-titles-videoserver-fit-vut.cunt.cz/ext/ext.html.
I've also adapted the code to be usable in other browsers by utilizing Tampermonkey or similar extensions.
Thank you for this awesome code and idea!

Good job.

authors: Kiznoh KrKOo

repo: KrKOo/VUT-FIT-Video-server-extension


text:
PlistBuddy set method

The increment version/build methods were really nice additions, but some people (like me, of course :)) use a script to increment these values in the plist, so the agvtool isn't really helpful.
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

Adding a set method to the PlistBuddy module would be really nice for us.
def set(file, key, value)
  output = `/usr/libexec/PlistBuddy -c "Set #{key} #{value}" "#{file}" 2>&1`
  output == "" ? value : nil
end

So we can do stuff like:
version = Shenzhen::PlistBuddy.print(plist, 'CFBundleShortVersionString')
[...]
Shenzhen::PlistBuddy.set(plist, 'CFBundleShortVersionString', newVersion)

Credit goes to Nassim's gist.

@rolandleth Cool, feel free to submit a pull request if you have some time :+1:

@KrauseFx Hmm, that would be my pleasure, but it should be added to the krausefx-shenzhen gem, and I don't know where to do that. Open a PR here?

Yes, the link is correct. Right now, only through environment variables.

Opened a PR! As for the params, I was thinking about passing arguments from the command line, for example fastlane release --minor

Thanks again for your contribution @rolandleth :+1:

authors: KrauseFx rolandleth

repo: KrauseFx/fastlane


text:
Global options

Added support for global setting of options

Travis CI build event failing for node 0.11 and 0.10; succeeding for node 0.12. This may be an issue with npm or the phantomjs package but those versions have been unchanged since last successful running so the cause is currently unknown.
I'm going to hold off merging until the issue is either resolved or I am satisfied that this PR is perfectly safe (which I am 99% certain but want to take some time to double check and validate).

Travis appears to not be working correctly. I have independently verified the builds on the older nodes so I'm going to merge and close this. I'll see if I can get travis to re-verify for my sanity.


text:
配置文件中添加代理选项

服务器上不是很方便使用全局代理，直连又经常出现对话卡死现象，希望能在配置文件中自行填写代理地址

感谢建议，当前使用的是openai官方的sdk，并不支持直接设置代理，未来会考虑改用原生requests请求

感谢建议，当前使用的是openai官方的sdk，并不支持直接设置代理，未来会考虑改用原生requests请求

openai sdk是可以设置代理的
openai.proxy='代理地址'即可设置，已经实验过了是可行的

好的！下个版本加入 ( •̀ ω •́ )✧

感谢！下个版本跟随chatgpt模型接入一同更新

authors: HMScygnet KroMiose


text:
merge package from arlac77/npm-package-template-esm-only

package.json

chore(package): ava@^2.0.0
chore(scripts): cover@#overwrite c8 --temp-directory build/tmp ava && c8 report -r lcov -o build/coverage --temp-directory build/tmp
chore(scripts): posttest@markdown-doctest

Coverage remained the same at 73.599% when pulling e1c8a616f1385075f663ba83c9a45e337fe95038 on npm-template-sync-1 into 90f4e909439c73a7686719613a1f41ab532fdf25 on master.

:tada: This PR is included in version 3.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: Kronos-Integration/kronos-endpoint


text:
merge from arlac77/npm-package-template-esm-only

.travis.yml

chore(travis): remove 12.10.0 (node_js)
chore(travis): remove npm (cache)
chore(travis): remove npm run cover,npx codecov,cat ./build/coverage/lcov.info | npx coveralls (script)
chore(travis): add [object Object],[object Object],[object Object] (jobs.include[])

:tada: This PR is included in version 3.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


text:
merge package template from arlac77/npm-package-template

LICENSE

chore(license): add current year 2018

Codecov Report

Merging #350 into master will decrease coverage by 1.63%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #350      +/-   ##
==========================================
- Coverage   79.78%   78.14%   -1.64%
==========================================
  Files           3        3
  Lines         183      183
==========================================
- Hits          146      143       -3
- Misses         37       40       +3

Impacted Files
Coverage Δ

tests/service-test.js
95.12% <0%> (-2.44%)
:arrow_down:

src/service-consul.js
71.64% <0%> (-1.5%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f720e31...154b101. Read the comment docs.

Coverage decreased (-1.3%) to 71.308% when pulling 154b101490c16e8a185fe04fb1cdc37abc7167c1 on template-sync-1 into f720e31e290c8a42fb12ae98fdf100d630f3c50e on master.

Coverage decreased (-1.3%) to 71.308% when pulling 154b101490c16e8a185fe04fb1cdc37abc7167c1 on template-sync-1 into f720e31e290c8a42fb12ae98fdf100d630f3c50e on master.

authors: arlac77 codecov-io coveralls


text:
merge package from arlac77/npm-package-template

package.json

chore(package): rollup@^1.12.0
chore(package): rollup-plugin-commonjs@^10.0.0
chore(package): rollup-plugin-node-resolve@^5.0.0
chore(package): add builtin-modules@^3.1.0
chore(scripts): cover@#overwrite c8 --temp-directory build/tmp ava && c8 report -r lcov -o build/coverage --temp-directory build/tmp
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/-test.js,tests/-test.mjs' as in template
chore(package): set $.ava.extensions='js,mjs' as in template

rollup.config.js

chore(rollup): import builtins

:tada: This PR is included in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: Kronos-Integration/kronos-service-koa


text:
Spaces between words in sidebar and project windows are too wide.

I've noticed an odd spacing issue on some areas of text within the application. See the image for reference:

The areas I've noticed this problem affecting are:

project names in the sidebar
Add Project button in the sidebar
Project titles in the main view (where all of a project's tasks are displayed)
Task titles in the main view
Task titles in a task view

hey @silverben10,
thanks for the report of this issue.
I don't see such behavior but I'd like to test more. Could you please share what is the system you're using (windows or linux and if linux then what distro and what desktop environment) ?

Of course, thanks for the quick reply!

OS: Linux
Distro: Arch
DE: KDE

I can try reinstalling it and see if the issue persists?

Thanks!
I don't think re-installation will help, it may be related to system font and its interference with the original font the app is using. But it's just a guess. I'll try to install kde to my test machine (not arch though) and I get back to you with more info.
If you can find what font do you use in KDE that would be helpful

Ok, sounds good. Here are the font settings for my DE.

I downloaded the fonts using this AUR package

repo: KryDos/todoist-linux


text:
Update README to show the correct license image.

In this commit, I updated the README to reflect the relicense under the GPL 3 as for some reason it was left as an MIT license.

Codecov Report

Merging #79 (828c782) into master (f4d353c) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #79   +/-   ##
=========================================
  Coverage     37.66%   37.66%
  Complexity      868      868
=========================================
  Files           894      894
  Lines         20760    20760
  Branches       1639     1639
=========================================
  Hits           7820     7820
  Misses        12845    12845
  Partials         95       95

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4d353c...828c782. Read the comment docs.

authors: aidanjbennett codecov-commenter

repo: KryptonMC/Krypton


text:
when only one photo, the photo is not centered

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request

Current behavior
When there is only one photo, the photo is not centered, but left aligned.
Expected behavior
Photo should be centered
Minimal reproduction of the problem with instructions
See punker (and click on the firest (and only) photo )
https://plnkr.co/edit/yBu18OCZQQjHPdyR0UGY?p=preview
What is the motivation / use case for changing the behavior?

Environment (the most important section to fill very carefully)

- Node version: 6.11.0
- npm version: 3.10.10
- Operating System and version:  Windows
- Angular version: X.Y.Z
- angular-cli version (or SystemJS/Webpack): X.Y.Z
- I'm using Server Side Rendering with angular-universal: YES/NO
- I'm compiling with mode: DEBUG / PROD / PROD with AOT

Browser:
- [x] Chrome (desktop) version 65.0.3325.181
- [x] Firefox version 59.02
- [x] Edge version 41.16299.248.0
- [x] Opera version 52.0.2871.40

Probably, I won't fix it this week, because I'm really busy, but I'll try asap. Please be patient.

Sorry for the delay, but I was really busy.
I'll try to fix it this weekend or next week.

Thank you for your patience.
Issue fixed in 5.5.1.
Feel free to re-open if you think that it's not ok.

however this issue is already closed (my fault, sorry for that), I confirm that this issue is indeed fixed !
Thanks for the excellent work !

@pieterdegraeuwe
thank u and I'm happy that you are happy :).
Feel free to both express your ideas and to contribute.


text:
Needs license

Thanks for putting this out there. Would be great to have a license attached so I can use it.

sorry !

authors: Kuqd garyjohnson

repo: Kuqd/DisableCharmBar


text:
Title:  US State Guesser Game Python

Is your proposal related to a problem? Please describe.
It is game which is made in python which uses turtle module takes the name from the user and deploy on the map
Add any other context or screenshots about the proposal request here.

@Kushal997-das assign me this issue


text:
added hackathon tracker

solved #1364

https://github.com/user-attachments/assets/df75b15b-e742-46bd-99f7-6899a57160db
🎉 Have you reviewed the Contributing Guidelines? 🤔 (Required)

[x] YES
[ ] NO

📝 Description
added hackathon tracker to web development project
🔧 Fixes #1364

🏷 Initiative Participation (Required)
This pull request is associated with the following initiative. Please choose the one you are contributing to:

[ ] 🌸 GSSoC (Girl Script Summer of Code)
[x] 🌼 GSSoC 2024 Extd.
[x] 🍂 Hacktoberfest 2024
[ ] ❄ Script Winter of Code (SWoC)
[ ] ⛄ Winter of Blockchain (WoB)
[ ] 🙋♂ Personal
[ ] 📌 Other (please specify): _______________

@Kushal997-das please check and merge it

@Kushal997-das sir please review and merge it as i need to raise 1 more pr

@Kushal997-das made necessary changes - sync the repo, added comments and screenshot. please check

@Kushal997-das how to deploy ? can you tell what exactly i need to do

Could you please deploy the project and add the live link to the README.md file? This will help users easily access and check the project.
Thank you!

You don't know what is deploy ? I want you to deploy (Host your project) so that we can see the website easily.

@Kushal997-das added the live deployment

@Kushal997-das i hope i have fixed everything correct now, please check and merge. also sorry for the inconvenience caused.


text:
refactor: appconfig and module generators

What type of PR is this?

/kind feature
What this PR does / why we need it:
This PR refactors the implementations for generating the Spec of AppConfiguration and the Resources of ModuleGenerator.
Which issue(s) this PR fixes:

Fixes #1330
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., design docs, usage docs, etc.:

Pull Request Test Coverage Report for Build 12082624304
Details

97 of 132 (73.48%)  changed or added relevant lines in 6 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.4%) to 49.074%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/generators/secret/secret.go
3
5
60.0%

pkg/generators/util.go
45
54
83.33%

pkg/generators/orderedresources/ordered_resources_generator.go
21
31
67.74%

pkg/generators/namespace/namespace_generator.go
13
27
48.15%

Files with Coverage Reduction
New Missed Lines
%

pkg/engine/operation/parser/parser.go
3
79.27%

Totals

Change from base Build 12065653611:
0.4%

Covered Lines:
10445

Relevant Lines:
21284

💛  - Coveralls

repo: KusionStack/kusion


text:
orderbook-generator

Orderbook generator: Initial version with randomized data

@talbaneth

repo: KyberNetwork/exchange-simulator


text:
KE-18856 acclerate clean block

acclerate clean block

retest this please

repo: Kyligence/spark