Closed Bug 1207313 Opened 5 years ago Closed 4 years ago

Implement Update Server to create new product+channel "Foxfood"

Categories

(Release Engineering Graveyard :: Applications: Balrog (backend), defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jgong, Unassigned)

References

Details

User Story

Below is the 3 use cases for implementing IMEI whitelisting for b2g dogfood updates

Scenario #1

Criteria
    Update channel is "dogfood".
Outcome
    User gets regular OTA updates (Gecko and Gaia only).


Scenario #2

Criteria
    Update channel is "foxfood".
    Device is on IMEI whitelist.
Outcome
    User gets both FOTA and possibly OTA updates as well.


Scenario #3

Criteria
    Update channel is "foxfood" (new channel)
    Device is not on IMEI whitelist.

Outcome
    User gets no updates
Create new product+channel "foxfood" as part of implementation of IMEI whitelisting for b2g dogfood updates
Blocks: 1201556
Blocks: 1201538
User Story: (updated)
Thanks for filing this Jean. Just one clarification: 

(Commenting on User Story)
> Below is the 3 use cases for implementing IMEI whitelisting for b2g dogfood
> updates
> 
> Scenario #1
> 
> Criteria
>     Update channel is "dogfood".
> Outcome
>     User gets regular OTA updates (Gecko and Gaia only).

Do you know if we have builds that we'd like to put on this channel already? Or do we need new builds for it?

> 
> Scenario #2
> 
> Criteria
>     Update channel is "foxfood".
>     Device is on IMEI whitelist.
> Outcome
>     User gets both FOTA and possibly OTA updates as well.
> 
> 
> Scenario #3
> 
> Criteria
>     Update channel is "foxfood" (new channel)
>     Device is not on IMEI whitelist.
> 
> Outcome
>     User gets no updates

Both of these scenarios will end up getting fulfilled by a single rule in Balrog once bug 1201538 is landed.
One other thing I should clarify: It should be simple to switch the current "dogfood" users to the "foxfood" channel, but we'll be switching _all_ of them (including those folks who aren't part of the IMEI whitelist). This means that anyone currently on the dogfood channel will get switched to the foxfood channel, and then get no more updates (because they won't be part of the foxfood IMEI whitelist). If that's unacceptable, we could ask Foxfooders to do a one-time reflash to switch their update channel, rather than change it with an OTA update.

Basically, we need one of the distinct populations of users to reflash after we set-up the foxfood channel.

Jean, I don't know if you're the one to make this decision, but I'm pretty sure you can find the person who can :).
Flags: needinfo?(jgong)
Scenario 1 is already happening for aries devices for those people who received a device at whistler.
Side note, Flame devices that are on nightly will have to switch to FOTA (gecko/gaia only) from OTA.

Scenario 2/3 needs to be implemented.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #3)
> Scenario 1 is already happening for aries devices for those people who
> received a device at whistler.

I think those users are going to end up in Scenario #2, because they'll be on the whitelist. They're currently on the "dogfood" channel, but we want to switch them to "foxfood". In the New World, Scenario #1 is developers and users that have done their own builds and put themselves on the dogfood channel.

> Side note, Flame devices that are on nightly will have to switch to FOTA
> (gecko/gaia only) from OTA.

Let's keep Flame and the "nightly" channel out of this to keep things simple - neither are part of any of these scenarios.
Just to ahve this documented in the bug : 
foxfood-test and foxfood-latest would be needed as well as channels for QA to have a staging area to test builds.

I understand the first part would be dealing with the scenarios mentioned in the USer story.
I me with Jean and Doug today to formulate a plan here. They said that the transition plan will involve having Foxfooders flash a new build to change channels. Here's the details of how we'll make the transition:
SCENARIO #2 and #3:
* Adjust the existing build that's on the "dogfood" channel to switch to the "foxfood" channel. We will probably also have it publish FOTAs instead of OTAs as part of this.
* Set-up new rules in Balrog for the following channels. All will have an IMEI whitelist applied to them, each will be otherwise configured as follows:
** "foxfood" - this will always point at a specific dated build, and is used by users on real devices
** "foxfood-test" - this will point to a specific dated build, and is used by QA to test updates before they are pushed live to the "foxfood" channel
** "foxfood-latest" - this will always point to the latest available build (automatically updated each time there's a build). This is also a QA channel.

All of the scenario #2 & 3 set-up should be pretty easy, so I'll have a look at it. Naoki pointed me at bug 1201540, which has a patch that actually looks very close to what we may need, so I'll probably start from it.

SCENARIO #1:
* A new build needs to be set-up for this. It should specify "dogfood" as its update channel, and publish OTA updates. Once set-up, we will adjust the "dogfood" rule in Balrog to always point at the latest version of it.

Setting up a new build is more involved, and out of my wheelhouse - someone else needs to look at this. Jean and Doug are trying to sort out who and when this will happen, but because it's *not* the official channel fo Foxfooders, it's less of a priority than scenarios #2 & 3.


Separately, Doug is going to look over my whitelist management instructions (https://wiki.mozilla.org/ReleaseEngineering/How_To/Update_The_Foxfooding_Program_IMEI_Whitelist) and give them a try in dev. We'll iterate on those if necessary, and create the whitelist in prod once bug 1201538 is pushed there.
Removing needinfo because Jean and I sorted this out (recap in the previous comment).
Flags: needinfo?(jgong)
Gave :nhirita permissions to update the IMEI release blob on production.
Blocks: 1211973
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #5)
> Just to ahve this documented in the bug : 
> foxfood-test and foxfood-latest would be needed as well as channels for QA
> to have a staging area to test builds.
> 
> I understand the first part would be dealing with the scenarios mentioned in
> the USer story.

Created a bug to create 3 new channels: Foxfood-test, Foxfood-latest and Foxfood-staging. Naoki, do you need more channels that these 3? https://bugzilla.mozilla.org/show_bug.cgi?id=1211973
No longer blocks: 1211973
Blocks: 1211973
I think 3 channels for foxfood will do.  Thanks.
What's left to do here?
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(jgong)
As far as I know, foxfood, foxfood-test, and foxfood-latest rules haven't been setup on balrog.
At the same time, there's confusion in regards to the name of foxfood versus b2g-ota.

Based on the conversations that have been happening; we need to verify what builds should be on which rules/releases.  I think there's a meeting tomorrow.

I think we need clarity on the next steps.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(jgong)
We decided to go with b2g-ota and then the project became tier 3. 
so... this is a won't fix.

We're shifting to remove the dogfood=1 out of the builds as well.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.