NebraLtd / helium-miner-software

Software for Nebra (and third party) Helium Miners
https://nebra.io/hnt
MIT License
94 stars 48 forks source link

Update deploy script for OpenFleets #473

Closed KevinWassermann94 closed 1 year ago

KevinWassermann94 commented 2 years ago

@KevinWassermann94 commented on Thu Jun 09 2022

Acceptance Criteria:

shawaj commented 2 years ago

This already happens automatically @KevinWassermann94

KevinWassermann94 commented 2 years ago

@shawaj This is for the new OpenFleets for our own units created as part of https://github.com/NebraLtd/hm-dashboard/issues/1090

shawaj commented 2 years ago

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

vpetersson commented 2 years ago

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.

shawaj commented 1 year ago

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

shawaj commented 1 year ago

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?

kashifpk commented 1 year ago

@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.

shawaj commented 1 year ago

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?

MuratUrsavas commented 1 year ago

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.)

shawaj commented 1 year ago

Blocked by:

shawaj commented 1 year ago

I guess we can close this one now @KevinWassermann94 ?