Panning from left edge in navigation link destination does not navigate back

When FancyScrollView is used in a view that is reached through a NavigationLink, it is not possible to pan from the left screen edge to navigate back.
Minimal example:
import SwiftUI
import FancyScrollView

struct ContentView: View {
    var body: some View {
        NavigationView {
            NavigationLink("Foo", destination: ChildView())
        }
    }
}

struct ChildView: View {
    var body: some View {
        FancyScrollView {
            Text("Bar")
        }
    }
}

Steps to reproduce:

Open the app
Tap on "Foo" to navigate to the ChildView
Place finger on left side of screen and swipe right to navigate back

Version information:
FancyScrollView 0.1.2
iOS 13.6 (17G5045c)

This is a known issue due to the fact that .setNavigationBarHidden will disable the gesture recognizer.
A possible solution is to swizzle the implementation of UINavigationController.setNavigationBarHidden(_:animated:) to only change the alpha values of the bar instead of this whole weird logic. But that resulted in a lot of the calculations being wrong due to the safe area, so I still have to look at that.

I have experimented a bit and I have a potential fix ready here, which builds upon your hackNavigationToAllowSwipeBackWhenHidden implementation.
I have tested it somewhat and it seems to behave well. But my testing hasn't been very thorough.
I can create a pull request, but note that this also contains the changes from my pull request #3.

Hihi I had no idea I pushed the hackNavigationToAllowSwipeBackWhenHidden 😅
#3 is merged already, so don't hesitate to send the PR

PR #4  is open :)

Merged

My fix no longer works in iOS 14 💩

Let's wait to see if iOS 14 fixes this again


Map is too low.

Shouldn't the map be higher, so that the buttons for character selection don't cover some of the levels?

If the aspect ratio gets this out of whack (here due to a wide screen and the (currently-empty) ad container at the top), we could try moving those buttons off to side in a vertical layout.

What OS/browser/screen you are having?

I notice the same issue on my laptop with an unnecessary padding on top of play screen

I have Windows 7, with Google Chrome (resolution is 1440*900).

How about now? We took out the ad bar placeholder we were going to test which was pushing everything down.
@DerpfacePython We have been introducing a ton of new stuff lately, and it's been pretty hard to keep up with all the bugs introduced by the changes. We are working on improving stability and quality now that the bulk of the teacher version and new interpreter engine are up.

@nwinter It still doesn't work, for some reason - the map is still too low.

hmm, i check on my Windows laptop and it seems fine on both Firefox and Chrome

Well, that's weird.

Fixed by 1e640fb?


Fixing the tone - Synapse Parameters/Mediators sections

removed WSO2 EI, EI, and WSO2 Enterprise Integrator from descriptions in the 'Synapse Parameters' and 'Mediators' sections.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.


removal of set_native_acl deviation

"This code is a Contribution to the OpenConfig Feature Profiles project ("Work") made under the Google Software Grant and Corporate Contributor License Agreement ("CLA") and governed by the Apache License 2.0. No other rights or licenses in or to any of Nokia's intellectual property are granted for any other purpose. This code is provided on an "as is" basis without any warranties of any kind."

Pull Request Functional Test Report for #2952 / 1b0d93c20627913c80d9d967e9df2d389fe3f46c
No tests identified for validation.
Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1966

Relevant Lines:
3533

💛  - Coveralls


receiver<T, E> should also check for std::exception_ptr

P2300R2 receiver concept has the following requires clause:
{ execution::set_error(std::move(t), (E&&) e) } noexcept;
On the other hand, the paper refers to receiver concept in multiple context without specifying the error type (i.e., definition of receiver_of, sender_to,  etc.) More importantly, the definition of connect() requires for the R type to be a receiver (without the possibility of inferring the error type).
This means, that even if a type R models receiver<E> (with E != exception_ptr), it will be used by the framework as a simple receiver. If the the type R doesn't properly allow calls to set_error(R, exception_ptr), it cannot be used with the rest of the primitives.
Thus, the best way to ensure that a receiver type is properly specified is to add another requires clause:
{ execution::set_error(std::move(t), exception_ptr{}) } noexcept;
ensuring that the receiver also support exceptions.

the design has changed here; receivers are no longer required to handle exception_ptr


[Bug]After compiling and installing the main version, the performance of vicuna-13b-v1.5 on the knowledge base is very poor.

Search before asking

[X] I had searched in the issues and found no similar issues.

Operating system information
Windows
Python version information
3.10
DB-GPT version
main
Related scenes

[ ] Chat Data
[ ] Chat Excel
[ ] Chat DB
[X] Chat Knowledge
[ ] Model Management
[ ] Dashboard
[ ] Plugins

Installation Information

[X] Installation From Source

[ ] Docker Installation

[ ] Docker Compose Installation

[ ] Cluster Installation

[ ] AutoDL Image

[ ] Other

Device information
GPU:P100
Models information
LLM: vicuna-13b-v1.5
Embedding model: bge-large-zh
What happened
after rellease v4.7  the main branch ,在知识库问答场景下，表现与V4.7差距非常大，请问下，是调整了哪些参数么？
What you expected to happen
我期望跟V4.7表现一致
How to reproduce
1
Additional context
1
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

hi @likenamehaojie could you give some cases about ChatKnowledge with vicuna13b-v1.5 between v0.4.7 version and latest version?

+1， for example, after v0.4.7, it would answer with Round, and never stop.

第二张图直接把最高预警变成了橙色预警

before v4.7 vicuna13b-v1.5 better than GPT3.5

could you give the llm model output log?

When I changed the model to codellama13B, the knowledge base performed well, back to the original level


refactor: style specific sticky columns in carbon row

Closes #6268
this pr refactors https://github.com/carbon-design-system/ibm-products/pull/4458, to apply backgrounds only on sticky elements, thus fixing ai-lable variants of datagrid
note: there is still a design conflict if we wanna use ai-lable with sticky column.
What did you change?
packages/ibm-products-styles/src/components/Datagrid/styles/_datagrid.scss
How did you test and verify your work?
storybook

@elycheea fixed it, also added back useMemo on header story (removed from here) as i noticed render issues when resizing in header story


Added missing relation as argument for hook methods

For both hooks, readRelated{name} and readingRelated{name}, it seems to be impossible to create an appropriate response at the moment because both hooks are called without $relation which is required for constructing the response:
https://github.com/laravel-json-api/laravel/blob/91d8e0cddb28efc1564c54ae6b43845dda73eb0e/src/Http/Controllers/Actions/FetchRelated.php#L76-L83

@aimeos what is it you need from the relation object?

Obviously, $relation->name() to build the RelatedResponse:
https://github.com/laravel-json-api/laravel/blob/91d8e0cddb28efc1564c54ae6b43845dda73eb0e/src/Http/Controllers/Actions/FetchRelated.php#L81

Ok, but you don't need the name from the relation, because it's already in the method name that's being called.
I.e. if the JSON:API field is comments, then the method on the controller being called is readingRelatedComments. So you already know the field name is comments.
So not sure why you'd need to call $relation->name()? Or am I missing something?

OK, didn't knew that it can be static in that case. It would be great to  have example code in the docs what you can do in the hooks, e.g. here and following sections: https://laraveljsonapi.io/docs/3.0/routing/controllers.html#fetch-many-aka-index
public function read( ?Post $post, PageQuery $query ) : DataResponse
{
    return \LaravelJsonApi\Core\Responses\DataResponse::make( $post )
      ->withMeta( ['key' => 'value'] )
      ->withQueryParameters( $query );
}

Or here: https://laraveljsonapi.io/docs/3.0/routing/controllers.html#fetch-related-aka-show-related
public function readingRelatedAuthor(Post $post, UserQuery $query): RelatedResponse
  return \LaravelJsonApi\Core\Responses\RelatedResponse::make( $post, 'author', $data )
      ->withMeta( ['key' => 'value'] )
      ->withQueryParameters( $request );
}

BTW: The docs contains an error because the hook functions must not return void.

Closing this as I'm not planning on making any changes.
FYI the docs show a return type of void, because you don't have to return anything from a hook method. You could just implement a side-effect, e.g. dispatching a job to the Laravel queue. Obviously if you do return anything from a hook (e.g. a response is a good example), you can type-hint your hook to return that value. (Hooks are not defined on an interface anywhere, so the return type can be anything you want, including void.)


Unknown mask provided

Hello there, i tried this plugin with facade and without it and in both it give me error, i literally followed the instructions that are on the usage and im getting this, when im using facade i get folders but i can't access messages or so.

Hi @omarhabeh ,
thanks for your report. I was able to reproduce the problem and just released a patch. Please update to the latest version, update your config/imap.php config file and try again.
Best regards,


Refine header command icons

This PR:

Makes the header command icons match the [subtler] color of other built-in "header" buttons, like the nav buttons in "Files" and "Remote":

Reduces the scale of the refresh icon so that it fit better (visually) within the bounds of the buttons:

Tweaks the scale and shape of the group icon to match more stylistically that of the refresh (and other built-in icons).

Lastly, I updated the corresponding canvas names in Icons.sketch to make it easier to export (creating the required folder automatically).

These changes, unfortunately, fly in the face of similar header command buttons (e.g. the built-in "Debug"), so it does create some stylistic discrepancies:

That being said, I think it looks better visually :)
(It might actually be worth suggesting said scale and color changes to Panic so that using built-in images in this context produces a better result.)

I totally agree. Looks great Pete! Thanks. This has been added in v3.1.2.


Add file extensions for Raku according to current conventions: https:…

Adding .raku, .rakumod, .rakutest, and .rakudoc as they are present-days standard extensions for Raku
Description
The languages.yml file already has an entry for Raku, but for some reason, the current extensions were not added there. There is a lis of official extensions at https://github.com/Raku/problem-solving/blob/master/solutions/language/Path-to-Raku.md#extensions
Checklist:

[x] I am associating a language with a new file extension.

[ ] The new extension is used in hundreds of repositories on GitHub.com

Search results for each extension:

