text:
Connectivity to Hass suddenly stopped - no known changes occured

Problem/Motivation
Today I noticed I could not reach my Home assistant while external to my local and tailscale network. This configuration has been working for 4 or 5 months without issue.
Expected behavior
Successfully access HASS through iOS app or browser from the internet
Actual behavior
Timeout, debug logs in add on do not show the attempted connection

So the add-on is running. Can you see it on the admin page as connected? https://login.tailscale.com/admin/machines Did you disable key expiry? 4-5 months ago?
You can retrieve the add-on logs even after multiple restarts with sg. like ha host log --identifier addon_a0d7b954_tailscale --lines 500 Aren't there any errors or warnings?
Without logs, without the add-on's config, it is hard to say anything more.

Same here. Updated today and the addon's stopped working. Previously I'd had it running as a funnel for a while now, with no issues.
There's only the following entry in the logs that appears to be anything questionable:
2024/05/20 21:10:53 rename of "/etc/resolv.conf" to "/etc/resolv.pre-tailscale-backup.conf" failed (rename /etc/resolv.conf /etc/resolv.pre-tailscale-backup.conf: device or resource busy), falling back to copy+delete

The rest just look like success messages.
I can also see the node appears as "connected" on Tailscale admin panel. In other works everything appears to be in order, but no connection.
Doubt it'll help, but here's the add-on config anyway:
funnel: true
log_level: debug
proxy: true
userspace_networking: false
proxy_and_funnel_port: 443

I have the same problem after updating to version 0.19.0

addon_a0d7b954_tailscale --lines 500
Yes addon is running. My key is set to never expire and no errors or warnings in the logs. Interestingly, unlike the others that have replied, my issue started before I updated to version 0.19.0. I updated to the latest but my issue persists.

My config:
funnel: true log_level: debug proxy: true userspace_networking: false proxy_and_funnel_port: 443

Quite simple configs. Hmmm.

my issue started before I updated to version 0.19.0

So there is a chance, that it is not related to this version. Strange coincidence.

userspace_networking: false

