how to import the stock indicators?

how to import the stock technical indicators, such as ema, sma? thanks

Found it. The traditional script include. Otherwise, just load it the same as highmap or stocks

Hi @xunxdd, I have the same question, i.e. how to add technical indicators.
I tried doing something like this:
  mounted () {
    let indicatorsAll = document.createElement('script')
    indicatorsAll.setAttribute('src', 'https://code.highcharts.com/stock/indicators/indicators-all.js')
    document.head.appendChild(indicatorsAll)

    let dragPanes = document.createElement('script')
    dragPanes.setAttribute('src', 'https://code.highcharts.com/stock/modules/drag-panes.js')
    document.head.appendChild(dragPanes)

    let annotationsAdvanced = document.createElement('script')
    annotationsAdvanced.setAttribute('src', 'https://code.highcharts.com/modules/annotations-advanced.js')
    document.head.appendChild(annotationsAdvanced)

    let priceIndicator = document.createElement('script')
    priceIndicator.setAttribute('src', 'https://code.highcharts.com/modules/price-indicator.js')
    document.head.appendChild(priceIndicator)

    let fullScreen = document.createElement('script')
    fullScreen.setAttribute('src', 'https://code.highcharts.com/modules/full-screen.js')
    document.head.appendChild(fullScreen)

    let stockTools = document.createElement('script')
    stockTools.setAttribute('src', 'https://code.highcharts.com/modules/stock-tools.js')
    document.head.appendChild(stockTools)
  },

but it doesn't seem to work.
My template is this:
<template>
  <highstock :options="ohlcv" ref="highcharts"></highstock>
</template>

And in vue.js I have this:
import VueHighcharts from 'vue-highcharts'
import Highcharts from 'highcharts'
import loadStock from 'highcharts/modules/stock'
loadStock(Highcharts)
Vue.use(VueHighcharts, { Highcharts })

Thanks!

@mmagerl
import VueHighcharts from 'vue-highcharts'
import Highcharts from 'highcharts'
import loadStock from 'highcharts/modules/stock'
import loadIndicatorsAll from 'highcharts/indicators/indicators-all'
loadStock(Highcharts)
loadIndicatorsAll(Highcharts)
Vue.use(VueHighcharts, { Highcharts })


Staking rewards accrue differently when redelegated

As this test demonstrates staking rewards seem to accrue differently if some of those rewards are redelegated during a period. My understanding of the staking rewards implementation is that a redelegation that happens instantly should not impact accrued staking rewards, though I could be wrong.

I think we have encountered the same bug and I fixed it in 9ca9d81de3284b3c6e22f8e900e59db4f7803d0c. Can you check if that fixes it?


[REVIEW] change confirmation label Agent to Controller and Dashboard

Fixed https://github.com/leap-solutions-asia/auto-scaling/issues/9
Install Auto Scaling Controller and Dashboard? [y/n]:

It's only changing label. I'll merge it.


use adapter-node as fallback in adapter-auto

Describe the problem
while building locally, the environement is undetectable so i guess no any adapter is used, but i think adpater-node should be used for fallback.
Describe the proposed solution
Add @sveltejs/adapter-node to fallback adapter
Alternatives considered
No response
Importance
would make my life easier
Additional Information
No response

I'm not sure about this. I'm concerned that, in trying to be helpful, this would actually cause more confusion. The other existing auto adapters are set up to be pretty much just that: automatic. You send the app source off to them, and they build it, and it deploys. There are presumably a number of other steps that are needed when using the Node adapter. You need to worry about the server installing just the prod dependencies. You maybe need to worry about Docker. You need to worry about some sort of reverse SSL proxy in front of the Node server. This all prevents adapter-node from being as automatic as the Cloudflare/Netlify/Vercel ones, and I don't think it should pretend to be.

It might be a little hack-y, but I've been using this to make something similar work in one of my projects
import autoAdapter from "@sveltejs/adapter-auto"
import nodeAdapter from "@sveltejs/adapter-node"

export default {
  kit: {
    adapter: process.env.IS_VERCEL ? autoAdapter() : nodeAdapter(),
  },
  ...
}

In our case, we want to self-host the app with Node, but also have Vercel serving our PRs without having to do some weird double config re-naming hack in our Dockerfile

instead of using hacky way, I guess it would be better to provide an option to use specified adapter as fallback

You maybe need to worry about

if possible, wouldn't it be great if there's an option to use fallback adapter like:
import adapter from "@svelte/adapter-auto";
import adapterNode from "@svelte/adapter-node";

export default {
   kit: {
       adapter: adapter({ fallback: "node" })
       // or: adapter: adapter({ fallback: adapterNode })
   }
}

I agree with adding a fallback to the options that are passed to the adapter.

This isn't hacky, it's a perfectly sensible solution (though I'd change it to adapter-vercel and just use process.env.VERCEL since that's set automatically when you're on Vercel):
export default {
  kit: {
    adapter: process.env.IS_VERCEL ? autoAdapter() : nodeAdapter(),
  },
  ...
}

Defaulting to adapter-node would be a terrible idea — if the environment isn't recognised, adapter-auto shouldn't start making wild assumptions about what you want. It should tell you that no supported environment can be detected and point you towards the relevant documentation (which is exactly what happens).


feature Support refresh mtmv

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.82 seconds
load time: 489 seconds
storage size:<PHONE_NUMBER>6 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230129174015_clickbench_pr_86591.html


libuvc - test_libuvc.c - errno: 22

Hi, there.
I try to test linuvc library and got the following report.
[V4L2 Input information]:
	input.name: 	"Camera 1"
			 CAMERA
[V4L2 Capability Information]:
	cap.driver: 	"uvcvideo"
	cap.card: 	"XiaoMi USB 2.0 Webcam: XiaoMi U"
	cap.bus_info: 	"usb-0000:00:14.0-5"
	cap.version: 	"266002"
	cap.capabilities:
			 VIDEO_CAPTURE
			 STREAMING
[V4L2 Support Format]:
	0. [YUYV] "YUYV 4:2:2"
	1. [MJPG] "Motion-JPEG"
[V4L2 Supported Control]:
	Brightness, range: [-64, 64], default: 0, current: 0
	Contrast, range: [0, 95], default: 0, current: 0
	Saturation, range: [0, 100], default: 64, current: 64
	Hue, range: [-2000, 2000], default: 0, current: 0
	White Balance Temperature, Auto, range: [0, 1], default: 1, current: 1
	Gamma, range: [100, 300], default: 100, current: 100
	Power Line Frequency, range: [0, 2], default: 1, current: 1
	White Balance Temperature, range: [2800, 6500], default: 4600, current: 4600
	Sharpness, range: [1, 7], default: 2, current: 2
	Backlight Compensation, range: [0, 3], default: 3, current: 3
v4l2_buf_enqueue - ioctl(VIDIOC_QBUF) failed: 22

The last line report errno = 22. My host is Ubutun 16.04. And the output yuv file cannot be played by ffplay without any modification of source code.

"ioctl(VIDIOC_QBUF) failed: 22" is not bug exactily, just enqueue one more time firstly.
I have fixed it. you can play yuv with
"ffplay -f rawvideo -pixel_format yuyv422 -video_size 640x480 uvc.yuv"


Invisible when using VerticalOptions="StartAndExpand"

Problem
The carousel view seems to be unable to calculate its own height based on its content when using the start and expand vertical option. When using a specific height or the fill and expand vertical option the carousel view does show up. I've only tested it on Android as I don't have a MacBook availible to use at the moment.
Code used
<cvcontrols:CarouselViewControl x:Name="DontsCarousel" Orientation="Horizontal" ItemsSource="{Binding Donts}" VerticalOptions="StartAndExpand" HorizontalOptions="FillAndExpand" ShowIndicators="True" InterPageSpacing="20" BackgroundColor="Yellow">
    <cvcontrols:CarouselViewControl.ItemTemplate>
        <DataTemplate>
            <Grid>
                <Grid.RowDefinitions>
                    <RowDefinition Height="Auto" />
                    <RowDefinition Height="Auto" />
                </Grid.RowDefinitions>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition Width="Auto" />
                </Grid.ColumnDefinitions>
                <Image Source="{Binding ImageSrc}" HorizontalOptions="FillAndExpand" Aspect="AspectFill" Grid.Row="0" Grid.RowSpan="2" />
                <BoxView BackgroundColor="AliceBlue" Opacity=".7" Grid.Row="1" />
                <Label Text="{Binding Description}" HorizontalOptions="Center" VerticalOptions="Center" HorizontalTextAlignment="Center" Grid.Row="1" Margin="0, 10, 0, 10" />
            </Grid>
        </DataTemplate>
    </cvcontrols:CarouselViewControl.ItemTemplate>
</cvcontrols:CarouselViewControl>

Packages used
CarouselView.FormsPlugin => 5.2.0
Forms => <IP_ADDRESS>0555

This control has been merged into Xamarin.Forms master branch. Please, wait for it to be released as part of Xamarin.Forms and submit any issues there https://github.com/xamarin/xamarin.forms/tree/feature-carouselview. Thanks

I think it will be before 3.0 but not sure about that.

OK, how will we be updated ?


[BUG] depthai_ros_driver camera.launch.py crashes "double free detected in tcache 2"

Describe the bug
When I ran ros2 launch depthai_ros_driver camera.launch.py, it crashes at a random time with the error
[component_container-2] free(): double free detected in tcache 2
[ERROR] [component_container-2]: process has died [pid 55444, exit code -6, cmd '/opt/ros/humble/install/lib/rclcpp_components/component_container --ros-args --log-level debug --ros-args -r __node:=oak_container -r __ns:=/'].

Minimal Reproducible Example
Run ros2 launch depthai_ros_driver camera.launch.py with default parameters.
(stereo_inertial_node in depthai_examples works well.)
Attach system log
Logs are here:
log.txt
log_system_information.json.txt
I am using a Jetson Orin Nano.

It is built from source. I've just updated depthai-core to 2.22.0, and depthai-ros to 2.7.3
It also happens with ros2 launch depthai_ros_driver example_marker_publish.launch.py, maybe more quickly

Same problem here

Does it also happen with rgbd_pcl.launch.py?

Looks good on this side

Any news on this issue? I'd like to use the ROS driver with 2d object detection but it crashes too often

Same problem here -- I've also installed from source from the latest humble branch.

@Serafadam I've encountered this problem on Ubuntu 22.04 with ROS2 Humble. I'm able to run the driver on v2.7.1 but then the point cloud rates is extremely slow. It gives a cloud at every minute or so. I'll give it a try with Docker. I can send the full log if it helps.

Sure, it would be nice if you provide information as in bug template. When it comes to the pointcloud rate, that could depend on the network/DDS setup

Hi, I was experiencing the same issue, both on a Ubuntu 22 laptop and a PI4. After attaching myself with a debugger, I narrowed the error to the IMU interpolation function (to be exact line 182 of ImuConverter.hpp).
The workaround I found is to set the sync method to COPY. Here is my pcl.yaml:
/oak:
  ros__parameters:
    camera:
      i_nn_type: none
    right:
      i_publish_topic: true
    stereo:
      i_align_depth: false
      i_subpixel: true
    imu:
      i_sync_method: COPY

Although I'm not sure if this is the cause as stereo_inertial_method uses same sync method, could you try it out @FabienDanieau  @tkelestemur-bdai ?

Indeed I do not have the error with i_sync_method: COPY

@Serafadam +1, this workaround resolves the issue for me as well (same lab as @tkelestemur-bdai)
@BOOTCFG nice detective work, thanks!

Hi @FabienDanieau, @ksharma-bdai could you check if this branch works for you?

Hi @FabienDanieau, @ksharma-bdai could you check if this branch works for you?

I'll try to give it a test today or tomorrow (otherwise I'll be away until next week). Assuming the branch is: https://github.com/luxonis/depthai-ros/tree/imu_sync_fix_humble ?