https://github.com/search?utf8=✓&type=Code&ref=searchresults&q=extension%3AFOOBAR+KEYWORDS+NOT+nothack

[x] I have included a real-world usage sample for all extensions added in this PR:

Sample source(s):

[URL to each sample source, if applicable]

Sample license(s):

[ ] I have included a change to the heuristics to distinguish my language from others using the same extension.

[ ] I am adding a new language.

[ ] The extension of the new language is used in hundreds of repositories on GitHub.com.

Search results for each extension:

https://github.com/search?utf8=✓&type=Code&ref=searchresults&q=extension%3AFOOBAR+KEYWORDS+NOT+nothack

[ ] I have included a real-world usage sample for all extensions added in this PR:

Sample source(s):

[URL to each sample source, if applicable]

Sample license(s):

[ ] I have included a syntax highlighting grammar: https://github-lightshow.herokuapp.com/
[ ] I have updated the heuristics to distinguish my language from others using the same extension.

[ ] I am fixing a misclassified language

[ ] I have included a new sample for the misclassified language:

Sample source(s):

[URL to each sample source, if applicable]

Sample license(s):

[ ] I have included a change to the heuristics to distinguish my language from others using the same extension.

[ ] I am changing the source of a syntax highlighting grammar

Old: https://github-lightshow.herokuapp.com/
New: https://github-lightshow.herokuapp.com/

[ ] I am updating a grammar submodule

[ ] I am adding new or changing current functionality

[ ] I have added or updated the tests for the new or changed functionality.

[ ] I am changing the color associated with a language

[ ] I have obtained agreement from the wider language community on this color change.

[URL to public discussion]
[Optional: URL to official branding guidelines for the language]

How do you search to see how many users are using an extension?
I tried using the search link included in the checklist but the result page for me for https://github.com/search?q=extension%3Arakumod+NOT+nothack&type=Code looks like nonsense, listing 63m users on the left, but only 3K matches / 100 pages.
I've searched the github doc pages on search and do not understand what I'm doing wrong or if the search is (currently?) borked.

@raiph

How do you search to see how many users are using a [file] extension?

From the linked issue, my understanding is that GitHub's interactive web search does not display these results; the issue mentions using Alhadis/Harvester to determine the counts, which is significantly slower.
Using that tool, I produced the following updated counts:

.raku: 2,068 files, 287 repos, 152 users
.rakumod: 2,065 files, 250 repos, 87 users
.rakutest: 325 files, 77 repos, 30 users

The policy states

We try only to add languages once they have some usage on GitHub. In most cases we prefer that each new file extension be in use in hundreds of repositories before supporting them in Linguist.

So it looks like .raku and .rakumod are both well over the "hundreds of repos" threshold.  I suppose that means it's time to move on to the other steps @lildude outlined above?

Closing in favour of https://github.com/github/linguist/pull/5168 as it's ready to go and I'm starting to get things in order for a new release.

Closing in favour of https://github.com/github/linguist/pull/5168 as it's ready to go and I'm starting to get things in order for a new release.


Manager not displayed in newer version of Chrome

When I start the manager and run it on a new version of Chrome (e.g. after 80.0), the manager fails to display (even though my servers still run correctly).
Reverting Chrome to v55.0 fixes the problem, but I'm just curious if anyone has successfully had the manager show up correctly in the newest version of Chrome?

https://www.chromestatus.com/feature/5144752345317376

Hi @maffoo --- I'm attempting to gauge how much work this would entail and how feasible it would be for someone who is unfamiliar with Node (me) to take this on. So far, my understanding is that the path would be something like

[x] Replicate a build of the current master and verify that it works on Chromium < 80.
[ ] Upgrade from Polymer 1.6 to 2.0.

[ ] Figure out how to get PolymerElements/{iron,neon,paper}-elements 2.0. The {iron,neon,paper}-elements repos haven't been upgraded for Polymer 2.0.
[ ] Migrate from PolymerTS to PolymerDecorators. This might be partially automated: see nippur72/PolymerTS#110.
[ ] ??

[ ] Upgrade from Polymer 2.0 to 3.0.

[ ] This upgrade is mostly automated by Polymer modulizer.
[ ] ??

Does this look accurate to you? Any large steps that I'm missing in the ?? areas? Thanks!

A temporary workaround for chrome version > 80: https://github.com/karma-runner/karma/issues/3419#issuecomment-583138545. I think this issue should still be addressed if possible though.

Will this issue be further addressed?

I'm hoping to continue working on this, but I'm completely unfamiliar with web tech and was hoping for some advice from @maffoo before continuing.
Current progress is here.

@maffoo Are you working on this? I saw your new branch and wanted to make sure you'd seen this issue and this branch.

Just wondering: Is anyone still trying to solve this issue? Actually, my question is, how to go around this problem? I mean there must be a way to do that. I can't imagine the entire google team is using an old version of Chrome on all the measurement computers...

@xiaoyuejin see the workaround above: https://github.com/labrad/scalabrad-web/issues/331#issuecomment-601955326. This still works for us.

It seems that HTMLImports was completely removed from chrome in version 88. The workaround above does not work anymore. The solution we use right now is to keep chrome up to date (it does not work with labrad), and install another chromium-based browser that is not updated so it would work with labrad.

Yeah, that's exactly why I was asking the questions I asked above...


Gradle wrapper should not be excluded from source files.

It is needed by other users to setup a dev envoriment

Thanks


fix(material/care): use checkmark to indicate selected option

For single-selection, use a checkmark to visually indicate which option is selected. Fix a11y issue where selection option is visually communicated with color alone. Communicate selection with both color and a checkmark.
Add 'checkmark' appearance to mat-option to be used for single-selection.

Creating a draft to test how hard this is to land internally.


.navigate() triggers after .resume() has been called

Hello,
Have been testing the router pausing and am finding that the call to navigate() will complete after resume() so the route will fire when it's not supposed to.
Is there any scope for having the resume being passable as a callback?
Thanks for you time!

Are you using the hash based routing? I mean using # symbol in the URL.


Enhance code-migration-detector to allow code analysis.

Is your feature request related to a problem? Please describe.
Migration effort can be seen based on the diagram converter, however currently there is no tooling available to analyze the code base.
Describe the solution you'd like
Prevent New Camunda 7 Implementations
User Story
As a system architect,
I want to ensure that no new implementations are added using Camunda 7 specific APIs and patterns,
so that we avoid complicating the upcoming migration to Camunda 8.
Acceptance criteria

Given that that a developer is adding or modifying a process solution,
when the changes are submitted,
then the CI/CD pipeline should automatically check for and reject any use of deprecated Camunda 7 APIs

Tasks

Develop ArchUnit rules to detect deprecated Camunda 7 APIs
Allow ignoring old violations

On-Demand Reporting of Camunda 7 Migration Challenges
User Story
As a system architect,
I want to have the ability to trigger an analysis that generates a detailed report of Camunda 7 architectural violations
so that I can proactively assess and plan the migration to Camunda 8
Acceptance criteria

Given that I trigger the analysis,
when  the analysis runs on the current codebase,
then the tool should evaluate the current code base for Camunda 7-specific architectural violations, generate a detailed report that includes each violation, explains the implications for migration to Camunda 8, and provides suggestions that conform to Camunda 8 best practices, potentially linking to documentation or examples for further guidance.

Tasks

Enhance ArchUnit reporting to include detailed violation analysis and migration guidance
Document how to generate a report on-demand.

Missing Tests

Engine Plugin

Describe alternatives you've considered

For now I would like to build the solution on top of the existing ArchUnit Implementation: https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/code-migration-detector

Additional context
Implementation will be discussed with @jonathanlukas

I've improved the README with a working MigrationPreparationTest.


413 Errors

When uploading files larger then a few 100MB through the proxy, I get a 413 error. How can I fix this?

Can you please send your docker logs?

Can you please send your docker logs?

Turns out it was actually the backend server, not NPMPlus.


Allow to pass a Blob to getData (so that only the first 128kb can be processed by EXIF)

