[Bug]: vLLM model backend crashed when running single user prompts, less than 128 token input context

Your current environment
tt-metal: https://github.com/tenstorrent/tt-metal/commit/385904186f81fed15d5c87c162221d4f34387164
vllm: https://github.com/tenstorrent/vllm/commit/384f1790c3be16e1d1b10de07252be2e66d00935
Runtime using ghcr.io/tenstorrent/tt-inference-server/tt-metal-llama3-70b-src-base-vllm:v0.0.1-tt-metal-385904186f81-384f1790c3be
Model Input Dumps
No response
🐛 Describe the bug
vLLM model backend crashed when running single user prompt, after several prompts were completed and some time had passed between usage it failed on first prompt sent again.
The prompts sent initially varied from 1-2048 context, ~2 hours passed, and the prompt causing failure was sent. The failure causing prompt was "Can you tell me a joke?", on the order of 10 tokens.
Logs below:
INFO 11-17 13:49:12 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.0 tokens/s, Running: 0 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 0.0%.
INFO 11-17 13:49:22 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.0 tokens/s, Running: 0 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 0.0%.
INFO 11-17 13:49:32 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.0 tokens/s, Running: 0 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 0.0%.
INFO 11-17 13:49:40 logger.py:37] Received request cmpl-5a89b06405434a5ba0e8845972bbfc22-0: prompt: '\n<|begin_of_text|>\n\n<|start_header_id|>user<|end_header_id|>\n\n\nTell me a fun fact.\n\n<|start_header_id|>assistant<|end_header_id|>\n\n\n', params: SamplingParams(n=1, presence_penalty=0.0, frequency_penalty=0.0, repetition_penalty=1.0, temperature=1.0, top_p=0.9, top_k=20, min_p=0.0, seed=None, stop=['<|eot_id|>'], stop_token_ids=[], include_stop_str_in_output=False, ignore_eos=False, max_tokens=512, min_tokens=0, logprobs=None, prompt_logprobs=None, skip_special_tokens=True, spaces_between_special_tokens=True, truncate_prompt_tokens=None), guided_decoding=GuidedDecodingParams(json=None, regex=None, choice=None, grammar=None, json_object=None, backend=None, whitespace_pattern=None), prompt_token_ids: [128000, 198, 128000, 271, 128006, 882, 128007, 1432, 41551, 757, 264, 2523, 2144, 382, 128006, 78191, 128007, 1432], lora_request: None, prompt_adapter_request: None.
INFO:     <IP_ADDRESS>:58712 - "POST /v1/completions HTTP/1.1" 200 OK
INFO 11-17 13:49:40 engine.py:291] Added request cmpl-5a89b06405434a5ba0e8845972bbfc22-0.
2024-11-17 13:49:40.071 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 1
ERROR 11-17 13:49:48 client.py:250] TimeoutError('No heartbeat received from MQLLMEngine')
ERROR 11-17 13:49:48 client.py:250] NoneType: None
ERROR:    Exception in ASGI application
  + Exception Group Traceback (most recent call last):
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 188, in __call__
  |     await response(scope, wrapped_receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 222, in __call__
  |     async for chunk in self.body_iterator:
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 179, in body_stream
  |     raise app_exc
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 149, in coro
  |     await self.app(scope, receive_or_disconnect, send_no_error)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/cors.py", line 85, in __call__
  |     await self.app(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/exceptions.py", line 62, in __call__
  |     await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
  |     raise exc
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
  |     await app(scope, receive, sender)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 715, in __call__
  |     await self.middleware_stack(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 735, in app
  |     await route.handle(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 288, in handle
  |     await self.app(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 76, in app
  |     await wrap_app_handling_exceptions(app, request)(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
  |     raise exc
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
  |     await app(scope, receive, sender)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 74, in app
  |     await response(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 257, in __call__
  |     await wrap(partial(self.listen_for_disconnect, receive))
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 685, in __aexit__
  |     raise BaseExceptionGroup(
  | exceptiongroup.ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
  +-+---------------- 1 ----------------
    | Traceback (most recent call last):
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
    |     result = await app(  # type: ignore[func-returns-value]
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py", line 60, in __call__
    |     return await self.app(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/fastapi/applications.py", line 1054, in __call__
    |     await super().__call__(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/applications.py", line 113, in __call__
    |     await self.middleware_stack(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 187, in __call__
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 165, in __call__
    |     await self.app(scope, receive, _send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
    |     response_sent.set()
    |   File "/usr/lib/python3.8/contextlib.py", line 131, in __exit__
    |     self.gen.throw(type, value, traceback)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 83, in collapse_excgroups
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
    |     await func()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 242, in stream_response
    |     async for chunk in self.body_iterator:
    |   File "/home/user/vllm/vllm/entrypoints/openai/serving_completion.py", line 262, in completion_stream_generator
    |     async for prompt_idx, res in result_generator:
    |   File "/home/user/vllm/vllm/utils.py", line 506, in merge_async_iterators
    |     item = await d
    |   File "/home/user/vllm/vllm/engine/multiprocessing/client.py", line 598, in _process_request
    |     raise request_output
    | vllm.engine.multiprocessing.MQEngineDeadError: Engine loop is not running. Inspect the stacktrace to find the original error: TimeoutError('No heartbeat received from MQLLMEngine').
    +------------------------------------

During handling of the above exception, another exception occurred:

  + Exception Group Traceback (most recent call last):
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 77, in collapse_excgroups
  |     yield
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
  |     response_sent.set()
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 685, in __aexit__
  |     raise BaseExceptionGroup(
  | exceptiongroup.ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
  +-+---------------- 1 ----------------
    | Traceback (most recent call last):
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 257, in __call__
    |     await wrap(partial(self.listen_for_disconnect, receive))
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
    |     await func()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 230, in listen_for_disconnect
    |     message = await receive()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 126, in receive_or_disconnect
    |     message = await wrap(wrapped_receive)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 121, in wrap
    |     result = await func()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 51, in wrapped_receive
    |     msg = await self.receive()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 555, in receive
    |     await self.message_event.wait()
    |   File "/usr/lib/python3.8/asyncio/locks.py", line 309, in wait
    |     await fut
    | asyncio.exceptions.CancelledError
    |
    | During handling of the above exception, another exception occurred:
    |
    | Exception Group Traceback (most recent call last):
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 188, in __call__
    |     await response(scope, wrapped_receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 222, in __call__
    |     async for chunk in self.body_iterator:
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 179, in body_stream
    |     raise app_exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 149, in coro
    |     await self.app(scope, receive_or_disconnect, send_no_error)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/cors.py", line 85, in __call__
    |     await self.app(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/exceptions.py", line 62, in __call__
    |     await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
    |     await app(scope, receive, sender)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 715, in __call__
    |     await self.middleware_stack(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 735, in app
    |     await route.handle(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 288, in handle
    |     await self.app(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 76, in app
    |     await wrap_app_handling_exceptions(app, request)(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
    |     await app(scope, receive, sender)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 74, in app
    |     await response(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 257, in __call__
    |     await wrap(partial(self.listen_for_disconnect, receive))
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 685, in __aexit__
    |     raise BaseExceptionGroup(
    | exceptiongroup.ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
    +-+---------------- 1 ----------------
      | Traceback (most recent call last):
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
      |     result = await app(  # type: ignore[func-returns-value]
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py", line 60, in __call__
      |     return await self.app(scope, receive, send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/fastapi/applications.py", line 1054, in __call__
      |     await super().__call__(scope, receive, send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/applications.py", line 113, in __call__
      |     await self.middleware_stack(scope, receive, send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 187, in __call__
      |     raise exc
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 165, in __call__
      |     await self.app(scope, receive, _send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
      |     response_sent.set()
      |   File "/usr/lib/python3.8/contextlib.py", line 131, in __exit__
      |     self.gen.throw(type, value, traceback)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 83, in collapse_excgroups
      |     raise exc
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
      |     await func()
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 242, in stream_response
      |     async for chunk in self.body_iterator:
      |   File "/home/user/vllm/vllm/entrypoints/openai/serving_completion.py", line 262, in completion_stream_generator
      |     async for prompt_idx, res in result_generator:
      |   File "/home/user/vllm/vllm/utils.py", line 506, in merge_async_iterators
      |     item = await d
      |   File "/home/user/vllm/vllm/engine/multiprocessing/client.py", line 598, in _process_request
      |     raise request_output
      | vllm.engine.multiprocessing.MQEngineDeadError: Engine loop is not running. Inspect the stacktrace to find the original error: TimeoutError('No heartbeat received from MQLLMEngine').
      +------------------------------------

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
    result = await app(  # type: ignore[func-returns-value]
  File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py", line 60, in __call__
    return await self.app(scope, receive, send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/fastapi/applications.py", line 1054, in __call__
    await super().__call__(scope, receive, send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/applications.py", line 113, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 187, in __call__
    raise exc
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 165, in __call__
    await self.app(scope, receive, _send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
    response_sent.set()
  File "/usr/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 83, in collapse_excgroups
    raise exc
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
    await func()
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 242, in stream_response
    async for chunk in self.body_iterator:
  File "/home/user/vllm/vllm/entrypoints/openai/serving_completion.py", line 262, in completion_stream_generator
    async for prompt_idx, res in result_generator:
  File "/home/user/vllm/vllm/utils.py", line 506, in merge_async_iterators
    item = await d
  File "/home/user/vllm/vllm/engine/multiprocessing/client.py", line 598, in _process_request
    raise request_output
vllm.engine.multiprocessing.MQEngineDeadError: Engine loop is not running. Inspect the stacktrace to find the original error: TimeoutError('No heartbeat received from MQLLMEngine').
CRITICAL 11-17 13:51:22 launcher.py:99] MQLLMEngine is already dead, terminating server process
INFO:     <IP_ADDRESS>:40756 - "POST /v1/completions HTTP/1.1" 500 Internal Server Error
INFO:     Shutting down
INFO:     Waiting for application shutdown.
INFO:     Application shutdown complete.
INFO:     Finished server process [1]

Possibly related to #35
Before submitting a new issue...

[x] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

Based on the log sent, it looks like the MQLLMEngineClient is not receiving a heartbeat in client.py::MQLLMEngineClient::run_heartbeat_loop from engine.py::MQLLMEngine::_heartbeat within timeout=VLLM_RPC_TIMEOUT. This indicates that the Engine is not sending an error or taking too many steps, but rather its _heartbeat_loop has died. It is possible that a hang has occurred and that this is related to https://github.com/tenstorrent/tt-metal/issues/15090 since that also resulted in TimeoutError('No heartbeat received from MQLLMEngine') (although it is not fully clear to me yet why a hang would kill the heartbeat thread). @tstescoTT please let me know if you are able to obtain more info from running with VLLM_LOGGING_LEVEL=DEBUG and if this is is also occurring with specific machines or clock frequencies.

Your hypothesis appears correct, another log in support below. I also don't understand how the heartbeat thread is getting killed, the entire MQLLMEngine process appears be getting terminated with server log MQLLMEngine is already dead sent during cleanup.
Here is a log running on f09cs03, 900 MHz firmware <IP_ADDRESS>, with VLLM_RPC_TIMEOUT=200000, and LLM_LOGGING_LEVEL=DEBUG. Heartbeat successful message every 40s (200/5) and TimeoutError after 200s:
2024-11-24 21:18:04.092 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 1
2024-11-24 21:18:04.264 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 2
2024-11-24 21:18:04.435 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 3
2024-11-24 21:18:04.606 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 4
2024-11-24 21:18:04.804 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 5
2024-11-24 21:18:04.975 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 6
2024-11-24 21:18:05.146 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 7
2024-11-24 21:18:05.316 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 8
2024-11-24 21:18:05.487 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 9
2024-11-24 21:18:05.658 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 10
2024-11-24 21:18:05.829 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 11
2024-11-24 21:18:06.000 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:316 - Filling kv cache for user 12
2024-11-24 21:18:06.197 | INFO     | models.demos.t3000.llama2_70b.tt.llama_generation:prefill_forward:330 - Finished prefill for all users up to 87 tokens, Starting decode...
INFO 11-24 21:18:06 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.7 tokens/s, Running: 12 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.7%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:11 metrics.py:396] Avg prompt throughput: 117.0 tokens/s, Avg generation throughput: 16.6 tokens/s, Running: 11 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 1.4%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:17 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 14.0 tokens/s, Running: 11 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 2.1%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:22 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 13.9 tokens/s, Running: 11 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 2.7%, CPU KV cache usage: 0.0%.
DEBUG 11-24 21:18:26 client.py:154] Heartbeat successful.
INFO 11-24 21:18:28 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 13.8 tokens/s, Running: 11 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 3.2%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:34 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 12.4 tokens/s, Running: 9 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 3.0%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:39 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 11.1 tokens/s, Running: 9 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 3.5%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:45 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 9.2 tokens/s, Running: 6 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 2.7%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:51 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 5.1 tokens/s, Running: 3 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 1.5%, CPU KV cache usage: 0.0%.
INFO 11-24 21:18:56 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 2.0 tokens/s, Running: 1 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.5%, CPU KV cache usage: 0.0%.
INFO 11-24 21:19:02 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 1.2 tokens/s, Running: 1 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.6%, CPU KV cache usage: 0.0%.
DEBUG 11-24 21:19:06 client.py:154] Heartbeat successful.
INFO 11-24 21:19:08 metrics.py:396] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 1.2 tokens/s, Running: 1 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.6%, CPU KV cache usage: 0.0%.
ERROR 11-24 21:22:26 client.py:250] TimeoutError('No heartbeat received from MQLLMEngine')
ERROR 11-24 21:22:26 client.py:250] NoneType: None
DEBUG 11-24 21:22:26 client.py:144] Shutting down MQLLMEngineClient check health loop due to timeout
DEBUG 11-24 21:22:31 client.py:170] Waiting for output from MQLLMEngine.
ERROR:    Exception in ASGI application
  + Exception Group Traceback (most recent call last):
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 188, in __call__
  |     await response(scope, wrapped_receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 222, in __call__
  |     async for chunk in self.body_iterator:
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 179, in body_stream
  |     raise app_exc
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 149, in coro
  |     await self.app(scope, receive_or_disconnect, send_no_error)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/cors.py", line 85, in __call__
  |     await self.app(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/exceptions.py", line 62, in __call__
  |     await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
  |     raise exc
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
  |     await app(scope, receive, sender)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 715, in __call__
  |     await self.middleware_stack(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 735, in app
  |     await route.handle(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 288, in handle
  |     await self.app(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 76, in app
  |     await wrap_app_handling_exceptions(app, request)(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
  |     raise exc
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
  |     await app(scope, receive, sender)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 74, in app
  |     await response(scope, receive, send)
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 257, in __call__
  |     await wrap(partial(self.listen_for_disconnect, receive))
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 685, in __aexit__
  |     raise BaseExceptionGroup(
  | exceptiongroup.ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
  +-+---------------- 1 ----------------
    | Traceback (most recent call last):
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
    |     result = await app(  # type: ignore[func-returns-value]
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py", line 60, in __call__
    |     return await self.app(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/fastapi/applications.py", line 1054, in __call__
    |     await super().__call__(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/applications.py", line 113, in __call__
    |     await self.middleware_stack(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 187, in __call__
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 165, in __call__
    |     await self.app(scope, receive, _send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
    |     response_sent.set()
    |   File "/usr/lib/python3.8/contextlib.py", line 131, in __exit__
    |     self.gen.throw(type, value, traceback)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 83, in collapse_excgroups
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
    |     await func()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 242, in stream_response
    |     async for chunk in self.body_iterator:
    |   File "/home/user/vllm/vllm/entrypoints/openai/serving_completion.py", line 262, in completion_stream_generator
    |     async for prompt_idx, res in result_generator:
    |   File "/home/user/vllm/vllm/utils.py", line 506, in merge_async_iterators
    |     item = await d
    |   File "/home/user/vllm/vllm/engine/multiprocessing/client.py", line 598, in _process_request
    |     raise request_output
    | vllm.engine.multiprocessing.MQEngineDeadError: Engine loop is not running. Inspect the stacktrace to find the original error: TimeoutError('No heartbeat received from MQLLMEngine').
    +------------------------------------

During handling of the above exception, another exception occurred:

  + Exception Group Traceback (most recent call last):
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 77, in collapse_excgroups
  |     yield
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
  |     response_sent.set()
  |   File "/tt-metal/python_env/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 685, in __aexit__
  |     raise BaseExceptionGroup(
  | exceptiongroup.ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
  +-+---------------- 1 ----------------
    | Traceback (most recent call last):
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 257, in __call__
    |     await wrap(partial(self.listen_for_disconnect, receive))
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
    |     await func()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 230, in listen_for_disconnect
    |     message = await receive()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 126, in receive_or_disconnect
    |     message = await wrap(wrapped_receive)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 121, in wrap
    |     result = await func()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 51, in wrapped_receive
    |     msg = await self.receive()
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 555, in receive
    |     await self.message_event.wait()
    |   File "/usr/lib/python3.8/asyncio/locks.py", line 309, in wait
    |     await fut
    | asyncio.exceptions.CancelledError
    |
    | During handling of the above exception, another exception occurred:
    |
    | Exception Group Traceback (most recent call last):
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 188, in __call__
    |     await response(scope, wrapped_receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 222, in __call__
    |     async for chunk in self.body_iterator:
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 179, in body_stream
    |     raise app_exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 149, in coro
    |     await self.app(scope, receive_or_disconnect, send_no_error)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/cors.py", line 85, in __call__
    |     await self.app(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/exceptions.py", line 62, in __call__
    |     await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
    |     await app(scope, receive, sender)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 715, in __call__
    |     await self.middleware_stack(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 735, in app
    |     await route.handle(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 288, in handle
    |     await self.app(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 76, in app
    |     await wrap_app_handling_exceptions(app, request)(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 62, in wrapped_app
    |     raise exc
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_exception_handler.py", line 51, in wrapped_app
    |     await app(scope, receive, sender)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/routing.py", line 74, in app
    |     await response(scope, receive, send)
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 257, in __call__
    |     await wrap(partial(self.listen_for_disconnect, receive))
    |   File "/tt-metal/python_env/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 685, in __aexit__
    |     raise BaseExceptionGroup(
    | exceptiongroup.ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
    +-+---------------- 1 ----------------
      | Traceback (most recent call last):
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
      |     result = await app(  # type: ignore[func-returns-value]
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py", line 60, in __call__
      |     return await self.app(scope, receive, send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/fastapi/applications.py", line 1054, in __call__
      |     await super().__call__(scope, receive, send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/applications.py", line 113, in __call__
      |     await self.middleware_stack(scope, receive, send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 187, in __call__
      |     raise exc
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 165, in __call__
      |     await self.app(scope, receive, _send)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
      |     response_sent.set()
      |   File "/usr/lib/python3.8/contextlib.py", line 131, in __exit__
      |     self.gen.throw(type, value, traceback)
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 83, in collapse_excgroups
      |     raise exc
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
      |     await func()
      |   File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 242, in stream_response
      |     async for chunk in self.body_iterator:
      |   File "/home/user/vllm/vllm/entrypoints/openai/serving_completion.py", line 262, in completion_stream_generator
      |     async for prompt_idx, res in result_generator:
      |   File "/home/user/vllm/vllm/utils.py", line 506, in merge_async_iterators
      |     item = await d
      |   File "/home/user/vllm/vllm/engine/multiprocessing/client.py", line 598, in _process_request
      |     raise request_output
      | vllm.engine.multiprocessing.MQEngineDeadError: Engine loop is not running. Inspect the stacktrace to find the original error: TimeoutError('No heartbeat received from MQLLMEngine').
      +------------------------------------

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 401, in run_asgi
    result = await app(  # type: ignore[func-returns-value]
  File "/tt-metal/python_env/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py", line 60, in __call__
    return await self.app(scope, receive, send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/fastapi/applications.py", line 1054, in __call__
    await super().__call__(scope, receive, send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/applications.py", line 113, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 187, in __call__
    raise exc
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/errors.py", line 165, in __call__
    await self.app(scope, receive, _send)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/middleware/base.py", line 189, in __call__
    response_sent.set()
  File "/usr/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/_utils.py", line 83, in collapse_excgroups
    raise exc
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 253, in wrap
    await func()
  File "/tt-metal/python_env/lib/python3.8/site-packages/starlette/responses.py", line 242, in stream_response
    async for chunk in self.body_iterator:
  File "/home/user/vllm/vllm/entrypoints/openai/serving_completion.py", line 262, in completion_stream_generator
    async for prompt_idx, res in result_generator:
  File "/home/user/vllm/vllm/utils.py", line 506, in merge_async_iterators
    item = await d
  File "/home/user/vllm/vllm/engine/multiprocessing/client.py", line 598, in _process_request
    raise request_output
vllm.engine.multiprocessing.MQEngineDeadError: Engine loop is not running. Inspect the stacktrace to find the original error: TimeoutError('No heartbeat received from MQLLMEngine').
CRITICAL 11-24 21:22:31 launcher.py:99] MQLLMEngine is already dead, terminating server process
INFO:     <IP_ADDRESS>:32788 - "POST /v1/completions HTTP/1.1" 500 Internal Server Error
CRITICAL 11-24 21:22:31 launcher.py:99] MQLLMEngine is already dead, terminating server process
INFO:     <IP_ADDRESS>:32792 - "POST /v1/completions HTTP/1.1" 500 Internal Server Error
CRITICAL 11-24 21:22:31 launcher.py:99] MQLLMEngine is already dead, terminating server process
INFO:     <IP_ADDRESS>:32804 - "POST /v1/completions HTTP/1.1" 500 Internal Server Error
INFO:     Shutting down
CRITICAL 11-24 21:22:31 launcher.py:99] MQLLMEngine is already dead, terminating server process
INFO:     <IP_ADDRESS>:32826 - "POST /v1/completions HTTP/1.1" 500 Internal Server Error
INFO:     Waiting for application shutdown.
INFO:     Application shutdown complete.
INFO:     Finished server process [28189]
(python_env) user@1345a0893276:~/app/src$ /usr/lib/python3.8/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: There appear to be 1 leaked semaphore objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '

(python_env) user@1345a0893276:~/app/src$

Okay, so it does look like the model hangs in either prefill or decode based on the two logs sent. Does this occur with other cloud machines at 900 MHz? I am trying to understand whether this could be a duplicate of https://github.com/tenstorrent/cloud/issues/3217 since @milank94 mentioned that some machines were hanging with 900 MHz already.

Ya I think you're right, because f09cs03 has known issues causing failure, https://github.com/tenstorrent/cloud/issues/3217 is likely the root cause. I wasn't able to reproduce this on f10cs01.
I'll close this issue for now until we see it reproduced on a machine without other known issues.
Still of note that it still isnt clear why the MQLLMEngine is being killed.


Replace deprecated textEditingValue method

As far as I can see, userUpdateTextEditingValue is called inside the _handleSelectionHandleChanged -> onSelectionHandleChanged -> _handleDragUpdate method. Therefore I think the SelectionChangedCause should be drag instead of keyboard. WDYT?

You are correct. Thx!


pull request for e2e test at 11/23/2016 06:56:04

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


fix: set correct nextest config

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Review comments for #306

As a < type of user >, I want < some goal > so that < some reason >
Review comments need to fix for https://github.com/devonfw/my-thai-star/pull/306

Not valid anymore as we have updated MTS to latest devon4j version 2021.04.002


Add label documenations

closes #304.
Adds reminder to use labels to CONTRIBUTING.md.
Adds a link to a newly created wiki page about when to use which label.

I also restructured steps 7, 8 and 9 a bit because just the changelog, not the term tracker got a reminder to be commited and that sounded unfair


C: hadoop-project hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-auth-examples hadoop-common-project/hadoop-common hadoop-common-project/hadoop-nfs hadoop-common-project/hadoop-kms hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-httpfs hadoop-hdfs-project/hadoop-hdfs-nfs hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-applicationhistoryservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-web-proxy hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client hadoop-mapreduce-project/hadoop-mapreduce-client hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs hadoop-hdfs-project/hadoop-hdfs-rbf hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/hadoop-yarn-server-timelineservice-hbase-client hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/hadoop-yarn-server-timelineservice-hbase-server/hadoop-yarn-server-timelineservice-hbase-server-2 hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase-tests hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-router hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-documentstore hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-globalpolicygenerator hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-services/hadoop-yarn-services-core hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-services/hadoop-yarn-services-api hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp hadoop-yarn-project/hadoop-yarn/hadoop-yarn-csi hadoop-mapreduce-project/hadoop-mapreduce-examples hadoop-client-modules/hadoop-client hadoop-tools/hadoop-azure hadoop-tools/hadoop-resourceestimator hadoop-client-modules/hadoop-client-api hadoop-client-modules/hadoop-client-runtime hadoop-client-modules/hadoop-client-check-invariants hadoop-client-modules/hadoop-client-minicluster hadoop-client-modules/hadoop-client-integration-tests hadoop-cloud-storage-project/hadoop-huaweicloud hadoop-cloud-storage-project/hadoop-cloud-storage U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6707/26/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2 shellcheck=0.7.0

Powered by
Apache Yetus 0.14.1 https://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6707/27/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m  0s

Docker mode activated.

-1 :x:
docker
18m 16s

Docker failed to build run-specific yetus/hadoop:tp-17624}.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hadoop/pull/6707

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6707/27/console

versions
git=2.34.1

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6707/28/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 45s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 50s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
37m 12s

trunk passed

+1 :green_heart:
compile
19m  8s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
compile
17m 37s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
mvnsite
23m 44s

trunk passed

+1 :green_heart:
javadoc
9m  2s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
7m 42s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
55m  9s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 34s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
35m  1s

the patch passed

+1 :green_heart:
compile
18m 34s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javac
18m 34s

the patch passed

+1 :green_heart:
compile
17m 11s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
javac
17m 11s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
hadolint
0m  8s

No new issues.

+1 :green_heart:
mvnsite
17m 55s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
9m 26s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
7m 42s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
57m  1s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
848m 34s
/patch-unit-root.txt
root in the patch passed.

+1 :green_heart:
asflicense
1m 34s

The patch does not generate ASF License warnings.

1168m  7s

Reason
Tests

Failed junit tests
hadoop.yarn.server.timelineservice.security.TestTimelineAuthFilterForV2

hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageDomain

hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesHBaseStorage

hadoop.yarn.server.timelineservice.storage.TestTimelineWriterHBaseDown

hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageEntities

hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageApps

hadoop.yarn.server.timelineservice.storage.TestTimelineReaderHBaseDown

hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowRun

hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowRunCompaction

hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowActivity

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6707/28/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6707

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit compile javac javadoc mvninstall shadedclient xmllint

uname
Linux 56727f52fd9a 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ce3e21a7b92516b6d6b9f8d24549f30c26795c16

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6707/28/testReport/

Max. process+thread count
3842 (vs. ulimit of 5500)

modules
C: hadoop-project . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6707/28/console

versions
git=2.25.1 maven=3.6.3 hadolint=1.11.1-0-g0e692dd shellcheck=0.7.0

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


[Federation] Setting up CoreDNS as DNS provider for Cluster Federation

Addresses and Fixes: #2197
CoreDNS chart is not merged yet into helm charts. https://github.com/kubernetes/charts/pull/785
Request to keep this on hold until it is merged.
cc @madhusudancs @kubernetes/sig-federation-misc

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, 14 unresolved discussions.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 28 at r1 (raw file):

To deploy CoreDNS we shall make use of helm charts. CoreDNS will be
deployed with Etcd as the backend and should be pre-installed. Etcd

etcd is usually spelled with a lower case e. Also, please link to their website - https://coreos.com/etcd
Same comments for all other occurrences.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 33 at r1 (raw file):

```shell
$ helm install --name etcd-operator --namespace ns stable/etcd-operator

Can we use a better, more descriptive namespace?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 41 at r1 (raw file):

After deployment succeeds, Etcd can be accessed with
"http://etcd-cluster:2379" endpoint within the host cluster.

Remove the quotes and just linkify the URL.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 44 at r1 (raw file):

CoreDNS default configuration should be customized to suit federation
and shown below is the Values.yaml, which overrides the default

Link to the default Values.yaml file?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 64 at r1 (raw file):

 - `isClusterService` specifies whether CoreDNS should be deployed as
cluster-service, which is default. You need to set it to false, so that
CoreDNS is deployed as kubernetes application service.

What's the difference between the two types? I am not sure I know the distinction.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 70 at r1 (raw file):

cluster.
 - Disable `middleware.kubernetes`, which is enabled by default by
setting `middleware.kubernetes.enabled` to false.

Do CoreDNS users understand this configuration? I don't know much about CoreDNS and I can't say whether I want this or not.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 72 at r1 (raw file):

setting `middleware.kubernetes.enabled` to false.
 - Enable `middleware.etcd` by setting `middleware.etcd.enabled` to
true.

Same as above.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 89 at r1 (raw file):

Federation control plane can be deployed using `kubefed init`. CoreDNS
can be chosen as DNS provider by specifying two additional parameters.

It is probably worth mentioning that middleware.etcd.zones and --dns-zone-name flag to kubefed init should match.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 98 at r1 (raw file):

```shell
[Global]
etcd-endpoints = http://etcd-cluster.ns:2379

I would make the host name part consistent. I understand why you are doing this. But I think it is worth making it consistent everywhere. Using etcd-cluster.ns everywhere isn't harmful right?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 99 at r1 (raw file):

[Global]
etcd-endpoints = http://etcd-cluster.ns:2379
zones = example.com

Trailing dot for consistency as we did here - https://github.com/kubernetes/kubernetes.github.io/pull/2899#pullrequestreview-27716728

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 103 at r1 (raw file):

 - `etcd-endpoints` is the endpoint to access Etcd.
 - `zones` is the federation domain for which CoreDNS is authoritative.

and say "which is same as --dns-zone-name"

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 105 at r1 (raw file):

 - `zones` is the federation domain for which CoreDNS is authoritative.

## Setup CoreDNS server in nameserver resolv chain

resolv.conf chain?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 109 at r1 (raw file):

Once the federation control plane is deployed and federated clusters
are joined to the federation, you need to add the CoreDNS server to
pod's nameserver resolv chain in all the federated clusters as this

resolv.conf chain?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 115 at r1 (raw file):

```shell
        - --server=/example.com/<CoreDNS endpoint>

Is it not possible to use the kube-dns ConfigMap for this yet?

Comments from Reviewable

@madhusudancs, Handled review comments. PTAL

Review status: 1 of 2 files reviewed at latest revision, 14 unresolved discussions.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 28 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
etcd is usually spelled with a lower case e. Also, please link to their website - https://coreos.com/etcd
Same comments for all other occurrences.

ok. Done

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 33 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Can we use a better, more descriptive namespace?

used my-namespace instead of ns

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 41 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Remove the quotes and just linkify the URL.

removed the quotes

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 44 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Link to the default Values.yaml file?

CoreDNS chart is not merged yet, so the link would not be stable if i link it to PR. On the other hand Values.yaml in helm charts is well known, so i think user should not have any difficulty finding out the default configuration given the chart.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 64 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
What's the difference between the two types? I am not sure I know the distinction.

CoreDNS chart can be deployed basically as 2 variants.

if isClusterService is true, then CoreDNS is deployed similar to kube-dns addon.
if isClusterService is false, then CoreDNS is deployed as any other k8s app.

they basically differ in labels and annotations.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 70 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Do CoreDNS users understand this configuration? I don't know much about CoreDNS and I can't say whether I want this or not.

CoreDNS users do understand about the middleware. I had given the reference Values.yaml above which can be used to deploy CoreDNS for federation dns server. This explanation is just to let know the user of the configuration details and i believe whoever wants to tweak the configuration would know how to fit it to their needs.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 72 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Same as above.

Same as previous reply

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 89 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
It is probably worth mentioning that middleware.etcd.zones and --dns-zone-name flag to kubefed init should match.

Added a Note

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 98 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
I would make the host name part consistent. I understand why you are doing this. But I think it is worth making it consistent everywhere. Using etcd-cluster.ns everywhere isn't harmful right?

Agree, used etcd-cluster.my-namespace everywhere

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 99 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Trailing dot for consistency as we did here - https://github.com/kubernetes/kubernetes.github.io/pull/2899#pullrequestreview-27716728

Done

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 103 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
and say "which is same as --dns-zone-name"

Added.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 105 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
resolv.conf chain?

Changed. Done

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 109 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
resolv.conf chain?

Changed. Done

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 115 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Is it not possible to use the kube-dns ConfigMap for this yet?

kube-dns ConfigMap in the current release cannot handle nameserver listening on any port other than 53. I did a PR to specify port for nameserver, but that would be included in subsequent releases.
If CoreDNS is deployed as NodePort service. than it will be accessible on some random port which cannot be configured using kube-dns ConfigMap method.

Comments from Reviewable

Madhu -- can you lgtm the changes if they look good to you?

@madhusudancs, the CoreDNS helm chart PR is merged now. request a LGTM from you. is the fixes ok?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 99 at r2 (raw file):

[Global]
etcd-endpoints = http://etcd-cluster.my-namespace:2379
zones = example.com.

Does the user need to own this domain name? (In the light of https://github.com/kubernetes/kubernetes/issues/43599)

Comments from Reviewable

@shashidharatd a few minor comments.

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 33 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
used my-namespace instead of ns

I would have preferred a descriptive one. Something like dns or coredns, but this is good enough.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 41 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
removed the quotes

Can you please linkify this so that people following the doc can just click the link? [http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379)

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 44 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
CoreDNS chart is not merged yet, so the link would not be stable if i link it to PR. On the other hand Values.yaml in helm charts is well known, so i think user should not have any difficulty finding out the default configuration given the chart.

Ok, fair enough.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 64 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
CoreDNS chart can be deployed basically as 2 variants.

if isClusterService is true, then CoreDNS is deployed similar to kube-dns addon.
if isClusterService is false, then CoreDNS is deployed as any other k8s app.

they basically differ in labels and annotations.

Oh I see what you mean. This defines whether the deployment is a cluster component. Is that right? Could you please clarify this in the doc. It is not clear right now.
If that's the case, should users care about it? What are the pros and cons?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 70 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
CoreDNS users do understand about the middleware. I had given the reference Values.yaml above which can be used to deploy CoreDNS for federation dns server. This explanation is just to let know the user of the configuration details and i believe whoever wants to tweak the configuration would know how to fit it to their needs.

Ok, cool.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 72 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
Same as previous reply

Ack.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 115 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
kube-dns ConfigMap in the current release cannot handle nameserver listening on any port other than 53. I did a PR to specify port for nameserver, but that would be included in subsequent releases.
If CoreDNS is deployed as NodePort service. than it will be accessible on some random port which cannot be configured using kube-dns ConfigMap method.

I see. Do you think it is worth documenting both these techniques along with your explanation above?

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 99 at r2 (raw file):
Previously, clenimar (Clenimar Filemon) wrote…
Does the user need to own this domain name? (In the light of https://github.com/kubernetes/kubernetes/issues/43599)

Not necessary if you are using CoreDNS as the DNS provider. However, it is the user's (read: cluster operator's) responsibility to

Appropriately configure cluster's kube-dns to forward all requests to example.com. to CoreDNS.
Make CoreDNS the authoritative server for example.com.
Ensure external clients reach CoreDNS for the DNS queries for example.com..

Comments from Reviewable

@madhusudancs, have tried adressing your comments. PTAL

Review status: 0 of 2 files reviewed at latest revision, 6 unresolved discussions.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 33 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
I would have preferred a descriptive one. Something like dns or coredns, but this is good enough.

Using something like coredns might have confused, since the keyword is used for other purposes also.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 41 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Can you please linkify this so that people following the doc can just click the link? [http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379)

oh, i misunderstood the comment. Fixed Now.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 64 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
Oh I see what you mean. This defines whether the deployment is a cluster component. Is that right? Could you please clarify this in the doc. It is not clear right now.
If that's the case, should users care about it? What are the pros and cons?

For federation use case. CoreDNS has to be deployed as normal k8s app and this is not default while installing helm chart. So i have given the overriding configuration to deploy CoreDNS as a normal k8s app with etcd as middleware.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 115 at r1 (raw file):
Previously, madhusudancs (Madhusudan.C.S) wrote…
I see. Do you think it is worth documenting both these techniques along with your explanation above?

Once the kube-dns configuration related PR is merged and available to users. users need not do this manual configuration at all. we should remove this section in future. So i feel we should leave out those details which we do take care of.

Comments from Reviewable

Reviewed 2 of 2 files at r3.
Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 33 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
Using something like coredns might have confused, since the keyword is used for other purposes also.

Fair enough.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 64 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
For federation use case. CoreDNS has to be deployed as normal k8s app and this is not default while installing helm chart. So i have given the overriding configuration to deploy CoreDNS as a normal k8s app with etcd as middleware.

Ok makes sense.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 115 at r1 (raw file):
Previously, shashidharatd (Shashidhara T D) wrote…
Once the kube-dns configuration related PR is merged and available to users. users need not do this manual configuration at all. we should remove this section in future. So i feel we should leave out those details which we do take care of.

Ok.

Comments from Reviewable

@devin-donnelly @chenopis @jaredbhatti could you please take a look?

@shashidharatd this is also needs a rebase.

@madhusudancs, sorry for the delay. rebased now

Hello @shashidharatd, I tried helm install --name etcd-operator stable/etcd-operator (with and without the --namespace flag) unsuccessfully. Do you know any reason for that?
Error: release etcd-operator failed: the server does not allow access to the requested resource (get namespaces default)

Hello @arthur0,
I am able to install the chart with/without namespace successfully. i am suspecting you are having issue with RBAC settings in your k8s cluster.
Anyway it would be good to post this issue in https://github.com/kubernetes/charts instead of here. there would be more users/developers to help out.

Another possibility: federation doesn't create a default namespace. The failing "gets" suggest that might be the case.

@chenopis, i have addressed your comments. PTAL

Review status: 1 of 3 files reviewed at latest revision, 21 unresolved discussions.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 6 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
If you could please use the Tutorial Template, that would really help us out. Thanks!

I have used the template now. PTAL

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 11 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the" before "DNS provider..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 13 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
"configuration" -> "configurations"

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 14 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
The sentence "In this guide..." is redundant and can be removed because the points it makes are already mentioned above.

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 27 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add comma: "To deploy CoreDNS, we shall..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 29 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
"etcd also can be deployed..." -> "etct can also be deployed..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 40 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the": "...can be accessed with..." -> "...can be accessed with the..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 43 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the": "The CoreDNS default..." and "...customized to suit the federation."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 44 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
start a new sentence: "...suit the federation. Shown below is..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 45 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the": "...on the CoreDNS chart."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 63 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "a" and "the": "a cluster-service, which is the default."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 64 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "a," capitalize Kubernetes: "...deployed as a Kubernetes application service."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 65 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
capitalize Kubernetes everywhere

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 66 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
Suggested wording:
You need to choose either "LoadBalancer" or "NodePort" to make the CoreDNS service accessible outside the Kubernetes cluster.

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 88 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the": "The Federation control plane..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 89 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the": "...can be chosen as the DNS provider..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 111 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the": "...the pod's nameserver..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 122 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
add "the": "...server to the pod's nameserver..."

Done.

docs/tutorials/federation/set-up-coredns-provider-federation.md, line 126 at r3 (raw file):
Previously, chenopis (Andrew Chen) wrote…
typo and remove extra space: "...cross-cluster service discovery!"

Done.

Comments from Reviewable

/lgtm @shashidharatd @madhusudancs Anything else before I merge this?

loogs good to me. @madhusudancs PTAL one final time.
Thanks

@chenopis @shashidharatd looks good to me too. Go go go!

@chenopis, @madhusudancs, This document should be available for 1.6, should i raise to release-1.6 branch also?

Note that using ServiceType = "LoadBalancer"  gives this result:
Error: release coredns failed: Service "coredns-coredns" is invalid: spec.ports: Invalid value: [{"name":"dns","protocol":"UDP","port":53,"targetPort":53,"nodePort":0},
{"name":"dns-tcp","protocol":"TCP","port":53,"targetPort":53,"nodePort":0}]: cannot create an external load balancer with mix protocols
Using ServiceType = "NodePort" seems to be necessary if you want to support both TCP and UDP.

@chrisjones262, on what cloud provider are you seeing the above issue?
Request you to file an issue in https://github.com/kubernetes/charts
AFAIK, there seems to be a bug in GCE loadbalancer, which does not allow to create a loadbalancer with same port for UDP & TCP. Are you by chance using GCE?
I hope this problem does not exist on other cloud providers like AWS or openstack

It is on Azure Container Service.   I would guess it’s cloud-provider independent.
From: Shashidhara T D<EMAIL_ADDRESS>Sent: Friday, April 14, 2017 10:34 AM
To: kubernetes/kubernetes.github.io<EMAIL_ADDRESS>Cc: Christopher Jones (MCS<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [kubernetes/kubernetes.github.io] [Federation] Setting up CoreDNS as DNS provider for Cluster Federation (#2810)
@chrisjones262https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchrisjones262&data=02|01|cjones%40microsoft.com|c5b3ceb90d854dd39a8008d483434911|72f988bf86f141af91ab2d7cd011db47|1|0|636277772391055382&sdata=hmgRRv3WKeKFQtyo9nTGucRUGvCUFJRIAxpBg6nCNMY%3D&reserved=0, on what cloud provider are you seeing the above issue?
Request you to file an issue in https://github.com/kubernetes/chartshttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fcharts&data=02|01|cjones%40microsoft.com|c5b3ceb90d854dd39a8008d483434911|72f988bf86f141af91ab2d7cd011db47|1|0|636277772391055382&sdata=wcWxMsRhQQ%2FsPVzf7iH1%2FFOfqriIgI0isex4s3zKDAc%3D&reserved=0
AFAIK, there seems to be a bug in GCE loadbalancer, which does not allow to create a loadbalancer with same port for UDP & TCP. Are you by chance using GCE?
I hope this problem does not exist on other cloud providers like AWS or openstack
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fkubernetes.github.io%2Fpull%2F2810%23issuecomment-294164044&data=02|01|cjones%40microsoft.com|c5b3ceb90d854dd39a8008d483434911|72f988bf86f141af91ab2d7cd011db47|1|0|636277772391055382&sdata=dhpOmzV9W54mH%2BR4fn9lpdRJa%2F%2Fslet6UiOfUxzE%2FwU%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJt1ZZBA8H9d_2JC_1diaT_9VYID6YsFks5rv4PUgaJpZM4MdAO2&data=02|01|cjones%40microsoft.com|c5b3ceb90d854dd39a8008d483434911|72f988bf86f141af91ab2d7cd011db47|1|0|636277772391055382&sdata=eI22HjmNMoXcJVwP8qdHM4Ro%2BgiLnapiF90fNb2tth0%3D&reserved=0.

@shashidharatd Since 1.6 was already released, I can merge this directly into master. Once you think the issue w/ @chrisjones262 is sufficiently resolved, I will merge this. Cheers

@chrisjones262, interesting to know that loadbalancers in 'Azure Container Service' also has similar characteristics as that GCE loadbalancers. We can just start the service to listen either on TCP or UDP in that case and think about implications for DNS server. I would request you to file this issue in https://github.com/kubernetes/charts as the fix need to go in that repo for CoreDNS helm chart.

@chenopis, just curious, can this documentation be part of 1.6.2 patch release? Does the hosted https://kubernetes.io reflect the changes done to patch release?
I wish that this documentation is merged and visible to greater audience ASAP, if it has to go in 1.7 release then we need to wait for another quarter.
Also the issue raised by @chrisjones262, affect subset of environments. IMHO, we should not hold back this documentation pr for that issue as there is no change required here. that issue is being addressed in https://github.com/kubernetes/charts/pull/928 and would take its own time to merge and is independent of kubernetes release cycles. @chrisjones262 do you agree?

@shashidharatd As long as that issue is being addressed, I'm fine w/ merging this now. Thx

Sorry for the delay.  I agree.
From: Shashidhara T D<EMAIL_ADDRESS>Sent: Sunday, April 16, 2017 11:58 PM
To: kubernetes/kubernetes.github.io<EMAIL_ADDRESS>Cc: Christopher Jones (MCS<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [kubernetes/kubernetes.github.io] [Federation] Setting up CoreDNS as DNS provider for Cluster Federation (#2810)
@chenopishttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchenopis&data=02|01|cjones%40microsoft.com|62c68095ab5f4b35d83408d48545fa46|72f988bf86f141af91ab2d7cd011db47|1|0|636279983009613773&sdata=gkiMGeqhYtlTm53yYH%2FCPAkTBp2MKHx2kPlSWT1YiHE%3D&reserved=0, just curious, can this documentation be part of 1.6.2 patch release? Does the hosted https://kubernetes.iohttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkubernetes.io&data=02|01|cjones%40microsoft.com|62c68095ab5f4b35d83408d48545fa46|72f988bf86f141af91ab2d7cd011db47|1|0|636279983009613773&sdata=4fTbdnMdmm%2BI0xZ2o%2BEZK4CJDR99%2F9SnBBGrT4Sqgpo%3D&reserved=0 reflect the changes done to patch release?
I wish that this documentation is merged and visible to greater audience ASAP, if it has to go in 1.7 release then we need to wait for another quarter.
Also the issue raised by @chrisjones262https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchrisjones262&data=02|01|cjones%40microsoft.com|62c68095ab5f4b35d83408d48545fa46|72f988bf86f141af91ab2d7cd011db47|1|0|636279983009613773&sdata=0jPj%2Fcx1JWZ8AQquHWff1jWG4dL7QEyOs2XsvgNSOxE%3D&reserved=0, affect subset of environments. IMHO, we should not hold back this documentation pr for that issue as there is no change required here. that issue is being addressed in kubernetes/charts#928https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fcharts%2Fpull%2F928&data=02|01|cjones%40microsoft.com|62c68095ab5f4b35d83408d48545fa46|72f988bf86f141af91ab2d7cd011db47|1|0|636279983009613773&sdata=VX8lB4MlKxzBrX4boGyizHLtns1uG1FGwU4DdCWDAnE%3D&reserved=0 and would take its own time to merge and is independent of kubernetes release cycles. @chrisjones262https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchrisjones262&data=02|01|cjones%40microsoft.com|62c68095ab5f4b35d83408d48545fa46|72f988bf86f141af91ab2d7cd011db47|1|0|636279983009613773&sdata=0jPj%2Fcx1JWZ8AQquHWff1jWG4dL7QEyOs2XsvgNSOxE%3D&reserved=0 do you agree?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fkubernetes.github.io%2Fpull%2F2810%23issuecomment-294400647&data=02|01|cjones%40microsoft.com|62c68095ab5f4b35d83408d48545fa46|72f988bf86f141af91ab2d7cd011db47|1|0|636279983009613773&sdata=VnvC%2Fi0J02gWd6qCW%2BgoYRQFIvUvJLfEGoLc9YJ6YpY%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJt1ZbD5xaQoZQ00gq8Qj7kW85uJm61kks5rwuNXgaJpZM4MdAO2&data=02|01|cjones%40microsoft.com|62c68095ab5f4b35d83408d48545fa46|72f988bf86f141af91ab2d7cd011db47|1|0|636279983009613773&sdata=xAbV2hnBtMagAvfR3pA3LUgtQjIF3Ehawlp9iO0tASU%3D&reserved=0.


Add debug information to release builds & more optimization

Otherwise debugging in release mode doesn't provide the corresponding source code in gdb.
Also optimizes more, so that the release build is as small as possible

Looking good, thank you!


change 'from' filter to 'gw' filter for cross-subnet check

Description
Description
This is a bug fix.
When enable route reflector in a cluster and enable IPinIP in cross-subnet mode, the calico couldn't work correctly.No mater the calico/nodes were in a same subnet or different subnets, they all communicate with other calico/nodes by IPinIP.
The calico/nodes do cross-subnet check by the 'from' filter. When enable route reflector, the 'from' filter would get the route reflector's IP address not the calico/node's IP address, so we should use the 'gw' filter instead of the 'from' filter.
Tests
I have tested this fix on my private cluster(both for with route reflector and without route reflector). The calico/nodes in my cluster can create route rules for each node correctly. Only the calico/nodes in different subnet communicate by IPinIP.
I do not test this fix on any public cloud, please test it if necessary.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.llr seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.llr seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Missing X11 on MacOS Big Sur

Thats it, there is a way around it ?
Edit (Apple MacBook Air m1 macOS v 11.2.3 (20D91))

I'm sorry, there is not yet any support for MacOS in any of the versions of this framework.
The old C++17 version of the framework had support for Windows and incomplete support for Linux. I have abandoned the C++17 version of the framework and started working on re-writing the whole thing in C++20 with a new and better design. I am planning to add support for MacOS. The current plan is to implement the new windowing module on all three platforms. I have started with Linux.

Oh okay, there is no problem, thanks :)


OS type lacks a space in the naming.

Bug Description:
When running neofetch.exe via cmd, the OS type lacks a space in the naming.
General Information:

Neofetch Version:
neofetch-win version v1.0.3

OS (Version):
Windows 11 Pro for Workstations [64-Bit]
Version 22H2 (Build 22621.1265)

Screenshot

fixed in v1.1.0


Merge master into next-major

This is the PR that disabled the Marklogic tests: https://github.com/quasar-analytics/quasar/pull/2632/files

@jsantos17 ah interesting. next-major already had the commits from that PR. But somehow the union.test didn't get updated. I'll add a separate commit to this PR to disable it for marklogic_xml.
I also checked and all the other tests that were disabled for ML in that PR are disabled already in next-major. So updates to union.test just got lost in the previous merge.

Ooo awesome, for spark we have:
[error] x select reduction from nested select [./demo/nestedSelectWithReduce.test] (2 seconds, 896 ms)
[error]  Fixed now, you should remove the 'pendingUntilFixed' marker (QuasarSpecification.scala:75)

I'll push a change enabling that!

@jsantos17 this should be good to go now!


Skip correct Collection<string, Training> fixture

@yguedidi here the fixture, it correctly skipped
Ref https://github.com/rectorphp/rector-doctrine/pull/359#issuecomment-2557908186

@TomasVotruba I am merging this fixture for proof to skip valid Collection<string, Training>

you're awesome @samsonasik thanks! now I need to upgrade to Rector 2.0 😁

is it also correctly skipped when the property is typed ? This was definitely not skipped for us in Rector 1.2.10 (the absence of tags in this repo makes it hard to know what was part of 1.2.10 vs 2.0)


Add support for grub2-mkconfig on Mariner

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[X] The toolchain has been rebuilt successfully (or no changes were made to it)
[X] The toolchain/worker package manifests are up-to-date
[X] Any updated packages successfully build (or no packages were changed)
[ ] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[X] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[X] All package sources are available
[X] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[X] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[X] All source files have up-to-date hashes in the *.signatures.json files
[X] sudo make go-tidy-all and sudo make go-test-coverage pass
[X] Documentation has been updated to match any changes to the build system
[X] Ready to merge

Summary

Today, when managing grub config files via the official grub toolchain, (grub2-mkconfig), it updates and replaces the existing  /boot/grub/grub.cfg that is laid out by the initial installer, in turn if a user was to use the official tool that is expected to work on other distros on Mariner, the user would be left with an unbootable system. Essentially the official toolchain that people have come to expect is not compatible withs Mariner.  This commit brings support for the industry default tool chain used to manage grub configs.
Change Log

Made grub tools grub2-mkconfig workable with Mariner grub install

Does this affect the toolchain?

NO
Associated issues

#xxxx

Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXX

Test Methodology

Build Grub2 package on a mariner system with my changes
confirmed flle /etc/default/grub was written out with defaults
ran grub2-mkconfig
rebooted system
System came up fine

Not actually sure why the spec lint fails. It runs fine on my build machine


Cestoda updates

About the PR
Downgraded the guns
2 AKMS -> 4 kardashev mosins
added a couple bowls
removes 1 catwalk
removed the hidden wt550
replaced the pilot's coffee with energy drinks, they need it
filled the ale bottle in the booze closet because i didnt realized it was empty
re-canonized the lore note by changing one word
Why / Balance
rain asked for worse guns, then i started fixing stuff myself

integration test fails unrelated to any mapping stuff


remove dead link

Nobody seems to know what this is meant to link to. Plus, as far as I can tell this is the only page on which we talk about metrics, so we don't really need a link.

Note that this is already broken in the 2.6.5 docs though the page it's trying to link to does exist in 2.6.5, but apparently got merged at some point in the 2.7 line.

cc @benm-da @michael-godfrey-da who have both reported this.


Disable File Field option from Application Form fields in the WagTail Admin

Description
Hiya @sandeepsajan0
There are now two stream fields for uploading files, "File field" and "Multiple file field".

[ ] Please disable the "File field" as an option when users are creating forms in WagTail. Providing only the "Multiple file field" should be sufficient.
[ ] Set a maximum allowable file size to double the usual size uploaded to each form
[ ] Use "File field" icon for "Multiple file field"

Image 1: Field Icons side-by-side

Image 2: Form Field options when creating a form

Instead add a setting on "Multiple file field" to set how many fields are allowed. 1-10 or unlimited are my suggestion for options.

My input is the "set how many fields are allowed" is low priority as I think it would be difficult to predict this usage.

Or is it never needed to limit the number of uploads? If that is the case the new setting is not needed.

I agree - for now the new setting of "how many fields are allowed" is not needed.
This could be handled with some simple content:

"please upload [the description of the single file you want to see], e.g. "please upload your CV"
"please upload [the description of the files you want to see], e.g. "please upload the CVs of your team members"

Could we close because it falls under an overarching issue of  #2275

@fourthletter how is it connected to that? (Not sure I follow!)

 It's unrelated. I thought #2275 was about having preset templates for creating new application forms in WagTail.

Or is it never needed to limit the number of uploads? If that is the case the new setting is not needed.

I recently started creating new applications for Funds, and see a value in limiting how many documents an applicant could upload at any one time. However, I'm willing to leave this up to standard best practice.
A secondary issue are the icons for "File field" on "Multiple file field" are unclear to users.

Are there any objections to the following:

removing the single file upload,
keeping the multiple file upload and then
deal with the maximum file upload limit in content

This would be the best experience for users and simplest to implement (I think!).
If this doesn't work, then we can implement some max. file limit control.
Objections?

@sandeepsajan0 this may seem like a minor issue, but this upload field has plagued many users for centuries.

[ ] removing the single file upload,
[ ] keeping the multiple file upload and then
[ ] deal with the maximum file upload limit in content

Example: This could be handled with some simple content:
"please upload [the description of the upload field you want to see], e.g. "please upload your CV"
"please upload [the description of the upload field you want to see], e.g. "please upload the CVs of your team members"

Standup April 21 - thank you @sandeepsajan0 for your question
During standup we decided the best course of action moving forward is to disable the "File field" as an option when users are creating forms in WagTail. Providing only the "Multiple file field" should be sufficient.
We cannot remove the single file block code because existing forms associated with Funds/Labs are using this field. Disabling this field so it does not show up as a field will prevent this field from being added to forms in the future.

Standup April 26
During we discussed the technical debt for continuing to work on this issue, and the potential benefit of removing the single finle upload button.

Looks great! Thank you @sandeepsajan0 💯


unknown voting mode

If one tries to start a voting for an assignment poll with the pollmethod votes the votecolletor raises an Unknown voting mode. error. Check this.

Yes, unknown voting mode is no longer raised. The "Start election" button will only be visible for voting modes supported by the votecollector.


RF: Do sensor-level group average via mne.grand_average()

This works thanks to a fix in mne-python:master that will be included in 0.19: https://github.com/mne-tools/mne-python/pull/6711
So this PR should probably only be merged after mne-python 0.19 has been released?

thx @hoechenberger
this breaks a test though. 2 options:

fix mne
fix the code here by avoiding to call grand_average if there is only one evoked

@agramfort Yeah I just saw that too. Didn't catch this locally because I couldn't download the sample dataset (slow connection). Will look into this. I think the assertion that more than 1 instance should be passed to mne.grand_average() does make sense though. But I also believe that grand averaging should, ideally, be done using the grand_average() function, just because the name is very explicit :) – How can it happen that we end up with a list of length 1 here anyway? Oh well, need to fetch the sample data once I have time and step through the pipeline.

you have only one subject in this dataset

Ok, so I was thinking, and I believe since this template also serves as some kind of reference, it would be great to use mne.granda_average() here as, like I said, the name is verbose, and because it sets .nave to the "correct" value.
So how about we modify mne.grand_average() to

raise if the input sequence is empty
throw a warning if the input sequence length is 1
proceed as usual otherwise

Can open an issue on the mne-python issue tracker to discuss this, of course.

@hoechenberger why do you want to change something that works? is there any advantage to use mne.grand_average ?

I guess it's a matter of documenting what is more recommended. I would
agree that mne.grand_average is really meant for this operation (group
level average of sensor data).
I am inclined to relax the constraint that mne.grand_average requires more
than one evoked and just raise a warning in this case.
ok for you @jasmainak ?

@jasmainak, like @agramfort said:

I guess it's a matter of documenting what is more recommended.

That's exactly my point here :)

sounds good, this would need a PR to mne-python in that case

@jasmainak Will do next week :)

… Or next month. Haha. Will put this on my todo list.

success ! merging

Yay! Thanks for your help


Auto-upgrade to <IP_ADDRESS>

Base PullRequest
default branch (https://github.com/http4k/http4k-connect/tree/master)
Command results

Details:

add path
/home/runner/work/_actions/technote-space/create-pr-action/v2/node_modules/npm-check-updates/build/src/bin

./upgrade_http4k.sh <IP_ADDRESS>

Changed files

Changed file:

gradle.properties

:octocat: Repo | :memo: Issues | :department_store: Marketplace

Codecov Report

Merging #231 (343b45e) into master (6ba4cf7) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##             master     #231   +/-   ##
=========================================
  Coverage     72.08%   72.08%
  Complexity     1144     1144
=========================================
  Files           574      574
  Lines          6390     6390
  Branches        517      517
=========================================
  Hits           4606     4606
  Misses         1477     1477
  Partials        307      307

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


I want to hide Pending Connection content until it's hover to invalid connection, How can I?

Hi @miroiu
I am not sure weather it is possible or not, but I wanted to hide content of pending connection until it's hover to invalid connection.
What I want is, I don't want to display the pending connection content "Drop on connector",

If it's hover to invalid connector it should display the content as shown below.

Any thoughts how to achieve this?
Thanks Again
Have a wonderfull day

Hi, did you try to change the visibility of the content with a DaraTrigger?

I tried but not working, I am not sure, I am new to WPF and MVVM so I might be doing wrong,
Please suggest some boilerplate code if this is wrong.
Thanks for your patience.

If I remove the style for content (It's giving build error so I have to remove), After removing it's somewhat working as expected, but still I am seeing a empty square box which looks somewhat weird.

@miroiu
Did you get a chance to look into it?

@ankitsatapara07 I updated the playground app with an example on how to do it

I hope that helps.

@miroiu
I just see the fix and the updated playground example.
Thank you so much for helping me.
Thanks again 👍


Update utils, utilstest to 0.1.98

Updates

es.weso:utils
es.weso:utilstest

from 0.1.94 to 0.1.98.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "es.weso" } ]

labels: library-update, semver-patch

Codecov Report

Merging #416 (058f2ee) into master (ce7e55f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #416   +/-   ##
=======================================
  Coverage   14.52%   14.52%
=======================================
  Files          57       57
  Lines        2073     2073
  Branches       71       71
=======================================
  Hits          301      301
  Misses       1772     1772

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 ce7e55f...058f2ee. Read the comment docs.


edit commands do not need to update the filtered list to show all items in the list

Yes, they do.
This is because after editing, the filtering conditions may filter out the edited item and make it not displayed in the list.