Grafana issue on Synology NAS

Hi,
I tried setting up the Powerwall-Dashboard with Docker on a Synology NAS. I'm not sure if this is even supposed to work, but the setup script is running fine and three containers seem to start up okay. Only grafana keeps shutting down with the following entries in the docker log:
GF_PATHS_DATA='/var/lib/grafana' is not writable.
You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migration-from-a-previous-version-of-the-docker-container-to-5-1-or-later
mkdir: cannot create directory '/var/lib/grafana/plugins': Permission denied
Any idea what is causing this or how to get grafana running?
Best regards,
Jochen

Hi @jaydkay - When grafana starts, it attempts to install the required plugins as indicated by the error.  It uses user 1000 group 1000 for this directory.  The link you pasted talks about this as being a user permission issue.  Some ideas I have:
Is it possible you already had grafana (older version) installed?  Try removing it and re-install:
# stop and remove
docker stop grafana
docker rm grafana

# reinstall
docker-compose -f powerwall.yml up -d

I have seen permission error if you run thesetup.sh as root.  If you did this, try to remove the Powerwall-Dashboard folder and reinstall using the local user.  You will need to make sure your local user has docker permissions:
# Add your user to docker group
sudo usermod -aG docker $USER

If that wasn't the case, you could try to change the permission manually:
# run a shell in grafana interactively
docker exec -ti --user root grafana /bin/bash
ls -la /var/lib/grafana/
chown 1000:1000 /var/lib/grafana/

Dear @jasonacox,
thanks for your quick reply. I tried following your suggestions, alas, no success so far...

Is it possible you already had grafana (older version) installed? Try removing it and re-install:

No, it's a completely new installation from scratch. In fact, it's my first contact with docker.

I have seen permission error if you run thesetup.sh as root. If you did this, try to remove the Powerwall-Dashboard folder and reinstall using the local user. You will need to make sure your local user has docker permissions:

Yes, I needed to start ./setup.sh via sudo - it seems that on Synology DSM, docker is typically not available for the normal user. Command usermod also doesn't exist, but there are corresponding commands, so was able to add the current user to the docker group and start docker with a standard user account. Unfortunately, the error remained the same. Additionally, now also Telegraf refuses to start with the following log entry:
I! Using config file: /etc/telegraf/telegraf.conf
E! [telegraf] Error running agent: Error loading config file /etc/telegraf/telegraf.conf: open /etc/telegraf/telegraf.conf: permission denied
Finally, I also tried your final suggestion:

If that wasn't the case, you could try to change the permission manually:

That didn't work either, because the container already refuses to start, so the command you suggested complains about grafana not yet running (but it never will):
Error response from daemon: Container ac20100690faff31b7c2df6bcb6fa9079eea9a496efdbbcf2fed6b8144731aae is restarting, wait until the container is running
If you have any more suggestions, please let me know. Thanks a lot again for your help!

Since you originally used sudo the file permission are likely in bad shape. I suggest removing the Powerwall-Dashboard directory and reinstall from scratch now that you have your local user in the docker group:
# remove the old install
rm -fr Powerwall-Dashboard

# git clone or pull down the repository again
git clone https://github.com/jasonacox/Powerwall-Dashboard.git

# run setup
cd Powerwall-Dashboard
./setup.sh

Thanks for the feedback on this.  Hopefully we can figure this out for anyone else using a Synology NAS to host their dashboard. :)

Awesome!!  Nice job @jaydkay !  Thanks for posting the helpful instructions.  I'll reference that in the troubleshooting tips.

Hi @jasonacox, @jaydkay,
I've just run into either the same problem or a closely related one while setting up Powerwall-Dashboard under a rootless docker. I was getting the same messages as Jochen GF_PATHS_DATA='/var/lib/grafana' is not writable. and mkdir: cannot create directory '/var/lib/grafana/plugins': Permission denied.
It took a while for me to track it down - as far as I can tell for the rootless version, it comes down to the fact that grafana runs with user:group ids of 472:0 in the rootless container, and this results in name space mapping issues when creating/writing files on the host machine (this explanation isn't quite right, but is probably close enough to the truth allow resolution of the problem).
I found two possible solutions:

The first solution is probably safe in a rootless system, but I really wouldn't recommend it as a) only probably safe and b) if you ever switch to a normal docker, it becomes very not safe.  It's simple - run the rootless container as "root" by changing the grafana user line in powerwall.yml to user: "0:0". This works as docker rootless maps root to the user running the docker installation. Again, I would really not recommend this approach - I'm just including it as someone else may find this step useful in their own troubleshooting.

The second solution is somewhat cleaner, although I'm pretty sure this is still just a work around for a limitation on name space mapping for rootless docker.

Change the grafana user line in powerwall.yml to user: "472:0" (you may be able to delete it altogether - haven't tried this).

Get the subuid entry for the user xxxx running docker from /etc/subuid on the host machine. In my case it is xxxx:100000:65536 - from this, we can calculate the uid mapping of the container uid grafana user to a subuser user id on the host machine as: first number in the subuid (100000) + 471 (0 offset of the grafana uid) - so for me this is 100471.

Change the ownership of the grafana directory in Powerwall-Dashboard on the host machine to this subuid:
sudo chown 100471 ./grafana (Fails without sudo, but this is a subuid in the xxxx user name space, so has the same privileges as xxxx - effectively no change in permissions)

Running ls -ld ./grafana should result in:
drwxr-xr-x 6 100471 xxxx 4096 Sep 21 10:54 ./grafana (where xxxx is the username running docker - same as the subuid file).

Kill the current container and restart.

docker stop grafana
docker rm grafana
docker compose -f powerwall.yml up -d

I hope this saves someone else a day or so of digging in the future. Picking up docker this way was definitely a baptism by fire.
Finally, @jasonacox, thanks again for the time you have put into a great monitoring tool!

Thanks for this great information, @BuongiornoTexas !  Is this on a Synology NAS or something else?

Is this on a Synology NAS or something else?

Raspberry Pi 4B - so quite the journey getting docker running at all even without dealing with getting it rootless and the grafana permissions issue.
Dropped in here as the error is identical to Jochen's and almost certainly related, but if you want to include it as a tip, I'd put it in a section on grafana permissions and/or rootless docker.

Thanks @BuongiornoTexas !!!- I'm running on a Raspberry Pi as well (Raspbian GNU/Linux 11 bullseye).  Can you cat /etc/os-release for anyone following this?
For my setup, I had to run something like this:
# Install docker
curl -fsSL https://get.docker.com/ -o get-docker.sh
sudo sh get-docker.sh
sudo apt install -y docker-compose

# Add your user to docker group
sudo usermod -aG docker $USER

# Set docker to start on boot
sudo systemctl enable docker.service
sudo systemctl enable containerd.service

# install docker-compose
sudo pip3 install docker-compose

I wonder if I can add notes or setup.sh instructions to help.

Like you, I'm on bullseye (64 bit).
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian

I think the difference between our installs is that I'm running docker as a non-privileged (rootless) user. So I don't have a docker group at all.
The process for setup is a bit messier, but works pretty well. It's detailed at: https://docs.docker.com/engine/security/rootless/
The steps I took were:

Use apt -qq list yyy to check for the following pre-req packages, and if not, installed them.
uidmap
dbus-user-session
fuse-overlayfs
slirp4netns (0.4 or later)

Run the Without packages install script  curl -fsSL https://get.docker.com/rootless | sh. At which point docker engine is installed.

Added the two environment lines at the end of the script to my .bashrc:

 export PATH=/home/username/bin:$PATH
 export DOCKER_HOST=unix:///run/user/1000/docker.sock

Installed v2 of docker compose manually per the process at https://docs.docker.com/compose/install/linux/ (there are binaries for arm64 on github now, aarch64 file identifier from uname -m!) :
DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
mkdir -p $DOCKER_CONFIG/cli-plugins
curl -SL https://github.com/docker/compose/releases/download/v2.11.0/docker-compose-linux-aarch64 -o $DOCKER_CONFIG/cli-plugins/docker-compose

I think everything was running after this.

Thanks @BuongiornoTexas ! This is a great 'get starting' for anyone wanting to run docker as a non-privileged (rootless) user.  I'll capture this in the troubleshooting section for anyone else wanting to do the same.
Thank you!

No probs. One more step I forgot - I created a file called docker-compose in ~/bin containing:
docker compose "$@"

And ran chown +x ~/bin/docker-compose. An alias that emulates v1 with v2.
Alternatively, users can just run docker compose manually.

I had the same permission error on a Pi4 running Ubuntu. The only way I could fix it was to change the grafana user line in powerwall.yml to user: "0:0", as noted by @BuongiornoTexas.

The only way I could fix it was to change the grafana user line in powerwall.yml to user: "0:0",

Is this on a standard docker install? If so, something doesn't sound quite right there - the problem I had was because docker was missing some of the privileges from a standard install (I think you have effectively given your grafana instance root privileges in the docker container, which shouldn't be needed at all).
One quick thought is your user id 1000? If not, that would break the setup.

Yes, it is standard.  My user id is 1001.

I change powerwall.yml to user: "1001", killed the current container and reinstalled. It is now working as expected.

Excellent. You may want to make the powerwall.yml entry 1001:1001 so that it also has the correct group permissions.

Hi all - i am also trying to install this on my Synology NAS.
This is what I have done so far:

I created a shared folder called Powerwall
Followed the instructions above:
Log in via SSH to Synology DSM. Create a usergroup docker:
sudo synogroup --add docker

Change ownership of docker to this group:
sudo chown root:docker /var/run/docker.sock
Make the user a member of the newly created group:
sudo synogroup --member docker

installed from github: git clone https://github.com/jasonacox/Powerwall-Dashboard.gi

ran the ./setup.sh from the directory Powerwall-Dashboard:

Backupadmin@BackupStation:/volume1/powerwall/Powerwall-Dashboard$ ./setup.sh

Now I am getting this error back:
Powerwall Dashboard (v2.8.0) - SETUP
ERROR: docker is not available or not runnning.
This script requires docker, please install and try again.
Docker is running on the Synology. The user "BackupAdmin" is a member of the "docker" group:

Is there anything else I can check to figure out what the issue is ?
Thanks so much for your help.

HI @marcbaier - I hope our community can chime in on this.  I guess I need to add a "Synology NAS" to my test suite (currently MacOS, Ubuntu Linux, Win 11 WSL and Raspberry Pi). 😄  What model are you using?

ERROR: docker is not available or not runnning.

What do you get when you run docker ps or docker info?

I get this when running docker ps:
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": dial unix /var/run/docker.sock: connect: permission denied
docker info:
Client:
Context:    default
Debug Mode: false
Server:
ERROR: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix /var/run/docker.sock: connect: permission denied

I am trying to run this on a DS1513+ running DSM7.1.1. I could also try it on a newer DS1019+ but I would presume that I would get the same issue there as well.

Thanks @marcbaier - that helps a lot!  Your local user does not have permission to run docker.  Check the permissions of the socket:
ls -l /var/run/docker.sock

Also, just to confirm, you did run these?
sudo synogroup --add docker
sudo chown root:docker /var/run/docker.sock
sudo synogroup --member docker $USER

DS1513+ running DSM7.1.1.

Thanks!  I'll see if I can find one.

This is what i get back when I run the docker.sock command above:
srw-rw---- 1 root docker 0 Feb  4 09:02 /var/run/docker.sock

Interesting.  That should work if your local user is part of the docker group.  I have seen it "not take" until I log out and log in again or reboot the host (on Linux, not a Synology). You can also try this (a common 'fix' mentioned on the docker helps):
sudo chmod 666 /var/run/docker.sock

That worked ! Now I was able to install the whole ./setup.sh. I am now stuck at the grafana setup. The IP Address of my Synology Nas is <IP_ADDRESS> and I wanted to use the browser on my iMac to access: http://<IP_ADDRESS>:9000, but I am getting an "this site can't be reached" error.

looks like grafana is not running. I went and looked into the docker install and this is what I see:

When I try to restart grafana I am getting these errors, as I think others on here also got:
GF_PATHS_DATA='/var/lib/grafana' is not writable.
You may have issues with file permissions, more information here: http://docs.grafana.org/
mkdir: cannot create directory '/var/lib/grafana/plugins': Permission denied

Did you follow the hints in my post at the beginning of this thread?
https://github.com/jasonacox/Powerwall-Dashboard/issues/22#issuecomment-1107892237
This part in particular:

Finally, edit file powerwall.yml and change the line
user: "1000:1000"
in the section grafana to the uid of the user on the Synology. I got that by running id while logged in via SSH.
After this, I was able to issue ./setup.sh, finish setting it up and all containers are starting up.

You probably need to stop, delete and re-create the containers after doing this change to take effect.

I did follow your instructions and replaced the uid with mine. however, I did not delete and re-create the containers. How would I do that ? directly in docker and then run the ./setup.sh again ?

ok so i did the following:

stop and delete all the containers
check the powerwall.yml file and change the value to 1029
(uid=1029(Backupadmin) gid=100(users) groups=100(users),101(administrators),65536(docker))
executed ./setup.sh again
in the docker app on the synology I still see the grafana and telegraf containers restarting.... so i guess nothing has changed.

ah - think i found the issue.  Now that I've done that, the containers are not restarting anymore and I am not getting an error message either.
thanks so much

You‘re welcome.

How can i change the way the savings are calculated in the dashboard ?

@marcbaier did you get the Grafana dashboard running?
FYI - some interesting endpoints you could test:

http://<IP_ADDRESS>:8675/vitals - Powerwall vitals
http://<IP_ADDRESS>:8675/stats - pypowerwall stats
http://<IP_ADDRESS>:8676 - weather411 current conditions

Yes I got it all running fine on the NAS but I don't seem to be getting any weather data. The bottom panels are empty:

I agree, it doesn't look like weather411 is running.
Try http://<IP_ADDRESS>:8676/ - weather411 current conditions
Also try:
# check logs
docker logs weather411

# restart weather411
docker restart weather411

When i click on the link above, I get a "this site can't be reached" error.
docker logs weather411 returns this:
Backupadmin@BackupStation:~$ docker logs weather411
Weather411 Server 0.1.2
ERROR: No config file. Fix and restart.
The error remains after doing a restart.

The weather411 configuration is missing. Run this:
./weather.sh

See the instructions here:
You will need to include your location (Latitude and Longitude) and your OpenWeatherMap API Key. To get a Key, you need to set up a free account at openweathermap.org. Make sure you check your email to verify account. API keys can take a few hours to activate.

Hi Jason - I thought I had already gone through this process during the regular setup. So I did it again using the code above. Here is the whole process:
Backupadmin@BackupStation:/volume1/powerwall/Powerwall-Dashboard$ ./weather.sh
Weather Data Setup
Weather data from OpenWeatherMap can be added to your Powerwall Dashboard
graphs.  This requires that you set up a free acccount with OpenWeatherMap
and enter the API Key during this setup process.
Do you wish to setup Weather Data? [y/N] y
Forecast looks great!  Proceeding...
Existing Configuration Founded
[Weather411]
DEBUG = no
[API]
Port to listen on for requests (default 8676)
ENABLE = yes
PORT = 8676
[OpenWeatherMap]
Register and get APIKEY from OpenWeatherMap.org
APIKEY = ff2a0e5eb1a213c45bf5bfc4d64baa3b
Enter your location in latitude and longitude
LAT = 47.4140132
LON = 8.2375113
WAIT = 10
TIMEOUT = 10
standard, metric or imperial
UNITS = metric
[InfluxDB]
Record data in InfluxDB server
ENABLE = yes
HOST = influxdb
PORT = 8086
DB = powerwall
FIELD = weather
Leave blank if not used
USERNAME =
PASSWORD =
Overwrite existing settings? [y/N] y
Removing old file weather/weather411.conf.
Set up a free account at OpenWeatherMap.org to get an API key

Go to https://openweathermap.org/
Create a new account and check your email to verify your account
Click on 'API Keys' tab and copy 'Key' value and paste below.

Enter OpenWeatherMap API Key: ff2a0e5eb1a213c45bf5bfc4d64baa3b
Enter your location coordinates to determine weather in your location.
For help go to https://jasonacox.github.io/Powerwall-Dashboard/location.html
Enter Latitude: 47.4140132
Enter Longitude: 8.2375113
Enter the desired units: M)etric, I)mperial or S)tandard where:
M)etrics = temperature in Celsius
I)mperial = temperature in Fahrenheit
S)tandard = temperature in Kelvin
Enter M, I or S: m
Units selected: metric
NOTE: The OpenWeatherMap key can take up to 2 hours to be valid.
You may see errors or no data until it is fully activated.
Running Docker Compose...
influxdb is up-to-date
pypowerwall is up-to-date
grafana is up-to-date
weather411 is up-to-date
telegraf is up-to-date
Weather Setup Complete
Backupadmin@BackupStation:/volume1/powerwall/Powerwall-Dashboard$

