Update deploy script to new commercial fleets
KevinWassermann94 opened this issue · 25 comments
@KevinWassermann94 commented on Thu Jun 02 2022
The deploy script needs to be updated to push new releases to the before-created OpenFleets.
Requirements
https://github.com/NebraLtd/hm-dashboard/issues/1090
Acceptance Criteria
- New updates are pushed to all newly created fleets
- Updates are not pushed to old fleets anymore
- Only relevant to our own fleets (no 3rd party vendor)
- Manually consolidate existing fleets into newly created commercial fleets (moving can be outsourced)
Well, I dropped third party vendors, but still looking a little bit crowded. @vpetersson @KevinWassermann94 @marvinmarnold Are we cool with this? 🤔
What about this one?
The hardware definitions are defined here. It should be nebra-light1 and nebra-light2
So we're assuming the Raspberry Pi Zero option would not be used for nebra-light2?
nebra-light1 Should be the RasPi version
nebra-light2 Should be the Radxa version
@marvinmarnold What do you think?
Nope, this wouldn't cut it as the Light Hotspot II Raspi has different config compared to Light Hotspot I. Either we'll ignore the Raspberry Pi option for Light Hotspot II, or create a variance like nebra-light2-radxa and nebra-light2-raspi.
What's your idea behind nebra-light1 and nebra-light2?
Imo light1 should be exclusive to Raspi and light2 is exclusive to Radxa?
I'm OK if we'd decide to make nebra-light2 exclusive to Radxa, but we'd be losing Raspi option there. Just want to make sure this is intentional.
I'm opting to define two variants today as the topic is still hot in my mind. Otherwise in case of a need, we should have to revisit the design later and create a variant anyway with a more confusing name (if we have a nebra-light2, then what the hell is nebra-light2-raspi? Is it the old one? Is it a newer one? Who the f.... 😄 )
Just to be clear:
nebra-light1 Is our first version of the light hotspot based on the RasPi Zero
nebra-light2 is our first version of the light hotspot based on the Radxa Zero
Similar to our nebra-indoor1 being our RasPi CM3 and nebra-indoor2 being our RockPi
@KevinWassermann94 yes, I know that. But the Light Hotspot II has two configurations (leave the original light hotspot aside for a sec). It can either use Raspberry Pi Zero (1 or 2) or Radxa Zero. Besides Light Hotspot I, we have actually two Light Hotspot II. So we have three in total. I guess this is the confusing part.
If they are not compatible, and we need three distinct configurations, then make it 'light3'
OK, nebra-light3 then. I'll add more info into the friendly name of the variant. Will add that later with another issue and PR after @pritamghanghas finishes his PR in hm-pyhelper.
@MuratUrsavas beware changing the friendly name as the effects how the app shows up the correct hotspot image I believe. And how it reads in diagnostics.
I think if we want to add arbitrary extra info we should do it as a comment or a new key value pair to make sure it doesn't cause issues
@shawaj No worries. Friendly name is just an information and not taken into consideration for any automatic operation. I'll keep an eye on it for any kind of issues.
Friendly name is used for diagnostics and app if there is no APPNAME specified I believe
EDIT: actually I just checked, the FRIENDLY name is used in the diagnostics page for all variants
Only relevant to our own fleets (no 3rd party vendor)
Presumably you don't mean to remove the 3rd parties, just that we don't need to change them, right?
Presumably you don't mean to remove the 3rd parties, just that we don't need to change them, right?
Correct. We're only dealing with our own fleets in this phase. The 3rd party ones will be dealt with later. They should be left as is for now.
@shawaj I'd like to get rid of storing device compose files for each variant in the repo. It is creating many unnecessary commits for every release and they are just automatic files, which should not be kept in an SCM system. Now with variants, there will be even more (switching from SBC to Variant and will discriminate it in gen_docker_compose.py).
I have a strong opinion about not keeping auto generated files in repositories. Since we have a good automation sub-system with GitHub Actions, we should not keep them.
@MuratUrsavas the compose files will mostly likely move to their own repos to meet requirements of openfleet.
@MuratUrsavas I see your point but they are consumed by people that don't know our codebase as well and they are needed for open fleets as @pritamghanghas has said.
So IMO it's not even a question, it's a necessity to keep them.
The only caveat to that is that as @pritamghanghas says we have separate repos such as https://github.com/NebraLtd/helium-cotx
But I think it makes more sense to store these all centrally in this repo and then federate the files out beyond that.
Also if we are moving to them being by variant, then this can be done in a single commit
It would be superb if we could do that with a pre-commit hook. This way we all could be happy 😄
For not keeping auto-generated files we could also add a simple instruction how to create that docker-compose with a simple command. I'm sure those consumers could create that file very easily, since there won't be a docker-compose.yml file around.
Well if we are moving to doing it by variant, it probably doesn't need to be separated into a matrix and so it can all be in a single commit. Or we could move it to a repository dispatch action in the same repo or something if that's easier
@shawaj We have to use a matrix since we have different deployments for the same commit. We can generate those files in one shot, though.
@NebraLtd/device-team this has been removed from the sprint