This is not needed to access HA or anything on the device from the tailnet and/or from the internet (funnel), this is needed only if HA or anything on the LAN wants to access the tailnet. If anything on the LAN (not HA on the device, but other devices on the LAN) wants to access the tailnet, with TS v1.66.x you need stateful_filtering: false (https://tailscale.com/security-bulletins#ts-2024-005 and https://github.com/lmagyar/homeassistant-addon-tailscale/issues/127), but I think something else is going on. So 2 tips for testing:

try userspace_networking: true
try stateful_filtering: false (only if anything from the LAN wants to access the tailnet)

And I have rename of "/etc/resolv.conf" ... in the logs also, and everything works. So that shouldn't be a problem.

Quite simple configs. Hmmm.

my issue started before I updated to version 0.19.0

So there is a chance, that it is not related to this version. Strange coincidence.

userspace_networking: false

This is not needed to access HA or anything on the device from the tailnet and/or from the internet (funnel), this is needed only if HA or anything on the LAN wants to access the tailnet. If anything on the LAN (not HA on the device, but other devices on the LAN) wants to access the tailnet, with TS v1.66.x you need stateful_filtering: false (https://tailscale.com/security-bulletins#ts-2024-005 and lmagyar#127), but I think something else is going on. So 2 tips for testing:

try userspace_networking: true
try stateful_filtering: false (only if anything from the LAN wants to access the tailnet)

funnel: true proxy: true userspace_networking: true log_level: debug stateful_filtering: true
No improvement, still nothing in the logs showing the attempted connection as well.

I have tried all four combinations of stateful_filtering and userspace_networking. No changes.

Could you test stateful_filtering: false temporarily? There is a non-zero chance it can be a solution (tailscale/tailscale#12108).

no change with stateful filtering = false

Does this return an IP? dig <machine-name>.<tailnet-name>.ts.net +short This would be TS's TCP proxy for the funnel.
Can you access the https://<machine-name>.<tailnet-name>.ts.net from a tailnet connected browser? To test TS's reverse proxy inside the add-on is working correctly?
Can you acces the http://<tailnet IP of HA>:<port where HA is accessible with plain http> from a tailnet connected browser?
I'm running out of ideas. In the past, when nothing worked that should, I've deleted all the site related cookies and everything from the browser, and usually that helped.

Does this return an IP? dig <machine-name>.<tailnet-name>.ts.net +short This would be TS's TCP proxy for the funnel.
Can you access the https://<machine-name>.<tailnet-name>.ts.net from a tailnet connected browser? To test TS's reverse proxy inside the add-on is working correctly?
Can you acces the http://<tailnet IP of HA>:<port where HA is accessible with plain http> from a tailnet connected browser?
I'm running out of ideas. In the past, when nothing worked that should, I've deleted all the site related cookies and everything from the browser, and usually that helped.

I sat down to respond to these and it was working again. Feels like something on the tailscale side changed and reverted. Anyone else's begin working without a real solution?

Yeah it's back on its own.
I've done some googling, and yeah this might have something to do with the latest Tailscale version. I found a few posts on other websites where others' setups, completely unrelated to HA and this addon, suddenly stopped working for no apparent reason as well in the last 24 hours.

Closing it out since it appears unrelated to this addon. Thanks everyone!

Welp, now its down again. Still feels like a tailscale thing but just wondering if we're all still in the same boat.

Got the same issue after the update this night. Can ping my own tailscale IP but notihing else. The connections between all other Tailscale devices are working as intended. Even incoming connections to HomeAssistant from other Tailscale devices. Without running Uptime Kuma on HA i wouldn't be able to see the issue because the connection to the App and Webinterface are fine.
I will let it run for a while and report if it changes itself without any configuration change. But i can't imagine that this is not related to the update at all.

I use it on three machines with HA, not one of them is functional since the last update

I have a possibly related issue with the same update: https://github.com/hassio-addons/addon-tailscale/discussions/365 since this update, I can no longer create backups via the samba backup HA add-on which have been perfectly working for years before this TS (add-on) update.

From what i have gathered as a layperson in my setup the issue lies with the routing in the containers: The tailscale addon container is entered as default gateway in other containers.

My problem is that since the update to version 0.19.0, the container with the add-on keeps shutting down and I don't even have the option to open its web interface.  I haven't found a solution yet.  Everything was working until the update.  I don't know if my description is understandable, I apologize for that.

ha host log --identifier addon_a0d7b954_tailscale --lines 500

@josefsedy You can see the past logs with ha host log --identifier addon_a0d7b954_tailscale --lines 1000 Even if the add-on is stopped.

I feel 3 different issues:

TS v1.66.x related, suddenly stops working, suddenly starts.
Outgoing traffic related, when stateful_filtering: false can help. Even TS reverted this in v1.66.4 where this will be default off (as in the next add-on version also). #368
A plain bug in the add-on logic that causes the add-on not to start. This is already fixed (will be fixed) in the next release. #366

This fixed it for me:

Enable stateful_filtering, save, restart Tailscale
Disable stateful_filtering, save, restart Tailscale
Restart the whole system

Had the same when setting it up with Userspace networking mode. It shows disabled, but you have to enable it, save, and disable it to get it disabled. Don't know if this is related to Homeassistant or the Tailscale Addon but it feels just wrong.

@ovizii On one of my machines it seems related to name resolution,
If I change the name of the backup destination into its current ip address, the addon starts up fine.
On that specific machine I can ping the backup server using its ip address, but not using its network name
On two other machines that have been installed identically, I can also ping the backup server by its network name
It's just a temporary workaround, but worth a try.

@ovizii On one of my machines it seems related to name resolution,
If I change the name of the backup destination into its current ip address, the addon starts up fine.
On that specific machine I can ping the backup server using its ip address, but not using its network name On two other machines that have been installed identically, I can also ping the backup server by its network name
It's just a temporary workaround, but worth a try.

Thanks but my backup target has always been an IP address which was advertised as a subnet by another tailscale node. And this upgrade broke that. :-(

Enable stateful_filtering, save, restart Tailscale
Disable stateful_filtering, save, restart Tailscale
It shows disabled, but you have to enable it, save, and disable it to get it disabled. Don't know if this is related to Homeassistant or the Tailscale Addon but it feels just wrong.

Yes, this is a HA UI bug (I don't know whether is there an issue for it), the UI can't distinguish between unset and disabled options, both displayed as disabled, I always use the YAML editor. As I remember thsi works in the UI editor: enable, save, disable, save, [check the yaml], restart :(

If I change the name of the backup destination into its current ip address, the addon starts up fine.

Seems to be related: https://github.com/tailscale/tailscale/issues/12108

The UI not being able to distinguish between unset and disabled is indeed very confusing (one really has to read the textual explanation to see what the default is) and what makes it even more confusing is, that when you do edit the yaml file, you don't get to see the default settings, only the ones that have been modified.
I imagine this is related to the way Tailscale itself handles the option; if you don't specify an option, then use the default.
It would take quite a bit of effort for the official maintainer (@frenck ? ) of the addon for Homeassistant to scan every new release of Tailscale for new options, its defaults and then add them to the default yaml file.
For the name resolution issue I have to dig in deeper. My three identical machines apparently are not as identical as I thought.

The UI not being able to distinguish between unset and disabled is indeed very confusing

This is feedback for the Home Assistant project, not this add-on.

It was not meant as criticism :-) only to clarify my understanding of the extra work it would bring.

Oh it is fine, but I do think such feedback is helpful in a way (at the right place) 😄
As for extra work... that is not what this is about. I don't think it is right to force a default from this end, instead, I think following upstream is the correct path.

Btw. the v0.19.1 update fixed everything. I updated the add-on, restarted it and voilà, my backups are working again. No configuration changes.

I don't have the same experience
after installing 0.19.1 it behaves the same
2024/05/22 18:46:37 got LocalBackend in 14ms
[18:46:37] INFO: Service NGINX exited with code 256 (by signal 15)
[18:46:37] INFO: Service tailscaled exited with code 256 (by signal 15)
s6-rc: info: service nginx successfully stopped
s6-rc: info: service init-nginx: stopping
s6-rc: info: service web: stopping
s6-rc: info: service tailscaled successfully stopped
s6-rc: info: service init-nginx successfully stopped
[18:46:37] INFO: Service Tailscale web exited with code 256 (by signal 15)
s6-rc: info: service web successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service base-addon-log-level: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service base-addon-log-level successfully stopped
s6-rc: info: service base-addon-banner: stopping
s6-rc: info: service base-addon-banner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

We need the beginning of the log, there must be another error, this is only a consequence of that error.

You can access the past logs with ha host log --identifier addon_a0d7b954_tailscale --lines 1000, there have to be a real ERROR message somewhere.

@lmagyar having the same issue as everyone else when upgrading to >=0.19.0. This contains the errors I see at the top of my log. Not sure if this is useful to you.
s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-nginx: starting
s6-rc: info: service web: starting
s6-rc: info: service tailscaled: starting
s6-rc: info: service web successfully started
s6-rc: info: service tailscaled successfully started
s6-rc: info: service post-tailscaled: starting
[13:12:29] INFO: Starting Tailscale...
[13:12:29] INFO: Starting Tailscale web...
[13:12:29] INFO: Allow UDP GRO for forwarding on enp0s25
[13:12:29] NOTICE: Tailscale logs will be suppressed after 200 lines, set add-on's configuration option 'log_level' to 'debug' to see further logs
netlink error: bit name not found (offset 56)
netlink error: Not supported
s6-rc: warning: unable to start service post-tailscaled: command exited 92
s6-rc: info: service init-nginx successfully started
2024/05/22 13:12:29 You have disabled logging. Tailscale will not be able to provide support.
2024/05/22 13:12:29 logtail started
2024/05/22 13:12:29 Program starting: v1.66.4-t067defc64-g49481b7d0, Go 1.22.3: []string{"/opt/tailscaled", "--state=/data/tailscaled.state", "--statedir=/data/state", "--no-logs-no-support"}
2024/05/22 13:12:29 LogID: c0f9341f5954375b5ae34008b022ee2db41cbb5a82764f4ab39b0d74ae274431
2024/05/22 13:12:29 logpolicy: using system state directory "/var/lib/tailscale"
logpolicy.ConfigFromFile /var/lib/tailscale/tailscaled.log.conf: open /var/lib/tailscale/tailscaled.log.conf: no such file or directory
s6-rc: info: service nginx: starting
logpolicy.Config.Validate for /var/lib/tailscale/tailscaled.log.conf: config is nil
2024/05/22 13:12:29 dns: [resolved-ping=yes rc=unknown ret=direct]
2024/05/22 13:12:29 dns: using "direct" mode
s6-rc: info: service nginx successfully started
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.
s6-rc: info: service nginx: stopping
s6-rc: info: service tailscaled: stopping

The messages that seem concerning to me are:
netlink error: bit name not found (offset 56)
netlink error: Not supported
s6-rc: warning: unable to start service post-tailscaled: command exited 92

...and
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.

Unfortunately, even today's update didn't help. This is an extract from the Supervisor log. The container keeps stopping and cannot be started.
File "/usr/src/supervisor/supervisor/host/logs.py", line 143, in journald_logs
raise HostNotSupportedError(
supervisor.exceptions.HostNotSupportedError: No systemd-journal-gatewayd Unix socket available
2024-05-22 19:22:50.939 ERROR (MainThread) [supervisor.host.logs] No systemd-journal-gatewayd Unix socket available
2024-05-22 19:22:50.940 ERROR (MainThread) [supervisor.api] Failed to get supervisor logs using advanced_logs API
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/api/init.py", line 404, in get_supervisor_logs
return await self._api_host.advanced_logs_handler(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/api/host.py", line 207, in advanced_logs_handler
async with self.sys_host.logs.journald_logs(
File "/usr/local/lib/python3.12/contextlib.py", line 210, in aenter
return await anext(self.gen)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/host/logs.py", line 143, in journald_logs
raise HostNotSupportedError(
supervisor.exceptions.HostNotSupportedError: No systemd-journal-gatewayd Unix socket available
2024-05-22 19:22:55.782 INFO (SyncWorker_4) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:23:00.228 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:23:04.217 ERROR (MainThread) [supervisor.api.ingress] Ingress error: Cannot connect to host 172.30.32.1:62128 ssl:default [Connect call failed ('172.30.32.1', 62128)]
2024-05-22 19:23:08.454 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:23:08.494 INFO (SyncWorker_3) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:23:12.375 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:23:19.046 ERROR (MainThread) [supervisor.host.logs] No systemd-journal-gatewayd Unix socket available
2024-05-22 19:23:19.046 ERROR (MainThread) [supervisor.api] Failed to get supervisor logs using advanced_logs API
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/api/init.py", line 404, in get_supervisor_logs
return await self._api_host.advanced_logs_handler(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/api/host.py", line 207, in advanced_logs_handler
async with self.sys_host.logs.journald_logs(
File "/usr/local/lib/python3.12/contextlib.py", line 210, in aenter
return await anext(self.gen)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/host/logs.py", line 143, in journald_logs
raise HostNotSupportedError(
supervisor.exceptions.HostNotSupportedError: No systemd-journal-gatewayd Unix socket available
2024-05-22 19:23:19.326 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:23:19.345 INFO (SyncWorker_4) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:23:19.437 ERROR (MainThread) [supervisor.host.logs] No systemd-journal-gatewayd Unix socket available
2024-05-22 19:23:19.438 ERROR (MainThread) [supervisor.api] Failed to get supervisor logs using advanced_logs API
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/api/init.py", line 404, in get_supervisor_logs
return await self._api_host.advanced_logs_handler(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/api/host.py", line 207, in advanced_logs_handler
async with self.sys_host.logs.journald_logs(
File "/usr/local/lib/python3.12/contextlib.py", line 210, in aenter
return await anext(self.gen)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/host/logs.py", line 143, in journald_logs
raise HostNotSupportedError(
supervisor.exceptions.HostNotSupportedError: No systemd-journal-gatewayd Unix socket available
2024-05-22 19:23:23.364 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:23:30.281 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:23:30.286 INFO (SyncWorker_3) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:23:34.350 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:23:41.041 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:23:41.052 INFO (SyncWorker_1) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:23:44.622 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:23:50.480 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:23:50.486 INFO (SyncWorker_0) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:23:54.580 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:24:01.135 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:24:01.139 INFO (SyncWorker_4) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:24:04.849 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:24:11.291 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:24:11.297 INFO (SyncWorker_5) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:24:14.886 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:24:20.664 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:24:20.668 INFO (SyncWorker_1) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:24:24.385 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:24:30.918 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:24:30.923 INFO (SyncWorker_3) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:24:34.392 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:24:40.214 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon Tailscale is failed, restarting...
2024-05-22 19:24:40.218 INFO (SyncWorker_2) [supervisor.docker.manager] Cleaning addon_a0d7b954_tailscale application
2024-05-22 19:24:43.691 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/hassio-addons/tailscale/amd64 with version 0.19.1
2024-05-22 19:24:48.357 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-4686' coro=<Addon.watchdog_container() done, defined at /usr/src/supervisor/supervisor/addons/addon.py:1429> exception=AddonsJobError('Rate limit exceeded, more than 10 calls in 0:30:00')>
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/addons/addon.py", line 1443, in watchdog_container
await self._restart_after_problem(event.state)
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 290, in wrapper
raise on_condition(
supervisor.exceptions.AddonsJobError: Rate limit exceeded, more than 10 calls in 0:30:00
2024-05-22 19:29:07.812 ERROR (MainThread) [supervisor.host.logs] No systemd-journal-gatewayd Unix socket available
2024-05-22 19:29:07.812 ERROR (MainThread) [supervisor.api] Failed to get supervisor logs using advanced_logs API
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/api/init.py", line 404, in get_supervisor_logs
return await self._api_host.advanced_logs_handler(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/api/host.py", line 207, in advanced_logs_handler
async with self.sys_host.logs.journald_logs(
File "/usr/local/lib/python3.12/contextlib.py", line 210, in aenter
return await anext(self.gen)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/host/logs.py", line 143, in journald_logs
raise HostNotSupportedError(
supervisor.exceptions.HostNotSupportedError: No systemd-journal-gatewayd Unix socket available

@rlad78 What are the outputs of the below 2 commands?
ip -4 route show 0/0
ip -6 route show ::/0

@josefsedy Could you please check for TS add-on's errors with this:  ha host log --identifier addon_a0d7b954_tailscale --lines 1000 Dont copy the whole, just some error related lines.

@rlad78 @josefsedy What are the outputs of the below 2 commands?
ip -4 route show 0/0
ip -6 route show ::/0

richard@snoothome:~$ ip -4 route show 0/0
default via 10.0.2.1 dev enp0s25 proto dhcp metric 100
richard@snoothome:~$ ip -6 route show ::/0
richard@snoothome:~$

I don't know where and how to look for it.

It could be this:
2024/05/22 19:24:45 | stderr | s6-rc: info: service s6rc-oneshot-runner successfully stopped
2024/05/22 19:24:45 | stderr | s6-rc: info: service s6rc-oneshot-runner: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service base-addon-banner successfully stopped
2024/05/22 19:24:45 | stderr | s6-rc: info: service base-addon-banner: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service base-addon-log-level successfully stopped
2024/05/22 19:24:45 | stderr | s6-rc: info: service fix-attrs successfully stopped
2024/05/22 19:24:45 | stderr | s6-rc: info: service base-addon-log-level: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service fix-attrs: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service legacy-cont-init successfully stopped
2024/05/22 19:24:45 | stderr | s6-rc: info: service legacy-cont-init: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service web successfully stopped
2024/05/22 19:24:45 | stderr | [19:24:45] INFO: Service Tailscale web exited with code 256 (by signal 15)
2024/05/22 19:24:45 | stderr | s6-rc: info: service tailscaled successfully stopped
2024/05/22 19:24:45 | stderr | [19:24:45] INFO: Service tailscaled exited with code 256 (by signal 15)
2024/05/22 19:24:45 | stderr | s6-rc: info: service init-nginx successfully stopped
2024/05/22 19:24:45 | stderr | s6-rc: info: service web: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service init-nginx: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service nginx successfully stopped
2024/05/22 19:24:45 | stderr | [19:24:45] INFO: Service NGINX exited with code 256 (by signal 15)
2024/05/22 19:24:45 | stderr | s6-rc: info: service tailscaled: stopping
2024/05/22 19:24:45 | stderr | s6-rc: info: service nginx: stopping
2024/05/22 19:24:45 | stderr | /run/s6/basedir/scripts/rc.init: fatal: stopping the container.
2024/05/22 19:24:45 | stderr | /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
2024/05/22 19:24:45 | stderr | s6-rc: warning: unable to start service post-tailscaled: command exited 1
2024/05/22 19:24:45 | stderr | For more information run ethtool -h
2024/05/22 19:24:45 | stderr | ethtool: bad command line argument(s)
2024/05/22 19:24:45 | stderr | [19:24:45] INFO: Allow UDP GRO for forwarding on eth0

it seems that the whole problem is on my Synology NAS where I have the container manager running.  Advanced SSH & Web Terminal behaves as non-standard as Tailscale.

OK, when I saw ethtool: bad command line argument(s) and netlink error: bit name not found (offset 56) I gave up and reverted the root cause. This was a suggested optimization from the TS log.

both v0.19.1 and v0.19 no longer work for me either. Everything up to 0.18 worked without problems
In Home Assistant, the situation seems fine, however in Synology NASs container, Tailscale addon does not start.
It that any way to come back to v0.18 version?

Is that any way to come back to v0.18 version?

It should. I think add-on version 0.19.0 had some general tailscale issues and some add-on bugs, 0.19.1 has only add-on bugs, reverted with #370.

do you know a simple way to install version v0.18.0?

Restore a backup is the only way.

Unfortunately, I don't have the 0.18.0 version backed up.  But version 0.17.0 is working.

FWIW, version 0.19.1 failed to connect my instance of Home Assistant to my tailnet. The addon starts then immediately stops. I don't recall seeing an explicit error message, just that nginx would report it was stopping mere seconds after it started. I needed this fixed ASAP so I restored my backup of version 0.18 and it now works properly (i.e. my Home Assistant server is now visible in the latest version of the Tailscale Android app).
Obviously something that changed between 0.18 and 0.19 appears to be the culprit.

Yes, #370 is under review, final version will try to keep the optimization, but the add-on will start even if it fails in any way.

authors: Tisoza c2mfj epposan esenliyim frenck gentertain itmokel josefsedy lmagyar ovizii rlad78 robert10055 tdejneka

repo: hassio-addons/addon-tailscale


text:
Test-ci

Add CI, testing on this branch

This PR removes #3 , requesting review from @danieljharvey

source: gharchive/pull-request

repo: hasura/ndc-clickhouse

license_type: permissive

license_source: github-api


text:
Declaring the Hathora version for the project

I was just trying out https://github.com/hpx7/tussie-mussie and hathora dev fails:
Project root: /tmp/tussie-mussie
Installing dependencies in /tmp/tussie-mussie/api

added 5 packages, and audited 6 packages in 2s

1 package is looking for funding
  run `npm fund` for details

found 0 vulnerabilities
Installing dependencies in /tmp/tussie-mussie/client/.hathora

added 14 packages, and audited 15 packages in 6s

1 package is looking for funding
  run `npm fund` for details

found 0 vulnerabilities
Installing dependencies in /tmp/tussie-mussie/client/prototype-ui
npm WARN deprecated @types/history@5.0.0: This is a stub types definition. history provides its own type definitions, so you do not need this installed.

added 122 packages, and audited 123 packages in 13s

20 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
Installing dependencies in /tmp/tussie-mussie/client/web

up to date, audited 35 packages in 525ms

found 0 vulnerabilities
Installing dependencies in /tmp/tussie-mussie/client/prototype-ui/plugins/Card

up to date, audited 14 packages in 501ms

found 0 vulnerabilities
Installing dependencies in /tmp/tussie-mussie/server

up to date, audited 2 packages in 468ms

found 0 vulnerabilities
Installing dependencies in /tmp/tussie-mussie/server/.hathora

added 10 packages, and audited 11 packages in 4s

1 package is looking for funding
  run `npm fund` for details

found 0 vulnerabilities
(node:38265) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Connected to coordinator at coordinator.hathora.dev
Starting frontend at /tmp/tussie-mussie/client/prototype-ui
✘ [ERROR] [plugin vite:dep-scan] Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json.

    ../../../../home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29521:10:
      29521 │     throw new Error(`Failed to resolve entry for package "${id}". ` +
            ╵           ^

    at packageEntryFailure (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29521:11)
    at resolvePackageEntry (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29517:9)
    at tryResolveFile (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29247:38)
    at tryFsResolve (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29229:16)
    at Context.resolveId (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29107:28)
    at Object.resolveId (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38255:55)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async resolve (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38458:26)
    at async /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38644:34
    at async callback (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:920:28)

  This error came from the "onResolve" callback registered here:

    ../../../../home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38640:18:
      38640 │             build.onResolve({
            ╵                   ~~~~~~~~~

    at setup (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38640:19)
    at handlePlugins (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:842:23)
    at Object.buildOrServe (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1136:7)
    at /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:2064:17
    at new Promise (<anonymous>)
    at Object.build (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:2063:14)
    at Object.build (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1913:51)
    at /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38416:54
    at Array.map (<anonymous>)

  The plugin "vite:dep-scan" was triggered by this import

    ../../client/prototype-ui/State.tsx:7:23:
      7 │ import CardPlugin from "./plugins/Card";
        ╵                        ~~~~~~~~~~~~~~~~

/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1602
  let error = new Error(`${text}${summary}`);
              ^

Error: Build failed with 1 error:
../../../../home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29521:10: ERROR: [plugin: vite:dep-scan] Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json.
    at failureErrorWithLog (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1602:15)
    at /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1248:28
    at runOnEndCallbacks (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1033:63)
    at buildResponseToResult (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1246:7)
    at /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1355:14
    at /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:665:9
    at handleIncomingPacket (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:762:9)
    at Socket.readFromStdout (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:632:7)
    at Socket.emit (node:events:390:28)
    at addChunk (node:internal/streams/readable:315:12) {
  errors: [
    {
      detail: Error: Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json.
          at packageEntryFailure (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29521:11)
          at resolvePackageEntry (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29517:9)
          at tryResolveFile (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29247:38)
          at tryFsResolve (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29229:16)
          at Context.resolveId (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29107:28)
          at Object.resolveId (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38255:55)
          at processTicksAndRejections (node:internal/process/task_queues:96:5)
          at async resolve (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38458:26)
          at async /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38644:34
          at async callback (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:920:28),
      location: {
        column: 10,
        file: '../../../../home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js',
        length: 0,
        line: 29521,
        lineText: '    throw new Error(`Failed to resolve entry for package "${id}". ` +\n' +
          '    at packageEntryFailure (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29521:11)\n' +
          '    at resolvePackageEntry (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29517:9)\n' +
          '    at tryResolveFile (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29247:38)\n' +
          '    at tryFsResolve (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29229:16)\n' +
          '    at Context.resolveId (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:29107:28)\n' +
          '    at Object.resolveId (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38255:55)\n' +
          '    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n' +
          '    at async resolve (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38458:26)\n' +
          '    at async /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38644:34\n' +
          '    at async callback (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:920:28)',
        namespace: 'file',
        suggestion: ''
      },
      notes: [
        {
          location: {
            column: 18,
            file: '../../../../home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js',
            length: 9,
            line: 38640,
            lineText: '            build.onResolve({\n' +
              '    at setup (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38640:19)\n' +
              '    at handlePlugins (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:842:23)\n' +
              '    at Object.buildOrServe (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1136:7)\n' +
              '    at /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:2064:17\n' +
              '    at new Promise (<anonymous>)\n' +
              '    at Object.build (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:2063:14)\n' +
              '    at Object.build (/home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/esbuild/lib/main.js:1913:51)\n' +
              '    at /home/kaspar/.nvm/versions/node/v16.13.2/lib/node_modules/hathora/node_modules/vite/dist/node/chunks/dep-971d9e33.js:38416:54\n' +
              '    at Array.map (<anonymous>)',
            namespace: 'file',
            suggestion: ''
          },
          text: 'This error came from the "onResolve" callback registered here:'
        },
        {
          location: {
            column: 23,
            file: '../../client/prototype-ui/State.tsx',
            length: 16,
            line: 7,
            lineText: 'import CardPlugin from "./plugins/Card";',
            namespace: '',
            suggestion: ''
          },
          text: 'The plugin "vite:dep-scan" was triggered by this import'
        }
      ],
      pluginName: 'vite:dep-scan',
      text: 'Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "/tmp/tussie-mussie/client/prototype-ui/plugins/Card". The package may have incorrect main/module/exports specified in its package.json.'
    }
  ],
  warnings: []
}

I'm guessing it was written for an older version of Hathora but there's no way to find out which.
One solution could be a top-level package.json and you always do npm run hathora (or maybe global hathora does that for you).
{
  "dependencies": {
    "hathora": "^0.5.19"
  },
  "scripts": {
    "hathora": "hathora"
  }
}

A less appealing but simpler solution would be to embed a version in hathora.yml and simply fail if hathora doesn't match.

Thanks for filing. The actual issue is that the prototype UI tries to import the Card plugin via import CardPlugin from "./plugins/Card";. This works if you define the plugin in an index.ts file but not index.tsx. I need to figure out how to get tsx plugins working with Hathora (let me know if you have any ideas).
Embedding the Hathora version in your project via a root level package.json is a totally valid option. This is something you can do already btw -- do a npm install hathora at root and then you can run hathora via e.g. npx hathora dev. I should probably document this pattern.
The only downside is for people who don't want a package.json in their root (this is for a future where there is expanded language support for Hathora, so you might have a Rust backend with a Kotlin frontend, and there is actually no Typescript in your project other than the generated prototype UI).
Let me know your thoughts on this.

(The issue of what's actually happening with tussie-mussie is an aside of course, let's figure that out somewhere else.)
As the examples grow there should be way to specify the hathora version at the very least (and bonus points if it can npm install the right version needed and run it). I gave some ideas above but am not a person that cares about having a Rust / Kotlin etc. support so I will leave it up to you.

Try out the local Hathora install and let me know how you like that. I think that’s the common pattern for pinning versions of node clis

I would be happy to add it to the docs as a recommended pattern/option if it works well for folks

FWIW I agree with the approach of npm install hathora -> npx hathora dev, I think it should be the default recommendation in the docs. This approach makes it better for reliable collaboration with other devs when the version is locked.

source: gharchive/issue

authors: francislavoie hpx7 kasbah

repo: hathora/builder

license: MIT


text:
Refactor Agent Engine Core

This refactors the Hawkular WildFly Agent core engine such that it is no longer a requirement that the agent be deployed within an EAP or WildFly server nor is it required to be deployed as a WildFly subsystem extension. The agent can still be deployed in that manner (as a WildFly subsystem extension) however the core engine can now be embedded in any Java VM. More importantly, it can now be injected in any VM via the Java -javaagent comment line option.
All the features still exist no matter the mode of deployment - specifically, the agent can still collect DMR and JMX inventory and metrics (or just metrics if you put the agent in metrics only mode).
The engine (org.hawkular.agent.javaagent.JavaAgentEngine) can be instantiated by passing to its constructor an agent engine configuration file (which is in YAML format).
See the README for instructions on injecting as a javaagent.

Created a JIRA for this: https://issues.jboss.org/browse/HWKAGENT-162

repo: hawkular/hawkular-agent

license_source: bigquery


text:
Bump opentracing version to 0.20.7

@objectiser could you please review? I would like to include this into the next release.

@pavolloffay LGTM :+1:

authors: objectiser pavolloffay

repo: hawkular/hawkular-apm


text:
Expose stream and config

The exported object is still the familiar favicons() function. However, this function now has some properties: setConfig(), generateFavicons(), and generateFaviconStream(). The first two were basically present inside index.js before, but now we can require() them from elsewhere. generateFaviconStream() is the streaming interface that was previously hidden inside generateFavicons(), split out so stream-aware tools like gulp can use it. The original test still works, now there's another test for setConfig() and generateFaviconStream().
The code for setConfig() is kind of a mess, since I had to pull in other stuff that was scattered all over the place. Someone with a firmer vision for favicons options could improve this.
:smile: This is yet another "first step" in fixing haydenbleasel/gulp-favicons#2.

Awesomeness. As for:

The code for setConfig() is kind of a mess, since I had to pull in other stuff that was scattered all over the place. Someone with a firmer vision for favicons options could improve this.

That's basically what I'm in the middle of sorting out. The old architecture was like:

RFG -> rfg_api -> real_favicon -> favicons -> gulp-favicons

New architecture is easier:

RFG -> favicons -> gulp-favicons

Thanks for this.

authors: haydenbleasel jessaustin

repo: haydenbleasel/favicons

license: mit


text:
Improve documentation

The documentation could be improved by:

Reviewing the language e clearness
Adding live examples (maybe links to codesandbox)

For instance, I just realized the explanation of the shouldDraw parameter of the addLayer method is not very clear. What it does is running a draw cycle in the engine once the layer's promise is resolved.

repo: hbmuller/philately


text:
Directory metadata analysis progress bar

Since the runtime of the directory analysis tool is rather long, the hope is to have a progress bar to estimate how long the program will run for
This is currently implemented in directory.py as a function of the total number of files. This is an accurate measure because the program processes files in tandem and each file takes approximately the same amount of time to process
However, it is time-consuming to count the number of files in a directory, especially for one on the scale of terabytes. Therefore, it is necessary to somehow estimate the total number of files
I have tested various Python libraries as well as cmd scripts. The current os.walk implementation is already very efficient and the only improvement I observed was from the robocopy cmd command which is roughly 20% faster (but still infeasible for larger directories)
It may be possible to run the program for a bit, track runtime v. data (in terms of file size) processed, then run a linear regression or curve fit to estimate total runtime after n files are processed, but this may lack accuracy due to runtime being a function of # of files rather than file size

May not be possible to address this issue. Perhaps revisit in the future if new use cases arrise.

authors: benjaminLuoHC pgaviganHC

repo: hc-sc-ocdo-bdpd/file-processing-tools


text:
[fix] error caused by transform order

I tried to run your code with my own datasets, and found it gives me the following error messages.
I could fix that error by changing the order of transform.
I'd be glad if you could take a look at this message.
Code I run:
python train.py --phase 'train' --dataset_path 'my_path' --project_path './output'

The error I got:
TypeError: cannot unpack non-iterable builtin_function_or_method object

I switched  the order of CenterCrop(input_size) and ToTensor(), and everything worked well.

Information is not enough. Could you give me more information?
I recommend you to try pytorch lightning version. It's much easier and stable. Iink is on README.md

Thank you very much for your reply.
I used torch=1.6.0
I simply thought you need to replace
def data_transforms(load_size=256, mean_train=mean_train, std_train=std_train):
    data_transforms = transforms.Compose(
        [
            transforms.Resize((load_size, load_size), Image.ANTIALIAS),
            transforms.ToTensor(),
            transforms.CenterCrop(input_size),
            transforms.Normalize(mean=mean_train, std=std_train),
        ]
    )
    return data_transforms

with
def data_transforms(load_size=256, mean_train=mean_train, std_train=std_train):
    data_transforms = transforms.Compose(
        [
            transforms.Resize((load_size, load_size), Image.ANTIALIAS),
            transforms.CenterCrop(input_size),
            transforms.ToTensor(),
            transforms.Normalize(mean=mean_train, std=std_train),
        ]
    )
    return data_transforms

However, I now understand that this issue is caused by the difference between pytorch and pytorch lightning.
Thank you.

Util now I've not encountered that problem. But I'm grad to hear that you solved the problem.
Thank you.


text:
verilator: Update to version 5.018

Updating to Verilator 5.018 slightly improves performance for us, so I wanted to gauge if there is any interest in upstreaming these changes.
Quite a few things have happened in the Verilator, so the rules proposed in this draft are not backward compatible with Verilator 4.224. Is it desirable to support both versions?

/gcbrun

Will merge if it passes the ci

Posting a quick reminder in case this one has slipped through the cracks over the holidays. Let me know if anything is missing for a merge!

@mithro @QuantamHD Kind reminder...

@QuantamHD @mithro friendly ping here 😄 I was gonna make the same change but found this PR to have been a step ahead.
Though, @hovind do you wanna bump to v5.0.22 (current latest)?

I've opened https://github.com/hdl/bazel_rules_hdl/pull/292 which bumps to 5.0.22 and resolves conflicts.

This could be closed now that https://github.com/hdl/bazel_rules_hdl/pull/292 is merged.

I hadn't noticed that conflicts had appeared. Thanks for pushing this forward, @abrisco!

authors: QuantamHD abrisco hovind oharboe


text:
HI i am using circle image view in grid view and when i change the postion by draging the image or select from gallery.

Image become invisible after changing the position in grid view and after selection from gallery.
I use notifyDataSetChanged after selection and after drag one place to other

Without any more details there's nothing I can do. Please reopen and add the relevant code snippets if still relevant.

authors: hdodenhof sandeepsinghsohal

repo: hdodenhof/CircleImageView


text:
🛑 stagin-env is down

In 8773895, stagin-env (https://staging.lessonpal.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: stagin-env is back up in cf1d6e2.

repo: heIsThePirate/upptime-lessonpal


text:
Unable to Import from ...

Hello,
I'm working on Intellij 2016.2.4 and I have the following exception everytime I try to "Import from" an AEM server
com.intellij.openapi.application.Application.invokeAndWait(Ljava/lang/Runnable;)V
java.lang.NoSuchMethodError: com.intellij.openapi.application.Application.invokeAndWait(Ljava/lang/Runnable;)V
at com.headwire.aem.tooling.intellij.action.ImportFromServerAction.doImport(ImportFromServerAction.java:149)
at com.headwire.aem.tooling.intellij.action.ImportFromServerAction.execute(ImportFromServerAction.java:84)
at com.headwire.aem.tooling.intellij.action.AbstractProjectAction$1.run(AbstractProjectAction.java:99)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:635)
at com.intellij.openapi.progress.impl.CoreProgressManager$3.run(CoreProgressManager.java:170)
at com.intellij.openapi.progress.impl.CoreProgressManager.a(CoreProgressManager.java:494)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:443)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:54)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:155)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$1.run(ProgressManagerImpl.java:128)
at com.intellij.openapi.application.impl.ApplicationImpl$2.run(ApplicationImpl.java:307)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
My IntelliJ full version :
IntelliJ IDEA 2016.2.4
Build #IU-162.2032.8, built on September 9, 2016
JRE: 1.8.0_112-release-b343 x86
JVM: OpenJDK Server VM by JetBrains s.r.o

Thx

Thank you for the report. This method was a recent addition to IntelliJ but I'm surprised it's not in 2016.2.
I will check and backport their code into the plugin if needed.

It turns out that IntelliJ had this method in place but in 2016.2 they required an additional parameter. So I used this method signature instead and it should fix your issue.
Please try out this pre-release https://github.com/headwirecom/aem-ide-tooling-4-intellij/commit/8044c7ea00314bce74fc514f711dbf5e0fa330d8 and let me know if that works out.

Hi,
Thx I will try it tomorrow and let you know.
Envoyé de mon iPhone

Le 27 mars 2017 à 01:25, Andreas Schaefer notifications@github.com a écrit :
It turns out that IntelliJ had this method in place but in 2016.2 they required an additional parameter. So I used this method signature instead and it should fix your issue.
Please try out this pre-release 8044c7e and let me know if that works out.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I guess this is not a problem anymore. Please re-open if that is still an issue.

authors: jlallement schaefa


text:
Make image size full-screen

Hello, is there any way to make image full-screen for example [here] (https://drive.google.com/file/d/1UiYy_viqzKvKngFcGn7vlVoH6q7DsYS2/view?usp=sharing) I made a screenshot of the problem
There is so much space wasted, but image is very small and uses only a third part of available space
It would be great to set an image width to be maximum, and be able to scroll down to label lower parts of the images

Hi! We use maxHeight to fit image canvas into browser viewport, but you can disable this by adding maxHeight="auto" to Image tag.

There is no maxHeight parameter in docs! Setting maxWidth="auto" still leaves with a lot of unused space

<View>
  <Image name="image" value="$image" zoom="true" zoomControl="false" rotateControl="false" maxWidth="auto"/>
  <RectangleLabels name="label" toName="image" strokeWidth="1">
    <Label value="Car" background="blue"/>
    <Label value="Person" background="#FFA39E"/>
    <Label value="Bicycle" background="#D4380D"/>
    <Label value="Motorcycle" background="#FFC069"/>
    <Label value="Scooter (el sparkesykkel)" background="#AD8B00"/>
    <Label value="Truck" background="#D3F261"/>
    <Label value="Bus" background="#389E0D"/>
    <Label value="Tram" background="#5CDBD3"/>
  </RectangleLabels>
</View>

My answer was for described problem when image is much higher than a screen given its aspect ratio.
In your case the problem is in default zoom and also in detected canvas size (it's calculated as the size for image zoomed in to fit maximum space on screen, which is not good for small images) We'll deal with this things very soon, we already have a plan for canvas/zoom improvements, and the first step is already made

authors: hlomzik maiiabocharova zeljkomarinkovic

repo: heartexlabs/label-studio


text:
Failed to compile heavyDB; CUDA architecture not detected

Hi,
I am unable to complie heavyDB. I have both the nvidia compiler and nvidia drivers setup in the system.
I have followed the steps below --
./scripts/mapd-deps-prebuilt.sh &&  mkdir build &&  cd build &&  cmake ..
The scripts/mapd-deps-prebuild.sh executes successfully.
The error code received is --
CMake Error at /usr/local/share/cmake-3.25/Modules/CMakeDetermineCUDACompiler.cmake:603 (message):
  Failed to detect a default CUDA architecture.

  Compiler output:

Call Stack (most recent call first):
  CMakeLists.txt:194 (enable_language)

My system environment is as follows:

OS and kernel version:  Ubuntu 20.04.6;  5.4.0-120-generic
GCC version: 9.4.0
CUDA version: 11.4
Nvidia driver version: 470.57.02
Boost version:  1.71.0
LLVM version: 12.0
CMake version:  3.25.1
OpenJDK version: 13.0.1

Let me know if I need to downgrade/upgrade any software to allow the build to happen as well.
Alternatively, when I try to compile by disabling CUDA like --
cmake -DENABLE_CUDA=off ..
I get the following error:
CMake Error at /usr/local/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Thrift (missing: Thrift_VERSION)
Call Stack (most recent call first):
  /usr/local/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  cmake/Modules/FindThrift.cmake:96 (find_package_handle_standard_args)
  CMakeLists.txt:373 (find_package)

To compile the GPU version, you need CUDA 11.8; version 11.4 is outdated. Additionally, ensure your GPU driver is at least version 520.x (though it's not required at compile time).
If you encounter issues with CMake, make sure to run mapd-deps.sh found in /usr/local/mapd-deps. This directory includes the Thrift library and other dependencies not present in the standard Ubuntu repositories.

Hi,
I upgraded the CUDA version to 12.1 and GPU driver to 530.x. However the cmake is still failing. Do I need to make any changes in the CMakeLists.txt file?
Thanks for the suggestion though!

Hello,
Just wanted to let you know that you don't need to make any modifications to the CMakeLists.txt file. Instead, you can try adding "-DCMAKE_CUDA_ARCHITECTURES=75" (replace 75 with the appropriate version for your setup) to your command.
However, please note that you may encounter an error if you run this command with an unsupported CUDA version or if you have already run the config script. To avoid this, run the command "source /usr/local/mapd-deps/mapd-deps.sh" before running the cmake command.
With the release of 8.0, we will probably move to cuda 12.1. However, for now, we are using 11.8. I'm installing cuda 12.1 to try and reproduce your error.

authors: cdessanti shwetaiisc

repo: heavyai/heavydb


text:
ERROR smithay_client_toolkit::window::concept_frame No font could be found

Ubuntu 20.04, Kernel 5.8.0, Wayland, Radeon HD 7730M, installed vulkan tools using this guide
I was first running into a bunch of font errors as mentioned here #386, I followed the advice to install fontconfig (and libfontconfig1-dev) and those errors went away.  However one remained.  Here is the output I see when I try to cargo run the tours example.

WARNING: radv is not a conformant vulkan implementation, testing use only.
[2021-04-08T18:15:59Z ERROR smithay_client_toolkit::window::concept_frame] No font could be found

I'm not sure how do deal with either line 1 or 2.  On line one, it warns about radv.  But in my grub command I've modified it to set amdgpu on and radeon support off like so:

GRUB_CMDLINE_LINUX_DEFAULT="radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dc=1 amdgpu.dpm=1 amdgpu.modeset=1"

For the second line of output (the "ERROR smithay_client_toolkit::window::concept_frame"), I have no idea what might fix that and nothing helpful showing up on search engines.
Any advice on how to fix this?

Very good advice for someone who doesn't use Linux often, thanks.

repo: hecrj/iced


text:
Display Date

What Date does PicFrame display when it shows the Date at the bottom of the photo.  The reason I ask is since it does not match the Exif Date Created tag when I look at them with exiftools.  Thanks.

I guess it's this if exists (just looked in configuration.yaml)
DateTimeOriginal
IFD		Exif
Code		36867 (hex 0x9003)
Name		DateTimeOriginal
Otherwise the file creation date is used.

Yes. @helgeerbe's above response is correct.

authors: helgeerbe jgodfrey john-k-mcdowell

repo: helgeerbe/picframe


text:
4.x: small archetype issues

Minor issues found while testing the 4.0 archetypes:
database-mp

[x] README says "that uses the dbclient API". This uses JPA.

quickstart-se

[x] README: health URL uses PORT instead of 8080. This is different from all other urls in the README
[x] pom has two copies of dependencies for helidon-webserver-observe-health and helidon-health-checks
[x] Exception when test runs:

2023.08.24 11:05:46.430 Attempt to start in unexpected state state STARTED; ignored
java.lang.IllegalStateException
        at io.helidon.metrics.PeriodicExecutor.lambda$startExecutor$1(PeriodicExecutor.java:139)
        at io.helidon.metrics.PeriodicExecutor.sync(PeriodicExecutor.java:175)
        at io.helidon.metrics.PeriodicExecutor.startExecutor(PeriodicExecutor.java:124)
        at io.helidon.metrics.PeriodicExecutor.start(PeriodicExecutor.java:91)
        at io.helidon.metrics.RegistryFactory.start(RegistryFactory.java:199)
        at io.helidon.webserver.observe.metrics.MetricsFeature.beforeStart(MetricsFeature.java:166)

Fixed by #7459

authors: barchetta tvallin

repo: helidon-io/helidon


text:
Gradle jandex fails when using Enums

Environment Details

Helidon Version: 4.0.0-m2
Helidon SE or Helidon MP - MP
JDK version: 21
OS: Linux - Fedora
Docker version (if applicable):

Problem Description
When using an Enum like:
private enum DbTypes {
        POSTGRES("postgres"), SQLITE3("sqlite3"), CUBRID("cubrid"), MARIADB("mariadb"), IBMDB2(
                "ibmdb2"), CASSANDRA("cassandra"), FIREBASE("firebase"), NEO4J("neo4j");

        final String db;

        DbTypes(String db) {
            this.db = db;
        }
    }

gradlew clean run --stacktrace produces:
 at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
Caused by: java.lang.NullPointerException: Cannot read the array length because "bytes" is null
        at org.jboss.jandex.IndexWriterV2.writeByteTable(IndexWriterV2.java:259)
        at org.jboss.jandex.IndexWriterV2.write(IndexWriterV2.java:200)
        at org.jboss.jandex.IndexWriter.write(IndexWriter.java:102)
        at org.jboss.jandex.IndexWriter.write(IndexWriter.java:66)
        at org.kordamp.gradle.plugin.jandex.tasks.JandexWorkAction.execute(JandexWorkAction.groovy:70)
        at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:63)

By removing the Enum the Service starts as expected. Note, running helidon dev or mvn package works.
Can be easily reproduce by including an Enum in any class.
Steps to reproduce
Simply include an enum in code
Same error with either and with both commented;
runtimeOnly "io.smallrye:jandex"
runtimeOnly 'org.jboss:jandex:3.1.3'

however the plugin always uses jboss.

This may be resolved by including in build.gradle
jandex {
    version = '3.1.5'
}


text:
[Addition]: EXTREMELY OBVIOUS SPOOFING WRECKING ENTIRE DOWNTOWN BOISE TRANSMIT SCALE AND EARNINGS!!! BAN ASAP. ITS BEEN GOING ON FOR OVER A YEAR NOW!

Hotspot b58 Addresses
112ds1fUVpFGZkgTWAMZxnRnYDkChZDvhjrp6wv9XXWzZXS7CJeN
Discord Handle
No response
Reason(s)
So I have been watching a hotspot nearby me for about 7 months now. It usually earns more than anyone in quite wide radius around downtown Boise extending into out east a ways.
However, the hotspot only EVER communicates or participates in activities with 6 to 7 other hotspots.... that’s it.... it literally NEVER talks to any other devices. The exact same devices see the beacons. If you check out the beacon witness map for every single beacon event for Brisk Slate Pelican, you will see that the lines connecting the witness map NEVER CHANGE!!! Also, if you check out any of the other 6 to 7 devices in this little spoof group, you will see that those devices only communicate with an extremely limited group of devices as well. Why? To increase each other’s witness rewards Drastically. If you only ever witness beacons seen by like 4-6 other hotspots, you will LItERALLY earn like triple as much as a hotspot with all 14 witnesses per beacon....
Literally this guy is my neighbor hex and I perform anywhere from 4-5x times more rewarded activities per day than any of them, in the same “asserted” geolocation and earn like 1/3 as much.. its total bs.
My transmit score since this spoof group has started to slowly grow has gone from .56 all the way down to .31 in four months. Yet, my directly adjacent hexes have not gained any additional devices in that times Frame.
Also if you looks at the distance of each hotspot in the rewarded activities... EVERY SINGLE ONE of them is between 2.1 and 3.6m apart supposedly.
Every single friggin hex in greater Boise except for like 1 or 2 hexes all now have transmit scale scores of .36 or less now. The other 1 or 2 hexes have a few 1 transmit scale scores and .8 scores but every single one of those devices has been listed as offline for months and months and months.
Please fix this and deny list Brisk Slate Pelican. It’s incredibly obvious this is a group spoof. Most likely 6 data only hotspots in a small enclosed room surrounded by metal to the outside world😂 and most likely nowhere near actual downtown Boise.

All the hotspots involved
11225Rydy7L4ezoGVYcHAvbiuX8rmH1zQ5edZXfpF7YMDPvYzYr9
112ds1fUVpFGZkgTWAMZxnRnYDkChZDvhjrp6wv9XXWzZXS7CJeN
112rnd7y1RWwndXLJuEkYqSpdaFmNoaDXBNPfssK5kxnLMQrJXww
1189xsbke9jdTcmb8PjGy4ezks4tUFWKQCuKisCxoQnVsTSajtm
11K7zYRNiKRyuKz68fNQ778yoKKsJXG2KYXaNFSTgV3LQ4W9E3Y
11N5KquW9jrHcyHjJAJeP3vfHJCmdqqfQLswReRsDcBnXsjhfpY
11P3TGwgFTNu64ufz8SACKC76v3uHFY3s2RJFZGja3upLGMjWGQ
11YhyY5zrH6JCMde5hi9mh8BGAqmd8kyNwaczos4Xtuqc67YcNm

repo: helium/denylist


text:
react native crypto update

resolves invalid 0000 checksum issue when creating an account. New accounts will now be created with proper checksums. Existing accounts with 0000 checksums can still be imported.
updates all the @helium libraries to the latest

LGTM. Need to test locally

[x]  Peroni test

Tested and Looks good. Was able to import account with 12 words and proper checksum.

løser ugyldig 0000kontrollsum-problem når du oppretter en konto. Nye kontoer vil nå opprettes med riktige sjekksummer. Eksisterende kontoer med 0000kontrollsummer kan fortsatt importeres.
oppdaterer alle @heliumbibliotekene til det siste

repo: helium/hotspot-app


text:
你好，ccaa_web_tar.gz下载不了

安装过程中，到下载这里的时候，一直下载不了，http://soft.xiaoz.org/linux/ccaa_web.tar.gz

抱歉，软件库服务器流量超标被服务商暂停了，要15号重置流量后才能恢复。

抱歉，软件库服务器流量超标被服务商暂停了，要15号重置流量后才能恢复。

目前仍然是404，无法下载安装

我把文件放到了github repo上.
试试这个:
bash <(curl -L git.io/ccaasudo.sh)

authors: crazypeace helloxz webfury zouyuefen

repo: helloxz/ccaa


text:
[stable/ghost] GhostPath admin bootstrapping process fails when non-/

Describe the bug
The adminuser bootstrapping step will always fail with any path other than root, it does not take into account the ghostPath setting and this causes it to always attempt to reach the administrative path on /ghost, rather than {ghostPath}/ghost
Version of Helm and Kubernetes:
Helm: 3.0.0
Kubernetes 1.14.9
Which chart:
Stable/Ghost
What happened:
When ghostPath is set to anything but /, the bootstrapping process (adminuser fails)
ghost   INFO  ==> Creating admin user... Error executing 'postInstallation': Server returned status code 404 from http://127.0.0.1:2368/ghost/ Server returned status code 404 from http://127.0.0.1:2368/ghost/
What you expected to happen:
the adminUser bootstrapping process should take the path field, either from ghostHost or ghostPath into consideration
How to reproduce it (as minimally and precisely as possible):
any of the following:
helm install --set ghostHost='domain.com',ghostPath='/blog'  --generate-name stable/ghost
helm install --set ghostHost='domain.com',ghostPath='/blog/'  --generate-name  stable/ghost
helm install --set ghostHost='domain.com/blog'  --generate-name stable/ghost
Anything else we need to know:
Theres a workaround where you can boot the instance using the root path, then directly manipulate the config later to the desired path

Hi @Chronojam
It looks like there was a bug in the version of the image the chart is using, please use the latest one
helm install gh stable/ghost --set ghostHost='localhost',ghostPath='/blog' --set image.tag=3.4.0-debian-10-r4

Regards.

Sorry about the long delay in responding
with the new image tag this now works as intended, im going to close this issue now
Thanks for looking into this!

repo: helm/charts


text:
[stable/prometheus-operator] Failed to list *v1.ThanosRuler: thanosrulers.monitoring.coreos.com is forbidden: User "system:serviceaccount:monitoring:sandbox-operator" cannot list resource "thanosrulers" in API group "monitoring.coreos.com" at the cluster scope

Describe the bug
There is an unexpected flood of error message for Thanos Ruler CRDS
Version of Helm and Kubernetes:
Helm: 2.15.1
Kubernetes: v1.14.10-gke.17
Which chart:
prometheus-operator version 8.10.0
What happened:
E0301 17:04:11.624026       1 reflector.go:123] github.com/coreos/prometheus-operator/pkg/thanos/operator.go:315: Failed to list *v1.ThanosRuler: thanosrulers.monitoring.coreos.com is forbidden: User "system:serviceaccount:monitoring:sandbox-operator" cannot list resource "thanosrulers" in API group "monitoring.coreos.com" at the cluster scope
E0301 17:04:12.626151       1 reflector.go:123] github.com/coreos/prometheus-operator/pkg/thanos/operator.go:315: Failed to list *v1.ThanosRuler: thanosrulers.monitoring.coreos.com is forbidden: User "system:serviceaccount:monitoring:sandbox-operator" cannot list resource "thanosrulers" in API group "monitoring.coreos.com" at the cluster scope
E0301 17:04:13.653165       1 reflector.go:123] github.com/coreos/prometheus-operator/pkg/thanos/operator.go:315: Failed to list *v1.ThanosRuler: thanosrulers.monitoring.coreos.com is forbidden: User "system:serviceaccount:monitoring:sandbox-operator" cannot list resource "thanosrulers" in API group "monitoring.coreos.com" at the cluster scope
E0301 17:04:14.655977       1 reflector.go:123] github.com/coreos/prometheus-operator/pkg/thanos/operator.go:315: Failed to list *v1.ThanosRuler: thanosrulers.monitoring.coreos.com is forbidden: User "system:serviceaccount:monitoring:sandbox-operator" cannot list resource "thanosrulers" in API group "monitoring.coreos.com" at the cluster scope
E0301 17:04:15.658397       1 reflector.go:123] github.com/coreos/prometheus-operator/pkg/thanos/operator.go:315: Failed to list *v1.ThanosRuler: thanosrulers.monitoring.coreos.com is forbidden: User "system:serviceaccount:monitoring:sandbox-operator" cannot list resource "thanosrulers" in API group "monitoring.coreos.com" at the cluster scope

What you expected to happen:
No error log message
How to reproduce it (as minimally and precisely as possible):
Install Helm prometheus-operator version 8.10.0
Anything else we need to know:

@Shini31 did you find a solution, I face the same issue. I guess it has to do with the recent thanos addition

I was able to resolve the issue by not installing the crd-thanosrulers.yaml
So I do skip CRD installation and install the CRDs manually skipping  crd-thanosrulers.yaml.
Maybe @vsliouniaev can take a look at it again as system:serviceaccount:monitoring:sandbox-operator does not exist.

@Shini31 did you find a solution, I face the same issue. I guess it has to do with the recent thanos addition

On the issue is still present

The PR proposed by @sbuzonas fixes the issue

Can confirm!


text:
[stable/mysql] --initialize specified but the data directory has files in it. Aborting.

Describe the bug
when i`m use cmd "helm install ", deployment is start error.
and i find the log

i`m modify the vaule.yaml
## mysql image version
## ref: https://hub.docker.com/r/library/mysql/tags/
##
image: "mysql"
imageTag: "5.7.28"

strategy:
  type: Recreate

busybox:
  image: "busybox"
  tag: "1.29.3"

testFramework:
  enabled: true
  image: "dduportal/bats"
  tag: "0.4.0"

## Specify password for root user
##
## Default: random 10 character string
mysqlRootPassword: 123456

## Create a database user
##
mysqlUser: nacos
## Default: random 10 character string
mysqlPassword: nacos

## Allow unauthenticated access, uncomment to enable
##
# mysqlAllowEmptyPassword: true

## Create a database
##
mysqlDatabase: nacos_devtest

## Specify an imagePullPolicy (Required)
## It's recommended to change this to 'Always' if the image tag is 'latest'
## ref: http://kubernetes.io/docs/user-guide/images/#updating-images
##
imagePullPolicy: IfNotPresent

## Additionnal arguments that are passed to the MySQL container.
## For example use --default-authentication-plugin=mysql_native_password if older clients need to
## connect to a MySQL 8 instance.
args: []

extraVolumes: |
  # - name: extras
  #   emptyDir: {}
extraVolumeMounts: |
  # - name: extras
  #   mountPath: /usr/share/extras
  #   readOnly: true
extraInitContainers: |
  # - name: do-something
  #   image: busybox
  #   command: ['do', 'something']
# Optionally specify an array of imagePullSecrets.
# Secrets must be manually created in the namespace.
# ref: https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod
# imagePullSecrets:
  # - name: myRegistryKeySecretName

## Node selector
## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
nodeSelector: {}

## Tolerations for pod assignment
## Ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
##
tolerations: []

livenessProbe:
  initialDelaySeconds: 120
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 3

readinessProbe:
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3

## Persist data to a persistent volume
persistence:
  enabled: true
  ## database data Persistent Volume Storage Class
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  storageClass:
    storageClassName: nacos-sc-mysql
    provisioner: fuseim.pri/ifs
    classParameters: {}
  accessMode: ReadWriteOnce
  size: 10Gi
  annotations: {}

## Use an alternate scheduler, e.g. "stork".
## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/
##
# schedulerName:

## Security context
securityContext:
  enabled: false
  runAsUser: 999
  fsGroup: 999

## Configure resource requests and limits
## ref: http://kubernetes.io/docs/user-guide/compute-resources/
##
resources:
  requests:
    memory: 2Gi
    cpu: 1000m

# Custom mysql configuration files path
configurationFilesPath: /etc/mysql/conf.d/

# Custom mysql configuration files used to override default mysql settings
configurationFiles:
  mysql.cnf: |-
    [mysqld]
    pid-file  = /var/run/mysqld/mysqld.pid
    socket    = /var/run/mysqld/mysqld.sock
    datadir   = /var/lib/mysql

    symbolic-links=0

    secure-file-priv= NULL
    skip-host-cache

    skip-name-resolve

    server-id = 1

    port = 3306

    autocommit = 0

    character_set_server=utf8mb4

    collation-server = utf8mb4_general_ci

    init_connect='SET NAMES utf8mb4'

    transaction_isolation = READ-COMMITTED

    lower_case_table_names = 1

    max_connections = 800

    back_log = 210

    max_connect_errors = 1000

    explicit_defaults_for_timestamp = true

    max_allowed_packet = 128M

    interactive_timeout = 1800
    wait_timeout = 1800

    tmpdir  = /tmp

    tmp_table_size = 134217728
    max_heap_table_size = 134217728

    read_buffer_size = 8388608

    read_rnd_buffer_size = 2097152

    join_buffer_size = 8388608

    sort_buffer_size = 4194304

    binlog_cache_size = 524288

    log_error = /var/log/mysql/error.log

    slow_query_log = 1
    slow_query_log_file = /var/log/mysql/slow.log

    log_queries_not_using_indexes = 1

    log_throttle_queries_not_using_indexes = 5

    log_slow_slave_statements = 1

    long_query_time = 8

    min_examined_row_limit = 1000

    expire_logs_days = 7

    master_info_repository = TABLE
    relay_log_info_repository = TABLE

    log_bin = /var/log/mysql/bin.log

    sync_binlog = 5

    log_slave_updates = 1

    gtid_mode = on

    enforce_gtid_consistency = 1

    binlog_gtid_simple_recovery = 1

    log_slave_updates = 1

    binlog_format = row

    binlog_row_image = minimal

    relay_log = /var/log/mysql/relay.log

    relay_log_recovery = 1

    slave_skip_errors = ddl_exist_errors

    innodb_page_size = 16384

    innodb_buffer_pool_size = 2G

    innodb_buffer_pool_instances = 8

    innodb_buffer_pool_load_at_startup = 1

    innodb_buffer_pool_dump_at_shutdown = 1

    innodb_lru_scan_depth = 2000

    innodb_io_capacity = 4000

    innodb_io_capacity_max = 8000

    innodb_lock_wait_timeout = 30

    innodb_file_per_table = 1

    innodb_undo_logs = 128

    innodb_log_file_size = 1073741842
    innodb_log_buffer_size = 16777216

    innodb_purge_threads = 4

    innodb_thread_concurrency = 0

    innodb_print_all_deadlocks = 1

    innodb_sort_buffer_size = 8338608
# Custom mysql init SQL files used to initialize the database
initializationFiles:
  nacos-config.sql: |-
    use nacos_devtest;
    CREATE TABLE `config_info` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `data_id` varchar(255) NOT NULL COMMENT 'data_id',
      `group_id` varchar(255) DEFAULT NULL,
      `content` longtext NOT NULL COMMENT 'content',
      `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
      `gmt_create` datetime NOT NULL DEFAULT '2010-05-05 00:00:00' COMMENT '创建时间',
      `gmt_modified` datetime NOT NULL DEFAULT '2010-05-05 00:00:00' COMMENT '修改时间',
      `src_user` text COMMENT 'source user',
      `src_ip` varchar(20) DEFAULT NULL COMMENT 'source ip',
      `app_name` varchar(128) DEFAULT NULL,
      `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
      `c_desc` varchar(256) DEFAULT NULL,
      `c_use` varchar(64) DEFAULT NULL,
      `effect` varchar(64) DEFAULT NULL,
      `type` varchar(64) DEFAULT NULL,
      `c_schema` text,
      PRIMARY KEY (`id`),
      UNIQUE KEY `uk_configinfo_datagrouptenant` (`data_id`,`group_id`,`tenant_id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info';
#  first-db.sql: |-
#    CREATE DATABASE IF NOT EXISTS first DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
#  second-db.sql: |-
#    CREATE DATABASE IF NOT EXISTS second DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

metrics:
  enabled: false
  image: prom/mysqld-exporter
  imageTag: v0.10.0
  imagePullPolicy: IfNotPresent
  resources: {}
  annotations: {}
    # prometheus.io/scrape: "true"
    # prometheus.io/port: "9104"
  livenessProbe:
    initialDelaySeconds: 15
    timeoutSeconds: 5
  readinessProbe:
    initialDelaySeconds: 5
    timeoutSeconds: 1
  flags: []
  serviceMonitor:
    enabled: false
    additionalLabels: {}

## Configure the service
## ref: http://kubernetes.io/docs/user-guide/services/
service:
  annotations: {}
  ## Specify a service type
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services---service-types
  type: ClusterIP
  port: 3306
  # nodePort: 32000
  # loadBalancerIP:

## Pods Service Account
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
serviceAccount:
  ## Specifies whether a ServiceAccount should be created
  ##
  create: false
  ## The name of the ServiceAccount to use.
  ## If not set and create is true, a name is generated using the mariadb.fullname template
  # name:

ssl:
  enabled: false
  secret: mysql-ssl-certs
  certificates:
#  - name: mysql-ssl-certs
#    ca: |-
#      -----BEGIN CERTIFICATE-----
#      ...
#      -----END CERTIFICATE-----
#    cert: |-
#      -----BEGIN CERTIFICATE-----
#      ...
#      -----END CERTIFICATE-----
#    key: |-
#      -----BEGIN RSA PRIVATE KEY-----
#      ...
#      -----END RSA PRIVATE KEY-----

## Populates the 'TZ' system timezone environment variable
## ref: https://dev.mysql.com/doc/refman/5.7/en/time-zone-support.html
##
## Default: nil (mysql will use image's default timezone, normally UTC)
## Example: 'Australia/Sydney'
# timezone:

# Deployment Annotations
deploymentAnnotations: {}

# To be added to the database server pod(s)
podAnnotations: {}
podLabels: {}

## Set pod priorityClassName
# priorityClassName: {}

## Init container resources defaults
initContainer:
  resources:
    requests:
      memory: 10Mi
      cpu: 10m

and i add the storageclass.yaml
{{- if and .Values.persistence.enabled (not .Values.persistence.existingClaim) -}}
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: {{ .Values.persistence.storageClass.storageClassName }}
provisioner:
{{ toYaml .Values.persistence.storageClass.provisioner | indent 2 }}
parameters:
{{ toYaml .Values.persistence.storageClass.classParameters | indent 2 }}
reclaimPolicy: Retain
allowVolumeExpansion: true
{{- end }}

I found the same error because of the lost + found folder
290
Or data exists in the mounted host folder
398
But my error is not like this，In the deployment.yaml file, initC is defined and lost + found is deleted and i'm user the storageclass create the pvc+pv，so pv is empty.
and the pod was first created，these files are created below my pv ，

Then the pod reports an error
Version of Helm and Kubernetes:
v1.13.5
Which chart:
https://hub.helm.sh/charts/stable/mysql

One more thing to add：
modify the pvc.yaml：
{{- if and .Values.persistence.enabled (not .Values.persistence.existingClaim) }}
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: {{ template "mysql.fullname" . }}
  namespace: {{ .Release.Namespace }}
{{- with .Values.persistence.annotations  }}
  annotations:
{{ toYaml . | indent 4 }}
{{- end }}
  labels:
    app: {{ template "mysql.fullname" . }}
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
spec:
  accessModes:
    - {{ .Values.persistence.accessMode | quote }}
  resources:
    requests:
      storage: {{ .Values.persistence.size | quote }}
{{- if .Values.persistence.storageClass }}
{{- if (eq "-" .Values.persistence.storageClass.storageClassName) }}
  storageClassName: ""
{{- else }}
  storageClassName: "{{ .Values.persistence.storageClass.storageClassName }}"
{{- end }}
{{- end }}
{{- end }}

helm lint 试过么

helm lint 试过么

能创建成功，helm lint只是校验文件格式的。
我的错误时pod里面的mysql初始化时，说数据文件夹中有数据

头盔皮棉试过么

能创造成功，helm lint只是校验文件格式的。
我的错误时pod里面的mysql初始化时，说数据文件夹中有数据

方便发下部署命令么

I'm having the same issue. Any luck solving it?

I'm having the same issue. Any luck solving it?

no，i have given up，if you solved，please tell me the way

hello everybody，i have been resolved this error.The reason is nfs server，but idon·t know why. I just used the hostpath pv to replace storageclass.

same issue here

Adding  the below solved my issue
args:
- "--ignore-db-dir=lost+found"

Adding the below solved my issue
args:

"--ignore-db-dir=lost+found"

Where abouts did you add this argument exactly? I'm having this issue when trying to mount an external volume with mysql...thanks!

Adding the below solved my issue
args:

"--ignore-db-dir=lost+found"

Where abouts did you add this argument exactly? I'm having this issue when trying to mount an external volume with mysql...thanks!

I'm using helm chart, so in the Deployment template I added the "args" as below:
          args:
            - "--ignore-db-dir=lost+found"
          volumeMounts:
            - name: mysql-initdb
              mountPath: /docker-entrypoint-initdb.d
            - name: {{ .Values.Mysql.name }}-persistent-storage
              mountPath: /var/lib/mysql

Adding the below solved my issue
args:

"--ignore-db-dir=lost+found"

This is it!

Adding the below solved my issue
args:

"--ignore-db-dir=lost+found"

Where abouts did you add this argument exactly? I'm having this issue when trying to mount an external volume with mysql...thanks!

I'm using helm chart, so in the Deployment template I added the "args" as below:
          args:
            - "--ignore-db-dir=lost+found"
          volumeMounts:
            - name: mysql-initdb
              mountPath: /docker-entrypoint-initdb.d
            - name: {{ .Values.Mysql.name }}-persistent-storage
              mountPath: /var/lib/mysql

This solution is working on OpenShift 4.5, thanks

authors: 294434171 avnertzur chrouzz dacianmujdar mrandrewdh one-two-my-gad ricardoandre97 rim-wood


text:
[stable/prometheus-adapter] Add podLabels support

What this PR does / why we need it:
Allow to add labels to prometheus-adapter pods created by deployment.
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @mattiasgees


text:
[stable/prometheus-pushgateway] configureable deployment strategy

What this PR does / why we need it:
When the pushgateway is configured to use a PV for storage and the PV does not allow multi attach, updates can't be applied because the newly created pod can never attach the storage volume and thus never starts. The old pod never gets deleted (and manually deleting the old pod also doesn't work in all cases). I changed the default behavior because I don't consider this a relevant change in behavior for the pushgateway.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/lgtm

Same error as in: https://github.com/helm/charts/issues/20639
/retest

@cstaud I get "Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message." plz trigger retest

Experiencing the same build error in another chart's PR. Seems to be more generic and affect many charts.

/ok-to-test

authors: cobexer cstaud douglascamata


text:
[stable/jenkins] configure agent.args in values.yaml

What this PR does / why we need it:
We have agent.args is empty by default, but then we set default when rendering templates. This is confusing to users and could be simplified.

./templates/_helpers.tpl
        {{- if .Values.agent.args }}
        args: "{{ .Values.agent.args }}"
        {{- else }}
        args: "^${computer.jnlpmac} ^${computer.name}"
        {{- end }}

./templates/config.yaml
{{- if .Values.agent.args }}
                  <args>{{ .Values.agent.args }}</args>
{{- else }}
                  <args>${computer.jnlpmac} ${computer.name}</args>
{{- end }}

It would be best if we could set this here to:
args: "${computer.jnlpmac} ${computer.name}"

and take care of escaping dollar signs in the template.
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @mogaal

/lgtm

authors: mogaal torstenwalter


text:
[stable/prometheus-redis-exporter] Add support for tolerations and affinity

Signed-off-by: JulienBreux julien.breux@gmail.com
What this PR does / why we need it:
Add possibility to add Tolerations and Affinity to prometheus-redis-exporter pods.
Tolerations and affinity allow better scheduling.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x]  DCO signed
[x]  Chart Version bumped
[x]  Variables are documented in the README.md
[x]  Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @acondrat

Please document new values in readme.md
/ok-to-test

Please document new values in readme.md

Done! 😊

/lgtm

authors: JulienBreux acondrat


text:
[stable/rabbitmq-ha] Upgrade RabbitMQ to 3.8.4 version

What this PR does / why we need it:
Upgrades stable/rabbitmq-ha Helm chart to use the latest 3.8.4 RabbitMQ by default.
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

@steven-sheehy done!


text:
Local dependency not found if in a directory different than charts

Output of helm version:
version.BuildInfo{Version:"v3.11.1", GitCommit:"293b50c65d4d56187cd4e2f390f0ada46b4c4737", GitTreeState:"clean", GoVersion:"go1.19.5"}

I am new to helm and was playing with how dependencies can be used to manage charts for different components so I am not sure if this is a misunderstanding on my part or a bug.
Scenario:
One chart (poc2-stack-playground) with one pod template and one subchart (example-subchart-app) with one deployment and configmap.
Code available here with all the existing files
In summary:
Dependency defined:
dependencies:
  - name: example-subchart-app
    repository: "file://subcharts/example-subchart-app"
    version: "0.1.0"

Chart contains:
./templates/simplepod.yaml

Subchart contains (no conditions)
./subcharts/example-subchart-app/templates/deployment.yaml
./subcharts/example-subchart-app/templates/configmap.yaml

Problem:
helm dep list/update: Succeeds but...
NAME                	VERSION	REPOSITORY                           	STATUS
example-subchart-app	0.1.0  	file://subcharts/example-subchart-app	ok

helm install test-parentchart . --debug --dry-run: Installation fails due to missing dependency
helm install test-parentchart . --debug --dependency-update --dry-run:  Installation does not include subchart components

If subchart is created in the charts folder:

helm install ...: Installs expected components, pod, deployment and configmap

Expected behaviour:

It should be possible to have the code of local charts in a different folder. (helm dep update should copy the required files,tgz)
If the dependency is found by helm dep update, helm install should not complain of missing dependencies

Thanks for your help

Cannot duplicate.
version.BuildInfo{Version:"v3.11.1", GitCommit:"293b50c65d4d56187cd4e2f390f0ada46b4c4737", GitTreeState:"clean", GoVersion:"go1.20.1"}

Found the problem, thank you @joejulian
I tried using the repo and I was able to install the helm without issues.
The difference between the repo and the folder where I was testing was the .helmignore, so I reviewed and saw that I had added *tgz  (instead of adding it to the .gitignore)
After removing *tgz from the .helmignore the installation and dependencies work as expected.

authors: alsastre joejulian

repo: helm/helm


text:
Helm 3: "required" template function breaks linter

Output of helm version:
$ helm version
version.BuildInfo{Version:"v3.0.0-alpha.1", GitCommit:"b9a54967f838723fe241172a6b94d18caf8bcdca", GitTreeState:"clean"}

Output of kubectl version:
N/A
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
N/A
If a chart uses the required filter with no default value running helm lint over the chart will fail, this does not happen in helm 2.
An example chart that will reproduce this issue is as follows:
Chart.yaml
apiVersion: v1
name: test
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application.
appVersion: 1.16.0

values.yaml
---

templates/foo.yaml
---
foo: {{ .Values.unset | required "uset is required!" }}

When running helm lint on this chart you get the following error:
Error: 1 chart(s) linted, 1 chart(s) failed
	%!s(<nil>)
	[INFO] Chart.yaml: icon is recommended
	[ERROR] templates/: render error at (test/templates/foo.yaml:3): 'uset is required!'

When running the same command using helm 2 the chart is valid
$ helm2 version --client
Client: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}

$ helm2 lint .
2019/06/13 16:00:11 [INFO] Missing required value: uset is required!
==> Linting .
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, no failures

I believe this maybe a regression of #4747 and #4221.

The patch was never brought over to Helm 3 prior to the removal of Tiller. Should be as simple as porting that patch over to the dev-v3 branch. Feel like taking a crack at that?

The patch was never brought over to Helm 3 prior to the removal of Tiller. Should be as simple as porting that patch over to the dev-v3 branch. Feel like taking a crack at that?

I've opened a PR, the dev-v3 and master branch have drifted a bit but I think I've got everything across.

Fixed by #5889.

authors: andytom bacongobbler


text:
Helm 3 alternative namespace for Release

Hi guys,
Is it possible to save release not in the same namespaces with deployment.. etc.. ?
We have 50 services installer via helm in dev/stage which also has own service's secret and now it is looks messy.
Can we optionally save release(secrets) in specific namespace ?

@alexandrsemak Unfortunately not as it is designed to save the release data as a secret in the namespace of the deployment.
The only way that I can see around it would be to organize the installation of the services into different namespaces. This might not be feasible for your use case.

@hickeyma gotcha, thank you for your answer. I understood that is possible to install each service in uniq namespace not sure if we able follow this approach.

Hope you can use this approach. Will close out the issue as answered. If you have any other questions, raise an issue or ask out in the helm-users Slack channel: https://github.com/helm/helm#community-discussion-contribution-and-support

authors: alexandrsemak hickeyma


text:
Add Helm charts for NATS.io

We have started to officially support Helm charts for NATS.io and we'd like to add them to the Helm Hub repo :)
> helm repo add nats https://nats-io.github.io/k8s/helm/charts/
> helm repo update

> helm repo list
NAME          	URL
nats          	https://nats-io.github.io/k8s/helm/charts/

> helm install my-nats nats/nats
> helm install my-stan nats/stan --set stan.nats.url=nats://my-nats:4222

Signed-off-by: Waldemar Quevedo wally@synadia.com

Thanks @mattfarina I've updated with the change :)

Thanks!

repo: helm/hub


text:
Write the initial buffrs guide to get people started

Add missing documentation / guidance in the buffrs book.

Some gaps are filled in by #157

Done

repo: helsing-ai/buffrs


text:
Chore Add forceErrorOnStatusCode

Description
copilot:summary
Changes
copilot:walkthrough

copilot:summary

repo: henomis/restclientgo