I stopped and deleted the old weather411 container before I did the above. When i look at the newly created weather411 containers log, i still see this:

Ok, wow, that's confusing!  The python script can't find the ./weather/weather411.conf file (which for you should be /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf).
When you set up the containers (ran setup.sh or compose-dash.sh), did you run them from the /volume1/powerwall/Powerwall-Dashboard folder?
TODO for me is to add a more helpful error message to Weather411.  It should list the config file it is trying to load.
Possible workaround:
Edit the powerwall.yml and edit the weather411 section to set a full path in the "source" for the volume mapping:
    weather411:
        image: jasonacox/weather411:latest
        container_name: weather411
        hostname: weather411
        restart: always
        user: "1000:1000"
        volumes:
            - type: bind
              source: /volume1/powerwall/Powerwall-Dashboard/weather
              target: /var/lib/weather
              read_only: true
        ports:
            - target: 8676
              published: 8676
              mode: host
        environment:
            - WEATHERCONF=/var/lib/weather/weather411.conf
        depends_on:
            - influxdb

Restart:
./compose-dash.sh up -d

hi Jason - i did make the changes to the powerwall.yml file. I stopped and deleted the weather411 container and executed the command you provided. however still no change:

Thanks for trying to get this to work and your troubleshooting steps.  It just occurs to me that the NAS may not be allowing access to user 1000.  Let's check the ownership of that file:
# see what it has right now to confirm this could be the issue
ls -l /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf

If it doesn't match user 1000 or is not world readable:
# change owner
sudo chown 1000:1000 /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf

# or change permission
sudo chmod a+r /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf

# restart
docker restart weather411
docker logs weather411 -f

OK I did this. When I now check the owner I get:
-rwxrwxrwx 1 1000 1000 534 Feb 11 23:30 /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf
restarted, but the logs still show:

Let's shell in to the weather411 docker container to see what it sees - try this from the command line (ssh):
docker exec -it weather411 sh
ls -l /var/lib
ls -l /var/lib/weather
set | grep WEATHER

# you may also try this just to make sure it can read the file
cat /var/lib/weather/weather411.conf

Here is what I see on my system:
$ docker exec -it weather411 sh
/app $ ls -l /var/lib
total 16
drwxr-xr-x    2 root     root          4096 Aug  9  2022 apk
drwxr-xr-x    2 root     root          4096 Aug  9  2022 misc
drwxr-xr-x    2 root     root          4096 Aug  9  2022 udhcpd
drwxr-xr-x    3 1000     1000          4096 Feb  9 07:03 weather
/app $ ls -l /var/lib/weather
total 68
-rw-r--r--    1 1000     1000           153 Feb  9 07:02 Dockerfile
-rw-r--r--    1 1000     1000          4660 Feb  9 07:02 README.md
drwxr-xr-x    3 1000     1000          4096 Feb  9 07:02 contrib
-rw-r--r--    1 1000     1000         13181 Feb  9 07:02 dashboard-weather411.json
-rw-r--r--    1 1000     1000         18131 Feb  9 07:02 server.py
-rwxr-xr-x    1 1000     1000           725 Feb  9 07:02 upload.sh
-rw-r--r--    1 1000     1000           535 Feb  9 07:03 weather411.conf
-rw-r--r--    1 1000     1000           531 Feb  9 07:02 weather411.conf.bak
-rw-r--r--    1 1000     1000           531 Feb  9 07:02 weather411.conf.sample
/app $ set | grep WEATHER
WEATHERCONF='/var/lib/weather/weather411.conf'

Don't know if this might help, but on my Synology system, the respective config-file weather411.conf is owned by the current user (admin) and is not an executable:
admin@ds:~$ ls -l Powerwall-Dashboard/weather/weather411.conf
-rw-r--r-- 1 admin users 532 Feb 11 16:45 Powerwall-Dashboard/weather/weather411.conf