Yes, sorry, for some reason the link didn't display properly

Yes, sorry, for some reason the link didn't display properly

Unfortunately it's still crashing when built from source (verified it's running the branch with a few printouts). Happy to run with any debug that could be useful. This was tested with the OAK-D Pro Wide USB.
Our devices will be under test and I'll be away starting Wednesday, but can resume testing next week.

I've pushed some additional changes

I've pushed some additional changes

No crashes after ~10 minutes on the updated branch with the same OAK-D Pro Wide USB camera (crashes within ~1 minute on apt version). I'm currently only able to verify it does not crash and rgb/depth streams to rviz, I don't have a known good regression test suite - so it would be nice if anyone else can confirm,
Thanks for the updates and let me know if there's anything else I can help with (will be out of contact the rest of this week after today).

I am also seeing the issue. Just to add - it is on Ethernet version of OAK-D Pro W.

@asimonov you can try the fix for noetic here

yes, this works without crashes for me.
ubuntu 20 inside docker on jetson orin NX with jetpack 5.1.1.
Oak-D Pro W Ethernet version.

Hi @FabienDanieau, @ksharma-bdai could you check if this branch works for you?
Sorry I was away. I'll test it asap.

Closing due to inactivity, please reopen if the issues still appear.


sqlglot_lineage: Node class has no attribute subfield

Describe the bug
When trying to extract column lineage from an sql query I get an error Node has no attribute subfield.
After looking at sqlglot Node class, the subfield attribute is missing.
sqlglot Node
The reference to node.subfield is at sqlglot_lineage.py in the function _get_direct_raw_col_upstreams.
We can warp this piece of code with a try ... except and that will solve this issue, but maybe this lines aren't relevant anymore.

Looks good. thanks!


Use default open mode in IFS search and find results

Changes
This PR will add a readonly value to IFS search and find results, to honor the default open mode set in the configurations.
When default open mode is browse, clicking on a search/find result will open the file in readonly mode.
How to test this PR
Examples:

Set the default open mode to browse in the extension configuration
Create a search or find result
Click on one of the search/find results
Confirm the file is opened on readonly mode
Change the default open mode to edit in the extension configuration
Re-run steps 2 and 3
Confirm the file is opened in edit mode

Checklist

[x] have tested my change

but it would be better to simply call the code-for-ibmi.openWithDefaultMode command

That was exactly my first attempt... but then the readonly attribute from the result view would be ignored, and we probably would like to propagate the value when the server or directory being searched is protected (would require further changes...), so I opted for this intermediate solution.
WDYT?

Hmmm...code-for-ibmi.openWithDefaultMode calls code-for-ibmi.openEditable with the default open mode.
code-for-ibmi.openEditable also checks if the path is protected, or even writable, etc.
Actually, just swapping code-for-ibmi.openEditable with code-for-ibmi.openWithDefaultMode and keeping both arguments should do the trick. That will open using the default mode BUT honor the readonly flag in priority if it is true.

Actually, just swapping code-for-ibmi.openEditable with code-for-ibmi.openWithDefaultMode and keeping both arguments should do the trick. That will open using the default mode BUT honor the readonly flag in priority if it is true.

But that didn't work for me... openWithDefaultMode wouldn't call the GlobalConfiguration.get function, even though overrideMode was undefined...?!
I can give it another shot...?

I think I understand: it will check the configuration if there is no overrideMode.
https://github.com/codefori/vscode-ibmi/blob/ab4d38c4cc20e7139726850d17edd465dd48013c/src/instantiate.ts#L676
So I think the correct way to call the command from the search view would be:
this.command = {
  command: `code-for-ibmi.openWithDefaultMode`,
  title: `Open`,
  arguments: [this._path, this._readonly  ? 'browse' as DefaultOpenMode : undefined]
};

Forcing browse only when the view is in read-only mode will leave it up to the command to decide how to open the editor otherwise.

@sebjulliand Seems to work now - for find results only!
Search results have the additional option of range, using type OpenEditableOptions, which is not supported by openWithDefaultMode... 😢
This is a case for our TypeScript guru! 🙏


ambient does not work on minikube

Is this the right place to submit this?

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

Bug Description
Follow this: https://istio.io/latest/docs/ops/ambient/getting-started/
I did not install Gateway APIs. I followed the "Istio APIs" instructions to install:
istioctl install --set profile=ambient --set components.ingressGateways[0].enabled=true --set components.ingressGateways[0].name=istio-ingressgateway --skip-confirmation

Cluster is minikube. I'm using a Istio 1.19-dev build (see "Version" field for details).
Things look installed properly:
$ kubectl get pods -n bookinfo
NAME                              READY   STATUS    RESTARTS   AGE
details-v1-7745b6fcf4-79m8s       1/1     Running   0          68s
productpage-v1-6f89b6c557-ccpth   1/1     Running   0          68s
ratings-v1-77bdbf89bb-ndv8b       1/1     Running   0          68s
reviews-v1-667b5cc65d-dzslp       1/1     Running   0          68s
reviews-v2-6f76498fc8-2mdfv       1/1     Running   0          68s
reviews-v3-5d8667cc66-j6m8x       1/1     Running   0          68s

$ kubectl get pods,ds -n istio-system
NAME                                       READY   STATUS    RESTARTS   AGE
pod/istio-cni-node-9nd56                   1/1     Running   0          9m55s
pod/istio-ingressgateway-7d67669df-9dgpg   1/1     Running   0          9m55s
pod/istiod-7c6f4d8478-26gc8                1/1     Running   0          10m
pod/ztunnel-tcpg8                          1/1     Running   0          10m

NAME                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/istio-cni-node   1         1         1       1            1           kubernetes.io/os=linux   9m55s
daemonset.apps/ztunnel          1         1         1       1            1           kubernetes.io/os=linux   10m

But there are errors in the CNI daemonset.. see cni-errors.log which is from kubectl logs -n istio-system daemonset/istio-cni-node  > cni-errors.log
First error in the logs is:
2023-07-25T12:41:04.140628Z	warn	ambient	unable to list IPSet: failed to list ipset ztunnel-pods-ips: no such file or directory

with a bunch of
2023-07-25T12:41:16.745442Z	warn	ambient	Error running command iptables-legacy: iptables: No chain/target/match by that name.

and then
2023-07-25T12:41:16.773229Z	error	controllers	error handling istio-system/ztunnel-tcpg8, retrying (retry count: 1): failed to get veth device: no routes found for <IP_ADDRESS>	controller=ambient

Version
$ istioctl version
client version: 1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a
control plane version: 1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a
data plane version: 1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a (2 proxies)

$ kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.26.1
Kustomize Version: v4.5.7
Server Version: v1.26.3

