Update deploy script for OpenFleets

[KevinWassermann94]

@KevinWassermann94 commented on Thu Jun 09 2022

Acceptance Criteria:

• Updates need to be pushed to OpenFleets

[shawaj]

This already happens automatically @KevinWassermann94

[KevinWassermann94]

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

[shawaj]

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]

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]

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 NebraLtd/hm-diag#389 and NebraLtd/hm-diag#326

We will then merge the 868, 915 and 470 fleets into the following OpenFleets:

• RasPi indoor
• RasPi outdoor
• RockPi indoor
• RockPi outdoor

And the following commercial fleets:

• RasPi indoor commercial
• RasPi outdoor commercial
• RockPi indoor commercial
• RockPi outdoor commercial

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]

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]

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

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]

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]

Blocked by:

• Frequency check to check for device tag as well as FREQ env var hm-diag#444
• https://github.com/NebraLtd/hm-dashboard/issues/1479
• https://github.com/NebraLtd/hm-dashboard/issues/1480

[shawaj]

I guess we can close this one now @KevinWassermann94 ?