Looking into the container, it looks like this:
admin@ds:~$ docker exec -it weather411 sh
/app $ ls -l /var/lib
total 0
drwxr-xr-x    1 root     root             0 Aug  9  2022 apk
drwxr-xr-x    1 root     root             0 Aug  9  2022 misc
drwxr-xr-x    1 root     root             0 Aug  9  2022 udhcpd
drwxr-xr-x    1 1024     users          250 Feb 11 15:45 weather
/app $ ls -l /var/lib/weather
total 64
-rw-r--r--    1 1024     users          153 Feb 11 15:43 Dockerfile
-rw-r--r--    1 1024     users         4660 Feb 11 15:43 README.md
drwxr-xr-x    1 1024     users           32 Feb 11 15:43 contrib
-rw-r--r--    1 1024     users        13181 Feb 11 15:43 dashboard-weather411.json
-rw-r--r--    1 1024     users        18131 Feb 11 15:43 server.py
-rwxr-xr-x    1 1024     users          725 Feb 11 15:43 upload.sh
-rw-r--r--    1 1024     users          532 Feb 11 15:45 weather411.conf
-rw-r--r--    1 1024     users          531 Feb 11 15:45 weather411.conf.bak
-rw-r--r--    1 1024     users          531 Feb 11 15:43 weather411.conf.sample

Btw, 1024 is the uid of the current user (admin) on my system.

Thanks @jaydkay !  It did strike me odd that @marcbaier 's system shows that file with the executable flag "x" for all.  Also, when you set this up on your Synology, do you recall any problems with weather411 or did it just work?
@marcbaier let us know what you system shows. Technically the permission on your system (and on @jaydkay ) should allow anyone to read that file including the weather411 python script.  I suspect something else is off like the file system is not getting namespace mapped into the docker container correctly.

It just worked out of the box. The only things I adjusted during setup of the Powerwall-Dashboard were the ones I mentioned in one of the first posts of this thread, see here.

Hi Jason - here we go:
/app $ ls -l /var/lib
total 20
drwxr-xr-x    2 root     root          4096 Aug  9  2022 apk
drwxr-xr-x    2 root     root          4096 Aug  9  2022 misc
drwxr-xr-x    2 root     root          4096 Aug  9  2022 udhcpd
drwx------    3 1029     users         4096 Feb 11 22:30 weather
/app $ ls -l /var/lib/weather
ls: can't open '/var/lib/weather': Permission denied
total 0

There's the problem!  The weather directory does not permit access. It should look like what @jaydkay posted:
drwxr-xr-x    1 1024     users          250 Feb 11 15:45 weather

See if you can fix it - ssh in and run:
ls -l /volume1/powerwall/Powerwall-Dashboard/

sudo chmod a+rx /volume1/powerwall/Powerwall-Dashboard/weather

ls -l /volume1/powerwall/Powerwall-Dashboard/

ok i did that and here is the result:
drwxr-xr-x  3 Backupadmin users   4096 Feb 11 23:30 weather
I then restarted the weather411 container and here is the log:
Weather411 Server [0.1.2]

Configuration Loaded [/var/lib/weather/weather411.conf]

Weather411 - Debug: False, Activate API: True, API Port: 8676
OpenWeatherMap - Key: ff2a0e5eb1a213c45bf5bfc4d64baa3b, Wait: 10, Units: metric
OpenWeatherMap - Lat: 47.4140132, Lon: 8.2375113, Timeout: 10
InfluxDB - Enable: True, Host: influxdb, Port: 8086, DB: powerwall, Field: weather

Starting threads

fetchWeather thread
apiServer thread - Listening on http://localhost:8676

I guess this means success ? If yes, you deserver a virtual beer ;)

Great news, @marcbaier !  Congratulations, you did it! ;)
Check your dashboard and you should now see weather data showing up in your graphs.  You can also visit the weather411 dashboard here: http://localhost:8676/ (replace localhost with the address of your NAS).

I guess this means success ? If yes, you deserver a virtual beer ;)

Haha!  I'll take it!  Or better yet a virtual cider or Oeil-de-Perdrix... 😂
In all seriousness, I do think we need better documentation or a setup.sh that better accommodates a Synology NAS hosted stack.

Hey all,  I'm installing the power wall dashboard on my Synology NAS well, and reading through this has helped me over the hurdles. I ran the quick start version (option 1) and was able to get all containers running.  I am stuck on the Grafana setup portion.  When adding the InfluxDB as a data source, I receive "error connecting influxDB influxQL" after I click Save and Test.
I confirm the influxdb container is running along with everything else.  Am i doing something wrong?

influxdb log.txt

Hi @panderson87 - thanks for opening this.
Did you happen to record or remember the main steps you took? It would be good to have that for others following the same path.  🙏
But more important, let's see if we can get your setup working!
InfluxDB Issues
This error could mean InfluxDB is not really listening - This would be evident in the "telegraf" logs:
# check logs of telegraf
docker logs telegraf