For large images it might be more efficient to only process the first 128kb (see e.g. http://code.flickr.net/2012/06/01/parsing-exif-client-side-using-javascript-2/).
To pass only the first 128kb to EXIF one can use file.slice(0, 131072). The result then is of type window.Blob and no longer a window.File, so the check in EXIF.getImageData has to be adjusted.
A full example of what this change allows to do:
var getFilePart = function(file) {
    // From http://code.flickr.net/2012/06/01/parsing-exif-client-side-using-javascript-2/:
    // Using Blob.slice() we pull out the first 128kb of the image to limit load on the worker
    // and speed things up. The Exif specification states that all of the data should exist in
    // the first 64kb, but IPTC sometimes goes beyond that, especially when formatted as XMP.
    var filePart;
    if (file.slice) {
        filePart = file.slice(0, 131072);
    } else if (file.webkitSlice) {
        filePart = file.webkitSlice(0, 131072);
    } else if (file.mozSlice) {
        filePart = file.mozSlice(0, 131072);
    } else {
        filePart = file;
    }
    return filePart;
}

var filePart = getFilePart(file);
EXIF.getData(filePart, function() {
    var tags = EXIF.getAllTags(filePart);
    console.log("Got tags ", tags);
});

I don't see reference to slice (on the FileReader) anymore and observed that passing exif.js huge file would actually store that much browser memory (which is sometimes simply not possible).
Was the slicing code somehow removed?


Feeds for blog, newsroom

This PR requires a slight modification to sheer which was made here
This adds the required settings to the blog and newsroom files in /_queries/ to enable RSS feeds.  This pattern can be followed for other post types that require feeds.

:+1:

:+1:

Sheer PR 95 is in.


Do not deploy control plane exposure when hibernated

How to categorize this PR?

/area control-plane
/kind bug
/priority normal
What this PR does / why we need it:
Control plane exposure should only be created when the cluster is not hibernated or is not using SNI.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

NONE

Well, I am not able to reproduce the issue to judge for myself whether this PR helps or not. Can you share steps to reproduce?
/invite @timuthy

The general problem with excluding steps during hibernation is that when you delete a hibernated cluster and you changed the deployment in the meantime, the resource (here cp exposure) is not up-to-date. That struck us in the past especially if the clusters were hibernated for a longer period of time, i.e. you never really know when migration code is supposed to be removed (/cc @ialidzhikov). Also see https://github.com/gardener/gardener/issues/1240.

you changed the deployment in the meantime, the resource (here cp exposure) is not up-to-date.

This is another problem which should be fixed in the deletion flow - you must recreate/update all resources which are relevant to the cluster deletion. Kube apiserver / service / kubecontroller manager and so must all be up.

Can you still explain why this PR is of kind bug and what the bug is actually about, as @ialidzhikov already asked?

I'm not able to reproduce it, but I've seen the following error:

Normal   Hibernated      11h                   gardener-controller-manager  Hibernating cluster due to schedule
Normal   Reconciling     11h (x6 over 12h)     gardenlet                    Reconciling Shoot cluster state
Normal   Reconciled      11h (x5 over 12h)     gardenlet                    Reconciled Shoot cluster state
Warning  ReconcileError  11h                   gardenlet                    Flow "Shoot cluster reconciliation" encountered task errors: [task "Deploying internal domain DNS record" failed: Failed to create "internal" DNS record: "retry failed with context deadline exceeded, last error: dnsentries.dns.gardener.cloud "internal" not found" (status=Deleting, message=entry is scheduled to be deleted) task "Deploying external domain DNS record" failed: Failed to create "external" DNS record: "retry failed with context deadline exceeded, last error: dnsentries.dns.gardener.cloud "external" not found" (status=Deleting, message=entry is scheduled to be deleted) task "Waiting until Shoot control plane exposure has been reconciled" failed: Error while waiting for ControlPlane shoot--foo/foo-exposure to become ready: extension encountered error during reconciliation: Error reconciling controlplane: could not get kube-apiserver service load balancer address: Service "kube-apiserver" not found]

Which I don't know how it would happen in a normal reconcilation, but the Waiting until Shoot control plane exposure has been reconciled should not be executed if the cluster is hibernated or SNI is enabled.

Any further opinions @mvladev @gardener/gardener-maintainers?

Not really, I don't fully get the problem with keeping the way it is atm and tend to agree with @timuthy.

I agree with the colleagues, the main argument is

By design, we've never deleted extension resources when the cluster was hibernated. Instead, we apply it again and the extension controllers are supposed to deal with the hibernation state of the cluster. This PR changes the behavior profoundly (even if it sounds reasonable) and thus can have unforeseeable side effects because we don't control every extension.

As we aren't even sure if this PR helps with the above seen problem and we don't have any reproduction steps, I'd suggest to close the PR for now and revisit it when we have more details/information on it?

OK, if nobody objects until EOB today, let's close the PR then.

/close


post basemap-screenshot-capture phase is annoying

It shows a view of the basemap at the initial viewport while waiting to upload the thumbnail.

This looks like it was fixed already


HUD revisions tier 2

Organise loose status bar functions into a comprehensive class.
Minor QOL updates to status bar behaviour.
Demagic renderer bar functions.

Is this PR makes it easier to eventually adopt usage of custom value bars for builder purposes (e.g. freeze bar, enemy HP bar etc etc)?

Is this PR makes it easier to eventually adopt usage of custom value bars for builder purposes (e.g. freeze bar, enemy HP bar etc etc)?

Yes, it moves one step closer to that possibility. :)

Hi, when I was tested this branch, I found another issue.
When Lara dies (in my case by height or lava floor), her air bar also appears getting inmediately empty like the health one.

Hi, when I was testing this branch, I found another issue.
When Lara dies (in my case by height or lava floor), her air bar also appears getting inmediately empty like the health one.

Fixed.

Ive just tested this branch and recreated the points raised by @Adngel and all issues have been fixed. I think this can be merged now unless you want to do more to it?


RevEng: Unnecessary usings in entity class code

Entity classes include the following using directives.
using Microsoft.Data.Entity;
using Microsoft.Data.Entity.Metadata;

I can't think of any entity class code that would require them.

@rowanmiller Suggest pri0 is too high...

@lajones agreed it is not critical, but we think it is small and we should just do it, so pri0 is to keep it in the radar for now.

Fixed with commit 1f3f1eb.


No topic route info in name server for the topic: RMQ_SYS_TRACE_TOPIC

在使用阿里云 消息队列 for Apache RocketMQ 时发现消息被消费但是查询 消息轨迹 始终显示 尚未消费  在日志中发现如下错误：
No topic route info in name server for the topic: RMQ_SYS_TRACE_TOPIC

When using Alibaba Cloud's "Message Queuing for Apache RocketMQ", it was found that the message was consumed but the query "Message Trace" always shows "Not yet consumed". The following errors were found in the log:
No topic route info in name server for the topic: RMQ_SYS_TRACE_TOPIC
Configuration information
spring:
  cloud:
    stream:
      bindings:
        TEST_ONE_INPUT:
          destination: TEST_TOPIC
          group: xxx%GID_TEST_ONE
        TEST_TWO_INPUT:
          destination: TEST_TOPIC
          group: xxx%GID_TEST_TWO

      rocketmq:
        bindings:
          TEST_ONE_INPUT:
            consumer:
              tags: tag1
          TEST_TWO_INPUT:
            consumer:
              tags: tag2

---

spring:
  cloud:
    stream:
      bindings:
        APP_SOURCE_OUTPUT:
          destination: TEST_TOPIC
      rocketmq:
        bindings:
          APP_SOURCE_OUTPUT:
            producer:
              group: xxx%GID_PRODUCER_TEST_GROUP

阿里云RocktMQ 节点在 美国硅谷
参考：https://github.com/alibaba/spring-cloud-alibaba/issues/764
添加区域列表配置：customized-trace-topic: rmq_sys_TRACE_DATA_us-west-1
还是无效

解决了嘛


feat: change to generic type for ExecutedQuery

This ought to fix https://github.com/planetscale/database-js/issues/150.
This change allows you to define a type for an object if you have an array of rows generated as an 'object'.
As a result, properties will be suggested as described in the issue, and you will not have to access properties for any.
I don't think we will have to worry about the ESLint error Unsafe member access .id on an any value.(https://typescript-eslint.io/rules/no-unsafe-member-access/).

@yutak23 I've merged your changes into #154. I'm going to close this PR in favor of that one for now because it goes a little deeper into type correctness.
Could you verify this solves the issue you were having?

@ayrton, Yes, I think that fix will solve my problem. Thank you very much.


MH_ANTWERPEN: complete bird names + location remarks

Complete individual.remarks and session.remarks for MH_ANTWERPEN + reupload ref data to movebank.

Updated in DB: Lilla and Lillo in Galgenschoor.


ClimaLand Diagnostics, update

Purpose
This is a second major PR to introduce diagnostics in ClimaLand.
To do:

[ ] union type ::BucketModel, ::SoilCanopyModel
[ ] more tests
[ ] better docs
[ ] macro to reduce code duplication in compute_ and add_diag ( ? )
[ ] fix names, units, comments of SoilCanopyModel diagnostics variables
[ ] add more default methods, period of averaging, what variables, etc.

@Sbozzolo just listing our to do list for now.


[BUG] celeborn raft HA exception

What is the bug(with logs or screenshots)?
A clear and concise description of what the bug is.
Start three master instances, two of which frequently brush exception logs

It does not affect the operation of the job, but the log volume has soared, which seems to be caused by the exception of selecting the master of the raft
How to reproduce the bug?
Steps to reproduce the bug.
start three master
Please help me see what the problem is
/cc @who-need-to-know
/assign @who-can-solve-this-bug

Can you share your celeborn cluster version? The git commit id will be very helpful.

Can you share your celeborn cluster version? The git commit id will be very helpful.

v0.2.0-incubating-rc3

Can you share your celeborn cluster version? The git commit id will be very helpful.

Is there a celeborn discussion group? Can you add me

We have slack channels and a DingTalk group. Feel free to reach us in a convenient way.

We have slack channels and a DingTalk group. Feel free to reach us in a convenient way.

I can't find the contact information of DingTalk group, can you send me

We have slack channels and a DingTalk group. Feel free to reach us in a convenient way.

I can't find the contact information of DingTalk group, can you send me

I need DingTalk group information too~

I need DingTalk group information too~

Ding talk groupId: 41594456

What is the current state of discussion on this issue? I would greatly appreciate it if you discuss this issue here, for that all of the open source participants can well know the state of this discussion. @waitinfuture @FMX  Thank you!

What is the current state of discussion on this issue? I would greatly appreciate it if you discuss this issue here, for that all of the open source participants can well know the state of this discussion. @waitinfuture @FMX Thank you!

Hi @sunjincheng121 , thanks for paying attention, I believe this issue is fixed, @FMX could you offer more details?

@sunjincheng121  Hi, this issue is fixed now.
This issue is caused by a bug that prevents the master node from loading its snapshot.
Following are patch lists:
https://github.com/apache/incubator-celeborn/pull/996

This issue is resolved. So I'll close this issue.


Istio CNI blocks traffic in application init containers

