Fwd: [LocalStorage Team] RFC: OTA Backstop

[Zach Kirschenbaum]

Good morning,

I am following the new RFC process for the Ota Backstop RFC. Nearing the end of step 3: Iterate.

Stakeholders that have provided feedback:

• +Dan Johnson (+2) and +Kevin Wells  on Software Delivery
• +James Sullivan (+2) on Storage + Resilience
• +Adam Barth author of platform versioning RFC

Thoughts on these stakeholders? I am wondering if we should solicit feedback from Managed OS to confirm how this will interact with stepping stones.

---------- Forwarded message ---------
From: Brett Wilson <bre...@google.com>
Date: Tue, Feb 9, 2021 at 7:59 PM
Subject: Re: [LocalStorage Team] RFC: OTA Backstop
To: Zach Kirschenbaum <zkb...@google.com>
Cc: Fuchsia-Eng-Council-Discuss <fuchsia-eng-c...@google.com>, TQ Software Delivery <tq-sw-del...@google.com>, tq-local-storage <tq-local...@google.com>, TQ Managed OS Team <tq-mo...@google.com>

Thanks, I'm very excited about this project.

Brett

On Tue, Feb 9, 2021 at 2:44 PM Zach Kirschenbaum <zkb...@google.com> wrote:

Hi everybody,

Broadcasting here for wider visibility.

https://fuchsia-review.googlesource.com/c/fuchsia/+/481013

This RFC proposes a plan to prevent devices from OTAing backwards across a version boundary. We are currently in the iterate phase and have incorporated feedback from Storage and Software Delivery. If you have additional feedback, please respond by Thursday 02/11 EOD.

LMK if you have any questions!  

--

Zach Kirschenbaum

Pronouns: he/him

--
You received this message because you are subscribed to the Google Groups "tq-local-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tq-local-stora...@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/tq-local-storage/CABcR56Td95xEO9d-ONvZ0%3DY1TQSjsUHSCFoV%2BkKOMRFSeeL7XQ%40mail.gmail.com.

--

Zach Kirschenbaum

Pronouns: he/him

[Adam Barth]

Do we need a stakeholder from security?  From the document, it sounds like the primary use case is during the development phase, which could mean we don't need a security stakeholder.

What about infrastructure?  Does this affect how we manage devices in CI?

Adam

[Zach Kirschenbaum]

thanks, James! That's useful framing so I added it to the "motivation" section.

On Tue, Feb 16, 2021 at 2:52 PM James Sullivan <jfsu...@google.com> wrote:

Although it's a good idea to include all relevant stakeholders, it's also important to note that this proposal doesn't change which OTA sequences are supported and which are not. It just makes this support explicit.

Without this proposal, attempting to backwards-OTA across an incompatible boundary will cause problems when you attempt to boot the device (e.g. the filesystem format might not be supported by the driver). With this proposal, you'd find out about this before you do the OTA (and the error will be much clearer), which just makes things easier for everyone. :)

On Tue, Feb 16, 2021 at 11:33 AM Zach Kirschenbaum <zkb...@google.com> wrote:

Do we need a stakeholder from security?  From the document, it sounds like the primary use case is during the development phase, which could mean we don't need a security stakeholder.

This matches my understanding. Just in case, I'll add on +Allison Pearce, who is the go-to security consultant for SWD.

What about infrastructure?  Does this affect how we manage devices in CI?

My initial thoughts are this should not affect how we manage devices in CI. I just added a patchset explaining how this interacts with the OTA e2e tests. Adding on +Erick Tryzelaar (SWD) and +Anthony Fandrianto (Infra) just in case.

Let me know if there's anything else we need to move this to the "last call" phase.

--

Zach Kirschenbaum

Pronouns: he/him

[Zach Kirschenbaum]

Do we need a stakeholder from security?  From the document, it sounds like the primary use case is during the development phase, which could mean we don't need a security stakeholder.

This matches my understanding. Just in case, I'll add on +Allison Pearce, who is the go-to security consultant for SWD.

What about infrastructure?  Does this affect how we manage devices in CI?

My initial thoughts are this should not affect how we manage devices in CI. I just added a patchset explaining how this interacts with the OTA e2e tests. Adding on +Erick Tryzelaar (SWD) and +Anthony Fandrianto (Infra) just in case.

Let me know if there's anything else we need to move this to the "last call" phase.

On Fri, Feb 12, 2021 at 7:58 PM Adam Barth <aba...@google.com> wrote:

[James Sullivan]

Although it's a good idea to include all relevant stakeholders, it's also important to note that this proposal doesn't change which OTA sequences are supported and which are not. It just makes this support explicit.

Without this proposal, attempting to backwards-OTA across an incompatible boundary will cause problems when you attempt to boot the device (e.g. the filesystem format might not be supported by the driver). With this proposal, you'd find out about this before you do the OTA (and the error will be much clearer), which just makes things easier for everyone. :)

[Zach Kirschenbaum]

Eng council -- would it be possible to move this to "last call"? 

Zach

[James Robinson]

Yes, definitely.

This RFC is now in "Last call" and will be open until 2021-02-23 for last comments and feedback. Stakeholders are encouraged to leave feedback on the review and express their support of (or objection to) the RFC by setting the Code-Review flag to +1 (or -1, as the case may be).

- James

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
To unsubscribe from this group and stop receiving emails from it, send an email to eng-council...@fuchsia.dev.

[Zach Kirschenbaum]

thank you, James! I'll signal boost this on the original thread.

[James Robinson]

This RFC is now accepted as RFC-0071. Congrats!

- James on behalf of FEC