Ok, I guess we are conflating different kinds of flag days here. A major
flag day is when you need user involvement to move forward, such as
creating new Firefox accounts.
What you are describing is an upgrade event, which can be solved through
parallel operations of two services (or two versions of the service).
How well and how invisible we will handle such events depends on how
much we want to invest in the technical solution, but once we went
through one flag day and have the data stored in cleartext we can do
arbitrary storage format and wire protocol format changes.
Worst case we have to operate two services against the same data store
(reving the wire format), or the same service against two data stores
that we cross replicate (reving the storage format). I have yet to hear
any argument why we would have two user visible flag days.
Andreas
Richard Newman wrote:
Brief reply to this, as I try to preserve the non-working weekend:
Sync 1.1 has essentially no upgrade paths. None whatsoever for wire version
changes, awful support for adding new engines, and no upgrade mechanism at all
that respects durability.
The best it can do is blow away all of your server data and lock out all of the other
clients until they upgrade, which was something we weren't willing to do since Firefox 4.
(As such, most of the Sync 2.0 "storage format 6" bugs are saved-up
improvements that were never worth breaking client compatibility. Sync's data formats
haven't changed since 2010.)
Assuming a definition of "flag day" as something like "no client interop across this
event horizon; upgrade required to continue working", then any change to Sync's wire protocol
or storage format would be such a thing. The clients would have no way to negotiate versions, no
way to stage storage format changes, etc. etc.
Even if we put in all of the expected amount of effort to build a service
discovery framework attached to Firefox Account, and switched to a better
storage system by using that (deprecate the old, automatically enable the new),
it would meet the definition of a flag day because it would partition your
devices as they hit the migration point: the old ones wouldn't have client code
for the new system, so they couldn't follow the breadcrumbs. (Even worse if we
don't ship that service discovery framework in v1!)
As I understand the approximate plan of record, we'll be addressing these
limitations by replacing the high-level protocol with one that understands
protocol and storage versioning and negotiation, with the role of the Sync 1.1
and 2.0 codebases being one of code reuse wherever possible. That way we can
rev protocols and storage formats as needed, without unilaterally locking out
clients or wiping data. (And our proposed storage protocols -- treesync and
queuesync -- both address much of the durability-defeating aspects of both Sync
1.1 and 2.0.)
----- Original Message -----
From: "Andreas Gal"<andreas....@gmail.com>
To: "Brian Warner"<war...@mozilla.com>
Cc: sync-dev@mozilla.org
Sent: Friday, August 9, 2013 8:57:30 PM
Subject: Re: The Sync 1.1 elephant^H^H^H^H^H^H option
Help me understand why we need a second flag day when changing wire
formats or storage formats.
Andreas
Sent from Mobile.
On Aug 9, 2013, at 18:02, Brian Warner<war...@mozilla.com> wrote:
On 8/9/13 4:37 PM, Lloyd Hilaiel wrote:
So I'd like to open a venting thread here. Let's capture once and for
all the real, actual, user facing or implementation complexity
downsides of implementing a new authentication flow and grafting it
onto Sync 1.1.
I expect rnewman will express this better than I can, but he mentioned
this morning that we basically get one flag day. It's not the super-bad
"everybody must change at the exactly same time" kind of flag day. But
it's a still-kinda-bad "everybody must do a one-way account upgrade
during some multi-month overlap between new-servers-launched and
old-servers-shut-down window" upgrade/flag-day.
If we use that upgrade to get from Sync1.1+OldAuth to Sync1.1+NewAuth,
we'll land on a system that is known to be fragile, and about which I've
heard scalability/ops problems. To upgrade from there to a more
stable/scalable protocol, we'd need a second flag day, and that'd be too
embarrasing to pull off.
cheers,
-Brian
_______________________________________________
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