After installing istio cni for using ambient mesh, i faced such problem that Istio CNI blocks traffic in application init containers. I am familiar with the workaround to the problem that is proposed in the documentation (https://istio.io/latest/docs/setup/additional-setup/cni/#compatibility-with-application-init-containers) but these instructions did not help me, the plugin ignores them.
I`ve set next configurations of istiod helm values file and istio cni values.
"istiod"
pilot:
 traceSampling: 100.0
 env:
   PILOT_HTTP10: "1"

istio_cni:
  enabled: true
  chained: true

"istio cni"
cni:
 ambient:
   enabled: true
 privileged: true

With deployed istio helms I have tried to run redis helm chart with init container using such values file.
helm install redis  bitnami/redis --version 18.2.0 --namespace test --values <(cat redis-values.yaml)
<values.yaml>
image:
  registry: quay.io
  repository: opstree/redis
  tag: latest

master:
  livenessProbe:
    enabled: true
    initialDelaySeconds: 40
    periodSeconds: 15
    timeoutSeconds: 15
    successThreshold: 1
    failureThreshold: 5

  podSecurityContext:
    enabled: true
    fsGroup: 1337

  podAnnotations:
    proxy.istio.io/config: |
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"
    traffic.sidecar.istio.io/includeOutboundIPRanges: "*"
    traffic.sidecar.istio.io/includeInboundPorts: "*"
    traffic.sidecar.istio.io/excludeOutboundPorts: "443"
    traffic.sidecar.istio.io/excludeInboundPorts: "443"
    traffic.sidecar.istio.io/excludeOutboundIPRanges: "<IP_ADDRESS>/32"

  initContainers:
    - name: init-celery-workers-restart
      image: bitnami/kubectl
      command: ['sh', '-c', 'sleep 30; kubectl delete pods -n test -l app.kubernetes.io/component=celery-worker']
      securityContext:
        runAsUser: 1337

  resources:
    requests:
      cpu: 80m
      memory: 60Mi
    limits:
      cpu: 80m
      memory: 60Mi

As pod starts i get such logs in init container`s output. At the same time istio cni, ztunnel & istiod have next logs.
"init container"
E0118 09:57:46.188460       8 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
E0118 09:57:56.195553       8 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
E0118 09:58:06.202729       8 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
Unable to connect to the server: EOF

"istio cni"
info    cni istio-cni ambient cmdAdd podName: redis-master-0 podIPs: [{IP:<IP_ADDRESS> Mask:ffffffff}]
info    cni Adding pod 'redis-master-0/test' (a9573a59-6adc-48e8-9d41-a9bd08fdc40c) to ipset
info    cni Adding route for redis-master-0/test: [table 100 <IP_ADDRESS>/32 via <IP_ADDRESS> dev istioin src <IP_ADDRESS>]

"ztunnel"
INFO xds{id=2}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
INFO xds{id=2}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
WARN outbound{id=b395fe07254d28f5ec84ffc0850994eb}: ztunnel::proxy::outbound: failed dur=96.464µs err=unknown source: <IP_ADDRESS>
WARN outbound{id=a1c3ba7180c313fa148f1899baa136e4}: ztunnel::proxy::outbound: failed dur=87.892µs err=unknown source: <IP_ADDRESS>

"istiod"
info    ads Push debounce stable[44] 3 for config ServiceEntry/pslabs/redis-master.pslabs.svc.cluster.local and 1 more configs: 100.244777ms since last change, 103.240829ms since last push, full=true
info    ads XDS: Pushing Services:95 ConnectedEndpoints:6 Version:2024-01-18T10:05:13Z/37
info    validationController    Not ready to switch validation to fail-closed: dummy invalid config not rejected
info    validationController    validatingwebhookconfiguration istio-validator-istio-system (failurePolicy=Ignore, resourceVersion=14938048) is up-to-date. No change required.
error   controllers error handling istio-validator-istio-system, retrying (retry count: 1004): webhook is not ready, retry  controller=validation

Also i tried to use ServiceEntry and DestinationRule to allow traffic to k8s service bypassing istio mesh.
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: k8s-api
  namespace: test
spec:
  hosts:
    - kubernetes.default.svc.cluster.local
  addresses:
    - <IP_ADDRESS>
  endpoints:
    - address: <IP_ADDRESS>
  exportTo:
    - "*"
  location: MESH_EXTERNAL
  resolution: STATIC
  ports:
    - number: 443
      name: https-k8s
      protocol: HTTPS
___

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: k8s-destrule
  namespace: test
spec:
  host: kubernetes.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE

IMO, It is not about istio-cni, but kubectl.
Kubectl needs ~/.kube/config file to know about the kubernetes cluster it controls.
What about accessing k8s master node, and copy /etc/kubernetes/admin.conf to initContainer's ~/.kube/config?

Thank you for your assumption, but this trouble becomes only when the namespace labeled istio.io/dataplane-mode=ambient otherwise all init containers are working correctly.
Name:         test
Labels:       kubernetes.io/metadata.name=test
Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource.

Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  4m18s  default-scheduler  Successfully assigned test/redis-master-0 to ip-10-0-81-204.eu-west-3.compute.internal
  Normal  Pulling    4m15s  kubelet            Pulling image "bitnami/kubectl"
  Normal  Pulled     4m14s  kubelet            Successfully pulled image "bitnami/kubectl" in 680.825197ms (680.843703ms including waiting)
  Normal  Created    4m14s  kubelet            Created container init-celery-workers-restart
  Normal  Started    4m14s  kubelet            Started container init-celery-workers-restart
  Normal  Pulled     3m43s  kubelet            Container image "quay.io/opstree/redis:latest" already present on machine
  Normal  Created    3m43s  kubelet            Created container redis
  Normal  Started    3m43s  kubelet            Started container redis

I reproduced this issue from AtoZ, and tried every tries to solve this issue.
But I think this is not implemented in ambient mesh and Istio-cni yet.
Those exclude* annotations only works in service mesh, not ambient mesh
@howardjohn
If this feature about init-container's outbound traffic is not implemented yet, can you assign me to this issue? I wanna implement this.

I don't know that its explicitly "not implemented", I think its a bug. We would need to find the root cause before we fix.
Note https://github.com/istio/istio/pull/48253/files changes things a lot

@howardjohn
Thanks for your reply, I will take a look at the coesbase.

I don't know that its explicitly "not implemented", I think its a bug. We would need to find the root cause before we fix.
Note https://github.com/istio/istio/pull/48253/files changes things a lot

Yep, that PR should resolve this.

Could you please try latest master or release 1.21 build, or wait for the official 1.21 release? see https://github.com/istio/istio/issues/48212.

Tagging as ambient beta as there is quite a lot of apps who have its own init containers.

I have tested the latest master and 1.21.0-beta.0 build but have the same result with the init container in the test namespace unable to get k8s service which is located in the default namespace and labeled istio.io/dataplane-mode=ambient.
Following the guide of installation, I installed istioctl of the latest version curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.21.0-beta.0 TARGET_ARCH=x86_64 sh -
$ istioctl version
client version: 1.21.0-beta.0
control plane version: 1.21.0-beta.0
data plane version: 1.21.0-beta.0 (7 proxies)

Then installed into the cluster running command istioctl install --set profile=ambient --skip-confirmation
$ istioctl install --set profile=ambient --skip-confirmation
✔ Istio core installed
✔ Istiod installed
✔ CNI installed
✔ Ztunnel installed
✔ Installation complete
Made this installation the default for injection and validation.

Labeled namespaces and created Redis pod with init container in "test" namespace (I`ve tested with and out annotations or securitycontext). The logs of pods are next:
"init container"
E0129       7 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
E0129       7 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
E0129       7 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
E0129       7 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
E0129       7 memcache.go:265] couldn't get current server API group list: Get "https://<IP_ADDRESS>:443/api?timeout=32s": EOF
Unable to connect to the server: EOF

"istiod"
info	model	Incremental push, service redis-headless.test.svc.cluster.local at shard Kubernetes/Kubernetes has no endpoints
info	model	Incremental push, service redis-replicas.test.svc.cluster.local at shard Kubernetes/Kubernetes has no endpoints
info	model	Incremental push, service redis-master.test.svc.cluster.local at shard Kubernetes/Kubernetes has no endpoints
info	ads	Push debounce stable[17] 10 for config Address//test/redis-headless.test.svc.cluster.local and 5 more configs: 100.218797ms since last change, 202.689346ms since last push, full=true
info	ads	XDS: Pushing Services:95 ConnectedEndpoints:7 Version:2024-01-29T13:37:36Z/5
info	delta	WDS: PUSH for node:ztunnel-dbqql.istio-system resources:3 removed:0 size:216B
info	delta	WDS: PUSH for node:ztunnel-mg5td.istio-system resources:3 removed:0 size:216B
info	delta	WDS: PUSH for node:ztunnel-m9kp4.istio-system resources:3 removed:0 size:216B
info	delta	WDS: PUSH for node:ztunnel-dzpjb.istio-system resources:3 removed:0 size:216B
info	delta	WDS: PUSH for node:ztunnel-n6pvj.istio-system resources:3 removed:0 size:216B
info	delta	WDS: PUSH for node:ztunnel-mn87w.istio-system resources:3 removed:0 size:216B
info	delta	WDS: PUSH for node:ztunnel-n5trr.istio-system resources:3 removed:0 size:216B
info	model	Full push, new service test/redis-headless.test.svc.cluster.local
info	model	Full push, new service test/redis-master.test.svc.cluster.local
info	ads	Push debounce stable[18] 3 for config ServiceEntry/test/redis-headless.test.svc.cluster.local and 1 more configs: 100.229553ms since last change, 100.242902ms since last push, full=true
info	ads	XDS: Pushing Services:95 ConnectedEndpoints:7 Version:2024-01-29T13:37:41Z/6
info	validationController	Not ready to switch validation to fail-closed: dummy invalid config not rejected
info	validationController	up-to-date, no change required	name=istio-validator-istio-error	controllers	error handling istio-validator-istio-system, retrying (retry count: 10): webhook is not ready, retry	controller=validation`

"ztunnel"
INFO ztunnel::app: no dns proxy created
INFO ztunnel::hyper_util: listener established address=<IP_ADDRESS>:15000 component="admin"
INFO ztunnel::hyper_util: listener established address=[::]:15020 component="stats"
INFO ztunnel::xds::client: sending initial request resources=0 type_url="type.googleapis.com/istio.workload.Address"
INFO ztunnel::xds::client: sending initial request resources=0 type_url="type.googleapis.com/istio.security.Authorization"
INFO xds{id=1}: ztunnel::xds::client: Stream established
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=143 removes=0
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.security.Authorization" size=0 removes=0
INFO ztunnel::readiness: Task 'state manager' complete (15.435201ms), marking server ready
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=144 removes=0
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.security.Authorization" size=0 removes=0
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1 removes=0
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1 removes=0
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=0 removes=3
INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=0 removes=1

"istio-cni-node"
info	ambient	Namespace kube-public is disabled from ambient mesh
info	ambient	Namespace kube-system is disabled from ambient mesh
info	ambient	Namespace sentry is disabled from ambient mesh
info	ambient	Namespace fluentd is disabled from ambient mesh
info	ambient	Namespace keda is disabled from ambient mesh
info	ambient	Namespace kube-node-lease is disabled from ambient mesh
info	ambient	Namespace test is enabled in ambient mesh
info	ambient	Namespace argocd is disabled from ambient mesh
info	ambient	Namespace mongodb is enabled in ambient mesh
info	ambient	Namespace mongo-express is disabled from ambient mesh
info	ambient	Namespace monitoring is disabled from ambient mesh
info	ambient	Namespace aws-lb-controller is disabled from ambient mesh
info	ambient	Namespace default is enabled in ambient mesh
info	ambient	Namespace external-secrets is disabled from ambient mesh
info	ambient	Ambient stale Pod IPs to be cleaned: []

Sorry, just got confirmation from Eric that the change is not in beta 0 yet, but should be in -beta.1 since it was merged after beta.0 was released. I expect that the new build will be available in a day or 2.

Unfortunately, the new release did not help solve this problem, the service logs are the same as last time, I tried to install using the Gateway API & HELM, but I didn`t find new values for cni agent or something like that, maybe I'm missing something?

Hello @linsun. I also used istio 1.21.0-beta.1 in ambient mesh mode. I have a problem with vault-agent-init init container. I tested container vault-agent-init don't have connectivity to outside other services in kubernetes.
Could you clarify when this issue will be fixed? Or please point me where this issue was fixed?

@Str33tWalk3r and @tomahkvt please try installing Istio/the Istio CNI component with
--set values.cni.ambient.dnsCapture=true
e.g. https://github.com/bleggett/istio/blob/master/manifests/charts/istio-cni/values.yaml#L59
This is currently required for resolving ServiceEntries and other things within pods, but it is off by default ATM.

Hello @bleggett. Thank you for your tip, but it doesn't resolve the problem.
I got the following error.
.301Z [ERROR] agent.auth.handler: error authenticating: error="Put "http://vault.vault.svc:8200/v1/auth/kubernetes/login\": dial tcp: lookup vault-development.vault.svc on <IP_ADDRESS>:53: read udp <IP_ADDRESS>:42968-><IP_ADDRESS>:53: read: connection refused" backoff=1s
It looks like there is no connectivity between init container and Kubernetes services.

@tomahkvt Then I don't think your pod is properly captured by ambient at all. The init container isn't really relevant - if it works at all, it would work just as well for the init container as for the regular pods.
I'm assuming you're following the latest docs - https://istio.io/latest/docs/ops/ambient/install/helm-installation/ or similar.
Can you

Install with the DNS flag and the following following extra debug verbosity flags:

Installing via istiod: --set values.cni.logLevel=debug --set values.global.logging.level="all:debug"
OR
Installing via Helm: --set cni.logLevel=debug --set global.logging.level="all:debug"

Create your init container pod

Figure out what node your init container pod was scheduled on, and do a

k logs -n istio-system ztunnel-XXXX
k logs -n istio-system istio-cni-node-XXXX

to dump the logs for the ztunnel and CNI agents on that node, and post them here? I need to verify that the pod is actually being captured for ambient in the first place.

Hi @bleggett I collected logs as you asked for init container.
cni logs
2024-02-21T07:43:45.387748Z	warn	ambient	pod testweb8-7745c69f54-d7rlh does not appear to have any assigned IPs, not capturing
2024-02-21T07:43:45.788466Z	info	ambient	in pod mode - adding pod test/testweb8-7745c69f54-d7rlh to ztunnel
2024-02-21T07:43:45.788863Z	info	iptables	Running iptables-restore with the following input:

mangle
-N ISTIO_PRERT
-N ISTIO_OUTPUT
-A PREROUTING -j ISTIO_PRERT
-A OUTPUT -j ISTIO_OUTPUT
-A ISTIO_PRERT -m mark --mark 0x539/0xfff -j CONNMARK --set-xmark 0x111/0xfff
-A ISTIO_PRERT -s <IP_ADDRESS> -p tcp -m tcp -j ACCEPT
-A ISTIO_PRERT ! -d <IP_ADDRESS>/32 -p tcp -i lo -j ACCEPT
-A ISTIO_PRERT -p tcp -m tcp --dport 15008 -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15008 --tproxy-mark 0x111/0xfff
-A ISTIO_PRERT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ISTIO_PRERT ! -d <IP_ADDRESS>/32 -p tcp -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15006 --tproxy-mark 0x111/0xfff
-A ISTIO_OUTPUT -m connmark --mark 0x111/0xfff -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
COMMIT
nat
-N ISTIO_OUTPUT
-A OUTPUT -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -d <IP_ADDRESS> -p tcp -m tcp -j ACCEPT
-A ISTIO_OUTPUT ! -o lo -p udp -m udp --dport 53 -j REDIRECT --to-port 15053
-A ISTIO_OUTPUT -p tcp -m mark --mark 0x111/0xfff -j ACCEPT
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -o lo -j ACCEPT
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -p tcp -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15001
COMMIT
2024-02-21T07:43:45.788901Z	info	Running command (without lock): iptables-restore --noflush -v
2024-02-21T07:43:45.801480Z	info	ambient	Pod testweb8-7745c69f54-d7rlh update event skipped, added/labeled by CNI plugin

ztunnel logs
2024-02-21T07:43:04.298491Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:04.298521Z DEBUG hyper::proto::h1::io: parsed 4 headers
2024-02-21T07:43:04.298525Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:04.298675Z DEBUG hyper::proto::h1::io: flushed 107 bytes
2024-02-21T07:43:04.748329Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:04.748355Z DEBUG hyper::proto::h1::io: parsed 5 headers
2024-02-21T07:43:04.748359Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:04.748582Z DEBUG hyper::proto::h1::io: flushed 1952 bytes
2024-02-21T07:43:11.550239Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: false, payload: [0, 0, 0, 0, 0, 0, 0, 0] }
2024-02-21T07:43:11.550262Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: true, payload: [0, 0, 0, 0, 0, 0, 0, 0] }
2024-02-21T07:43:11.551371Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: false, payload: [59, 124, 219, 122, 11, 135, 22, 180] }
2024-02-21T07:43:11.551618Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: true, payload: [59, 124, 219, 122, 11, 135, 22, 180] }
2024-02-21T07:43:14.298600Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:14.298640Z DEBUG hyper::proto::h1::io: parsed 4 headers
2024-02-21T07:43:14.298644Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:14.298675Z DEBUG hyper::proto::h1::io: flushed 107 bytes
2024-02-21T07:43:19.748076Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:19.748104Z DEBUG hyper::proto::h1::io: parsed 5 headers
2024-02-21T07:43:19.748108Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:19.748158Z DEBUG hyper::proto::h1::io: flushed 1952 bytes
2024-02-21T07:43:24.298346Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:24.298375Z DEBUG hyper::proto::h1::io: parsed 4 headers
2024-02-21T07:43:24.298379Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:24.298530Z DEBUG hyper::proto::h1::io: flushed 107 bytes
2024-02-21T07:43:34.298439Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:34.298489Z DEBUG hyper::proto::h1::io: parsed 4 headers
2024-02-21T07:43:34.298493Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:34.298515Z DEBUG hyper::proto::h1::io: flushed 107 bytes
2024-02-21T07:43:34.747990Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:34.748018Z DEBUG hyper::proto::h1::io: parsed 5 headers
2024-02-21T07:43:34.748022Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:34.748073Z DEBUG hyper::proto::h1::io: flushed 1952 bytes
2024-02-21T07:43:41.551982Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: false, payload: [0, 0, 0, 0, 0, 0, 0, 0] }
2024-02-21T07:43:41.552007Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: true, payload: [0, 0, 0, 0, 0, 0, 0, 0] }
2024-02-21T07:43:41.553190Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: false, payload: [59, 124, 219, 122, 11, 135, 22, 180] }
2024-02-21T07:43:41.601820Z DEBUG xds{id=1}:Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: true, payload: [59, 124, 219, 122, 11, 135, 22, 180] }
2024-02-21T07:43:44.298877Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:44.298906Z DEBUG hyper::proto::h1::io: parsed 4 headers
2024-02-21T07:43:44.298909Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:44.298943Z DEBUG hyper::proto::h1::io: flushed 107 bytes
2024-02-21T07:43:45.791878Z DEBUG ztunnel::inpod::protocol: FD 19 type is netns
2024-02-21T07:43:45.791894Z DEBUG ztunnel::inpod::protocol: FD 19 looks like a netns
2024-02-21T07:43:45.791897Z DEBUG ztunnel::inpod::protocol: Validating netns FD: Ok(())
2024-02-21T07:43:45.791903Z DEBUG ztunnel::inpod::workloadmanager: received message: AddWorkload(WorkloadData { netns: OwnedFd { fd: 19 }, info: WorkloadInfo { workload_uid: WorkloadUid("62ab2568-2db2-43d6-b2d5-1a92b913557b") } })
2024-02-21T07:43:45.791911Z  INFO ztunnel::inpod::statemanager: pod WorkloadUid("62ab2568-2db2-43d6-b2d5-1a92b913557b") received netns, starting proxy
2024-02-21T07:43:45.791921Z DEBUG ztunnel::inpod::statemanager: starting proxy workload=WorkloadInfo { workload_uid: WorkloadUid("62ab2568-2db2-43d6-b2d5-1a92b913557b") } inode=4026532556
2024-02-21T07:43:45.791966Z  INFO ztunnel::proxy::inbound: listener established address=[::]:15008 component="inbound" transparent=true
2024-02-21T07:43:45.791985Z  INFO ztunnel::proxy::inbound_passthrough: listener established address=[::]:15006 component="inbound plaintext" transparent=true
2024-02-21T07:43:45.791999Z  INFO ztunnel::proxy::outbound: listener established address=[::]:15001 component="outbound" transparent=true
2024-02-21T07:43:45.792013Z  INFO ztunnel::proxy::socks5: listener established address=<IP_ADDRESS>:15080 component="socks5"
2024-02-21T07:43:49.748234Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:49.748266Z DEBUG hyper::proto::h1::io: parsed 5 headers
2024-02-21T07:43:49.748270Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:49.748325Z DEBUG hyper::proto::h1::io: flushed 1952 bytes
2024-02-21T07:43:54.298733Z DEBUG hyper::proto::h1::role: setting h1 header read timeout timer
2024-02-21T07:43:54.298764Z DEBUG hyper::proto::h1::io: parsed 4 headers
2024-02-21T07:43:54.298767Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-02-21T07:43:54.298842Z DEBUG hyper::proto::h1::io: flushed 107 bytes

@Str33tWalk3r @bleggett
Is this problem solved? If not, I'll see why and try to fix it~

This problem does exist, and I reproduce it using 1.21.0-beta.1 in ambient mesh mode.
The problem is that ztunnel is not forwarding the request and does not consider the pod as a valid workload.

This problem does exist, and I reproduce it using 1.21.0-beta.1 in ambient mesh mode.
The problem is that ztunnel is not forwarding the request and does not consider the pod as a valid workload.

Interesting. From the logs above it's pretty clear that

The CNI agent did see and add the pod with the init container
The Ztunnel does successfully capture the pod with the init container

2024-02-21T07:43:45.791911Z INFO ztunnel::inpod::statemanager: pod WorkloadUid("62ab2568-2db2-43d6-b2d5-1a92b913557b") received netns, starting proxy

So it's unclear to me what would be unique about the fact that the pod has an init container at that point.
@zengyuxing007 TY for picking up and let us know what you find.

@bleggett
The root cause of this problem is that ztunnel does not have the workload information for the redis pod because istio determines that it is not ready, so it is not synchronized.
Any initContainer attempting to make a network request should have this problem.
the traffic  is black holed and cannot get out, but the pod will never get ready so it's stuck.
@Str33tWalk3r
When ambient supports port exclusion, we can configure excludePorts to avoid blocking kubectl 6443 requests like the one in this example.

Istio isn't supposed to elide the pod when it's not ready, only if it's not running. not sure if that is working incorrectly or what

Istio isn't supposed to elide the pod when it's not ready, only if it's not running. not sure if that is working incorrectly or what

@howardjohn  when a pod is in the pending state but it is assigned a podIP, the workload is sent to ztunnel, and validation fixes this. please take a look at this PR , check  if it makes sense. thanks ~

If your init container wants to egress to the network before the pod is ready, the solution is probably to support port exclusions in ambient, so the init container ports can be allowliatef to egress outside the mesh before the pod is ready.

If your init container wants to egress to the network before the pod is ready, the solution is probably to support port exclusions in ambient, so the init container ports can be allowliatef to egress outside the mesh before the pod is ready.

Yes, the excludePorts functionality is expected and should also solve most scenarios like this one.
however, maybe there are exceptions,, such as in this example where the kubectl operation for the initContainer needs to exclude port 6443, but a conflict arises if the business pod request in turn needs this port to be intercepted.

Hello. @zengyuxing007 Could you clarify when excludePorts functionality is expected?

@tomahkvt @zengyuxing007 already fixed this in https://github.com/istio/istio/commit/011bbc9f30387bdbb9574af9d5932a1790755146 -> which is merged to master.
So, try a dev build and it should be fixed.
Port exclusions are not required for this particular fix but we do want to add them to ambient for parity with sidecar generally, and will (probably sometime in the beta phase).

@bleggett I want to clarify. Did you fix init container network problem for ambient mesh or side car case?

@bleggett I want to clarify. Did you fix init container network problem for ambient mesh or side car case?

@zengyuxing007 fixed it, not me, and they fixed it for the ambient mesh case, which is (as far as I know, given this issue is only related to ambient) the only place that needed fixing.

@bleggett Thank you a lot for your answer.

@zengyuxing007 @bleggett The development build incorporating this fix has been tested and appears to be functional. I sincerely appreciate your dedication and efforts.

ty @zengyuxing007 !

Hello, @zengyuxing007 @bleggett. Previously I tried to run the dev build (istio-1.22-alpha.42572fab5be79af8de284953ec72cbf439631da8) and the issue was fixed there, but the other day I tried to run more modern builds (istio-1.22-alpha.ffed2074bd92a84b9bd87577e41226c3cfac1a 9b) for example, the same problem was traced there, this is connected with the fact that these are built from different branches? And is there any news when the 1.22 alpha release is planned?

@Str33tWalk3r it works in my testing, can you give reproduction steps?

@Str33tWalk3r and maybe open a new, more specific issue if you can get us the repro, as this issue is closed and the fix merged into 1.22 and 1.21.

@Str33tWalk3r it works in my testing, can you give reproduction steps?

So if I take a newer image 1.22-alpha.ffed2074bd92a84b9bd87577e41226c3cfac1a9b downloading it locally, unpacking it, and going to the folder cd 1.22-alpha.ffed2074bd92a84b9bd87577e41226c3cfac1a9b, adding the location of this file to PATH export PATH=$PWD/bin:$PATH checking version of istioctl and running commandistioctl install --set profile=ambient --set "components.ingressGateways[0].enabled=true" --set "components.ingressGateways[0].name=istio-ingressgateway" --skip-confirmation, after installing all parts labeled namespaces istio.io/dataplane-mode=ambient` and restarting all pods that running in namespace to add to ambient mesh. With this image I've got an error that this issue fixed but if I take istio-1.22-alpha.42572fab5be79af8de284953ec72cbf439631da8 and repeat steps that i mentioned above - all works correctly.

1.22-alpha.ffed2074bd92a84b9bd87577e41226c3cfac1a9b is older than 1.22-alpha.42572fab5be79af8de284953ec72cbf439631da8
the former is from Feb 08, before this fix merged. the latter is from Mar 13, after this fix merged (Mar 7th)

I apologize for my mistake in selecting two outdated images out of the three for testing. However, I have tried a newer image named 1.22-alpha.fefbe293c1a0d04cfc79aae2683b2d402251edb1 which was built on April 9, 2024, and it appears to be working perfectly fine. Thank you very much for your assistance. It is my understanding that this issue will be resolved in the upcoming 1.22 release.

I apologize for my mistake in selecting two outdated images out of the three for testing. However, I have tried a newer image named 1.22-alpha.fefbe293c1a0d04cfc79aae2683b2d402251edb1 which was built on April 9, 2024, and it appears to be working perfectly fine. Thank you very much for your assistance. It is my understanding that this issue will be resolved in the upcoming 1.22 release.

No worries! We appreciate the eyeballs.


bash-completion: Fix tests with musl.

Motivation for this change
Fixes test error
self = <test_iconv.TestIconv object at 0x7ffff52f3410>
completion = <CompletionResult []>

    @pytest.mark.complete("iconv -")
    def test_1(self, completion):
>       assert completion
E       assert <CompletionResult []>

../t/test_iconv.py:7: AssertionError

by applying upstream commit not present in a newer release.
See

https://github.com/scop/bash-completion/commit/2cdac1b9f24df62a1fa80c1824ee8524c9b02393
https://github.com/scop/bash-completion/issues/312

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @peti

Still building for me.
@GrahamcOfBorg build pkgsMusl.bash-completion

@GrahamcOfBorg build pkgsMusl.bash-completion

Still building for me.

Done now.

I changed it to be applied unconditionally: 8031617f3f9


Change addFilteredLogs implementation and add actual log filtering to MockEthersProvider

The previous implementation of addFilteredLogs was wrong in two aspects:

{ traces: undefined } is not strictly equal to {};
When there's some element in Filter.topics that's an array, it means an OR between one or more topics in that position (so it didn't make sense to use an expect.arrayContaining() for this, it would actually be something like expect.toBeIn() (only available in jest-extended). Also, when there's some element in Filter.topics that's null, it means any topic (this was not considered before).

But anyway, it didn't really make sense to do these kinds of checks in this case because the idea of addFilteredLogs(filter, logs) was more like "with this filter as input, getLogs(filter) should return logs". So addFilteredLogs now tests strict equality of the filter object. Whether this is a breaking change or not (also, if it should be mantained or not) is to be discussed.
This PR also adds addLog(logs), which then makes getLogs(filter) actually filter logs like it would be done normally from the logs that were added through this way. If addFilteredLogs(filter2, logs2) is called, it will simply override that behavior when getLogs(filter2) is called.

Note that the package version wasn't bumped because it's not clear if the change to addFilteredLogs should be maintained or not, since it could be considered as a breaking change.

I think we can deprecate addFilterdLog, the new approach looks cleaner to me.

I think we can deprecate addFilteredLogs, the new approach looks cleaner to me.

Actually, do you mean we should just deprecate it (i.e. leave it but mark it as deprecated) or remove it?

Made the changes we commented about, deprecated addFilteredLogs and changed the addLogs log parameter to be an array instead of a rest parameter. I decided to do that because in tests there will probably be a logs array, so removing the need to use ...logs in those cases seems like a good option.


Action._transaction does not read the entire bert response

I ran into an issue where the BERT decoder was failing because of truncated data. The actual error message varies depending on which function the decoder is in when it reaches the end of the data. It turns out that socket.recv was only being called once, even if the length of the data it returned was less than the length of the data indicated by the BERP header.
Here is a gist I've created to demonstrate the problem: https://gist.github.com/1010888 . It includes a python-ernie service that returns an arbitrary amount of data and a python-bertrpc client that reads from this service. It also includes an example terminal session showing both the usage and the error.

Jordan, thank you for the pull request and the detailed error report. I'm sorry that this took so long to get merged -- it fell through the cracks on my end.
This is now merged, and I will release an updated version to PyPI within the next few days.

Thanks, Michael. Better late than never, right? I've CC'ed a couple of guys who may still be interested in this. We had to create a fork (with just this commit AFAIK) because it was a time sensitive fix http://pypi.python.org/pypi/insight-bertrpc/0.1.3.
/cc @tpett @kelredd


WIP: Experiment with running Integration Tests on CI

An experiment with GitHub Actions

All tests that don't require system services (like an X11 server) pass without hassle.
If we can separate out the GTK and DBus tests, we can run all the others on CI.

We could just add a new test category and a corresponding build target.
For example "systemtest" which depends on "integrationtest" and contains only the things which require system services.

As GitHub supports matrix builds we can build and test the code in parallel for Linux / Mac / windows.


Nested Layout patch broken in Beta

Hi I tried VL.Elementa today and I came across the following issue:

I suspect there may be something missing from the current version of VL Beta that this library depends upon.
The error takes me down to Elementa.Core and here:

Of course this means I can't use the library for my project until the next update for vvvv, or rather that I'll have to switch back to the previous iteration until beta's vl gets updated, or is there some way I can fix this?

VL.Elementa should work from beta40 on


[libra_channel] Add feedback mechansim to libra_channel for msg delivery

Motivation
Currently, it is difficult for the sender to know when the message is delivered, if at all. By adding an optional oneshot channel for feedback, the sender can request libra_channel to notify it when the message is delivered to the receiver, or dropped.
Closes: #2123
Have you read the Contributing Guidelines on pull requests?
Y

@bors-libra r+

:pushpin: Commit 711b391 has been approved by ankushagarwal

@bors-libra r=ankushagarwal

:pushpin: Commit 5c0081c has been approved by ankushagarwal

:hourglass: Testing commit 5c0081ca91314a02b0a323a9671b7e3b4ecffb52 with merge 373bb24c7b1b5c78190cb6108c1e722376446d61...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: ankushagarwal
Pushing 373bb24c7b1b5c78190cb6108c1e722376446d61 to master...


mriqc: error: unrecognized arguments: --hmc-fsl

Hi, when trying to go through the MRIQC tutorial from https://andysbrainbook.readthedocs.io/en/latest/OpenScience/OS/MRIQC.html#mriqc-tutorial, I ran into an issue when running the actual script. The error message I got was mriqc: error: unrecognized arguments: --hmc-fsl.

Script from MRIQC tutorial (https://andysbrainbook.readthedocs.io/en/latest/OpenScience/OS/MRIQC.html#mriqc-tutorial):
#!/bin/bash

#User inputs:
bids_root_dir=$HOME/BIDS_tutorial
subj=01
nthreads=2
mem=10 #gb
container=singularity

#Make mriqc directory and participant directory in derivatives folder
if [ ! -d $bids_root_dir/derivatives/mriqc ]; then
mkdir $bids_root_dir/derivatives/mriqc
fi

if [ ! -d $bids_root_dir/derivatives/mriqc/sub-${subj} ]; then
mkdir $bids_root_dir/derivatives/mriqc/sub-${subj}
fi

#Run MRIQC
echo ""
echo "Running MRIQC on participant $s"
echo ""

if [ $container == singularity ]; then
  unset PYTHONPATH; singularity run $HOME/mriqc_0.15.1.simg \
  $bids_root_dir $bids_root_dir/derivatives/mriqc/sub-${subj} \
  participant \
  --n_proc $nthreads \
  --hmc-fsl \
  --correct-slice-timing \
  --mem_gb $mem \
  --float32 \
  --ants-nthreads $nthreads \
  -w $bids_root_dir/derivatives/mriqc/sub-${subj}
else
  docker run -it --rm -v $bids_root_dir:/data:ro -v $bids_root_dir/derivatives/mriqc/sub-${subj}:/out \
  poldracklab/mriqc:0.15.1 /data /out \
  participant \
  --n_proc $nthreads \
  --hmc-fsl \
  --correct-slice-timing \
  --mem_gb $mem \
  --float32 \
  --ants-nthreads $nthreads \
  -w $bids_root_dir/derivatives/mriqc/sub-${subj}
fi

Hi @JanaHermans - I'll look into this, but I can already advance that the action to be taken is actually removing the option. MRIQC is not a preprocessing tool, so how head-motion is calculated should be irrelevant beyond plotting the frame-wise displacement and training models to identify bad data automatically.

Related #904

Okay, just checked and indeed the option got deprecated a while ago, then removed and it does not exist anymore. Please do not use the option. Rationale for the removal is given above.


[Bug] RayService not deploying when enableInTreeAutoscaling is true

Search before asking

[X] I searched the issues and found no similar issues.

KubeRay Component
ray-operator
What happened + What you expected to happen
When deploying a RayService, pods of the ray cluster are not being started if enableInTreeAutoscaling is true. I can see that the RayCluster and RayService resources exist in the Kubernetes cluster.
Here are the logs of the operator:
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:114
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:311
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
2022-10-17T20:13:18.415Z    DEBUG    events    Normal    {"object": {"kind":"RayService","namespace":"ray-serve-prototype-v2","name":"rayservice-xgboost-autoscaling-model","uid":"dcfd592d-208f-4f69-baca-87b0000627c7","apiVersion":"ray.io/v1alpha1","resourceVersion":"62464606"}, "reason": "WaitForDashboard", "message": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
2022-10-17T20:13:18.415Z    INFO    controllers.RayService    Reconciling the cluster component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
2022-10-17T20:13:18.416Z    INFO    controllers.RayService    Reconciling the Serve component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
pod name is too long: len = 67, we will shorten it by offset = 17
2022-10-17T20:13:18.490Z    ERROR    controllers.RayService    Fail to reconcileServe.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model", "error": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:114
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:311
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
2022-10-17T20:13:18.490Z    DEBUG    events    Normal    {"object": {"kind":"RayService","namespace":"ray-serve-prototype-v2","name":"rayservice-xgboost-autoscaling-model","uid":"dcfd592d-208f-4f69-baca-87b0000627c7","apiVersion":"ray.io/v1alpha1","resourceVersion":"62464606"}, "reason": "WaitForDashboard", "message": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
2022-10-17T20:13:20.416Z    INFO    controllers.RayService    Reconciling the cluster component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
pod name is too long: len = 67, we will shorten it by offset = 17
2022-10-17T20:13:20.417Z    INFO    controllers.RayService    Reconciling the Serve component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
2022-10-17T20:13:20.435Z    ERROR    controllers.RayService    Fail to reconcileServe.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model", "error": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:114
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:311
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
2022-10-17T20:13:20.436Z    DEBUG    events    Normal    {"object": {"kind":"RayService","namespace":"ray-serve-prototype-v2","name":"rayservice-xgboost-autoscaling-model","uid":"dcfd592d-208f-4f69-baca-87b0000627c7","apiVersion":"ray.io/v1alpha1","resourceVersion":"62464649"}, "reason": "WaitForDashboard", "message": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
2022-10-17T20:13:20.436Z    INFO    controllers.RayService    Reconciling the cluster component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
2022-10-17T20:13:20.490Z    INFO    controllers.RayService    Reconciling the Serve component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
pod name is too long: len = 67, we will shorten it by offset = 17
2022-10-17T20:13:20.502Z    ERROR    controllers.RayService    Fail to reconcileServe.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model", "error": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:114
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:311
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
2022-10-17T20:13:20.502Z    DEBUG    events    Normal    {"object": {"kind":"RayService","namespace":"ray-serve-prototype-v2","name":"rayservice-xgboost-autoscaling-model","uid":"dcfd592d-208f-4f69-baca-87b0000627c7","apiVersion":"ray.io/v1alpha1","resourceVersion":"62464649"}, "reason": "WaitForDashboard", "message": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
2022-10-17T20:13:22.436Z    INFO    controllers.RayService    Reconciling the cluster component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
2022-10-17T20:13:22.437Z    INFO    controllers.RayService    Reconciling the Serve component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
pod name is too long: len = 67, we will shorten it by offset = 17
2022-10-17T20:13:22.453Z    ERROR    controllers.RayService    Fail to reconcileServe.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model", "error": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:114
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:311
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
2022-10-17T20:13:22.453Z    DEBUG    events    Normal    {"object": {"kind":"RayService","namespace":"ray-serve-prototype-v2","name":"rayservice-xgboost-autoscaling-model","uid":"dcfd592d-208f-4f69-baca-87b0000627c7","apiVersion":"ray.io/v1alpha1","resourceVersion":"62464692"}, "reason": "WaitForDashboard", "message": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
2022-10-17T20:13:22.453Z    INFO    controllers.RayService    Reconciling the cluster component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
2022-10-17T20:13:22.454Z    INFO    controllers.RayService    Reconciling the Serve component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
pod name is too long: len = 67, we will shorten it by offset = 17
2022-10-17T20:13:22.469Z    ERROR    controllers.RayService    Fail to reconcileServe.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model", "error": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:114
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:311
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
2022-10-17T20:13:22.469Z    DEBUG    events    Normal    {"object": {"kind":"RayService","namespace":"ray-serve-prototype-v2","name":"rayservice-xgboost-autoscaling-model","uid":"dcfd592d-208f-4f69-baca-87b0000627c7","apiVersion":"ray.io/v1alpha1","resourceVersion":"62464692"}, "reason": "WaitForDashboard", "message": "Service \"t-autoscaling-model-raycluster-9rtjq-dashboard-svc\" not found"}
2022-10-17T20:13:24.454Z    INFO    controllers.RayService    Reconciling the cluster component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}
2022-10-17T20:13:24.455Z    INFO    controllers.RayService    Reconciling the Serve component.    {"ServiceName": "ray-serve-prototype-v2/rayservice-xgboost-autoscaling-model"}

Reproduction script
Note that the following RayService successfully deploys without enableInTreeAutoscaling: true
apiVersion: ray.io/v1alpha1
kind: RayService
metadata:
  name: rayservice-xgboost-autoscaling-model
spec:
  serviceUnhealthySecondThreshold: 300 # Config for the health check threshold for service. Default value is 60.
  deploymentUnhealthySecondThreshold: 300 # Config for the health check threshold for deployments. Default value is 60.
  serveConfig:
    importPath: example_xgboost.model
  rayClusterConfig:
    rayVersion: '2.0.0' # should match the Ray version in the image of the containers
    enableInTreeAutoscaling: true
    ######################headGroupSpecs#################################
    # head group template and specs, (perhaps 'group' is not needed in the name)
    headGroupSpec:
      # Kubernetes Service Type, valid values are 'ClusterIP', 'NodePort' and 'LoadBalancer'
      serviceType: ClusterIP
      # the pod replicas in this group typed head (assuming there could be more than 1 in the future)
      replicas: 1
      # logical group name, for this called head-group, also can be functional
      # pod type head or worker
      # rayNodeType: head # Not needed since it is under the headgroup
      # the following params are used to complete the ray start: ray start --head --block --redis-port=6379 ...
      rayStartParams:
        port: '6379' # should match container port named gcs-server
        #include_webui: 'true'
        object-store-memory: '100000000'
        # webui_host: "<IP_ADDRESS>"
        dashboard-host: '<IP_ADDRESS>'
        num-cpus: '2' # can be auto-completed from the limits
        node-ip-address: $MY_POD_IP # auto-completed as the head pod IP
        block: 'true'
      #pod template
      template:
        metadata:
          labels:
            # custom labels. NOTE: do not define custom labels start with `raycluster.`, they may be used in controller.
            # Refer to https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
            rayCluster: raycluster-sample # will be injected if missing
            rayNodeType: head # will be injected if missing, must be head or wroker
            groupName: headgroup # will be injected if missing
          # annotations for pod
          annotations:
            key: value
        spec:
          nodeSelector:
            node.kubernetes.io/instance-type: n1-standard-8
          containers:
            - name: ray-head
              image:  <custom image based on rayproject/ray:2.0.0-py38-cu102>
              imagePullPolicy: Always
              #image: bonsaidev.azurecr.io/bonsai/lazer-0-9-0-cpu:dev
              env:
                - name: MY_POD_IP
                  valueFrom:
                    fieldRef:
                      fieldPath: status.podIP
                - name: SERVE_DEPLOYMENT_HANDLE_IS_SYNC
                  value: "0"
              resources:
                limits:
                  cpu: 4
                  memory: 4Gi
                requests:
                  cpu: 4
                  memory: 4Gi
              ports:
                - containerPort: 6379
                  name: gcs-server
                - containerPort: 8265 # Ray dashboard
                  name: dashboard
                - containerPort: 10001
                  name: client
                - containerPort: 8000
                  name: serve
    workerGroupSpecs:
      # the pod replicas in this group typed worker
      - replicas: 3
        minReplicas: 2
        maxReplicas: 5
        # logical group name, for this called small-group, also can be functional
        groupName: small-group
        # if worker pods need to be added, we can simply increment the replicas
        # if worker pods need to be removed, we decrement the replicas, and populate the podsToDelete list
        # the operator will remove pods from the list until the number of replicas is satisfied
        # when a pod is confirmed to be deleted, its name will be removed from the list below
        #scaleStrategy:
        #  workersToDelete:
        #  - raycluster-complete-worker-small-group-bdtwh
        #  - raycluster-complete-worker-small-group-hv457
        #  - raycluster-complete-worker-small-group-k8tj7
        # the following params are used to complete the ray start: ray start --block --node-ip-address= ...
        rayStartParams:
          node-ip-address: $MY_POD_IP
          block: 'true'
        #pod template
        template:
          metadata:
            labels:
              key: value
            # annotations for pod
            annotations:
              key: value
          spec:
            nodeSelector:
              node.kubernetes.io/instance-type: n1-standard-8
            initContainers:
              # the env var $RAY_IP is set by the operator if missing, with the value of the head service name
              - name: init-myservice
                image: busybox:1.28
                command: ['sh', '-c', "until nslookup $RAY_IP.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
            containers:
              - name: machine-learning # must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc'
                image: <custom image based on rayproject/ray:2.0.0-py38-cu102>
                imagePullPolicy: Always
                # environment variables to set in the container.Optional.
                # Refer to https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/
                env:
                  - name:  RAY_DISABLE_DOCKER_CPU_WARNING
                    value: "1"
                  - name: TYPE
                    value: "worker"
                  - name: CPU_REQUEST
                    valueFrom:
                      resourceFieldRef:
                        containerName: machine-learning
                        resource: requests.cpu
                  - name: CPU_LIMITS
                    valueFrom:
                      resourceFieldRef:
                        containerName: machine-learning
                        resource: limits.cpu
                  - name: MEMORY_LIMITS
                    valueFrom:
                      resourceFieldRef:
                        containerName: machine-learning
                        resource: limits.memory
                  - name: MEMORY_REQUESTS
                    valueFrom:
                      resourceFieldRef:
                        containerName: machine-learning
                        resource: requests.memory
                  - name: MY_POD_NAME
                    valueFrom:
                      fieldRef:
                        fieldPath: metadata.name
                  - name: MY_POD_IP
                    valueFrom:
                      fieldRef:
                        fieldPath: status.podIP
                  - name: SERVE_DEPLOYMENT_HANDLE_IS_SYNC
                    value: "0"
                ports:
                  - containerPort: 80
                    name: client
                lifecycle:
                  preStop:
                    exec:
                      command: ["/bin/sh","-c","ray stop"]
                resources:
                  limits:
                    cpu: "2"
                    memory: "2Gi"
                  requests:
                    cpu: "2"
                    memory: "2Gi"

Anything else
I'm using a namespace-scope operator and the nightly image of Kuberay
apiVersion: v1
kind: Namespace
metadata:
  name: ray-serve-prototype-v2
  labels:
    app: ray
---
#############################################################################################################
# Operator-related
#############################################################################################################
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
    app: ray
  name: kuberay-operator
  namespace: ray-serve-prototype-v2
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  labels:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
  name: kuberay-operator
  namespace: ray-serve-prototype-v2
rules:
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - create
  - get
  - list
  - update
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - pods/status
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
  - delete
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingressclasses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ray.io
  resources:
  - rayclusters
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ray.io
  resources:
  - rayclusters/finalizer
  verbs:
  - update
- apiGroups:
  - ray.io
  resources:
  - rayclusters/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ray.io
  resources:
  - rayjobs
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ray.io
  resources:
  - rayjobs/finalizer
  verbs:
  - update
- apiGroups:
  - ray.io
  resources:
  - rayjobs/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ray.io
  resources:
  - rayservices
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ray.io
  resources:
  - rayservices/finalizers
  verbs:
  - update
- apiGroups:
  - ray.io
  resources:
  - rayservices/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - rolebindings
  verbs:
  - create
  - delete
  - get
  - list
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - roles
  verbs:
  - create
  - delete
  - get
  - list
  - update
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
  name: kuberay-operator-leader-election
  namespace: ray-serve-prototype-v2
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - ""
  resources:
  - configmaps/status
  verbs:
  - get
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
  name: kuberay-operator
  namespace: ray-serve-prototype-v2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kuberay-operator
subjects:
- kind: ServiceAccount
  name: kuberay-operator
  namespace: ray-serve-prototype-v2
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
  name: kuberay-operator-leader-election
  namespace: ray-serve-prototype-v2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kuberay-operator-leader-election
subjects:
- kind: ServiceAccount
  name: kuberay-operator
  namespace: ray-serve-prototype-v2
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/path: /metrics
    prometheus.io/port: "8080"
    prometheus.io/scrape: "true"
  labels:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
  name: kuberay-operator
  namespace: ray-serve-prototype-v2
spec:
  ports:
  - name: monitoring-port
    port: 8080
    targetPort: 8080
  selector:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: kuberay-operator
    app.kubernetes.io/name: kuberay
    app: ray
  name: kuberay-operator
  namespace: ray-serve-prototype-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: kuberay-operator
      app.kubernetes.io/name: kuberay
  template:
    metadata:
      labels:
        app.kubernetes.io/component: kuberay-operator
        app.kubernetes.io/name: kuberay
    spec:
      containers:
      - command:
        - /manager
        - -watch-namespace
        - ray-serve-prototype-v2
        image: kuberay/operator:nightly
        livenessProbe:
          failureThreshold: 5
          httpGet:
            path: /metrics
            port: http
          initialDelaySeconds: 10
          periodSeconds: 5
        name: kuberay-operator
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        readinessProbe:
          failureThreshold: 5
          httpGet:
            path: /metrics
            port: http
          initialDelaySeconds: 10
          periodSeconds: 5
        resources:
          limits:
            cpu: 100m
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 50Mi
        securityContext:
          allowPrivilegeEscalation: false
      securityContext:
        runAsNonRoot: true
      serviceAccountName: kuberay-operator
      terminationGracePeriodSeconds: 10

Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Thanks for all of the details! I will take a look.

Reproduced the issue with the provided config. Looking into causes.

I've identified the issue -- there's a bug stemming from inconsistency in the RayCluster controller's naming for autoscaler's Role. The bug only occurs when the name of RayCluster is long enough, which is liable to happen with the RayCluster name generated by the RayService controller.
I will open a PR fixing the bug.
The short-term workaround is to use a shorter name for your RayService.

I was able to deploy the RayService successfully by shortening its name to "rxam".

Not to conflate issues, but we're also seeing an issue where the head-svc endpoint names are being truncated for names > 50 characters, could this be related?

Truncation is necessary due to K8s length limits.
Let me go back and fix the issue with char length limits -- it slipped my mind.

Fix: https://github.com/ray-project/kuberay/pull/689


PropertyListReadStreamException: Unexpected end of plist

Input plist  https://gist.github.com/iulian0512/fe8e8a1629346d459deadac9057c3c84
test code
 var xmlStr = File("/Users/ics/gitlab/mobileapp/ios/Runner/Info.plist").readAsStringSync();
 var lst = PropertyListSerialization.propertyListWithString(xmlStr) as List;

issue appears to happen if after the closing tag there is no newline

Hi good spotting. This is fixed in version 1.1.1
Please allow 30 minutes for dart.pub to finish processing this package version before attempting to upgrade.

apart from that very useful library, great work, thanks.