Errors would look like:
2023-02-20T05:37:00Z W! [outputs.influxdb] When writing to [http://influxdb:8086]: database "powerwall" creation failed: Post "http://influxdb:8086/query": dial tcp <IP_ADDRESS>:8086: connect: connection refused
2023-02-20T05:37:10Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: failed doing req: Post "http://influxdb:8086/write?db=powerwall&rp=raw": dial tcp <IP_ADDRESS>:8086: connect: connection refused
2023-02-20T05:37:10Z E! [agent] Error writing to outputs.influxdb: could not write any address
2023-02-20T05:37:20Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: failed doing req: Post "http://influxdb:8086/write?db=powerwall&rp=raw": dial tcp <IP_ADDRESS>:8086: connect: connection refused
2023-02-20T05:37:20Z E! [agent] Error writing to outputs.influxdb: could not write any address

Docker Networking Issues
The error you see could mean Grafana is unable to resolve the name "influxdb" which docker compose should handle. Option 1 (setup.sh) uses docker-compose to get this running (including setting up the 'network powerwall-dashboard_default' to handle the lookup and communication).  To test that all of this is set up correctly try this:
# take the stack down
./compose-dash.sh down

# rebuild the stack
./compose-dash.sh up -d

It should show something like this:

Try to set up the database again in Grafana after restarting.

Thanks for the quick reply.  So in checking the telegraf container, it was not fully started.  Logs showed
"error loading config file /etc/telegraf/telegraf.d/local.conf: open /etc/telegraf/telegraf.d/local.conf: permission denied"
So, I deleted the container, updated the powerwall.yml file and under telegraf, changed the user from 1000:1000 to match the uid/group of my Synology installer account (I initially did this for all of the other "user" entries in the file except for this one.)  Reran setup and was able to get the past the issue with the influxdb powerwall database.
10 minutes in, I am monitoring the Powerwall Power Flow dashboard and only see Weather reporting in so far.  All other graphs are currently showing "No Data."  I will give it more time.
I'll also type up my steps i took to get this installed later this evening.
Thanks!

Thanks @panderson87 !

error loading config file /etc/telegraf/telegraf.d/local.conf: open /etc/telegraf/telegraf.d/local.conf: permission denied

For anyone else who has that problem, it is an easy to fix with:
chmod 644 telegraf.conf
docker restart telegraf

All other graphs are currently showing "No Data." I will give it more time.

You should see data from telegraf immediately so this is not a good sign.  Telegraf is likely still having an error. Check docker logs telegraf and if you see the permission denied issue, try the above steps.

Looks like plugin errors.

Ran the commands above just to double check permissions, and they look ok.  Restarted container but not working still

The errors indicate that pypowerwall is not running correctly (see what docker logs pypowerwall show).
Also, did you start the containers using ./compose-dash.sh up -d?  I ask because docker-compose needs to build the networking to allow the containers to talk to each other.  Restart would be:
./compose-dash.sh down
./compose-dash.sh up -d

Sorry, I restarted the containers all manually from the Docker Gui in Synology.  Just rerun the commands in ssh and issue persists.
In checking the pypowerwall logs it looks like a login issue and/or network issue.  it's currently on wifi and it tends to drop off the network even though the AP is literally on the other side of the wall, i should get it hardwired.
Receiving this message when trying to log into the powerwall as a customer.
Error: API Limit Reached (Api Limit reached for this endpoint).
Here were the logs but I'm sure the API limit is the issue.
pypowerwall.txt

are you sure you don't have an authorization issue ? you should be seeing data immediately once grafana is running. did you use the last 5 digits from your tesla gateway and not the whole password ?

I had a similar issue today where pypowerwall wouldn’t start after update.  PW had an IP address but I couldn’t reach it from the browser. I ended up restarting the eero node it was connected to and then it worked.The timing was odd because it was right after I upgraded 2.8.2 > 2.8.3.  On Feb 20, 2023, at 11:46 AM, panderson87 @.***> wrote:
Sorry, I restarted the containers all manually from the Docker Gui in Synology.  Just rerun the commands in ssh and issue persists.
In checking the pypowerwall logs it looks like a login issue and/or network issue.  it's currently on wifi and it tends to drop off the network even though the AP is literally on the other side of the wall, i should get it hardwired.
Receiving this message when trying to log into the powerwall as a customer.
Error: API Limit Reached (Api Limit reached for this endpoint).
Here were the logs but I'm sure the API limit is the issue.
pypowerwall.txt
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

are you sure you don't have an authorization issue ? you should be seeing data immediately once grafana is running. did you use the last 5 digits from your tesla gateway and not the whole password ?

Yes, I am positive but will need to double-check that I don't have a typo.  I changed the default password and have been using tapping into the powerwall's production data via HomeAssistant Energy dashboard.
@dsf01 Yes, same issue here.  Either the page does not respond, which a handful of mesh reboots will fix that, or now in this case, I'm getting the API limit error.  I wonder if the HomeAssistant integration is having something to do with it.

Issue resolved. It did end up being the wrong password, somehow it got reset back to default! Thanks all.
Like I said I'll try to type out series of events later today.
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: dsf01 @.>
Sent: Monday, February 20, 2023 3:12:35 PM
To: jasonacox/Powerwall-Dashboard @.>
Cc: panderson87 @.>; Mention @.>
Subject: Re: [jasonacox/Powerwall-Dashboard] Grafana issue on Synology NAS (Issue #22)
I had a similar issue today where pypowerwall wouldn’t start after update.  PW had an IP address but I couldn’t reach it from the browser. I ended up restarting the eero node it was connected to and then it worked.The timing was odd because it was right after I upgraded 2.8.2 > 2.8.3.  On Feb 20, 2023, at 11:46 AM, panderson87 @.***> wrote:
Sorry, I restarted the containers all manually from the Docker Gui in Synology. Just rerun the commands in ssh and issue persists.
In checking the pypowerwall logs it looks like a login issue and/or network issue. it's currently on wifi and it tends to drop off the network even though the AP is literally on the other side of the wall, i should get it hardwired.
Receiving this message when trying to log into the powerwall as a customer.
Error: API Limit Reached (Api Limit reached for this endpoint).
Here were the logs but I'm sure the API limit is the issue.
pypowerwall.txt
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
—
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjasonacox%2FPowerwall-Dashboard%2Fissues%2F22%23issuecomment-1437503941&data=05|01||9853cda7690a42bbd55408db137ecf0c|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125207590930188|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=bRK%2BYz7wB8ByTJDRRbbDx6sEgTPbcG%2BL0GY0EkvYUcg%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAXCOJGDKIZNIRB5PYACS4Y3WYPF3HANCNFSM5UACDZBQ&data=05|01||9853cda7690a42bbd55408db137ecf0c|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125207590930188|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=2SThAEfrb7Okn3vMS2iTLVi%2BbNL4foHjxcAH%2Fs3wBOw%3D&reserved=0.
You are receiving this because you were mentioned.Message ID: @.***>

@panderson87 - Your powerwall dropping off wifi may be an ARP problem - more specifically, the powerwall may still be on the network, but ignoring ARP requests.
For me the symptoms were:

I could access the powerwall web interface immediately after rebooting my router.
After a couple of hours, it disappeared from the network, and I had to use the app to "reconnect" to the wifi.
Powerwall-Dashboard worked fine until the server machine needed a reboot, after which it lost the powerwall data feed.

If your problem is similar, you could try adding a static ARP entry - worked like magic for me (and saved several hundred dollars for the hard wiring).

I'll give that a shot. I had a dhcp reservation set up in the router and even forced the pw to connect to 2.4ghz thinking that would've help.
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: BuongiornoTexas @.>
Sent: Monday, February 20, 2023 4:20:19 PM
To: jasonacox/Powerwall-Dashboard @.>
Cc: panderson87 @.>; Mention @.>
Subject: Re: [jasonacox/Powerwall-Dashboard] Grafana issue on Synology NAS (Issue #22)
@panderson87https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpanderson87&data=05|01||3cf08625780e43b9e66008db13884530|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125248218179281|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=YBKIkAMBYFwX%2FvQiUd90NbCZS31lH8ORfyvLC2w77IU%3D&reserved=0 - Your powerwall dropping off wifi may be an ARP problem - more specifically, the powerwall may still be on the network, but ignoring ARP requests.
For me the symptoms were:

I could access the powerwall web interface immediately after rebooting my router.
After a couple of hours, it disappeared from the network, and I had to use the app to "reconnect" to the wifi.
Powerwall-Dashboard worked fine until the server machine needed a reboot, after which it lost the powerwall data feed.

If your problem is similar, you could try adding a static ARP entry - worked like magic for me (and saved several hundred dollars for the hard wiring).
—
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjasonacox%2FPowerwall-Dashboard%2Fissues%2F22%23issuecomment-1437559105&data=05|01||3cf08625780e43b9e66008db13884530|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125248218179281|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=foBQ3S7JxPmY2eSki0CE02ijUQdbWsqYavrP4bM1Erw%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAXCOJGDMT5GXPUTDMYSDXWDWYPNZHANCNFSM5UACDZBQ&data=05|01||3cf08625780e43b9e66008db13884530|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125248218179281|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=CGsNhDFwSGg1Ous%2FzaOYgKf6lRo1xgpKosUOgDz6qA8%3D&reserved=0.
You are receiving this because you were mentioned.Message ID: @.***>

Does sound like my issue (I also tried the 2.4GHz trick without success) - if the static ARP works, I've got a couple of cheat sheets for permanent static ARPs for windows and systemd setups. Let me know if you want either of them.

Congrats on getting it to work @panderson87 !

It did end up being the wrong password, somehow it got reset back to default!

I've seen that before. I don't know what triggers it, but have seen firmware updates reset the password in the past. The "Error: API Limit Reached" is the result of multiple bad password attempts.
On the WiFi conversation, I gave up on that after always getting drop-outs (even though it would reconnect after 5-10m) and just ran a hardware.  Zero issues for past year because of that.  But any WiFI pro tips @BuongiornoTexas would be great for our community.  :)
I had a thought... while the issues seem to be more prevalent for Synology users, we seem to have an increasing number of users having setup problems.  Most are related to some odd file ownership or permission setting (or even auth issue like this one for @panderson87 ). We spend a lot of time going back and forth doing basic troubleshooting steps to see what part of the stack isn't working correctly.  It would be super amazing if we had a simple verify.sh (or troubleshoot.sh) script that basically tests all of the components for health and reports exactly which parts of the stack are working correctly or where it sees errors.  I may take a stab at it today if I have time. I feel like it would help users find problems and get their setup working faster.

But any WiFI pro tips @BuongiornoTexas would be great for our community. :)

Well, I did the ARP fixes around December 2022 and haven't had any issues since, so it definitely worked for my problem. @jasonacox, your issues sounds a little different - the failure to respond to ARP takes a bit longer than 5-10 minutes to appear.
I'm going to save myself a bit of time - here is the write up I did for whirlpool. https://whrl.pl/RgxRzh

Here are the steps that I took to get this working on my NAS. I'm a github and noob so sorry if the formatting is not correct.
Make sure Docker has been installed in Package Center and SSH is enabled in Terminal & SNMP on your Synology NAS

On Synology NAS, in Control Panel>Shared Folder> Create a shared folder named powerwall
On Synology NAS, in Control Panel>User & Groups, select your user and edit. Under Permissions, make sure your user has read/write permissions to the powerwall share you created.
On your computer, from a browser, navigate to https://github.com/jasonacox/Powerwall-Dashboard.git
Download zip file and extract source code.
From your computer, in Windows Explorer, navigate to [\YourNasIP\powerwall](file://yournasip/powerwall)  then copy and paste the extracted source code into the powerwall share.  Confirm both files AND folders are there.
Use your favorite SSH tool and log in to your NAS (I used Putty) and log in as your install user (not root.) type in “id” and press enter to find your uid and gid.
Back on your NAS, edit the powerwall.yml file located in the powerwall share.  Find all lines that say:
user: "1000:1000"
and replace with your uid and gid and save.
In my case, mine now says user: "1026:101"
I changed this for pypowerwall, telegraf, Grafana, and weather411.
Back in SSH navigate to the Powerwall share where the source code is extracted to and run the command   ./setup.sh and follow the steps in the interactive setup.
If the setup does not run due to docker errors, refer to https://github.com/jasonacox/Powerwall-Dashboard#docker-errors

Wow! Thanks @panderson87 !

In my case, in addition to the steps regarding file ownership of docker and the usergroup settings mentioned in this post, I've only changed the user setting for grafana in compose.env. I did not need to change the user settings for all other containers, i.e. pypowerwall, telegraf and weather411. Don't know if it is important, just thought I should mention it.

Thanks @jaydkay - I'll keep this open to remind me to combine this insight into a guidance doc and FAQ for Synology users (unless someone else is willing to do that and submit a PR 😉 ).

I did not need to change the user settings for all other containers, i.e. pypowerwall, telegraf and weather411

Correct, they only read from the file system so as long as their user has read permission, it will work.  Grafana needs to write to disk for its settings.

I got this working following this comment by @jaydkay, but I wanted to clarify how to update the user in case it'll help someone else. After ssh'ing into the Synology NAS and running id, you will see this:
uid=1026(Daniel) gid=100(users) groups=100(users),101(administrators),65538(docker)

Open powerwall.yml and change every place where user: appears to the uid and group of your user, e.g. user: "1026:1026". There should be 4 places that it needs to be updated: under pypowerwall, telegraf, grafana, and weather411. The grafana entry will be user: "${GRAFANAUSER}", but just change it to user: "1026:1026". Of course, use the your own uid, not mine :).

Thank you, Daniel!


Permission Set

Went through steps loading into full sandbox but it did not create a permission set.

Hi @Rowe89,
Can you confirm that the package actually installed? I ask because people have reported that due to known issue W-5394323 that installing managed packages into sandboxes are failing. I wonder if you're in the same boat.
The only other workarounds are to either deploy the metadata from GitHub directly, or deploy into production (or try out in a free developer edition org).

Bug W-5394323 has since been fixed by Salesforce engineering teams. Please let me know if you encounter this again. Root cause was that the namespace cache for looking up Lightning components after installing a managed package was stale and so didn't have the new components. The new process is to invalidate the cache so the new components will be found.


Site.find_for_request should use request methods instead of request headers

Is there a reason that Site.find_for_request() inspects request headers directly instead of using request.get_host()?  It does not look like wagtail respects USE_X_FORWARDED_HOST due to how it looks up the request site.

I don't think so - I think that might just have been me being unaware of get_host...

Duplicated by #2358 (closing this one as the other has a corresponding pull request)


properly cleanup .discopop before running

We should be able to rerun all the tools and they should properly cleanup the .discopop directory before the execution so that leftover files of previous executions are removed and do not mess with the results.
Most tools already behave as expected, however some might not.
To close,

[ ] make sure that every tool works as expected even if there are (possibly outdated) leftovers of previous executions inside .discopop

linked to #467


need a button that says "upgrade to latest uProxy" when user goes to "https://www.uproxy.org/chrome-install"

https://www.uproxy.org/chrome-install this link
works great , I was wondering if we can make another button say's 'upgrade to latest uProxy' or something , -it will reinstall the latest app and remove the old app. at the moment , if user have previously installed app, this link shows the app is already been installed which is right but previously installed app was the old one.
I am putting this issue as p3 , since it's a good to have one

Can we update users to the latest version automatically @iislucas ?

Let's be careful here.  It's possible to image someone taking over the uproxy update system and forcing everyone to upgrade to a compromised version.  I'd personally prefer a "Newest version is ****, click [Here] to upgrade", or something along those lines.  That way users can check around with technical users that they trust before doing an upgrade.  Or at least an option for that explicit choice to upgrade vs auto-upgrade.  The latter is likely to leave users more secure on average, but with so much at stake, and us not having build much reputation yet, it's important that we keep the user in as much control as they want.

Chrome already automatically updates to the latest version.
The one caveat is that uproxy app needs to be restarted; because it may have open connection to a social network or peer, it doesn't disconnect and update itself automatically (doing so would break proxying/social network connection).
I think we can have the extension observe when it is newer than the app, and have a button to restart the app to upgrade to the latest version. That will need a little UX design. Updating ticket.

Closing as this is not a priority right now.


fix: remove conflicting transition utilities

Remove the default duplicate Transition utilities in TailwindCSS (they do not need to be redefined) to prevent users from customizing transition effects, such as duration-300 being overridden by the higher priority of the NextUI Plugin and not working.
Removing these redundant transition effects will not cause existing component effects to fail because TailwindCSS already includes them. Please feel free to check the preview documentation page. We only need to set DEFAULT_TRANSITION_DURATION to the DEFAULT key in order to modify the default transition time.
See: https://tailwindcss.com/docs/transition-property

Closes #1502
📝 Description

Add a brief description

⛳ Current behavior (updates)

Please describe the current behavior that you are modifying

🚀 New behavior

Please describe the behavior or changes this PR adds

💣 Is this a breaking change (Yes/No):

No
📝 Additional Information

Summary by CodeRabbit

Bug Fixes

Patched the theme package to resolve conflicts with transition utilities, enhancing CSS compatibility and addressing issue #1502.
Removed conflicting transition definitions affecting CSS classes.

@u3u @jrgarciadev Hello guys, I am having this trouble and I am a beginner , how can I use the fix?


deps(jasmine): upgrade jasmine to 3.3

Use () => Promise<boolean> over Function typings.
Fix an ExpectedConditions test where it was set to a const.
Fix a TypeScript typing interface issue with RunResults in taskRunner.

That worked! There was a bug in the test suite when setting the EC to a const. Since it is a global var it can be changed to a different instance. This is because the EC is tied to the browser, browsers are tied to the session. If you restart the browser or fork the browser, the const EC points to an old session.
I am not sure how this passed in previous tests. We must have made a change recently.

Backed out Jasmine 3.3 changes for ExpectedConditions and other tsc errors.


fix: correct the case for e-mail field in the password reset page

The e-mail input field earlier was displaying the e-mail in uppercase which ideally should have been in lowercase. This pull request resolves that minor issue.
Before making the change :

After making the change :

I have made the change inside the <input> tag as the .form-control class is also being used elsewhere.


Add ability to see all change history of model.

Codecov Report

Merging #318 into master will decrease coverage by 3.24%.
The diff coverage is 38.23%.

@@            Coverage Diff             @@
##           master     #318      +/-   ##
==========================================
- Coverage   97.62%   94.38%   -3.25%
==========================================
  Files          15       15
  Lines         590      623      +33
  Branches       72       75       +3
==========================================
+ Hits          576      588      +12
- Misses          7       26      +19
- Partials        7        9       +2

Impacted Files
Coverage Δ

simple_history/admin.py
82.96% <38.23%> (-15.08%)
:arrow_down:

Continue to review full report at Codecov.

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

You should be able to access the whole change history of a model through the admin by registering the historical model with the admin. I.e. if you have a model called City and you want to be able to see all change history for City, you can register HistoricalCity in the admin. Not sure why you'd want this extra endpoint when you can easily do that.


Make repo for early version of this repo (the ubuntu box)

Trying to do that over here:
https://github.com/mhulse/vagrant-lamp
Still a work in progress. Going to get this one running more smoothly before honing that one.


fix: clean up all FSM CRDs upon uninstallation

Description:

Testing done:

Affected area:

Functional Area

New Functionality
[ ]

CI System
[ ]

CLI Tool
[ ]

Certificate Management
[ ]

Control Plane
[ ]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[ ]

Performance
[ ]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[ ]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project?

Did you notify the maintainers and provide attribution?

Is this a breaking change?

Has documentation corresponding to this change been updated in the fsm-docs repo (if applicable)?

Codecov Report
Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (5933da2) 47.70% compared to head (c361814) 47.71%.

Files
Patch %
Lines

cmd/cli/uninstall_mesh.go
81.48%
5 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@               Coverage Diff                @@
##           release/v1.2     #148      +/-   ##
================================================
+ Coverage         47.70%   47.71%   +0.01%
================================================
  Files               194      194
  Lines             14874    14883       +9
================================================
+ Hits               7095     7101       +6
- Misses             7734     7738       +4
+ Partials             45       44       -1

Flag
Coverage Δ

unittests
47.71% <81.48%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Cultionet create issue

@jgrss
All tests are passing, unit tests pass but having the below issue with cultionet create:
cultionet create --project-path /home/ubuntu/Geography/training_data --grid-size 100 100 --config-file /home/ubuntu/Geography/config.yml --max-crop-class 1 --image-date-format %Y%j

Tried running the above command, it creates the below directories but no .pt files are created.
It creates the below 3 directories:
ckpt
data
figures
The data includes:
     classes.info
     predict
     test
     train

Gives the below Warning:
/home/ubuntu/.local/lib/python3.8/site-packages/pkg_resources/__init__.py:123: PkgResourcesDeprecationWarning: 0.23ubuntu1 is an invalid version and will not be supported in a future release
  warnings.warn(
/home/ubuntu/.local/lib/python3.8/site-packages/pkg_resources/__init__.py:123: PkgResourcesDeprecationWarning: 0.1.36ubuntu1 is an invalid version and will not be supported in a future release
  warnings.warn(
No directory: : 144it [00:00, 152.10it/s]

The train directory includes the below:
train:
    processed:
         (empty)

Also note:
Tried running the above create command on the previous version, it created the below two files:
train:
    processed:
         pre_filter.pt
         pre_transform.pt

But the directories are now empty once upgraded to the latest version.

This is what I get when trying to run cultionet create, and the training file (.pt) is not created:
$ cultionet create --project-path /home/ubuntu/Geography/training_data --grid-size 100 100 --config-file /home/ubuntu/Geography/config.yml --max-crop-class 1 --image-date-format %Y%j
/home/ubuntu/.local/lib/python3.8/site-packages/pkg_resources/__init__.py:123: PkgResourcesDeprecationWarning: 0.23ubuntu1 is an invalid version and will not be supported in a future release
  warnings.warn(
/home/ubuntu/.local/lib/python3.8/site-packages/pkg_resources/__init__.py:123: PkgResourcesDeprecationWarning: 0.1.36ubuntu1 is an invalid version and will not be supported in a future release
  warnings.warn(
No directory: : 144it [00:00, 160.39it/s]

That's for raising this. I will look into it this week.

@varunshah111 could you look at #61 and see if you see any possible solutions from that thread? I think this may be related. If you remain stuck, I would probably need to look at a small sample from the dataset that you are working with.

Thank you! That resolved the issue and were able to create the training files after the changes.
Moving to the next step of training the model. I get the below error:
...
...
  File "/home/ubuntu/.local/lib/python3.8/site-packages/pytorch_lightning/strategies/strategy.py", line 390, in validation_step
    return self.model.validation_step(*args, **kwargs)
  File "/home/ubuntu/.local/lib/python3.8/site-packages/cultionet/models/lightning.py", line 813, in validation_step
    eval_metrics = self._shared_eval_step(batch, batch_idx)
  File "/home/ubuntu/.local/lib/python3.8/site-packages/cultionet/models/lightning.py", line 743, in _shared_eval_step
    loss = self.calc_loss(batch, predictions)
  File "/home/ubuntu/.local/lib/python3.8/site-packages/cultionet/models/lightning.py", line 634, in calc_loss
    crop_star_l2_loss = self.crop_star_l2_loss(
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1130, in _call_impl
    return forward_call(*input, **kwargs)
  File "/home/ubuntu/.local/lib/python3.8/site-packages/cultionet/losses/losses.py", line 373, in forward
    loss = tanimoto_loss(inputs, targets)
  File "/home/ubuntu/.local/lib/python3.8/site-packages/cultionet/losses/losses.py", line 364, in tanimoto_loss
    tpl = (yhat * y).sum(dim=0)
RuntimeError: The size of tensor a (38416) must match the size of tensor b (38221) at non-singleton dimension 0

This is related to one or more of your .pt file data dimensions not aligning with other .pt files. See this reply to the same error.
What is the temporal resolution of your time series?

@varunshah111 See some updates on branch jgrss/v170_issues, with details from issue #67.

Thanks! I was able to create the training data and train the model. Had questions about creating predict dataset. Creating new issue for this.


can't launch unity in renderdoc

Description
can't launch unity in renderdoc

Steps to reproduce
1.open renderdoc and click File/LaunchApplication
2.fill in Executable Path and Command-line Arguments
3.click Launch
4.error information popup

Environment

RenderDoc version: v1.7
Operating System: Win 10
Graphics API: DX11

unity: 2019.3.6f1
log:
RDOC 010236: [20:24:47]    win32_process.cpp( 514) - Log     - Running process C:\Program Files\Unity\Hub\Editor\2019.3.6f1\Editor\Unity.exe
RDOC 010236: [20:24:48]    win32_process.cpp( 597) - Log     - Injecting renderdoc into process 16680
RDOC 010236: [20:24:49]    win32_process.cpp( 385) - Error   - Couldn't find module 'renderdoc.dll' among 92 modules
RDOC 010236: [20:24:49]    win32_process.cpp( 940) - Error   - Can't locate renderdoc.dll in remote PID 16680

Unity these days has a complex relationship with the Unity Hub and so doesn't always directly launch its editor process (instead asking the Hub process to launch it instead). The only way I've found to do it is to ensure no unity processes are running and the launch the hub itself through RenderDoc and ensure you enable capturing child processes.
However Unity has built-in RenderDoc integration which I recommend you use instead if you're unable to configure it for launch correctly.

I have try to use Unity built-in RenderDoc, but when i clicked Load RenderDoc, unity crashed.

Some Unity versions have had bugs that cause crashes loading RenderDoc. Check that you're running the latest version as AFAIK they've been fixed.


Improve models tests

Merging Improve models tests with fixed codes into main.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 97.76358% with 7 lines in your changes missing coverage. Please review.

Files with missing lines
Patch %
Lines

webpage/signals.py
57.14%
6 Missing :warning:

webpage/models.py
80.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Files with missing lines
Coverage Δ

webpage/apps.py
100.00% <100.00%> (ø)

webpage/migrations/0020_profile.py
100.00% <100.00%> (ø)

webpage/modules/builder.py
94.47% <100.00%> (ø)

webpage/tests/test_builder.py
100.00% <100.00%> (ø)

webpage/tests/test_diet.py
100.00% <100.00%> (ø)

webpage/tests/test_equipment.py
100.00% <100.00%> (ø)

webpage/tests/test_equipmentlist.py
100.00% <100.00%> (ø)

webpage/tests/test_favourite.py
100.00% <100.00%> (ø)

webpage/tests/test_ingredient.py
100.00% <100.00%> (ø)

webpage/tests/test_ingredientlist.py
100.00% <100.00%> (ø)

... and 6 more


Separate EasyrtcID From Socket.io

The latest versions of socket.io changed their socket id naming convention to include several additional characters (including #, and /). This broke the regex for expected EasyRTC ID's.
Rather than change the regex, which could break existing apps, I'd like to generate our own EasyRTC ID's. This will also ease a future transition for allowing alternate transports.
This issue was discussed in our forum at:

https://easyrtc.com/forums/viewthread/60/

@dryswabbie Really nice.
Reviewed and did not see particular issue.

@dryswabbie did you try that yet using socket.io 1.4.5 ? Do you want me to setup a test branch for that feature or you think it can be merge.
It would be a major milestone.

I updated out demo.easyrtc.com server to use the beta branch alongside the latest production versions of express and socket.io. So far the fix seems to work well, and I think it's good to go.

👍
Having to use the 0.19.16/7 version of the socket.io server and client is annoying.

@ben-pr-p master branch should support socket.io ^1.3.7
I will merge @dryswabbie work into the up-comming release. See roadmap.

https://github.com/priologic/easyrtc/blob/master/server_example/package.json

Is the current master branch the one published on npm?

The npmjs.org package is linked to @dryswabbie.
I just sent him a request to link it on this repo instead.
Meanwhile you can install that version that is this official one via:

npm install git+https://github.com/priologic/easyrtc

Tested socket 1.5 with success, I will do a separate push for deps update.


⚠ Bofrost.lu has degraded performance

In f349d8e, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2345 ms

Resolved: Bofrost.lu performance has improved in 7ea9727 after 1 hour, 27 minutes.


Client Allocation Request for: This is a test application, please ignore

Client Allocation Questions
Core Information

Name: This is a test application, please ignore
Website / Social Media: [This is a test application, please ignore](This is a test application, please ignore), (This is a test application, please ignore, Twitter)
Region: North America
DataCap Requested: 768 GiB
Addresses to be Notarized: This is a test application, please ignore
Notary Requested: rjan90
Github handle: @

This user’s identity has been verified through filplus.storage


After five hours of internal cost, we switch to economy mode

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue

How Has This Been Tested (if it applies)

Checklist

[x] The documentation is up-to-date with the changes I made.
[x] I have read the CONTRIBUTING document and completed the CLA (see CLA).
[x] All tests passed, and additional code has been covered with new tests.

Deprecated by more recent PR based on ideas discussed here.


Add Ability To Map Channel Groups of the Same Type to Each Other

This feature should enable parity with features found in SoftMotion.  SoftMotion has a concept of an Axis which is essentially a collection of tags (position, velocity, limit enable, etc).  These tags get mapped to plug-in hw, but they do so by binding the axis.  Today we could give the same runtime functionality, but the user experience would be slow, confusing, and error prone.  If we supported channel group abstractions and their mapping, we could support the softmotion use-case and any others like it that come up in the future.

Thinking about it, we should just do a pattern match like :: so it'd be "axis:deathmachine:setpt" or perhaps: "axis:setpt:deathmachine" or something like that. Then do a pattern match through a dialog.

partial implementation in tag editor mapping function. Exec interface is really only responsible for handling the mapping, editor is for making it pretty, so this should be reopened in the editor repo for improvements to that new interface (which absolutely needs improvements)


[ISSSUE 1188]Fix the problem when more than one producer or consumer in the same process can trace only one

What is the purpose of the change
Fix the bug when there are more than one producer (or consumer) , the Tracer can not show all trace infomation.
ISSUE 1188
Brief changelog
Set different ProducerGroup for different TraceProducer, the ProducerGroup will like _INNER_TRACE_PRODUCER-user-specified-producer-group
Verifying this change
Produce and consume message for a same topic in the same process, the console show both produce and consume information.

Coverage increased (+0.2%) to 50.613% when pulling 6d5c7bb7b6cd14cda70a96d67c519a3f030dd7fe on ahuazhu:trace_multi_topic into d66243c03cb903588c0089b7152fe8c8f33bcc84 on apache:develop.

Hi @duhenglucky @ShannonDing @jonnxu  please help to review this pr,together.

If users start the mutiple producer or consumer instances in the same process,the instance name is the same one.You can set different instance name in the start method when the traceProducer is started. @ahuazhu

LGTM

If users start the mutiple producer or consumer instances in the same process,the instance name is the same one.You can set different instance name in the start method when the traceProducer is started. @ahuazhu

If set different instance name for trace producer, multiple client instances will be created.

LGTM

@duhenglucky  when release？Thanks！


Service medal

About the PR

Added a service medal, and replaced the crew medal with the service medal in the hop's office
Why / Balance

it's kind of strange for there to be no service medal.. so i added it.
Technical details

Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

There's abunch of other commits
Changelog

:cl:
add: Added a service medal.

i don't understand why abunch of commits from my local, unmerged pr's keep appearing..
i'm unsure if these actually do anything though..


Allow for osm binary installs to be available post osm installation

Please describe the Improvement and/or Feature Request
OSM supports several project installation at install time using "osm install", but there is no way to install those applications post the osm installation. Support of all installation applications should be available with a "osm deploy" command.
Scope (please mark with X where applicable)

New Functionality          [X]
Install                    [ ]
SMI Traffic Access Policy  [ ]
SMI Traffic Specs Policy   [ ]
SMI Traffic Split Policy   [ ]
Permissive Traffic Policy  [ ]
Ingress                    [ ]
Egress                     [ ]
Envoy Control Plane        [ ]
CLI Tool                   [X]
Metrics                    [ ]
Certificate Management     [ ]
Sidecar Injection          [ ]
Logging                    [ ]
Debugging                  [ ]
Tests                      [ ]
CI System                  [ ]
Demo                       [ ]
Project Release            [ ]

Possible use cases
User deploys OSM with Jaeger and forgets to deploy Prometheus. User can use a command "osm deploy set=OpenServiceMesh.deployPrometheus=true" to update the osm mesh with the same Prometheus installation available with osm install --set=OpenServiceMesh.deployPrometheus=true

There has been no ask for this use case. Will reopen when necessary.


Update is_sorted.py

Changes made-

The first 2 return statements have been changed to break statements. This ensures that the code after the first for loop is executed. Previously it would never execute the latter part.
The second append statement should add elements to stack and not storage_stack. Try the test case [3,4,7,8,5,6]. The program returns True. It should return False.

(Put an X inside the [ ] to denote check mark [X].)

[ ] If creating a new file :

[ ] added links to it in the README files ?
[ ] included tests with it ?
[ ] added description (overview of algorithm, time and space compleixty, and possible edge case) in docstrings ?

[x] if done some changes :

[X] wrote short description in the PR explaining what the changes do ?
[X] Fixes #401  if related to any issue

[ ] other

Pull Request Test Coverage Report for Build 738

2 of 3 (66.67%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 71.54%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

algorithms/stack/is_sorted.py
2
3
66.67%

Totals

Change from base Build 737:
0.05%

Covered Lines:
4306

Relevant Lines:
6019

💛  - Coveralls

@anoubhav Thanks PR, could you add your test case in test_stack.py in tests too?


API docs are broken

https://repman.io/docs/api/
"Unable to render this definition
The provided definition does not specify a valid version field."

Is there any update on this?


first index error fix

If you move the arrow key up at the first index, you will end up in an infinite loop.
I don't think it's a good idea, but you shouldn't have any problems.
Press the up arrow key in the first row

A problem occurred

I would like to use limit, is there any chance to merge this? @fdschmidt93


Add xbps (used by voidlinux) as a package provider

I wanted to use puppet on void-linux, so this PR adds the package provider for xbps.
Let me know if any changes has to be made :)

Can one of the admins verify this patch?

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Forgot to add strings to locales, updated with squash.

Reworded the commit message to pass bundle exec rake commits.

@joshcooper @tvpartytonight (just pinging).
Rebased on tip of main branch removing conflicts, can someone please review.

Hi @Animeshz thanks for your pull request! I had a few minor comments, but generally looked great.

I had a few minor comments, but generally looked great.

I got those addressed (and tested basic functionality on local machine), let me know if anything else has to be done.

Sorry I didn't performed lint checks. I've addressed those nuances now.
And tests should now pass. Please have a look :smile:

closing and reopening to trigger checks

@Animeshz can you fix the rubocop checks by running bundle exec rubocop -a and squash your commits?

It used to pass all checks that time, seems like rubocop rules have been changed since then.

Let me rebase, fix and squash up real quick.


[ndr/daserste]

https://github.com/ytdl-org/youtube-dl/issues/26563
branch daserste-ndr
fix will be merged soon.

@FelixBer
Well, what can I say. I forgot to merge it into latest release. But will do in next release.

Thanks :)

https://github.com/blackjack4494/youtube-dlc/pull/95


Visualize VMs objects and related pods in the Kubernetes tab

What do you want to improve?
Visualize VMs objects and related pods in the Kubernetes tab.
What is the current behavior?
There is no kubernetes objects

What will the new behavior be?
Visualize VMs objects

Visualize Pods

related to https://github.com/janus-idp/backstage-plugins/issues/1807


Add overload for using Set method on a property from a backing model.

This will enable using Set and therefore the OnPropertyChanged and Subscriber notification when dealing directly with Properties on a backing Model of the ViewModel.
Example usage:
public class UserModel
{
    public string Firstname { get; set; }
    public string Lastname { get; set; }
}

public class UserViewModel : ViewModelBase
{
    private UserModel model;

    public string Firstname { get => model.Firstname; set => Set(model, x => x.Firstname, value); }
    public string Firstname { get => model.Lastname; set => Set(model, x => x.Lastname, value); }
}

Missing Unit tests will be added

This is just a Proposal on a feature that I would like to see personally.
However I can totatlly understand if you think this will introduce too much clutter in the code base.

Love to see the contribution, however this breaks with the convention and only partially resolves the underlying issue. It would be better to have the ability to implement INotifyPropertyChanged in the underlying model and then directly binding to a property on the view model that holds an instance of this model. Other frameworks allow to do this and I'm planning on introducing such a functionality but this could lead to breaking changes so this is postponed to the next major release.


fix: route may be undefined when no match

When we just mock one route, if we have more requests than the one mocked, they dont have .route in callHistory. that result in JS error (destructured parameter).route is undefined
    fetchMock.mockGlobal();
    fetchMock.put('/documents', 200, 'updateDocuments');
    // remove line below and then its not working anymore
    fetchMock.route('*', 200);

    await $('>>>.chip.contract').click();
    await fetchMock.callHistory.flush(true);

    expect(
      fetchMock.callHistory.called('updateDocuments')
    ).toBe(true);

I may miss something, but the code change seems to fix this issue

Try using fetchMock.catch() instead of fetchMock.route('*', 200) - that would be the advised approach
Can I also ask what error you get exactly when you don't include the catch all route? Is it thrown from inside the call to flush()? fetch-mock should end up here https://github.com/wheresrhys/fetch-mock/blob/main/packages/fetch-mock/src/Router.ts#L208, but as you're using flush instead of await perhaps that error isn't bubbling up, making it a bit confusing


how to remove the zoom controls from my google map at the bottom right

i have been trying to remove the zoom controls at the bottom right but cant seem to figure out how, any help?

hI @macphailmagwira
Just add zoomControlsEnabled: false,
This platform is not meant for assistance on personal code.
Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

I had no idea, thanks anyway, let me do that, I appreciate the help


need help understanding API / Lambda

trying to read the doc i am not seeing anything regarding servers under API i see i can make a token but thats all.
after contacting Okta they said i am not licensed for it i can make the token.
is this the same as Okta Key of do i have to have API server license to enable this.
sorry i know this is not a bug but needed help understand since i am not a Lambda person at all and when i thought i made the lambda i cant find the  following info
okta_auth_server
client_id
URL for gimme-creds-lambda

Hi, I have a related question. I'm an aws-okta refugee and I'm evaluating gimme-aws-creds as a potential replacement. Why is the Okta API key necessary for gimme-aws-creds? Neither aws-okta nor saml2aws needs one to authenticate with Okta in order to generate temporary AWS credentials.

gimme-aws-creds queries Okta to generate a list of AWS applications that are relevant to the user.  I believe you can avoid the use of an API key entirely if you explicitly configure your gimme-aws-creds to use a specific ARN and Okta application ID.

@Sector95 Thanks, using an ARN and an Okta app-specific SAML URL is what we do for aws-okta (we use a hub-and-spoke model with AssumeRole), so hopefully that will work for us with gimme-aws-creds, as well. I'll follow up here when I've had a chance to try it out.

gimme-aws-creds queries Okta to generate a list of AWS applications that are relevant to the user. I believe you can avoid the use of an API key entirely if you explicitly configure your gimme-aws-creds to use a specific ARN and Okta application ID.

Is there any documentation on this?  Our security team is never going to share a read only API key with everyone.  I tried doing waht you said, but it fails to connect.
❯ cat .okta_aws_login_config
[admin]
okta_org_url = https://auth.url.com <-- my real okta URL
okta_auth_server =
client_id =
gimme_creds_server = internal
aws_appname = AWS - Account <-- This is the app name in Okta
aws_rolename = arn:aws-us-gov:iam::account:role/okta_admin <-- this is a real ARN
write_aws_creds = True
cred_profile = role
okta_username = justin
app_url = https://auth.url.com/home/amazon_aws/fs90kfgkdfg9dfk/272 <-- the APP URL from Okta
resolve_aws_alias = False
include_path = False
preferred_mfa_type = token:hardware
remember_device = False
aws_default_duration = 3600
device_token =
output_format =

❯ gimme-aws-creds --profile admin
OKTA_API_KEY environment variable not found!


Release

As there were implemented list of things we wanted, we release should come (we need those methods in other repositories for working with text matchers).

@yegor256 @Graur what do you think about it?

@includealex @yegor256 The last release was on 15 of September. So, I believe it's time to release eo-srtings

@rultor release, tag is 0.1.0

@rultor release, tag is 0.1.0

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.1.0

@yegor256 Done! FYI, the full log is here (took me 10min)

@includealex It's not done yet. We need to merge this PR first

@includealex the puzzle #114 is still not solved.

@includealex the only puzzle #114 is solved here.

@yegor256 Can we make another release (I suggest version 0.1.1) ? Since this pull request merge was failed: https://github.com/objectionary/home/pull/86#issuecomment-1368049215

@rultor release, tag is 0.1.1

@rultor release, tag is 0.1.1

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.1.1

@yegor256 Done! FYI, the full log is here (took me 13min)


ARROW-6541: [Format][C++] Update Columnar.rst for two-part EOS, update C++ implementation

Trying to reproduce the failure that's occurring in Ursabot Python 2.7 build

I can repro, not sure why it occurs in Python 2.7 but not 3.6/7

@pitrou @emkornfield I found that Python 2.7 wasn't returning aligned memory from io.BytesIO and so I am making the metadata read path copy the metadata unconditionally if it is unaligned (even if the IPC format is implemented properly)


Disable analysis options that are incompatible with input source's output geometry

Waypoint for #6886

[x] get geometry type for a node; async, since it might need to lookup the geometry through the SQL API
[x] update add-analysis view, show loading until geometry type is resolved for given node model
[x] update create-analysis-options-models, disable types that doesn't have matching input geometry and change desc
[x] merge changes to cartodb.js SQL class (to know if describeGeom fails), update shrinkwrap properly etc. :point_right: https://github.com/CartoDB/cartodb.js/pull/1219

@xavijam can you review?
in particular the async get of the geometry type, if you have any other proposals of a simpler way of handling that I'm all ears.
cc @javierarce @urbanphes

Backend tests fail on the CI for some unknown reason, but there are only changes to the frontend in this PR (which pass) so disregard the "default" check for now.

Failures about geocoding quotas and isolines stuff, could you give us some light here @rafatower or @ethervoid?:
Failures:
09:12:42
09:12:42   1) Carto::User behaves like user models User#used_geocoding_quota calculates the used geocoder quota in the current billing cycle
09:12:42      Failure/Error: get_user_by_id(@user1.id).get_new_system_geocoding_calls.should == 210
09:12:42        expected: 210
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/carto/user_spec.rb:6
09:12:42      # ./spec/models/user_shared_examples.rb:129:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   2) Carto::User behaves like user models User#used_geocoding_quota calculates the used geocoding quota for an organization
09:12:42      Failure/Error: @organization.get_new_system_geocoding_calls.should == 230
09:12:42        expected: 230
09:12:42             got: 100.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/carto/user_spec.rb:6
09:12:42      # ./spec/models/user_shared_examples.rb:155:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   3) Carto::User behaves like user models User#used_geocoding_quota calculates the used geocoder quota in the current billing cycle including empty requests
09:12:42      Failure/Error: get_user_by_id(@user1.id).get_new_system_geocoding_calls.should == 220
09:12:42        expected: 220
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/carto/user_spec.rb:6
09:12:42      # ./spec/models/user_shared_examples.rb:166:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   4) Carto::User behaves like user models User#used_here_isolines_quota calculates the used here isolines quota in the current billing cycle
09:12:42      Failure/Error: @user1.get_here_isolines_calls.should == 110
09:12:42        expected: 110
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/carto/user_spec.rb:6
09:12:42      # ./spec/models/user_shared_examples.rb:228:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   5) Carto::User behaves like user models User#used_here_isolines_quota calculates the used here isolines quota for an organization
09:12:42      Failure/Error: @organization.get_here_isolines_calls.should == 220
09:12:42        expected: 220
09:12:42             got: 100.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/carto/user_spec.rb:6
09:12:42      # ./spec/models/user_shared_examples.rb:240:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   6) Carto::User behaves like user models User#used_here_isolines_quota calculates the used here isolines quota in the current billing cycle including empty requests
09:12:42      Failure/Error: @user1.get_here_isolines_calls.should == 120
09:12:42        expected: 120
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/carto/user_spec.rb:6
09:12:42      # ./spec/models/user_shared_examples.rb:250:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   7) refactored behaviour behaves like user models User#used_geocoding_quota calculates the used geocoder quota in the current billing cycle
09:12:42      Failure/Error: get_user_by_id(@user1.id).get_new_system_geocoding_calls.should == 210
09:12:42        expected: 210
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/user_spec.rb:12
09:12:42      # ./spec/models/user_shared_examples.rb:129:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   8) refactored behaviour behaves like user models User#used_geocoding_quota calculates the used geocoding quota for an organization
09:12:42      Failure/Error: @organization.get_new_system_geocoding_calls.should == 230
09:12:42        expected: 230
09:12:42             got: 100.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/user_spec.rb:12
09:12:42      # ./spec/models/user_shared_examples.rb:155:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   9) refactored behaviour behaves like user models User#used_geocoding_quota calculates the used geocoder quota in the current billing cycle including empty requests
09:12:42      Failure/Error: get_user_by_id(@user1.id).get_new_system_geocoding_calls.should == 220
09:12:42        expected: 220
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/user_spec.rb:12
09:12:42      # ./spec/models/user_shared_examples.rb:166:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   10) refactored behaviour behaves like user models User#used_here_isolines_quota calculates the used here isolines quota in the current billing cycle
09:12:42      Failure/Error: @user1.get_here_isolines_calls.should == 110
09:12:42        expected: 110
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/user_spec.rb:12
09:12:42      # ./spec/models/user_shared_examples.rb:228:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   11) refactored behaviour behaves like user models User#used_here_isolines_quota calculates the used here isolines quota for an organization
09:12:42      Failure/Error: @organization.get_here_isolines_calls.should == 220
09:12:42        expected: 220
09:12:42             got: 100.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/user_spec.rb:12
09:12:42      # ./spec/models/user_shared_examples.rb:240:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42   12) refactored behaviour behaves like user models User#used_here_isolines_quota calculates the used here isolines quota in the current billing cycle including empty requests
09:12:42      Failure/Error: @user1.get_here_isolines_calls.should == 120
09:12:42        expected: 120
09:12:42             got: 10.0 (using ==)
09:12:42      Shared Example Group: "user models" called from ./spec/models/user_spec.rb:12
09:12:42      # ./spec/models/user_shared_examples.rb:250:in `block (3 levels) in <top (required)>'
09:12:42
09:12:42 Finished in 8 minutes 31.99 seconds
09:12:42 249 examples, 12 failures, 8 pending

:es:

@viddo @javierarce, @ethervoid has fixed the problem with the failing tests -> https://github.com/CartoDB/cartodb/pull/6986.

Oook, this PR is branched of analysis however so the fix is not there yet, I'll update that one after merging this one then


Generalize Stream::for_each using IntoFuture

Makes the for_each combinator significantly more useful. This is
technically a breaking change due to adding a type parameter to
ForEach and changing the method signature. However, both are very
unlikely to affect code in practice.

@alexcrichton do you feel comfortable landing this in the 0.1 series? It will help on the tutorial front.

@alexcrichton do you feel comfortable landing this in the 0.1 series? It will help on the tutorial front.

Looks good to me, I did an initial run of cargo-crusader and it didn't turn up any real breakage. Due to the closure I doubt anyone is doing much naming a ForEach type specifically, and I think inference still works out, so I think we can get away with this.
Some other PRs though have shown that we may not want to put F: IntoFuture in type parameter lists on structs but rather F::Future directly. It has implications on variance I think mainly.
Would that work here to do that?

Looks good to me, I did an initial run of cargo-crusader and it didn't turn up any real breakage. Due to the closure I doubt anyone is doing much naming a ForEach type specifically, and I think inference still works out, so I think we can get away with this.
Some other PRs though have shown that we may not want to put F: IntoFuture in type parameter lists on structs but rather F::Future directly. It has implications on variance I think mainly.
Would that work here to do that?

Oh I should also mention that I did some initial investigation and found no breakage here, so in that respect we're good to go here.

I don't think we can avoid IntoFuture here, since we need to do the conversion fresh every time the closure is invoked.


Match exact policy type

Signed-off-by: weru<EMAIL_ADDRESS>Related issue
Fixes #654

Proposed Changes

The policy filter will check for an exact match.
I also changed the filter name (from stringContains to yamlContainsPolicy) so that it states what exactly the function does.
Checklist

[x] I have read the contributing guidelines.
[x] I have inspected the website preview for accuracy.
[x] I have signed off my issue.

@JimBugwadia can you please offer review?

@JimBugwadia


Fix e2e test

In ssl mode, dfp has added extra div wrapper to load the creative.

Closing as it fails in IE 11 & Edge. Needs more investigation


TargetUnitCommandEvent.target_unit vs target?

Discussed in https://github.com/ggtracker/sc2reader/discussions/147

Originally posted by zimri-leisher July 28, 2021
I'm relatively new to this library but I think I may have found a small issue: in the TargetUnitCommandEvent class definition, there is a field called target_unit that apparently stores a reference to the unit being targeted. However, in the ContextLoader class, in the handleTargetUnitCommandEvent method, it puts a reference to the target unit into the target field. This caused a small issue for me before I figured it out, and I know it's not a big deal, but I figured I'd better post here.

Interesting. Specifically, you're referring to the definition here
https://github.com/ggtracker/sc2reader/blob/c2a5407cb13fc41e2b44af07ae2a7ba48ffb7695/sc2reader/events/game.py#L330
and corresponding effort to populate it here
https://github.com/ggtracker/sc2reader/blob/c2a5407cb13fc41e2b44af07ae2a7ba48ffb7695/sc2reader/engine/plugins/context.py#L72
and here
https://github.com/ggtracker/sc2reader/blob/c2a5407cb13fc41e2b44af07ae2a7ba48ffb7695/sc2reader/engine/plugins/context.py#L86
Right?
Given that there are references to target in other places like
https://github.com/ggtracker/sc2reader/blob/c2a5407cb13fc41e2b44af07ae2a7ba48ffb7695/sc2reader/events/game.py#L251
and I presume that most people are using target, I think probably the right fix is to change the class definition to declare target not target_unit. What do others think?
@zimri-leisher Can you open a pull request updating that?


Can't find host

Hi! Thanks for putting this together. I have everything running, but can't ping or otherwise resolve the hosts from other machines. I'm very new to mdns, so I'm not sure what to look for or how to interpret what I have found.
avahi-helper log:
dockergen.1 | 2022/04/03 16:52:54 Received event die for container 94a004be6d7e
dockergen.1 | 2022/04/03 16:52:55 Received event stop for container 94a004be6d7e
dockergen.1 | 2022/04/03 16:52:55 Generated 'cnames' from 7 containers
dockergen.1 | 2022/04/03 16:52:55 Running '/usr/src/app/restart.sh'
cname.1    | INFO: Exiting on SIGTERM...
dockergen.1 | 2022/04/03 16:52:55 Contents of cnames did not change. Skipping notification '/usr/src/app/restart.sh'
forego     | starting cname.1 on port 5200
forego     | sending SIGTERM to dockergen.1
forego     | sending SIGTERM to cname.1
dockergen.1 | 2022/04/03 16:52:56 Received signal: terminated

Let's say one of those virtual hosts is test.local.
$ hostname
pi
$ avahi-resolve -n pi.local
pi.local     <IP_ADDRESS>
$ avahi-resolve -nv6 pi.local
Server version: avahi 0.7; Host name: pi.local
pi.local     fe80::c401:bdff:fe96:af0f
$ avahi-resolve -n test.local
pi.local     fe80::c401:bdff:fe96:af0f
$ avahi-resolve -n4 test.local
Failed to resolve host name 'test.local': Timeout reached

Note that the hostname and the virtual host resolve to the same v6 ip address, but the virtual host fails to resolve a v4 version. Not sure if that's significant or an issue.
On another machine:
$ ping test.local
Ping request could not find host test.local. Please check the name and try again.

$ ping pi.local

Pinging pi [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=5ms TTL=64
...

Where should I go from here? Thanks!

@techiebod Thanks for the tip! I did that, and now the container output looks much more promising. However, the results to the test commands above (avahi-resolve and ping) have the same output. Even though this container reports success, I am not able to resolve the cnames from other machines on the network. Any other thoughts? You said it's working for you, so after starting this container, you can successfully ping (or visit) the urls in the VIRTUAL_HOST environment variable values on your other containers? Thanks!

Yep, all works for me, with the following docker-compose config:
  avahi-proxy:     container_name: avahi-proxy     image: hardillb/nginx-proxy-avahi-helper     privileged: true     volumes:       - /var/run/docker.sock:/tmp/docker.sock:ro       - /run/dbus/system_bus_socket:/run/dbus/system_bus_socket:rw     restart: always
And then a container setup like this (some lines removed for brevity):
homer:     image: b4bz/homer     environment:       - VIRTUAL_HOST=blackbox.local       - VIRTUAL_PORT=8080     ports:       - 8080:8080
So with the above on another machine (i.e. not the host or container) I can ping blackbox.local for example.
To test your local Avahi setup you can do the same from the commandline with: avahi-publish -a -R blah.local <host-ip>
Which whilst it runs, should allow you to ping blah.local from another machine.
Or if you prefer (on a mac) run: dns-sd -G v4 blah.local
HTH

Thanks for the confirmation. It's keeping me going, knowing that you're getting it to work! My config now looks like yours (I have several containers I want to host, so they're all on different ports, but otherwise looks the same), and it's still not resolving. avahi-publish works (while running I can ping from another machine). But nothing that avahi-proxy "sets up" seems to be working. Do you know of any way to debug/check on what it's set up, other than pinging? Thanks again.

If you exec into the avahi-proxy (or whatever you've called it) with:
docker exec -it avahi-proxy bash
Can you see your entries in the cnames file?  Mine has all the entries I have active
How this seems to work is that it scans for docker events to add them to here, and then uses another process which is a bit of python to write them onto the dbus for avahi (if I've understood correctly, and I reserve the right to have completely misunderstood! 😄 ).

Thanks for the further suggestions. Everything checks out though.

Can you see your entries in the cnames file? Mine has all the entries I have active

@twastvedt can you show an example of the names you are trying.

Yes. the cnames file has a list of all 6 of the containers with VIRTUAL_HOST set:
esphome.local
home.local
infinitude.local
node-red.local
portainer.local
zwave.local

@twastvedt dunno if you've sorted this yet, or given up! ;)
But if you want to debug this further, given that you can see avahi-proxy is seeing the changes made in docker-land, the next bit is to work out if avahi is seeing them, a killall -USR1 avahi-daemon will get avahi to dump it's "zone" info into syslog, and then you can see if they appear.  Which then at least let's you see if avahi is getting the messages or not

@techiebod Not sorted. I'm out of my depth here, but I'd still love to get this working and still very much appreciate your help.
I did as you suggest. Initially Avahi's cache dump in syslog did not include any of the cnames from avahi-proxy. I don't believe I actually changed anything, but after some fiddling I restarted the machine and now the cnames show up in the syslog!
(Raspberry Pi's name in the below is "katie")
Jun  7 21:01:26 katie avahi-daemon[693]: Got SIGUSR1, dumping record data.
 Is this what the cname lines in syslog should look like?

So that looks good now.  Where are you pinging from?  Can it ping katie.local? If it can ping katie.local based on that info you should be able to ping zwave.local for example.  But this shows that the info has been passed through from docker, and out to avahi, to the proxy is doing it's job :)

Weird. Pinging from my Windows laptop, which is on the same network:
$ ping katie.local

Pinging katie.local [fe80::5fe1:15f:977e:69a7%2] with 32 bytes of data:
Reply from fe80::5fe1:15f:977e:69a7%2: time=5ms
Reply from fe80::5fe1:15f:977e:69a7%2: time=2ms
Reply from fe80::5fe1:15f:977e:69a7%2: time=3ms
Reply from fe80::5fe1:15f:977e:69a7%2: time=2ms

Ping statistics for fe80::5fe1:15f:977e:69a7%2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 5ms, Average = 3ms

$ ping zwave.local
Ping request could not find host zwave.local. Please check the name and try again.

As you say, I guess this is no longer an issue with this project, though now I'm not sure where the issue is!