Closed KevinWassermann94 closed 1 year ago
This already happens automatically @KevinWassermann94
@shawaj This is for the new OpenFleets for our own units created as part of https://github.com/NebraLtd/hm-dashboard/issues/1090
Ah ok maybe should clarify that.
There's some setup requirements for the open fleets including creating repos and pushing the data to them and linking them up in the Nebra backend. I also think we need to much improve our instructions and deployment instructions for them
Ah ok maybe should clarify that.
There's some setup requirements for the open fleets including creating repos and pushing the data to them and linking them up in the Nebra backend. I also think we need to much improve our instructions and deployment instructions for them
Agreed. That's also part of this exercise.
Have updated the scripts to push to the new commercial fleets.
However as discussed with @KevinWassermann94 we are thinking to remove frequency from diagnostics as per https://github.com/NebraLtd/hm-diag/pull/389 and https://github.com/NebraLtd/hm-diag/pull/326
We will then merge the 868, 915 and 470 fleets into the following OpenFleets:
And the following commercial fleets:
Need to confirm with @kashifpk if this will cause any issues with hotspot production tool or generally speaking for tracking frequency of units in Balena / Nebra dashboard
Think we can close this now @KevinWassermann94 ? The only thing we need to know is from @kashifpk about any issues with onboarding if there is no FREQ environment variable?
@KevinWassermann94 @shawaj - Current HPT implementation requires frequency to be present in the diagnostics report in /initFile.txt
that is returned by hm-diag. In hm-diag frequency is read from an environment variable called FREQ
.
We have a way to set this information in the miner images we send to manufacturing and it is only needed during production for things like printing the frequency on product labels etc.
In a discussion today, @MuratUrsavas's idea of setting it in docker compose used to generate production images and then reading it from a docker volume when hm-diag starts is the implementation that we want. Should not be a big change.
Sounds reasonable to me. So that will mean that we will have the frequency recorded in our dashboard right?
Just not in Balena after the testing? Or it will be persistent?
In a discussion today, @MuratUrsavas's idea of setting it in docker compose used to generate production images and then reading it from a docker volume when hm-diag starts is the implementation that we want.
Just a small reminder, it won't be a docker compose bound solution. Docker compose will be updated for sure, but it won't be frequency specific. It will just get a new volume.
The frequency file will be injected while creating hotspot production images. And will be wiped only in Balena purges. Otherwise it will persist.
I could have some low level solutions to even persist purge events, but I don't see a value in that. That could be handled manually while purging. (Create device specific ENV var, and our software stack will look for that freq file. If not there, will get that info from Balena ENV var and create that file for future use.)
I guess we can close this one now @KevinWassermann94 ?
@KevinWassermann94 commented on Thu Jun 09 2022
Acceptance Criteria: