Open oliv3r opened 1 year ago
While not a hard need, I'd required to merge #179 first, to avoid warnings and errors.
Also, in theory, the container building stage of the pipeline can remove the 'test' as it runs the same tests. Currently, tests are only run for amd64 (or rather, the 'host' OS). But could even test all architectures.
I know its listening on port 80, but is there an easy command we can check this against?
You might want to look at uptime robot and upptime.
One thing missing, is a way to monitor semonitor's health. I know its listening on port 80, but is there an easy command we can check this against? (wget for example). I don't see anything 'LISTENING' on my ports (80, 22221/2), but during startup it does print
ports: 22222, 22221, 80
.
I'm not sure what this would accomplish. On startup semonitor listens on those 3 ports only when it is in network mode for a connection from an inverter to one of them. Once the connection is made it is maintained indefinitely and semonitor doesn't listen on ports any more as long as the connection stays up. If you are monitoring the output of semonitor you can quickly tell if something has stopped working.
You might want to look at uptime robot and upptime.
And what will that do? An external service, that'll do what? The healthcheck is intended to validate that semonitor.py is still functioning properly. E.g. if you send a ping on port 80, it will reply with pong; and it would only do that, if semonitor is happily answering on its interfaces for example. So not sure how uptimerobot would help?
One thing missing, is a way to monitor semonitor's health. I know its listening on port 80, but is there an easy command we can check this against? (wget for example). I don't see anything 'LISTENING' on my ports (80, 22221/2), but during startup it does print
ports: 22222, 22221, 80
.I'm not sure what this would accomplish. On startup semonitor listens on those 3 ports only when it is in network mode for a connection from an inverter to one of them. Once the connection is made it is maintained indefinitely and semonitor doesn't listen on ports any more as long as the connection stays up. If you are monitoring the output of semonitor you can quickly tell if something has stopped working.
Ah right, it's just I noticed that semonitor was printing it, that's all. Your reply makes total sense of course.
So semonitor's output goes to stdout, but the heatlcheck script, generally runs within the container, so we'd have to tee the output somewhere, or have something pickup the output. But whatever we use to check, it'll have to be scriptable and reliable of course.
Personally, I run semonitor with -vv
which tells me that data was sent/received, with just a single -v
it already becomes very silent... food for later ;)
I'll rebase and address the open points later; which should fix the pipeline
Finally the CI builds :) took some effort; but there it is.
Lets test it a bit before merging. I can/will test it on my RS482 SE5000HD setup; Can you test it with your setups? I think you use an Ethernet based setup (is that even supported? I thought the new crypto made it that this is now obsolete)?
@ericbuehl So I've made it that hopefully everybody is happy :) (which is also a very common way 'of the hub' :p).
One "issue" remains, is that for whatever reason, @jbuehl 's limits are linked to LFS and we have run out of LFS quota. I have no idea why this is or how this works. Even on my fork, which you'd expect has its own quota, it didn't work.
I had to create a dummy account, fork the repo (which even then, didn't work) and after requesting to remove the forking relationship (which took a few hours), did it work as you can see here: https://github.com/oliver-githubdummy1/solaredge/actions
The moment I push to this repo however, it still fails with LFS errors.
I therefore suggest to create a new org on github, and transfer (and rename it to semonitor maybe) to there. This would then break all restrictions linked to @jbuehl's account. For link-integrety sake, @jbuehl can then 'fork' the organisations repo to his own space (remove issues and PR's etc) so that it can be found in the same place.
Unless this is all just a bug in github :p but I can't find anybody else complaining ...
The LFS bandwidth quota for my account was exceeded due to the large number of times this PR and its associated test data was uploaded in the past month. The quota will automatically be reset in 13 days, so I would suggest waiting until after July 20 and trying again.
The LFS bandwidth quota for my account was exceeded due to the large number of times this PR and its associated test data was uploaded in the past month. The quota will automatically be reset in 13 days, so I would suggest waiting until after July 20 and trying again.
Oh wow, 1G isn't all that much. I wonder if turning the repo into an org would even remotly help in that case. Maybe opensource projects get more allocation?
It's really weird though that this got yanked out of your account, cause I did most of the work on my fork; with just some pushes (which also count, I know), but the LFS data was hardly touched/modified. I think they are doing something wacco where even a fork's bandwith for LFS accounts for the repo's original owner. I couldn't get my 'dummy' thing working until I disconnected the forking relation ship. Super weird for sure.
I make my case for turning this repo into an organization even more now though;
You must manage billing settings and paid features for each of your accounts separately. You can switch between settings for your personal account, organization accounts, and enterprise accounts using the context switcher on each settings page. For more information, see "About billing on GitHub
So limits are at the least tied to an org; meaning it won't affect your personal account. I've created an org, and made @jbuehl and @ericbuehl owners; feel free to kick me out ;) but this will at least not affect your personal account any longer.
So due to other priorities I hadn't touched this since last time I responded, but it's still complaining about being over quota (or again?).
Can't imagine how it relates to #181 from @ericbuehl ... and don't see any other MR's in this repo ...
The LFS quota is displaying exactly the same message saying it will reset in 13 days, but it obviously didn't. I don't know what is wrong but I don't have any time to spend on this.
@jbuehl understood; the option to transfer this to the org is still an option. I'll try again in 14 days if I remember/have time :)
Meanwhile, @ericbuehl how do you feel about transferring this project to the org? This would take minimal effort of @jbuehl by just hitting the 'transfer' button of this repo, after which you/I can figure out and fix what's going on, without burdering @jbuehl any more then needed.
After the transfer, having a (read-only) fork here (the original location) is a good idea for continuity, but that's secondary/optional.
Thanks!
This MR creates a container environment (Docker, podman etc) to launch semonitor within. This makes life a bit easier in managing solaredge (setting up python and the needed deps).
One thing missing, is a way to monitor semonitor's health. I know its listening on port 80, but is there an easy command we can check this against? (wget for example). I don't see anything 'LISTENING' on my ports (80, 22221/2), but during startup it does print
ports: 22222, 22221, 80
.