Minikube (relevant for this issue; this error doesn't happen with KinD):
$ minikube version
minikube version: v1.30.1
commit: 08896fd1dc362c097c925146c4a0d0dac715ace0

Operating System/Hardware:
$ uname -a
Linux jmazzite-thinkpadp1gen3.ttn.csb 6.3.12-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul  6 04:05:18 UTC 2023 x86_64 GNU/Linux

$ cat /etc/redhat-release
Fedora release 38 (Thirty Eight)

### Additional Information

[bug-report.tar.gz](https://github.com/istio/istio/files/12161334/bug-report.tar.gz)

### Affected product area

- [X] Ambient
- [ ] Docs
- [ ] Installation
- [ ] Networking
- [ ] Performance and Scalability
- [ ] Extensions and Telemetry
- [ ] Security
- [ ] Test and Release
- [ ] User Experience
- [ ] Developer Infrastructure
- [ ] Upgrade
- [ ] Multi Cluster
- [ ] Virtual Machine
- [ ] Control Plane Revisions

Link to bug-report.tar.gz

I tried starting minikube with --cni=kindnet but still getting errors.

kubectl logs -n istio-system daemonsets/istio-cni-node  > kindnet.log: kindnet.log
istioctl bug-report: bug-report.tar.gz

The initial warns are from node cleanup, as the logs mention, they're not relevant and are only logged as WARN:
ambient Node-level network rule cleanup started
2023-07-25T11:49:32.823752Z info    ambient If rules do not exist in the first place, warnings will be triggered - these can be safely ignored
...(warn)
...(warn)
2023-07-25T11:49:32.899316Z info    ambient Node-level cleanup done

This is an actual error, however:
2023-07-25T11:49:32.899398Z error   controllers error handling istio-system/ztunnel-7vggw, retrying (retry count: 1): failed to get veth device: no routes found for <IP_ADDRESS> controller=ambient

CNI can't seem to find a route for the pod IP, and so the node initialization fails before it gets to creating the ipset.   This is effectively a catastrophic failure - it doesn't put the CNI agent into an unready state - it should.
Check istio-system - I bet your ztunnel pods are unhealthy - there should be one-per-node, but if there's no route to your node's ztunnel IP, that's a bit odd and points to a non-istio problem.

Check istio-system - I bet your ztunnel pods are unhealthy. There should/must be a route to the ztunnel pod IP if the ztunnel pod is actually running in a correctly configured k8s cluster.

ztunnel pod and DS both look OK (the resource yaml for both are further down below):
$ kubectl get pods -n istio-system -l app=ztunnel
NAME            READY   STATUS    RESTARTS   AGE
ztunnel-thlvf   1/1     Running   0          7m13s

$ kubectl get ds -n istio-system ztunnel
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
ztunnel   1         1         1       1            1           kubernetes.io/os=linux   7m18s

Ztunnel pod logs:
$ kubectl logs -n istio-system -l app=ztunnel --tail=-1
2023-07-25T23:49:50.141644Z  INFO ztunnel: version: version.BuildInfo{Version:"33af17df795052ab725c35c98332d6aa3fc9535b", GitRevision:"33af17df795052ab725c35c98332d6aa3fc9535b", RustVersion:"1.71.0", BuildStatus:"Clean", GitTag:"1.19.0-alpha.1-26-g33af17d", IstioVersion:"unknown"}
2023-07-25T23:49:50.141714Z  INFO ztunnel: running with config: proxy: true
dns_proxy: false
window_size: 4194304
connection_window_size: 4194304
frame_size: 1048576
socks5_addr: <IP_ADDRESS>:15080
admin_addr: <IP_ADDRESS>:15000
stats_addr: '[::]:15020'
readiness_addr: '[::]:15021'
inbound_addr: '[::]:15008'
inbound_plaintext_addr: '[::]:15006'
outbound_addr: '[::]:15001'
dns_proxy_addr: '[::]:15053'
network: ''
local_node: minikube
proxy_mode: Shared
local_ip: <IP_ADDRESS>
cluster_id: Kubernetes
cluster_domain: cluster.local
ca_address: https://istiod.istio-system.svc:15012
ca_root_cert: !File ./var/run/secrets/istio/root-cert.pem
xds_address: https://istiod.istio-system.svc:15012
xds_root_cert: !File ./var/run/secrets/istio/root-cert.pem
xds_on_demand: false
fake_ca: false
self_termination_deadline:
  secs: 5
  nanos: 0
proxy_metadata:
  ISTIO_VERSION: 1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a
num_worker_threads: 2
enable_original_source: null
proxy_args: proxy ztunnel

2023-07-25T23:49:50.141919Z  INFO ztunnel::hyper_util: listener established address=[::]:15020 component="stats"
2023-07-25T23:49:50.141944Z  INFO ztunnel::hyper_util: listener established address=<IP_ADDRESS>:15000 component="admin"
2023-07-25T23:49:50.141965Z  INFO ztunnel::proxy::inbound: listener established address=[::]:15008 component="inbound" transparent=true
2023-07-25T23:49:50.141979Z  INFO ztunnel::proxy::inbound_passthrough: listener established address=[::]:15006 component="inbound plaintext" transparent=true
2023-07-25T23:49:50.141990Z  INFO ztunnel::proxy::outbound: listener established address=[::]:15001 component="outbound" transparent=true
2023-07-25T23:49:50.142005Z  INFO ztunnel::proxy::socks5: listener established address=<IP_ADDRESS>:15080 component="socks5"
2023-07-25T23:49:50.142009Z  INFO ztunnel::hyper_util: listener established address=[::]:15021 component="readiness"
2023-07-25T23:49:50.142017Z  INFO ztunnel::readiness: Task 'proxy' complete (1.602693ms), still awaiting 1 tasks
2023-07-25T23:49:50.145633Z  INFO ztunnel::xds::client: sending initial request resources=0 type_url="type.googleapis.com/istio.workload.Address"
2023-07-25T23:49:50.145655Z  INFO ztunnel::xds::client: sending initial request resources=0 type_url="type.googleapis.com/istio.security.Authorization"
2023-07-25T23:49:50.148625Z  INFO xds{id=1}: ztunnel::xds::client: Stream established
2023-07-25T23:49:50.148676Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=13
2023-07-25T23:49:50.148712Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/kube-system/registry-nr2cc
2023-07-25T23:49:50.148724Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/istiod-7c6f4d8478-jv5wj
2023-07-25T23:49:50.148730Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/kube-system/registry-proxy-dq9p5
2023-07-25T23:49:50.148734Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/kube-system/coredns-787d4945fb-zn7sc
2023-07-25T23:49:50.148740Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/ingress-nginx/ingress-nginx-controller-6cc5ccb977-9dpcj
2023-07-25T23:49:50.148765Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.security.Authorization" size=0
2023-07-25T23:49:50.148773Z  INFO ztunnel::readiness: Task 'state manager' complete (8.358733ms), marking server ready
2023-07-25T23:49:50.492388Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:49:50.492481Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/ztunnel-thlvf
2023-07-25T23:49:58.550705Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:49:58.550787Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/istio-egressgateway-78957ffb6-67rn2
2023-07-25T23:49:59.362577Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:49:59.362615Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/istio-egressgateway-78957ffb6-67rn2
2023-07-25T23:50:06.703472Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:50:06.703673Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/istio-ingressgateway-7d67669df-wsbth
2023-07-25T23:50:09.798993Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:50:10.021420Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:50:10.419592Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=3
2023-07-25T23:50:27.331479Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:50:27.331610Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/grafana-7bd5db55c4-dvff2
2023-07-25T23:50:32.441886Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:50:32.441926Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/jaeger-78756f7d48-qjq2f
2023-07-25T23:50:40.511249Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:50:40.511285Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/grafana-7bd5db55c4-dvff2
2023-07-25T23:50:47.657471Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:50:47.657547Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/istio-system/prometheus-67f6764db9-ngsmz
2023-07-25T23:51:37.878201Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=3
2023-07-25T23:51:38.019844Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:51:50.441269Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:51:50.441301Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/bookinfo/details-v1-7745b6fcf4-kn94s
2023-07-25T23:52:01.580019Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:52:01.580131Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/bookinfo/ratings-v1-77bdbf89bb-mcwn7
2023-07-25T23:52:48.221120Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=2
2023-07-25T23:52:48.221176Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/bookinfo/reviews-v1-667b5cc65d-9bd2m
2023-07-25T23:52:48.221208Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/bookinfo/reviews-v3-5d8667cc66-nxd9n
2023-07-25T23:52:49.204452Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:52:49.204485Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/bookinfo/reviews-v2-6f76498fc8-tf75h
2023-07-25T23:53:03.459096Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:53:03.459154Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/bookinfo/productpage-v1-6f89b6c557-6l4cw
2023-07-25T23:53:04.617903Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.workload.Address" size=1
2023-07-25T23:53:04.618114Z  INFO xds{id=1}: ztunnel::xds: handling delete Kubernetes//Pod/bookinfo/productpage-v1-6f89b6c557-6l4cw
2023-07-25T23:53:04.619739Z  INFO xds{id=1}: ztunnel::xds::client: received response type_url="type.googleapis.com/istio.security.Authorization" size=1
2023-07-25T23:53:04.619905Z  INFO xds{id=1}: ztunnel::xds: handling RBAC update productpage-viewer

Here's the tail of the istio-cni-node logs:
$ kubectl logs -n istio-system istio-cni-node-2j8xj --tail=5

2023-07-25T23:53:03.341290Z	info	ambient	Adding pod 'productpage-v1-6f89b6c557-6l4cw/bookinfo' (cfb8a61d-04b2-4e35-9006-2ef333ac2805) to ipset
2023-07-25T23:53:03.347177Z	info	ambient	Adding route for productpage-v1-6f89b6c557-6l4cw/bookinfo: [table 100 <IP_ADDRESS>/32 via <IP_ADDRESS> dev istioin src <IP_ADDRESS>]
2023-07-25T23:53:03.349911Z	warn	ambient	Failed to add route ([table 100 <IP_ADDRESS>/32 via <IP_ADDRESS> dev istioin src <IP_ADDRESS>]) for pod productpage-v1-6f89b6c557-6l4cw: Cannot find device "istioin"

ztunnel pod YAML:
$ kubectl get -n istio-system pods -l app=ztunnel -oyaml
apiVersion: v1
items:
- apiVersion: v1
  kind: Pod
  metadata:
    annotations:
      ambient.istio.io/redirection: disabled
      cni.projectcalico.org/allowedSourcePrefixes: '["<IP_ADDRESS>/0"]'
      prometheus.io/port: "15020"
      prometheus.io/scrape: "true"
      sidecar.istio.io/inject: "false"
    creationTimestamp: "2023-07-25T23:49:30Z"
    generateName: ztunnel-
    labels:
      app: ztunnel
      controller-revision-hash: 5577d475d5
      pod-template-generation: "1"
      sidecar.istio.io/inject: "false"
    name: ztunnel-thlvf
    namespace: istio-system
    ownerReferences:
    - apiVersion: apps/v1
      blockOwnerDeletion: true
      controller: true
      kind: DaemonSet
      name: ztunnel
      uid: a86eb416-288f-4252-8480-0dd95494156f
    resourceVersion: "846"
    uid: e6f0414c-d539-482e-8cdc-30634253a916
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchFields:
            - key: metadata.name
              operator: In
              values:
              - minikube
    containers:
    - args:
      - proxy
      - ztunnel
      env:
      - name: CLUSTER_ID
        value: Kubernetes
      - name: POD_NAME
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: metadata.name
      - name: POD_NAMESPACE
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: metadata.namespace
      - name: NODE_NAME
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: spec.nodeName
      - name: INSTANCE_IP
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: status.podIP
      - name: SERVICE_ACCOUNT
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: spec.serviceAccountName
      image: gcr.io/istio-testing/ztunnel:1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a
      imagePullPolicy: IfNotPresent
      name: istio-proxy
      ports:
      - containerPort: 15020
        name: ztunnel-stats
        protocol: TCP
      readinessProbe:
        failureThreshold: 3
        httpGet:
          path: /healthz/ready
          port: 15021
          scheme: HTTP
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 1
      resources:
        requests:
          cpu: 500m
          memory: 2Gi
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          add:
          - NET_ADMIN
          drop:
          - ALL
        privileged: false
        readOnlyRootFilesystem: true
        runAsGroup: 1337
        runAsNonRoot: false
        runAsUser: 0
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
      - mountPath: /var/run/secrets/istio
        name: istiod-ca-cert
      - mountPath: /var/run/secrets/tokens
        name: istio-token
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: kube-api-access-mz2hf
        readOnly: true
    dnsPolicy: ClusterFirst
    enableServiceLinks: true
    nodeName: minikube
    nodeSelector:
      kubernetes.io/os: linux
    preemptionPolicy: PreemptLowerPriority
    priority: 0
    restartPolicy: Always
    schedulerName: default-scheduler
    securityContext: {}
    serviceAccount: ztunnel
    serviceAccountName: ztunnel
    terminationGracePeriodSeconds: 30
    tolerations:
    - effect: NoSchedule
      operator: Exists
    - key: CriticalAddonsOnly
      operator: Exists
    - effect: NoExecute
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/disk-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/memory-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/pid-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/unschedulable
      operator: Exists
    volumes:
    - name: istio-token
      projected:
        defaultMode: 420
        sources:
        - serviceAccountToken:
            audience: istio-ca
            expirationSeconds: 43200
            path: istio-token
    - configMap:
        defaultMode: 420
        name: istio-ca-root-cert
      name: istiod-ca-cert
    - name: kube-api-access-mz2hf
      projected:
        defaultMode: 420
        sources:
        - serviceAccountToken:
            expirationSeconds: 3607
            path: token
        - configMap:
            items:
            - key: ca.crt
              path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
            - fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace
              path: namespace
  status:
    conditions:
    - lastProbeTime: null
      lastTransitionTime: "2023-07-25T23:49:30Z"
      status: "True"
      type: Initialized
    - lastProbeTime: null
      lastTransitionTime: "2023-07-25T23:49:50Z"
      status: "True"
      type: Ready
    - lastProbeTime: null
      lastTransitionTime: "2023-07-25T23:49:50Z"
      status: "True"
      type: ContainersReady
    - lastProbeTime: null
      lastTransitionTime: "2023-07-25T23:49:30Z"
      status: "True"
      type: PodScheduled
    containerStatuses:
    - containerID: docker://8b0b42a525cb36b3dac407c454e229571548dc74331726f14e0d54b95269baeb
      image: gcr.io/istio-testing/ztunnel:1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a
      imageID: docker-pullable://gcr.io/istio-testing/ztunnel@sha256:f27b080094d7ab3dbe388b4bae2f482e51841e2d0061c68370a52e8982fadf60
      lastState: {}
      name: istio-proxy
      ready: true
      restartCount: 0
      started: true
      state:
        running:
          startedAt: "2023-07-25T23:49:50Z"
    hostIP: <IP_ADDRESS>
    phase: Running
    podIP: <IP_ADDRESS>
    podIPs:
    - ip: <IP_ADDRESS>
    qosClass: Burstable
    startTime: "2023-07-25T23:49:30Z"
kind: List
metadata:
  resourceVersion: ""

ztunnel DS yaml:
$ kubectl get -n istio-system ds/ztunnel -oyaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  annotations:
    deprecated.daemonset.template.generation: "1"
  creationTimestamp: "2023-07-25T23:49:30Z"
  generation: 1
  labels:
    install.operator.istio.io/owning-resource: installed-state
    install.operator.istio.io/owning-resource-namespace: istio-system
    istio.io/rev: default
    operator.istio.io/component: Ztunnel
    operator.istio.io/managed: Reconcile
    operator.istio.io/version: 1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a
  name: ztunnel
  namespace: istio-system
  resourceVersion: "847"
  uid: a86eb416-288f-4252-8480-0dd95494156f
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: ztunnel
  template:
    metadata:
      annotations:
        ambient.istio.io/redirection: disabled
        cni.projectcalico.org/allowedSourcePrefixes: '["<IP_ADDRESS>/0"]'
        prometheus.io/port: "15020"
        prometheus.io/scrape: "true"
        sidecar.istio.io/inject: "false"
      creationTimestamp: null
      labels:
        app: ztunnel
        sidecar.istio.io/inject: "false"
    spec:
      containers:
      - args:
        - proxy
        - ztunnel
        env:
        - name: CLUSTER_ID
          value: Kubernetes
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        - name: INSTANCE_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.podIP
        - name: SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.serviceAccountName
        image: gcr.io/istio-testing/ztunnel:1.19-alpha.c641d08aa437381c3678805e17c0479f247e714a
        imagePullPolicy: IfNotPresent
        name: istio-proxy
        ports:
        - containerPort: 15020
          name: ztunnel-stats
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz/ready
            port: 15021
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          requests:
            cpu: 500m
            memory: 2Gi
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            add:
            - NET_ADMIN
            drop:
            - ALL
          privileged: false
          readOnlyRootFilesystem: true
          runAsGroup: 1337
          runAsNonRoot: false
          runAsUser: 0
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/run/secrets/istio
          name: istiod-ca-cert
        - mountPath: /var/run/secrets/tokens
          name: istio-token
      dnsPolicy: ClusterFirst
      nodeSelector:
        kubernetes.io/os: linux
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: ztunnel
      serviceAccountName: ztunnel
      terminationGracePeriodSeconds: 30
      tolerations:
      - effect: NoSchedule
        operator: Exists
      - key: CriticalAddonsOnly
        operator: Exists
      - effect: NoExecute
        operator: Exists
      volumes:
      - name: istio-token
        projected:
          defaultMode: 420
          sources:
          - serviceAccountToken:
              audience: istio-ca
              expirationSeconds: 43200
              path: istio-token
      - configMap:
          defaultMode: 420
          name: istio-ca-root-cert
        name: istiod-ca-cert
  updateStrategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
status:
  currentNumberScheduled: 1
  desiredNumberScheduled: 1
  numberAvailable: 1
  numberMisscheduled: 0
  numberReady: 1
  observedGeneration: 1
  updatedNumberScheduled: 1

and here's one of the problems - this pod in the bookinfo namespace isn't able to start:
$ kubectl describe pods -n bookinfo kiali-traffic-generator-s2psz
Name:             kiali-traffic-generator-s2psz
Namespace:        bookinfo
Priority:         0
Service Account:  default
Node:             minikube/<IP_ADDRESS>
Start Time:       Tue, 25 Jul 2023 19:53:04 -0400
Labels:           app=kiali-traffic-generator
                  kiali-test=traffic-generator
Annotations:      ambient.istio.io/redirection: enabled
Status:           Pending
IP:
IPs:              <none>
Controlled By:    ReplicaSet/kiali-traffic-generator
Containers:
  kiali-traffic-generator:
    Container ID:
    Image:          quay.io/kiali/kiali-test-mesh-traffic-generator:latest
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Environment:
      DURATION:  <set to the key 'duration' of config map 'traffic-generator-config'>  Optional: false
      ROUTE:     <set to the key 'route' of config map 'traffic-generator-config'>     Optional: false
      RATE:      <set to the key 'rate' of config map 'traffic-generator-config'>      Optional: false
      SILENT:    <set to the key 'silent' of config map 'traffic-generator-config'>    Optional: false
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-zdcxt (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kube-api-access-zdcxt:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason                  Age                      From               Message
  ----     ------                  ----                     ----               -------
  Normal   Scheduled               9m29s                    default-scheduler  Successfully assigned bookinfo/kiali-traffic-generator-s2psz to minikube
  Warning  FailedCreatePodSandBox  9m27s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "5c8494a3a55b1b7169a4a23b1a34a4fee61e721ef792a1188f8f28b0bf2dcd3d" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m25s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "ecc447031f4fed9fa848e85cba18443aaa5a098d77406fd5a0bf59c953b514c0" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m24s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "f84139395f8e8f12d53e8387878332cfccba185c142e5b71da0d5d3d15959649" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m23s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0320e3b34b85af53fe4ca75872a44a66cfdf08c1bb322585fb81ca7502e8bac4" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m21s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "8a70d3a89b088c7745e221e83dfae95a4d29812617fd75be9c5283115f69bcc2" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m20s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "13cef4d8654788116ba3f49b2d6a6a2521f0f3e5b9437db5c5d48824467209f5" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m19s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "ce2cd9cf0e998d5e9712925ec14344e785495e677c4746492774af9aca5098ed" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m18s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "1d6169f1730d949e3d4e9f832253e6d1db8553606d8876811fe04310c70777e5" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m17s                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "af483e0e4a3117b41f170b1a2c01d4e8856ec67cd0a7a2433709b6c23440e857" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Warning  FailedCreatePodSandBox  9m13s (x4 over 9m16s)    kubelet            (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "614b71ee3a2b79e66cf030e4615b526325fc837e9f4185182b85c5cbac3c4a6c" network for pod "kiali-traffic-generator-s2psz": networkPlugin cni failed to set up pod "kiali-traffic-generator-s2psz_bookinfo" network: plugin type="istio-cni" name="istio-cni" failed (add): Cannot find device "istioin"
  Normal   SandboxChanged          4m27s (x265 over 9m26s)  kubelet            Pod sandbox changed, it will be killed and re-created.

bug-report.tar.gz

Aight so we have 2 different problems with 2 different CNIs:

Initial CNI you were using in your minikube:

Whatever CNI you were using by default in minikube isn't currently compatible with the Istio CNI for this reason:

no routes found for <IP_ADDRESS> controller=ambient

☝ this is the cause of the problem with that CNI plugin. Regardless of the subsequent errors for other pods, the issue is that the Istio CNI DS cannot find a route from itself to the ztunnel IP thru the K8S network, as configured.
That code is here, and we're using the standard Go netlink library to do a route lookup.
There should be a route configured by the K8S cluster (not Istio) CNI from the CNI pod to the ztunnel pod, and there is not (from the perspective of the CNI DS).
We need to understand why that is for that particular CNI plugin.
A good way to test is to jump into the CNI pod and do an ip route get from the CNI DS pod to the ztunnel on the same node, e.g. ip route get from <cni pod IP> <ztunnel pod IP>. That's effectively what the netlink code is that is causing the failure is doing, so I would be interested to see if it also fails when you do it manually from within the CNI DS.

kindnet CNI  in your minikube:

with kindnet CNI:
kubectl logs -n istio-system daemonsets/istio-cni-node > kindnet.log: kindnet.log
istioctl bug-report: bug-report.tar.gz

For your kindnet log, we are getting a slew of different errors, all of them related to a lack of permissions by the CNI DS:
2023-07-25T14:41:24.578273Z	info	ambient	Node-level cleanup done
2023-07-25T14:41:24.616612Z	error	ambient	failed to add inbound tunnel: operation not supported
2023-07-25T14:41:24.616671Z	error	ambient	failed to add inbound tunnel address: no such device
2023-07-25T14:41:24.617392Z	error	ambient	failed to add outbound tunnel: operation not supported
2023-07-25T14:41:24.617428Z	error	ambient	failed to add outbound tunnel address: no such device
2023-07-25T14:41:24.617458Z	error	ambient	failed to set inbound tunnel up: no such device
2023-07-25T14:41:24.617484Z	error	ambient	failed to set outbound tunnel up: no such device
2023-07-25T14:41:24.617505Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioout/rp_filter: open /proc/sys/net/ipv4/conf/istioout/rp_filter: no such file or directory
2023-07-25T14:41:24.617517Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioout/accept_local: open /proc/sys/net/ipv4/conf/istioout/accept_local: no such file or directory
2023-07-25T14:41:24.617526Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioin/rp_filter: open /proc/sys/net/ipv4/conf/istioin/rp_filter: no such file or directory
2023-07-25T14:41:24.617534Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioin/accept_local: open /proc/sys/net/ipv4/conf/istioin/accept_local: no such file or directory

At the very least, host node's /proc must be writable by the CNI DS for it to function. This indicates it's something to do with how minikube is configured, and a lack of required permissions between the CNI DS and the emulated K8S node.
What minikube driver are you using?

What minikube driver are you using?

I'm using kvm2 driver. You can use this script to start minikube to get what I get (well, assuming the actual minikube version is the same) - this is the same script I use: https://github.com/kiali/kiali/blob/master/hack/k8s-minikube.sh
I start it via: k8s-minikube.sh --cni kindnet start when doing these tests.
By default, that script will use the kvm2 driver.
Note the default cni used by that script is auto - so I don't know what it would pick by default with that. But the script's --cni kindnet will pass that to minikube.

A good way to test this is to jump into the CNI pod and do an ip route get from the CNI DS pod to the ztunnel on the same node, e.g.

ip route get from <cni pod IP> <ztunnel pod IP>.

That's effectively what the netlink code above that is causing the failure is doing, so I would be interested to see if it also fails when you do it manually from within the CNI DS.

Started minikube withOUT --cni kindnet (so default is auto - I actually don't know how to know what it actually ends up using).  All I then did was install today's 1.19 dev build (istio-1.19-alpha.ca648f31ec02194e161d923a2c7da28e374d1922) via istioctl install --set profile=ambient --set components.ingressGateways[0].enabled=true --set components.ingressGateways[0].name=istio-ingressgateway --skip-confirmation
CNI pod IP:
$ kubectl get -n istio-system pod $(kubectl get pod -n istio-system -l k8s-app=istio-cni-node -o jsonpath='{.items..metadata.name}') -o jsonpath='{.status.podIP}'
<IP_ADDRESS>

Ztunnel pod IP:
$ kubectl get -n istio-system pod $(kubectl get pod -n istio-system -l app=ztunnel -o jsonpath='{.items..metadata.name}') -o jsonpath='{.status.podIP}'
<IP_ADDRESS>

From CNI DS:
$ kubectl exec -it -n istio-system $(kubectl get ds -n istio-system istio-cni-node -oname) -- ip route get from <IP_ADDRESS> <IP_ADDRESS>
<IP_ADDRESS> from <IP_ADDRESS> dev bridge uid 0
    cache

From CNI pod:
$ kubectl exec -it -n istio-system $(kubectl get pod -n istio-system -l k8s-app=istio-cni-node -oname) -- ip route get from <IP_ADDRESS> <IP_ADDRESS>
<IP_ADDRESS> from <IP_ADDRESS> dev bridge uid 0
    cache

istio-cni-node pod errors: kubectl logs -n istio-system -l k8s-app=istio-cni-node --tail=-1 > istio-cni-node-err.txt
This looks bad:
2023-07-27T21:05:49.599039Z	error	controllers	error handling istio-system/ztunnel-9txn6, retrying (retry count: 1): failed to get veth device: no routes found for <IP_ADDRESS>	controller=ambient

2023-07-27T21:05:49.599039Z	error	controllers	error handling istio-system/ztunnel-9txn6, retrying (retry count: 1): failed to get veth device: no routes found for <IP_ADDRESS>	controller=ambient

Correct, this is the error mentioned previously when the default CNI is used. There's no route to the ztunnel pod.

A good way to test this is to jump into the CNI pod and do an ip route get from the CNI DS pod to the ztunnel on the same node, e.g: ip route get from <cni pod IP> <ztunnel pod IP>.

Did you try this? What does ip route give you for a route with a dest of istio-system/ztunnel-9txn6's IP? Please try it, and share the results. My suspicion is it will give you no route. If it tells you there's no route, that's a cluster CNI problem, not an Istio problem. If it tells you there is a route, then we might have a netlink problem.

By default, that script will use the kvm2 driver.

The kvm2 driver doesn't seem to be properly supporting running istio-cni as a privileged container then, as you can see from these errors:
2023-07-25T14:41:24.578273Z	info	ambient	Node-level cleanup done
2023-07-25T14:41:24.616612Z	error	ambient	failed to add inbound tunnel: operation not supported
2023-07-25T14:41:24.616671Z	error	ambient	failed to add inbound tunnel address: no such device
2023-07-25T14:41:24.617392Z	error	ambient	failed to add outbound tunnel: operation not supported
2023-07-25T14:41:24.617428Z	error	ambient	failed to add outbound tunnel address: no such device
2023-07-25T14:41:24.617458Z	error	ambient	failed to set inbound tunnel up: no such device
2023-07-25T14:41:24.617484Z	error	ambient	failed to set outbound tunnel up: no such device
2023-07-25T14:41:24.617505Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioout/rp_filter: open /proc/sys/net/ipv4/conf/istioout/rp_filter: no such file or directory
2023-07-25T14:41:24.617517Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioout/accept_local: open /proc/sys/net/ipv4/conf/istioout/accept_local: no such file or directory
2023-07-25T14:41:24.617526Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioin/rp_filter: open /proc/sys/net/ipv4/conf/istioin/rp_filter: no such file or directory
2023-07-25T14:41:24.617534Z	error	ambient	failed to write to proc file /proc/sys/net/ipv4/conf/istioin/accept_local: open /proc/sys/net/ipv4/conf/istioin/accept_local: no such file or directory

My recommendation would be to use the docker driver instead,  I suspect that will work with kindnet. If you have a requirement to use kvm2 then the next step is to debug minikube+kvm2 to understand what the permissions problem is, and why privileged pods can't mount /proc with the kvm2 driver. https://minikube.sigs.k8s.io/docs/drivers/kvm2/#troubleshooting

Open a shell into the istio-cni pod on the node that's running ztunnel-9txn6. What does ip route give you for a route with a dest of istio-system/ztunnel-9txn6's IP? Please try it, and share the results.

Yes, I did that and reported the results in my previous comment. I provide the commands and output results for that. I'll repeat here.  The first two commands get the IPs, the second two commands run that ip route (from the daemonset and pod, which I don't think matters, but for completeness I do both to show they return the same thing):
CNI pod IP:
$ kubectl get -n istio-system pod $(kubectl get pod -n istio-system -l k8s-app=istio-cni-node -o jsonpath='{.items..metadata.name}') -o jsonpath='{.status.podIP}'
<IP_ADDRESS>

Ztunnel pod IP:
$ kubectl get -n istio-system pod $(kubectl get pod -n istio-system -l app=ztunnel -o jsonpath='{.items..metadata.name}') -o jsonpath='{.status.podIP}'
<IP_ADDRESS>

From CNI DS (this is the ip route command):
$ kubectl exec -it -n istio-system $(kubectl get ds -n istio-system istio-cni-node -oname) -- ip route get from <IP_ADDRESS> <IP_ADDRESS>
<IP_ADDRESS> from <IP_ADDRESS> dev bridge uid 0
    cache

From CNI pod (this is the ip route command):
$ kubectl exec -it -n istio-system $(kubectl get pod -n istio-system -l k8s-app=istio-cni-node -oname) -- ip route get from <IP_ADDRESS> <IP_ADDRESS>
<IP_ADDRESS> from <IP_ADDRESS> dev bridge uid 0
    cache

Open a shell into the istio-cni pod on the node that's running ztunnel-9txn6. What does ip route give you for a route with a dest of istio-system/ztunnel-9txn6's IP? Please try it, and share the results.

Yes, I did that and reported the results in my previous comment. I provide the commands and output results for that. I'll repeat here. The first two commands get the IPs, the second two commands run that ip route (from the daemonset and pod, which I don't think matters, but for completeness I do both to show they return the same thing):
CNI pod IP:
$ kubectl get -n istio-system pod $(kubectl get pod -n istio-system -l k8s-app=istio-cni-node -o jsonpath='{.items..metadata.name}') -o jsonpath='{.status.podIP}'
<IP_ADDRESS>

Ztunnel pod IP:
$ kubectl get -n istio-system pod $(kubectl get pod -n istio-system -l app=ztunnel -o jsonpath='{.items..metadata.name}') -o jsonpath='{.status.podIP}'
<IP_ADDRESS>

From CNI DS (this is the ip route command):
$ kubectl exec -it -n istio-system $(kubectl get ds -n istio-system istio-cni-node -oname) -- ip route get from <IP_ADDRESS> <IP_ADDRESS>
<IP_ADDRESS> from <IP_ADDRESS> dev bridge uid 0
    cache

From CNI pod (this is the ip route command):
$ kubectl exec -it -n istio-system $(kubectl get pod -n istio-system -l k8s-app=istio-cni-node -oname) -- ip route get from <IP_ADDRESS> <IP_ADDRESS>
<IP_ADDRESS> from <IP_ADDRESS> dev bridge uid 0
    cache

Ah my bad, I missed that.
Okay so:

Ambient doesn't support CNIs that don't use veths at this time. That means you have to use kindnet (or another CNI that does) for minikube/etc. That's what the ip route get (and the CNI errors) are complaining about.

The permission errors you get when you do use kindnet are probably related to your minikube driver. You need a driver that supports K8S hostNetwork=true, and allows containers to have permissions to write to /proc from within the container. You can choose a minikube driver that allows you to mount the node's /proc into the CNI agent.

tl;dr we need to update the minikube docs for ambient because it has different/more specific requirements at this time than vanilla Istio, and minikube's defaults are insufficient.

For now use the docker driver and kindnet explicitly, and it should work, e.g. the following works for me

OK. Thanks. I'll try that and see how it goes. For now, I have it all working with KinD so this isn't any kind of blocker for me personally. But I figured it is good to try to nail down what is required in order to get things to work on minikube, also.

With CNI of kindnet and driver of docker, things looks different now.
The only error message I see in the DS istio-cni-node:
$ kubectl logs -n istio-system daemonset/istio-cni-node | grep error
2023-08-08T12:44:44.643276Z	error	controllers	error handling istio-system/ztunnel-zgjfn, retrying (retry count: 1): failed to get ns name: failed to get namespace for 8	controller=ambient

Warnings in the logs:
$ kubectl logs -n istio-system istio-cni-node-psn22 --tail=-1 | grep warn
2023-08-08T12:44:40.031001Z	info	FLAG: --log-level="warn"
2023-08-08T12:44:40.037646Z	warn	ambient	unable to list IPSet: failed to list ipset ztunnel-pods-ips: no such file or directory
2023-08-08T12:44:44.553343Z	info	ambient	If rules do not exist in the first place, warnings will be triggered - these can be safely ignored
2023-08-08T12:44:44.566626Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.567359Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.568090Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.568815Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.569529Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.570224Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.570952Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.571648Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.572439Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-PREROUTING' does not exist
2023-08-08T12:44:44.573145Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.573918Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-POSTROUTING' does not exist
2023-08-08T12:44:44.574594Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.575324Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-PREROUTING' does not exist
2023-08-08T12:44:44.576014Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.576717Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-POSTROUTING' does not exist
2023-08-08T12:44:44.577414Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.578145Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-FORWARD' does not exist
2023-08-08T12:44:44.578823Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.579546Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-INPUT' does not exist
2023-08-08T12:44:44.580268Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.581025Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-OUTPUT' does not exist
2023-08-08T12:44:44.581705Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.582503Z	warn	ambient	Error running command iptables-nft: iptables v1.8.7 (nf_tables): Chain 'ztunnel-FORWARD' does not exist
2023-08-08T12:44:44.583175Z	warn	ambient	Error running command iptables-nft: iptables: No chain/target/match by that name.
2023-08-08T12:44:44.584415Z	warn	ambient	Error running command ip rule del priority 100: RTNETLINK answers: No such file or directory
2023-08-08T12:44:44.585234Z	warn	ambient	Error running command ip rule del priority 101: RTNETLINK answers: No such file or directory
2023-08-08T12:44:44.586078Z	warn	ambient	Error running command ip rule del priority 102: RTNETLINK answers: No such file or directory
2023-08-08T12:44:44.586944Z	warn	ambient	Error running command ip rule del priority 103: RTNETLINK answers: No such file or directory
2023-08-08T12:44:44.586985Z	warn	ambient	did not find existing inbound tunnel istioin to delete: Link not found
2023-08-08T12:44:44.587008Z	warn	ambient	did not find existing outbound tunnel istioout to delete: Link not found

However, I can't seem to get it to work.... trying to get the sleep pod to make a request to bookinfo:
$ kubectl exec -it -n bookinfo deployments/sleep -- curl http://productpage:9080
curl: (7) Failed to connect to productpage port 9080 after 2994 ms: Couldn't connect to server
command terminated with exit code 7

I see the same thing with my traffic generator:
$ kubectl exec -it -n bookinfo kiali-traffic-generator-7xkgr -- curl http://productpage.bookinfo:9080
curl: (7) Failed to connect to productpage.bookinfo port 9080: No route to host
command terminated with exit code 7

So something is still missing.
The one difference I can see is my version of minikube:
$ minikube version
minikube version: v1.30.1
commit: 08896fd1dc362c097c925146c4a0d0dac715ace0

Let me try this with the latest (1.31) and see if I get any better results.

Also tested with minikube start --cni=kindnet --driver=qemu2

Now that https://github.com/istio/istio/pull/47444 has merged, you should be able to take a nightly build and install istio with the flag --set values.cni.cniNetnsDir=/var/run/docker/netns into minikube running in Docker mode.

@bleggett I think I'm missing something. I tried to set that cniNetnsDir and it failed:
$ istioctl manifest install --skip-confirmation=true --set profile=ambient --set values.cni.cniNetnsDir=/var/run/docker/netns
Run the command with the --force flag if you want to ignore the validation error and proceed.
Error: generate config: unknown field "cniNetnsDir" in v1alpha1.CNIConfig

This is the 1.20 dev build I have (just downloaded it this morning):
$ istioctl version
no ready Istio pods in "istio-system"
1.20-alpha.2343aa9200b1815a5712fd01a8c7ad84bdada32a

@jmazzitelli ugh yeah  my bad - if you use plain Helm it will work but I forgot extra steps are required to expose Helm flags via istioctl
Fixing that with https://github.com/istio/istio/pull/47499 then it should work.

This should have been taken care of when this issue is resolved.
Could you try it?  Instruction is posted on our slack:
https://istio.slack.com/archives/C049TCZMPCP/p1702045603158969

cc @josunect ^^

Hi @jmazzitelli @johscheuer have you had chance to try it? Thx!

I have not. Is this available in a dev build that we can grab from https://storage.googleapis.com/istio-build ? That's how I test things.

Not yet, because the PRs (very large) for https://github.com/istio/istio/issues/48212 are still under reviews for the past 2 weeks. The testing from various env will increase our confidence about merging the PRs thus the ask. :).

I set the cni by "istioctl install --set values.cni.cniNetnsDir="/var/run/docker/netns" --set profile=ambient --set "components.ingressGateways[0].enabled=true" --set "components.ingressGateways[0].name=istio-ingressgateway" --skip-confirmation" in minikube env, but the istio-cni-node yaml not changed:
  containers:
  - args:
     # ...
    command:
    - install-cni
    image: docker.io/istio/install-cni:1.20.2
    volumeMounts:
    - mountPath: /var/run/netns
      mountPropagation: HostToContainer
      name: cni-netns-dir
  volumes:
  - hostPath:
      path: /var/run/netns
      type: Directory
    name: cni-netns-dir

Hi, this feature not merged yet, you'd have to use a temporary build from Yuval. https://github.com/istio/istio/issues/46163#issuecomment-1858063456

This should be resolved, 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.

I was testing istio-1.21.0-beta.0 and the Istio installation was successful:
minikube start --cni=kindnet
 --set hub=gcr.io/istio-release  --set values.meshConfig.enableAutoMtls=true --set values.pilot.env.ENABLE_NATIVE_SIDECARS=false --set profile=ambient --set values.gateways.istio-egressgateway.enabled=true --set values.gateways.istio-ingressgateway.enabled=true --set values.meshConfig.defaultConfig.tracing.sampling=100.00 --set values.meshConfig.accessLogFile=/dev/stdout --set values.cni.cniNetnsDir=/var/run/docker/netns
But for some reason, I cannot see the Kiali graph, it doesn't look to be generating all the Telemetry:

I also tested  istio-1.21.0-beta.0 with kind and no cniNetnsDir option, and the graph is generated correctly.

Sorry the code was just merged last Friday late (evening time for ET) - istio-1.21.0-beta.0 may not have the change, cc @istio/release-managers and @bleggett to chime in.

https://github.com/istio/istio/wiki/Dev Builds - latest dev build should have the change @josunect

Not sure i just tried the beta-1
Normal   Scheduled    21s               default-scheduler  Successfully assigned istio-system/istio-cni-node-twndn to docker-desktop
Warning  FailedMount  5s (x6 over 20s)  kubelet            MountVolume.SetUp failed for volume "cni-netns-dir" : hostPath type check failed: /var/run/netns is not a director
Failing for me using Docker Desktop M1

POD failing Docker Desktop
  Warning  FailedCreatePodSandBox  25m                  kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "b0f41752d43c430f6f5ab3b637cb562c6bcdba71fe046beebcfefe6f88232322" network for pod "reviews-v2-b7dcd98fb-nhr26": networkPlugin cni failed to set up pod "reviews-v2-b7dcd98fb-nhr26_default" network: plugin type="loopback" failed (add): missing network name:, failed to clean up sandbox container "b0f41752d43c430f6f5ab3b637cb562c6bcdba71fe046beebcfefe6f88232322" network for pod "reviews-v2-b7dcd98fb-nhr26": networkPlugin cni failed to teardown pod "reviews-v2-b7dcd98fb-nhr26_default" network: plugin type="loopback" failed (delete): missing network name]
Installation of istio is successful
istioctl install --set profile=ambient --set "components.ingressGateways[0].enabled=true" --set "components.ingressGateways[0].name=istio-ingressgateway"  --skip-confirmation
NAME                                    READY   STATUS    RESTARTS   AGE
istio-cni-node-dlr85                    1/1     Running   0          31m
istio-ingressgateway-689f9d6fb4-f8jpk   1/1     Running   0          31m
istiod-556d7d4cf5-5477v                 1/1     Running   0          31m
ztunnel-d4mrw                           1/1     Running   0          31m

Tested in minikube and it is working as expected.

It's failing in docker desktop ztunnel not starting with the same error above. Will try to look into it & debug.

Thanks @harsh4870 - pls keep us posted.  Does istio sidecars work for your docker desktop env?
cc @bleggett FYI

Yes, sidecar setup is working like charm with Docker Desktop, in the Ambient profile ztunnel failing.
Tried fully resetting the K8s cluster on Docker Desktop but same error.

@bleggett  Sure, Thanks here i have created issue - https://github.com/istio/istio/issues/49208

I think there is some kind of issue in minikube with sidecars namespaces in Istio-1.21.beta.1.
I was going to do some testing for this issue in minikube, creating a istio-injection=enabled labeled namespace and other with ambient label. The pods with sidecars where unable to start.
I was able to reproduce it installing Istio with Ambient profile and bookinfo, this is how the pods look:

Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  12m                   default-scheduler  Successfully assigned bookinfo/details-v1-698d88b-kdrxw to minikube
  Normal   Pulled     10m (x5 over 12m)     kubelet            Container image "gcr.io/istio-release/proxyv2:1.21.0-beta.1" already present on machine
  Normal   Created    10m (x5 over 12m)     kubelet            Created container istio-validation
  Normal   Started    10m (x5 over 12m)     kubelet            Started container istio-validation
  Warning  BackOff    2m33s (x44 over 12m)  kubelet            Back-off restarting failed container istio-validation in pod details-v1-698d88b-kdrxw_bookinfo(fefd8a19-8d16-44a7-a534-b2d317e4d528)

@josunect If it only shows up when you have a mixed sidecar-and-ambient setup, I would bet that's fixed by https://github.com/istio/istio/pull/49230 which should be in the most recent dev build.

Thank you @bleggett, I'll try on a newer build.

@josunect If it only shows up when you have a mixed sidecar-and-ambient setup, I would bet that's fixed by #49230 which should be in the most recent dev build.

It looks that is working on Istio-1.21.0-rc0. Thank you!


Update sbt-mima-plugin to 0.8.0

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

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.typesafe", artifactId = "sbt-mima-plugin" } ]

labels: sbt-plugin-update, semver-minor

Codecov Report

Merging #861 into develop will decrease coverage by 0.05%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #861      +/-   ##
===========================================
- Coverage    89.34%   89.28%   -0.06%
===========================================
  Files          117      117
  Lines         9326     9326
  Branches       365      365
===========================================
- Hits          8332     8327       -5
- Misses         994      999       +5

Impacted Files
Coverage Δ

...scala/com/twitter/algebird/PredecessibleLaws.scala
71.42% <0.00%> (-14.29%)
:arrow_down:

...ala/com/twitter/algebird/ApproximateProperty.scala
72.00% <0.00%> (-10.00%)
:arrow_down:

...main/scala/com/twitter/algebird/monad/Reader.scala
52.94% <0.00%> (-5.89%)
:arrow_down:

...src/main/scala/com/twitter/algebird/Interval.scala
83.47% <0.00%> (ø)

.../main/scala/com/twitter/algebird/BloomFilter.scala
94.69% <0.00%> (+0.44%)
:arrow_up:

.../main/scala/com/twitter/algebird/JavaMonoids.scala
80.32% <0.00%> (+1.63%)
:arrow_up:

.../main/scala/com/twitter/algebird/Applicative.scala
58.06% <0.00%> (+3.22%)
:arrow_up:

Continue to review full report at Codecov.

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


python3Packages.libtmux: fix disabledTestPaths in darwin

Description of changes
Closes #221505.
Change disabledTestPaths in the libtmux derivation.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 221506 run on aarch64-darwin 1

1 package failed to build:

python311Packages.libtmux

3 packages built:

arsenal
python310Packages.libtmux
tmuxp

Looks like test_capture_pane_start is flaky.


Syndication link not displaying

This post has a syndication link to goodreads.com that is not displaying currently. Below is the Monocle debug for the post.
May be related to the author information not being parsed. The missing author should resolve once Aperture gets the latest version of XRay, though.
{
    "type": "entry",
    "published": "2020-05-07 22:39-0700",
    "url": "https://gregorlove.com/2020/05/currently-reading-youre-a/",
    "syndication": [
        "https://www.goodreads.com/review/show/3324627020"
    ],
    "content": {
        "text": "Currently reading: You're a Miracle (And a Pain in the Ass): Embracing the Emotions, Habits, and Mystery That Make You You by Mike McHargue (ISBN<PHONE_NUMBER>243)",
        "html": "
Currently reading: You're a Miracle (And a Pain in the Ass): Embracing the Emotions, Habits, and Mystery That Make You You by Mike McHargue (ISBN 9781984823243)
"
    },
    "post-type": "note",
    "_id": "11405979",
    "_source": "95",
    "_is_read": false
}

Took a fresh look at this and noticed the goodreads link is there, with an SVG inside, but it's not visible.
<svg class="svg-icon" style="
    background: red;
"><use xlink:href="/assets/font-awesome-5.11.2/brands.svg#link"></use></svg>

https://monocle.p3k.io/assets/font-awesome-5.11.2/brands.svg doesn't appear to define #link


Warn if duplicate *pool instances are being created

This is because such usage would almost always lead to unexpected behaviour.
This PR also improves the docs for the microgrid.*pool() functions.
Closes #902

Based on #900.  Only the last 4 commits are relevant.

I wonder if it wouldn't be safer to just fail the request if it matches an existing pool instead of printing a warning and proceed with a behavior that can potentially cause issues.

I don't think this is a critical issue that we need to fail, because it would continue to function, and they're calling propose_power anyway.
I think we can fail for trivial issues that happen at startup.  But once the app is running, we should try to avoid crashes.  Maybe we can look into static analysis, if there are multiple calls to *pool in a class, etc.

Mmm, still not fully convinced, from this text:

If not, a random prioritization will be imposed on them to resolve conflicts, which may lead to unexpected behavior.

For me unexpected behavior is bad. If using the same args is a bug (maybe is one that sometimes can be unproblematic), we should probably error. For me it is a bug if there is no valid case where you actually want to call the function 2 times with the exact same arguments. If you say there is a valid case where a user wants to do this, then I agree a warning is enough. Just avoiding a crash is not a good enough reason not to raise an exception IMHO, programmers can make all sort of mistakes that will lead to a crash, instead those crashed should be properly handled when possible (like with the actor auto-restart).
Also I guess getting a pool is something you probably do at the start of an application/actor, so the failure should occur pretty soon.
This also makes me think that maybe we don't want to provide a default priority if getting the same pool several times with the same priority is problematic.

Also I guess getting a pool is something you probably do at the start of an application/actor, so the failure should occur pretty soon.

No, they might try to make a second pool only when they try to send a charge command, for example, which could be days after deployment.
The power manager cleans up old requests after 1 min, so even if they create a new pool for each request, it just means that we'd converge to the target power more slowly, rather than crashing on friday 11pm because we try to handle weekend rush.
And if multiple actors use the same batteries with the same priorities, it probably doesn't matter to them, but maybe we can make it even more harder to ignore, by making the priority a required parameter when creating *pools.
If priority is required, they will have to think about it and deal with it.  I think that much should be enough.

Maybe qualifying the documentation makes it better?
    ... If not,
    a random prioritization will be imposed on them to resolve conflicts, which may
    lead to unexpected behavior like longer duration to converge on the desired
    power.

OK, I created a separate discussion, because it seems like it is not a trivial topic, so we shouldn't block this PR which is already an improvement on the status quo:

https://github.com/frequenz-floss/frequenz-sdk-python/discussions/913

Maybe qualifying the documentation makes it better? (I've made this change already)

I guess it is a bit more clear, but maybe it would be better to clarify the random priority is only among the conflicting requests, right? Is not really a random priority in the sense that it could be a proper different priority value.
I asked ChatGPT for help and given some instructions it came up with:

In deployments with multiple actors managing the same set of EV chargers, assigning distinct priorities for each is recommended to prevent conflicts. Without unique priorities, requests with identical EV chargers and priority levels are deterministically sorted in an implicit order (without changing their priority values). This can lead to unpredictable conflict resolution and longer times to reach the desired power distribution. Note that this internal sorting affects only requests that match both in charger set and priority level.

Not for this PR, as it is probably more work, but maybe another approach would be to have a policy based on when the requests were made, like the latest request will always have a higher priority than the previous conflicting requests.

Not for this PR, as it is probably more work, but maybe another approach would be to have a policy based on when the requests were made, like the latest request will always have a higher priority than the previous conflicting requests.

But this would lead to races between the actors, which is what the PowerManager hopes to avoid.

What kind of races?

They will keep sending conflicting requests repeatedly, maybe even continuously, because they see that they both have bounds, but the actual target power is somewhere else, and they need to correct it.  and we'll end up oscillating between charging and discharging every second.

OK, I see now, the issue is not when the pools are created but when they are actually used :+1:


Nick: Watch igudhilu.com

Nick requests the watch of the watch_keyword igudhilu\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

igudhilu\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Add video supplement for "How to Use This Book"

@ncorbin-id, #76 has been merged. How would you like to proceed with the video?

@clyne First I will take what you've written and create a script from it along with a proof-of-concept video. Then I'll take your comments and feedback on that and create a more polished version, which may or may not end up being final. It's important that we get any script or wording issues taken care of before that second iteration of the video since re-recording and editing audio is a non-trivial task.
I say this with the caveat that I need to get a few Unidata projects out the door first, so I'm looking at the week of Sept 20 to have a script and POC video ready for your review. Given that I'm assuming the video will be supplemental to the content that's already written, I'm hoping that won't be too much of a stretch. But please let me know if that would be an issue.
One initial question for you, are you hoping that the video will cover the entire contents of "How to Use This Book" or just the "Running Pythia Foundation examples" section? I'm leaning towards the latter in case the organization of the book ever changes.

@clyne First I will take what you've written and create a script from it along with a proof-of-concept video. Then I'll take your comments and feedback on that and create a more polished version, which may or may not end up being final. It's important that we get any script or wording issues taken care of before that second iteration of the video since re-recording and editing audio is a non-trivial task.
I say this with the caveat that I need to get a few Unidata projects out the door first, so I'm looking at the week of Sept 20 to have a script and POC video ready for your review. Given that I'm assuming the video will be supplemental to the content that's already written, I'm hoping that won't be too much of a stretch. But please let me know if that would be an issue.

Sounds great. No rush.

One initial question for you, are you hoping that the video will cover the entire contents of "How to Use This Book" or just the "Running Pythia Foundation examples" section? I'm leaning towards the latter in case the organization of the book ever changes.

Agreed!

The first draft of the script is complete and ready for comment. I've drafted it in Google docs for direct commenting, and I already have a few questions for y'all in there already.
https://docs.google.com/document/d/1yD8q63KEei5sDCOW_mNI4Ncadli4SpRBUceVbXYa4Rk/edit?usp=sharing
I'll also set the expectation again that modifying the wording of the script at this stage is very important since changing wording after the voiceover is recorded is a lot of work.

Looks great, @ncorbin-id. Please see my in-line reviews. cc'ing @brian-rose

Just finished going through and left inline comments in the doc.
I'd love to resolve two issues before we proceed:

what's the name of the book? Thanks @ncorbin-id for identifying the inconsistency. I opened a new issue for this #176
Basic workflow for users who want to "download and run notebooks locally".

On point 2, my concern is that running notebooks requires a python / conda environment, and we don't really have clear instructions on how to set that up short of cloning the whole repo and using our environment.yml file. And of course once you clone the repo, you have all the notebooks.
I think we need to make a choice, are we going to

encourage new users to download and run individual notebooks, in which case we need clear instructions on how to set up a stand-alone Pythia Foundations run environment
or instead, encourage people to clone the repo, use the included environment.yml file to set up their environment, and use git branches to make modifications to notebooks.

Neither one is perfect. For new and casual users, it would nice if there was a more "one click" method for setting up a local conda environment.

It seems that the first choice (bullet 1) would be slightly preferable. It's what we've documented. We've already provided an icon to download individual notebooks. And it would seem a slightly lower barrier for users to have to run a one-time command to set up their environment appropriately, rather than to have them clone a repo, find the notebook in the repo, and then also set up their environment correctly. The IWG folks should weigh in on this (cc @andersy005, @dopplershift)

Well, we could post instructions that point out how to create the environment without cloning like:
conda env create -f https://raw.githubusercontent.com/ProjectPythia/pythia-foundations/main/environment.yml

In that case we might want a more stripped-down environment file to point to (we can have multiple in the repo), since the one I pointed to above has all the dependencies necessary to build the site, not just run a notebook. Of course, the flip side is making sure that second environment stays correct and up-to-date...

Well, we could post instructions that point out how to create the environment without cloning like:
conda env create -f https://raw.githubusercontent.com/ProjectPythia/pythia-foundations/main/environment.yml

I suspect that this is the right approach. We give users a straightforward way to set up a working environment without worrying whether they know how to git clone a repo.
We had a related discussion about environments in #56 (with no particular resolution). If we settle on this approach, then I think it makes sense to maintain two different environment files as @dopplershift suggests.
As for keeping the run environment up-to-date, it should be possible to set up some additional CI for this.

Perhaps this can be discussed at the IWG meeting this week and we can figure out a path forward that would allow us to complete the video.

Hey y'all, a few pending questions on this for you to make sure I have the story straight:

Is downloading a single chapter as an ipynb still an option for the user?
If yes, then will the user create the environment from an environment.yml file or will they need to clone the whole repo?
Where will the written instructions for the above workflow live in the book?

With those answers I'll fix up the script and send it back for additional comment.

@ncorbin-id, we've discussed this at a few working group meetings, and I think we've settled on a strategy. In response to your questions:

Yes. The download button will remain on each book page.
Instructions for how to create a run-time environment (using @dopplershift's suggested approach above) will be prominently found in the "How to Use This Book" section. This will use the same environment.yml in the source repo so it will run all our notebooks, but the user will not need to understand anything about cloning to make this work.
Good question. I don't think we even have an open issue for this currently. But it's a relatively easy lift so I can try to put something together this week.

Yes to 1 and 2. The instructions have been added to 'how-to-use' this book, in the yet-to-be merged PR, #199

Hi @ncorbin-id, just checking in to see what the status is on this. It looks like we've merged #199, mentioned above. Thanks!


Electrs not running

I would first like to thank you again for your quick feedback on https://github.com/sparrowwallet/sparrow/issues/729 and add the following:
Now it says "Electrum not running" without further action. The command sudo journalctl -f -u electrs leads to:
sudo journalctl -f -u electrs
-- Journal begins at Tue 2022-11-01 05:40:59 GMT. --
Nov 01 13:21:04 raspberrypi electrs[2726027]: note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Nov 01 13:21:04 raspberrypi electrs[2726027]: [2022-11-01T13:21:04.795Z INFO  electrs::db] closing DB at /mnt/hdd/app-storage/electrs/db/bitcoin
Nov 01 13:21:04 raspberrypi electrs[2726027]: Error: electrs failed
Nov 01 13:21:04 raspberrypi electrs[2726027]: Caused by:
Nov 01 13:21:04 raspberrypi electrs[2726027]:     0: sync failed
Nov 01 13:21:04 raspberrypi electrs[2726027]:     1: failed to get block<PHONE_NUMBER>00000000070742427fa10ec3c66d006160155a704d9f56d090a3ea
Nov 01 13:21:04 raspberrypi electrs[2726027]:     2: receiving on an empty and disconnected channel
Nov 01 13:21:04 raspberrypi systemd[1]: electrs.service: Main process exited, code=exited, status=1/FAILURE
Nov 01 13:21:04 raspberrypi systemd[1]: electrs.service: Failed with result 'exit-code'.
Nov 01 13:21:04 raspberrypi systemd[1]: electrs.service: Consumed 8.091s CPU time.
Nov 01 13:22:04 raspberrypi systemd[1]: electrs.service: Scheduled restart job, restart counter is at 138.
Nov 01 13:22:04 raspberrypi systemd[1]: Stopped Electrs.
Nov 01 13:22:04 raspberrypi systemd[1]: electrs.service: Consumed 8.091s CPU time.
I would be infinitely grateful for any further advice.

I actually don't know for certain, and but since this affects Electrs and not Sparrow I ask that you raise the issue at https://github.com/romanz/electrs rather than here.
My suspicion though is that there is something wrong with your Bitcoin Core, or the connection Electrs has to it.


Remove moot version property from bower.json

Per bower/bower.json-spec@a325da3

 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.


after update

Even i updated the theme i still see the "ovel is outdated or broken.. current: (v1.0.6 Build 150)...etc."

Working On It 😄


Updated subworkflows, modules and test snaps

PR checklist

[ ] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[ ] If necessary, also make a PR on the nf-core/nanostring branch on the nf-core/test-datasets repository.
[ ] Make sure your code lints (nf-core lint).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

@atrigila I created a separate ticket for the MultiQC error https://github.com/nf-core/nanostring/issues/108

Looks like if you modify the PR template the linting fails, so we might not be able to add this there.


Add spillable batch caching and sort fallback to hash aggregation

This adds out-of-core support for hash aggregation by making all batches that are held while iterating spillable along with a sort-based fallback for groupby aggregations.
The aggregation strategy has changed as part of this PR.  Besides the sort-based fallback, the approach to aggregations before falling back is also different. The overall goal is to maximize the input size and minimize the number of aggregation calls.

Input batches are coalesced to 2X the target size (or 2GB cudf limit, whichever is smaller) to target an approximate 4X overall non-spillable footprint (input batch + output batch). This matches the 4X target size footprint for joins.
Instead of aggregating and immediately merging with a single held batch, aggregated batches are made spillable and collected in a queue.  Only after all input batches have been aggregated do we attempt to merge-aggregate them.
If we are unable to merge the aggregated batches into a single batch due to the target batch limits then a sort-based fallback is used where an out-of-core sorter sorts the batches based on grouping keys.  The resulting batches are sliced at a key boundary so the batches can be independently merge-aggregated without needing to hold the entire output at once.

Marking this as a draft while collecting some profiles and performing some scale testing.  The sort fallback is being exercised by some of the existing hash aggregation tests that use a tiny batch size to force the fallback.

build

CI failed with a CPU/GPU mis-match in the test test_hash_multiple_mode_query[{'spark.rapids.sql.variableFloatAgg.enabled': 'true', 'spark.rapids.sql.hasNans': 'false', 'spark.rapids.sql.castStringToFloat.enabled': 'true', 'spark.rapids.sql.batchSizeBytes': '1000'}-[('a', RepeatSeq(String)), ('b', Integer), ('c', Null)]] but I cannot reproduce this locally.  Kicking the CI build again to see if this is consistent.

build

So good news is that the CI failure is repeatable, and I was able to reproduce it locally by setting PYSP_TEST_spark_master="local[8,1]".  The problem goes away if I change the code to avoid hinting to cudf that the data is sorted.  I'll dig more into the failure, see if I can get a repro case with just libcudf.

I was able to localize this to a problem in libcudf with sort-hinted aggregations.  I filed https://github.com/rapidsai/cudf/issues/8717

build

I think this is ready to be merged.  CI tests are passing, I manually tested this on Databricks, and this was benchmarked on NDS at 3TB scale with no significant performance regression.
@revans2 it would be great if you could give this another look.